The stupidity of trying to "fix" DHCPv6
Iljitsch van Beijnum
iljitsch at muada.com
Fri Jun 10 11:03:14 UTC 2011
On 10 jun 2011, at 12:40, Tim Chown wrote:
>> But it's stupid to want to change DHCPv6 just now the last major OS is about to start supporting it. That continues the current situation where anyone who isn't happy with autoconfig-only can't make a configuration that works will all major OSes.
> Well, remember that, from Google's estimate, only 0.3% of the access networks are IPv6 capable, so there's still 99.7% to deploy.
There's deployment of code and deployment of configuration. The former is in good shape now, so better not tinker with it unnecessarily. It's also not very useful to count the 80% of the internet that consists of home users behind the cheapest home gateway running with the default settings the same way as we count the other 20% who actually have an opinion on the matter.
> I don't buy that a transition from RA+DHCP to DHCP-only is particularly complex though. Turn off the RAs and let DHCP do it's (extra) things.
Well, but if you turn off RAs while there are still systems that can't understand a new DHCPv6 router address option, then those systems have no idea where the routers are so they don't work.
> Standing back a little, I can see an argument that IPv6 would be an easier 'sell' if there were two modes of operation, one with only RAs, and one with only DHCPv6.
The trouble is that having the correct router NOT send RAs buys you very little: in theory you can now skip coordination between different departments if the DHCPv6 and router configs are handled by different people. In practice, you need to coordinate regardless because the routers need to know where to send the packets so they need to have the prefixes that the DHCPv6 servers assign from configured on their interfaces.
What you really want is for the hosts to ignore RAs sent by incorrect routers. This means turning off autoconfig on the hosts, which seems, at the very least, an uphill struggle unless we're talking about places with hosts bolted to the floor so the configuration can be tied to a specific network. And in that case you can do tons of other stuff, such as SEND or simply statically configuring everything.
Lest anyone accuse me of raining on their parade: I think very workable compromise would be to have a router preference option in DHCPv6. This way, routers still advertise themselves, but if there are multiple routers, the DHCPv6 info is the tie breaker so rogue RAs are avoided when this option is understood. But doing this doesn't impose difficulties on hosts that don't implement the new option.
More information about the NANOG