[141776] in North American Network Operators' Group
Re: The stupidity of trying to "fix" DHCPv6
daemon@ATHENA.MIT.EDU (Iljitsch van Beijnum)
Sat Jun 11 10:22:33 2011
From: Iljitsch van Beijnum <iljitsch@muada.com>
In-Reply-To: <205054C9-A2C7-41D7-8BE9-4D032399BD3C@delong.com>
Date: Sat, 11 Jun 2011 16:21:12 +0200
To: Owen DeLong <owen@delong.com>
Cc: "nanog@nanog.org" <nanog@nanog.org>
Errors-To: nanog-bounces+nanog.discuss=bloom-picayune.mit.edu@nanog.org
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.=
