Lab report: Adventures with DHCP6 and Router Advertisments

Jan 062012

This Friday, I’m going to share the results of an IPv6 lab with a couple of friends. In Sweden we have a saying: “Don’t throw stones in a greenhouse”. If I encourage all readers to play with IPv6, I should do it myself. So we spent much more than 30 minutes on router advertisements and DHCPv6. We learned a lot. I am sure that if you spend 30 minutes on IPv6 every Friday you will learn a lot too.

The goal with our lab was to test address management in IPv6. We discovered a few smaller issues, some very irritating issues and read a lot of RFCs and manual pages. Doing this together with colleagues in other organizations, with different views and experiences on system and network management, really speeds up the learning process for all.

The lab setup

IPv6 connection – only – to an interface on a FreeBSD server . No IPv4 at all
RADvD server for router advertisments on FreeBSD server
ISC DHCP on FreeBSD server
Windows 7 and Apple OS/x Lion laptops

Tests

Configuring radvd server to deliver router and DNS address
Configuring radvd server to enable DHCPv6 address assignment and DNS configuration
Configuring radvd server to disable stateless configuration and force DHCPv6 only

IPv6 only? You must be crazy

When starting, we assigned static IPv6 addresses to all laptops to test the connection. To run only IPv6 was in itself an interesting test. On OS/X Lion you can disable IPv4, which is a good step forward. This disabled IPv4 on external interfaces, but the loopback interface (127.0.0.1) is still running IPv4. Propably because there’s a lot of stuff going on in the O/S that still relies on IPv4. On Windows it seemed like all of IPv4 was gone. We tried running virtual machines, but it seemed like Parallells in OS/X had issues with no IPv4 being active in the OS/X machine. We lost the network interface in the virtual machine totally.

We surfed a bit on the web in this environment, just out of curiosity. Very few of the sites that participated in the World IPv6 Day still had IPv6 enabled. Facebook has IPv6 support on https://www.v6.facebook.com/ . Many times Facebook looked like a web site from the early days of the web, since the CSS did not load properly and the web page was white with text and some blue underlined links. When the CSS loaded, a lot of the pictures was missing. Seems like the content delivery system did not provide an ALG between IPv6 and IPv4 for external pictures.

Web sites with dual stack support on the same URL seemed slow. The reason was that there was a lot of embedded objects that wasn’t reachable over IPv6 and these generated timeouts in the browser – but it took a while. We noticed a Twitter widget fail miserably. Web designers really need to test with IPv6 only clients to make sure that the web site experience is similar or at least not degraded by timeouts. While servers will remain dual stack for a long time, I believe that clients are the first ones to be single stack again, but this time with IPv6 only. Or dual stack with a lousy IPv4 connection over multiple NATs.

Router Advertisments and DNS servers

In an earlier article we described how a device gets a routable IPv6 address in addition to the link-local address (FE80::). One option is to manually configure all addresses. The other is to use automatic configuration, supported by the network. Automatic configuration starts with router advertisements, RA. The original RA standard includes sending out the router address (or a set of routers) and a few flags. DNS was not included. Support for DNS was added later, but our guess was that the original authors of the specifications considered using the multicast address for DNS servers.

Observation: Windows 7 will assign multicast address DNS servers if it doesn’t get DNS server addresses by other means. OS/X did not.
We did not test if we could get a DNS server to listen to the multicast DNS address.
No operating system seemed to support getting DNS server configuration in router advertisements. The RADVD server did support sending it.

Router Advertisment with the managed flag

The M flag in the router advertisment indicates that a network is managed and should get DHCPv6 address assignments. Both OS/X Lion and Windows 7 supports this, but keeps the auto-assigned address. In this configuration, you will end up with the link local and multiple global addresses. By turning on the AdvAutonomous flag in radvd.conf we managed to turn off the automatically configured addresses and only use link-local and DHCPv6 assigned addresses.

The O flag in router advertisments indicates that the host has additional data to fetch from DHCP. Regardless if the IPv6 address is automatically configured or managed via DHCPv6, the client has to run DHCPv6 to get other pieces of information – like DNS servers, SIP configuration options, TFTP address or application specific data. All our clients supported this – at least for DNS.

Windows 7 with multiple interfaces

One Windows 7 laptop was connected to a 3G network, running an OpenVPN connection with IPv4 and IPv6 during some tests. While that connection was open, this system did not send any DHCPv6 requests on the interface that the router indicated should be managed by DHCPv6. When we removed the USB dongle (and the extra interface), everything worked perfectly. Our feeling was that the system could only run DHCPv6 on one interface. This needs further tests.

Where can we find the DUID and the IAID?

We sneaked out of the lab to take a look at the Microsoft Windows DHCP server support for IPv6 and discussed how to assign an address to a specific computer, not just taking an address from a pool. The DHCP server need the DUID and IAID to be able to do this.

The question is where to find this information. You can let the computer run DHCP and the Windows server will give you the data after the assignment is done. But if you want to assign addresses before the systems connect to the network, you are in trouble.

Observations:

After – but not before – the Windows 7 client has an IPv6 address it will show you the DUID and the IAID for each interface.
The Linux DHCPv6 server showed a very strange piece of data that is not easy to relate to the DUID and IAID for the host in the dhcp leases file. This is not good.
In OS/X, we could not figure out how to find the DUID and IAID used in DHCPv6. Surely Apple doesn’t want to force admins to use Wireshark to find out?

Björn, the sysadm on the site, told us that when enabling DHCPv6 on the production network there was a lot of warnings on screens about duplicate IPv6 addresses. The reason for this turned out to be that PCs are installed by distributing ghost images of a master system. Every system had the same DUID and got the same IPv6 assignment. The DUID is in the Windows Registry and can be removed with a manual operation. This should be done before creating a ghost image, so that when the copies are booted on new machines, new and unique DUIDs will be created. We hope that there are tools that can do this automatically in a network.

reg delete HKLM\SYSTEM\CurrentControlSet\Services\Tcpip6\Parameters /f /v Dhcpv6DUID

Executive summary:

In this lab, we tested various methods to assign and manage IPv6 addresses for two common operating systems – Microsoft Windows 7 and Apple OS/X Lion. Both systems supported various combinations of stateless and stateful address assignments. We tested with a FreeBSD server, but not with a Windows server. We can’t say it was easy to get everything to work, we had to read a lot of documentation and discuss many things before we got it right. The IPv6 documentation was not always accessible over IPv6, so we had to have systems with IPv4 to use to access the Internet.

That’s all for this week. We will continue our labs and hope that we inspire you to spend some time with IPv6 too. Please share your lab results – and try to make them accessible over IPv6!