CGNAT for ISPs

What CGNAT is and why it exists

CGNAT (Carrier-Grade NAT) is a large-scale network address translation system that lets an ISP map thousands of subscribers' private IP addresses to a smaller pool of public IPv4 addresses at the network edge. DataRadius is ISP billing and management software that works in CGNAT environments — routers connect outbound even without a public IP, so subscriber management is unaffected.

The internet was designed around IPv4, which provides roughly 4.3 billion unique addresses. IANA allocated its last free IPv4 blocks to the five Regional Internet Registries on 3 February 2011. RIPE NCC ran out in November 2019. AFRINIC reached its last /8 block. APNIC has been on a waiting list for years.

For an ISP, this means new public IPv4 addresses are expensive and scarce. In 2024, a single IPv4 address trades between $30 and $60 on transfer markets. An ISP with 5,000 subscribers assigning one public IP each would need $150,000 to $300,000 just for address space.

CGNAT solves this by letting many subscribers share a small number of public addresses. Instead of every subscriber getting a unique public IP, the ISP assigns private addresses (typically from the 100.64.0.0/10 range defined in RFC 6598) to subscriber equipment, and the CGNAT device translates those private addresses to public addresses as traffic leaves the ISP network. One public address can serve dozens or even hundreds of subscribers simultaneously.

How CGNAT works: the double NAT problem

CGNAT introduces a second layer of address translation on top of the NAT that most subscribers already run at home, creating what is commonly called double NAT.

In a typical home network without CGNAT, the subscriber's router performs NAT once. Devices on the home LAN (phones, laptops, smart TVs) have private addresses like 192.168.1.x. The home router translates those to the single public IP assigned by the ISP. One layer of translation, and the subscriber's router holds the mapping table.

With CGNAT, the picture changes:

Layer 1 — Subscriber NAT. The home router translates LAN addresses (192.168.1.x) to the WAN address assigned by the ISP. But that WAN address is no longer public. It comes from the shared address space 100.64.0.0/10 (RFC 6598), sometimes called the "CGN range." This range was reserved specifically for carrier-grade NAT so it does not collide with RFC 1918 private addresses (10.x, 172.16.x, 192.168.x) that subscribers use on their LANs.

Layer 2 — Carrier NAT. The CGNAT device, sitting at the ISP network edge, translates the 100.64.x.x source address and source port to a public IPv4 address and a mapped port from the ISP's public pool. This second translation is what gives CGNAT its name — it is NAT performed by the carrier, not the subscriber.

When a subscriber's device opens a connection to a website, the outbound packet undergoes two translations: first at the home router, then at the CGNAT device. The reply follows the reverse path. Both layers maintain state tables that track active mappings.

The CGNAT device must track every active connection for every subscriber behind it — potentially millions of simultaneous flows — and translate packets at line rate.

Port allocation and mapping strategies

The number of subscribers that can share one public IP address depends entirely on how the CGNAT device allocates ports.

A single IPv4 address has 65,535 usable TCP and UDP ports (port 0 is reserved). The CGNAT device divides this port space among subscribers. There are three common allocation strategies:

Deterministic NAT (static port block allocation). Each subscriber is assigned a fixed block of ports on a public address at provisioning time. For example, subscriber A gets ports 1024–2023 on 203.0.113.1, subscriber B gets ports 2024–3023, and so on. The mapping is predictable: given a public IP and port number, you can calculate which subscriber it belongs to without consulting a log database. RFC 7422 discusses this approach. The trade-off is inflexibility — if one subscriber needs more ports than their allocation, connections fail, even if other subscribers are idle.

Dynamic NAT (per-connection allocation). The CGNAT device assigns a port from the public address pool on demand, one connection at a time. This is the most efficient use of port space because idle subscribers consume zero ports. But it requires logging every individual mapping (source IP, source port, translated IP, translated port, timestamp), which generates enormous log volumes — potentially billions of entries per day for a large ISP.

Port block allocation with dynamic assignment. A hybrid approach where the CGNAT device assigns a block of ports (say, 1,000) to a subscriber when their first connection arrives, and reclaims the block after an inactivity timeout. This reduces logging (one log entry per block assignment rather than per connection) while still being more flexible than deterministic NAT. RFC 7422 and RFC 6888 discuss considerations for this approach.

The math for capacity planning: if you allocate 1,000 ports per subscriber and reserve ports 0–1023 for well-known services, one public IP supports approximately 64 subscribers (64,512 usable ports ÷ 1,000). With 500 ports per subscriber, you reach 128 subscribers per address. The smaller the allocation, the more subscribers per address — but the higher the risk that a subscriber runs out of ports during heavy use (many browser tabs, streaming, background app connections).

