Re: quietly....

[Mark Andrews <marka () isc org>]

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:
> > =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: marka () isc org