In message <9271a508-9b5e-4919-ac14-487b8c8e8...@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: > >=20 > >>> 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 = > 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: ma...@isc.org
