Re: IPv6 default routes / NM vs. kernel autoconfig vs DHCP6

[Tore Anderson <tore fud no>]

* Stuart D Gathman

> One situation that ought to work IMHO (although ~1/2 of IPv6 experts
> disagree) is that DHCP6 should work in concert with routes that are
> not /64.

Agreed. As it happens, NM recently gained support for such setups.

> For instance, RA provides a 2001:db8:1:2:3::1/80 default
> route,

The default route, by definition, is ::/0. Do you mean a on-link prefix
route?

Also, 2001:db8:1:2:3::1/80 isn't a prefix you'd normally see in a RA,
as the interface bits aren't all zeroes. Did you mean
2001:db8:1:2:3::/80?

> sets the M bit, and DHCP6 provides the address
> 2001:db8:1:2:3::1000.  NM should be able to set the default route

It's actually the kernel that will set the default route, as well as
any on-link prefix routes, in response to receiving an RA, not NM.
(However, NM will make a static copy of the default route set up by the
kernel.) This has worked just fine for many many years.

> *and* apply the /80 prefix length to the DHCP6 address.

Why?

> This could
> get non-trivial when there are multiple routes provided by RA.  NM
> must then find the route that matches the DHCP6 address to determine
> the correct prefix.

An address assigned by DHCPv6 IA_NA is just that, a single address.
DHCPv6 cannot provide a prefix length, or indeed any routes at all. The
implicit prefix length if an IA_NA assignment, therefore, is always
/128.

This is what was recently fixed in NM. Before it used to believe the
buggy ISC DHCPv6 client, which always explicitly advertised a false
prefix length of /64. Now NM hard-codes /128 instead. See
<http://cgit.freedesktop.org/NetworkManager/NetworkManager/commit/?id=eb460b70dad82d366d35fa5703c0e79a1389e4d1>.

> Note: the experts that disagree feel that all LANs should be /64
> always forever, and prefixes should only be used in routers.  I find
> it quite handy to be able to subnet the /64 provided by the ISP, and
> while I agree that ISPs should always forever allocate a minimum of
> /64 to end users, nevertheless endusers should be able to subnet that
> and still have workstations and devices work without manual
> configuration.

I think «the experts» generally have a more pragmatic view of the world
than that (there are exceptions, of course). Using prefix lengths other
than /64 is certainly not forbidden (see for example RFC 6164). What is
true, however, is that if you want to use SLAAC, you'll have to use a
/64, because that's the only prefix length for which an algorighm to
automatically generate your own interface bits is defined. For that
reason, *defaulting* to a /64 is sensible - especially in consumer-grade
home routers and similar. For the same reason, the absolutely minimum an
ISP should hand out to its subscribers, is a /64 - and in the RIPE NCC
service area, the IPv6 address allocation and assignment policy
explicitly forbids the assignment of smaller prefixes to end users.

-- 
Tore Anderson