How NAT Quietly Killed the Peer-to-Peer Internet

NAT began as a stopgap. RFC 1631 proposed it in 1994 alongside CIDR to buy time against IPv4 address exhaustion, letting many devices share a single public address by rewriting packet headers at the router. The catch is asymmetry: outbound connections work fine because the router remembers the mapping, but an unsolicited inbound packet has nowhere to go. That single limitation is why an ordinary user can’t just run an FTP, game, or web server from their machine the way early Internet hosts could.

Everything since has been a workaround that never fully restores direct connectivity. Port forwarding maps one public IP+port to one internal device, but it collapses on shared or carrier-grade NAT where you don’t even control the translating router. UPnP, NAT-PMP, and PCP automate the request but still depend on a cooperative router and are often disabled on security grounds. STUN discovers your external mapping for hole-punching, yet fails under the symmetric NAT common on CGNAT and institutional networks; TURN relays all traffic through a third-party server at the cost of latency; and ICE (used by WebRTC) simply tries every method and hopes one sticks. IPv6 was the intended long-term fix, but adoption has stalled, and many operators reflexively reimpose NAT-style firewalling even where global addresses exist.

The author’s argument is that this was one of the earliest blows to the open Internet. By making inbound connections the exception rather than the norm, NAT trained a generation to see the client-server, device-to-cloud model as natural rather than as an artifact of address scarcity. Self-hosting became an expert endeavor requiring external infrastructure, and centralization on “the cloud” followed as the path of least resistance.