nanog mailing list archives

Re: The stupidity of trying to "fix" DHCPv6


From: Iljitsch van Beijnum <iljitsch () muada com>
Date: Fri, 10 Jun 2011 17:13:09 +0200

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.

Current thread: