[141702] in North American Network Operators' Group
Re: The stupidity of trying to "fix" DHCPv6
daemon@ATHENA.MIT.EDU (Iljitsch van Beijnum)
Fri Jun 10 11:17:30 2011
From: Iljitsch van Beijnum <iljitsch@muada.com>
In-Reply-To: <20110610144751.GA25027@ussenterprise.ufp.org>
Date: Fri, 10 Jun 2011 17:13:09 +0200
To: Leo Bicknell <bicknell@ufp.org>
Cc: nanog@nanog.org
Errors-To: nanog-bounces+nanog.discuss=bloom-picayune.mit.edu@nanog.org
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.=
