Carrier-Grade NAT (CGNAT), also known as Large-Scale NAT (LSN) or CGN, is a network address translation technology deployed by Internet Service Providers to extend the usability of their limited IPv4 address pools. Unlike traditional home router NAT, CGNAT operates at the ISP level, creating an additional layer of address translation between subscribers and the public Internet.
Traditional NAT (Home Router):
Private Device → Home Router NAT → Public Internet
192.168.1.10 → 203.0.113.5 → Internet Server
CGNAT Architecture (Double NAT):
Private Device → Home Router → CGNAT → Public Internet
192.168.1.10 → 100.64.0.5 → 203.0.113.5 → Internet Server
(Private) (Shared Public)
The key difference: with CGNAT, your home router doesn't receive a unique public IPv4 address. Instead, it receives an address from the shared address space (typically 100.64.0.0/10, defined in RFC 6598), and the ISP's CGNAT device translates this to a public IPv4 address shared among 50-200 other subscribers.
Primary reason: IPv4 address exhaustion forces ISPs to conserve scarce IPv4 addresses by sharing them among multiple customers.
Economic factors:
Operational benefits for ISPs:
IPv4 address exhaustion is not a future threat—it's the current reality driving CGNAT adoption worldwide.
2011: IANA (Internet Assigned Numbers Authority) allocated its last IPv4 blocks to Regional Internet Registries (RIRs)
Regional exhaustion dates:
IPv4 provides approximately 4.3 billion addresses (2^32), but:
Mathematical reality: No amount of NAT optimization can solve the fundamental constraint of limited IPv4 address space. Only routed networks, particularly with IPv6, can scale effectively.
CGNAT allows ISPs to delay full IPv6 deployment while maintaining IPv4 service availability. However, it's explicitly recognized as a transitional technology—not a permanent solution. The network is not expected to become fully IPv6-based for several more years, and until then, CGNAT technology helps ISPs provide IP connectivity to their subscribers despite IPv4 scarcity.
CGNAT performs Network Address and Port Translation (NAPT) at carrier scale, sharing public IPv4 addresses across many subscribers using port multiplexing.
A single public IPv4 address has 65,535 available ports. CGNAT divides these ports among multiple subscribers:
Port allocation example:
Public IP: 203.0.113.5
Subscriber A: ports 1024-5000 (3,977 ports)
Subscriber B: ports 5001-9000 (4,000 ports)
Subscriber C: ports 9001-13000 (4,000 ports)
...
Subscriber N: ports 61001-65535 (4,535 ports)
Typical sharing ratios:
Outbound connection (Client to Internet):
Step 1: User device initiates connection
Source: 192.168.1.100:54321
Destination: 93.184.216.34:80 (example.com)
Step 2: Home router NAT
Source: 100.64.0.25:12345 (from ISP CGNAT range)
Destination: 93.184.216.34:80
Step 3: CGNAT translation
Source: 203.0.113.5:15678 (shared public IP:allocated port)
Destination: 93.184.216.34:80
Step 4: Reaches Internet server
Server sees: 203.0.113.5:15678
(Same public IP as 50+ other subscribers)
Inbound response (Internet to Client):
Step 1: Server responds to 203.0.113.5:15678
Step 2: CGNAT looks up port mapping table
Port 15678 → 100.64.0.25:12345
Step 3: ISP network routes to customer router
Step 4: Home router NAT translates to 192.168.1.100:54321
Step 5: Response reaches user device
RFC 6598 reserves 100.64.0.0/10 specifically for CGNAT deployments:
Detecting CGNAT: If your router's WAN IP address falls in 100.64.0.0/10, you're definitely behind CGNAT.
Many jurisdictions require ISPs to log CGNAT translations for law enforcement purposes.
Required logging information:
Data volume challenges:
CGNAT introduces significant limitations that degrade user experience and break critical network functionality.
Problem: Inbound connections from the Internet cannot reach devices behind CGNAT.
Why it fails: Multiple subscribers share the same public IP address. The ISP's CGNAT cannot route incoming traffic to a specific customer without pre-configured port mappings—and ISPs typically don't provide this for residential CGNAT deployments.
Affected use cases:
Example failure scenario:
User wants to host Minecraft server on port 25565
Without CGNAT:
Internet → Public IP:25565 → Router port forward → Local server
✓ Works perfectly
With CGNAT:
Internet → Public IP:25565 → CGNAT (which customer?) → ✗ FAILS
Port forwarding on home router has no effect—the public IP is shared!
Online gaming relies heavily on peer-to-peer connections and NAT traversal. CGNAT creates "Strict NAT" or "NAT Type 3" conditions that severely limit multiplayer functionality.
NAT types in gaming:
Impact on gaming:
Affected games and platforms:
Certain VPN protocols struggle or fail entirely through CGNAT due to protocol-specific NAT traversal requirements.
IPsec VPN issues:
Remote desktop problems:
Protocols broken by CGNAT:
Applications with degraded performance:
CGNAT port allocation algorithms may cause port exhaustion during heavy usage.
Port exhaustion scenarios:
Symptoms of port exhaustion:
IPv6 fundamentally eliminates the address scarcity that necessitates CGNAT, providing every device with globally routable addresses and restoring end-to-end connectivity. See benefits-ipv6-over-ipv4.md for more details on why IPv6 is superior.
IPv6 provides 340 undecillion addresses (2^128):
Practical allocation:
/64 subnet = 18.4 quintillion addresses/48 prefix = 65,536 subnets of 18.4 quintillion addresses each/64 or even /56 prefixFor understanding address structure and types better, see ipv6-address-types.md. No address sharing required—every device gets globally unique addressing.
With IPv6, devices receive public, globally routable addresses by default:
IPv6 architecture (No CGNAT):
Device (2001:db8:1234::5678) → Internet
Direct connection, no address translation
Inbound connections work naturally (subject to firewall rules)
Benefits restored:
IPv6 networks eliminate CGNAT complexity:
With CGNAT (IPv4):
Device → Home NAT → ISP CGNAT → Internet
- Double NAT complications
- Port exhaustion risks
- Logging requirements
- State table maintenance
With IPv6:
Device → Internet (via firewall)
- No address translation
- Stateless routing
- Simplified troubleshooting
- Better performance
Common misconception: "NAT provides security."
Reality: NAT provides obscurity, not security. Firewalls provide actual protection.
IPv6 routers include stateful firewalls that:
See configure-ipv6-firewall.md for detailed firewall configuration guidance. Security advantage: IPv6 firewalls make security policy explicit rather than relying on the side effects of address translation.
ISPs deploying IPv6 in CGNAT environments use several standardized transition mechanisms to provide both IPv4 and IPv6 connectivity efficiently. These technologies enable IPv6-native infrastructure with dual-stack capability while maintaining IPv4 service availability.
ISP objectives:
Transition mechanisms achieve these goals by running IPv6-native networks with efficient IPv4 service layered on top.
DS-Lite (RFC 6333) enables ISPs to operate IPv6-only core networks while delivering IPv4 services through IPv4-in-IPv6 tunneling combined with centralized CGNAT. See ds-lite-explained.md for comprehensive DS-Lite information including detection methods and deployment details.
Components:
B4 Element (Basic Bridging BroadBand): Customer equipment (CPE)
AFTR (Address Family Transition Router): ISP network core
Packet flow:
Customer Device (192.168.1.100)
↓ IPv4 packet
B4 Element (CPE)
- Encapsulates IPv4 packet in IPv6
- Source: [B4 IPv6 address]
- Destination: [AFTR IPv6 address]
↓ IPv4-in-IPv6 tunnel
IPv6-Only ISP Network
↓
AFTR (ISP Core)
- Decapsulates IPv6, extracts IPv4 packet
- Performs CGNAT (192.168.1.100 → 203.0.113.5:port)
↓ IPv4 packet
IPv4 Internet
For ISPs:
For users:
User impact:
Technical considerations:
Major ISP implementations:
MAP-E (Mapping of Address and Port with Encapsulation, RFC 7597) is an IPv6 transition mechanism that uses stateless IPv4-in-IPv6 encapsulation with deterministic port allocation, eliminating the need for carrier-grade NAT.
Key innovation: Pre-allocates specific port ranges to each subscriber using algorithmic mapping.
Components:
MAP-E CE (Customer Edge): CPE router
MAP-E BR (Border Relay): ISP network edge
Address and port mapping:
Customer receives:
- IPv6 prefix: 2001:db8:1234:5600::/56
- Shared IPv4: 203.0.113.5
- Port range: 2048-4095 (2,048 ports)
All IPv4 connections must use ports 2048-4095
Outbound connection:
Step 1: Device initiates connection (192.168.1.100:54321)
Step 2: MAP-E CE performs NAT44
- Source: 203.0.113.5:2500 (from allocated port range)
- Destination: 93.184.216.34:80
Step 3: MAP-E CE encapsulates in IPv6
- IPv6 header: Source [CE IPv6], Dest [BR IPv6]
- IPv4 payload: 203.0.113.5:2500 → 93.184.216.34:80
Step 4: IPv6-only network routes to MAP-E BR
Step 5: MAP-E BR decapsulates, forwards IPv4 packet to Internet
Inbound connection:
Step 1: Internet packet arrives at MAP-E BR
Destination: 203.0.113.5:3000
Step 2: MAP-E BR uses algorithm to determine IPv6 destination
Port 3000 in range 2048-4095 → maps to specific customer IPv6
Step 3: BR encapsulates in IPv6, routes to customer CE
Step 4: CE decapsulates, performs NAT44 to local device
Stateless operation:
Port forwarding possible:
Performance:
Reduced port availability:
CPE complexity:
Port range restrictions:
| Feature | DS-Lite | MAP-E |
|---|---|---|
| ISP infrastructure | Stateful AFTR (CGNAT) | Stateless BR |
| Scalability | Limited by AFTR capacity | Unlimited (stateless) |
| Port forwarding | Impossible | Possible (restricted ports) |
| Logging | Required (CGNAT state) | Minimal (deterministic) |
| Complexity | Moderate | Higher |
| Port availability | Full range (per session) | Fixed subset per subscriber |
MAP-T (Mapping of Address and Port with Translation, RFC 7599) uses double stateless NAT64/NAT46 translation instead of encapsulation, providing the same benefits as MAP-E with different technical implementation. See nat64-dns64-explained.md for detailed NAT64 information.
MAP-E: IPv4-in-IPv6 encapsulation (original IPv4 packet wrapped in IPv6 header)
MAP-T: IPv4↔IPv6 translation (IPv4 header replaced with IPv6 header)
Translation process:
MAP-T CE: IPv4 → IPv6 (NAT46 - Stateless translation)
IPv6-only network transport
MAP-T BR: IPv6 → IPv4 (NAT64 - Stateless translation)
Components:
MAP-T CE (Customer Edge):
MAP-T BR (Border Relay):
Address mapping:
Shared IPv4: 203.0.113.5, Port range: 4096-8191
IPv6 representation: 2001:db8:5:cb00:71:5000::/104
└─ Encodes IPv4 address and port range in IPv6 bits
MAP-T advantages:
MAP-T disadvantages:
MAP-E advantages:
MAP-E disadvantages:
MAP-E is more widely deployed due to:
MAP-T may be preferred when:
Both achieve the same end result: stateless, scalable IPv4-over-IPv6 with port-restricted NAPT.
464XLAT (RFC 6877) is the dominant IPv6 transition mechanism for mobile networks, combining customer-side translation (CLAT) with provider-side NAT64 (PLAT) to enable IPv4 application compatibility on IPv6-only networks. See 464xlat-explained.md for comprehensive 464XLAT details.
Mobile carriers faced unique challenges that made 464XLAT the ideal solution:
Problem 1: IPv4 literal addresses in applications
8.8.8.8)Problem 2: Device diversity
Solution: 464XLAT provides transparent IPv4 connectivity on IPv6-only networks without application modifications.
Two-stage translation:
CLAT (Customer-side transLATor) - On device/CPE:
192.0.0.4)PLAT (Provider-side transLATor) - In carrier network:
Packet flow:
IPv4 App (8.8.8.8)
↓ IPv4 packet
CLAT (on device)
- Translates to IPv6: 64:ff9b::808:808
↓ IPv6 packet
IPv6-Only Mobile Network
↓
PLAT (carrier NAT64)
- Translates to IPv4: source CGNAT IP → dest 8.8.8.8
↓ IPv4 packet
IPv4 Internet
Android: Native support since Android 4.3 (July 2013)
iOS: Support since iOS 9.2 (2015)
Other platforms: Windows 11, Linux (via clatd daemon)
T-Mobile US:
Verizon Wireless:
Telstra (Australia):
Others: Deutsche Telekom, Orange Polska, SK Telecom, KDDI, China Mobile
Complete application compatibility:
True IPv6-only network:
Performance:
Same CGNAT restrictions:
Device requirements:
ISPs worldwide have deployed various combinations of CGNAT and IPv6 transition mechanisms based on their specific infrastructure and customer requirements.
Free (France) - DS-Lite Pioneer:
Deutsche Telekom (Germany) - Hybrid Approach:
Stadtwerke Flensburg (Germany) - Modern Fiber:
Mobile carriers (Japan):
China Mobile, China Telecom:
T-Mobile US - 464XLAT Success Story:
Verizon Wireless:
Cable ISPs (Comcast, etc.):
ISPs that succeeded with IPv6 transition:
CGNAT severely impacts gaming, server hosting, and peer-to-peer applications due to inability to accept inbound connections.
NAT Type classification:
Open NAT (Type 1 / Type A):
Moderate NAT (Type 2 / Type B):
Strict NAT (Type 3 / Type C/D):
Console gaming:
PC gaming:
Symptoms:
Web servers: Cannot accept inbound HTTP/HTTPS (ports 80, 443 blocked)
Game servers: Minecraft, CS:GO, Valheim hosting impossible
File sharing: FTP, SFTP require port forwarding (unavailable)
Remote access: SSH, RDP from Internet blocked
Home automation: Cloud access for some smart home devices fails
Media servers: Plex, Jellyfin remote access broken (may work with relay)
Surveillance cameras: Direct remote viewing impossible
BitTorrent:
WebRTC (video conferencing):
Direct Connect, eDonkey: Severely degraded or broken
When native IPv6 isn't available or applications require IPv4 inbound connectivity, several workarounds can bypass CGNAT restrictions.
IPv6 request:
Dedicated IPv4 request:
Commercial VPN providers offering port forwarding:
How it works:
Internet → VPN Provider Public IP:25565 → VPN Tunnel → Your Device
Inbound traffic reaches VPN server
VPN forwards to your device via tunnel
You appear to have public IP
Use cases:
Limitations:
Cloudflare Tunnel (free):
Setup:
cloudflared tunnel create myserver
cloudflared tunnel route dns myserver subdomain.example.com
cloudflared tunnel run myserver
Ngrok (free tier available):
Setup:
ngrok http 80
# Provides: https://random-subdomain.ngrok.io → localhost:80
Use cases:
Limitations:
Setup your own relay server:
Step 1: Rent VPS with public IPv4 ($5-10/month)
Step 2: Configure reverse SSH tunnel
# From home server (behind CGNAT):
ssh -R 8080:localhost:80 user@vps-public-ip
# VPS now forwards port 8080 to your local port 80
Step 3: Configure VPS firewall/nginx to proxy traffic
Persistent solution: Use systemd service or autossh
Advantages:
Disadvantages:
ZeroTier (free for small networks):
Tailscale (free tier available):
Use cases:
How it works:
Device A (behind CGNAT) ←→ Tailscale Control ←→ Device B (anywhere)
Direct P2P connection when possible
Relay via Tailscale servers when NAT prevents P2P
Limitations:
When IPv6 is available:
Challenges:
Hybrid approach:
Understanding your current network setup is critical for troubleshooting and determining which workarounds to pursue.
Method 1: Check router WAN IP address
Router shows:
WAN IP: 100.64.25.100 → You are behind CGNAT (RFC 6598 address)
WAN IP: 10.x.x.x or 192.168.x.x → Possible CGNAT (check Method 2)
WAN IP: Public IP (not in private ranges) → Likely no CGNAT
Method 2: Compare router IP with public IP
# Check router's WAN IP (admin panel or CLI)
Router WAN IP: 100.64.25.100
# Check public IP from external service
curl ifconfig.me
# Returns: 203.0.113.5
# If different: You are behind CGNAT
# If same: No CGNAT (native public IP)
Method 3: Port forwarding test
Method 4: Traceroute analysis
traceroute 8.8.8.8
# Look for hops in 100.64.0.0/10 range early in path
# Indicates CGNAT infrastructure
Comprehensive testing: Visit https://test-ipv6.run
The site performs:
What test-ipv6.run reveals:
Scenario 1: CGNAT without IPv6
Scenario 2: CGNAT with DS-Lite
Scenario 3: CGNAT with 464XLAT (mobile)
Scenario 4: Native Dual-Stack (no CGNAT)
Check IPv6 address:
# Linux/macOS
ip -6 addr show # Linux
ifconfig | grep inet6 # macOS
# Windows
ipv6config
# Look for global unicast address (2000::/3 range)
# Example: 2001:db8:1234:5678::1
Test IPv6 connectivity:
# Ping IPv6-only host
ping6 ipv6.google.com
# Test IPv6 web access
curl -6 ifconfig.me
# Returns your public IPv6 address if working
Check for DS-Lite:
# If router WAN shows only IPv6 (no IPv4):
# AND IPv4 Internet works:
# You are likely on DS-Lite
# Traceroute may show IPv6 hops even for IPv4 destinations
traceroute -4 8.8.8.8
# If you see IPv6 addresses in trace: DS-Lite indicator
| Test Results | Likely Configuration |
|---|---|
| IPv4 works, IPv6 fails, WAN IP in 100.64.x.x | CGNAT without IPv6 |
| IPv4 works, IPv6 works, WAN IP public IPv4 + IPv6 | Native dual-stack (no CGNAT) |
| IPv4 works, IPv6 works, WAN IP only IPv6 | DS-Lite or similar tunnel |
| IPv4 works, IPv6 works, Mobile network | Likely 464XLAT |
| IPv4 fails, IPv6 works | IPv6-only (need CLAT or DNS64/NAT64) |
The ultimate solution to CGNAT's limitations is widespread IPv6 deployment, enabling true end-to-end connectivity without address translation. See setup-ipv6-only-networks.md for guidance on implementing IPv6-only network architectures.
As of 2025:
Mobile networks: 70-90% IPv6 deployment (highest adoption segment)
Fixed broadband: 30-60% IPv6 deployment (varies by region)
Economic pressure:
Technical benefits:
Industry momentum:
Legacy systems:
Knowledge gap:
Chicken-and-egg problem:
2025-2027:
2028-2035:
2035+:
As a user:
As a developer:
As a network administrator:
CGNAT emerged as a necessary response to IPv4 address exhaustion, enabling ISPs to extend IPv4 service availability by sharing scarce addresses across multiple subscribers. However, CGNAT introduces significant limitations—broken port forwarding, strict NAT types in gaming, and hosting impossibilities—that fundamentally degrade the Internet's end-to-end connectivity model.
IPv6 eliminates the need for CGNAT by providing an effectively infinite address pool, restoring direct connectivity and enabling the Internet to function as originally designed. Transition mechanisms like DS-Lite, MAP-E, MAP-T, and 464XLAT enable ISPs to deploy IPv6-native infrastructure while maintaining IPv4 service compatibility, bridging the gap during this critical transition period.
Key takeaways:
As the Internet continues its inevitable transition to IPv6, CGNAT will gradually fade into obsolescence—but until that day arrives, understanding CGNAT's limitations and available workarounds is critical for anyone navigating today's transitional Internet landscape.
Test your network's IPv6 readiness and check if you're behind CGNAT: Visit test-ipv6.run for comprehensive, browser-based testing of your IPv4 and IPv6 connectivity. The tool provides real-time results, latency measurements, and an IPv6 readiness score—helping you understand exactly how your connection works.
Last updated: 2025-10-26