Note that dhclient does not itself configures the interface but instead
calls the shellscript /sbin/dhclient-script to do the work. So a quick
workaround is to patch that script to use a fixed netmask of /128
(patch attached).

The real fix is to hand a fixed /128 netmask to the dhclient-script from
the daemon. This patches C-code in dhclient (patch attached).

Note that the dhcpv6 protocol doesn't have an option for a netmask. So
it is always /128 and routing is left to icmpv6 router advertisements.

That also means that the option "accept_ra" of the dhcp method for the
INET6 address family in /etc/network/interfaces (see interfaces(5) man
page) probably should be on by default or completely removed. In
addition maybe a fixed netmask should be configurable (see excerpts from
RFC5942 below).

Just some more facts regarding this issue:
RFC 5942 is very clear about a DHCP client "inventing" a prefix:

RFC5942, p.7 under "Host Rules":
"""
   1.  The assignment of an IPv6 address -- whether through IPv6
       stateless address autoconfiguration [RFC4862], DHCPv6 [RFC3315],
       or manual configuration -- MUST NOT implicitly cause a prefix
       derived from that address to be treated as on-link and added to
       the Prefix List.  ...
"""

and on p.8 under the heading "Observed Incorrect Implementation Behavior":
"""
   ...  An address
   could be acquired through the DHCPv6 identity association for non-
   temporary addresses (IA_NA) option from [RFC3315] (which does not
   include a prefix length), or through manual configuration (if no
   prefix length is specified).  The host incorrectly assumes an
   invented prefix is on-link.  This invented prefix typically is a /64
   that was written by the developer of the operating system network
   module API to any IPv6 application as a "default" prefix length when
   a length isn't specified...
"""

I sincerely hope this gets fixed in the next release of dhcpd. Note that
I've also filed an upstream report with issue number #35178 (before I
knew about this debian report) and I'm surprised the currently scheduled
4.3.0a1 release doesn't yet have the fix.

Ralf
-- 
Ralf Schlatterbeck             email: r...@zoo.priv.at
--- /sbin/dhclient-script.orig	2013-05-27 23:00:32.000000000 +0200
+++ /sbin/dhclient-script	2014-01-10 17:08:13.000000000 +0100
@@ -344,9 +344,9 @@
         ;;
 
     BOUND6|RENEW6|REBIND6)
-        if [ "${new_ip6_address}" ] && [ "${new_ip6_prefixlen}" ]; then
+        if [ "${new_ip6_address}" ]; then
             # set leased IP
-            ip -6 addr add ${new_ip6_address}/${new_ip6_prefixlen} \
+            ip -6 addr add ${new_ip6_address}/128 \
                 dev ${interface} scope global
         fi
 
--- client/dhc6.c.orig	2014-01-14 13:18:41.000000000 +0100
+++ client/dhc6.c	2014-01-14 13:19:06.000000000 +0100
@@ -3841,11 +3841,8 @@
 				      piaddr(addr->address),
 				      (unsigned) addr->plen);
 		} else {
-			/* Current practice is that all subnets are /64's, but
-			 * some suspect this may not be permanent.
-			 */
 			client_envadd(client, prefix, "ip6_prefixlen",
-				      "%d", 64);
+				      "%d", 128);
 			client_envadd(client, prefix, "ip6_address",
 				      "%s", piaddr(addr->address));
 		}

Reply via email to