nanog mailing list archives
Re: quietly....
From: Mark Andrews <marka () isc org>
Date: Thu, 03 Feb 2011 09:04:33 +1100
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:On 2 feb 2011, at 14:10, Owen DeLong wrote: =20I didn't say they were necessarily good routers.=20No, you said the router always knows better than the DHCP server. =This is an example of a common case whereit 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 = these packets from fake routers in the switches. So ask your switch = vendor for that feature in IPv6.=20Turns 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?=20Turns 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.=20This 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. =20Then 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.)=20I 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:=20We 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
Current thread:
- Re: quietly...., (continued)
- Re: quietly.... sthaug (Feb 02)
- RE: quietly.... Frank Bulk (Feb 13)
- Re: quietly.... Iljitsch van Beijnum (Feb 15)
- Re: quietly.... David Israel (Feb 15)
- Re: quietly.... Jack Bates (Feb 15)
- Re: quietly.... Michael Dillon (Feb 15)
- Re: quietly.... Jay Ashworth (Feb 15)
- Re: quietly.... Lamar Owen (Feb 18)
- Re: quietly.... Valdis . Kletnieks (Feb 15)
- Re: quietly.... Jack Bates (Feb 15)
- Re: quietly.... Mark Andrews (Feb 02)
- Re: quietly.... Ricky Beam (Feb 02)
- Re: quietly.... Lamar Owen (Feb 02)
- Re: quietly.... Tony Finch (Feb 02)
- Re: quietly.... Mark Andrews (Feb 02)
- Re: quietly.... Nick Hilliard (Feb 02)
- Re: quietly.... Randy Bush (Feb 02)
- Re: quietly.... Tony Finch (Feb 02)
- Re: quietly.... Jack Bates (Feb 02)
- Re: quietly.... Owen DeLong (Feb 02)
- Re: quietly.... Mark Smith (Feb 02)