What is CGNAT? Carrier-Grade NAT Explained

Carrier-Grade NAT (CGNAT) is a large-scale Network Address Translation deployment where an ISP translates thousands of subscribers' addresses through a shared pool of public IPv4 addresses. Unlike the NAT running on your home router -- which maps your private 192.168.x.x addresses to the single public IP your ISP assigned -- CGNAT sits upstream in the ISP's network, mapping many customers' addresses to a much smaller number of public addresses. A subscriber behind CGNAT is double-NATted: their device's private address is translated by their home router, and then the router's WAN address (itself not a globally routable address) is translated again by the ISP's CGNAT device before reaching the internet.

CGNAT exists because IPv4 addresses ran out. IANA allocated its last five /8 blocks to the Regional Internet Registries in 2011, and most RIRs have since exhausted their free pools. ARIN ran out in 2015. RIPE NCC now allocates a maximum /24 (256 addresses) to new members. The market price for IPv4 addresses has risen to $40-60 per address. ISPs connecting new subscribers -- especially in mobile, rural broadband, and developing markets -- simply do not have enough public IPv4 addresses to give one to every customer. CGNAT lets them serve 10, 50, or even 1000 subscribers behind each public address.

The 100.64.0.0/10 Shared Address Space (RFC 6598)

When ISPs began deploying CGNAT, they initially used RFC 1918 private address space (10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16) for the addresses assigned to customer equipment. This caused collisions: if a subscriber's home network uses 10.0.0.0/8 internally and the ISP also assigns the customer's WAN interface a 10.x.x.x address, the customer cannot reach internal ISP infrastructure, and routing breaks in confusing ways.

RFC 6598 (April 2012) solved this by reserving a new address block specifically for CGNAT: 100.64.0.0/10, providing 4,194,304 addresses (100.64.0.0 through 100.127.255.255). This "shared address space" is distinct from both private (RFC 1918) and public addresses. You can look up 100.64.0.0 in the looking glass to verify that no autonomous system announces this prefix in BGP -- it is not supposed to appear in the global routing table.

Key properties of the 100.64.0.0/10 shared address space:

• Not globally routable. Packets with source or destination addresses in 100.64.0.0/10 must not be forwarded across network boundaries. ISPs must filter this range at their borders, the same way they filter RFC 1918 space.
• Not for end-user networks. This space is exclusively for the link between the ISP's CGNAT device and the customer premises equipment (CPE). Customers should not use it for their internal LANs.
• Distinct from RFC 1918. A customer using 10.0.0.0/8 internally will not collide with their ISP's 100.64.x.x assignment. The two address spaces are disjoint by design.
• Reverse DNS undefined. There is no standardized PTR record delegation for 100.64.0.0/10. Some ISPs set up internal reverse DNS; many do not. This can affect diagnostics tools like traceroute that rely on reverse lookups.

In practice, ISPs deploy the 100.64.0.0/10 space on the subscriber-facing interfaces of their CGNAT devices and on the WAN interfaces of customer CPE (cable modems, DSL modems, ONTs). The subscriber never sees this address directly -- their home router presents a 192.168.x.x gateway on the LAN side. But if you log into your home router's admin interface and check the WAN IP, seeing an address in the 100.64.0.0/10 range is the definitive indicator that you are behind CGNAT.

Deterministic NAT vs. Dynamic NAT

CGNAT implementations fall into two fundamental architectures, each with radically different tradeoffs for logging, scalability, and subscriber experience.

Dynamic (Bulk) Port Allocation

In dynamic CGNAT, the NAT device assigns external address:port mappings on demand as subscribers open connections. When a subscriber initiates a new flow, the CGNAT selects an available (public IP, port) pair from its pool and creates a mapping. Ports are typically allocated in bulk -- blocks of 64, 128, or 256 ports at a time -- to reduce per-connection overhead and the rate of allocation/deallocation operations.

Dynamic allocation maximizes utilization: ports are only consumed when subscribers actually need them, and a quiet subscriber consumes zero ports from the public pool. The downside is that every allocation event must be logged. If the CGNAT assigns 128-port blocks, every block allocation and deallocation generates a log entry recording which subscriber received which external address and port range at which timestamp. At scale -- millions of subscribers, each opening and closing connections constantly -- this produces an enormous volume of log data.

