Glonce

NAT's 1994 quick fix for IP scarcity reshaped the internet

infrastructureThe Glonce editorsHacker News🔥54Glonce rating54Impact50Novelty40Relevance70Surprise35Players10Credibility80

The essay argues that network address translation (NAT) is one of the earliest and most underrated causes of internet centralization. NAT was formally proposed in RFC 1631 in 1994 as a short-term fix, alongside CIDR, for two problems: IP address depletion and routing scale. It lets multiple devices share one public IP address by rewriting address information in packet headers as traffic crosses a router. Combined with reserved private address ranges, this became the standard home-network setup: private addresses inside, one public address translated at the router. The catch is that NAT only knows how to route replies to connections your own devices initiated. If an outside server tries to contact you first, the router has no idea which internal device the packet is for, and drops it. That single limitation, the author argues, is why running a server from home stopped being the default. A whole ecosystem of workarounds grew up around it, none complete. Port forwarding lets you manually tell a router to route a given external port to a specific internal device, but one public IP and port can serve only one device at a time, which breaks down on enterprise or university networks sharing a handful of addresses, and does not work at all if the ISP itself sits you behind carrier-grade NAT (CGNAT), where you do not control the translating device. UPnP, NAT-PMP and PCP let software request port forwards automatically, but they are frequently disabled over security concerns and still fail whenever the ISP is doing the NATing. STUN asks a public server what your packet looks like on arrival, letting two peers exchange the external IP and port a 'cone NAT' assigned them and connect directly, a technique called hole punching. That fails under 'symmetric NAT', common on CGNAT and institutional networks, where a device gets a different external port for every destination it contacts. TURN sidesteps the whole problem by relaying all traffic through a third-party server, at the cost of added latency and someone having to run that server. ICE, which is what WebRTC uses, tries every method in order of preference and falls back until something works. The intended long-term fix, per RFC 1631, was IPv6, giving every device a real globally unique address and removing the need for NAT entirely. The essay says IPv6 adoption's growth curve looks like it is stalling out too early, and that even where IPv6 is deployed, many ISPs and institutional networks keep applying NAT-like restrictions out of inertia or misplaced security thinking, including running actual NAT on IPv6 by deploying Unique Local Addresses (fc00::/7) the way private RFC 1918 space is used on IPv4. The consequences the author draws out: running a server used to mean just running an executable and sharing your address, and now typically requires configuring port forwarding that is often unavailable behind CGNAT or on institutional networks; NAT trained a generation of users to see client-server as the natural shape of the internet, when it started as a side effect of address scarcity; and NAT even got framed as a security feature, hiding your devices, which made people resist the very fix, IPv6, that would have removed the need for it. NAT is not the only force behind today's walled gardens, the essay concludes, but it was the first, and it is why sending a file directly to someone is hard, why people do not run their own email, and why self-hosting anything usually means buying a VPS instead of using hardware already sitting at home.

Key facts

  • NAT was formally proposed in RFC 1631 in 1994 as a short-term fix for IP address depletion and routing scale, alongside CIDR.
  • Ordinary NAT breaks unsolicited inbound connections: a router has no way to know which internal device an external server's first packet is meant for.
  • Port forwarding maps one public IP and port to only one device at a time and fails entirely under carrier-grade NAT (CGNAT), where the ISP, not the user, controls the translating device.
  • STUN-based hole punching works under 'cone NAT' but fails under 'symmetric NAT', common on CGNAT and institutional networks, forcing a fallback to relay-based TURN or the try-everything approach of ICE, which is what WebRTC uses.
  • IPv6, the long-term fix named in RFC 1631, has an adoption curve the author describes as stalling out too early, and some networks still apply NAT-like restrictions to IPv6 addresses out of habit.

Why it matters

The piece reframes a familiar complaint, that the modern internet is walled gardens and centralized clouds rather than the peer-to-peer network it was designed as, as the traceable result of one 1994 engineering compromise rather than an inevitable evolution. NAT was meant to buy time until IPv6 solved address scarcity for good; instead it became permanent infrastructure, and the client-server mental model most users now treat as simply how the internet works is, per the essay, a side effect of that stopgap rather than a natural law.

Who it affects

Anyone who has tried to self-host a service, run a game server, or send a file directly to another person from a home connection has hit the wall this essay describes. It is most acute for people on carrier-grade NAT or inside university and enterprise networks that share a small pool of public addresses, where the user does not control the router doing the translation and manual fixes like port forwarding are unavailable. It also matters to developers building peer-to-peer or real-time applications, since it explains why WebRTC needs STUN, TURN and ICE at all rather than a plain direct connection.

How to use it

The essay functions as a primer on NAT traversal for anyone building or debugging peer-to-peer connectivity: it lays out, in order of how much they give up, port forwarding (manual, breaks under CGNAT), UPnP/NAT-PMP/PCP (automatic but often disabled), STUN-based hole punching (works only under cone NAT), TURN (a relay of last resort, adds latency), and ICE (the practical WebRTC approach of trying all of the above). Anyone choosing an approach for self-hosting or real-time software can use this as a map of which technique fails under which network condition, notably CGNAT versus symmetric NAT.

How solid is it

This is a single-author technical essay published on the writer's personal site and submitted to Hacker News, where it gathered 55 points and 35 comments, not a peer-reviewed or data-driven study. Its historical claims, the 1994 date and content of RFC 1631, the mechanics of NAT, STUN, TURN, ICE and CGNAT, are standard, checkable networking facts. Its central thesis, that NAT is a leading cause of internet centralization, is an argument and interpretation built on those facts rather than a claim the essay itself backs with data; the piece cites no external studies, adoption statistics, or named commentators.

Risks and caveats

The essay does not identify its author or give a publication date beyond the 1994 RFC it discusses, and it names no specific ISPs, institutions, or companies as examples of the behavior it criticizes. Its claim that IPv6 adoption is stalling is stated qualitatively, as a sigmoid curve flattening too early, with no adoption percentage or timeline given, and no source is cited for it. The piece is argumentative rather than neutral reporting: it does not engage with counterarguments for why NAT-like defaults persist, such as the security benefits some administrators genuinely intend.

“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.”

— RFC 1631 abstract, as quoted in the essay