My next class:
Network Monitoring and Threat Detection In-DepthSingaporeNov 18th - Nov 23rd 2024

The Good, Bad and Ugly about Assigning IPv6 Addresses

Published: 2012-08-27. Last Updated: 2012-08-28 21:55:46 UTC
by Johannes Ullrich (Version: 1)
2 comment(s)

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

2 comment(s)
My next class:
Network Monitoring and Threat Detection In-DepthSingaporeNov 18th - Nov 23rd 2024

Comments

A quick thought is that a Hybrid (or better term might be "linked") solution would be a good fit. Possibly have RA hand out addresses, but have a process linking what is handed out to DHCPv6 to store it. DHCPv6 could also hand out addresses to those systems not yet able to take advantage of RA.
Haven't thought the whole process through, but having a repository of the information (DHCP) does seem to be handy, although there may be a need for two processes to distribute the information if all the handshaking can be worked out ?
soe of the "glue" you are looking for may be provided by DNS. You can use dynamic dns (or mdns, which is widely supported with IPv6) to track hosts and the IP addresses associated with them.

Diary Archives