Re: The stupidity of trying to "fix" DHCPv6

[Iljitsch van Beijnum <iljitsch () muada com>]

On 11 jun 2011, at 4:03, Owen DeLong wrote:

> You can call that bad network design if you want, but, there are real world requirements and scenarios where that has 
> to happen for a variety of reasons.

> Those networks have working configurations in DHCPv4 and no ability to move to IPv6
> until this is solved.

Yeah, and they needed provider independent space to be able to move to IPv6, too. Didn't happen to a measurable degree 
either.

There is no point in repeating all the IPv4 mistakes with IPv6, if that's what you want, stay on IPv4.

Just because someone wants it doesn't make something a good idea. Especially because time and time again people take 
some underlying need, translate that in some technical "need" that is an extremely bad way to address that underlying 
need. So just giving people what they ask for invariably leads to sub-par results. Your doctor doesn't just give you 
the medicine you ask for either.

Yes, I know this carries an implicit accusation of stupidity. I can live with that, and I'm not impressed if people are 
offended. (You get used to that surprisingly quickly.)

> > I'm all for improvements, but only if they can be made without fragmenting the installed base and perpetuating the 
> > situation we are finally leaving behind where there is no agreed upon DHCPv6 behavior across different operating 
> > systems.

> I see no reason that additional DHCPv6 options would have to fragment the installed
> base or perpetuate the lack of agreed upon DHCPv6 behavior.

Risks are in the eye of the beholder. I'm sure the financial sector didn't see any problems coming their way in 2007 
either. I'm sure I sometimes see problems that never materialize. Still better safe than sorry. Especially because this 
is all nonsense in the margin that we can all very easily live without. What are we talking about here? One RA message 
every 200 seconds? Is that so bad?

> > People who don't like this should blame their younger selves who failed to show up at the IETF ten years ago to get 
> > this done while DHCPv6 was still clean slate.

> There were a lot of people who tried to "show up" at the IETF 10 years ago and talk
> about this stuff from an operational perspective. They were basically told that operators
> don't know what they want and they should shut up and go away and let real men
> do the work.

So what has changed now? Is it helpful to take that advice for 10 years and THEN revisit the issue?

BTW, I first went to the IETF 10 years ago and didn't encounter such an attitude (although many others I didn't like).

> Personally, I'd rather not have administrators rejecting IPv6 and it seems to me that adding routing information 
> options
> to DHCPv6 is a light-weight action that is already possible within the existing protocol specification (just need to 
> assign
> option numbers and attribute/value formats) and makes IPv6 a whole lot more palatable to a rather large number of
> administrators.

Assuming facts not in evidence.

There is a small group of people that is never happy. Give them more, they remain unhappy. The adagium "don't feed the 
trolls" applies to them.

> > It is a bad thing because of the installed base fragmentation and the reduced robustness resulting from using such 
> > an option. As such, my life will be worse when this is done so I'm against doing this.

> How does this make your life worse? If it's not your network, why do you care?

Because it allows one more configuration that works for some stuff and not other stuff. I get around enough that I'll 
encounter such a configuration at some point.

> As to fragmentation of the installed base, I don't see how adding a couple of options to DHCPv6 creates 
> fragmentation. It adds functionality that
> people can use.

No, it add functionality that allows administrators to remove functionality but that only works if there are no systems 
that don't have the first functionality and hence can do without the second functionality. It'll take years for 
operating systems to catch up, and all of that just to fix something that isn't broken in the first place.

(Remember, not talking about rogue RAs!)

> Because in some cases, the HOST administrator is not the NETWORK administrator and cannot
> necessarily control how the administrator of a given router does things. In some cases, this means
> that the HOST administrator wants his hosts to act in a manner that is not consistent with what
> the administrator of certain network devices wants to tell other hosts on the same link to do.

Again, why NOW?

We are just getting to the point where DHCPv6 can actually be used. Quit while you're ahead.

And fixing protocols to make them work even in the face of explicit misconfiguration is a road that leads nowhere 
quickly.

> > A really bad situation would be an IPv6-only network where tons of hosts keep broadcasting DHCPv6 multicasts. This 
> > can easily clog up wifi bandwidth, as multicasts are sent at very low bitrates because they lack acknowledgments.

> Shouldn't happen. First, if some form of back-off isn't built into DHCPv6, that should be fixed.

Right, first we break, then we fix. Job security all around!

> Second, if your network doesn't have any RAs and your DHCP server isn't answering, it
> really doesn't matter that it gets clogged up because nothing is working anyway.

Oh right, IPv4 only networks aren't considered to be "working" these days.