As part of my network consulting business, I work with Carrier-Grade Network Address Translation (CGNAT) and IPv6 almost daily. After a few exchanges with a fellow blogger on IPv4, NAT, CGNAT, and IPv6 (here, here, and here), and repeatedly seeing misunderstandings about how to implement Network Address Translation (NAT) properly, I felt compelled to write this post.
For years, I’ve encouraged more thoughtful practices around NAT, which is deemed necessary by some but is an imperfect solution in network engineering. The most common form today, Port Address Translation (PAT), introduced additional complexity and led to a range of workaround technologies.
By design, NAT changed how the Internet functions. Default NAT configurations across many platforms are often inconsistent, and developers have spent decades working around their limitations. Choosing this direction has limited Layer 4 protocols to just TCP and UDP, sidelining potential alternatives such as DCCP, UDP-Lite, and SCTP. Meanwhile, native, routed IPv6 has existed since 1995 (RFC 1883), offering a cleaner approach that was slow to gain traction.
While stateful firewalls also contributed to the protocol constraints we face today, NAT played a significant role in shaping the Internet’s current architecture.
Even today, routing remains underused in many environments. NAT is often deployed in situations where routing via Internal Gateway Policies (IGPs), Border Gateway Protocol (BGP), or other protocols would be more appropriate. This misunderstanding extends to Layer 2 as well. Bridged networks are still common, often creating avoidable complexity and loops, where a routed Layer 3 design would be cleaner and more scalable.
There’s a saying: “Route when you can, bridge when you must.” It’s solid advice that’s often ignored.
Perhaps we need a new one: “Route when you can. Bridge when you must. But if you’re thinking NAT… just route IPv6 and walk away with dignity.”
The case against NAT
Put simply, with IPv6, there’s no need for NAT. Native, end-to-end routing provides a cleaner, more scalable model. While there are well-known challenges with IPv6 multi-homing and provider-assigned (PA) space, these are already addressed in my IPv6 Architecture guide. Importantly, they’re not unique to IPv6 — IPv4 suffers from the same issues.
So, what are the consequences of NAT?
In short — a long list of technical workarounds. Protocols and techniques such as STUN, TURN, ICE, WebRTC, and Application Layer Gateways (ALGs) exist largely to navigate NAT traversal. While STUN still has a role in stateful firewall environments, most of the others are the result of adapting to the constraints imposed by NAT.
These workarounds are ubiquitous, but they have not eliminated the underlying inefficiencies. Consider some common peer-to-peer (P2P) use cases:
- VoIP and SIP: Calls between NAT-ed endpoints often fail to establish directly and fall back to TURN relays, sometimes introducing significant latency if the relay server is distant from either party.
- Same-LAN NAT scenarios: When two endpoints on the same network use STUN and receive identical public IPs (but with different source ports), NAT hairpinning is required to complete the connection. In many deployments, hairpinning is not enabled by default, resulting in unnecessary relayed traffic via TURN, even when both devices are within a few metres of each other.
- Online gaming: NAT can break direct P2P matchmaking. As a fallback, game clients connect via TURN relays, often causing unpredictable latency, even among players in the same region or ISP.
- Traffic centralization: As P2P reliability has degraded, developers have shifted towards centralized server-client architectures hosted on hyperscale platforms. This raises broader questions about content and traffic centralization on the Internet.
These are not hypothetical concerns. In large-scale networks such as service provider or enterprise networks, P2P traffic is common. Applications like WhatsApp, for instance, route significant amounts of traffic over TURN relays when it could’ve just stayed intra-AS or intra-LAN, with hairpinning or natively routed IPv6.
Even in data centre environments, NAT introduces overhead. Operators at hyperscalers such as Meta and Google have discussed these challenges publicly, citing performance tradeoffs and operational complexity.
The user-facing impact of these workarounds often remains invisible until latency spikes or failures occur. Then, support teams face the consequences of issues caused by NAT-induced indirection.
Finally, CGNAT introduces the well-known problem of port exhaustion, with limited ports needing to be shared across millions of users and devices. Again, this is a limitation that simply doesn’t exist in properly routed environments, particularly with IPv6.
Broken NAT — is there such a thing as ‘not-so-broken’ NAT?
Long story short, yes, mostly.
How to improve NAT deployments
There are ways to make NAT behave more reliably, particularly in peer-to-peer scenarios:
- Enable NAT Hairpinning: This allows devices behind the same NAT to communicate with each other using their public IP addresses. It helps eliminate the need for a TURN relay when both endpoints are within the same LAN or Autonomous System (AS).
- Enable EIM and EIF: Endpoint Independent Mapping (EIM) and Endpoint Independent Filtering (EIF) (RFC 7857), for ports in the range 1024 – 65535 for both TCP and UDP, to improve NAT traversal for applications. This can reduce the reliance on TURN for external peer-to-peer connections.
- Consider Port Control Protocol (PCP): PCP enables dynamic control of NAT mappings. However, adoption is limited across operating systems and applications, and those efforts might be better spent supporting IPv6 instead.
Caveats
A more functional NAT is still not equivalent to a properly routed network. Some issues remain.
Hairpinning is inconsistently supported. On some commercial CGNAT devices, such as those from A10 Networks (see page 31), it works out of the box. On Linux-based platforms, it may require custom configuration and may not always behave consistently.
EIM and EIF support is patchy. For instance, MikroTik supports EIM only for UDP. EIF may be missing entirely, and other platforms might not follow the relevant RFCs precisely.
Address and port exhaustion still apply. No amount of NAT optimization will solve the fundamental constraint of limited IPv4 address space. Only routed networks, particularly with IPv6, can scale effectively.
The IPv6 challenge
IPv6 adoption remains uneven. Even when deployed, IPv6 networks are often implemented with outdated IPv4-era practices, ignoring well-documented best practices such as BCOP-690.
Happy Eyeballs has helped with IPv6 usability but may also have reduced the urgency for network operators to fix broken deployments.
Improving IPv6 deployment requires systemic changes:
- Support generational turnover. As with the transition from circuit switching to IP/MPLS, the shift to IPv6 will be led by new engineers who understand its architecture and benefits.
- Modernize education and certification. IPv6 should be taught as the default address family. It provides a cleaner, more scalable foundation for understanding IP networking. Legacy technologies, including IPv4, NAT, and their workarounds, should be introduced later in the curriculum.
‘But NAT is a Firewall!’
NAT is not a firewall. If you need a firewall, configure one explicitly regardless of whether you’re using IPv4 or IPv6. The two are separate functions, and conflating them leads to misconfigurations and a poor security posture. If you need convincing, read this white paper on “The Myth of Network Address Translation as Security” or Samy Kamkar’s findings on NAT Slipstreaming v2.0.
Conclusion
The core takeaway is straightforward — routing IPv6 is better than NAT. To route at scale, we need to adopt IPv6 properly. If IPv6 continues to be deployed poorly, NAT, and perhaps even NAT66, will persist, undermining the benefits IPv6 was meant to deliver.
At its core, NAT was and always will be what we call in India, jugaad engineering; the closest English translation would be frugal engineering.
Daryll Swer is an independent network consultant specializing in IPv6 deployment and building tailored OOB designs. He provides expert guidance to ISPs, data centres, and businesses looking to optimize their networks. With ongoing research (AS149794) and practical insights, he empowers professionals to harness the full potential of IPv6 and improve their network performance and scalability.
This post is adapted from the original on Daryll’s Blog.
The views expressed by the authors of this blog are their own and do not necessarily reflect the views of APNIC. Please note a Code of Conduct applies to this blog.