(Yes this is a top post ... get over it) Thank you Leo for doing such a great job in this scenario of explaining why acronym familiarity has much more to do with people's entrenched positions, than the actual network manageability they claim to be worried about. The hyperbolic nonsense in >>> replace every ethernet switch in your entire network with new hardware that supports "RA Guard", and then deploy new configuration on every single port of every single device in your network. Please develop a capital justification plan for Mr MoneyBagsCEO for replacing every switch in your network so you can safely deploy IPv6. <<< , clearly shows that it is the spooky acronym "RA" that is more important to focus on than reality. It also does a nice job of wrapping up the point about why an IPv6 rollout needs a long term plan with appropriate multi-year budgeting. ;) For starters, in the scenario described, you only need 1 port protected, and that is for the person that would be doing the configuration, so it is 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 ... There are two very different models for IPv6 address/information allocation, and each needs to be fully functional and independent of the other; period. 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. 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. The only devices I know of that attempt to ignore an RA are Samsung's Android image which do the stupid thing of configuring an address from the RA on the lan, but refuse to create a routing entry from it if there has ever been a route via the 4G radio. (that is fundamentally a platform bug because google lets them set the knobs that way instead of doing the right thing as a metric bias between the available routes for fall back when one or the other goes away) Ryan's different dhcp answers based on auth state is a use case, and if in widespread use as a way around 1X, it might get enough support by itself to carry the day. If there are other use cases which are not self-contradictory justifications of maintaining acronym familiarity, they will spread the support base and make it easier to get past the objections. This is not about which model is 'right', if anything limiting it is about minimizing the different ways people can hang themselves without realizing the risks beforehand. At the end of the day, the IETF's job is to document technologies so vendors can implement for consistent behavior in independently managed networks. Vendors will build whatever they are paid to build, but if you want generic COTS, then lots of people need to justify a specific behavior with some level of consistency to get that documented as the consensus approach. So far there have not been enough consistent scenarios to get an RI option passed. Tony
-----Original Message----- From: Leo Bicknell [mailto:bicknell@ufp.org] Sent: Monday, December 30, 2013 3:25 PM To: Lee Howard Cc: Jamie Bowden; North American Network Operators' Group Subject: Re: turning on comcast v6
On Dec 30, 2013, at 2:49 PM, Lee Howard <Lee@asgard.org> wrote:
I'm not really an advocate for or against DHCP or RAs. I really just want to understand what feature is missing.
I encourage you to try this simple experiment in your lab, because this happens all day long on corporate networks around the world, and illustrates the differences quite nicely. While not a complete treatment of the operational differences, it's an important illustration.
Configure up a simple network topology of three boxes representing a hub and spoke network:
DHCP SVR | --lan--r1--wan--hubrtr--wan--r2--lan
Number it up as expected for both protocols:
wan links: IPv4 /30, IPv6 /64 lan links: IPv4 /24, IPv6 /64
Drop a DHCP server off the hubrtr, set r1 and r2 to forward DHCP requests to it. Verify a machine plugged into either of the LANs gets a fully functional network for both protocols.
Now, take r1 turn it off, and stick it in a closet. You see, that office closed. Normal every day thing.
Plug up two PC's to the remaining LAN off r2. This represents your desktop, and your neighbors desktop. Think Bob from accounting perhaps. Open two windows on each, one with an IPv4 ping, one with an IPv6 ping running.
Now, boss man comes in and has a new office opening up. Go grab the r1 box out of the closet, you need to upgrade the code and reconfigure it. Cable it up to your PC with a serial port, open some some sort of terminal program so you can catch the boot and password recover it. Plug it's ethernet into your lan, as you're going to need to tftp down new config, and turn it on.
Here's what you will soon find:
1) The IPv6 pings on both machines cease to work.
2) The IPv4 network continues to work just fine.
Now, for even more fun, turn on another PC, say Sally from HR just rebooted her machine. It will come up in the same state, IPv6 not working, while IPv4 works just fine.
Lastly, for extra credit, explain to Mr MoneyBagsCEO why Bob and Sally are now complaining to him that their network is down, again. Make sure you not only understand the technical nuances of why the problem above happened, but also how to explain them to a totally non-technical CEO.
(Oh yeah, go ahead and unplug r1 to "fix" the problem, and observe how long until the pings start working again. I think it's 15 minutes, IIRC. For super-extra credit tell me how to make that time shorter for everyone on the LAN with Cisco or Juniper commands on r2.)
I'll give you a hint on understanding this issue. The IETF's grand solution is to replace every ethernet switch in your entire network with new hardware that supports "RA Guard", and then deploy new configuration on every single port of every single device in your network. Please develop a capital justification plan for Mr MoneyBagsCEO for replacing every switch in your network so you can safely deploy IPv6.
Now do you understand why people just want to put the route in DHCPv6 and move on?
It's not a "feature" that's different between the two, it's that operationally they have entirely different attack surfaces and failure modes. And yes, it involves people doing stupid things. However if the IETF is going to rely on smart people deploying networking devices we might as well give up and go home now.
-- Leo Bicknell - bicknell@ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/