IPv6 Router: Setting NAT64 & DNS64

In this post, I will try to explain how to setup NAT64 & DNS64 in order to enable an IPv6 LAN (no IPv4 enabled) to talk to a mixed IPv4 en IPv6 Internet. It is assumed that there are no IPv4 hosts left in the LAN. In the setup there is one gateway for both native IPv6 traffic and translated (NAT64) IPv4 traffic. This gateway is also the DNS64 server.

Operating system and packages

The setup was built using Ubuntu 10.04 server, using the following packages:

• Router Advertisements: RADVD (available via ubuntu package manager)
• DNS64: TOTD (available via ubuntu package manager)
• NAT64: TAYGA (available here as a package)
• DHCPv6: WIDE-DHCPV6-SERVER (available via ubuntu package manager)

Interfaces & prefixes

The following interfaces & prefixes were used (replace values by your own where needed):

• Assigned IPv6 subnet: 4000:0:0::/48
• LAN IPv6 subnet : 4000:0:0:1::/64
• LAN interface: eth4
• IPv4 Internet interface: eth0
• NAT64 tunnel interface: nat64
• 6to4 NAT range: 4000:0:0:2:EEEE::/96 (should be within your own subnet)
• GW IP: 4000:0:0:1::1/64
• An Internet based DNS server with IP 99.99.99.99

RADVD & DHCPv6 configuration

RADVD will take care of sending Router Advertisements to the clients, enabling SLAAC (Stateless Address Auto-configuration). Is should be configured like this (/etc/radvd.conf):

interface eth4
{
    AdvSendAdvert on;
    AdvManagedFlag off;     //stateless autoconfiguration
    AdvOtherConfigFlag on;  //clients get extra parameters via DHCPv6
    MaxRtrAdvInterval 10;   //resend RA @ random times, max 10sec delay
    prefix 4000:0:0:1::/64  //announce prefix to clients
    {
        AdvOnLink on;
        AdvAutonomous on;
    };
    RDNSS 4000:0:0:1::1
    {
    };
};

While the RDNSS messages are sufficient for some operating systems like iOS and Linux (with extra rdnssd packages), others need their DNS via DHCPv6 (such as Windows 7). Mac OS X doesn’t listen to any of them and needs a manual DNS configuration. The DHCPv6 configuration is rather simple. Put the following line in /etc/wide-dhcpv6/dhcp6s.conf:

option domain-name-servers 4000:0:0:1::1;

DNS64: TOTD

The TOTD package is a DNS64 + forwarding daemon (it doesn’t handle DNS itself):

• If an AAAA request is made for a hostname that has AAAA records, the original AAAA record is returned
• If an AAAA request is made for a hostname that only has an A record, TOTD will translate the original A record (holding an IPv4 address) into an IPv6 record, using the prefix configured in its configuration file (/etc/totd.conf) :

forwarder 99.99.99.99 port 53   //forward DNS requests to this server
prefix 4000:0:0:2:EEEE::        //this prefix is used for translation
port 53

NAT64: TAYGA

Package TAYGA akan menangani proses NAT64. Jika DNS64 memberikan address ke client, dia akan menyambungkan diri dengan IPv6 address melalui default GW. The GW itself sends the package to his nat64 tunnel interface which is managed by the TAYGA daemon. The daemon creates a mapping between the IPv6 address of the client computer and an IPv4 address of the private address range, as configured. As a last step, the IPv6 address as returned by DNS64 is translated back to the original IPv4 address and sent out to the Internet, using normal NAT44.

This is how it’s configured: Create the following configuration file (/etc/tayga.conf):

tun-device nat64              //name of the NAT64 tunnel device
ipv4-addr 172.16.254.1        //IP address of the remote tunnel endpoint
prefix 4000:0:0:2:EEEE::/96   //IPv6 prefix of translated IPv4 addresses
dynamic-pool 172.16.254.0/24  //pool for mapping IPv6 client <-> IPv4

Next, let TAYGA create the tunnel device and add the necessary IP addresses & routes:

tayga --mktun                               //create tunnel devices
ip link set nat64 up
ip addr add 172.16.0.1 dev nat64            //local endpoint of the tunnel
ip addr add 4000:0:0:1::1 dev nat64         //same IP as GW
ip route add 172.16.254.0/24 dev nat64      //send through tunnel
ip route add 4000:0:0:2:EEEE::/96 dev nat64 //send through tunnel
tayga -d

(or use /etc/init.d/tayga start – the -d option gives some debugging information)

The translated (IPv4) packets will be sent to the default GW for IPv4 connectivity. The only thing left is to translate the source address (the local IPv4 endpoint address of the nat64 tunnel) to the public IPv4 address of your internet interface. This is done with IPTABLES:

iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE
iptables -A FORWARD -i eth0 -o nat64
                    -m state --state RELATED,ESTABLISHED -j ACCEPT
iptables -A FORWARD -i nat64 -o eth0 -j ACCEPT

IP Forwarding

If you haven’t done so already, turn on IP forwarding on the gateway:

echo 1 > /proc/sys/net/ipv4/conf/all/forwarding
echo 1 > /proc/sys/net/ipv6/conf/all/forwarding

(can also be done via sysctl commands etc…)

Debugging

• To check if the DNS64 is working correctly, try doing some nslookup’s (or dig). Hostnames that normally do not return an AAAA record should now return a “fake” one with a value within the configured range. If that’s not happening, first check your /etc/resolv.conf on your local machine to see if it points to the correct server
• NAT64 problems can be checked by running tcpdump on your gateway, especially on the nat64 tunnel interface

Referensi

• http://www.bitprocessor.be/2011/05/31/setting-up-nat64-dns64/