[136308] in North American Network Operators' Group
Re: quietly....
daemon@ATHENA.MIT.EDU (Iljitsch van Beijnum)
Wed Feb 2 09:19:39 2011
From: Iljitsch van Beijnum <iljitsch@muada.com>
In-Reply-To: <FD962FB5-3D1D-48C4-9D5B-73D81132606B@delong.com>
Date: Wed, 2 Feb 2011 15:17:14 +0100
To: Owen DeLong <owen@delong.com>
Cc: NANOG list <nanog@nanog.org>
Errors-To: nanog-bounces+nanog.discuss=bloom-picayune.mit.edu@nanog.org
On 2 feb 2011, at 14:10, Owen DeLong wrote:
>> I didn't say they were necessarily good routers.
> No, you said the router always knows better than the DHCP server. This =
is an example of a common case where
> it does not.
If someone turns their box into a router they can also turn it into a =
DHCP server. This is what happens with IPv4. The solution is to filter =
these packets from fake routers in the switches. So ask your switch =
vendor for that feature in IPv6.
> It really isn't. If the DHCP server on a subnet could override the =
rogue routers RA messages by policy, then, it would actually make it =
fairly trivial to address this issue.
And who overrides the rogue DHCPv6 messages? Or is it turtles all the =
way down?
>> But there's so much wrong with DHCPv6 that trying to fix it is pretty =
much useless, we need to abandon DHCP and start from scratch. Good thing =
IPv6 works just fine without DHCPv6.
> This is a clear example of the myopia in the IETF that has operators =
so frustrated.
I can assure you that I'm quite alone within the IETF with that view.
I'm not talking about the interaction between DHCPv6 and RAs here, just =
about how bad DHCPv6 is on its own terms. For instance, there's no =
client identifier or using MAC addresses to identify clients, this is =
now done with a DUID. Unfortunately, administrators have no way of =
knowing what DUID a given client is going to use so having a DHCPv6 =
server set up with information tailored to a specific client is really =
hard. There's also stateful and stateless DHCPv6, but it's the client =
that has to choose between them, while the server knows whether it's =
going to return stateful or stateless information. There's no prefix =
length in DHCPv6, so this needs to be learned from RAs. (Although it can =
be argued that because routers need to know this info anyway, having the =
prefix length there doesn't buy you anything.)
The problem with DHCP in general is that there is a continuous influx of =
new options but they all need to be encoded into a binary format inside =
a small packet. This info should be in an XML file on a HTTP server =
instead, rather than be overloaded into the connectivity bootstrapping. =
The problem with RA / DHCP is that RAs were built with some vague notion =
of what DHCP would do some day and then when DHCPv6 was developed half a =
decade later the evolving ideas didn't fit with the shape of the hole =
left in RAs anymore but that problem wasn't addressed at this time. =
Fixing that now (hopefully fixing it well, not doing stupid things like =
making DHCPv6 an IPv4 DHCP clone with all the IPv4 DHCP problems that we =
all suffer every day) means that we'll end up with three types of =
systems:
- no DHCPv6
- legacy DHCPv6
- new DHCPv6
Good luck trying to come up with a combination of RA and DHCP settings =
that make all three work well. Even without new DHCPv6, there's already =
12 ways to set up RAs and DHCP and only a few combinations produce =
useful results.=
