15.5 CGNAT

Understanding CGNAT

Carrier Grade Network Address Translation, usually written as CGNAT or CGN, is a large scale form of NAT that Internet Service Providers use. It allows many different customers to share a much smaller pool of public IPv4 addresses. This chapter focuses on what makes CGNAT unique compared to ordinary NAT on a home router, what problems it solves, and which new limitations it creates.

Why CGNAT Exists

IPv4 addresses are scarce. A single public IPv4 address can represent only one unique endpoint on the global Internet. When IPv4 was designed, nobody expected billions of consumer devices, cloud services, and mobile phones to all need connectivity at the same time.

Home routers and office gateways already use private addressing and NAT inside local networks, but that still requires at least one public IPv4 address per customer. For very large providers, especially mobile carriers, this is not enough. There are far more customers than public IPv4 addresses available.

CGNAT is the provider side answer. Instead of giving every customer a unique public IPv4 address, the provider places a large NAT device in its own network, shares a relatively small pool of public addresses, and maps thousands of customers behind those addresses using different port numbers.

In other words, CGNAT stretches the usefulness of the remaining IPv4 space so that providers can keep adding subscribers while IPv6 deployment is still incomplete.

Where CGNAT Sits in the Network

In a typical home or mobile setup, there are two different NAT boundaries when CGNAT is used, one in the customer network and one inside the provider network.

At home, your router converts private addresses like 192.168.1.10 to one address on the router's outside interface. That outside interface does not always have a globally reachable address when CGNAT is involved. Instead, your router may receive another private style address from the ISP, often from a special range reserved for carrier use.

The provider runs large centralized CGNAT clusters deeper in the network. These devices translate between many subscriber side addresses and a pool of real public addresses used on the Internet.

A simplified path for a packet leaving a home network with CGNAT looks like this:

1. Device in the home network with a private address, for example 192.168.1.10.
2. Home router does NAT and sends traffic out with its WAN side address, for example 100.64.12.34.
3. CGNAT device in the provider network maps 100.64.12.34 and a specific port to one of the ISP public addresses, for example 203.0.113.5:49500.
4. The packet goes to the Internet with source 203.0.113.5:49500.

This creates a situation called double NAT because translation happens twice between the local device and the public Internet.

Address Ranges Used by CGNAT

ISPs need an internal address space that is not routable on the Internet but also does not collide with normal private ranges customers use at home. To support this, RFC 6598 defines a special block of IPv4 addresses named Shared Address Space.

The shared block is:

$$
100.64.0.0/10
$$

This includes addresses from 100.64.0.0 up to 100.127.255.255.

Providers commonly assign these addresses to customer facing interfaces or intermediate hops inside the access network. If your router's WAN address starts with 100.64, that is a strong sign you are behind CGNAT. However, some providers may also use other private ranges for this purpose, such as 10.0.0.0/8, so 100.64.0.0/10 is not the only sign, just the one specifically reserved for carrier grade use.

How CGNAT Differs From Home NAT

Although CGNAT and home NAT are based on the same technical idea, there are important differences in scale, control, and flexibility.

The most important distinction is ownership and control. With normal NAT on a home router, you control the device and its configuration. You can open ports, set up port forwarding, or place devices into a DMZ depending on what the router supports. With CGNAT, the NAT function belongs to the provider. Customers are not usually allowed to configure any port forwarding on it.

Another major difference is scale. A home NAT device manages translations for perhaps dozens of local devices. A CGNAT system manages translations for thousands or even millions of subscribers at once. To do this, it requires much more processing power, optimized hardware, and sophisticated logging systems.

It also changes how identification works. With normal NAT, one customer uses one public IP address, so that address roughly represents that customer at a given time. With CGNAT, one visible public IP address might represent hundreds of different subscribers simultaneously, distinguished only by port numbers.

The table summarizes these differences.

Port Mapping and Port Exhaustion

Since many customers share a single public IP address in a CGNAT environment, the provider must rely heavily on TCP and UDP port numbers to separate traffic. Each internal flow is translated to a unique combination of public address and port.

For one public IPv4 address, there are 65,536 possible port numbers. Not all of these are usable for translation, since some are reserved or used by the carrier, but a large subset can be assigned to subscriber connections.

