dhclient incorrectly assumes a /64 ipv6 prefix

Patched builds for precise, trusty, xenial at ppa:
https://launchpad.net/~ddstreet/+archive/ubuntu/lp1609898

yakkety build also at ppa

The attachment "lp1609898-precise.debdiff" seems to be a debdiff. The ubuntu-sponsors team has been subscribed to the bug report so that they can review and hopefully sponsor the debdiff. If the attachment isn't a patch, please remove the "patch" flag from the attachment, remove the "patch" tag, and if you are member of the ~ubuntu-sponsors, unsubscribe the team.

[This is an automated message performed by a Launchpad user owned by ~brian-murray, for any issue please contact him.]

In what circumstances do dhcpv6 servers hand out an IPv6 address without also reporting the prefix length the client should use? Something seems wrong here. (Is it me? :)

Thanks

> In what circumstances do dhcpv6 servers hand out an IPv6 address without also reporting
> the prefix length the client should use? Something seems wrong here. (Is it me? :)

unfortunately the dhcpv6 spec (RFC 3315) doesn't provide a way for a dhcpv6 server to tell a client what the address's prefix length is. It just provides the address.

Router Advertisement messages do provide prefix length, but that's a different protocol from dhcpv6; sometimes dhcpv6 and RA are provided by a server, and sometimes only one of dhcpv6 or RA are provided.

RA allows clients to "auto" generate ipv6 addresses, inside the prefix length. dhcpv6 provides specific ipv6 addresses to clients, but doesn't tell them the prefix length. Clients don't need the prefix length if they are assigned the full ipv6 address, because they can find other on-link ipv6 addresses using Neighbor Discovery, and dhcpv6 does provide its link-local server address (to use as a default route).

This was already uploaded for yakkety a while ago: https://launchpad.net/ubuntu/+source/isc-dhcp/4.3.3-5ubuntu13.1

It is stuck in proposed (http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#isc-dhcp) due to some NetworkManager test regression. I retried those and will watch out for this.

I sponsored the SRUs to the review queues. Unsubscribing sponsors now.

Hello Dan, or anyone else affected,

Accepted isc-dhcp into xenial-proposed. The package will build now and be available at https://launchpad.net/ubuntu/+source/isc-dhcp/4.3.3-5ubuntu12.2 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!

tested on xenial:

using isc-dhcp-client 4.3.3-5ubuntu12.1, bug exists; dhcpv6 prefix is set to /64.

using isc-dhcp-client 4.3.3-5ubuntu12.2, bug is fixed; dhcpv6 prefix is correctly set to /128.

tested on yakkety:

using isc-dhcp-client 4.3.3-5ubuntu13, bug exists; dhcpv6 prefix is set to /64.

using isc-dhcp-client 4.3.3-5ubuntu13.1, bug is fixed; dhcpv6 prefix is set correctly to /128.

Hello Dan, or anyone else affected,

Accepted isc-dhcp into trusty-proposed. The package will build now and be available at https://launchpad.net/ubuntu/+source/isc-dhcp/4.2.4-7ubuntu12.7 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!

Hello Dan, or anyone else affected,

Accepted isc-dhcp into precise-proposed. The package will build now and be available at https://launchpad.net/ubuntu/+source/isc-dhcp/4.1.ESV-R4-0ubuntu5.11 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!

The change in isc-dhcp for Xenial may be causing a NetworkManager test regression.

http://autopkgtest.ubuntu.com/packages/n/network-manager/xenial/amd64

I assume you mean these 2 failing tests, below; that's correct behavior now, the tests should be changed to expect a /128 DHCPv6 address instead of a /64 DHCPv6 address.

======================================================================
FAIL: test_open_b_ip6_dhcp (__main__.T)
Open network, 802.11b, IPv6 with DHCP
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/tmp/autopkgtest.O8S7lL/build.sFx/network-manager-1.2.0/debian/tests/wpa-dhclient", line 55, in test_open_b_ip6_dhcp
    ['11.0'])
  File "/tmp/autopkgtest.O8S7lL/build.sFx/network-manager-1.2.0/debian/tests/wpa-dhclient", line 149, in do_test
    self.check_address(ipv6)
  File "/tmp/autopkgtest.O8S7lL/build.sFx/network-manager-1.2.0/debian/tests/wpa-dhclient", line 228, in check_address
    self.assertRegex(out, 'inet6 2600::[0-9a-z]+/64')
