On Dec 31, 2013, at 12:36 PM, Tony Hain <alh-ietf@tndh.net> wrote:
likely pointless. Do you really believe that dhcp messages picked up by the rogue router wouldn't end up answering with the wrong values and breaking both IPv4 & IPv6? Next, do you really believe that DHCP Guard for an IPv4 aware switch will do anything when an IPv6 DHCP message goes by? Don't you have to replace every switch and reconfigure anyway? Or is rogue DHCP service a problem that goes away with IPv4? Why do people continue to insist that a cornerstone of their network security model is tied to an inherently insecure protocol that was never intended to be used as a security tool? ... but I digress …
In the scenario I described, which I suggest is extremely common, the rogue router will not provide any DHCPv4 client with an address, ever. It is configured to forward to a DHCP sever, and based on the steps I suggested it has no route to reach it. It will forward the packet out its down uplink, and never get a reply. It is in fact 100% benign. Let me repeat, it's 100% benign, and will not affect any users, ever. Yes, if the router has a local DHCP server there would be an issue. But that's not actually very common, most of the people running DHCP want a central server and the logging that goes along with it. I'll admit my scenario was contrived, constructed to specifically show ONE aspect of the problem. It is not the only operational issue, but it is one that is easy for engineers to understand and replicate. However, it's also common. I know multiple people who shot themselves in the foot in this very way, with operational networks. It's not a theoretical problem, it's one that happens every day. Here's another problem that happens every day in data centers and offices. Someone accidentally bridges two VLAN's together for a few minutes by plugging in a cable to the wrong port, realizing it and then unplugging it. In an IPv4+DHCPv4 world the majority of the time the impact is, well, NONE. No hosts notice. Some switches compute a new spanning tree adjacency and some broadcast traffic goes where it shouldn't, but everything remains operational. Do the same with IPv6 and all of the hosts on one of the two VLAN's will instantly stop working. There are controlled environments, like a single tenant data center where a rogue DHCP server is simply not a security concern, but where a tech accidentally bridging VLAN's is a very real possibility. The fact of the matter is that the scale, scope, and impact from a rogue DHCP server is entirely different from a rogue RA server. IPv4+DHCP is operationally much more robust in the face of various scenarios, where as IPv6+RA pretty much always results in near instantaneous 100% failure.
Unfortunately there have been too many voices demanding a 'one size fits all' approach within the IETF, and we have gotten to the current situation where you need to deploy parts of both models to have a functional network. RFC 6106 is a half-baked concession from the 'dhcp is the only true way' crowd to allow home networks to be functional, but if you want anything more than DNS you have to return to the one-true-way, simply because getting consensus for a more generic dhcp-options container in the RA was not going to happen. The Routing Information DHCP option has been held hostage by those that might be described as a 'dhcp is broken by design' crowd, because many saw that as a bargaining point for consensus around a more feature rich RA. Both hard line positions preventing utility in the other model are wrong, but in the presence of a leadership mantra of one-size-fits-all, neither side was willing to allow complete independent functionality to the other.
I think you describe the IETF situation reasonably well. The internal bickering between the "RA camp" and the "DHCP camp" have largely prevented either one from producing something robust.
Making progress on the Routing Information option requires a clear scenario to justify it, because vast swamp of dhcp options that have ever been used in IPv4 are not brought forward without some current usage case. Lee was asking for that input, and while the scenario you paint below might be helped by that option, it presumes that every device on the network has additional configuration to ignore an errant RA sent from the router being configured simply because the network is supposed to using DHCP.
This is some extremely circular logic. We can't have DHCP until there are options in devices to ignore RA's. We can't have an option to ignore RA's in devices, because at the moment RA's are the only way to get a default route so it doesn't make sense. Someone has to go first, the other side will follow. I suggest it makes a lot more sense to get working DHCP, before pressuring end-user boxes to have an option or even default to ignoring RA's. -- Leo Bicknell - bicknell@ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/