On Feb 2, 2011, at 6:17 AM, Iljitsch van Beijnum wrote:
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.
Turns out that this is A LOT less common and when it does happen, it's easier to find and eliminate.
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?
Turns out to be quite a bit easier to isolate and remove the rogue DHCP server. Also turns out that there isn't a single-checkbox way to accidentally create a DHCP server, unlike a rogue RA.
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.
Then you have had impressive success at blocking useful development for a lone individual.
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.)
I agree that there is much that needs to be improved in DHCPv6. The lack of a default router, however, is the broken part that causes the most difficulty in modern operations.
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:
We can agree to disagree about that. While it's true that there is a large number of options and the DHCP packet needs to remain relatively small, the reality is that no site uses all of them. They large number of options represents a superset of the differing needs of various sites. XML on HTTP is too much overhead for things a system needs to know at boot time to download its kernel. Operationally, DHCPv4 is just fine and is meeting the needs today. There's no reason we shouldn't have at least equivalent functionality in DHCPv6.
- 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.
Yes... It really would be better if both SLAAC and DHCPv6 provided complete solutions and the operator could pick the single solution that worked best for them. Unfortunately, instead of looking at how things are used in the real world, IETF pursued some sort of theoretical purity exercise and we have two half-protocols that can't possibly provide a complete solution in either one. SLAAC fails because you can't get information about DNS, NTP, or anything other than a list of prefixes and a router that MIGHT actually be able to default-route your packets. DHCP fails because you can't get a default router out of it. Owen