Carrier-Grade NAT (CGNAT) Explained
Carrier-grade NAT shares one public IPv4 address across many subscribers. It is the standard answer to address scarcity at access-network scale, and the reason a growing share of consumer connections cannot accept an inbound connection.
How it works
The subscriber’s CPE receives an address from 100.64.0.0/10 — shared address space, defined by RFC 6598 — rather than a public one. Traffic leaving the access network passes through a CGN device that rewrites source addresses and ports to a public address from a pool.
The reason for a dedicated range matters. Subscribers already use RFC 1918 space inside their homes and offices. If the provider used 10.0.0.0/8 on the same segment, the subscriber’s own network and the provider’s would collide, and the CPE would have no way to distinguish them. 100.64.0.0/10 gives 4,194,304 addresses that exist nowhere else, which is why it should never be used as ordinary internal space — see private IP ranges.
The port budget decides everything
A public address has 65,536 TCP ports and the same number of UDP ports, of which roughly 64,000 are usable per protocol. That number, divided by the ports you allocate per subscriber, is your subscriber-per-address ratio.
| Ports per subscriber | Subscribers per address | Typical experience |
|---|---|---|
| 512 | ~125 | Aggressive; visible failures on modern web pages |
| 1,024 | ~62 | Workable for light use, tight for households |
| 2,048 | ~31 | Common default |
| 4,096 | ~16 | Comfortable, including video and gaming |
The pressure comes from how applications behave rather than how much bandwidth they use. A single modern web page can open dozens of concurrent connections, and each connection consumes a port for the duration plus a timeout afterwards. Video conferencing, streaming, and background sync from a household of devices add up quickly.
Set the allocation too high and you save no addresses. Set it too low and you generate support calls that are almost impossible to diagnose from the subscriber’s side, because the failure looks like a slow or broken website rather than an exhausted port pool.
What it costs beyond the hardware
Logging. Determining which subscriber used a public address at a given moment requires records. Per-connection logging at scale produces volumes that are expensive to store and slow to query. Allocating a fixed port block per subscriber and logging only the block assignment, as recommended in RFC 6888, reduces this by orders of magnitude — but it has to be designed in, not retrofitted.
Shared reputation. Every subscriber behind an address inherits the behaviour of every other. One compromised machine sending spam gets the address blocklisted, and everyone on it loses mail delivery or hits CAPTCHAs on ordinary websites. You cannot fix this per subscriber; you can only move them to a different address.
Broken inbound. Port forwarding stops working. Self-hosted services, security cameras, remote desktop, some VoIP configurations, console gaming with strict NAT requirements, and peer-to-peer applications all degrade or fail. Each of these becomes a support ticket, and the honest answer is often that the product no longer supports the use case.
Geolocation drift. Addresses in a CGNAT pool serve subscribers across a wide area, so geolocation resolves to the pool rather than the user. Content licensing, regional pricing, and fraud scoring all get less accurate.
State at scale. The CGN device holds connection state for every active flow. It is a single point of failure with a memory limit, and its capacity planning is a separate exercise from bandwidth planning.
When the economics stop working
CGNAT is genuinely cheaper than public addressing at the low end, where subscribers are numerous and undemanding. The comparison narrows as soon as any of the following apply:
- Business customers. They need inbound reachability, and a public address is usually part of the product. CGNAT is not an option here at any price.
- Support load exceeds the saving. Each broken-inbound ticket has a cost. At some subscriber count the tickets outweigh the address cost.
- Logging storage becomes material. Retention requirements vary by jurisdiction, and the storage bill compounds.
- Reputation incidents recur. Time spent on delisting and the churn from affected subscribers is a real cost that never appears in the CGNAT business case.
The comparison worth running is total cost per subscriber over the equipment’s life, including logging storage and a realistic support estimate, against the amortised cost of address space serving the same subscribers. Buying or leasing frequently wins for business tiers and for any segment where inbound connectivity is part of the service. IPv4 services covers acquiring space; telecom and ISP use cases covers the segment specifically.
The IPv6 relationship
CGNAT is a bridge, not a destination. The end state for most access networks is IPv6 to the subscriber with a translation mechanism for IPv4-only destinations — 464XLAT on mobile, MAP-T or MAP-E on fixed access, or dual-stack where public IPv4 is available.
Deploying IPv6 does not remove the need for IPv4 in the short term, because the destinations subscribers reach are not all dual-stacked. What it does is reduce the IPv4 traffic that has to cross the CGN, which stretches the same address pool further and buys planning time.
Related
- Private IP ranges — why 100.64.0.0/10 is not RFC 1918 space
- Reserved and bogon ranges — what the edge filters drop
- What is IPAM — tracking pool utilization
- CIDR chart — pool sizing reference