NAT Explained: Types of NAT and Where ISPs Use Them
Network Address Translation is one of those technologies that runs underneath almost everything and is explained clearly almost nowhere. At its core it does a single, simple thing: it rewrites the address (and often the port) information on packets as they cross a boundary, keeping a table so that return traffic can be translated back the way it came. But the variations on that simple idea are not interchangeable, and for an ISP juggling a finite supply of public IPv4 addresses, the differences between them — how many public addresses each consumes, how much state each holds, and what each breaks — are the difference between a network that scales gracefully and one that hits a wall.
This guide walks through the four kinds of NAT an ISP actually encounters — static, dynamic, PAT (overload), and carrier-grade NAT — explains how each works and what it costs, and shows where each one belongs in a real network. The throughline is that every form of NAT is a workaround for IPv4 scarcity, and the only thing that truly retires the workaround is IPv6. Understanding NAT well is partly about using it correctly today and partly about knowing exactly what you are trying to grow out of.
Why NAT exists at all
There were never going to be enough public IPv4 addresses — about 4.3 billion total — for every device on earth, and the practical pool available to any one operator is far smaller and expensive to expand. NAT lets many devices share fewer public addresses by translating between a large private (internal) address space and a small public one. The NAT device maintains a translation table mapping internal address-and-port pairs to public address-and-port pairs, and it rewrites packets in both directions so that a reply to a translated packet finds its way back to the original internal host. Everything else about NAT — its types, its costs, its failure modes — flows from how that table is built and how aggressively addresses and ports are shared.
Static NAT: fixed one-to-one
Static NAT is the simplest form: a permanent, one-to-one mapping between a specific private address and a specific public address. The mapping never changes and is bidirectional, so the internal host is reachable from the outside at its dedicated public address. This is what you use when something needs to be consistently reachable — a customer's server, a business subscriber who has bought a static public IP, a piece of your own infrastructure. The cost is plain: static NAT consumes one public IPv4 address per internal host, so it does nothing to relieve scarcity. ISPs use it deliberately and sparingly, usually as a billable add-on for customers who genuinely need inbound reachability.
Dynamic NAT: shared pool, still one-to-one
Dynamic NAT maps internal addresses to public ones drawn from a pool, assigned on demand and released when idle. It is more flexible than static NAT because the public addresses are shared over time rather than nailed to specific hosts, but the crucial limitation is that each active internal host still occupies a whole public address while it has a mapping. If you have a pool of 100 public addresses, you can support 100 concurrent translated hosts — host 101 simply fails until one frees up. Because of that one-public-IP-per-active-host ratio, dynamic NAT alone does not scale to a large subscriber base, and you rarely see it as the primary translation method on a modern ISP; it is mostly a building block or a legacy arrangement.
PAT / NAT overload: many behind one
Port Address Translation — also called NAT overload — is the form that actually beats address scarcity, and it is what your home router does. Instead of consuming a public address per host, PAT lets many internal hosts share a single public address by distinguishing their connections with the source port. The translation table now keys on the full tuple of internal address, internal port, public address and public port, so one public IP can carry tens of thousands of simultaneous connections from a whole household, each on a distinct public port. The trade-off moves from addresses to ports and state: a single public IP has only about 64,000 usable ports, and every active connection consumes a port and a table entry. PAT is the workhorse of the entire NAT family, and CGNAT is essentially PAT scaled up to carrier dimensions.
CGNAT: PAT at carrier scale
Carrier-Grade NAT applies PAT across thousands of subscribers, sharing a pool of public addresses among them — typically with each subscriber's own home NAT behind it, which is why it is called NAT444 (two layers of translation between the device and the internet). Because so many subscribers share each public IP, CGNAT introduces a distinct set of problems that ordinary PAT doesn't: subscribers can't reliably accept inbound connections, abuse on a shared IP damages everyone's reputation, and you must keep translation logs to attribute any given public ip:port:time back to a subscriber for abuse and legal requests. It is how ISPs keep adding customers despite IPv4 exhaustion, and it has enough operational nuance — port-block allocation, pool sizing, logging — that it deserves its own treatment in our dedicated CGNAT guide.
The types side by side
| Type | Mapping | Public IPs consumed | What it consumes | Where ISPs use it |
|---|---|---|---|---|
| Static NAT | Fixed 1:1, bidirectional | One per host | Public addresses | Servers, business statics, infrastructure |
| Dynamic NAT | 1:1 from a pool, on demand | One per active host | Pool addresses | Rare; legacy or building block |
| PAT / overload | Many:1 by port | One for many hosts | Ports + table state | Customer-premises and small-scale sharing |
| CGNAT (NAT444) | Many:few by port, at scale | One for many subscribers | Ports + state + logging | Subscriber IPv4 reachability at scale |
What NAT costs you
No form of NAT is free, and the costs compound as you scale up the sharing. The first cost is the broken end-to-end model: NAT was designed for outbound-initiated traffic, so anything that needs inbound reachability — port forwarding, self-hosted services, IP cameras, peer-to-peer applications — needs special handling or simply doesn't work behind the more aggressive NAT types. The second cost is state and port consumption: every active connection occupies a port and a translation-table entry on the NAT device, and table size and port count are both finite. The failure mode here is insidious — a busy subscriber can exhaust their available ports and start failing to open new connections while bandwidth graphs look completely healthy, so the symptom (“some things won't connect”) points away from the real cause. The third cost is operational: at carrier scale, NAT brings logging, compliance and shared-reputation burdens that a home router never has. Size your pools and per-subscriber port limits with headroom and monitor utilization, because the day a pool saturates is the day connections fail network-wide.
How to choose
Match the NAT type to the job. Use static NAT only where something must be reachable from outside, and treat each one as a public address spent — bill it accordingly. Reach for PAT/CGNAT as the default for ordinary subscriber traffic, because it is the only thing that meaningfully stretches scarce IPv4. Keep dynamic NAT in mind as a concept rather than a primary strategy. And whatever mix you run, instrument it: track pool utilization and per-subscriber port usage so exhaustion is something you see coming on a dashboard, not something you discover from a wave of tickets. Provisioning a static-IP add-on, in particular, should be a clean, self-service flow wired into your billing and provisioning system rather than a manual one-off.
The real fix: IPv6
Every type of NAT above is a coping mechanism for the fact that IPv4 ran out, and none of them are features to celebrate — they add cost, break applications, and consume operational attention forever. The actual cure is IPv6, whose address space is so vast that every device can hold its own globally reachable address and NAT becomes largely unnecessary. You don't migrate overnight; the realistic path is dual-stack, running IPv6 alongside NAT'd IPv4 so that traffic uses IPv6 wherever both ends support it and falls back to NAT only where it must. The strategic payoff is direct: every flow that moves to IPv6 is a flow that never touches your translation tables, which steadily relieves port pressure, shrinks your logs, and restores end-to-end reachability for everything that speaks it. NAT, in other words, is best understood as something you operate competently today while deliberately shrinking its footprint over time.
The takeaway
The four NAT types are not a menu of equivalents — they trade off public addresses against ports and state in fundamentally different ways. Static and dynamic NAT spend a public address per host and so cannot scale; PAT and its carrier-scale cousin CGNAT spend ports and table state instead, which is what lets one public IP serve a household or thousands of subscribers. Use each where it fits, size for the resource it actually consumes, monitor for exhaustion, and remember the whole edifice exists only because IPv4 is scarce. The endgame is dual-stack IPv6, which doesn't optimize NAT so much as make most of it unnecessary — and the sooner you push traffic onto it, the smaller every NAT problem becomes.