Carrier-Grade NAT (CGNAT) Explained

If you have ever tried to self-host a server, set up a gaming lobby, or use a P2P application from a home internet connection and found it mysteriously impossible — Carrier-Grade NAT (CGNAT) may be the culprit. Understanding CGNAT explains one of the most consequential — and frustrating — aspects of how modern ISPs manage their networks.

The IPv4 Address Exhaustion Problem

The internet runs on IPv4 addresses, of which there are approximately 4.3 billion. By 2011, IANA had distributed the last blocks of unallocated IPv4 addresses to the Regional Internet Registries. By 2019, RIPE NCC (covering Europe and the Middle East) had completely exhausted its IPv4 pool.

ISPs face a structural problem: they have more customers than they have IPv4 addresses. Traditional home NAT (NAT44) solved this at the customer premises — one public IP shared by a household with a router. But as mobile devices, IoT, and new subscribers proliferate, even one-public-IP-per-household is too expensive.

Carrier-Grade NAT (CGNAT), also called Large-Scale NAT (LSN), solves this by adding a second layer of NAT at the ISP level — sharing a single public IPv4 address among potentially hundreds or thousands of subscribers.

How CGNAT Works

In a traditional home network:

Internet
    |
Public IP: 203.0.113.45  ← ISP assigns one per customer
    |
Home Router (NAT44)
    |
Private IPs: 192.168.1.x  ← Your devices

With CGNAT, the ISP inserts another NAT layer:

Internet
    |
Public IP: 203.0.113.45  ← Shared among many CGNAT customers
    |
ISP CGNAT Gateway (NAT444)
    |
"Shared" IP: 100.64.0.x  ← ISP assigns this to your CPE
    |
Your Home Router (NAT44)
    |
Private IPs: 192.168.1.x  ← Your devices

A single public IP might serve 100-1000 subscribers simultaneously. The CGNAT device tracks which (public IP, port) combination belongs to which subscriber's traffic.

The 100.64.0.0/10 Address Space

CGNAT requires a special address range that is neither globally routable nor RFC 1918 private. Why not just use RFC 1918? Because many customers' home routers also use RFC 1918 addresses — overlapping ranges would cause routing confusion.

RFC 6598 reserved 100.64.0.0/10 specifically for use between ISP CGNAT gateways and customer premises equipment (CPE). This range covers:

100.64.0.0 to 100.127.255.255
(~4 million addresses)

If your device's "public" IP address starts with 100.64., 100.65., ... through 100.127., you are behind CGNAT.

This range is sometimes called Shared Address Space. It is not routable on the public internet, not usable for private internal networks (in theory), and not assignable to public-facing services.

Detecting CGNAT

Several methods reveal whether your connection uses CGNAT:

Check Your WAN IP vs. External IP

# Your router's WAN IP (what the ISP assigned your router)
# Check router admin panel: 192.168.1.1 → WAN status

# Your external IP as seen from the internet
curl https://api.ipify.org
curl https://icanhazip.com

If the router WAN IP starts with 100.64.x.x through 100.127.x.x, you are behind CGNAT.

If the WAN IP looks like a public address (not RFC 1918, not 100.64/10) but differs from what internet sites report, you may be behind a transparent CGNAT that assigns non-100.64 addresses internally.

Traceroute Analysis

traceroute 8.8.8.8

If you see two hops with private or 100.64/10 addresses before reaching the public internet, CGNAT is present.

Test Inbound Connectivity

CGNAT makes inbound connections impossible by default. Try having an external service attempt to connect to your IP on a port:

• Use portchecker.co or similar to test if a port is open
• If port checks always fail even with firewall/NAT properly configured, CGNAT is the likely cause

Impact on Applications and Services

Self-Hosting and Port Forwarding

CGNAT completely breaks traditional port forwarding. Even if you configure your router to forward port 80 to an internal server, external users cannot reach 203.0.113.45:80 because that public IP is shared — the ISP CGNAT device has no rule to forward traffic to you specifically.

This affects: - Web server hosting - Game server hosting - Home automation (Home Assistant, etc.) with remote access - IP cameras and DVRs - Any service requiring inbound connections

Online Gaming

Many online games use peer-to-peer connections for voice chat or game state synchronization. P2P requires at least one party to accept inbound connections. Two players both behind CGNAT cannot establish a direct P2P connection — the game must relay through a TURN server, increasing latency.

Game consoles report this as "NAT Type Strict" or "NAT Type D" (Nintendo), indicating inbound connections are blocked.

P2P File Sharing

