[141779] in North American Network Operators' Group
Re: The stupidity of trying to "fix" DHCPv6
daemon@ATHENA.MIT.EDU (Owen DeLong)
Sat Jun 11 11:06:22 2011
From: Owen DeLong <owen@delong.com>
In-Reply-To: <1492E17B-1744-47CA-9A2C-8CC9190DCA94@muada.com>
Date: Sat, 11 Jun 2011 08:05:01 -0700
To: Iljitsch van Beijnum <iljitsch@muada.com>
Cc: "nanog@nanog.org" <nanog@nanog.org>
Errors-To: nanog-bounces+nanog.discuss=bloom-picayune.mit.edu@nanog.org
On Jun 11, 2011, at 7:21 AM, Iljitsch van Beijnum wrote:
> On 11 jun 2011, at 4:03, Owen DeLong wrote:
>=20
>> 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.
>=20
>> Those networks have working configurations in DHCPv4 and no ability =
to move to IPv6
>> until this is solved.
>=20
> Yeah, and they needed provider independent space to be able to move to =
IPv6, too. Didn't happen to a measurable degree either.
>=20
IPv6 PI has actually proven to be good and did result in a measurable =
increase in the IPv6 adoption rate
among end-sites. Unfortunately, it's still not as well known as would be =
ideal. I still get a lot of enterprise
administrators saying to me "How can I move to IPv6, I can't get PI =
space." Seems a lot of administrators
don't pay close enough attention to know that policies changed several =
years ago.
> There is no point in repeating all the IPv4 mistakes with IPv6, if =
that's what you want, stay on IPv4.
>=20
Agreed... However, that's not what this is.
> 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.
>=20
True. However, since a lot of people need it, it doesn't hurt anyone who =
isn't using it, and is relatively easy to implement, it is a good idea.
I respect it's not your chosen solution. Your chosen solution is not the =
solution others think is the best. In fact, many people think that your
chosen solution is an extremely bad way to address that underlying need. =
Giving people alternatives and letting them decide what is
best for their network invariably leads to results. If the network =
administrator doesn't like the results and has other options, then, he
is free to choose different options seeking better results. Failing to =
give the network administrator options invariably leads to sub-par
results which may only be considered optimal by someone who isn't even =
familiar with the particular situation in question.
As to my doctor and medicine, actually, my doctor knows that I have some =
medical background and we do discuss drug choices
openly. I don't ask for things that don't make sense and my doctor has =
generally either convinced me that there is a better choice
through an open discussion or has prescribed the drug I chose/requested.
You are not talking about a doctor/patient scenario here where the =
doctor is an expert and the people asking for this have no
medical training. Here, we are talking about requirements coming from =
network engineers that are every bit as skilled as you
are in the field and every bit as capable of making informed decisions =
about the correct solution for their environment.
The difference is that they are not trying to tell you that you can't =
have the solution you want, they're merely trying to also
have the ability to choose a different solution. Choice never leads to =
sub-par solutions. It invariably leads to the solution
most favored by the people making the choices.
> 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.)
>=20
Yes, I'm well familiar with your level of arrogance. I'm not impressed =
by that any more than you are impressed by people
being offended when you call them stupid.
>>> 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.
>=20
>> I see no reason that additional DHCPv6 options would have to fragment =
the installed
>> base or perpetuate the lack of agreed upon DHCPv6 behavior.
>=20
> 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?
>=20
You're still railing on the idea that the goal here is to eliminate the =
RA message. That's simply
not the case. The goal here is to deal with the fact that host =
administration is NOT the purview
of people who run routers and people who run hosts do NOT want the =
network guys
configuring their hosts.
This is about administrative boundaries and the ability for the correct =
group within a company
to have the correct policy controls over their pieces of the puzzle.
If they could make the hosts flat-out ignore the RA, they could (for the =
most part) care less
about the RA being there or not. The goal is to eliminate the ability of =
those whack-jobs
that run the network to dictate the fate of the host administration =
team.
(Yes, I realize that I just implicitly called you a whack-job, but, =
realize that I'm part of the
networking team, too, so, we're both whack-jobs in the eyes of the =
system administrators.
You get used to that surprisingly quickly as well.)
>>> 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.
>=20
>> 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.
>=20
> So what has changed now? Is it helpful to take that advice for 10 =
years and THEN revisit the issue?
>=20
Yes, because now the issue is more pressing and more important to more =
administrators.
10 years ago, it was a fight over something that might become relevant =
later. Today, it's
a fight over something that matters today or maybe tomorrow at the =
latest.
> BTW, I first went to the IETF 10 years ago and didn't encounter such =
an attitude (although many others I didn't like).
>=20
Good for you. Did you try proposing anything that was contrary to the =
current religion at the time or did you join
the ivory tower biggots in supporting solutions that work better in =
theory than in operational reality and embrace
their bold new failure to address major concerns (such as scalable =
routing) while focusing on irrelevant minutiae
such as 8+8 vs. GSE?
If you just went to drink the Kool-aid, I'm sure you didn't encounter =
that attitude. OTOH, if you told them you didn't
like their Kool-aid and proposed a new flavor, your results would =
probably have been closer to mine.
>> 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.
>=20
> Assuming facts not in evidence.
>=20
Not really. I talk to a lot of enterprise administrators in my job and =
this is a pretty universal issue.
> 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.
>=20
While that is true, I don't think it is an accurate portrayal of the =
situation in this case. For one thing, if you analyze
it carefully, you see that they aren't asking for more. They are merely =
asking for the functionality and capabilities
that they already have to be made available in what they are being told =
is their next protocol whether they like
it or not.
>>> 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.
>=20
>> How does this make your life worse? If it's not your network, why do =
you care?
>=20
> 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.
>=20
I have no sympathy for you here. If you choose to be a consultant, then, =
you knew the job was dangerous when you took it.
If it wasn't this, it would be something else. That's the nature of the =
job. If we consider the protocol to be set in stone, it will
never advance and you have taken a giant step backwards from the very =
things that made IPv4 successful. Look at the number
of serious changes that have happened to IPv4 since IPv6 was first =
published.
>> 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.
>=20
> 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.
>=20
Since the administrator knows his network, it's up to the administrator =
to make that determination. Obviously this
would not be a good solution for $RANDOM_COFFEESHOP_WIFI. OTOH, for an =
enterprise with a relatively
homogenous set of host requirements (and most enterprises do actually =
have this in order to reduce their
administrative costs), that's not an issue. It doesn't remove =
functionality. It provides the same functions (and
a few more) in a different manner. The fact that you don't like that =
particular manner is irrelevant to the
discussion, nobody is asking you to use it.
Remember, I'm not proposing that we just add default-route to DHCP. I'm =
proposing routing information.
This would include functionality that would allow multiple specific =
static routes to be defined, for example.
> (Remember, not talking about rogue RAs!)
>=20
Neither am I. We already agree that RA-Guard is the better solution to =
that problem.
>> 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.
>=20
> Again, why NOW?
>=20
Because NOW IPv6 is starting to become an operational discussion that =
matters to administrators
rather than a theoretical discussion that matters to a bunch of people =
in an ivory tower somewhere
where they hopefully can't do too much harm to the operational network.
> We are just getting to the point where DHCPv6 can actually be used. =
Quit while you're ahead.
>=20
The fact that this was such a battle is testament to the ivory-tower =
failure of the IETF and the
dysfunction of allowing decisions to be made without input from the =
operational community
who is generally too busy keeping the present working to spend a lot of =
time debating the
(presently) irrelevant minutiae of possible futures.
> And fixing protocols to make them work even in the face of explicit =
misconfiguration is a road that leads nowhere quickly.
>=20
Huh? That's not what anyone is discussing here.
>>> 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.
>=20
>> Shouldn't happen. First, if some form of back-off isn't built into =
DHCPv6, that should be fixed.
>=20
> Right, first we break, then we fix. Job security all around!
>=20
If DHCP doesn't back off, it's already broken. The fact that this =
breakage would only affect
networks with the M bit set presently where it would break more =
universally under my
proposal does not make it less broken.
>> 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.
>=20
> Oh right, IPv4 only networks aren't considered to be "working" these =
days.
IPv4 networks don't work if the DHCP server doesn't answer unless the =
network
is statically configured. IPv4 DHCP _DOES_ have a backoff built in to =
the protocol.
If your IPv6 network is statically configured, then it won't have a =
bunch of hosts
trying DHCPv6.
I'm not sure I see the relevance of your statement there.
Owen
