IPv6 Router: Setting NAT64 & DNS64

From OnnoWiki
Jump to navigation Jump to search

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