The routing and addressing problem is nothing new in the IPv4 world. Version 6 of the Internet Protocol (IP), which is no spring chicken itself, was designed to help. This article investigates whether IPv6 can provide a full-fledged alternative to IPv4 on today’s networks. Despite my initial euphoria, reality hit me hard during my testing sessions and turned this article into a report about my own experiments on an IPv6-only network.

^{The Theory}

The method a computer on an IPv6 network uses is described in theory by the Internet Engineering Task Force (IETF). RFC 4861 specifies the Neighbor Discovery Protocol (NDP), which replaces the Address Resolution Protocol (ARP) among other things. It is responsible for mapping MAC addresses to IP addresses but also discovers the router responsible for addresses on other networks and optionally distributes address prefixes for the local network. The sequence is as follows:

• When the interface is enabled, a Router Solicitation Request is sent to the multicast address ff02::2 (all routers on the local LAN segment.) All IPv6 routers on the network reply with a Router Advertisement.
• Depending on the flags in the advertisement, the client either automatically configures an IP address in the prefix it receives using the MAC address in EUI64 format (see the “Creating Addresses with EUI64” box) or in the anonymizing temporary version. The flag for this is AdvAutonomous.
• If the AdvManagedFlag is set, the “administered protocol” is additionally used for autoconfiguration – this means DHCPv6. If both flags are set, the client uses DHCP to retrieve an address and assigns the automatically configured address to itself.

The client is thus reachable on the LAN and will also find its neighbors. Additionally, the client knows the IPv6 routes for contacting computers beyond the LAN. If DHCP is not used, the client currently doesn’t know which name server to use, or where the other network services are located. RFC 5006 thus defines an extension to the router advertisements that lets the clients find the name server. Another important flag is AdvOtherConfig. According to the IETF and the radvd man page, this flag is supposed to be explained in RFC 4862 regarding IPv6 stateless address autoconfiguration. However, document history shows that it was removed from the RFC but not deprecated, so it is still valid. According to the radvd documentation, the meaning of the flag is: “When set, hosts use the administered (stateful) protocol for autoconfiguration of other (non-address) information.” In other words, DHCPv6 must be used to find services like name servers, etc.

DHCPv6 basically acts like DHCP for IPv4, except that it doesn’t use broadcasts (which no longer exist in IPv6). Instead, it uses a multicast address and the DHCP server binds to port 547/UDP. For my tests, I used systems with Linux (Gentoo), Windows 7 Ultimate, and Mac OS X Snow Leopard.

^{Windows 7}

My Windows lab system was a fresh installation with default settings in a virtual machine (VM) on VirtualBox. The VM’s network interface was connected to a VLAN segment that didn’t speak any IPv4 (like all of my test systems). The address configuration in Windows 7 works as expected, or as defined by the Router Advertisements. All flags are implemented accordingly (Figure 1), but RDNSS support is missing.

Figure 1: Apart from RDNSS, all of the IPv6 parameters are configured correctly on Windows 7.

If DHCPv6 is used, the client system also receives details of a name server. An investigation with Wireshark showed that the client only asks for a name server and the list of local domains. Additionally, some Microsoft-specific options are requested. They tell the client everything it needs on the Microsoft network, because the client uses DNS with service discovery (SRV records for services) to find all the components required for functionality.

In my first test, a strange thing happened: The IP address of a web server was advertised by means of a WPAD DNS entry; the web server used the wpad.dat file to serve a proxy autoconfiguration file. And, the file contained the web proxy on the LAN with a resolvable IPv6 address that was also connected to IPv4 and thus capable of accessing both worlds. The BITS service, which Microsoft uses for patches, thus worked immediately. Additionally, a Firefox browser that installed later, and which was configured for autoconfiguration, was able to access the proxy.

The preinstalled Internet Explorer 8 failed to discover the Internet service – the rest of the network was configured so that no direct IPv6 connection to the Internet was possible, and the proxy was used at all times. IE was able to talk to IPv6-capable web servers on the LAN. The remedy was to disable IPv4 in the network properties, thus forcing Internet Explorer to use the proxy.

If Windows 7 fails to find a DNS server, it uses three standard addresses as its name servers: fec0::1, fec0::2 and fec0::3. The prefix fec0 was originally the counterpart to the RFC 1918 addresses but has been deprecated. If you don’t have a DHCPv6 server, you can use a workaround: assign one of the fec0 addresses to a server on the LAN, and run an IPv6-capable name server on it.

In my test, Windows 7 failed to create an entry on the DNS server. Sniffing the DNS packets sent by the client failed to reveal an update packet, which the client would normally use to register its hostname and the IP assigned to it. This is useful in Active Directory environments at least to make sure that the clients work on the network.

^Linux

The Linux kernel has spoken IPv6 for some time now, at least in terms of the address configuration. It also takes the value of the autonomous flags into account, but that’s more or less where the buck stops. Linux introduced support for the RDNSS flag in 2.6.24, but you need a userspace daemon that parses the name server from the advertisements and writes the information to the /etc/resolv.conf file. The Netlink interface is used for this. In kernel versions prior to 2.6.24, the service itself tries to sniff and parse the advertisements. The daemon is called rdnssd and comes with the Ndisc6 package, which includes other useful tools.

DHCPv6 clients for Linux are available, for example, from the Internet Software Consortium (ISC), which also provides the popular DHCP Server, or in the dhcpv6 package, which also includes a server. The packages have limited support (the ISC version is more complete) that let you retrieve an address as well as options such as the name server or NTP server.

Compared with Windows 7, the problem is that you need to know whether DHCPv6 is in use when configuring a client. There is no daemon that parses the advertisement’s Managed option and then launches – or doesn’t launch – the DHCP client process. Open source programmers have a chance to make a name for themselves here.

Despite this, if you use DHCPv6, Linux will parse the advertisements to learn both routes and other configuration parameters, and the client will work on the network. If you only want the clients to use DHCP to discover the name server, advertisements with the RDNSS flag are all you need.

^{Mac OSX 10.6 Snow Leopard}

Apple was the biggest disappointment in my lab, especially considering the fact that the latest operating system versions and applications like Mail and Safari have supported IPv6 for some years. Apple also uses IPv6 with link-local addresses (prefix fe80) to find services with its Bonjour protocol. Even an iPhone 3G, provided with router advertisements in our WLAN test, sent a DHCPv6 request and asked for the name server.

However, a Snow Leopard client only evaluates the flags in the router advertisements; support for RDNSS is missing.

If the Managed flag is set, there is no DHVPv6 client that retrieves the required data. You can use the system settings in the network area IPv6 addresses to manually enter the name server (Figure 2). However, this approach is not recommended for large-scale networks.

Figure 2: If necessary, you can enter IPv6 name servers manually in Mac OS X.

While I was working on this article, Apple’s Version 10.7 “Lion” was released. This version now has a DHCPv6 client, and the autoconfiguration is standards-compliant and functional according to various reports in network forums.

Conclusions

The results in my lab weren’t really convincing, as some manual attention is still needed. You can get it to work, but it will mean investing more time than overworked administrators can afford.

I tried my luck with Linux (Gentoo), Windows 7 Ultimate, and Mac OS X Snow Leopard. To sum up briefly, none of these systems worked as it should have out of the box.

The Author
Konstantin Agouros works for n.runs AG as a consultant for network security. He focuses on telecommunications providers. He also published a book, DNS/DHCP, with Open Source Press.