[141715] in North American Network Operators' Group
Re: The stupidity of trying to "fix" DHCPv6
daemon@ATHENA.MIT.EDU (Owen DeLong)
Fri Jun 10 13:35:50 2011
In-Reply-To: <CD39C09D-16F0-4BF5-AFFC-C802B59A581C@muada.com>
From: Owen DeLong <owen@delong.com>
Date: Fri, 10 Jun 2011 12:32:13 -0500
To: Iljitsch van Beijnum <iljitsch@muada.com>
Cc: "nanog@nanog.org" <nanog@nanog.org>
Errors-To: nanog-bounces+nanog.discuss=bloom-picayune.mit.edu@nanog.org
Sent from my iPad
On Jun 10, 2011, at 10:13, Iljitsch van Beijnum <iljitsch@muada.com> wrote:
> On 10 jun 2011, at 16:47, Leo Bicknell wrote:
>=20
>>> So we agree on the problem. Now the only thing we have to do is come up w=
ith a solution that everybody likes.
>=20
>> 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.
>=20
> Don't you realize that this doesn't solve anything?
>=20
Actually, it does. It doesn't solve the problem you choose to argue about be=
low. That problem is addressed by RA Guard. However, it does solve a differe=
nt problem.
Some administrators want DHCP to be a complete solution and do not want to u=
se RA at all, whether from a legitimate router or otherwise.
There are situations, for example, where the administrator does not want all=
hosts in a broadcast domain to receive the same set of prefixes and/or the s=
ame set of routers. This can be achieved by using different parameters based=
on the system identifier in the DHCP configuration. It cannot be achieved u=
sing RA.
> The whole point of stateless autoconfig and DHCP is to allow a host that a=
rrives without any prior knowledge about the network to be configured withou=
t human intervention so it can communicate over the network.
>=20
Sure, but...
> So we must assume a host with no prior configuration. All currently existi=
ng 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 serve=
r).
>=20
> So if you put such a host with an updated DHCPv6 implementation in a netwo=
rk with rogue RAs, they will autoconfigure addresses in the advertised prefi=
xes exactly the same as today. Like I said before: removing the correct info=
rmation from RAs does nothing to get rid of the incorrect information in RAs=
.
>=20
Eliminating rogue RAs is not the problem being described. That problem is so=
lved through RA-Guard. The problem being described is the desire to be able t=
o configure a host from zero to functionally on the internet using DHCP with=
out RAs. I think everyone understands that you don't want to do so. That's f=
ine. However, adding the functionality to DHCPv6 doesn't require you to use i=
t. Making it available for operators that want to use it is not a bad thing.=
> 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 pr=
oblem. However, that solution still has two issues:
>=20
> 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
>=20
In some situations, this fate (it's fate, not fait, btw) sharing is not desi=
red. In some situations,
the use of VRRP is a more useful alternative.
> So my suggestion is: learn gateway addresses from RAs as we do today, but i=
n addition create a DHCPv6 option that contains gateway addresses, and then w=
hen a gateway address is in the DHCPv6 list, it gets a higher priority.
>=20
That would be a fine partial solution. However, it is desirable (IMHO) to pr=
ovide for a more generic DHCPv6 option that allows one to convey routing inf=
ormation so that DHCPv6 could be used to convey a predetermined static routi=
ng table of arbitrary complexity.
(yes, this would usually be a single default route, but, there are circumsta=
nces where it is
desirable for a host to have additional static routes).
> 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. I=
f system administrators screw up and the DHCPv6 info doesn't match the actua=
l routers, everything still works except that there is no rogue RA protectio=
n.
>=20
> This should make everyone happy except those so set in their IPv4 ways tha=
t 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 RA=
s to function and won't go away anytime soon.
I think it's a fine solution as far as it goes and a good part of a complete=
solution. However,
documenting that a host which sees no RA should attempt DHCPv6 would also be=
a good thing, IMHO. As it currently stands, some hosts which are DHCPv6 cap=
able will not attempt to query DHCP until they receive an RA with the M bit s=
et.
Yes, there will be an issue with legacy IPv6 hosts needing to catch up with t=
he protocol change for some time. However, this has been the case with many c=
hanges over time in IPv4 as well. Look at the transition from BootP to DHCP.=
Administrators are actually capable of adapting to or in some cases influen=
cing the level of required hardware/software performance of things that conn=
ect to their network if given the tools to do so.
Owen