AssertionError: Regex didn't match: 'inet6 2600::[0-9a-z]+/64' not found in '20: wlan0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000\n link/ether 02:00:00:00:00:00 brd ff:ff:ff:ff:ff:ff\n inet6 2600::11/128 scope global tentative \n valid_lft forever preferred_lft forever\n inet6 fe80::ff:fe00:0/64 scope link \n valid_lft forever preferred_lft forever\n'

======================================================================
FAIL: test_wpa2_ip6 (__main__.T)
WPA2, 802.11g, IPv6
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/tmp/autopkgtest.O8S7lL/build.sFx/network-manager-1.2.0/debian/tests/wpa-dhclient", line 137, in test_wpa2_ip6
    'Authentication suites: PSK'])
  File "/tmp/autopkgtest.O8S7lL/build.sFx/network-manager-1.2.0/debian/tests/wpa-dhclient", line 149, in do_test
    self.check_address(ipv6)
  File "/tmp/autopkgtest.O8S7lL/build.sFx/network-manager-1.2.0/debian/tests/wpa-dhclient", line 228, in check_address
    self.assertRegex(out, 'inet6 2600::[0-9a-z]+/64')
AssertionError: Regex didn't match: 'inet6 2600::[0-9a-z]+/64' not found in '45: wlan0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000\n link/ether 02:00:00:00:00:00 brd ff:ff:ff:ff:ff:ff\n inet6 2600::12/128 scope global tentative \n valid_lft forever preferred_lft forever\n inet6 fe80::ff:fe00:0/64 scope link \n valid_lft forever preferred_lft forever\n'

tested on precise:

using isc-dhcp-client 4.1.ESV-R4-0ubuntu5.10, bug exists; dhcpv6 prefix is set to /64.

using isc-dhcp-client 4.1.ESV-R4-0ubuntu5.11, bug is fixed; dhcpv6 prefix is set correctly to /128.

tested on trusty:

using isc-dhcp-client 4.2.4-7ubuntu12.6, bug exists; dhcpv6 prefix is set to /64.

using isc-dhcp-client 4.2.4-7ubuntu12.7, bug is fixed; dhcpv6 prefix is set correctly to /128.

The attached debdiffs lp1609898-nm-[trusty|xenial|yakkety].debdiff patch network-manager's debian/tests/wpa-dhclient test to use /128 instead of /64 for its DHCPv6 address test.

Note it leaves the ipv6 Router Advertisement provided addresses with /64, as that prefix length is provided to the client (unlike DHCPv6) in the RA messages.

@ddstreet,
Can you propose a patch for network manager to adjust test cases to this new behavior? I'm wondering if there are other parts of network-manager that may expect /64 instead of /128 and break existing users.

@arges, yep the attached lp1609898-nm-[trusty|xenial|yakkety].debdiff patches update network-manager's test script to the new behavior. I can pull the patches out of the debdiffs, if that's easier.

I did a brief search in the network-manager tests and didn't find any other place that looks like it's testing the dhcpv6-provided address; I'll also try nm with the updated isc-dhcp-client to see if anything breaks.

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.

Adjusted the network-manager test for yakkety: https://git.launchpad.net/~network-manager/network-manager/+git/ubuntu/commit/?id=756271bf57

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.

Also note that dnsmasq can act as both a dhcpv6 server as well as serving router advertisements.

The ISC dhcp server only does dhcpv6, it does not have support (that I know of) for serving router advertisements.

If you do want your clients to use slaac addresses in addition to the dhcpv6 address, change:
  AdvAutonomous on; # clients will use SLAAC (RFC 4862) addrs

If you do want your server to act as the client's default router (gateway), remove:
  # AdvDefaultLifetime 0; # this server is a default router (gateway) when commented
or change the value to a non-zero number of seconds

This bug was fixed in the package isc-dhcp - 4.1.ESV-R4-0ubuntu5.11

---------------
isc-dhcp (4.1.ESV-R4-0ubuntu5.11) precise; urgency=medium

  * Don't assume IPv6 prefix length of 64 (LP: #1609898).
    Pulled from debian commit c347ab8a43587164486ce1f104eedfd638594e59.

 -- Dan Streetman <email address hidden> Thu, 04 Aug 2016 13:07:23 -0400

The verification of the Stable Release Update for isc-dhcp has completed successfully and the package has now been released to -updates. Subsequently, the Ubuntu Stable Release Updates Team is being unsubscribed and will not receive messages about this bug report. In the event that you encounter a regression using the package from -updates please report a new bug using ubuntu-bug and tag the bug report regression-update so we can easily find any regressions.

This bug was fixed in the package isc-dhcp - 4.2.4-7ubuntu12.7

