[Dnsmasq-discuss] Cannot assign IPv6 address for /96 subnet

[Dan Williams]

On Sat, 2013-02-23 at 12:24 +0100, Joakim Langlet wrote:
> tis 2013-02-19 klockan 18:02 -0600 skrev Dan Williams:
> > On Tue, 2013-02-19 at 21:06 +0000, Simon Kelley wrote:
> > > So, I did some testing. I configured an server interface with 
> > > prefix-length 96, and configured dnsmasq with a dhcp-range and 96 prefix.
> > > 
> > > Using dhclient, I got a lease successfully.
> > > 
> > > The only problem is that dhclient configured the client's interface with 
> > > prefix-length 64.
> > > 
> > > I moment's thought shows that this is expected: there is nowhere in the 
> > > DHCPv6 messages for the prefix-length information to be passed to the 
> > > client. There _is_ a prefix-length field in router-advertisements. but 
> > > AFAIK, there's no way for the DHCPv6 client to use that information.
> > > 
> > > Of course if you're using RA for address-allocation, using SLAAC, the 
> > > prefix length has to be 64 anyway.
> > 
> > We had this discussion for NM a long time back.  dhclient hardcodes the
> > prefix to /64 because there's no agreement in the standards on prefixes,
> > and last I knew, DHCPv6 didn't even have a prefix/netmask option.  It
> > turns out that's kinda pointless anyway, so we ignore that /64 from
> > dhclient and hardcode it to /128 or something like that.
> > 
> > But the point is, until standards get changed and dhclient updates to
> > use them, you're stuck wtih a /64 or whatever you choose to override
> > that as.
> > 
> > Dan
> > 
> > 
> > _______________________________________________
> > Dnsmasq-discuss mailing list
> > Dnsmasq-discuss at lists.thekelleys.org.uk
> > http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
> 
> Hi Dan, Simon and all others,
> 
> I have had similar issues with /96 prefix and dhclient in connection to
> my Raspberry Pi based dual-stack router.
> 
> Initially, I hoped to use SLAAC for some client computers but no
> implementation use the "room" in the standard.
> 
> In RFC2462 the following is stated in section 5.5.3 (RA processing
> bullits)
> 
> 
>     d) If the prefix advertised does not match the prefix of an address
>        already in the list, and the Valid Lifetime is not 0, form an
>        address (and add it to the list) by combining the advertised
>        prefix with the link's interface identifier as follows:
> 
>    |            128 - N bits               |       N bits           |
>    +---------------------------------------+------------------------+
>    |            link prefix                |  interface identifier  |
>    +----------------------------------------------------------------+
> 
> 
>        If the sum of the prefix length and interface identifier length
>        does not equal 128 bits, the Prefix Information option MUST be
>        ignored.  An implementation MAY wish to log a system management
>        error in this case. It is the responsibility of the system
>        administrator to insure that the lengths of prefixes contained in
>        Router Advertisements are consistent with the length of interface
>        identifiers for that link type. Note that interface identifiers
>        will typically be 64-bits long and based on EUI-64 identifiers as
>        described in [ADDR-ARCH].
> 
>        If an address is formed successfully, the host adds it to the
>        list of addresses assigned to the interface, initializing its
>        preferred and valid lifetime values from the Prefix Information
>        option.
> 
> There is nothing here that prevents using a longer prefix length
> than /64. It only states that it *typically* be /64 and use EUI-64.

For RA, yes.  Any prefix is allowed there.  But DHCPv6 is different.  I
can't recall all the details of why we decided to ignore dhclient's
prefix option for NM and lock it to /128, but Pavel Simerda does and I'm
cc-ing him on this message so he can weigh in on this.

Dan

> An implementation that fulfills the ambition to be "policy-free" and as
> useful as possible, could in my view be more flexible and "creative".  
> 
> If the prefix-length in the RA is greater than /64, one could start with
> shaving of the inserted "midbits" of the EUI-64 identifier. If that is
> not enough, shave off bits from the left. The risk of dual address
> allocation is still *very* small and the DAD mechanism could be used as
> well.
> 
> This would allow SLAAC on prefixes longer than /64 without actually
> *breaking* RFC2462 rules (in my view). An additional bit in /proc could
> enable/disable the extension (default off). 
> 
> In combination with DAD, it should be pretty safe. Small networks, such
> as my 6RD-allocation, could use this feature. Larger networks will have
> larger allocations (maybe /48) and would not enable this behavior.
> 
> As you have discussed, the DHCPv6 lacks a prefix option. As an
> intermediate solution to this in the clients, it would be nice if there
> was an option to "trust the prefix of the RAs". Then, a "correct" prefix
> (in most cases) would be allocated. If the last received prefix from an
> RA was always "saved" and accessible from /proc, that could be used if
> its validity (receive time related) could be verified.
> 
> It should noted that the use of a fixed /64 prefix really breaks routing
> in a site where a /64 allocation is subdivided into several networks
> with longer prefixes.
> 
> If no RA was received, in spite of router solicitations, clients maybe
> should prefer to set a /128 prefix (in my view!). This would allow a
> correctly implemented IPv6 router to issue a "redirect" if the actual
> destination was not actually outside of the "local-link". At such
> "redirects", the used prefix could maybe be updated by deduction.
> 
> There could also be some kind of state associated with a route, deeming
> it as weakly defined. If an RA is later received, the weakly defined
> routes that matches the RA prefix could be given a new prefix (/128 -->
> prefix in RA). A bit wild...I know!
> 
> I think it would solve a lot of problems in "small network" if SLAAC
> allowed longer prefixes and DHCPv6 clients would be allowed to trust RA
> prefixes.
> 
> Best Regards,
> Joakim Langlet
> 
>