[Bug 1609898] Re: dhclient incorrectly assumes a /64 ipv6 prefix

[Dan Streetman]

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

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

Title:
  dhclient incorrectly assumes a /64 ipv6 prefix

Status in isc-dhcp package in Ubuntu:
  In Progress
Status in isc-dhcp source package in Precise:
  New
Status in isc-dhcp source package in Trusty:
  New
Status in isc-dhcp source package in Xenial:
  New
Status in isc-dhcp source package in Yakkety:
  In Progress

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]

  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

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