Deterministic NAT

Deterministic NAT eliminates per-connection logging entirely by establishing a fixed, algorithmic mapping between subscriber addresses and external addresses/ports. Given a subscriber's internal address (e.g., 100.64.1.7), the CGNAT can compute the external address and port range without any state lookup. Typically, the port space (1024-65535 = 64,512 usable ports) is divided evenly across subscribers sharing each public IP:

Because the mapping is deterministic, no per-flow logging is required. Given a timestamp and an external address:port, law enforcement or abuse handlers can compute which subscriber held that mapping without consulting any log database. The ISP only needs to record the deterministic mapping configuration (which block of subscriber addresses maps to which public IPs and port ranges), plus any changes to that configuration.

The downside is inefficiency. Every subscriber gets the same port allocation regardless of their actual usage. A subscriber running a single browser tab gets the same 1,008 ports as one running a BitTorrent client with hundreds of connections. If the per-subscriber port allocation is too small, heavy users hit port exhaustion. If it is too large, light users waste ports that could serve additional subscribers.

Port Exhaustion: The Hard Limit

Port exhaustion is the central scaling problem of CGNAT. A single IPv4 address has 65,535 TCP ports and 65,535 UDP ports. Subtracting the well-known ports (0-1023) and accounting for protocol overhead, roughly 64,000 ports per protocol are available for NAT mappings. When multiple subscribers share a public address, the port space is divided among them, and each subscriber's effective port budget shrinks proportionally.

A typical residential subscriber consumes 100-500 ports during normal browsing. Each open tab, background service, and DNS query consumes at least one port mapping. Mobile apps are more aggressive -- a modern smartphone with push notifications, background sync, analytics, and ad networks can maintain 50+ simultaneous connections at idle. A household with multiple devices can easily sustain 500-2,000 concurrent connections.

The problem compounds when applications hold ports open. WebSocket connections for real-time apps (chat, notifications, collaborative editing) persist for minutes or hours. BitTorrent opens hundreds of peer connections simultaneously. Game clients maintain persistent connections to multiple servers. VoIP applications like WebRTC hold media channels open for the duration of a call.

When a subscriber's port allocation is exhausted, new connections fail. The symptoms vary by protocol: HTTP requests timeout or return connection errors, DNS lookups fail causing cascading application failures, and real-time applications drop. From the subscriber's perspective, "the internet is broken" -- but only for them, not for their neighbor who is on the same CGNAT but hasn't hit the limit.

ISPs mitigate port exhaustion through several mechanisms:

• Aggressive timeouts. Reducing the NAT mapping timeout reclaims ports faster. TCP established timeouts are often reduced from the default 5 days to 2-4 hours. UDP timeouts are reduced from 30 seconds to as low as 15-30 seconds. This accelerates port recycling but can break long-lived idle connections and applications that assume longer timeouts.
• Increasing the public IP pool. More public addresses means more ports per subscriber. Doubling the pool doubles the available port space. But public IPv4 addresses cost $40-60 each, so expanding the pool has a direct financial cost.
• Per-subscriber port limits. Capping the maximum number of ports a single subscriber can consume prevents one heavy user from starving others. Typical limits are 1,000-4,000 ports per subscriber.
• Endpoint-independent mapping. Reusing the same external port for multiple connections to different destinations reduces port consumption (discussed below).

NAT Mapping Behavior: EIM vs. EIF

RFC 4787 defines the behavioral properties of NAT devices using precise terminology. Two properties are particularly important for CGNAT: the mapping behavior and the filtering behavior. These determine how the NAT creates and enforces address/port mappings, and they have a direct impact on which applications work through the NAT.

Endpoint-Independent Mapping (EIM)

An EIM NAT reuses the same external address:port mapping for all outgoing connections from the same internal address:port, regardless of the destination. If internal host 100.64.1.7:5000 is mapped to 203.0.113.3:18742 for a connection to server A, then a subsequent connection from 100.64.1.7:5000 to server B will also use 203.0.113.3:18742 as the source.

