One of the primary goals of humanity is not to repeat the same mistakes made in the past. The desire is to “fail forward” frequently in different ways on the path to continual improvement. When it comes to IPv6, the protocol designers wanted to avoid repeating the mistakes of IPv4; specifically, its limited address space that necessitates Network Address Translation (NAT). IPv6’s 128-bit addresses ensure that the address space is large enough to provide unique addressing to every network and avoid any potential address overlaps.
IPv6 advocates have extolled the benefits of restoring the end-to-end model of communication originally conceived of by the early IPv4 protocol designers. IPv6 evangelists have also cautioned against using NAT with IPv6. However, many network and security architects are comfortable with the concept of NAT and may wonder why NAT doesn’t exist for IPv6.
Resisting the Urge to NAT IPv6
For decades, IPv6 purists have fought against establishing a standard for IPv6 NAT (e.g., IPv6 to IPv6 Network Address Translation or NAT66). Today, there isn’t even a pending draft of NAT66, much less a published IETF RFC. In addition, there is an IETF RFC titled “Local Network Protection for IPv6” (RFC 4864) that lists all the reasons why NAT is not needed for IPv6.
The primary argument against NAT66 is that IPv6 has plentiful address space that is globally unique, so the need for more address space is not an issue. There is no need for Port Address Translation (PAT) (a.k.a. NAPT/one-to-many NAT/masquerading) functionality in IPv6 to extend the address space or avoid address conflicts.
Another argument against NAT66 is aimed at security architects that conflate the stateful packet filtering performed by firewalls with IPv4 NAT functionality. Stateful packet filtering can provide the same level of security for IPv6 as it does for IPv4, just without the NAT function. It is a myth that “No IPv6 NAT Means Less Security.”
We are well aware of how NAT adds complexity for IPv4 networks. NAT ends up making IPv4 addresses “locally significant” as address overlaps are commonplace. NAT can cause problems for applications that require end-to-end native connectivity and embed addresses inside the protocol payload (e.g., FTP, IPsec, SIP, RTSP, SAP, SCTP, DCCP, etc.). Other protocols, like HTTP and HTTPS, are designed to tolerate NATs along the traffic path.
IPv6 native connectivity can exist between nodes on both private networks behind firewalls as well as across the Internet. NAT can be avoided in IPv6 networks and NAT is not needed or recommended.
Network Prefix Translation for IPv6 (NPTv6)
There actually were early IETF drafts for IPv6-to-IPv6 Network Address Translation (NAT66) put forth for consideration, but the decisions were to not repeat the IPv4 NAT mistake. What the IETF eventually agreed upon was something called “IPv6-to-IPv6 Network Prefix Translation” (RFC 6296). Note the subtlety in the RFC title where the word “Prefix” takes the place of the word “Address”.
Instead of performing a stateful NAT66 function, NPTv6 statelessly translates source address from one prefix to another prefix. This is a 1:1 mapping of the source address to the destination, and back again. NPTv6 simply copies the low-order part of the IPv6 address in packets traversing its two interfaces, while the rest of high-order part of the IPv6 address remains. Below is a picture that shows the part of the IPv6 address that is translated and the part that is copied.
The diagram above shows use of fd00::/8 IPv6 Unique Local Addresses (ULA) (RFC 4193). This type of a scenario is often shown as a method for small-medium sized businesses (SMBs) to avoid vendor lock-in if their one ISP furnishes them with Provider Assigned (PA) IPv6 addresses. For larger enterprises, it is recommended to use global unicast IPv6 addresses without NAT, rather than to use ULA IPv6 addresses with NAT. Furthermore, using ULA IPv6 addresses is frequently discouraged.
There are some network and security devices that now support NPTv6. Following are the vendors and their products that my research has discovered (but there could be others).
- You can configure NPTv6 on a router running VyOS.
- Palo Alto Networks firewalls running PAN-OS support NPTv6, but they can’t do NAT66.
- NPTv6 is supported on various Cisco routers (ASR1k/CSR1k/ISR4k) running IOS-XE.
- Juniper routers running Junos can perform NPTv6.
- A10 Networks devices can perform NPTv6.
- OPNsense firewall and routing software can do NPTv6.
- pfSense firewalls run what they call NPt.
NAT66 Can Be Useful
It is frequently recommended to follow the same operational model and processes that an organization uses for IPv4 for their IPv6 deployment. Since most organizations are familiar and comfortable with IPv4 NAT (a.k.a. NAT44), they can’t be blamed for wanting to have that same functionality in their IPv6 implementation.
In reality, NAT66 can be beneficial is some circumstances. For example, NAT66 could be used when there is a desire to maintain routing symmetry, similar to how NAT44 is being used in a network today. There could be a situation when an organization has a “pool” of clustered redundant firewalls (or middle-boxes) and IPv4 NAT is used to help maintain state. Some extremely large organizations may have large firewall “farms” and it may be undetermined which firewall the traffic goes through. The NAT44 functionality ensures that the return traffic comes back through the firewall that was used to forward the traffic, thus maintaining state and routing symmetry.
With IPv6 and global addresses, and no NAT, the traffic could leave one firewall and come back to a different firewall because NAT66 isn’t being performed. In this situation the IPv6 traffic may not work well during a firewall failure scenario, or traffic could be asymmetric. If NAT66 was a configurable option, then the same highly available network firewall architecture would allow for congruent traffic paths for IPv4 and IPv6.
Many smaller organizations, like SMBs, don’t use the Border Gateway Protocol (BGP) routing protocol with an Autonomous System Number (ASN) and only have a single ISP. As we mentioned earlier, if the Regional Internet Registry’s (RIR’s) policies won’t provide them a Provider Independent (PI) IPv6 address block, or their ISP won’t route a PI block for them, then the SMB would experience vendor lock-in using the ISP’s Provider Assigned (PA) IPv6 address space. Some SMBs use dual ISP links for redundancy (one primary, one backup) and they have one default route advertised internally by the primary firewall, and a second backup default route advertised by the secondary firewall. They use NAT44 to keep the returning traffic coming back to the stateful NAT44 device that allowed the originating outbound connection. If the primary firewall fails, the secondary firewall takes over and connectivity is maintained. You can see why an SMB may want to have NAT66 in a situation like this.
It is still possible to use traditional stateful proxies and Application Layer Gateways (ALGs) to broker connections from one IPv6 network to another IPv6 network. It should also be mentioned that outbound web proxies (like web content filters, a.k.a. Secure Web Gateways (SWGs)) and inbound reverse proxies (like server load balancers) perform a NAT-like behavior. These systems aren’t performing a NAT66 function, per se. They are actually terminating the TCP connection on one interface and establishing a new TCP connection using the other interface. This has the effect of changing the source address as the connection is made through the proxy.
NAT66 Exists
Contrary to popular belief, there are ways to perform NAT with IPv6, and vendors have implemented NAT66 into their products – even touting NAT66 on their product data sheets. Even though the IPv6 purists cringe when NAT66 is mentioned, and the IETF has not formally created an RFC to define how it should function, implementations of NAT66 still exist.
These vendors have implemented NAT66 in their products without there being a formal standard to guide their code development to ensure interoperability. The concern here is that each vendor’s products may not behave the same and that there could be resulting interoperability issues.
It should also be mentioned that the IETF has laid some groundwork for NAT66. The Port Control Protocol (PCP) (RFC 6887) specification does allow for an IPv6 host to learn how NAT is performed. PCP can also be used to share the NAT64 PREF64 with IPv6-only nodes so they can use DNS64/NAT64 to reach IPv4-only services (RFC 7225). There is even a DHCPv4 and DHCPv6 option for PCP (RFC 7291).
Here is a list of the various systems that support NAT66 and how to configure them.
- Fortinet FortiGate firewalls support NAT66 along with NAT64 and NAT46.
- Cisco ASA firewalls also support NAT66
- NAT66 is configurable on Juniper Junos routers.
- Juniper SRX firewalls also support IPv6 source NAT.
- NAT66 is configurable on an F5 BIG-IP (LTM) system.
- Check Point firewalls running R76 or newer support NAT66.
- NAT66 is supported on OpenWrt.
- NAT66 works on a H3C SecPath Firewall (command ref and config guide).
- NAT66 can be configured on a SonicWall.
Configuring NAT66 with ip6tables
One of the easiest ways to configure NAT66 is using a Linux system running netfilter (ip6tables). On Linux systems, ip6tables has supported NAT since version 1.4.18. There are some useful examples (by Marco Cilloni and Jeff Loughridge) of how to configure NAT66 with ip6tables.
To start, simply configure the system with IPv6-enabled interfaces and verify IPv6 network reachability. Configure an IPv6 default route (::/0) toward the outside interface and internal IPv6 routes as necessary.
Next, enable IPv6 forwarding in the kernel using this command.
sysctl -w net.ipv6.conf.all.forwarding=1
And, to make IPv6 forwarding permanent, uncomment this line in the /etc/sysctl.conf file.
vi /etc/sysctl.conf
net.ipv6.conf.all.forwarding=1
The next step is to configure ip6tables to perform a “masquerade” function, just like is commonly performed with iptables.
ip6tables -t nat -A POSTROUTING -o $OUTSIDE -j MASQUERADE
ip6tables -A FORWARD -i $OUTSIDE -o $INSIDE -m state –state RELATED,ESTABLISHED -j ACCEPT
ip6tables -A FORWARD -i $INSIDE -o $OUTSIDE -j ACCEPT
Now we can check the ip6tables configuration and look at connections passing through this system with the following commands.
ip6tables -S -t nat
ip6tables -t nat -nvL
conntrack -f ipv6 –L
Voila! NAT66.
Summary
Organizations that currently have symmetric routing with IPv4 NAT may want the same functionality in IPv6 with NAT66. IPv6 purists would do well to remember Aesop’s fable about the oak and the reed: It may be better to bend and allow NAT66, rather than be steadfast and break in resisting the goals and desires of numerous network operators who feel their working lives will be made easier with NAT66.
Whether we wanted NAT66 or not, we already have it. Vendors have gone ahead and implemented NAT66 in the absence of a standard method for this functionality. The IETF can either standardize NAT66 or we must be content with a world where there are numerous different implementations of NAT66.
But should you deploy NAT66? While it is important to acknowledge its existence, it should be re-iterated that using global IPv6 addresses without NAT is still the recommended approach. NAT66 really isn’t needed, except in some rare corner cases, and should be avoided where at all possible. But it is important to admit… that NAT66 does exist.
