{"id":7358,"date":"2021-12-28T14:34:55","date_gmt":"2021-12-28T22:34:55","guid":{"rendered":"https:\/\/blogs.infoblox.com\/?p=7358"},"modified":"2025-04-02T12:03:35","modified_gmt":"2025-04-02T19:03:35","slug":"you-thought-there-was-no-nat-for-ipv6-but-nat-still-exists","status":"publish","type":"post","link":"https:\/\/www.infoblox.com\/blog\/ipv6-coe\/you-thought-there-was-no-nat-for-ipv6-but-nat-still-exists\/","title":{"rendered":"You Thought There Was No NAT for IPv6, But NAT Still Exists"},"content":{"rendered":"

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. Achieving IPV6 Readiness<\/strong><\/a> is a critical step for organizations seeking to modernize their networks and avoid the pitfalls of legacy protocols. 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<\/a> (NAT). IPv6\u2019s 128-bit addresses ensure that the address space is large enough to provide unique addressing to every network and avoid any potential address overlaps, solidifying IPV6<\/strong><\/a> as the future of networking.<\/p>\n

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.<\/p>\n

Resisting the Urge to NAT IPv6<\/h3>\n

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<\/a>) that lists all the reasons why NAT is not needed for IPv6.<\/p>\n

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<\/a> (PAT) (a.k.a. NAPT\/one-to-many NAT\/masquerading) functionality in IPv6 to extend the address space or avoid address conflicts.<\/p>\n

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.<\/a>\u201d<\/p>\n

We are well aware of how NAT adds complexity for IPv4 networks. NAT ends up making IPv4 addresses “locally significant”<\/a> 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.<\/p>\n

IPv6 native connectivity<\/a> 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.<\/p>\n

Network Prefix Translation for IPv6 (NPTv6)<\/h3>\n

There actually were early IETF drafts for IPv6-to-IPv6 Network Address Translation (NAT66)<\/a> 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”.<\/p>\n

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.<\/p>\n

\"\"<\/p>\n

The diagram above shows use of fd00::\/8 IPv6 Unique Local Addresses (ULA) (RFC 4193<\/a>).\u00a0 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.\u00a0 For larger enterprises, it is recommended to use global unicast IPv6 addresses without NAT, rather than to use ULA IPv6 addresses with NAT<\/a>.\u00a0 Furthermore, using ULA IPv6 addresses is frequently discouraged<\/a>.<\/p>\n

There are some network and security devices that now support NPTv6.\u00a0 Following are the vendors and their products that my research has discovered (but there could be others).<\/p>\n