EIM is critical for peer-to-peer applications and NAT traversal techniques like STUN. When two peers behind different NATs want to communicate directly (as in WebRTC, VoIP, or multiplayer gaming), they use a rendezvous server to exchange their external address:port mappings. This only works if the NAT reuses the same mapping regardless of the destination -- i.e., if the mapping is endpoint-independent. With address-dependent or address-and-port-dependent mapping, the external port changes for every new destination, making the exchanged mapping useless.

Endpoint-Independent Filtering (EIF)

EIF determines whether the NAT accepts incoming packets on a mapped port from any source, or only from the original destination. With EIF, once a mapping exists (e.g., 203.0.113.3:18742 maps to 100.64.1.7:5000), any external host can send packets to 203.0.113.3:18742 and they will be forwarded to the internal host. With address-dependent filtering (ADF), only the destination that the internal host originally contacted can send return packets. With address-and-port-dependent filtering (APDF), both the source address and port must match.

EIF is the most permissive and makes P2P connectivity easiest, but it also exposes internal hosts to unsolicited inbound traffic -- essentially, any host on the internet can send packets to a mapped port. Most CGNAT deployments use ADF as a compromise: it allows STUN-based NAT traversal (because the mapped external port is reachable by the peer once the peer's address is known via the rendezvous server) while blocking fully unsolicited traffic.

RFC 4787 recommends EIM for UDP NAT, and RFC 7857 extends this recommendation to CGNAT specifically. The combination of EIM + ADF is the most common CGNAT configuration: consistent port mappings for traversal, with source-address-based filtering for security.

Logging Requirements and RFC 7422

Legal compliance is one of the most operationally demanding aspects of CGNAT. When a public IPv4 address is shared by multiple subscribers, the address alone is insufficient to identify which subscriber was responsible for a given connection at a given time. Law enforcement, abuse reports, and DMCA takedowns all require the ISP to identify the specific subscriber. This means the ISP must log enough information to reconstruct the subscriber-to-public-mapping at any point in time.

RFC 7422 ("Deterministic Address Mapping to Reduce Logging in Carrier-Grade NAT Deployments") explicitly addresses this problem. It recommends deterministic NAT as a way to reduce logging requirements. With dynamic NAT, the ISP must log every port block allocation and deallocation event -- potentially billions of log entries per day for a large ISP. With deterministic NAT, the ISP only logs the mapping algorithm configuration and any changes to it.

The logging burden for dynamic CGNAT is staggering. Consider an ISP with 1 million subscribers, each averaging 200 port block allocations per day (accounting for bulk allocation with blocks of 128 ports). That is 200 million log entries per day, each containing:

• Timestamp (millisecond precision)
• Subscriber internal address (100.64.x.x)
• External public address
• Allocated port range (start port, end port)
• Protocol (TCP/UDP)
• Event type (allocation/deallocation)

At roughly 100-200 bytes per entry, that is 20-40 GB of raw log data per day, or 7-15 TB per year. This data must be stored, indexed, and queryable for the retention period mandated by local law (typically 6-24 months). The storage, indexing, and query infrastructure for CGNAT logs is a significant operational cost that ISPs must factor into their CGNAT deployment.

Some ISPs use a hybrid approach: deterministic mappings for the majority of subscribers (eliminating per-flow logging), with a dynamic overflow pool for subscribers who exceed their deterministic port allocation. Only the overflow allocations require per-event logging, dramatically reducing the log volume.

Impact on Applications

Gaming

Online gaming is one of the applications most affected by CGNAT. Many game protocols rely on direct peer-to-peer connectivity or expect the ability to receive unsolicited inbound connections. Console gaming platforms (Xbox Live, PlayStation Network) historically used UPnP or NAT-PMP to configure port forwarding on the home router -- but these protocols only affect the home router (NAT #1), not the ISP's CGNAT (NAT #2). The result is that CGNAT subscribers often see "strict" or "moderate" NAT type classifications in their console settings, meaning peer-to-peer matchmaking is restricted and they can only connect through relay servers.

Game servers that rely on a subscriber's ability to host (dedicated servers for games like Minecraft, or peer-hosted lobbies) are effectively impossible behind CGNAT without additional tunnel or relay infrastructure. The subscriber has no public IP to advertise and no way to configure port forwarding on the CGNAT device. This has pushed game architecture toward client-server models with centralized matchmaking and relay servers, increasing infrastructure costs for game developers.

VoIP and Real-Time Communication

VoIP protocols like SIP were designed before NAT was ubiquitous and embed IP addresses in application-layer signaling messages. SIP INVITE messages contain SDP bodies with the caller's IP address and media ports. Behind CGNAT, these addresses are 100.64.x.x or 192.168.x.x -- neither of which is reachable from the public internet. This breaks call setup unless the VoIP application uses STUN/TURN to discover and relay through the external address.

Modern VoIP and WebRTC applications handle this through ICE (Interactive Connectivity Establishment), which systematically tries direct connectivity, STUN-assisted connectivity, and TURN relay as fallback. CGNAT increases the likelihood that calls must be relayed through a TURN server rather than connected directly, adding latency and cost. For ISPs that also offer voice services, CGNAT can degrade their own VoIP product unless voice traffic is exempted from the CGNAT or given priority in the NAT mapping table.

Peer-to-Peer

BitTorrent and other P2P protocols are heavily impacted by CGNAT. BitTorrent clients behind CGNAT cannot accept incoming connections from peers, reducing their connectivity to a fraction of the swarm. The client can still initiate outbound connections, but many peers in the swarm are also behind NAT (regular or carrier-grade), making mutual connectivity impossible without a relay. Worse, BitTorrent clients are among the heaviest consumers of NAT state -- a single client can maintain hundreds of simultaneous connections, rapidly consuming port allocations.

ISPs have historically throttled or deprioritized P2P traffic; CGNAT provides a technical mechanism that achieves a similar effect without explicit traffic management. By limiting per-subscriber ports, the ISP implicitly caps the number of peer connections a BitTorrent client can maintain.

Port-Sensitive Services

Any service that requires a stable public IP or uses IP addresses for access control is broken by CGNAT. IP-based geolocation becomes less accurate when many subscribers share a single address. IP reputation systems may blacklist a shared public address because of one subscriber's abuse, affecting all subscribers sharing that address. Rate limiting based on source IP penalizes every subscriber behind the same CGNAT public address collectively. SMTP servers that check connecting IPs against blocklists may reject mail from CGNAT addresses, since the shared IP may appear on spam lists due to another subscriber's behavior.

Port Control Protocol (PCP)

Port Control Protocol (RFC 6887) was designed specifically to give end hosts a way to request explicit port mappings from upstream NAT devices, including CGNAT. PCP is the successor to NAT-PMP (which only worked with the directly connected NAT) and is designed to traverse multiple layers of NAT.

A PCP client sends a MAP request to the CGNAT device, asking for a specific external port to be forwarded to the client's internal address and port. If the CGNAT supports PCP and the request can be satisfied, the CGNAT creates a mapping and returns the assigned external address and port. The client can then advertise this address to external peers, effectively punching a hole through the CGNAT.

PCP solves several CGNAT problems:

• Server hosting. A subscriber can request a port mapping and run a server reachable from the public internet, even behind CGNAT.
• P2P connectivity. Applications can request mappings and exchange them with peers, enabling direct connectivity without TURN relays.
• Long-lived mappings. PCP allows requesting specific lifetimes for mappings, preventing the CGNAT from timing out a mapping that the application still needs.
• Third-party mappings. PCP supports THIRD_PARTY option, allowing a control plane element (like an IoT hub) to request mappings on behalf of devices that cannot run PCP themselves.

In practice, PCP adoption in ISP CGNAT deployments has been limited. Many ISPs see unrestricted inbound port mappings as a security concern and choose not to enable PCP. Others support it but limit the number of mappings per subscriber. The result is that most applications cannot rely on PCP and must use STUN/TURN-based traversal or relay infrastructure as fallback. Apple's Back to My Mac and several smart home platforms attempted to use PCP/NAT-PMP, but the inconsistent support across ISP NAT devices limited their reliability.

How ISPs Deploy CGNAT

CGNAT deployment is a significant infrastructure decision that affects every subscriber on the network. ISPs take several approaches depending on their network architecture, subscriber base, and IPv4 address inventory.

Centralized CGNAT

The simplest deployment places CGNAT appliances at a central aggregation point -- typically the ISP's core or distribution layer. All subscriber traffic passes through the CGNAT on the way to the internet. This simplifies management (one or two CGNAT clusters to operate) but creates a single point of failure and a potential bottleneck. Each CGNAT appliance must handle the aggregate traffic of all subscribers behind it, which at large ISPs can be hundreds of gigabits per second.

Centralized CGNAT also introduces additional latency, since subscriber traffic must traverse the ISP's network to reach the CGNAT before exiting to the internet. For ISPs with geographically distributed networks, this can add several milliseconds of round-trip time.

Distributed CGNAT

Larger ISPs distribute CGNAT function across multiple points in their network -- at regional aggregation routers, at the BRAS/BNG (Broadband Network Gateway), or even at the access node. Distributed deployment reduces the blast radius of a CGNAT failure, keeps traffic paths shorter, and distributes the processing load. The tradeoff is operational complexity: more CGNAT instances to manage, configure, monitor, and keep in sync regarding logging and port allocation policy.

CGNAT on the BNG

Some ISPs run CGNAT as a function on their Broadband Network Gateways (BNGs), which are the routers that terminate subscriber sessions (PPPoE or IPoE). This eliminates a separate CGNAT appliance entirely, reducing cost and latency. Modern BNG platforms from vendors like Juniper (MX series), Nokia (7750 SR), and Cisco (ASR 9000) support inline CGNAT as a service card or software function. The BNG already terminates every subscriber session, so it has natural visibility into subscriber identity -- simplifying the mapping between CGNAT state and subscriber accounting.

Selective vs. Universal CGNAT

Not all ISPs put every subscriber behind CGNAT. Many use a selective approach:

• New subscribers only. Existing subscribers keep their public IPv4 address. Only new subscribers who connect after the ISP's public address pool is exhausted are placed behind CGNAT.
• Mobile only. Mobile networks were early adopters of CGNAT because cellular subscribers are almost exclusively clients (not servers) and the mobile subscriber base grows rapidly. Many fixed broadband ISPs still assign public IPv4 while their mobile arm uses CGNAT.
• Tiered offerings. Some ISPs offer a public IPv4 address as a premium add-on (for a monthly fee) or as part of business-tier plans, while residential plans use CGNAT. This creates a revenue stream from IPv4 scarcity.
• IPv6 + CGNAT. ISPs deploying dual-stack give subscribers a public IPv6 prefix (typically a /56 or /48) and use CGNAT only for IPv4 traffic. Since an increasing share of traffic (Google reports ~45% globally, higher in some regions) uses IPv6 natively, the CGNAT handles a shrinking fraction of total traffic.

CGNAT and IPv6 Transition

CGNAT and IPv6 are not competing solutions -- they are complementary. CGNAT extends the life of IPv4 while IPv6 deployment reaches critical mass. Several transition mechanisms explicitly combine the two.

DS-Lite (Dual-Stack Lite)

DS-Lite (RFC 6333) is a transition mechanism where the ISP runs an IPv6-only access network. Subscriber CPE receives only an IPv6 address from the ISP -- no IPv4 at all. When a subscriber needs to reach an IPv4 destination, the CPE encapsulates the IPv4 packet inside an IPv6 tunnel (using the B4 element at the customer side and the AFTR -- Address Family Transition Router -- at the ISP side). The AFTR performs CGNAT on the decapsulated IPv4 packets before forwarding them to the IPv4 internet.

DS-Lite is elegant in that it eliminates the need for per-subscriber IPv4 address assignment entirely. The ISP only needs a pool of IPv4 addresses at the AFTR for CGNAT. Many European ISPs (Deutsche Telekom, Free in France) have deployed DS-Lite at scale.

MAP-E and MAP-T

MAP (Mapping of Address and Port) distributes CGNAT function to the subscriber CPE itself. In MAP-E (Encapsulation, RFC 7597), the CPE performs the IPv4-to-IPv6 encapsulation and the port-restricted NAT. Each CPE is assigned a specific range of ports on a shared public IPv4 address, and the mapping is encoded algorithmically from the CPE's IPv6 prefix. The ISP's border relay simply decapsulates and routes. MAP-T (Translation, RFC 7599) does the same with stateless IPv4/IPv6 translation instead of encapsulation.

MAP eliminates the centralized CGNAT bottleneck entirely -- the NAT function is distributed across all subscriber CPEs. The ISP's border relay is stateless, making it extremely scalable. Japanese ISPs have been early adopters of MAP-E, deploying it at scale to handle the combination of massive subscriber counts and severe IPv4 scarcity.

464XLAT

464XLAT (RFC 6877) is the dominant IPv6 transition mechanism for mobile networks. The mobile device runs a CLAT (Customer-side Translator) that translates IPv4 packets from legacy applications into IPv6, sends them over the IPv6-only mobile network, and an ISP-side PLAT (Provider-side Translator) translates them back to IPv4 for the destination. Like MAP, the heavy lifting is distributed: the PLAT is stateless (using NAT64/DNS64), and the per-subscriber state is on the device itself.

T-Mobile US deployed 464XLAT across its entire network, running IPv6-only on the radio access network. All IPv4 traffic from mobile devices is translated through 464XLAT. This is one of the largest CGNAT-equivalent deployments in the world, and it works because the majority of traffic (>90% on T-Mobile's network) uses IPv6 natively, so the 464XLAT path handles a small fraction of total traffic.

Detecting CGNAT

There are several ways to determine if you are behind CGNAT:

1. Check your router's WAN IP. Log into your home router and look at the WAN/Internet IP address. If it is in the 100.64.0.0/10 range, you are behind CGNAT. Some ISPs use RFC 1918 space (10.x.x.x) for CGNAT, which also indicates it.
2. Compare your router's WAN IP to your public IP. Visit the looking glass or run curl ifconfig.me. If your public IP differs from your router's WAN IP, there is an additional NAT between you and the internet.
3. Traceroute analysis. Run a traceroute to an external destination. If you see hops with 100.64.x.x addresses, those are the ISP's CGNAT infrastructure. Note that some CGNAT devices do not decrement TTL (making them invisible to traceroute), and some ISPs filter ICMP from CGNAT addresses.
4. Port forwarding test. Try to set up port forwarding on your home router and test it from an external source. If the port is not reachable despite correct router configuration, CGNAT is blocking inbound connections.

CGNAT Hardware and Performance

CGNAT at ISP scale demands specialized hardware or high-performance software implementations. The CGNAT device must process every packet of every subscriber's internet traffic, maintain millions of concurrent NAT mappings, and handle hundreds of thousands of new connection setups per second.

Dedicated CGNAT appliances from vendors like A10 Networks (Thunder CGN), F5 (BIG-IP CGNAT), and Juniper (MX series with MS-MPC/MIC) are designed for this workload. A modern CGNAT appliance can handle:

• Throughput: 100-400 Gbps per appliance
• Concurrent sessions: 64-256 million NAT mappings
• Connection rate: 2-10 million new connections per second
• Subscribers: 100,000-1,000,000 per appliance

Software-based CGNAT running on commodity x86 servers (using DPDK or VPP for fast packet processing) has become increasingly viable. ISPs can run CGNAT as a virtual network function (VNF) on standard servers, avoiding vendor lock-in and reducing hardware costs. The tradeoff is that x86-based CGNAT typically achieves lower per-node throughput (10-100 Gbps) than dedicated appliances, requiring more nodes to serve the same subscriber count.

Operational Challenges

Running CGNAT at scale introduces a category of operational problems that ISPs without CGNAT never encounter:

• Abuse handling complexity. Every abuse report includes an IP address and timestamp. Without CGNAT, the ISP can directly identify the subscriber. With CGNAT, the ISP must also have the source port to look up the mapping. Many abuse reports, DMCA notices, and law enforcement requests do not include the source port, making them impossible to resolve. ISPs must either educate complainants to include port information or implement systems that can match on partial information.
• IP reputation impact. When one subscriber behind a CGNAT address sends spam or participates in a botnet, the shared public IP gets blacklisted, affecting every other subscriber sharing that address. ISPs must monitor blacklist status of their CGNAT pool and rotate addresses or move problematic subscribers to dedicated addresses.
• Geolocation accuracy. Geolocation databases associate IP addresses with physical locations. A single CGNAT address may serve subscribers across a wide geographic area, causing geolocation to return the wrong city or region. This affects content licensing (streaming services), ad targeting, and fraud detection systems that rely on IP geolocation.
• Service rate limiting. Web services that rate-limit by source IP will rate-limit all subscribers behind a CGNAT address collectively. If the rate limit is 100 requests per minute per IP, and 500 subscribers share that IP, each subscriber's effective rate limit is a fraction of what it would be with a dedicated address. This is particularly problematic for API rate limits, CAPTCHA triggers, and anti-fraud systems.
• Failover and high availability. CGNAT devices maintain millions of stateful mappings. If a CGNAT appliance fails, all those mappings are lost, breaking every active connection for every affected subscriber. CGNAT deployments require stateful failover (session synchronization between active and standby appliances) to maintain mappings during failover, which doubles the hardware investment and adds complexity.

CGNAT and TCP/UDP Differences

CGNAT handles TCP and UDP differently due to the protocols' different connection semantics:

TCP has explicit connection setup (SYN/SYN-ACK/ACK) and teardown (FIN/FIN-ACK or RST). The CGNAT can track connection state precisely: it creates a mapping when it sees a SYN, and it can release the mapping when it sees a FIN exchange or RST. Timeouts for established TCP connections are typically 2-4 hours (down from the Linux default of 5 days). For TCP connections in other states (SYN_SENT, TIME_WAIT), timeouts are shorter (30-120 seconds).

UDP is connectionless. The CGNAT must rely entirely on timeouts to determine when a mapping is no longer needed. UDP mappings typically expire after 30-120 seconds of inactivity. This creates problems for applications that send infrequent UDP packets (DNS resolvers with long TTL responses, QUIC connections during idle periods, game clients in lobby). If the mapping expires between packets, the next packet gets a new external port, breaking the application's notion of a stable endpoint. QUIC (HTTP/3) is designed to handle this through connection migration -- when the external port changes, QUIC can resume the connection on the new port using its connection ID, rather than relying on the 5-tuple. This is one of the key advantages of QUIC over TCP for NAT-heavy environments.

ICMP presents a special challenge. ICMP has no ports, so the CGNAT must use a different identifier for NAT mappings. For ICMP Echo (ping), the CGNAT uses the ICMP identifier field as a pseudo-port. For other ICMP types (errors, unreachable messages), the CGNAT must inspect the embedded original packet header to match the ICMP message to the correct subscriber's mapping. This deep inspection adds processing overhead and complexity.

The Future of CGNAT

CGNAT deployment will continue to grow as IPv4 scarcity intensifies. The remaining freely available IPv4 space is concentrated in a few RIRs (AFRINIC has the most remaining space), and transfer market prices continue to rise. New ISPs and expanding networks in Africa, South Asia, and Southeast Asia face the steepest IPv4 costs and are the heaviest CGNAT adopters.

Simultaneously, IPv6 adoption continues its slow trajectory upward. As more content providers, CDNs, and cloud platforms offer native IPv6, the fraction of traffic requiring IPv4 (and thus CGNAT) shrinks. ISPs deploying dual-stack with CGNAT for IPv4 and native IPv6 find that their CGNAT devices handle a decreasing share of total traffic over time, which eases scaling pressure and extends the useful life of their public IPv4 address pools.

The endgame is an IPv6-only internet where CGNAT becomes unnecessary. But given the current rate of IPv6 adoption, CGNAT will remain a critical piece of ISP infrastructure for at least another decade. For network engineers, understanding CGNAT -- its mechanisms, limitations, and failure modes -- is essential to diagnosing connectivity problems in an internet where most subscribers no longer have a public IPv4 address of their own.

Look Up the Shared Address Space

The 100.64.0.0/10 shared address space should never appear in the global BGP routing table. Use the god.ad looking glass to verify this -- a lookup of 100.64.0.0 should return no route, confirming that ISPs are correctly filtering this space at their borders. If you are curious about your own public IP (the one after CGNAT translation), look it up to see which autonomous system announces the prefix you are sharing with other subscribers.