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 the switches. 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 everything. -- Leo Bicknell - bicknell@ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/