In practice, an ISP assigns each subscriber a limited subset of ports on one or more public addresses. This is sometimes called port slicing. If a customer opens too many simultaneous connections, they might use up all available ports from their slice.

When that happens, new connection attempts cannot be translated because there is no free public side port to map them to. This is called port exhaustion. Symptoms include some applications failing to connect, web pages loading partially, or temporary inability to create new connections until old ones time out.

Providers try to reduce port exhaustion in several ways. They might limit the number of concurrent connections per customer, use multiple public IPs across a CGNAT cluster, shorten idle timeouts, or use load balancing algorithms to spread customers across the available address and port space.

CGNAT devices must also track many more sessions than a home router. Session tables can grow very large, so the devices need efficient data structures and hardware acceleration to keep translation overhead low.

Logging and Privacy Concerns

When one public IP address is shared between many subscribers, external systems cannot uniquely identify a customer by IP alone. The mapping between customers and specific port numbers at specific times becomes the only way to do that.

To satisfy legal and regulatory requirements, ISPs that deploy CGNAT often keep detailed logs of translations. These logs usually record the internal subscriber address, the public IP and port used, the destination, and timestamps. This allows law enforcement or legal entities, under proper procedures, to trace abusive or illegal activity back to a subscriber.

This extensive logging raises important privacy questions. From the subscriber perspective, more detailed data about their online connections is stored centrally by their provider. Such logs can become attractive targets for attackers or could be misused if not properly protected.

CGNAT therefore pushes providers to treat translation logs as sensitive data. They must decide retention periods, implement access controls, and secure storage according to legal and privacy policies.

Impact on Applications and Services

CGNAT is generally transparent for simple client side activities such as web browsing or streaming. However, it can cause noticeable limitations and problems for certain types of applications, especially those that expect to accept inbound connections or rely on peer to peer communication.

Server hosting from home is the clearest example. To host a web server, game server, or any other service that needs to be reachable from the Internet, you usually configure port forwarding on your router. With CGNAT, traffic from the Internet reaches the CGNAT device first, which does not know where to send unsolicited inbound connections unless it has specific rules. Since customers cannot configure these rules, typical inbound connections are impossible.

Peer to peer and real time applications such as some games, VoIP, or file sharing tools often use NAT traversal techniques such as STUN, TURN, or hole punching. These methods try to establish direct connections between peers behind different NAT devices. Double NAT introduced by CGNAT makes this more difficult and sometimes impossible, especially if the provider uses strict policies or symmetric NAT behavior on the CGNAT device.

Some security protocols, such as IPsec in tunnel mode without UDP encapsulation, can also be problematic. Since NAT changes IP headers, protocols that authenticate those fields must adapt or encapsulate their traffic so that translation does not break integrity checks. This is covered in more detail in other chapters, but CGNAT makes correct handling even more important because multiple layers of translation can be present.

Rate limiting and connection limits are another area of impact. Since many subscribers share one address, providers sometimes restrict the number of simultaneous new connections or flows per address in order to protect their infrastructure. This can make heavy multi connection activities, like large BitTorrent sessions, behave erratically.

As a result, some applications implement special CGNAT detection logic. For example, they might check if the client's local WAN IP is within the shared address block and then assume that direct incoming connections are unlikely to work. They may switch to relay servers or other fallback mechanisms automatically.

CGNAT and Online Identity

Because one public address represents many users, CGNAT affects how external systems interpret identity, blocking, and reputation.

In a non CGNAT environment, if an IP address is associated with abusive behavior, a website or service might decide to block that address. With CGNAT, such a block would affect every subscriber currently sharing that address, including innocent users. This can result in situations where some customers find themselves locked out of websites or services due to actions taken by others behind the same CGNAT IP.

Similarly, rate limiting based on public IP can penalize all users sharing that address. If a website allows five login attempts per IP per minute, and dozens of users behind the same CGNAT IP try to log in, some of them may face delays or temporary blocks.

To manage this, some websites use additional identifiers such as cookies, tokens, device fingerprints, or account based checks instead of relying on the IP address alone. Despite that, IP based controls remain common and can contribute to user frustration when CGNAT is involved.

CGNAT Detection from the User Side

Ordinary users often want to know whether they are behind CGNAT, especially when they plan to host services or troubleshoot connectivity problems.

