[141896] in North American Network Operators' Group
Re: The stupidity of trying to "fix" DHCPv6
daemon@ATHENA.MIT.EDU (Owen DeLong)
Mon Jun 13 19:30:59 2011
From: Owen DeLong <owen@delong.com>
In-Reply-To: <97623D46-87FA-4C9A-8AF8-A3023A2FE38F@muada.com>
Date: Mon, 13 Jun 2011 16:28:33 -0700
To: Iljitsch van Beijnum <iljitsch@muada.com>
Cc: NANOG list <nanog@nanog.org>
Errors-To: nanog-bounces+nanog.discuss=bloom-picayune.mit.edu@nanog.org
On Jun 12, 2011, at 4:01 AM, Iljitsch van Beijnum wrote:
> On 11 jun 2011, at 17:05, Owen DeLong wrote:
>=20
>>> Your doctor doesn't just give you the medicine you ask for either.
>=20
>> 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.
>=20
> It's true that the patient also knows some stuff here.
>=20
> There's a lot of bitching here on the NANOG list about how operators =
get no respect at the IETF. But that's a two-way street. There's also =
tons of people in operations who have no appreciation to what the IETF =
brings to the table.
>=20
> Operators tend to see issues in isolation, or at the very least only =
see the connections that are relevant to their environment. The IETF has =
to take into consideration all possible environments. Sometimes things =
that seem a clear win in a constrained environment could be a disaster =
if they were used all over the internet.
>=20
Sure, but, doing that for something that is only locally significant, =
such as RA/DHCP means that you should implement a
true superset of the operational requirements so that operators can =
choose the tools that best fit their environment, rather
than a rag tag set of incomplete tools that require operators to =
implement ALL of them in order to form a single complete
solution and offer no flexibility on which set of solutions is chosen.
Guess which one more accurately describes the current state of RA/DHCPv6 =
from an operator perspective?
> You know what they say: a doctor who treats himself has a fool for a =
patient.
>=20
Yes, but, a doctor who accepts the word of another doctor without doing =
his own analysis is unlikely to be
a patient for very long. Death has a way of terminating doctor patient =
relationships.
>> Yes, I'm well familiar with your level of arrogance.
>=20
> Yes, I know I stick out like a sore thumb in these humble parts.
>=20
OK... Point taken. However...
>>> 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?
>=20
> Judge for yourself:
>=20
> =
http://www.muada.com/drafts/draft-van-beijnum-multi6-isp-int-aggr-01.txt
>=20
I'm sure that got reasonably well shouted down, but, it's close enough =
to a few pieces of IETF dogma
that I suspect it probably didn't result in "fool, go home" style =
comments from too many places.
> Let me wrap up this discussion with the following:
>=20
> IPv6 address configuration is a house of cards. Touch it and it all =
comes crashing down. DHCPv6 has a number of significant flaws, and the =
interaction between DHCPv6 and router advertisements only barely makes =
sense. All of this makes it seem like a good idea to tweak stuff to make =
it better, but in reality that's a mistake: it just means more =
opportunities for things to fail. What we need is to rethink the host =
configuration problem from the ground up, starting at the host and what =
it should do when it sees its interface come up.
>=20
I'm fine with that latter idea and it may well yield a better solution. =
However, in the operational world, we cannot wait for that and what we =
have today is not
sufficiently adequate to meet real world requirements as they exist =
today. As such, we MUST modify what we have today in ways that extend it =
to have the
capabilities that are required. I understand you find this distasteful. =
I even understand some of your reasons. I even agree with some of them.
However, we do not have the option if we are to make IPv6 deployable in =
the enterprise of ignoring these requirements. These aren't situations =
that
have existing workarounds and the administrators are simply opposed to =
doing things differently. These are situations where the fundamental
operation of the network cannot be accomplished under IPv6 within the =
current organizational requirements.
Asking organizations to restructure their networks is one thing. Asking =
them to also reorganize their organizational politics around that =
network
restructuring is, well, "recipe for fail" seems like an understatement.
> One model that seems attractive here is the on the iPhone uses, where =
you can modify the IP configuration on a per-wifi network basis. If we =
can apply this kind of logic to wired networks, too, then suddenly we're =
no longer limited to having one monolithic set of client side behavior =
that must always be followed, but we can be much more flexible.
The real goal should be to have a way (or ways) for hosts to operate =
across a wide variety of environments with zeroconf. Having to build =
profiles for different
networks is a great workaround for failures in that effort, but, it is =
not what I would call a good solution to the problem in general.
Owen
