What Is CGNAT and Why Growing ISPs Can't Avoid It

The free pool of IPv4 addresses ran dry years ago, and the transfer market that replaced it prices a single address at a level that makes “one public IPv4 per subscriber” a fantasy for any growing ISP. Yet the bulk of the internet — banking portals, legacy APIs, older CDNs, countless embedded devices — still assumes IPv4 will be there. Carrier-Grade NAT (CGNAT) is how operators square that circle: a small block of public IPv4 addresses is shared across a large population of subscribers, each of whom lives behind a private address internally. It is not an elegant technology. It is a rationing mechanism, and like all rationing it works fine until demand spikes in the wrong place.

For an ISP, CGNAT is less a feature than a managed liability. It keeps you growing without buying address space you cannot afford, but it quietly changes the contract you have with your subscribers: some applications that worked on a public IP now misbehave, your abuse-response and legal-compliance workload multiplies, and a single misbehaving subscriber can degrade the reputation of an address shared by hundreds of innocent neighbors. Understanding exactly how CGNAT consumes resources — and where it fails — is what separates an ISP whose customers never notice it from one drowning in “my camera won't connect” tickets.

How CGNAT actually works

Internally, each subscriber receives a private address, typically from the shared CGNAT space reserved for exactly this purpose (the 100.64.0.0/10 range) rather than ordinary RFC 1918 space, so it doesn't collide with the customer's own home network. A CGNAT device — often integrated into the BNG or a dedicated NAT appliance — sits at the border between your access network and the internet. When a subscriber opens a connection, the device rewrites the source address to one of its public IPs and the source port to a value it tracks, recording the full mapping so that return traffic can be translated back. Because the subscriber's own router is usually doing NAT too, the packet is translated twice on its way out: once by the customer, once by you. This double translation is why CGNAT is commonly called NAT444 (private-to-private-to-public).

Port-block allocation, not per-connection

The naive way to run CGNAT is to allocate one public port per connection on demand, but that creates two problems: the translation log explodes (one record per flow), and bursty subscribers can starve the pool unpredictably. The standard answer is port-block allocation. Each subscriber is pre-assigned a contiguous block of ports on a public IP — say 2,000 ports — and uses only those. This caps how many simultaneous connections one subscriber can hold, makes the per-subscriber footprint predictable, and collapses the logging burden from one record per connection to one record per block assignment. The trade-off is the cap itself: a single public IPv4 address has only ~64,000 usable ports, so if you hand each subscriber a 2,000-port block you can place roughly 32 subscribers per public IP. Smaller blocks pack more subscribers per address but increase the chance a heavy user runs out of ports; larger blocks are roomier per user but waste address capacity.

What CGNAT breaks

The end-to-end model the internet was built on assumes a host can be reached at its address. CGNAT violates that for inbound traffic, and the breakage is concrete:

• Port forwarding and self-hosting stop working — there is no stable public ip:port a subscriber can publish, so home servers, NVR/IP-camera remote access, and self-hosted services fail without extra mechanisms.
• Peer-to-peer and some gaming degrade because NAT traversal (STUN/UPnP-style hole punching) is harder or impossible when the carrier NAT is symmetric and the subscriber can't control it.
• Shared-IP reputation bites: one compromised or abusive subscriber gets the shared public IP rate-limited, CAPTCHA-walled, or blocklisted, and every other subscriber on that address inherits the punishment.
• Geolocation drifts, because the public IP may map to a pool location rather than the subscriber's actual area, breaking location-aware services.
• The logging burden becomes a compliance liability: when many subscribers share an address, only your translation records tie a public ip:port:timestamp back to a specific customer for an abuse complaint or law-enforcement request — and that data accumulates fast and must be retained and searchable.

Costs and mitigations

How it fails at scale

CGNAT failures are rarely a clean outage; they are a slow erosion. The first symptom is usually a rise in tickets that don't correlate with any link or bandwidth problem — a subset of customers report that one specific app or device “stopped working,” and the common thread is that they all need inbound reachability. The second is the port-exhaustion ceiling: a subscriber running many simultaneous flows (a busy household, lots of IoT, aggressive apps that open hundreds of connections) burns through their port block and new connections start failing while existing ones look fine. Because the symptom is intermittent and bandwidth graphs look healthy, it is easy to misdiagnose. The third failure is reputational: a single bot-infected device shares its public IP with hundreds of others, and suddenly a chunk of your subscriber base is solving CAPTCHAs to use ordinary websites. None of these announce themselves on a NOC dashboard unless you are explicitly monitoring NAT pool and per-block utilization.

Sizing the pool and per-subscriber ports

Sizing CGNAT is a balance between density and headroom. Start from the ~64,000 usable ports per public IP and decide a per-subscriber port-block size that fits your subscriber behavior — a few thousand ports comfortably covers a typical household, while light or mostly-IPv6 subscribers can do with less. Divide to get subscribers-per-IP, then add headroom: never run the pool near 100%, because utilization is bursty and the day you saturate is the day connections fail network-wide. Plan oversubscription on the realistic assumption that not every subscriber is at peak simultaneously, but keep a generous margin, and alarm on pool utilization well before exhaustion. The single most effective sizing lever, though, isn't on the IPv4 side at all — it's deploying IPv6, because every flow that rides IPv6 is a flow that never touches your NAT pool.

The real fix: IPv6 dual-stack

CGNAT manages IPv4 scarcity; it does not cure it. The cure is IPv6, where address space is effectively unlimited and every device can hold a real, reachable address with no translation at all. The pragmatic deployment is dual-stack: give subscribers native IPv6 alongside their CGNAT'd IPv4, and modern endpoints and major content providers will prefer IPv6 automatically. In a well-run dual-stack network, a large and growing share of traffic — often the majority — flows over IPv6 and never enters the CGNAT pool, which directly relieves port pressure, shrinks your translation logs, and sidesteps the inbound-reachability and reputation problems for everything that speaks IPv6. CGNAT then degrades gracefully into a fallback for legacy IPv4-only destinations rather than the load-bearing path for all traffic.

How to choose your strategy

For nearly every growing ISP the answer is not CGNAT-or-not but CGNAT-and: run CGNAT for IPv4 reachability, deploy IPv6 dual-stack aggressively to drain traffic off the NAT pool, use deterministic port-block allocation to keep logging sane, and sell an optional public/static IPv4 to the minority of customers who genuinely need inbound access — gamers, small businesses, camera and home-server users. That last point matters operationally: a clean, self-service way to provision a public IP add-on turns a recurring support headache into a revenue line, and it should be wired into your provisioning and billing system rather than handled by hand.

The takeaway

CGNAT is unavoidable for most growing ISPs because buying a public IPv4 address for every subscriber is no longer economically real — but it is a trade-off to be engineered, not a switch to flip and forget. Size your pools and port blocks with real headroom, monitor utilization so port exhaustion never surprises you, keep deterministic translation logs for compliance, and treat optional public IPv4 as a paid feature for the few who need it. Above all, deploy IPv6 dual-stack and keep pushing traffic onto it: that is the one move that makes CGNAT smaller every year instead of a problem that grows with your subscriber count. Done well, your subscribers never know CGNAT exists; done carelessly, it becomes a permanent, expensive drip of tickets you can never quite drain.