The stupidity of trying to "fix" DHCPv6
owen at delong.com
Sat Jun 11 15:05:01 UTC 2011
On Jun 11, 2011, at 7:21 AM, Iljitsch van Beijnum wrote:
> 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.
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.
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.
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.)
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.
>> 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?
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.
>> 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?
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).
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
> Assuming facts not in evidence.
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.
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.
>> 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.
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.
> 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.
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!)
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.
> Again, why NOW?
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.
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.
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.
>> 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!
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.
> 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
I'm not sure I see the relevance of your statement there.
More information about the NANOG