The stupidity of trying to "fix" DHCPv6

Sat Jun 11 02:03:46 UTC 2011

On Jun 10, 2011, at 12:57 PM, Iljitsch van Beijnum wrote:

> On 10 jun 2011, at 18:06, Leo Bicknell wrote:
> 
>> 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.
> 
> 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.
> 
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.
> 
> 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.
> 
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.
> 

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.
> 

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:
> 
>> 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.
> 
> It's good to want things. Doesn't mean you'll get it.
> 

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.
> 
> 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!
> 

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.
> 
> It can also be done using my suggested "DHCP validates RA gateway address" mechanism.
> 

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.
> 
> Well, someone certainly intermingled the discussions, and it wasn't me.
> 

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.
> 
> 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? 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.
> 

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.
> 

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)
> 
> 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.
> 
lol

>> sharing is not desired.
> 
> Why not?
> 

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.
> 
> 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.
> 

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.
> 

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