The stupidity of trying to "fix" DHCPv6

Fri Jun 10 15:13:09 UTC 2011

On 10 jun 2011, at 16:47, Leo Bicknell wrote:

>> So we agree on the problem. Now the only thing we have to do is come up with a solution that everybody likes.

> in DHCPv6 it was decided to not implment a field for the
> default gateway or subnet mask, under the logic that the former was
> learned via RA's, and the latter was always a /64.  While it's not
> quite as trivial as adding those two fields, it's not that much
> more complex.  The right behavior for a host that comes up and sees
> no RA's needs to be documented.

Don't you realize that this doesn't solve anything?

The whole point of stateless autoconfig and DHCP is to allow a host that arrives without any prior knowledge about the network to be configured without human intervention so it can communicate over the network.

So we must assume a host with no prior configuration. All currently existing IPv6 hosts that I'm aware of have stateless autoconfig enabled by default (save for some *X distros that assume the system will be some kind of server).

So if you put such a host with an updated DHCPv6 implementation in a network with rogue RAs, they will autoconfigure addresses in the advertised prefixes exactly the same as today. Like I said before: removing the correct information from RAs does nothing to get rid of the incorrect information in RAs.

Now you could argue that the DHCPv6-supplied gateway addresses should have higher priority than the ones learned from RAs. At least that solves the problem. However, that solution still has two issues:

1. No longer the fait sharing that comes from RA-learned gateway addresses
2. Old and new hosts may use different gateways on the same network

So my suggestion is: learn gateway addresses from RAs as we do today, but in addition create a DHCPv6 option that contains gateway addresses, and then when a gateway address is in the DHCPv6 list, it gets a higher priority.

This way, if there are no rogue RAs the behavior is the same for unupdated and updated hosts. If there are rogue RAs, the updated hosts ignore them. If system administrators screw up and the DHCPv6 info doesn't match the actual routers, everything still works except that there is no rogue RA protection.

This should make everyone happy except those so set in their IPv4 ways that they insist on removing RAs. Which is not only a bad idea, but an exercise in futility because of the large number of "legacy IPv6" hosts that need RAs to function and won't go away anytime soon.