Paul Hoffman
Last updated 2008-03-20
A few months ago, the IETF announced that there would be an experiment in running an IPv6-only network for part of the 71st IETF meeting. One objective was to see how well IETF services were available in such an environment. IMC and VPNC, two organizations that I run, host some mailing lists and mailing list archives for the IETF (as do many other organizations). Thus, it seemed appropriate for me to try to get these servers to work in a pure IPv6 environment for the test.
This quick-and-dirty guide describes how I set up the server. Big thanks go to Iljitsch van Beijnum and Bill Fenner for hand-holding during the process. All errors and bad advice herein are my fault, not theirs. Please send any comments or suggestions to Paul Hoffman <paul.hoffman@vpnc.org>.
I asked my ISP Opus One, if they have IPv6 addresses for the systems colocated in their facility. The answer was "no, why do you ask", so I told them about the IETF experiment. Opus One was happy to participate if they could get IPv6 transit from their upstream provider.
After some initial failures by Opus One finding someone at the upstream who knew how to sell them IPv6 space, we called on a few IETFers who might know someone there who could help. We got a few names, and tried again. We got a few steps forward, but never far enough for that provider to get Opus One any addresses, even after a few months.
On the advice of I looked into getting a IPv6 tunnel, and ended up getting one from SixXS. They offer free IPv6 tunnels in three modes, depending on the type of system that needs the IPv6 address. Given that these are servers with a set of fixed IP addresses, I chose a static tunnel. After a few easy rounds of web sign-up, I had a tunnel with a /64 assigned to me.
The specifics of this step, of course, depends on both the OS you are running and the method you use for getting IPv6 service. As described above, I am running on FreeBSD 6.0, and I got a static IPv6 address from a tunnel broker through SixXS. The configuration here is probably valid for other versions of FreeBSD and other types of tunnels, but don't follow this section blindly.
After giving a few CLI commands, I was able to test the setup with ping6 and then lynx to an IPv6 address. I added the followng to /etc/rc.conf:
gif_interfaces="gif0" gifconfig_gif0="<myIPv4> <theirIPv4>" ipv6_ifconfig_gif0="<myIPv6> prefixlen 64" ipv6_defaultrouter="<theirIPv6>" ipv6_enable="YES"A reboot proved that this was, in fact, the right incantation for the system.
The system uses Sendmail for SMTP service and Apache 2.2 for web service. Both were fairly easy to configure for IPv6.
To tell Sendmail that I wanted it to watch both IPv4 and IPv6, I edited the .mc configuration file. It started with:
DAEMON_OPTIONS(`Port=smtp, Name=MTA25-v4, Family=inet')I added:
DAEMON_OPTIONS(`Port=smtp, Name=MTA25-v6, Family=inet6') define(`confBIND_OPTS', `WorkAroundBrokenAAAA')Note that Sendmail needs to be built to handle IPv6; not all default builds have that option turned on. For example, the default port building in FreeBSD didn't have IPv6 turned on, but it was simple to rebuild Sendmail with this.
There are (unfortunately) many ways to tell Apache what address and port to listen to for HTTP service. My server uses one of its many addresses for web service, so I had the following in my http.conf file:
NameVirtualHost <myIPv4> Listen <myIPv4>:80I added (including the square brackets):
NameVirtualHost [<myIPv6>] Listen [<myIPv6>]:80
Because I want to be able to control the system in the IPv6-only environment, I made sshd also look on the IPv6 address for connections.
One step that is often overlooked in making servers available on an IPv6-only network is being sure that the DNS nameserver is authoritative for you. I run my own nameserver, so this should have been easy: just add that address to the WHOIS information for the nameserver.
It turns out that doing that is not possible for most registrars, including mine, GoDaddy. (To GoDaddy's credit, their phone support person quickly understood what I wanted, did an informal escalation in order to find out that they couldn't even do what I wanted by hand, and told me where the most effective place for me to send the suggestion that they make this possible.)
Following the advice here, I bought a new domain name, ipv6secondary.net, from GKG.net (whom I had used earlier to register the test IDN éxample.com). They had no problem with me having both an IPv4 and IPv6 address for the new domain name.
Adding the IPv6 address to the "listen-to" command in BIND should have been direct, but it wasn't. My first attempt was to add the following to my named.conf file:
listen-on { 127.0.0.1; <myIPv4>; <myIPv6>; };
I rebooted named, and no error was reported, so I assumed I had done this
correctly. Unfortunately, BIND 9.3.4-P1 (and probably other versions)
silently ignore this error. Later, I discovered that the correct
incantation is:
listen-on { 127.0.0.1; <myIPv4>; };
listen-on-v6 { <myIPv6>; };
I was not able to really test whether or not this would work until I got on the IETF's IPv6 only network. Although I got another tunnel from SixXS for my Windows system, I could not figure out how to make that system turn off IPv4 for anything other than the tunnel. I also could not figure out how to do the same for the Mac, so I didn't even try.
On Sunday at the IETF, I was not able to get to my system on the IPv6-only network, even though I could see in the logs that the system was being hit from other places in the IPv6 network. I reported this to the NOC, and they found that there was a routing issue in the SixXS network that affected the IETF's routes, but not all routes. The issue was fixed by the end of the Sunday reception.