News

NAT Is the Original Sin of the Centralized Internet

Network address translation was meant as a stopgap for IPv4 exhaustion, but it quietly became the architecture that killed peer-to-peer hosting and trained a generation to think client-server is the only way.

August 31, 2026· 3 min read· Source: robin's page
NAT Is the Original Sin of the Centralized Internet

Network address translation (NAT) was proposed in RFC 1631 in 1994 as a short-term fix for IPv4 address depletion. Thirty years later, it's not just a stopgap—it's the reason your home server is unreachable, why you rent a VPS to host anything, and why the idea of someone connecting directly to your computer feels exotic or even dangerous.

The mechanics are familiar to anyone who's debugged a home network: your device sends a packet with a private source IP, the router rewrites it to a public IP and port, and the reply comes back through the same mapping. The problem is obvious the moment an external host wants to initiate a connection—the router has no idea where to send it. That's not a bug; it's the design.

The workarounds are all compromises

Port forwarding is the most direct fix, but it maps one public IP+port to one device at a time, which breaks on CGNAT or institutional networks where you don't control the translating device. UPnP and its cousins automate the forwarding, but they're often disabled out of misplaced security fear—and they still fail if your ISP is doing carrier-grade NAT.

STUN, TURN, and ICE are the P2P stack that powers WebRTC. STUN works only under cone NAT; symmetric NAT (common on CGNAT) makes the mapping useless. TURN just relays traffic through a server, which defeats the purpose. ICE tries everything in order, which is the best you can do on today's internet—but it's replaced a simple direct connection with external infrastructure.

IPv6 was supposed to fix this

The long-term solution RFC 1631 referenced was IPv6, which gives everyone a globally unique address and obviates NAT. But adoption has stalled, and even where IPv6 exists, ISPs and institutions keep applying NAT out of inertia—sometimes literally NATing IPv6 with Unique Local Addresses, which is baffling.

The real cost is cultural

NAT didn't just make hosting hard; it trained everyone to think client-server is natural. The cloud-centric mental model—my device talks to a server that talks to other devices—is an artifact of address scarcity, not a fundamental property of the internet. Worse, NAT got normalized as a security feature, which made people resist the thing that would fix it.

NAT isn't the only reason the internet is full of walled gardens, but it was the first. It's why you can't just send a file to a friend, why you don't run your own email, and why running any service means renting a VPS instead of using hardware you already own.

NAT isn't the only reason the internet is full of walled gardens, but it was the first—it's why it's hard to send a file to someone, why you don't run your email on your own computer, and why running your own services is difficult and often expensive.
Manul X Editorial
NAT workarounds and their tradeoffs
At a glance
MethodHow it worksKey limitation
Port forwardingManually map a public port to a private IPOne public IP+port per device; fails behind CGNAT
UPnP/NAT-PMP/PCPSoftware asks router to forward ports automaticallyOften disabled; fails if ISP does CGNAT
STUNAsk a public server what your external address looks likeUseless under symmetric NAT
TURNRelay all traffic through a serverAdds latency and requires third-party infrastructure
ICETry all techniques in orderComplex; still may fall back to relay