Skip to content
Tech News
← Back to articles

Internet centralization and the original sin of NAT

read original more articles
Why This Matters

This article highlights how NAT, a technology introduced to address IP address depletion, has inadvertently contributed to internet centralization and complexity. It underscores how NAT's widespread adoption has limited peer-to-peer connectivity, affecting both user privacy and the original decentralized design of the internet. Understanding this history is crucial for addressing ongoing issues of internet openness and innovation.

Key Takeaways

Internet centralization and the original sin of NAT

In this comic, the concept of an ordinary person having a FTP server is quickly dismissed. And yes, it’s not common. To the average computer user, the idea that someone could just… connect to your computer feels exotic, or even dangerous — see the very common ironic fear of your IP address being known to other people on the internet.

If you take someone who’s “good with computers” but not a networking person, their mental model of The Internet probably involves a definition of “servers” or “the cloud” that distinguishes them from personal computers in some meaningful way. True peer‐to‐peer, if they ever think about it, is an endeavor: WebRTC, STUN, TURN, ICE, what have you. Given that we live in a world of NAT, CGNAT, and restrictive ISPs, this isn’t entirely wrong, but it breaks the elegant design of the original Internet.

Why you don’t have a FTP server

Network address translation (NAT) was first formally proposed in RFC 1631 in 1994. In its abstract, it says:

The two most compelling problems facing the IP Internet are IP address depletion and scaling in routing. Long‐term and short‐term solutions to these problems are being developed. The short‐term solution is CIDR (Classless InterDomain Routing). The long‐term solutions consist of various proposals for new internet protocols with larger addresses.

Classless interdomain routing is not the point of this post, but basically we started giving people more options for network sizes, and while complex in implementation, it was philosophically virtually uncontroversial.

RFC 1631 proposed a second short‐term solution to IP address depletion and scaling in routing: NAT. While it is not exactly the same type of NAT omnipresent on home routers today, the basic idea is the same: it allows multiple devices to share an IP address (from the perspective of a device on the other end of a routing device) by modifying the network address information in the IP packet headers while transferring the packet across a traffic routing device. We then later reserved certain addresses for private use, and these things are used in conjunction on most IP networks — private addresses within the network, NATing to one public address at the router. On your typical home router, here’s how you usually connect to an external server with NAT:

Your computer sends a packet like this: Source IP 10.11.70.21 Source Port 50413 Destination IP 67.215.249.229 Destination Port 70 It hits your router, and it modifies it to this: Source IP 146.7.15.85 Source Port 60612 Destination IP 67.215.249.229 Destination Port 70 The server replies: Destination IP 146.7.15.85 Destination Port 60612 Your router rewrites it back: Destination IP 10.11.70.21 Destination Port 50413

If you’ve thought this through, you might be asking: in the situation that an external server wants to talk to you first, how does that happen? It sends a packet to 146.7.15.85, and your router…

... continue reading