BitTorrent and similar protocols work much better when a client can accept inbound connections (being "connectable"). CGNAT users are only connectable through relay mechanisms, limiting download speeds and reducing ability to seed.

VoIP

SIP/VoIP protocols embed IP addresses in protocol messages (SDP body). When behind CGNAT, the embedded address is private and unreachable by external parties. SIP ALG (Application Layer Gateway) on routers partially addresses this, as does STUN, but CGNAT complicates VoIP significantly.

Remote Desktop / VPN Server

Running an RDP server, SSH server, or VPN endpoint at home becomes impossible under CGNAT without a workaround.

Port Allocation Under CGNAT

Since hundreds of users share one public IP, the CGNAT gateway must allocate TCP/UDP ports carefully. RFC 6888 defines best practices:

Port Block Allocation (PBA): Rather than allocating individual ports on-demand, the CGNAT device pre-allocates a block of ports (e.g., 1000 ports) to each subscriber. This: - Reduces state table churn - Enables logging (you can audit which subscriber used which port range at what time) - Creates a hard limit on concurrent connections per subscriber

A typical allocation might be: - Subscriber A: ports 10000-10999 on public IP 203.0.113.45 - Subscriber B: ports 11000-11999 on public IP 203.0.113.45 - ...

If you exhaust your 1000-port allocation (e.g., with many simultaneous connections), new connections fail. Power users running BitTorrent with 500+ simultaneous peers can hit this limit.

Workarounds for CGNAT

Request a Public IP from Your ISP

Many ISPs will assign a static or dynamic public IPv4 address on request, often for a monthly fee ($5-20 USD/month). This is the cleanest solution for self-hosting.

Call or chat with your ISP: "Do you offer public IPv4 addresses?" or "Can I opt out of CGNAT?"

IPv6

If your ISP supports IPv6, deploy IPv6-accessible services. IPv6 gives every device a globally routable address, bypassing CGNAT entirely for IPv6 connections.

VPN Tunnel with a Cloud Server

Rent a cheap VPS (Virtual Private Server) with a public IP. Establish a VPN tunnel between your home network and the VPS. Route inbound traffic from the VPS to your home server:

Internet → VPS public IP → WireGuard tunnel → Home server

Services like Tailscale, ZeroTier, and Cloudflare Tunnel automate this pattern.

Cloudflare Tunnel (cloudflared)

Cloudflare's tunneling service (cloudflared) requires no inbound ports. Your home server establishes an outbound WebSocket connection to Cloudflare, which proxies inbound HTTPS traffic back through the tunnel. Works perfectly under CGNAT.

STUN and ICE for P2P

STUN (Session Traversal Utilities for NAT) and ICE (Interactive Connectivity Establishment) are protocols used by WebRTC, VoIP, and some games to punch through NAT and establish P2P connections. They work by having both parties contact a mutual third-party server to discover their external IP:port mapping and attempt to synchronize connection timing.

CGNAT significantly reduces the success rate of NAT traversal, but it is not impossible — symmetric NAT is harder to traverse than port-restricted NAT.

PCP (Port Control Protocol)

RFC 6887 defines PCP as a mechanism for clients to request specific external port mappings from CGNAT devices. It is the CGNAT equivalent of UPnP. ISP support varies.

CGNAT and Logging / Legal Issues

When law enforcement requests logs for a specific IP address at a specific time, a CGNAT deployment complicates attribution. Multiple users share one IP.

RFC 6888 requires CGNAT devices to maintain logs correlating: - Public IP + port range - Subscriber (private IP or circuit ID) - Time range

ISPs must retain these logs to comply with lawful intercept requirements in most jurisdictions. The retention period varies by country (e.g., 12 months in the EU under data retention regulations).

For security analysts: if an incident involves a source IP that turns out to be a CGNAT address, you cannot identify the actual responsible party without the ISP's internal logs. The port number used becomes critical forensic evidence.

CGNAT vs. IPv6: The Long-Term Picture

CGNAT is explicitly a transitional technology — a stopgap until IPv6 deployment makes IPv4 address pressure irrelevant. The internet would be better served by universal IPv6 adoption than by building increasingly complex NAT infrastructure.

In practice, CGNAT deployments are expanding rather than contracting as IPv4 prices rise and ISP investment in IPv4 procurement becomes less attractive than CGNAT infrastructure.

For users: if you frequently hit CGNAT limitations, advocating for IPv6 deployment from your ISP (or switching to an ISP that offers IPv6 + public IPv4) is the most future-proof solution.

Quick Reference