NAT's Original Sin: Why Your Computer Can't Be a Server

The Original Design: End-to-End Peer-to-Peer

In the 1970s, the internet was designed without a client-server hierarchy. Every host had a globally unique address and could act as both consumer and provider of services. A 1980s UNIX workstation running sendmail became a mail server; running ftpd made it a file server. No cloud was needed — the architecture was end-to-end, peer-to-peer, and any node could initiate a connection to any other.

NAT's Emergence as a Temporary Fix

By 1994, IPv4 address exhaustion and routing scalability became urgent. The IETF published RFC 1631, introducing Network Address Translation (NAT) as a short-term measure alongside CIDR, while the long-term solution was the next-generation protocol (later IPv6). RFC 1631 explicitly positioned NAT as a stopgap to buy time for IPv6 deployment. Instead, the temporary workaround became permanent, and IPv6 turned into the "always next year" protocol.

How NAPT Works and Why It Blocks Inbound Connections

Home routers actually run NAPT (Network Address and Port Translation), standardized in RFC 3022. It rewrites both IP addresses and port numbers. For example, an internal packet:

Source IP: 192.168.1.100, Source Port: 50413
Destination IP: 93.184.216.34, Destination Port: 80

becomes after the router:

Source IP: 203.0.113.7, Source Port: 60612
Destination IP: 93.184.216.34, Destination Port: 80

The router stores this mapping in a NAT table. When the server replies to 203.0.113.7:60612, the router looks up the table, rewrites the destination back to 192.168.1.100:50413, and forwards it inside.

The critical limitation: NAT mappings are created only by outbound traffic . If an external host tries to initiate a connection to 203.0.113.7:60612 without a prior outbound packet from the internal host, the mapping does not exist and the packet is dropped. TCP mappings expire quickly after connection close; UDP mappings typically last only tens of seconds to minutes. This forces P2P applications to send periodic keepalive packets — not to save power, but to race against the NAT's expiration timers.

Port Forwarding Limitations and CGNAT

Port forwarding (static NAT) maps a public port to an internal host, but a single public IP port can serve only one internal device at a time. In a shared household, multiple users cannot simultaneously host services on the same well-known port (e.g., Minecraft's 25565).

Worse, the premise of controlling the NAT device is eroding. ISPs also face address scarcity and deploy Carrier-Grade NAT (CGNAT), standardized in RFC 6598, which reserves 100.64.0.0/10 for carrier-internal addressing. Your router's "public" IP may actually be a CGNAT-internal address, adding a second translation layer. The mapping tables reside in ISP equipment, inaccessible to users. CGNAT also imposes logging costs for regulatory compliance, ultimately passed to customers.

UPnP and the Firewall Misconception

UPnP (and its successors NAT-PMP and PCP) lets applications automatically request port mappings from the router. Technically sound, but often disabled by default on consumer routers, ostensibly for "security." Early UPnP implementations had vulnerabilities, but the deeper issue is a widespread misunderstanding: NAT is not a firewall. It blocks inbound connections not because it inspects traffic, but because it lacks a mapping. The accidental obscurity became a perceived security feature, cementing the intuition that "inbound connections = danger" — a mindset that later hindered IPv6 adoption.

STUN, TURN, ICE: Complex Workarounds for NAT Traversal

When port forwarding and UPnP fail, applications resort to a protocol suite for NAT traversal:

STUN (Session Traversal Utilities for NAT): The client asks a public STUN server "What does my packet look like when it reaches you?" The server replies with the public IP:port (e.g., 203.0.113.7:60612). The client shares this with its peer; both send packets to each other's reported addresses, punching holes in their respective NATs (hole punching).

NAT Typing Matters: RFC 3489 classified NATs into Full Cone, Restricted Cone, Port-Restricted Cone, and Symmetric. RFC 5780 refined this into mapping behavior (Endpoint-Independent, Address-Dependent, Address-and-Port-Dependent) and filtering behavior. Only Endpoint-Independent Mapping (cone NATs) allows the STUN-learned address to work for arbitrary peers. Address-and-Port-Dependent Mapping (Symmetric NAT) assigns a different public port for each destination, rendering the STUN-learned address useless for peer-to-peer. Symmetric NATs are common precisely where hole punching is most needed: CGNAT, campus, and enterprise networks.

TURN (Traversal Using Relays around NAT): When hole punching fails, both peers connect to a public relay server. All traffic routes through the relay — nearly 100% connectivity, but with added latency (e.g., 10 ms direct → 30 ms relayed) and bandwidth costs borne by someone.

ICE (Interactive Connectivity Establishment): Not a new protocol, but a framework that gathers all candidates (direct, STUN, TURN), prioritizes them, and performs connectivity checks. WebRTC uses ICE to negotiate the best path.

Every video conference stutter or web-call echo may hide a sad story: both parties behind Symmetric NATs, STUN failing, TURN relaying packets around a server that shouldn't be necessary. We built an immensely complex stack to simulate what should be trivial: two computers talking directly.

IPv6: The Long-Term Solution That Didn't Fully Arrive

IPv6's 128-bit address space (≈3.4×10³⁸ addresses) eliminates the need for NAT. Every device can have a globally unique address. Yet adoption, after years of growth, has not achieved critical mass. Worse, many IPv6 deployments retain NAT-era thinking:

Some administrators run NAT66, translating Unique Local Addresses ( fc00::/7) to public IPv6 — translating what needs no translation.

Even with public IPv6 addresses, firewalls often default-deny inbound connections. Three decades of NAT conditioned operators to equate inbound connectivity with attack. The roof is fixed, but everyone still carries umbrellas indoors because "not carrying an umbrella is unsafe" became common sense.

Centralization as Technical Debt

NAT hides your address → you cannot be reached → you must initiate connections → everyone must initiate connections to a central "other" → that "other" is the server; the collection of such servers is the cloud. Centralization is not a corporate conspiracy; it is the technical debt accumulated over 30 years of NAT.

The bill is long:

Self-hosted email? Residential IP blocks are blacklisted because spammers abused NATed botnets.

BitTorrent downloads stall? Many peers cannot accept incoming connections, relying on the few with public IPs.

Access home NAS from work? Requires port forwarding or a vendor's relay, sending your files on a detour.

Video conferencing? WebRTC falls back to TURN relays, and everyone pays for the bandwidth.

Game server? First check if your ISP uses CGNAT; then negotiate for a true public IP.

Irony: NAT was invented to save addresses (and money). It spawned a massive cloud industry. Addresses were saved, but services that could run on a home PC now require a rented VPS. NAT turned "owning a server" from every internet user's default right into a scarce, paid resource.

Who Bears Responsibility?

Blame cloud providers, ISPs, firewall vendors, or the security culture that turned "your IP is known" into a horror movie. But the first switch was flipped in 1994 by a stopgap for address shortage.

NAT changed three things:

Topology: The internet shifted from a peer-to-peer mesh to a client-server star, because most nodes lost addressability.

Mindset: People accepted "my device only reaches out to the cloud, never receives" as natural law, even mistaking this limitation for security.

Economics: When reachability becomes scarce, whoever holds public addresses and servers collects rent.

Next time you stare at a sluggish cloud upload and curse the product manager, consider: the real culprit may not be the PM or the cloud vendor, but the NAT that was supposed to retire with IPv6 — and never left.

Centralization was not the internet's original design; it is NAT's original sin.