[141745] in North American Network Operators' Group
Re: The stupidity of trying to "fix" DHCPv6
daemon@ATHENA.MIT.EDU (Owen DeLong)
Fri Jun 10 22:05:26 2011
From: Owen DeLong <owen@delong.com>
In-Reply-To: <AE120605-D8D0-42F1-AB85-CABF6A3D91F6@muada.com>
Date: Fri, 10 Jun 2011 19:03:46 -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 10, 2011, at 12:57 PM, Iljitsch van Beijnum wrote:
> On 10 jun 2011, at 18:06, Leo Bicknell wrote:
>=20
>> However, many networks are much more closed deployments. Enterprises
>> have not deployed IPv6 internally yet. Many will not deploy it for
>> another 3-5 years, chosing instead to use web proxies at the edge
>> that speak IPv4 (RFC1918) internally and IPv6 externally. They
>> often can enforce the software deployed on the boxes connected.
>=20
> If they have such tight control over their network and what attaches =
to it, then obviously rogue RAs can be clamped down upon in a variety of =
ways.
>=20
Rogue RA is not the problem this seeks to solve. Yes, it helps with that =
problem
also, but, I wouldn't be saying we need this if it was just rogue RA =
that people
are concerned about.
>> The fact that bad standards and software exist today should never be =
an
>> argument to not design and deploy better software. So what if it =
takes
>> until 2019, at least from 2019 to the end of IPv6 we'll have =
something
>> better.
>=20
> If only. Having third parties point to routers is less robust than =
having routers announce their own presence. In the telco world, there's =
a separation between the control and data channels, which has important =
security advantages. But the IETF has always favored fate sharing. It =
makes routing protocols more robust and it makes RA more robust than =
IPv4 DHCP.
>=20
So you say, but, the real world doesn't bear out your claim. For one =
thing, assuming that
routers on a link are intended to serve all machines on a link assumes =
facts not in evidence.
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.
This isn't about fate sharing vs. non-fate sharing. This is about giving =
administrators a
rich set of tools and allowing them to pick the ones that best fit their =
situation.
Nobody is trying to prevent you from using RA/SLAAC on your network. =
More power
to you. I use it on some of my networks too. However, I also deal with =
customers who
have situations that are not well served by it and they need DHCP with =
the ability
to provide different routing configurations to different hosts on the =
same link.
> 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. In fact, I =
think that
adding these options could allow for a set of rules that would be =
acceptable to all
and would allow administrators to make choices based on the needs of =
their
environments.
A host which receives a DHCPv6 option it doesn't understand is expected =
to ignore
that option. Administrators who count on DHCPv6 options that are newer =
than the
software/hardware on some of their hosts should expect those hosts to =
ignore the option.
This is easily documented.
> 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.
Perhaps we should have stood up stronger at the time, but, frankly, we =
had real
work to do that mattered to our users for the next 24 hours rather than =
a decade
later. As such, we had limited bandwidth to attempt to push our goals =
somewhere
where our "interference" was not welcome.
So, if you want to blame younger selves, blame the IETF younger selves =
and
the protocol zealots that shouted down the operator community and told =
us to
mind or own business.
> On 10 jun 2011, at 19:32, Owen DeLong wrote:
>=20
>> Some administrators want DHCP to be a complete solution and do not =
want to use RA at all, whether from a legitimate router or otherwise.
>=20
> It's good to want things. Doesn't mean you'll get it.
>=20
No, but, it does mean some might reject your shiny new protocol until it =
provides them the tools they believe they need,
whether you agree with their assessment of their needs or not.
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.
> One of the three big RIRs has already run out of IPv4 space, the =
second will within less than a year. IPv6 deployment is still measured =
by counting zeroes behind the decimal point. We still don't have good =
CPE and broadband specs. The "happy eyeballs" stuff is still =
experimental but much needed. Important operating systems have serious =
IPv6-related bugs.
>=20
> And THIS is the time to start asking for a new feature that even when =
viewed most favorably, is just a nice-to-have? No more that pesky =
multicast packet once every 200 seconds (or when a new host attaches to =
the network). Yes, that's really something the IETF and vendors have to =
spend their cycles on. NOW. Because otherwise, you know, there's this =
packet. It's really bad. Every 200 seconds!
>=20
Yes... This _IS_ the time to ask for a simple additional DHCP option =
definition that does not require rewriting any
existing standards and allows much greater operator flexibility. This =
_IS_ absolutely the time to solve these issues
before we get widespread refusal to deploy a dysfunctional protocol that =
causes operators to believe that IPv4+more
NAT is a superior solution because they can make their networks work =
well enough for their needs by doing so and
IPv6 still won't work in their environment.
This isn't about getting rid of the RA packet. Heck, anyone can turn of =
RAs on almost any host or router easily enough.
What this is about is providing missing functionality that a significant =
number of operators consider vital to their
ability to use the protocol in their environment.
I know you want to make this about eliminating the RA packet and solving =
rogue RA because, frankly, if it were
about that, the argument here would be pretty weak. However, that's not =
what it's about. It never was what this
is about. This solution would provide some small amount of help to the =
rogue RA issue, but, it wouldn't solve
it and there is already a known complete solution (RA Guard) which just =
needs to be more widely implemented.
>> There are situations, for example, where the administrator does not =
want all hosts in a broadcast domain to receive the same set of prefixes =
and/or the same set of routers. This can be achieved by using different =
parameters based on the system identifier in the DHCP configuration. It =
cannot be achieved using RA.
>=20
> It can also be done using my suggested "DHCP validates RA gateway =
address" mechanism.
>=20
Only if you add the routing information options to DHCP which you seem =
to be opposing. If you add
the routing information options to DHCP, then, we don't need RA any more =
and we can simply turn
it off on the routers and be done.
>> Eliminating rogue RAs is not the problem being described. That =
problem is solved through RA-Guard.
>=20
> Well, someone certainly intermingled the discussions, and it wasn't =
me.
>=20
You may not have started the intermingling, but, you certainly =
exacerbated it.
>> The problem being described is the desire to be able to configure a =
host from zero to functionally on the internet using DHCP without RAs. I =
think everyone understands that you don't want to do so. That's fine. =
However, adding the functionality to DHCPv6 doesn't require you to use =
it. Making it available for operators that want to use it is not a bad =
thing.
>=20
> 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? If you're worried that someone running a network you support will =
make
a decision you don't like if we give them that option, then, I don't =
have a lot of sympathy for you.
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. It's just another tool. Railing against it as you do is, =
frankly, about as useful as claiming that we shouldn't allow anyone to
develop a non-ethernet layer 2 transport because it will fragment the =
installed base and turn us away from the everything converges as
ethernet path that we currently seem to be on.
> I just wish someone had said the same when it was decided that =
.ip6.int in reverse DNS zone files was ugly and needed to be changed to =
.ip6.arpa. Or when someone decided that it's a good idea to set the DF =
bit on ALL packets when doing PMTUD.
>=20
Frankly, I agree that ip6.arpa makes more sense than ip6.int. What I =
don't understand is why we needed a different in-addr SLD to begin with.
Why couldn't it be in-addr.arpa? It's not like any valid IPv6 PTR record =
would conflict with any valid IPv4 PTR record. I don't mind ip6.arpa,
but, whatever.
Having said that, that decision frankly strikes me as being largely =
irrelevant to anything of operational concern. Who cares what the zone
is called as long as everyone uses the same name and expects the same =
structures within the zone.
What we're talking about here is a lack of functionality that has real =
operational impact.
> This industry has a history of doing stuff that ends up wasting huge =
amounts of time and money that could easily have been avoided but =
apparently the voice of reason was absent that day. Not this time.
>=20
You're right. Unfortunately, I think you are mistaken who has spoken =
with the voice of reason in this instance.
>> In some situations, this fate (it's fate, not fait, btw)
>=20
> Oh, right, I always get that wrong and I know I always get it wrong =
but still that doesn't help me to get it right.
>=20
lol
>> sharing is not desired.
>=20
> Why not?
>=20
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.
In the real world, things are not as black and white as the =
configuration examples in a router manual
and there are political issues that require technical functionality to =
work around.
I'm not defending these designs or situations, and, I agree that solving =
them at layers 8 and 9
would be preferable. However, solving them at layer 8 and 9 is nearly =
impossible and has to
be done differently and uniquely in each circumstance. In the meantime, =
working around them
by adding a couple of DHCPv6 options to the existing standard is =
harmless and pragmatic.
>> documenting that a host which sees no RA should attempt DHCPv6 would =
also be a good thing, IMHO.
>=20
> Nope, not a good thing. It doesn't work for normal operation because =
the delay while lack of RAs is observed would be unacceptable. Also, the =
M and O bits need to be honored.
>=20
If there's no RA, there are no M or O bits to honor. If the delay is =
unacceptable, the administrator can
turn on RAs that send the M and O bits and don't deliver any prefixes.
If there's no RA, there's nothing lost by having the host fall back to =
DHCP Only.
Yes, the DHCP with RA functionality would still be preferable (though, =
frankly, I see no
reason that a host couldn't send the RS and DHCP Solicitation at the =
same time and
only use the DHCP answer received (if any) if it got back an M|O bit(s) =
or no RA at all).
In this way, the RA delay would be only minimally disruptive and =
probably well within
acceptability in most environments. The M|O bits would still be honored =
if present.
> 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.
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.
> And like I said before, we have more pressing things to do than tinker =
some more with DHCPv6.
Meh... We can achieve a big win for relatively low cost very quickly and =
make IPv6 much
more palatable to a wide audience of enterprise administrators. I can't =
really say that there's
much more pressing than that. Yes, the issues you described above also =
fit into that category,
so, I'd say this is about equal.
Owen
