In a message written on Tue, Jun 14, 2011 at 02:00:35PM -0400, Ben Jencks wrote:
This has always confused me. What aspect of host configuration is the router providing that's so problematic? The prefix, which has to match on the router and host in order for anything to work anyway? The indication to go use DHCPv6, which doesn't really add anything since you need to configure a DHCPv6 proxy anyway? There's just so little information in an RA, and the router needs to know it all anyway, that I'm having trouble understanding what environment would find this so horrifying.
The problem for most folks is that it becomes an "in addition to" thing to support, troubleshoot, and debug. To make that ok, you have to look at the cost/benefits. I urge everyone in this thread to try a simple experiment. Configure an IPv6 segment in your lab. Make sure there is no IPv4 on it, not on the router, and that the IPv4 stack (to the extent possible) is disabled on the hosts. Now try to use one of the hosts to access IPv6 content. You'll find the box does SLAAC just fine and gets an address. You'll find RA's provide a default gateway and can get your packets out to the world. You'll also find absolutely nothing works, at a bare minimum because you have no DNS servers. People aren't noticing this today because they are dual stack, and end up reaching their DNS servers from IPv4 DHCP information over IPv4 transport. They may then get AAAA's, and use IPv6 after that. Your box is dead in the water. How do you get DNS servers? Today the answer is to run DHCPv6. Of course if you need other options (netboot information, NTP servers, domain controllers, and so on) you also need DHCPv6 to get a functioning box. So just like in IPv4, IPv6 requires DHCP to have a functioning end user box. DHCP remains a hard requirement. The odd part now is that in IPv4 DHCP carries the default gateway, while in IPv6 land you must also run Router Advertisements on your router and have the host listen to them. The industry has taken a robust single protocol solution and turned it into a dual, co-dependent protocol situation. The IETF is working on one solution, which is to add DNS information to the RA's! So now you'll configure your routers to hand out DNS servers to clients, and then everything else (NTP servers, Domain Controllers, etc) in DHCP! What I and others are suggesting is the other way around, how about we just put a default route in DHCPv6 like we did in v4, and forget all about RA's so we're back to a single protocol solution? Beyond that it is important to notice that the failure modes and attack vectors for RA's and DHCP are different. I argue DHCP is "better", but I also realize that's a very subjective judgment. That said, there are cases where people may prefer DHCP's robustness and/or failure modes, and cases where people might prefer RA's. Lastly, there's a hidden bit here many people haven't dealt with yet in lab networks. In IPv4 critical environments it's typical to use HSRP or VRRP to provide a single gateway across two routers. The IPv6 way to do this is to have both advertise RA's, possibly with different priorities. Depending on your environment this may or may not be as "feature rich" for you. For instance RA's timers aren't as adjustable (as they depend on end hosts), and I don't know of any vendor who implements interface tracking for RA's the way it is done with HSRP/VRRP. We need more folks using IPv6 in production to find this stuff. If you spin up a dual stacked box in the lab with a single router RA's work great, DHCPv4 gives you DNS, and you'll never notice any issues. Run a dual-router IPv6 only production network for some end users, and you'll notice some differences, and I think find that some of those differences are deficiencies. -- Leo Bicknell - bicknell@ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/