Autoconfiguring IPv6 Clients

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.