Just to clear things up, I'm not advocating the use of 80-bit prefixes. I was asking if they were a legitimate way to prevent SLAAC in environments with hardware that don't support disabling the autonomous flag for a prefix, or hosts that don't respect the autonomous flag. I've since done some testing in the lab, and have found that the majority of operating systems that are still in use respect the autonomous flag when deciding whether or not to run SLAAC if IPv6 is implemented, so this becomes a non-issue. I agree, sticking with a 64-bit prefix for every network is a good thing. SLAAC itself is also a good thing and I'm not advocating that it go away. I think its rather elegant and provides a lot of flexibility. That said, DHCPv6 is also a key part of IPv6. The fact that we have M and O flags in RA, and the A flag in advertised prefixes is a pretty strong signal that both stateless and stateful configuration are valid choices for IPv6 deployment. Adding DNS information to RA would generally be a bad idea. There is more to host configuration than just DNS, though DNS is the most common. I think that RA knows its role and archives it rather nicely. When you want to provide hosts with other configuration, like DNS, you can do so making use of a lightweight implementation of DHCPv6. In fact, most routers already support this. The argument that implementing DHCPv6 in the client is somehow too much work is ridiculous. DHCPv6 is as essential to IPv6 as ICMPv6 and MLD. You really shouldn't consider an implementation of IPv6 without a functional DHCPv6 client complete. At the same time, adding gateway information to DHCPv6 is also a bad idea. This is already accomplished by RA in an elegant and thoughtful way. This whole line of thinking is a result of the mindset that SLAAC and DHCPv6 are mutually exclusive; they're not. RA, SLAAC, and DHCPv6 compliment one another. They are all important components of the IPv6 addressing architecture. What we have now generally works well. Getting vendors to work together and actually implement things the same way is sometimes a challenge. Perhaps we need to update the language on RFCs from MAY and SHOULD to MUST and eliminate the ambiguity of what needs to be implemented with IPv6. In an enterprise environment, SLAAC has no place. It makes perfect sense to not run SLAAC on prefixes you advertised in this case. Just because SLAAC is the default doesn't mean it's the only method of deployment. There are still some challenges to work out with DHCPv6 implementations, and it may help dual-stack environments if DHCPv6 is amended to include a MAC address in requests when running on a dual-stack network so associations can be made between IP and IPv6 addresses on a host, but the use of DUID is generally a good thing. Once we start seeing more IPAM solutions include support for IPv6 and DHCPv6 I think a lot of the hostility towards DHCPv6 will go away. We've been implementing DHCPv6 support in our home-grown IPAM solution and have found that it all works rather nicely. Mac OS X is a challenge since it doesn't provide a DHCPv6 client, but our position has become that of saying we don't roll out IPv6 to clients with incomplete implementations and to leave it at that. IPv6 isn't quite necessary for all clients just yet. There is very little that is reachable by IPv6 only. Until that changes, we're willing to ignore certain groups of clients in an effort to pressure vendors to come into the fold and support DHCPv6 by default. If we have a case where there is a legitimate need for IPv6, we still have the ability to manually assign an IPv6 address on the host, but this would be on a very limited basis. If you're an ISP and deploying IPv6 for your residential customers, by all means run SLAAC. It's easy and it works. If you manage an enterprise IT environment and need control over your network, disable SLAAC and run DHCPv6. This will allow you to roll out IPv6 at your own pace, giving you time to make sure that hosts and users are prepared for it, all while maintaining the benefits of DHCPv6 in your architecture. That's all I'm trying to say. -- Ray Soucy Communications Specialist +1 (207) 561-3526 Communications and Network Services University of Maine System http://www.maine.edu/