NAT — Trivia & Interesting Facts¶

Surprising, historical, and little-known facts about Network Address Translation.

NAT was a temporary hack that saved the Internet and then refused to leave¶

NAT was invented in the early 1990s as a stopgap to slow IPv4 address exhaustion while IPv6 was being developed. RFC 1631 (1994) explicitly called it "The IP Network Address Translator" and described it as a short-term solution. Over 30 years later, NAT is more pervasive than ever, and IPv6 adoption — while growing — has not eliminated the need for NAT. The "temporary" fix became permanent infrastructure.

A single public IP can support over 65,000 simultaneous connections per destination¶

Port Address Translation (PAT, also called NAPT) maps internal addresses to unique source port numbers on a single public IP. Since there are 65,535 available ports and the mapping is per-destination-IP:port, a single NAT IP can theoretically support millions of simultaneous connections to different destinations. In practice, NAT devices run out of memory for connection tracking long before they exhaust port space.

NAT breaks the end-to-end principle that the Internet was built on¶

The Internet was designed so that any host could communicate directly with any other host — the "end-to-end principle." NAT violates this by hiding internal hosts behind translated addresses, making inbound connections impossible without explicit port forwarding. This single architectural change killed peer-to-peer connectivity by default and is why technologies like STUN, TURN, ICE, and hole punching exist — all workarounds for a problem NAT created.

Carrier-Grade NAT puts you behind two layers of NAT¶

As IPv4 addresses became scarce, ISPs began deploying Carrier-Grade NAT (CGN, RFC 6598), which places customers behind an ISP-level NAT in addition to their home router's NAT. This "double NAT" breaks port forwarding, degrades gaming and VoIP performance, and makes it impossible to host any server on your home connection. The 100.64.0.0/10 address range (RFC 6598) was allocated specifically for the ISP-side of CGN.

NAT traversal for VoIP required inventing an entirely new protocol suite¶

SIP and RTP (used for VoIP) embed IP addresses inside the application payload, which NAT doesn't translate. This meant VoIP calls through NAT would fail silently — the signaling would work but the audio wouldn't flow. Fixing this required STUN (RFC 5389), TURN (RFC 5766), ICE (RFC 8445), and SIP ALGs on NAT devices. The complexity of NAT traversal for VoIP consumed enormous engineering effort across the telecom industry throughout the 2000s.

Symmetric NAT is the hardest type to traverse and the most common in enterprises¶

There are four NAT behavior types: Full Cone, Restricted Cone, Port Restricted Cone, and Symmetric. Symmetric NAT uses a different external port for every destination, making it resistant to hole-punching techniques. Unfortunately, symmetric NAT is the type most commonly found in enterprise firewalls and carrier-grade NAT. This is why WebRTC, which uses ICE for NAT traversal, sometimes requires TURN relay servers that add latency and cost.

NAT64 translates between IPv6 and IPv4, enabling IPv6-only networks¶

NAT64 (RFC 6146) allows IPv6-only clients to communicate with IPv4-only servers by translating between the protocols at the NAT device. Combined with DNS64 (which synthesizes AAAA records for IPv4-only destinations), NAT64 enables fully IPv6-only internal networks. Apple requires all iOS apps to work in NAT64 environments since 2016, because mobile carriers increasingly deploy IPv6-only with NAT64 for their subscribers.

The Linux conntrack table is where NAT state lives and dies¶

On Linux, NAT state is maintained in the connection tracking (conntrack) table. The default maximum is often 65,536 entries, which can be exhausted on busy NAT gateways. When the table fills, new connections are silently dropped with no error message — just packets disappearing. Tuning nf_conntrack_max and nf_conntrack_tcp_timeout_established is a rite of passage for anyone running Linux-based NAT at scale.

Hairpin NAT is a surprisingly common misconfiguration headache¶

When an internal host tries to reach a public IP that NATs back to another internal host on the same network, the traffic must "hairpin" through the NAT device. Many NAT implementations don't support this by default, causing internal-to-internal communication via public IPs to fail mysteriously. The typical symptom is "the website works from outside but not from inside the office," and the fix is either enabling NAT hairpinning or using split-horizon DNS.

NAT was declared harmful by the IAB in 2007¶

The Internet Architecture Board published RFC 5765 stating that NAT is harmful to the architecture of the Internet and recommending migration to IPv6 as the long-term solution. Despite this official declaration from the Internet's architectural governance body, NAT usage has only increased since 2007. This is perhaps the most ignored architectural recommendation in Internet history.