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

[Joakim Langlet]

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.

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