Looking for general feedback on IPv6 deployment to the edge. As it turns out delivering IPv6 to the edge in an academic setting has been a challenge. Common wisdom says to rely on SLAAC for IPv6 addressing, and in a perfect world it would make sense. Given that historically we have relied on DHCP for a means of NAC and host registration, like many academic institutions, the idea of sweeping changes to accommodate IPv6 was just not going to happen in the near future. The only solution that lets us expand our roll out IPv6 to the edge without major changes to the production IPv4 network seems to point to making use of DHCPv6, so the effort has been focused there. Our current IPv6 allocation schema provides for a 64-bit prefix for each network. Unfortunately, this enables SLAAC; yes, you can suppress the prefix advertisement, and set the M and O flags, but that only prevents hosts that have proper implementations of IPv6 from making use of SLAAC. The concern here is that older hosts with less than OK implementations will still enable IPv6 without regard for the stability and security concerns associated with IPv6. Needless to say, the thought of being able to enable IPv6 on a per-host basis is met with far less resistance than opening up the floodgates and letting SLAAC take control. Ultimately, the best solution that I've been able to come up with is to preserve the IPv6 allocation schema and reserve a 64-bit prefix for each network, but for the initial deployment use an 80-bit one in its place with the extra 16 bits given a value of 1. The advantages of this: Guarantee that SLAAC will not be initiated for the prefix; Allow for a migration path to 64-bit prefixes in the future; and, Make it easy to identify a network that us making use of an 80-bit prefix by setting the extra bits to a value of 1. This allows us to be fairly confident that extending IPv6 to edge networks will not impact production services, and focus on DHCPv6 for host configuration and address assignment. We have no problem using a 64-bit prefix and letting SLAAC take care of addressing for certain networks where we actually manage the hosts, so that has been included as an exception. All other networks, however, will make use of DHCPv6 or manual configuration to receive native IPv6. So far, this has proven to work well with testing of various hosts and applications. Has anyone run into issues with applications in not using a 64-bit prefix? Of course, the other challenge here is proper DHCPv6 client implementations for host operating systems. Linux, Windows Server 2003 and later, Windows Vista, and Windows 7 all support DHCPv6. Windows XP has a poor implementation of IPv6 but has the option of using Dibbler or some other 3rd party DHCPv6 client. Mac OS X is a challenge; it currently has no option for DHCPv6, though newer releases provide for manual configuration of IPv6 addressing. Does anyone know if Apple has plans to release a DHCPv6 client for Mac OS X? Since the goal for this initial wave is to make IPv6 available to those who request it or have a need for it, we feel its acceptable that there will need to be some user participation in enabling IPv6 for a host. I think the hope is that more systems, like Windows 7, will begin including mature DHCPv6 clients which are enables when the M flag for a router advertisement is set and perhaps make it the default behavior. Is this likely to happen or am I being too optimistic? Anyway, just thought I'd bounce it to NANOG and get some feedback. -- Ray Soucy Communications Specialist +1 (207) 561-3526 Communications and Network Services University of Maine System http://www.maine.edu/