5.3.3 — NAT, IPv4 Scarcity & IPv6

Your laptop's address is probably 192.168.1.something. Chapter 5.3.1 said that range is private and not routable on the internet — no router outside your home will forward a packet to it, and every other home on Earth is using the same numbers.

So how are you reading this?

The answer is a device in your home rewriting your packets as they leave, and rewriting the replies as they come back, while keeping a table of who asked for what. It is called NAT, it was introduced in 1994 as a stopgap measure, and thirty years later it is still holding the internet together.

1. Why the addresses ran out

2^{32} is about 4.3 billion. That is fewer addresses than there are people, let alone devices — most people carry two or three.

But the shortage arrived far sooner than that arithmetic suggests, and the reason is the classful waste from Chapter 5.3.1. Whole class A blocks of 16.7 million addresses were handed to single organisations in the 1980s. A company needing 300 addresses received 65,536. The space was exhausted not by usage but by allocation, and the numbers below tell the story:

• 1981 — IPv4 standardised. 4.3 billion addresses looks infinite for a research network.
• 1993 — CIDR removes classes, slowing the burn.
• 1994 — NAT specified as an explicit stopgap while a real successor is designed.
• 1998 — IPv6 standardised.
• 2011 — IANA allocates the last unreserved blocks to the regional registries.
• 2015–2019 — each regional registry exhausts in turn.
• Today — IPv4 addresses are traded on a secondary market at roughly $30–50 each, and cloud providers charge for them by the hour.

IPv6 was ready thirteen years before exhaustion and still has not replaced IPv4. Section 5 is why, and it is a lesson about incentives rather than technology.

2. NAT, mechanically

A NAT box — your home router, or a cloud NAT gateway — sits between a private network and the internet, and rewrites addresses in both directions.

Both devices happened to choose source port 51000, which would make their replies indistinguishable. The NAT router assigns each a different external port, and the translation table is what lets it undo the rewrite when the reply arrives.

Step by step, for one request:

Outbound. Your laptop sends a packet with source 192.168.1.42:51000 and destination 142.250.187.238:443. The router rewrites the source to 203.0.113.7:60001 — its own public address and a port it has chosen — records the mapping in its translation table, and forwards it.

The server replies to 203.0.113.7:60001, because that is the only address it ever saw. It has no idea your laptop exists.

Inbound. The router receives the reply, looks up port 60001 in its table, finds 192.168.1.42:51000, rewrites the destination accordingly, and delivers it on the local network.

The port number is doing all the work. With 65,535 ports available, one public address can multiplex tens of thousands of simultaneous connections from many devices. That is why this is properly called PAT (port address translation) or "NAT overload", though everyone just says NAT.

Note what layer this is. A device that is supposed to work at layer 3 is reading and rewriting layer-4 port numbers. That is a layering violation (Chapter 5.1), it is universal, and it is the source of every problem in the next section.

3. What NAT broke

NAT is not free. It changed the internet's fundamental shape, and the consequences are worth knowing individually.

Inbound connections are impossible by default. A packet arriving at the NAT box for a connection nobody started matches nothing in the translation table, so the router does not know which internal device to give it to. It drops the packet. Your laptop cannot be connected to from outside — which is why hosting anything at home requires port forwarding, a manually configured static entry in that table.

The end-to-end principle is dead. Chapter 5.1 described the internet's founding idea: any machine can talk to any other, with intelligence at the edges. NAT ends that. Most devices on the internet can only initiate, never receive. The internet became asymmetric — a small number of servers and billions of clients — and NAT is a large part of why. Whether that is a cause or a symptom of the centralised web is a genuinely interesting argument.

Peer-to-peer needs elaborate workarounds. Two machines both behind NAT cannot connect directly, because neither can accept an inbound connection. The industry built an entire stack to work around this:

• STUN — a public server tells you what your external address and port look like from outside.
• NAT hole punching — both peers simultaneously send outbound packets to each other's discovered external address. Each outbound packet creates a translation entry, so the other side's packet then matches an existing entry and gets through. Two failures cancelling out into a success.
• TURN — when hole punching fails, give up and relay all traffic through a public server, which costs bandwidth and adds latency.
• ICE — the protocol that tries all of the above in order and picks whatever works.

Every video call you make runs this machinery. All of it exists solely because of NAT.

Protocols that carry addresses inside the payload break. FTP's active mode sends an IP address in the data stream. NAT rewrote the header but not the payload, so the address inside is a private one the far side cannot reach. The fix was a NAT box that inspects and rewrites FTP payloads — a layer-3 device parsing a layer-7 protocol, which is about as deep a layering violation as exists, and it stops working the moment the protocol is encrypted.

