>IPv6 Deployment Scenarios Part 3: IPv6 client and NAT64

Posted by

>

In the IPv6 Deployment Scenarios series of articles we’ve been discussing the need for IPv6, issues with migrating to IPv6, and some strategies to use to get it up and running in your network.  This article continues where we left of with the dual-stack scenario. In this article we will be looking at using IPv6-only clients and make use of NAT64 to provide IPv4 connectivity for these clients.[1]

We will be using a piece of software called Ecdysis [2].  I downloaded the LiveCD, which runs a modified version of Fedora, and booted it up on a spare workstation with two NIC adapters.  Here is the basic network architecture being explored in this scenario:

The initial boot-up of Ecdysis didn’t show my NICs in the device configuration so I skipped it.  I logged in as root with no password and setup the following:

  • Outside global IPv6 address
    • ip addr add /126 eth0
  • Outside public IPv4 address
    • ip addr add /29 eth0
  • Set IPv4 and IPv6 default routes
    • ip route add default via dev eth0
    • ip route add default via dev eth0
  • DNS servers
    • edited /etc/resolv.conf and added in my local DNS servers
  • Inside global IPv6 address
    • ip addr add /64 eth1
Once I had these configured and I tested functionality using ping and ping6. I verified connectivity to ipv6.google.com and google.com. 
In the /root directory there is a script called magic-quick-start.sh that I used to start the service. There is also a nat64-config.sh that gets thing setup.  I ran nat64-config.sh and then magic-quick-start.sh. 
After that I configured my Windows 7 client with an IPv6 address and gateway. It didn’t appear the linux box was handing that information out.  I then specified the IPv6 address of the Linux box for the DNS server as well as the default gateway.  I could then access all of the v4 and v6 sites from a v6 only client.   It is quite impressive. The one down-side to this is that for v4 access we suffer the same issues that standard NAT has. Because we are sharing a single public address, port forwarding, running servers, and providing always-on two-way communication is difficult. 
Windows 7 running IPv6 only:
C:UsersAdministrator>ipconfig

Windows IP Configuration


Ethernet adapter Local Area Connection:

   Connection-specific DNS Suffix  . :
   IPv6 Address. . . . . . . . . . . : XXXX:YYYY:0:1e0::2
   Link-local IPv6 Address . . . . . : fe80::9d9e:7efe:7926:5ea2%11
   Default Gateway . . . . . . . . . : XXXX:YYYY:0:1e0::1
I verified connectivity by first pinging the ipv6 and ipv4 versions of the Google website:
C:UsersAdministrator>ping ipv6.google.com

Pinging ipv6.l.google.com [2001:4860:800b::68] with 32 bytes of data:
Reply from 2001:4860:800b::68: time=42ms
Reply from 2001:4860:800b::68: time=43ms
Reply from 2001:4860:800b::68: time=42ms
Reply from 2001:4860:800b::68: time=43ms

Ping statistics for 2001:4860:800b::68:
    Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
    Minimum = 42ms, Maximum = 43ms, Average = 42ms

C:UsersAdministrator>ping google.com

Pinging google.com [64:ff9b::4a7d:e113] with 32 bytes of data:
Reply from 64:ff9b::4a7d:e113: time=17ms
Reply from 64:ff9b::4a7d:e113: time=16ms
Reply from 64:ff9b::4a7d:e113: time=17ms
Reply from 64:ff9b::4a7d:e113: time=16ms

Ping statistics for 64:ff9b::4a7d:e113:
    Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
    Minimum = 16ms, Maximum = 17ms, Average = 16ms
The 64::ff9b::/96 network is reserved for the NAT64 process. When the IPv6 client makes a DNS request the NAT64/DNS64 box makes an upstream DNS request. If a AAAA record is returned it passes that response back down to the client.  If only a A record is returned it encapsulates the IPv4 address into the host portion of an IPv6 address using the 64.ff9b::/96 prefix.  If you notice the first ping is an IPv6 site (2001:4860:800b::68) and the second ping is for an IPv4 address (64:ff9b::4a7d:e113) because it starts with the 64:ff9b:: prefix. The 4a7d:e113 portion is the IPv4 address in hex format.
I then checked the results using whatismyv6.com:

The v6 address matched what was configured on my v6-only client and the v4 address matched what was configured on my NAT64 box for IPv4 translation.  It worked great and looks like a valid option for running IPv6-only clients and using a small pool of IPv4 addresses for v4 connectivity. 
In the next article I’ll be looking at some business models and IPv4 address conservation methods utilized with those models. 

References:
[1] http://www.networkworld.com/community/blog/testing-nat64-and-dns64
[2] http://ecdysis.viagenie.ca/index.html

Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s