A modern smartphone with a few apps running typically maintains 100–300 concurrent connections. A household with multiple devices, a smart TV streaming, and a gaming console can easily reach 500–800 simultaneous connections. Setting port allocations too low creates support tickets that are difficult to diagnose.

What breaks for subscribers behind CGNAT

CGNAT is invisible to most subscribers most of the time. Web browsing, email, streaming video, and social media work without issues because these are outbound connections that NAT handles naturally. The problems appear when a subscriber needs inbound connections or when applications make assumptions about having a unique public address.

Port forwarding does not work. Subscribers cannot forward a port on their home router to make a local service reachable from the internet. Even if they configure port forwarding on their home router, the CGNAT device does not know about it and will not pass inbound traffic. This affects home security cameras, NAS devices with remote access, self-hosted websites, and any service that relies on inbound connections.

Hosting game servers or peer-to-peer sessions fails. Multiplayer games where one player hosts a session require other players to connect inbound. Behind CGNAT, this does not work unless the game uses relay servers. Some gaming platforms (Xbox, PlayStation) report the NAT type — subscribers behind CGNAT will typically see "Strict NAT" or "NAT Type 3," which limits matchmaking and voice chat.

VoIP quality can degrade. Voice over IP protocols like SIP use specific port ranges for media streams. Double NAT can interfere with SIP signaling and RTP media, causing one-way audio, call setup failures, or calls that drop after 30 seconds (a symptom of NAT mapping timeout mismatches). Modern VoIP apps that use STUN/TURN servers handle this better, but traditional SIP phones and PBX systems often struggle.

IP-based geolocation and rate limiting behave unexpectedly. When 64 subscribers share one public IP, every website sees the same source address for all of them. Geolocation databases may return the ISP's data center location rather than the subscriber's actual location. Rate limiting and abuse detection systems may flag the shared address, blocking all subscribers behind it because one subscriber triggered a threshold.

Some websites and APIs block shared addresses. Banks, government portals, and content providers occasionally blacklist IP addresses that appear to generate suspicious traffic volumes. A single misbehaving subscriber behind CGNAT can get the shared address blocked for everyone.

The Port Control Protocol (PCP, RFC 6887) was designed to let subscriber devices request specific port mappings from CGNAT devices, which would solve many of these issues. In practice, PCP adoption is low among CGNAT vendors and subscriber equipment, so it is not a reliable solution today.

Logging requirements and law enforcement compliance

When every subscriber has a unique public IP, identifying who was behind a specific address at a specific time is straightforward — check the DHCP logs. CGNAT breaks this because multiple subscribers share each address. The IP alone is no longer enough; you also need the port number and the exact time.

RFC 6302 (Logging Recommendations for Internet-Facing Servers) addresses this directly. It recommends that any system performing address translation log:

