Re: quietly....

[Iljitsch van Beijnum <iljitsch () muada com>]

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.