bicknell at ufp.org
Wed Feb 2 15:13:12 CST 2011
In a message written on Wed, Feb 02, 2011 at 09:55:30PM +0100, Iljitsch van Beijnum wrote:
> On 2 feb 2011, at 21:18, John Payne wrote:
> > Having machines listen to any RA they receive is _today_ a cause of a lot of operational problems.
> You should have come to the IETF 10 or even 5 years ago. It's too late now, one day before the global pool of IPv4 addresses runs out. IPv6 is what it is. There will be more tinkering but if you think there's enough time to wait for your pet feature to be standardized and implemented widely, you're sorely mistaken.
I went to the IETF ~5 years and argued about the problems with RA's
and the lack of things like a default route in DHCP. I had working
group chairs tell me "You're an operator, you don't know what you're
talking about, and clearly don't understand IPv6". After a few
months of bashing my head against that abuse I gave up.
This problem will now be solved by vendors, when operators put up cash.
The solutions will be far uglier than if it was designed properly, and
the IETF will fade even further into irrevelance.
> Because IPv4-style DHCP often breaks because the DHCP server points to the wrong router address and because NAT breaks end-to-end connectivity so severe workaround in applications become necessary. But you knew that.
FUD, plain and simple. DHCP does not "often break", it's used by
probably hundreds of millions of devices every day, mostly without
problem. In fact, in my short time with IPv6 I've had several orders
of magnitude more breakage with RA's than with DHCP. Actual operational
experience. Try telling that to IETF folks though, and they are
convinced you're just an idiot rather than trying to understand what
happens when the rubber meets the road.
> Can you explain what exactly the problems with DHCPv6 are that you're running into that are inherent to DHCP and/or IPv6 host configuration and won't be fixed by bringing IPv4 ethernet switch features to IPv6?
I love this question, because it basically admits the protocol is
broken. To make RA's even remotely palitable, you need "RA Guard" on
the switches. This feature does not exist, but if we bring features
like DHCP guard forward into the IPv6 world, it's the logical solution
and solves the problem.
However, to the IETF people who think this, they just don't understand
how many networks are built and run.
Let's split the problem space. Ther are folks who say run hotel or dorm
networks and need to protect from bad, bad users. For them DHCP guard,
RA guard, BotNet guard, and all sorts of other features need to be in
However, there are a lot of corporate network users where there really
is no rogue DHCP server. Perhaps they are even using 802.1x on end user
ports, so there are no rogue users at all. However, they do need a
robust networking configuration.
I'll give the simple scenario I've done to myself twice. Went to a
remote site. Replaced the router with a new router. Took the old
router back to the office and plugged it in so I could upgrade the code.
IPv6 stopped working instantly.
IPv4 kept working just fine, forever.
Why? Well, the router from the other site sends out RA's as soon as it
is plugged in, and all the hosts believe it and sink traffic to it. On
the IPv4 side it was a DHCP HELPER.
Let me repeat that, it's the part the IETF folks always miss.
IT WAS A DHCP HELPER.
A box on the network goes to do a DHCP request. It goes to the
actual router, and to this "rogue" remote office router. However, being
not configured correctly the rogue router's DHCP helper points to a
default route out a WAN interface that is down, and the packet is
dropped. No response, the host gets a response from the real router and
all is well.
The mere act of plugging in a old router takes down IPv6, but leaves
IPv4 working just fine. I'd say that's a LOT less robust. Rather than
give me IPv6 DHCP that works like IPv4, and thus would be just as
robust, the IVTF, the vendors making the decisions, want me to deploy RA
guard, which ooops, isn't on any of the old switches so you'll have to
replace all of them.
Basically, as an operator, the vendors got together, developed a
broken protocol, figured out a work-around that requires me to replace
everything. Or in short, the vendors figured out how to make me replace
Leo Bicknell - bicknell at ufp.org - CCIE 3440
PGP keys at http://www.ufp.org/~bicknell/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 826 bytes
Desc: not available
More information about the NANOG