View source for 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. GW akan mengirim paket ke nat64 tunnel interface yang di managed oleh TAYGA daemon. TAYGA daemon akan membuat mapping antara IPv6 address dari client computer dan IPv4 address dari private address range, seperti yang kita konfigurasikan. Akhirnya, IPv6 address yang dikembalikan oleh DNS64 akan di terjemahkan kembali ke IPv4 address original dan dikirim ke Internet, menggunakan NAT44 normal.

Cara mengkonfigurasi tayga, pertama kali buat file konfigurasi(/etc/tayga.conf), misalnya

 vi /et/tayga.conf

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

Selanjutnya, perintahkan TAYGA untuk membuat tunnel device fan tambahkan IP address & routes yang dibutuhkan:

 tayga --mktun                               //buat tunnel devices
 ip link set nat64 up
 ip addr add 172.16.0.1 dev nat64            //local endpoint dari tunnel
 ip addr add 4000:0:0:1::1 dev nat64         //sama dengan IP GW
 ip route add 172.16.254.0/24 dev nat64      //kirim melalui tunnel
 ip route add 4000:0:0:2:EEEE::/96 dev nat64 //kirim melalui tunnel
 tayga -d

(atau gunakan /etc/init.d/tayga start - opsi -d memberikan informasi debugging)

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/