skip to content

Why did NAT become standard on IPv4 networks, and what does it cost the Internet's end-to-end reachability between hosts?

level: juniorimportance: must knowfreq 62%

answer

  1. 32 bits is not enough
  2. private ranges plus shared ports
  3. who can start a connection
  4. state in the middle of the path
  5. the 128-bit answer

basics

~20 s

IPv4's 32-bit space (about 4.3 billion addresses) ran short, so NAT lets many privately addressed hosts share one public address. The cost: outside hosts cannot start connections to them, the translator holds critical per-flow state, and addresses inside payloads break.

solid answer

~50 s

IPv4 addresses are 32 bits, about 4.3 billion in total before reservations, which was not enough for every device. NAT lets a site number its hosts from the RFC 1918 private ranges (`10.0.0.0/8`, `172.16.0.0/12`, `192.168.0.0/16`) and rewrite them to one or a few public addresses at the edge; NAPT also rewrites ports so thousands of flows share one address. The price is the end-to-end model: an inside host has no public address of its own, so nothing outside can initiate a connection to it without a forwarding rule or traversal; the translator holds every mapping, so its failure breaks sessions even after it recovers (RFC 2993); protocols that write addresses into their payload need gateways; and a shared address no longer identifies one user (RFC 6269). IPv6's 128-bit space removes the scarcity, and RFC 6296 records that the IETF does not recommend NAT for IPv6.

go deeper

for a junior

Know the numbers: IPv4 is 32 bits, about 4.3 billion addresses; recall the three RFC 1918 ranges and that NAT shares one public address among many hosts.

for a middle

Explain port sharing in NAPT and list the concrete costs: no unsolicited inbound connections, state held in the translator, and addresses embedded in payloads.

for a senior

Connect the costs to operations: translator failover breaking sessions, keepalives for idle mappings, gateways for legacy protocols and attribution when an address is shared.

for a principal

Argue the strategic picture: NAT bought time, but every year of reliance adds translation layers and workarounds, so the investment case points at IPv6 rather than more translation.

## Why IPv4 ran short An IPv4 address is 32 bits, so the whole space holds 2^32 = 4,294,967,296 addresses - about 4.3 billion - before anything is reserved. Sizeable blocks are set aside for special purposes (private use, loopback, multicast, documentation, the old Class E range), and early allocations were handed out in large fixed chunks. Once there were more devices than usable public addresses, networks needed a way for many hosts to share a few. ## How NAT answers it RFC 1918 reserves three private ranges that any organisation may use internally and that are not routed on the public internet: | Prefix | Range | |---|---| | `10.0.0.0/8` | 10.0.0.0 - 10.255.255.255 | | `172.16.0.0/12` | 172.16.0.0 - 172.31.255.255 | | `192.168.0.0/16` | 192.168.0.0 - 192.168.255.255 | A translator at the edge rewrites a private source address - and, in **NAPT** (Network Address and Port Translation), the source port as well - to its public address on the way out, and reverses the rewrite on replies. Thousands of inside connections can share one public address because each gets its own external port. RFC 2993 lists further motivations: less renumbering when a site changes provider, and a simple, uniform device at the customer edge. ## What the end-to-end model promised The internet's architectural principles (RFC 1958, revisited for NAT in RFC 2993) assume: - every host has an address that means the same thing everywhere, so **any host can initiate** a connection to any other; - **state lives in the endpoints** ("fate-sharing"): if a router fails, traffic reroutes and the conversation survives, because only the two hosts held the connection's state; - the network forwards packets without needing to understand what is inside them. ## What NAT costs 1. **Inbound reachability.** An inside host has no public address of its own. Nothing outside can start a connection to it until a mapping exists - created by a forwarding rule, a mapping protocol, or traversal techniques such as hole punching and relays. Servers, peer-to-peer applications and voice calls all pay for this. 2. **Critical state in the network.** The translator holds every mapping. RFC 2993 notes that if it fails, all communication through it fails, and even after it recovers the sessions stay broken because the mappings are gone - worse than a router, which simply resumes forwarding. 3. **Path rigidity.** Because the state sits in one box, a flow cannot move to another translator mid-session without breaking. 4. **Addresses in payloads.** Protocols that write an address into their own messages (FTP's data-port commands, SIP's session descriptions) carry the private address to the far side, so translators add application-level gateways. 5. **Attribution.** When many users share one address, "address X did something at time T" no longer identifies anyone; RFC 6269 notes that ports must then be logged too. 6. **Keepalives.** Mappings expire when idle, so applications send keepalive traffic, which RFC 6269 notes costs battery on mobile devices. ## The IPv6 argument IPv6 uses 128-bit addresses - 2^128, about 3.4 x 10^38 - so the scarcity that justified NAT disappears: every host can hold a globally unique address and end-to-end reachability returns, governed by whatever firewall policy the network writes. RFC 6296 records that the IETF does not recommend NAT for IPv6. NAT was a stop-gap that stretched IPv4; it never created a single new address. ## Why the costs grew over time The first NATs sat at the edge of one office, so their costs were local. As the address shortage deepened, operators began translating again inside their own networks, so one connection could cross two translators. Every layer adds the same costs again: another table that must hold the mapping, another place where inbound reachability ends, another set of timers deciding whether an idle session survives, and another log an investigator needs before an address can be tied to a person. Applications responded by building traversal and relay machinery into themselves, which is why so much real-time and peer-to-peer software carries logic whose only job is to work around translation. ## In an interview Start with the arithmetic (32 bits, about 4.3 billion), name the private ranges and port sharing, then give at least two concrete costs - lost inbound reachability and state in the middle of the path - before naming IPv6 as the structural fix. Mentioning that NAT's inbound blocking is a side effect rather than a security policy earns credit, as long as you do not present NAT as the reason it was invented.

  • Did NAT solve IPv4 address exhaustion?
    No - it slowed it. NAT lets many hosts share a public address, but it creates no addresses, and as demand kept growing operators added a second layer of translation inside their own networks, with shared address space and its attribution problems. The structural fix is IPv6's 128-bit space; NAT bought time for the transition.
  • Why is a NAT failure worse for running sessions than a router failure?
    A router keeps no per-flow state, so when it recovers or traffic reroutes, existing conversations continue. A NAT holds the mapping for every flow; RFC 2993 notes that if it restarts without preserved state, sessions stay broken even after recovery because returning packets no longer match any mapping.

saying these in an interview costs you the question

  • NAT was invented mainly as a security feature.
  • RFC 1918 private addresses are routed across the public internet.
  • An outside host can reach an inside host at its private address.
  • NAT is transparent to every application protocol.
  • IPv6 will need NAT too because there are so many devices.