Logging and rate limiting lose accuracy. Everyone behind one NAT shares an external address. A rate limiter keyed on IP (Chapter 9.7.5) treats an entire office, or an entire mobile network under carrier-grade NAT, as one user.

"NAT is a firewall" is a half-truth worth being precise about. It does block unsolicited inbound connections, which is a real security benefit and the reason most home networks are not immediately compromised. But it is a side effect of not knowing where to send the packet, not a security policy. It does not inspect traffic, does not stop outbound connections to anywhere, and does nothing against anything a user clicks on. Treating NAT as your security model is a mistake, and Chapter 8.6 covers what an actual firewall does.

4. IPv6, and the parts that are genuinely different

IPv6 uses 128-bit addresses. That is 2^{128}, or about 3.4 \times 10^{38} — enough to give every atom on the surface of the Earth roughly a hundred addresses. The number is absurd on purpose: it is chosen so that nobody ever has to conserve again, and so that addresses can be allocated wastefully in exchange for simpler management.

The notation. Eight groups of four hex digits separated by colons, with two shorthand rules:

2001:0db8:0000:0000:0000:ff00:0042:8329       full
2001:db8:0:0:0:ff00:42:8329                   leading zeros in a group dropped
2001:db8::ff00:42:8329                        one run of all-zero groups → ::

:: may appear only once in an address, because two of them would make the number of omitted groups ambiguous.

Some to recognise: ::1 is loopback (the IPv6 127.0.0.1), :: is the unspecified address (the IPv6 0.0.0.0), fe80::/10 is link-local, and 2000::/3 is the currently allocated global unicast space.

What actually changed, beyond the size:

Every device gets a globally routable address, so NAT is unnecessary. Peer-to-peer works again by default. A typical home is allocated a /64 or even a /56 — that is 2^{64} addresses for one house, which is more than the entire IPv4 internet, squared.

Autoconfiguration is built in. SLAAC (stateless address autoconfiguration) lets a device hear a router advertisement, take the network prefix from it, generate its own host part, and be online with no DHCP server at all.

The header is simpler. IPv6's header is fixed at 40 bytes with no checksum and no fragmentation fields. Removing the checksum means routers do no per-hop recalculation (Chapter 5.3.2 step 4), and removing fragmentation means routers never fragment — if a packet is too big for a link, the router sends an error and the sender must adjust. Both changes move work out of the middle of the network, in the spirit of the end-to-end principle.

No broadcast at all. IPv6 replaces broadcast with multicast, so a device only receives traffic for groups it has joined. ARP is replaced by Neighbour Discovery over multicast, which means a device is no longer interrupted by every discovery message on the network.

IPSec was originally mandatory, though in practice this became a recommendation. It is often overstated as an IPv6 advantage.

5. Why the transition has taken thirty years

This is the interesting part, and the answer is not technical.

The two protocols are not compatible. An IPv6-only machine cannot talk to an IPv4-only machine. They are different address spaces with different headers; there is no translation that preserves meaning. So dual-stack — running both simultaneously — is the only real transition path, which means running two networks, two firewall rule sets and two monitoring systems for years, at double the operational cost, for zero user-visible benefit.

The incentives are backwards. If you enable IPv6, you gain nothing until the other side has it too. If a content provider enables IPv6, it still needs IPv4 for everyone else, so it saves nothing. Nobody can move first profitably, which is the classic coordination failure and exactly the ossification force from Chapter 5.1.

NAT relieved the pressure that would have forced the move. This is the deepest irony in networking: the stopgap worked so well that the permanent fix became optional. A temporary measure from 1994 removed the urgency that would have driven adoption.

Where it stands. Roughly 45% of Google's traffic arrives over IPv6, up steadily each year. Mobile networks are largely IPv6-native because they were built recently and needed the addresses. India, Vietnam, France, Germany and Saudi Arabia are well above half. The United States is around half. Corporate networks and older data centres lag furthest, because they have the most existing configuration to change.

Where the cost has landed. IPv4 addresses are now a traded asset. AWS began charging for every public IPv4 address in 2024 — roughly $0.005 per hour, about $3.60 a month each — which for a company running a thousand instances is a real line item. That is the address shortage arriving on a finance team's invoice, and it is currently the strongest force pushing IPv6 adoption. Not elegance; cost.

6. What this means when you build things

Private addressing is the default everywhere, and cloud networks are built on it. A cloud VPC is a private range (10.0.0.0/16 is the conventional choice), instances get private addresses, and outbound internet access goes through a NAT gateway. Chapter 5.10 builds this in full, and it will make more sense knowing that it is exactly your home router's arrangement with a management console attached.

