Wow, I don't recall making it personal? I have broken networks before by connecting miss-configured devices, by the way, and I was a moron for doing so. I don't base my network design decisions around preventing people with full access to configure the network breaking it; but rather restrict the level of access people have and impingement sane policies on when and how changes are made; like most of the people on this list. The point was you shouldn't base protocol design around the possibility that someone might tell it to do something you don't want it to do; otherwise you'll end up with a one-size-fits-all protocol that has zero flexibility (and might not even be functional at all). Similar problems existed in IPv4; but over time networks evolved and better protection methods became available. The days of the dumb switch are over; and at the price and performance of today's switches we should expect features like RA guard and MLD snooping to be standard. We threw out Ethernet hubs a decade or two ago for good reason, and there was resistance then too. On a side note, if you're going to resort to direct personal attacks, maybe you shouldn't be doing so while representing your company. Everything on NANOG is archived and sticks around for a very, very long time. Ray On Fri, Jun 10, 2011 at 3:21 PM, Steve Clark <sclark@netwolves.com> wrote:
On 06/10/2011 09:37 AM, Ray Soucy wrote:
You really didn't just write an entire post saying that RA is bad because if a moron of a network engineer plugs an incorrectly configured device into a production network it may cause problems, did you?
You are the moron - this stuff happens and wishing it didn't doesn't stop it. Get a clue!
Honestly. This whole argument is getting ridiculous.
On Fri, Jun 10, 2011 at 9:32 AM, Leo Bicknell <bicknell@ufp.org> wrote:
In a message written on Fri, Jun 10, 2011 at 01:03:01PM +0000, Bjoern A. Zeeb wrote:
On Jun 10, 2011, at 10:10 AM, sthaug@nethelp.no wrote:
Several large operators have said, repeatedly, that they want to use DHCPv6 without RA. I disagree that this is stupid.
I wonder if it's just a "violation" of rule #1: stop thinking legacy!
People are used to what they have done for a decade or two. It's hard to see the change and results in "why is this all so different and complicated?". It's hard to open ones mind for the new, but it is essential to do with new technology.
The problem in this case is that the failure modes are significantly different. Some folks have learned this the hard way.
It's a very easy scenario to reconstruct. Consider the "branch office router" in a typical corporate enviornment. We're talking a device with one WAN port, and one LAN port. Configure it for dual stack, speaking IPv4, and in IPv4 configure it the typical corporate way with a "DHCP Helper" forwarding requests over the WAN to a central DHCP server. In IPv6, configure it with RA's, the supposed "better" way.
Now, take the 100% working branch router and have it sent back to corporate. Maybe they got a bigger router, maybe the office closed. A network engineer gets the router and is tasked with making it ready to redeploy.
The network engineer plugs it into the switch on his desktop, plugs in a serial cable, turns it on and steps out to get a coffee while it boots. He's planning to erase the configuration and then load new software over the network.
As soon as the router boots the IPv6 network fails for all the users on his subnet. IPv4 keeps working fine.
Oops.
What happened? Well, the router sent IPv6 RA's as soon as it came up, and every workstation instantly started using them. In IPv4, the router received DHCPv4 requests and forwarded them per the helper address, except that its WAN port is down, and thus it in fact didn't send them anywhere.
The important points:
- IPv4 "failed safe" with the DHCP config. This "rogue device" will never disrupt the IPv4 configuration. DHCP snooping isn't even needed in your switches, since it never returns a response.
- IPv6 "failed immediately" with the RA configuration. What's worse is if you simply turn the device off after you realized you took down the entire network devices will continue to be broken for 2-4 hours until the RA's time out. The only method to mitigate is to deploy RA guard on all of your switches, which probably means replacing 100% of your hardware with new stuff that can do that, and then deploying new features.
The fact of the matter is that the failure modes of these two protocols are vastly different operationally. The DHCP failure semantics are not only better understood, but cause less disruption to the network. Even a properly rouge DHCP server will only damage _new_ clients coming up on a network, existing folks will work just fine. Contrast with RA's which instantly break 100% of the users.
Even more annoying is that if I use RA's for the default gateway, I still have to run DHCPv6 anyway. If I don't my boxes don't have DNS servers, NTP servers, know where to tftpboot, etc. It's not a choice of one or the other, it's I always run DHCPv6, do I need RA's or not.
Given the failure modes I would much prefer to run with RA's turned off completely, and have DHCPv6 able to provide a default gateway just as it works in IPv4.
My opinion comes not from "thinking legacy", indeed my employer has been fully dual stacked since 2003. My opinion comes from the fact that in the 8 years of operational experience we have RA's are significantly more fragile, and IMHO not ready for widespread IPv6 deployment.
-- Leo Bicknell - bicknell@ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/
-- Stephen Clark NetWolves Sr. Software Engineer III Phone: 813-579-3200 Fax: 813-882-0209 Email: steve.clark@netwolves.com http://www.netwolves.com
-- Ray Soucy Epic Communications Specialist Phone: +1 (207) 561-3526 Networkmaine, a Unit of the University of Maine System http://www.networkmaine.net/