Setting up an IPv6 Test Lab - June 22, 2007

With IPv6 enabled by default on all new operating systems, a colleague and I set out to learn a few things about this now ubiquitous protocol. We wanted to see how many of our network analysis tools and tricks are still useful, and we hoped to discover new tools to add to our arsenal.

Our test lab was comprised of a hub, two XP laptops, two Vista desktops, and an OpenBSD 4.1 laptop to act as a router. We posted the MAC address on each computer to help identify the machines, printed out an IPv6 PDF cheat sheet, and kept a copy of "Running IPv6" by Iljitsch van Beijnum handy.

To keep things simple, we started with all the machines connected to the same network and no router. We had to install IPv6 on the XP machines, although it was just a matter of typing "ipv6 install" on the command line and didn't even require a reboot. Any host-based firewalls were disabled, and a note was placed by the door to remind us to enable them before the machines left the test lab. All machines were set to get IPv4 addresses through DHCP, although no DHCP server was configured on the network. At this point, the "ipconfig /all" command showed that all the machines had assigned themselves a link-local IPv6 address, which begins with "fe80". Vista is unusual because the link-local address doesn't relate to the hardware MAC address, but instead uses a random identifier. Because of this, we also wrote the last four digits of the IPv6 address on the machines. There were also listings for Teredo IPv6-to-IPv4 Tunneling adapters on the windows machines, but we didn't plan to explore those on this day. The output from OpenBSD's "ifconfig" command also showed the expected link-local IPv6 address.

We tested basic connectivity by pinging the "all nodes link-local" multicast address:

	XP:       ping6 ff02::1
	OpenBSD:  ping6 ff02::1%xl0
	Vista:    ping ff02::1

Because the OpenBSD machine had more than one network interface, we had to specify the interface with the % symbol and interface name (xl0) after the address. Windows also supports using the % symbol to reference a specific interface (interface index), which can be found along with a wealth of additional information by using the "ipv6 if" command. Also, note that Vista has combined the IPv4 and IPv6 ping utilities. We had trouble getting responses from the Vista machines unless we had them ping first, which is something that should be further explored. Viewing the IPv6 neighbor discovery protocol table (similar to an IPv4 ARP table) can also help you track which machines are on the network.

	OpenBSD:  ndp -a
	Vista/XP: ipv6 nc

Now it was time to test some basic network analysis tools. The first tool that I wanted to test was the venerable tcpdump. Capturing IPv6 traffic was as simple as:

	OpenBSD:  tcpdump -e -n -i xl0 ip6

The "e" flag displays the Ethernet MAC address, "n" displays numbers instead of names which is important on a network without a DNS server, "i" specifies the interface, and "ip6" displays IPv6 packets. We also tried Ethereal (now Wireshark) on one of the XP laptops, which had no trouble capturing and displaying IPv6 traffic. Running "nmap -6" on OpenBSD against one of the XP machine's IPv6 address also worked as expected.

Vista's "Meeting Space" application relies on IPv6, so we used it to generate some traffic on the network. This was a great opportunity to play with this new application and generate something more than just pings. It basically uses SSDP and the FF02::C multicast address to talk to all meeting participants.

The next phase involved a router to test the ability of workstations to discover the network. OpenBSD is fairly simple to set up as an IPv6 router. The two network interfaces (url0 and xl0) were given fake global unicast addresses by putting a single line in the interface configuration files:

	/etc/hostname.url0: inet6 2001:aaaa::1 64
	/etc/hostname.xl0:  inet6 2001:bbbb::1 64

I then modified /etc/sysctl.conf and uncommented one line to enable ipv6 forwarding. I also needed to enable the router advertising daemon at boot so hosts could discover the router and the network prefix. In this network, I want the router to advertise on both network interfaces, and to provide extra debugging information. I appended the following file:

	/etc/rc.conf.local: rtadvd="-D url0 xl0"

We connected one of the XP machines directly to the url0 interface with a cross-over cable, and a second network was born. For good measure, the router and all the workstations were restarted.

Once all the machines came up, we logged in and checked the network interfaces. Vista notified us of a new network, asked us if it was public or private, and offered to lock down the network depending on our answer. We chose private to make the machines visible on the network. The windows machines had picked up two new IPv6 addresses, one of which was "temporary". Because of privacy concerns about tying the Ethernet MAC address to a global IPv6 address, hosts can use an additional random address that changes periodically for outbound requests. On a local network, hosts with random addresses raised some questions around logging and security.

Our first test was to ping the "all routers link-local" (ff02::2) address. We then pinged across the router, which involved typing long IPv6 addresses because we didn't have DNS set up, but everything seemed to work. Using tcpdump on the router let us observe the traffic as it passed.

Time was running out, so we gathered up our notes, re-enabled our firewalls, and took the test network apart. I'm looking forward to phase two: connecting a test network to the global IPv6 network through a tunnel-broker.