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.