Public addresses are a resource to budget. In the cloud, a public IPv4 address costs money per hour, is a finite quota, and is one of the things a load balancer exists to conserve — one public address in front of many private instances.

Design for being behind NAT. Assume your service cannot receive unsolicited inbound connections. This is why webhooks (Chapter 5.8) exist as a pattern: the client cannot be called, so it establishes an outbound connection or polls, or you push through a service that both sides can reach.

Never key anything security-critical on an IP address alone. Carrier-grade NAT means thousands of mobile users share one address, and a single user's address changes as they move between networks. Rate limiting by IP is a blunt instrument, and IP-based access control is weak identity (Chapter 8.4).

Write address-family-agnostic code. If your code parses an address by splitting on ., or stores it in a 32-bit integer, or has a validation regex for four octets, it will break the first time it meets an IPv6 address. Chapter 5.9 shows the socket API's address-family-independent way to do this, which is to resolve a name into whatever address family the system supports and connect to that.

What the interviewer will push on

"Explain NAT." Rewrite the source address and port on the way out, keep a translation table, reverse the rewrite on replies. The tell is naming the port as the multiplexing key — that is why one public address serves a whole office.

"Why can two machines behind NAT not connect directly?" Neither can accept an inbound connection, because an unsolicited packet matches no translation entry. Then name the workaround stack — STUN to discover your external address, hole punching so both sides create entries simultaneously, TURN to relay when that fails — and note that every video call depends on it.

"Is NAT a security feature?" It blocks unsolicited inbound connections as a side effect of not knowing where to route them, which is a genuine benefit and not a security policy. It inspects nothing and restricts no outbound traffic.

"Why has IPv6 taken so long?" Not technical. The protocols are incompatible so dual-stack is the only path, that doubles operational cost for no user-visible benefit, nobody profits by moving first, and NAT removed the urgency. Then note what is finally moving it: cloud providers charging for IPv4 addresses.

"What actually changed in IPv6 besides the address size?" No NAT needed, SLAAC autoconfiguration, a fixed 40-byte header with no checksum and no router fragmentation, and broadcast replaced entirely by multicast with Neighbour Discovery in place of ARP.

"Your service rate-limits by IP address. Any concerns?" Carrier-grade NAT puts thousands of mobile users behind one address, so a limit that is right for one person blocks a whole network. Meanwhile a determined attacker rotates addresses cheaply. IP is a weak identity signal in both directions.

One thing to volunteer: point out that NAT is the reason the internet became asymmetric — billions of clients that can only initiate, a small number of servers that can receive — and that the entire STUN/TURN/ICE stack, and much of the webhook and long-polling design vocabulary, exists to work around that one 1994 stopgap. It reframes a piece of trivia as an architectural force.

Recall

• IPv4 exhausted early because of classful over-allocation, not usage; CIDR slowed it, NAT (1994) was the stopgap, and the last blocks were allocated in 2011.
• NAT rewrites the source address and port outbound, keeps a translation table, and reverses it inbound. The port is the multiplexing key, which is why one public address serves an entire office. It is a layer-3 device rewriting layer-4 fields.
• What NAT broke: no inbound connections, the end-to-end principle, peer-to-peer (hence STUN, hole punching, TURN and ICE), protocols carrying addresses in their payload, and per-IP logging and rate limiting.
• NAT blocks unsolicited inbound traffic as a side effect, not as a security policy — it inspects nothing and restricts no outbound connection.
• IPv6 is 128 bits with :: collapsing one run of zero groups; the real changes are no NAT, SLAAC autoconfiguration, a fixed 40-byte header with no checksum and no router fragmentation, and multicast replacing broadcast (Neighbour Discovery instead of ARP).
• The transition stalled because the protocols are incompatible, dual-stack doubles operational cost for no visible benefit, nobody gains by moving first, and NAT removed the urgency. Cloud providers charging per IPv4 address is what is finally moving it.
• Consequences for your code: assume you cannot receive inbound connections, budget public addresses as a cost, and never key security on an IP address.

Self-test: Which field does NAT use to tell two internal devices' connections apart? · Why does an unsolicited inbound packet get dropped at a NAT box? · Explain hole punching in two sentences · Why can :: appear only once in an IPv6 address? · Give the incentive reason IPv6 adoption stalled, not the technical one · Why is rate limiting by IP address unreliable in both directions?

Next: Chapter 5.4 moves up one layer. IP has now delivered a packet to a machine and made no promises about whether it arrived, arrived once, or arrived in order — and TCP is the machinery that turns that into a reliable, ordered stream of bytes.