The document that gave us NAT called it a short-term fix. Right there in the text. RFC 1631, published in May 1994, described network address translation as a stopgap to buy time until the real solution — a bigger address space — arrived. It was engineering triage: the internet was going to run out of IPv4 addresses, IPv6 wasn’t ready, and someone needed to keep the lights on in the meantime.
That was thirty-one years ago. The meantime never ended. NAT is now the single most load-bearing piece of infrastructure that almost nobody chose on purpose — it’s in your home router, your phone’s carrier link, your cloud VPC, your office. And in the course of buying the internet a few years of breathing room, it quietly rewrote what the internet fundamentally is. This is the story of a hack that was supposed to be temporary and instead ate the architecture it was patching.
The problem NAT actually solved
An IPv4 address is 32 bits: about 4.3 billion possible addresses. In 1994 that already looked terminal, because addresses weren’t handed out one at a time — they were allocated in enormous fixed-size blocks, and the waste was staggering. NAT’s authors, building on a 1993 paper by Paul Francis and Tony Eng (Francis credits the address-reuse idea to Van Jacobson), had a blunt, clever answer: let a whole private network hide behind a single public address. Inside your network, use addresses nobody else can see; at the border, a translator rewrites the source address of outbound packets to the one public IP and remembers enough state to send the replies back to the right machine inside.
RFC 1918 (February 1996) nailed down the private ranges everyone now knows by heart — 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16 — and RFC 3022 (January 2001) formalized the version that actually took over: translate the port too, so hundreds of internal machines can share one public address by multiplexing on port numbers. That’s the box on your desk. One public IP, an entire household or office behind it, and the outside world none the wiser.
It worked. It worked so well that the moment of reckoning kept not arriving. The IANA global free pool of IPv4 addresses was finally exhausted on February 3, 2011; ARIN handed out the last addresses in its North American free pool in September 2015. By every projection from the early 90s, the internet should have hit a wall years before that. It didn’t, because NAT let a finite pool of addresses serve a near-infinite number of devices. NAT is the reason IPv4 exhaustion was a slow-motion administrative event instead of the day the internet stopped growing.
What NAT quietly deleted
Here’s the part that doesn’t show up on the invoice. NAT didn’t just conserve addresses. It broke the design principle the internet was built on.
In 1984, Saltzer, Reed, and Clark published “End-to-End Arguments in System Design”, one of the most quietly influential papers in computing. The argument, applied to networks: keep the middle dumb and the edges smart. The network’s job is to move packets; intelligence, state, and features belong at the endpoints. This is why the early internet was so generative. Every machine had a real, globally routable address and was a first-class peer. Any host could talk directly to any other host. You didn’t ask permission to run a server — you just ran one, and the network delivered.
NAT is the negation of that. A NAT box is a stateful, intelligent thing sitting in the middle, and it fundamentally changes the rules: outbound connections work, inbound connections don’t. A machine behind NAT can reach out, but nothing on the internet can reach in unless the NAT was explicitly told to expect it. The symmetry is gone. In the end-to-end internet, every host was a peer; in the NAT internet, most hosts are clients, and being reachable — being a server — became a privilege you have to arrange for. We stopped noticing because the client/server web is all most people ever wanted. But an entire generation of what the internet could have been — trivial peer-to-peer, every device addressable, no gatekeeper in the path — got designed out, one home router at a time.
The address that never comes back
If you think you at least own your one public address, check again. As the free pool ran dry, ISPs started doing to you what you do to your laptops: putting many customers behind a single public IP. RFC 6598 (2012) carved out 100.64.0.0/10 — “shared address space” — specifically so carriers could run Carrier-Grade NAT without colliding with the 192.168 addresses already inside your house. Under CGNAT you’re behind two layers of translation: your router NATs your devices, and the ISP NATs your router. You often don’t have a public address at all. You share one with strangers.
This is why hosting a game server, or getting a clean port-forward, or running anything that expects an inbound connection has quietly gotten harder over the years even as bandwidth got cheaper. It’s not your imagination. The address space beneath you got more crowded, and each layer of NAT is another place where “just connect to me directly” stops being a thing you can do.
The tax you pay on every video call
Because inbound connections don’t work through NAT, an entire scaffolding of workaround protocols exists solely to defeat it — and you run it dozens of times a day without knowing. When two people on a video call need a direct media path, their devices can’t just connect; both are behind NAT. So they perform a ritual: a STUN server tells each device what its public address looks like from the outside, then both fire packets at each other simultaneously in a maneuver called hole punching, exploiting the momentary mappings their own outbound packets created. When that fails — and behind stricter “symmetric” NATs it does — the call falls back to a TURN relay: a server in the middle that both sides can reach, forwarding every byte of audio and video because the two endpoints simply cannot touch. ICE is the framework that tries all these paths and picks one that works.
Read that back. To make two computers talk to each other — the thing the internet was literally designed to do — we now deploy address-discovery servers, timing tricks, and bandwidth-eating relays. That’s the NAT tax. It’s paid in latency, in server costs, in the staggering complexity of every real-time application ever shipped. The end-to-end internet needed none of it, because there were no boxes in the middle rewriting addresses.
Why IPv6 took thirty years
IPv6 — the actual fix, with 128-bit addresses and enough room to give every grain of sand its own subnet — has existed since the late 90s. Google’s measurements show native IPv6 crossed 50% of its users for the first time on March 28, 2026. Eighteen years after the first serious push to deploy it, IPv6 finally reached half. Half. For a strictly better protocol that solves a problem everyone agreed was existential.
The reason is NAT, and it’s almost funny. IPv6’s killer feature was supposed to be “we’re out of addresses and you have no choice.” But NAT quietly removed the “no choice” part. It made the address shortage survivable, then comfortable, then invisible. Why endure the pain of a dual-stack migration for a problem your NAT box already hides? Every year NAT worked was a year the urgency behind IPv6 leaked away. The stopgap didn’t just delay its replacement — it actively sabotaged the incentive to replace it, by being good enough that the emergency never felt like one.
The myth worth killing
One thing NAT is not, despite thirty years of people insisting otherwise: a security feature. Yes, unsolicited inbound connections don’t reach machines behind NAT, and that blocks some scanning noise. But that’s an accident of how address translation works, not a security boundary anyone designed, and it fails the moment you configure a port-forward, run UPnP, or trust the outbound direction — which is where nearly every real attack lives anyway. Treating “I’m behind NAT” as “I’m protected” is how flat internal networks with no real segmentation get built, and how one compromised laptop turns into a bad afternoon. NAT hides your addresses. It does not defend them. Those are different jobs, and a firewall — a thing with an actual policy you wrote — does the second one.
What the story is actually about
It’s easy to read this as a lament, and it isn’t one. NAT was a genuinely brilliant piece of engineering that saved the internet from a wall it was heading straight for. The uncomfortable lesson is subtler: temporary solutions that work are the most permanent things we build. A patch that merely works gets replaced when something better shows up. A patch that works beautifully becomes load-bearing, accumulates a whole ecosystem on top of it, erases the pain that would have driven its own replacement, and thirty years later is indistinguishable from the foundation.
NAT was supposed to buy a few years. Instead it bought so much time that it changed the building. The next time you reach for a stopgap because the real fix isn’t ready — and you will — it’s worth remembering that the internet is still, in 2026, running on the one from 1994. The meantime is where we live now.