The network at ARIN XXI was a bit more complex than a typical ARIN meeting network. In order to facilitate the IPv6 event we designed what amounts to three separate networks for ARIN XXI. These networks had three separate SSIDs: ARINXXI, ARINXXI-V6 and ARINXXI-V6-XP. The following diagram gives a view of the network topology.
IPv6 transit on each network was provided by tunnels back to the ARIN offices in Virginia where we have IPv6 transit through OCCAID via the Equinix IPv6IX. The following diagram depicts the IPv6 tunnel configuration.
ARINXXI: The primary network supported both IPv4 and IPv6. IPv4 addresses and DNS servers were assigned via DHCPv4 while IPv6 addresses were assigned using RA. IPv4 address space and transit was provided by our sponsor, Wild Blue. IPv6 address space and transit was provided by a tunnel back to the ARIN offices. This machine did not have any special configuration. It was set up as a Linux based router with radvd providing IPv6 addresses advertisements to clients and BIND 9 providing DNS services. The IPv6 tunnel and routing were handled using standard Linux mechanisms.
IPv4 and IPv6 packet forwarding were enabled:
The IPv6 Tunnel was setup:
You also need to assign an IPv6 address to the internal Ethernet Interface:
Bind was setup as a recursive name server listening on both IPv4 and IPv6.
ARINXX-V6: The ARINXXX-V6 network was configured to support only IPv6 on the local network segment (No IPv4 for clients at all). This network provided connectivity to the IPv4 Internet by using NAT-PT and the TOTd DNS gateway. The IPv6 transit and address space for this network was provided by a tunnel to the ARIN offices. The IPv4 transit which was required for NAT-PT was provided by the meeting sponsor. We used a Linux box as the gateway device for this network. DHCPv6 services were used to provide clients which supported DHCPv6 a DNS server. Those clients that did not support DHCPv6 were required to configured their DNS server manually. The Linux box ran an implementation of NAT-PT which is available from http://www.lucastomicki.net/naptd.php]. The Linux machine also ran a DNS application layer gateway (DNS ALG) named TOTd, or Trick or Treat Daemon. The TOTd application is basically a DNS proxy that provides a NAT-PT compatible AAAA record for hosts that do not return a valid AAAA record when a DNS query is performed. This allows the NAT-PT daemon to provide the translation necessary to connect to an IPv4 only resource from an IPv6 only client. While the basic configuration of this Linux gateway was pretty standard things get a bit complicated when using the naptd daemon. The following configuration details will hopefully help you along if you would like to set this up yourself.
IPv6 packet forwarding must be enabled:
The IPv6 Tunnel was setup (You will need to have you own tunnel endpoint to define in line two):
and an IPv6 address was assigned to the internal Ethernet Interface:
We found that radvd had to be up and running in order for DHCPv6 to work properly. It appeared the ISC dhcpd (4.1.0a1) wanted to see an RA before it would do its thing.
dhcpd was also started with the following command line options:
The DNS ALG (TOTd) was configured as follows:
The nat-pt application does not use text based configuration files. It provides a tool that generates a binary configuration file. What follows is a log of the answers we supplied to the configuration generator for our network. We tried a lot of the different setups in our lab and we found the the only setup the worked reliably was a very basic configuration (we accepted the defaults).
Several iptables rules are required to make the NAT-PT daemon work properly. This is because the daemon is running in use ... \n