As you are planning to roll out IPv6, one of the questions that keeps coming up is how to assign addresses. Sure, you may do so manually one system at a time, but that is not exactly the preferred method. IPv6 provides two different protocols to assign addresses:

Router Advertisements (RA)

The router may advertise itself, and the network it is supporting, via Router Advertisements. In this case, the router will typically advertise the first 64 bits of the address, and the host will make up the last 64. Router advertisements that advertise more then 64 bits are ignored. Router Advertisements are widely supported by client devices. The problem with this method is that you will see very little accountability as to who is using what IP address at what time. Unlike DHCP, there is no "lease" and the router will not log who used what address when.

DHCPv6

DHCPv6 is a complete rewrite of the DHCP protocol, but provides many of the same features you are used to from DHCPv4. Your DHCPv6 server will hand out leases, you can assign static IP addresses, and you will obtain logs with details who obtained what IP address, just like in IPv4 (of course, just like in IPv4, a malicious user could just "pick up" an address without using the DHCP server).

RA and DHCPv6 interactions

It gets tricky if you have both, router advertisements and DHCP. This is actually "normal" when it comes to IPv6. Router advertisements include two flags, which will indicate the presence of a DHCP server:

- "managed" flag: used to indicate that there is a DHCP server handing out addresses.
- "other" flag: used to indicate that there is a DHCP server handing out other information (like DNS server addresses) but not addresses. The address is still provided by the router advertisement.

I ran some preliminary tests to see how different operating systems resolve the conflicts that may occur if both router advertisements and DHCP is present. I used a Cent OS server as router and DHCP server, and as client, I used Cent OS 6.3 ("Linux"), OS 10.8 Mountain Lion (OS X), Windows 7 and Windows 8 (latest pre-release from technet).

1. "Other" and "Managed" flag cleared, but the DHCP server is still running and the systems had a DHCP address prior to the last reboot
   Windows 8 and OS X will still use the DHCP server.
   Linux and Window 7 will only use the RA provided address
2. "Managed" flag set, DHCP server running
   all operating systems tested will use RA and DHCP provided addresses
3. "Managed" and "Other" flag set, but the DHCP server is not running
   all operating systems tested will just use the RA provided addresses
4. "Managed" and "Other" flag set (and DHCP Server running
   This test was a bit tricky. In a first round, all operating systems ignored the RA, and only used the DHCP address. In a second round, they accepted all.

Advertising recursive name servers via RA

A relatively recent extension to router advertisements allows the inclusion of the recursive name servers IP address ("RDNSS"). This option was originally introduced by RFC 5106, and later revised by RFC 6106 [1]. Linux and OS  X appears to accept it, but Windows doesn't.  (7 or 8). 

iOS/Android

According to my tests, neither operating system appears to support DHCPv6. You have to use router advertisements to configure IPv6. However, both operating systems make it hard to review the IPv6 configuration, and I am still working on more systematic tests. According to some sources, iOS appears to support DHCPv6, but I wasn't able to verify this so far in my tests [2].

[1] http://tools.ietf.org/html/rfc6106
[2] http://en.wikipedia.org/wiki/Comparison_of_IPv6_support_in_operating_systems

(thanks to feedback from readers, I did edit some parts of the diary removing confusing statements about "RA" and stateless auto configuration as well as cleaning up the language around RFC 5106). 

 (want to learn more about IPv6? Or just want to go to Vegas? See http://www.sans.org/network-security-2012/description.php?tid=5086 )

------
Johannes B. Ullrich, Ph.D.
SANS Technology Institute
Twitter