dhclient incorrectly assumes a /64 ipv6 prefix

Bug #1609898 reported by Dan Streetman on 2016-08-04
32
This bug affects 4 people
Affects Status Importance Assigned to Milestone
isc-dhcp (Debian)
Fix Released
Unknown
isc-dhcp (Ubuntu)
Medium
Dan Streetman
Precise
Medium
Unassigned
Trusty
Medium
Unassigned
Xenial
Medium
Unassigned
Yakkety
Medium
Dan Streetman
network-manager (Ubuntu)
Medium
Martin Pitt
Precise
Undecided
Unassigned
Trusty
Medium
Unassigned
Xenial
Medium
Unassigned
Yakkety
Medium
Martin Pitt

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

Dan Streetman (ddstreet) wrote :
Dan Streetman (ddstreet) wrote :
Dan Streetman (ddstreet) wrote :
Changed in isc-dhcp (Ubuntu):
assignee: nobody → Dan Streetman (ddstreet)
importance: Undecided → Medium
status: New → In Progress
Dan Streetman (ddstreet) wrote :

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

Dan Streetman (ddstreet) wrote :
Dan Streetman (ddstreet) wrote :

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

tags: added: patch
Seth Arnold (seth-arnold) wrote :

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

Dan Streetman (ddstreet) wrote :

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

Changed in isc-dhcp (Ubuntu Precise):
importance: Undecided → Medium
Changed in isc-dhcp (Ubuntu Trusty):
importance: Undecided → Medium
Changed in isc-dhcp (Ubuntu Xenial):
importance: Undecided → Medium
Changed in isc-dhcp (Debian):
status: Unknown → Fix Released
Martin Pitt (pitti) wrote :

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.

Changed in isc-dhcp (Ubuntu Yakkety):
status: In Progress → Fix Committed
Changed in isc-dhcp (Ubuntu Precise):
status: New → In Progress
Changed in isc-dhcp (Ubuntu Trusty):
status: New → In Progress
Changed in isc-dhcp (Ubuntu Xenial):
status: New → In Progress
Martin Pitt (pitti) wrote :

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!

Changed in isc-dhcp (Ubuntu Xenial):
status: In Progress → Fix Committed
tags: added: verification-needed
Dan Streetman (ddstreet) wrote :

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.

tags: added: verification-done-xenial
removed: verification-needed
Dan Streetman (ddstreet) wrote :

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.

tags: added: verification-done-yakkety
Chris J Arges (arges) wrote :

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!

Changed in isc-dhcp (Ubuntu Trusty):
status: In Progress → Fix Committed
tags: added: verification-needed
Changed in isc-dhcp (Ubuntu Precise):
status: In Progress → Fix Committed
Chris J Arges (arges) wrote :

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!

Brian Murray (brian-murray) wrote :

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

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

Dan Streetman (ddstreet) wrote :

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'

Dan Streetman (ddstreet) wrote :

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.

tags: added: verification-done-precise
Dan Streetman (ddstreet) wrote :

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.

tags: added: verification-done-trusty
removed: verification-needed
Dan Streetman (ddstreet) wrote :
Changed in network-manager (Ubuntu Precise):
status: New → Invalid
Dan Streetman (ddstreet) wrote :
Dan Streetman (ddstreet) wrote :
Dan Streetman (ddstreet) wrote :

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.

Chris J Arges (arges) wrote :

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

Dan Streetman (ddstreet) wrote :

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

Dan Streetman (ddstreet) wrote :

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: updated
description: updated
Martin Pitt (pitti) wrote :
Changed in network-manager (Ubuntu Yakkety):
assignee: nobody → Martin Pitt (pitti)
importance: Undecided → Medium
status: New → Fix Committed
Changed in network-manager (Ubuntu Xenial):
status: New → Triaged
Changed in network-manager (Ubuntu Trusty):
status: New → Triaged
Dan Streetman (ddstreet) wrote :

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.

Dan Streetman (ddstreet) wrote :

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

description: updated
Launchpad Janitor (janitor) wrote :

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

Changed in isc-dhcp (Ubuntu Precise):
status: Fix Committed → Fix Released

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.

Launchpad Janitor (janitor) wrote :

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

Changed in isc-dhcp (Ubuntu Trusty):
status: Fix Committed → Fix Released
Launchpad Janitor (janitor) wrote :

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

Changed in isc-dhcp (Ubuntu Xenial):
status: Fix Committed → Fix Released
Martin Pitt (pitti) wrote :

Cherry-picked into xenial branch.

Changed in network-manager (Ubuntu Xenial):
status: Triaged → Fix Committed

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
Martin Pitt (pitti) wrote :

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

tags: added: verification-done
removed: verification-done-precise verification-done-trusty verification-done-xenial verification-done-yakkety verification-needed
Changed in network-manager (Ubuntu Xenial):
importance: Undecided → Medium
Changed in network-manager (Ubuntu Trusty):
importance: Undecided → Medium
Launchpad Janitor (janitor) wrote :

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

Changed in network-manager (Ubuntu Yakkety):
status: Fix Committed → Fix Released
Launchpad Janitor (janitor) wrote :

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

Changed in isc-dhcp (Ubuntu Yakkety):
status: Fix Committed → Fix Released
LaMont Jones (lamont) wrote :

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

LaMont Jones (lamont) wrote :

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

LaMont Jones (lamont) wrote :

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

Launchpad Janitor (janitor) wrote :

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

Changed in network-manager (Ubuntu Xenial):
status: Fix Committed → Fix Released
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Duplicates of this bug

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.