Unfortunately, while I initially put in the bug description that there
was no regresssion potential, I've been made aware that some network
configurations rely on the previous (incorrect) behavior of the dhcp
client to set a prefix len of /64.  Such configurations will break when
the dhcp clients are updated, and the dhcp server must be updated to use
Router Advertisements to provide the prefix len to dhcp clients.  I
updated the description's Regressions section with more details.

** Description changed:

  [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]
  
- None.  Non-standard (i.e. not /64) subnets served by dhcpv6 currently
- are broken, this fixes that.
+ 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.
+ 
  
  [Other info]
  
  This is fixed in debian:
  https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=684009

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

Title:
  dhclient incorrectly assumes a /64 ipv6 prefix

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

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

Reply via email to