Network Address Translation is the practice of rewriting the addresses in IP packets as they cross the boundary between a private network and the public internet, so that many internal hosts can share a small number of globally unique addresses. The original specification is RFC 1631, “The IP Network Address Translator (NAT),” written by K. Egevang of Cray Communications and P. Francis of NTT and published in May 1994. It was proposed as a short-term measure to ease IPv4 address depletion and routing-table pressure, explicitly complementing the longer-term work on classless addressing.
The mechanism is simple in outline. A NAT device sits at the edge of a network and maintains a translation table. When a packet leaves the private network, the NAT rewrites the source address, recording the mapping; when a reply returns, it rewrites the destination back to the original internal address. RFC 1631 notes that the system modifies source and destination addresses and updates the affected checksums so the packets remain valid. The key insight in the RFC is that “only a subset of the IP addresses inside a stub domain need be translated into globally unique addresses,” because at any moment only a fraction of internal hosts are communicating with the outside world.
A major attraction was deployability. The authors observe that NAT “requires no changes to hosts or routers” beyond the translating device itself, which made it possible to roll out incrementally without coordinating a flag day across the internet. An organization could conserve public addresses by giving its internal hosts addresses drawn from a reusable private range, and many organizations could reuse the same private blocks without conflict because those addresses never appear on the public internet. This reuse is exactly what kept the 4.3 billion IPv4 addresses serviceable far longer than anyone in the early 1990s expected.
The authors were candid about the costs. RFC 1631 acknowledges that NAT “breaks certain applications,” particularly those that carry IP addresses inside their payloads rather than only in packet headers, and that it complicates debugging and security monitoring. Most fundamentally, it removes “end-to-end significance of an IP address,” meaning a host’s address no longer uniquely and globally identifies it. This erosion of the end-to-end principle, on which the internet was originally designed, is the deepest criticism of NAT and a recurring theme in arguments for IPv6.
RFC 1631 was meant to be temporary, a bridge until protocols with a larger address space arrived, and it was later obsoleted by RFC 3022, which refined the model and named the common many-to-one variant Network Address Port Translation. The irony is that the stopgap outlasted expectations: NAT became ubiquitous in home routers and corporate gateways and is one of the main reasons IPv4 survived long past its predicted exhaustion. The temporary fix from 1994 is still running in nearly every household network today.