[141722] in North American Network Operators' Group
Re: The stupidity of trying to "fix" DHCPv6
daemon@ATHENA.MIT.EDU (Iljitsch van Beijnum)
Fri Jun 10 15:57:25 2011
From: Iljitsch van Beijnum <iljitsch@muada.com>
In-Reply-To: <51851769-D812-4EEE-84A0-F463B7E852AB@delong.com>
Date: Fri, 10 Jun 2011 21:57:07 +0200
To: Owen DeLong <owen@delong.com>
Cc: "nanog@nanog.org" <nanog@nanog.org>
Errors-To: nanog-bounces+nanog.discuss=bloom-picayune.mit.edu@nanog.org
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.
> 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.
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.
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.
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.
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!
> 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.
> 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.
> 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.
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.
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.
> 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.
> sharing is not desired.
Why not?
> 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.
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.
And like I said before, we have more pressing things to do than tinker =
some more with DHCPv6.
