Comment 0 for bug 1609898

[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.

[Other info]

This is fixed in debian:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=684009