For anyone reading this because the isc-dhcp-client update broke their DHCPv6 network:
First, I assume you're running a DHCPv6 server to provide the ipv6 addresses to your clients. If you do not have any Router Advertisement service configured on your server, the easiest thing to do is use radvd. # sudo apt install radvd radvd requires ipv6 forwarding to be enabled (on the server), which you likely already have enabled, but if not you should edit /etc/sysctl.conf to uncomment/add: net.ipv6.conf.all.forwarding=1 then create a /etc/radvd.conf file with contents similar to this, replacing IFACE with the interface name and using the appropriate ipv6 prefix/len for your network: interface IFACE # your interface name { AdvSendAdvert on; # send RA's on this interface AdvManagedFlag on; # clients will request DHCPv6 addr AdvOtherConfigFlag on; # clients will use DHCPv6 other config AdvDefaultLifetime 0; # this server is NOT a default router (gateway) prefix 2001:db8::/64 # your subnet prefix/len { AdvOnLink on; # everyone in this subnet is "on (this) link" AdvAutonomous off; # clients will NOT use SLAAC (RFC 4862) addrs }; }; You can of course leave the # comments out. Then (re)start the radvd daemon, or just reboot the server. For comparision, here is an interface before the isc-dhcp-client update, without any RA: ubuntu@lp1609898-xenial:~$ ip addr show ens7 3: ens7: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000 link/ether 52:54:00:5f:c4:ee brd ff:ff:ff:ff:ff:ff inet6 2001:db8::55/64 scope global valid_lft forever preferred_lft forever inet6 fe80::5054:ff:fe5f:c4ee/64 scope link valid_lft forever preferred_lft forever ubuntu@lp1609898-xenial:~$ ip -6 route 2001:db8::/64 dev ens7 proto kernel metric 256 pref medium fe80::/64 dev ens7 proto kernel metric 256 pref medium and after the update, with RA (radvd configured with above conf): ubuntu@lp1609898-xenial:~$ ip addr show ens7 3: ens7: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000 link/ether 52:54:00:5f:c4:ee brd ff:ff:ff:ff:ff:ff inet6 2001:db8::55/128 scope global valid_lft forever preferred_lft forever inet6 fe80::5054:ff:fe5f:c4ee/64 scope link valid_lft forever preferred_lft forever ubuntu@lp1609898-xenial:~$ ip -6 route 2001:db8::55 dev ens7 proto kernel metric 256 pref medium 2001:db8::/64 dev ens7 proto kernel metric 256 expires 86389sec pref medium fe80::/64 dev ens7 proto kernel metric 256 pref medium I tested on both xenial and trusty. -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to network-manager 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 Committed Status in network-manager source package in Precise: Invalid Status in isc-dhcp source package in Trusty: Fix Committed Status in network-manager source package in Trusty: Triaged Status in isc-dhcp source package in Xenial: Fix Committed Status in network-manager source package in Xenial: Triaged 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 -- Mailing list: https://launchpad.net/~desktop-packages Post to : desktop-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~desktop-packages More help : https://help.launchpad.net/ListHelp