• Source address (subscriber's private address)
• Source port
• Translated address (public address)
• Translated port
• Timestamp (with sub-second precision, synchronized via NTP)
• Protocol (TCP, UDP, ICMP)

For dynamic NAT, this means logging every connection — every TCP SYN, every UDP flow. A moderately busy ISP with 10,000 subscribers can generate hundreds of millions of log entries per day. Storing, indexing, and searching these logs at the volumes required is a real infrastructure challenge.

For deterministic NAT or block allocation, logging requirements are lighter. You only need to record which subscriber was assigned which port block at which time. If subscriber A always holds ports 1024–2023 on 203.0.113.1, a single log entry per assignment (and release) is sufficient to answer "who had port 1500 on 203.0.113.1 at 14:32 UTC?"

Most jurisdictions that require data retention for ISPs (the EU Data Retention Directive before it was invalidated, various national laws, the US CALEA framework, and similar regulations in Africa and Asia) expect ISPs to be able to answer law enforcement queries of the form: "Who was using IP address X, port Y, at time Z?" If your CGNAT setup cannot answer that question, you may be non-compliant.

Practical recommendations for logging:

1. Use deterministic NAT or port block allocation to reduce log volume by orders of magnitude compared to per-connection logging.
2. Synchronize clocks across all CGNAT devices and logging infrastructure using NTP. A one-second clock drift can make logs useless for legal purposes.
3. Retain logs for the period required by your jurisdiction — typically 6 to 24 months. Compressed, indexed storage is essential at these volumes.
4. Test your query capability before you need it. Can your team look up a specific IP, port, and timestamp and return a subscriber identity within a reasonable time? If the answer takes hours of manual log parsing, the system needs work.

Performance considerations for CGNAT deployment

Running CGNAT introduces a stateful device in the forwarding path of every subscriber packet. The performance requirements differ from a simple router or firewall.

Session table size. The CGNAT device must track every active mapping. With 10,000 subscribers averaging 300 concurrent connections each, that is 3 million sessions in the state table. Peak loads can be 2–3× the average.

Packets per second (PPS). Throughput in Mbps matters less than PPS because every packet requires a state table lookup. Small packets (DNS queries, TCP ACKs, VoIP) create the highest PPS load relative to bandwidth.

Endpoint-independent mapping (EIM). RFC 6888 requires that a given internal IP and port always maps to the same external IP and port regardless of destination — critical for STUN-based NAT traversal in VoIP and gaming.

High availability. If the CGNAT device fails, every subscriber behind it loses internet access. Redundant deployments with session state synchronization between active and standby units are a baseline requirement.

For smaller ISPs (under 5,000 subscribers), a capable x86 server running a Linux-based CGNAT implementation can handle the load. Larger deployments typically use dedicated CGNAT appliances or high-performance software with kernel-bypass packet processing.

IPv6 as the long-term solution

CGNAT is a workaround for IPv4 exhaustion. The actual solution is IPv6, which provides 340 undecillion addresses — enough to assign a unique address to every device on every network for the foreseeable future.

With native IPv6, every subscriber gets a /48 or /56 prefix — billions of unique addresses. No NAT needed. Port forwarding, peer-to-peer protocols, VoIP, and gaming all work without CGNAT complications. Geolocation is accurate per subscriber. Law enforcement can identify users by address alone.

The transition path for most ISPs is dual-stack: assign subscribers both an IPv6 prefix and a private IPv4 address behind CGNAT. IPv6-capable traffic flows natively while IPv4-only destinations still work through CGNAT. As more content becomes IPv6-reachable (Google, Netflix, and Cloudflare already serve most traffic over IPv6), the load on the CGNAT device decreases.

DS-Lite (RFC 6333) is an alternative where subscriber traffic is IPv6-only on the access network and IPv4 is tunneled to a centralized CGNAT device. MAP-E (RFC 7597) and MAP-T (RFC 7599) distribute the NAT function to subscriber CPE, reducing centralized CGNAT load.

The pragmatic path for a small to mid-size ISP today:

1. Request an IPv6 allocation from your RIR if you do not have one.
2. Enable IPv6 on your backbone and peering links.
3. Deploy dual-stack to subscribers — IPv6 prefix delegation plus a 100.64.x.x IPv4 address behind CGNAT.
4. Monitor IPv6 adoption metrics — track what percentage of subscriber traffic uses IPv6 versus IPv4.
5. Reduce CGNAT capacity over time as IPv6 traffic share grows.

The goal is not to eliminate CGNAT overnight but to ensure it carries a shrinking share of traffic while IPv6 handles the rest. Every new subscriber on IPv6 is one less translation the CGNAT device has to perform, one less entry in the session table, and one less log line to store.

Key points for ISP operators

CGNAT is a necessary tool in the current IPv4-scarce environment, but it carries operational costs that go beyond the price of hardware. Planning a deployment means accounting for subscriber experience, legal compliance, and the capacity to handle state at scale.

Before deploying CGNAT, an ISP operator should answer these questions:

• How many subscribers will share each public address? This determines port allocation and directly affects subscriber experience. Start conservative (1,000 ports per subscriber) and tighten only if address costs force it.
• What logging strategy will you use? Deterministic port allocation reduces log volume dramatically. Whatever you choose, test that you can answer a law enforcement query within hours, not days.
• How will you handle subscriber complaints? Create documentation for your support team explaining what CGNAT is, what it affects, and what workarounds exist (static IP add-on, IPv6). Many subscriber complaints about "slow internet" or "cannot connect to my camera" trace back to CGNAT.
• Do you offer a static public IP option? Subscribers who need inbound connectivity (businesses, remote workers with VPN requirements, hobbyist server operators) should be able to purchase a static public address as an add-on. This is also a revenue opportunity.
• When will you deploy IPv6? CGNAT buys time. IPv6 removes the constraint. The longer you wait on IPv6, the more you invest in CGNAT infrastructure that becomes unnecessary once IPv6 reaches critical mass.

CGNAT is not a permanent architecture — it is a bridge. The ISPs that treat it as temporary and invest in the IPv6 transition alongside it will spend less on address translation infrastructure over the next decade than those that double down on IPv4-only designs.