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.
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.
| Method | How it works | Key limitation |
|---|---|---|
| Port forwarding | Manually map a public port to a private IP | One public IP+port per device; fails behind CGNAT |
| UPnP/NAT-PMP/PCP | Software asks router to forward ports automatically | Often disabled; fails if ISP does CGNAT |
| STUN | Ask a public server what your external address looks like | Useless under symmetric NAT |
| TURN | Relay all traffic through a server | Adds latency and requires third-party infrastructure |
| ICE | Try all techniques in order | Complex; still may fall back to relay |
Source: robin's page
Discussion
0 Comments
Be the first to start the discussion.