In message <9271A508-9B5E-4919-AC14-487B8C8E8617@delong.com>, Owen DeLong write s:
On Feb 2, 2011, at 6:17 AM, Iljitsch van Beijnum wrote:
I didn't say they were necessarily good routers. =20 No, you said the router always knows better than the DHCP server. = This is an example of a common case where it does not. =20 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 =
On 2 feb 2011, at 14:10, Owen DeLong wrote: =20 these packets from fake routers in the switches. So ask your switch = vendor for that feature in IPv6. =20 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. =20 And who overrides the rogue DHCPv6 messages? Or is it turtles all the = way down? =20 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. =20 This is a clear example of the myopia in the IETF that has operators = so frustrated. =20 I can assure you that I'm quite alone within the IETF with that view. =20 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.) =20 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: =20 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 =20 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
They didn't fail. They were designed to complement each other. It just that somewhere along the way people forgot that. -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org