Prolixium dot com: News >> Blog >> IPv6 NAT+PAT on GNU/Linux

Let the flogging begin! Yep, I'm using IPv6 NAT+PAT on GNU/Linux.

Sure, for awhile it's been possible to do this in other operating systems (Junos, ScreenOS, IOS, FreeBSD, OpenBSD, etc.).. but not GNU/Linux.

The ip6tables MASQUERADE target was introduced in kernel 3.7 as ip6t_MASQUERADE.ko. Since I have a setup at home that involves using a Verizon Wireless LTE USB stick for backup Internet access (see this and this on the struggles I had to undertake to get it to work with GNU/Linux), this is a requirement for me if I want my IPv6 Internet traffic to use the connection as well. Verizon Wireless has supported native IPv6 on their LTE network since it launched, back in December of 2010.

I had to roll a vanilla kernel from kernel.org and use the deb-pkg target since the latest kernel in Debian is based on 3.2. I also had to grab iptables 1.4.17, build it, and install it from scratch, too. The three configuration options I enabled in the kernel were the following:

CONFIG_NF_NAT_IPV6=m
CONFIG_IP6_NF_TARGET_MASQUERADE=m
CONFIG_IP6_NF_TARGET_NPT=m

I'm not using NPTv6, yet, but I might try that out in the future. Once built and installed, I added the following familiar line to my iptables configuration script to enable MASQUERADE functionality for IPv6 on the upstream interface:

ip6tables -t nat -A POSTROUTING -s $VOXELV6 -o $EXT -j MASQUERADE

Since my internal network is numbered out of my IPv6 block from Voxel dot net (now Internap) that is usually tunneled to a server I have with them, $VOXELV6 is defined as 2001:48c8:1:100::/56. $EXT is wwan0, which is the USB stick. A very simplified diagram of this setup is shown below:

IPv6 Setup

Normally, IPv6 traffic flows through the tunnel between starfire and dax. When the Road Runner connection fails or is otherwise manually depreferenced on starfire (this will also bring down the OpenVPN tunnel to dax), IBGP moves IPv4 and IPv6 connectivity over to evolution where formerly only IPv4 NAT took place.

Now, both IPv4 and IPv6 NAT+PAT is done on evolution. It works fairly well:

(evolution:17:44)% sudo ip6tables -t nat -S POSTROUTING    
-P POSTROUTING ACCEPT
-A POSTROUTING -s 2001:48c8:1:100::/56 -o wwan0 -j MASQUERADE

(destiny:17:30)% mtr --report --report-cycles=32 -w 2001:4860:4860::8888 
HOST: destiny                            Loss%   Snt   Last   Avg  Best  Wrst StDev
  1.|-- et3.starfire.prolixium.net          0.0%    32    0.2   0.3   0.2   0.4   0.0
  2.|-- et0.evolution.prolixium.net         0.0%    32    0.5   0.5   0.5   0.6   0.0
  3.|-- 2600:1004:b01d:66b7:0:4a:d1a7:7f40  0.0%    32   34.7  44.7  32.1  68.8   8.0
  4.|-- 2001:4888:0:1000:201:200::          0.0%    32   49.0  45.3  31.4 100.3  12.5
  5.|-- 2001:4888:20:2010:201:25::          0.0%    32   83.2  47.3  32.9  83.2  12.5
  6.|-- 2001:4888:20:2000:201:1:0:1         3.1%    32   56.9  47.1  36.1  62.7   6.6
  7.|-- 2001:4888:20:1002:201:24::          0.0%    32   52.5  43.9  32.1  61.8   8.2
  8.|-- 2600:804:21f::1                     0.0%    32   52.9  56.5  40.7  82.0   9.1
  9.|-- Loopback0.GW1.MIA19.ALTER.NET       0.0%    32   62.1  75.5  54.9 137.5  18.4
 10.|-- 2600:804:80f::a                     0.0%    32  115.0 123.5 108.4 159.1  12.0
 11.|-- 2001:4860::1:0:245c                 0.0%    32   80.3  80.3  62.1 159.9  21.0
 12.|-- 2001:4860::8:0:464f                 0.0%    32   75.5  87.9  65.1 160.6  18.6
 13.|-- 2001:4860::2:0:a7                   0.0%    32   99.7  84.7  69.5 126.2  13.0
 14.|-- ???                                100.0    32    0.0   0.0   0.0   0.0   0.0
 15.|-- google-public-dns-a.google.com      3.1%    32   94.0  84.1  71.6 102.7   8.2

It's been stable for about an hour, now, so that's good enough for me. Since I'm not using a tunnel with this connection, I can also get a full 1500 byte MTU:

(destiny:18:23)% ping6 -c 4 -M do -s 1452 he.net.     
PING he.net.(he.net) 1452 data bytes
1460 bytes from he.net: icmp_seq=1 ttl=54 time=140 ms
1460 bytes from he.net: icmp_seq=2 ttl=54 time=167 ms
1460 bytes from he.net: icmp_seq=3 ttl=54 time=136 ms
1460 bytes from he.net: icmp_seq=4 ttl=54 time=134 ms

--- he.net. ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3003ms
rtt min/avg/max/mdev = 134.451/144.745/167.546/13.340 ms

So, what about the flogging? That's because lots of people will say this is the wrong way of doing things. They say I should call up Verizon Wireless and petition them to support DHCPv6-PD, in addition to the 3GPP-mandated /64 assigned to the cellular interface (see section 1.5.3 of RFC 3314). They also say NAT is evil.

Sure, I could do that, but it won't help me now. Even though NAT does suck in general, I say IPv6 NAT+PAT works fine in certain circumstances like this. It's just a tool, it can be used for good and as well as evil. To be honest, I don't find NAT or this use of it inherently evil.

If you want, read some of my other blog entries on the topic of IPv6 NAT+PAT.