What Is NAT? Network Address Translation and PAT Explained

The heart of NAT is a translation table the router maintains. When a device on the private network sends a packet toward the internet, the router replaces the private source address in the header with a public, routable address, and it writes down the mapping between the two. Because most consumer and small-business setups have only one public address, the router also rewrites the source port so it can tell overlapping conversations apart. It stores that combination — the internal address and port, the chosen external address and port, and the destination — as a single entry, then forwards the modified packet on toward its destination.

When the reply comes back, it is addressed to the public IP and port the router selected. The router looks up the matching table entry, rewrites the destination back to the original private address and port, and delivers the packet to the correct internal host. This is why NAT is fundamentally a stateful, outbound-triggered mechanism: an internal device starting a conversation creates the mapping that lets the answer return. Traffic arriving from the internet with no matching entry has nowhere to go, which is the behavior people often mistake for a firewall — the router simply holds no record telling it where to deliver an unsolicited packet.

Plain NAT can be one-to-one: a single private address is mapped to a single public address, which is how you publish an internal server on its own routable IP. What almost everyone actually runs at home and across branch offices is PAT — Port Address Translation, also called NAT overload or IP masquerading. PAT is the many-to-one case formally described as NAPT in RFC 3022 and drawn from the terminology in RFC 2663. Those three names are vendor and community labels for the same NAPT mechanism, not separate standards; each multiplexes many internal hosts behind one public address by giving every conversation a distinct port number.

That reliance on ports carries a structural limit. TCP and UDP each use a 16-bit port field, so only ports 0 through 65535 exist per protocol, which caps how many simultaneous translated sessions one public address can theoretically multiplex. Real devices hit far lower effective limits because of table memory, per-destination uniqueness rules, and shared ephemeral pools, so treat that ceiling as a property of the header, not a capacity guarantee. When even that is not enough, providers add another layer: Carrier-Grade NAT (CGNAT) translates many subscribers behind a shared pool, using the RFC 6598 100.64.0.0/10 range reserved so it will not collide with customers' own private addresses.

Private addressing exists because there were never enough IPv4 addresses to give every device a unique public one. RFC 1918 reserves three blocks for private use — 10.0.0.0/8, 172.16.0.0/12, and 192.168.0.0/16 — that any organization may use internally without registration. The catch is deliberate: the RFC states these addresses have no global meaning and that packets carrying them should not be forwarded across the public internet. Routers on the internet are expected to drop such traffic, so a device with a private address literally cannot be reached from outside until something translates it to a public address first.

The scarcity that made this necessary is not hypothetical. IANA allocated the last of its top-level IPv4 blocks on February 3, 2011, and ARIN, the registry for North America, exhausted its own free pool on September 24, 2015. With no new IPv4 addresses to hand out, sharing a small number of public addresses across many private hosts became the default way networks operate. That is the working distinction between a public IP address — globally unique and routable across the internet — and a private one that is valid only inside a given network; NAT is the bridge that lets the second kind reach the first.

No — and conflating the two causes real procurement mistakes. NIST's firewall guidance, SP 800-41 Revision 1, frames NAT as a routing technology rather than a firewall technology. NAT does hide internal addresses as a side effect, and NIST SP 800-53's boundary-protection control, SC-7, lists address translation as one acceptable way to keep internal components from being discovered. But that control's actual requirement is a managed interface — a gateway, router, or firewall that monitors and controls communications at the boundary — not NAT on its own. NAT satisfies an address-hiding technique; it does not satisfy a security control.

The protection people credit to a NAT router — that unsolicited inbound connections are blocked — comes from the stateful connection tracking the device performs, not from translation. A dedicated stateful firewall delivers that same protection without NAT's side effects, which include breaking protocols such as IPsec, DNSSEC, and geolocation that expect end-to-end addresses. For anyone evaluating network hardware, the practical takeaway is concrete: a requirement for boundary security should call for genuine stateful firewall inspection, and "NAT support" on a data sheet should never be accepted as evidence that a device meets a security requirement.

Because PAT only creates mappings for outbound conversations, reaching an internal server from the internet needs an explicit rule. Port forwarding is that rule: a static entry saying traffic arriving on a given external port should be sent to a specific internal address and port. It is how a camera, a game server, or an on-premises application gets published. A related but separate feature is hairpinning, also called NAT loopback or NAT reflection, which lets a device inside the network reach that same server using the router's public address rather than its private LAN address. Many routers support port forwarding but not hairpinning, producing the classic "works from outside, fails from inside" support ticket.

Double NAT is when two translating devices sit in series — typically your own router behind an ISP gateway or CGNAT that is also performing NAT. Outbound browsing usually still works, so it often goes unnoticed. It breaks down when something needs a stable inbound path: static port forwarding on the inner router no longer reaches the internet, and stacked translators are more likely to behave as symmetric NAT, which changes the external port per destination. That behavior is a common reason peer-to-peer connections fail in online gaming and real-time voice or video, where two endpoints must predict each other's external addresses to connect directly.

Mostly, but not entirely. IPv6's address space is so large that NAT's original purpose — stretching scarce addresses — simply disappears, and RFC 4864 explicitly recommends that enterprises use global, routable IPv6 addressing rather than recreating NAT on IPv6. That direction is also a federal driver: OMB Memorandum M-21-07 set IPv6-only targets of at least 20% of IP-enabled assets by the end of FY2023, 50% by FY2024, and 80% by FY2025. Those deadlines have arrived without confirmed full compliance, and agencies continue reporting progress into FY2026, so "NAT recedes on IPv6" describes an active direction of travel rather than a finished transition.

Translation still has a job during the long coexistence period, though. NAT64, paired with DNS64 and defined in RFC 6146, lets IPv6-only clients reach IPv4-only servers through a shared pool of public IPv4 addresses on a translator, so address translation shifts from hiding hosts to bridging the two protocols. Prefix translation for IPv6 (NPTv6) also survives for niche renumbering and multihoming cases. For buyers, that means IPv6 readiness on new routers and firewalls increasingly implies dual-stack operation plus NAT64/DNS64 for legacy IPv4 back ends — capabilities worth specifying explicitly rather than assuming they ship enabled.