There are a few indirect methods to guess the presence of CGNAT. One is to compare the IP address reported by an external "what is my IP" website with the IP address on the WAN interface of the router. If they are different, the router may be receiving a private or shared address from the ISP and the public one is assigned at a CGNAT device. If the WAN address falls inside 100.64.0.0/10, that is a strong indicator of CGNAT use.

Another approach is to look for double NAT indicators on home routers. Some devices explicitly show a warning when they detect that their upstream address is private or from the shared block, and that the Internet connection passes through more than one NAT boundary.

Finally, users can ask the provider directly. Many ISPs will state whether they use CGNAT and may offer options such as a dedicated public IPv4 address, sometimes for an additional charge, for customers who need inbound connectivity.

CGNAT and IPv6 Transition

CGNAT is often described as a temporary measure introduced to slow down IPv4 address exhaustion until IPv6 is widely deployed. In practice, it has already been in use for many years and is deeply integrated into mobile and broadband networks.

From a design perspective, CGNAT does not solve the fundamental limitation of IPv4. It only allows providers to stretch a finite resource further. It also introduces operational costs, increases network complexity, and can degrade the user experience for some services.

IPv6, with its vastly larger address space, can eliminate the need for CGNAT by giving every device a globally unique address. However, the transition to IPv6 is gradual. During this period, CGNAT often coexists with IPv6 deployments. For example, a provider may assign IPv6 prefixes directly to customers while keeping IPv4 traffic behind CGNAT for legacy services.

In such dual stack or transition scenarios, some providers encourage customers to prefer IPv6 capable services. When traffic uses IPv6, it bypasses CGNAT entirely and may experience fewer restrictions. Over time, as more services and client devices support IPv6, the relative importance of CGNAT may decrease.

Practical Workarounds and Alternatives

Users who are affected by CGNAT constraints, particularly the inability to accept incoming connections, have several potential workarounds, although none of them are universal.

Some providers offer static or dynamic public IPv4 addresses for an additional fee. In that case, the customer line is removed from CGNAT and is assigned a direct public address instead. All traditional port forwarding configurations become possible again on the home router.

Another option is to build tunnels that start outbound from the CGNAT side. Since outbound connections are generally permitted, users can create a VPN or SSH tunnel from a device behind CGNAT to a server with a public IP address. Remote clients then connect to that server, which forwards traffic over the tunnel. In this way, the remote server acts as a fixed point on the Internet while the CGNAT user initiates the only required outward connection.

Specialized relay and overlay services, such as some gaming platforms and remote access tools, are designed to operate successfully even when all participants are behind some form of NAT or CGNAT. They function as intermediaries that both sides can reach from the inside.

There are also devices and software that integrate IPv6 with IPv4 connectivity. If a user has native or tunneled IPv6 connectivity, they can run services that listen on IPv6 addresses and bypass the entire CGNAT structure on the IPv4 side. However, this requires remote clients to support IPv6 and to have IPv6 connectivity as well.

Each of these methods comes with trade offs in complexity, cost, and performance. CGNAT remains a structural constraint that cannot be fully removed from the user side without cooperation from the provider or use of external infrastructure.

Limitations and Risks for Providers

For providers, CGNAT introduces its own risks and limitations. The concentration of many subscribers behind shared addresses creates points of failure. If a CGNAT cluster fails, the outage can affect a large portion of the subscriber base. This drives providers to invest in redundancy, high availability, and careful capacity planning.

Security is another concern. CGNAT devices are attractive targets because they handle large volumes of subscriber traffic. A successful attack on a CGNAT system might enable interception or disruption of many users at once. Providers must therefore treat CGNAT systems as critical security assets and protect them accordingly.

Scaling is both a technical and financial challenge. As subscriber numbers and bandwidth demands grow, session tables increase and logging requirements become heavier. Hardware and software must keep up with these demands without introducing significant latency or packet loss.

Finally, providers must navigate the tension between maximizing IPv4 address efficiency and maintaining a reasonable user experience. Aggressive sharing of addresses and tight port limits save address space but can damage service quality and lead to support calls. Relaxing those limits improves the user experience but consumes more IPv4 resources.

These practical constraints encourage providers to continue investing in IPv6 deployment as a long term exit path, while using CGNAT as an intermediate strategy that needs careful design and ongoing management.