[Bug 1609898] Re: dhclient incorrectly assumes a /64 ipv6 prefix

[Andy Whitcroft]

Hello Dan, or anyone else affected,

Accepted network-manager into xenial-proposed. The package will build
now and be available at https://launchpad.net/ubuntu/+source/network-
manager/1.2.2-0ubuntu0.16.04.3 in a few hours, and then in the -proposed
repository.

Please help us by testing this new package.  See
https://wiki.ubuntu.com/Testing/EnableProposed for documentation how to
enable and use -proposed.  Your feedback will aid us getting this update
out to other Ubuntu users.

If this package fixes the bug for you, please add a comment to this bug,
mentioning the version of the package you tested, and change the tag
from verification-needed to verification-done. If it does not fix the
bug for you, please add a comment stating that, and change the tag to
verification-failed.  In either case, details of your testing will help
us make a better decision.

Further information regarding the verification process can be found at
https://wiki.ubuntu.com/QATeam/PerformingSRUVerification .  Thank you in
advance!

** Tags added: verification-needed

-- 
You received this bug notification because you are a member of Ubuntu
Foundations Bugs, which is subscribed to isc-dhcp in Ubuntu.
https://bugs.launchpad.net/bugs/1609898

Title:
  dhclient incorrectly assumes a /64 ipv6 prefix

Status in isc-dhcp package in Ubuntu:
  Fix Committed
Status in network-manager package in Ubuntu:
  Fix Committed
Status in isc-dhcp source package in Precise:
  Fix Released
Status in network-manager source package in Precise:
  Invalid
Status in isc-dhcp source package in Trusty:
  Fix Released
Status in network-manager source package in Trusty:
  Triaged
Status in isc-dhcp source package in Xenial:
  Fix Released
Status in network-manager source package in Xenial:
  Fix Committed
Status in isc-dhcp source package in Yakkety:
  Fix Committed
Status in network-manager source package in Yakkety:
  Fix Committed
Status in isc-dhcp package in Debian:
  Fix Released

Bug description:
  [Impact]

  clients who get an ipv6 address from a dhcpv6 server assume the
  address has a /64 prefix, but that is not necessarily true, and if the
  subnet is different than /64 those clients will not be able to reach
  other addresses in that /64 prefix because the other systems are not
  on-link.  This /64 assumption of dhclient effectively breaks the
  client networking for certain addresses.

  [Test Case]

  Set up a server with two interface nics, and one client connected to
  each of those interfaces.  On the server, set up a ipv6 subnet on each
  interface, with a larger prefix than /64, e.g.:

  2001:db8:0:0:1::/96
  2001:db8:0:0:2::/96

  configure dhcpv6 on the server, to provide ipv6 addresses on each
  interface.  Set the server as the default ipv6 route for the clients.

  Allow the clients to get dhcpv6 ipv6 addresses from the server.  The
  clients will each get a ipv6 address with a /64 prefix, due to the bug
  in dhclient.

  Try to ping (or otherwise communicate) between the clients.  Since
  they have /64 prefixes, they think they are on-link with each other,
  but they are not, so they can't communicate.

  After the dhclient bug is fixed, repeat the above setup, and the
  clients will get /128 prefixes instead, and then will be able to
  communicate with each other, because they will route the traffic to
  each other through the server.

  [Regression Potential]

  Non-standard (i.e. not /64) subnets served by dhcpv6 currently are
  broken, this fixes that.

  However, any ipv6 network configurations that rely on the previous
  incorrect assumed /64 behavior (as described here:
  https://tools.ietf.org/html/rfc5942#section-5) in order to allow
  dhcpv6 clients to communicate with other systems inside the subnet,
  but do not use RA to also provide clients with the actual prefix len,
  will break.

  To clarify: a server that provides clients with dhcpv6 addresses, but
  does not also provide the prefix len via RA, will change behavior;
  previously, all clients on the subnet could talk directly to each
  other, with this update the clients cannot talk to each other
  directly; all traffic between clients will be routed through the
  default gateway.

  Further, if the network does not provide a default gateway - for
  example a local network that is intended only for traffic between
  local servers - the clients will not be able to talk to each other at
  all.

  Note that such configurations *are* broken configurations, that just
  happened to work before because of incorrect dhcp client behavior;
  such configurations must be updated to perform RA to provide the
  prefix len to clients.

  See comment 30 for details on how to configure radvd to restore
  network functionality.

  [Other Info]

  This is fixed in debian:

  https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=684009

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/isc-dhcp/+bug/1609898/+subscriptions