---------------
isc-dhcp (4.2.4-7ubuntu12.7) trusty; urgency=medium

  * Don't assume IPv6 prefix length of 64 (LP: #1609898).
    Pulled from debian commit c347ab8a43587164486ce1f104eedfd638594e59.

 -- Dan Streetman <email address hidden> Thu, 04 Aug 2016 13:07:23 -0400

This bug was fixed in the package isc-dhcp - 4.3.3-5ubuntu12.3

---------------
isc-dhcp (4.3.3-5ubuntu12.3) xenial; urgency=medium

  [ Mathieu Trudel-Lapierre ]
  * debian/isc-dhcp-client.install: install new files for initramfs-tools
    to their proper locations; from debian/initramfs-tools. (LP: #1621507)

 -- LaMont Jones <email address hidden> Fri, 23 Sep 2016 15:09:46 -0600

Cherry-picked into xenial branch.

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!

http://autopkgtest.ubuntu.com/packages/n/network-manager succeeds again on xenial, thus verified.

This bug was fixed in the package network-manager - 1.2.4-0ubuntu1

---------------
network-manager (1.2.4-0ubuntu1) yakkety; urgency=medium

  [ Aron Xu ]
  * Imported Upstream version 1.2.4
  * Update patches for new upstream release:
    - Filter-DNS-servers-to-add-to-dnsmasq-based-on-availa.patch: not needed
    - Order-IPv6-nameservers-before-IPv4-for-dns-plugins-d.patch: not needed
    - libnm-don-t-require-initialized-out_encrypted-argume.patch: merged upstream
    - cli-initialize-connection-list-in-do_device_connect.patch: merged upstream
    - rename due to gbp-pq:
      Don-t-block-network.target-on-NetworkManager-wait-on.patch =>
      systemd-Don-t-enable-NetworkManager-wait-online.serv.patch
    - post-release cherry-picks:
      - wifi-clear-WiFi-requested_scan-if-suppl-exits.patch
      - wifi-clear-WiFi-requested_scan-if-suppl-goes-INACTIV.patch
    - refreshed remaining ones

  [ Martin Pitt ]
  * debian/tests/wpa-dhclient: Don't assume that the IPv6 prefix length from
    the DHCP server is /64. (LP: #1609898)
  * debian/tests/*rfkill*: Load fake-rfkill.ko's dependencies before trying to
    insserv it. (LP: #1626568)
  * debian/tests/killswitches-no-urfkill: Make the script work with set -e, so
    that we don't try to run tests after compile errors.
  * Switch back to dns=dnsmasq for Ubuntu 16.10. We still don't have a DNS
    plugin for resolved, and don't want to break domain-specific DNS servers
    for the final release.

 -- Martin Pitt <email address hidden> Tue, 27 Sep 2016 08:16:12 +0200

This bug was fixed in the package isc-dhcp - 4.3.3-5ubuntu14

---------------
isc-dhcp (4.3.3-5ubuntu14) yakkety; urgency=medium

  * Add an initramfs-tools hook and ship everything we need to run dhclient in
    the initramfs. This is necessary for proper IPv6 netboot support.
    (LP: #1621507)

 -- Mathieu Trudel-Lapierre <email address hidden> Wed, 21 Sep 2016 09:57:48 -0400

With this fix, my IPv6 service from Comcast broke.

Specifically, they hand out an IP on the /64 via dhcpv6, with the default gateway being an IP on the same /64, along with an IA /56 for the customer to use locally.

Adding the default route fails because there is no route to said gateway (since we have decided that we have a /128).

I have confirmed that the machine is accepting router advertisements, and that comcast is not sending them.

After further checking, comcast is sending them, my machine is just not seeing them... Will file a separate bug.

This bug was fixed in the package network-manager - 1.2.2-0ubuntu0.16.04.3

---------------
network-manager (1.2.2-0ubuntu0.16.04.3) xenial; urgency=medium

  * debian/tests/wpa-dhclient: Don't assume that the IPv6 prefix length from
    the DHCP server is /64. (LP: #1609898)

network-manager (1.2.2-0ubuntu0.16.04.2) xenial; urgency=medium

  [ Martin Pitt ]
  * Read config and system connections from /run/NetworkManager/ to support
    netplan (LP: #1627641)
  * debian/gbp.conf: Set debian-branch to xenial

  [ Mathieu Trudel-Lapierre ]
  * Add dns-manager-don-t-merge-split-DNS-search-domains.patch: do not add
    split DNS search domains to resolv.conf; doing so would risk leaking names
    to non-VPN DNS nameservers when attempting to resolve non- FQDN names.
    (LP: #1592721)

 -- Martin Pitt <email address hidden> Tue, 27 Sep 2016 16:29:22 +0200