CGNAT Explained: How Carrier-Grade NAT Shares IPv4 Addresses

Carrier-Grade NAT (CGNAT) is an ISP-level translation layer. It lets multiple customers share a single public IPv4 address, because the global pool of available addresses is already exhausted. You can check whether you're behind CGNAT by comparing the WAN IP shown in your router's admin interface against the public IPv4 address an external diagnostic tool reports. If the router shows an address in the 100.64.0.0/10 range, your connection runs through a shared carrier gateway instead of holding a unique public IP; if the two addresses simply differ, another NAT layer sits upstream, often CGNAT or a second router.

Key Takeaways

• A WAN IP within the 100.64.0.0/10 range defined by RFC 6598 definitively indicates your connection passes through Carrier-Grade NAT.
• Comparing your router's WAN IP against the public IP shown on ColdProxy's My IP tool reveals upstream translation layers when the two values differ.
• CGNAT prevents inbound port forwarding because the ISP controls the shared gateway and subscribers can't open inbound ports on it.
• IPv6 restores direct end-to-end connectivity by providing sufficient address space for unique public IPs without shared translation infrastructure.
• ColdProxy's IPv6 Checker shows whether a target publishes IPv6 addresses or points to a recognized CDN before you buy; a detected CDN alone does not confirm ColdProxy support.

This matters because CGNAT changes how your connection interacts with the wider internet. Behind this architecture, inbound port forwarding fails: the ISP controls the translation gateway, and subscribers can't open inbound ports on it. A block placed on that shared public IP hits every customer routing traffic through it at that moment, which makes reputation management impossible for any one user sharing the exit point. Knowing this separates network limitations from local configuration errors, and it clarifies why some applications simply can't work over these connections without alternative infrastructure.

How to Confirm You Are Behind CGNAT Using WAN IP Comparison

Diagnosing Carrier-Grade NAT means comparing what your local hardware sees as its upstream address against what the outside world sees as your origin. Standard home routers perform Network Address Translation (NAT) to map private local IPs to one public IP from the ISP. In a normal setup, the WAN IP on the router matches the public IP visible to external services. When the two values diverge, an extra translation layer sits between your premises and the open internet. That layer is usually CGNAT, though it could be a second local router, such as an ISP modem-router that isn't in bridge mode, so ruling out local double-NAT comes first, before you blame the carrier.

Disable any VPNs, proxies, or browser extensions that might alter your outbound path before you run this check, so you're testing the raw ISP connection. Log into your router's admin panel and find the status page showing the WAN or Internet IP your upstream provider assigned. Then, on the same device and connection, visit the What's My IP tool and note the public IPv4 address external servers see; compare that value, not any IPv6 address the tool also lists. The tool shows your current public exit IP instantly, with no software to install, giving you the external reference point this check needs.

A router showing a WAN IP of 100.75.22.14 while a public IP checker displays 203.0.113.45 confirms an upstream CGNAT layer translating between the two. The 100.64.0.0/10 address block is reserved specifically for Carrier-Grade NAT deployments under RFC 6598 to prevent conflicts with private home networks. If your router's WAN IP falls anywhere in the 100.64.x.x to 100.127.x.x range, you're behind CGNAT, regardless of what the public checker shows.

Even if the WAN IP sits in a different private range, like 10.x.x.x or 192.168.x.x, and still differs from the public IP, you have an upstream NAT layer. Confirming it belongs to the ISP rather than a secondary local device may take tracing the hop count or calling support.

This diagnosis explains specific failures that no amount of local troubleshooting will fix. Inbound port forwarding fails because the CGNAT gateway puts many subscribers behind one IP, and the ISP gives subscribers no way to claim exclusive rights to specific incoming ports. Peer-to-peer connections can fail or fall back to slower relays, because a peer behind CGNAT can't accept unsolicited inbound connections. Gaming hosts, self-managed security cameras, and remote desktop servers become unreachable from outside the local network, unless they use relay services or tunneling that sidesteps the need for inbound connectivity entirely.

Sharing a public IP means sharing reputation consequences with strangers, too. When hundreds of unrelated subscribers route traffic through the same CGNAT exit, a spam complaint or abuse report against that IP hits everyone using it at the time. Reconnecting for a new shared IP is no guarantee of escape, because the next assignment may land you on another equally tainted shared address. This collective liability is built into the architecture, and it's a real constraint for any workflow that needs a consistent, clean origin.

Why ISPs Deploy CGNAT and Its Impact on Shared IPv4 Space

ISPs deploy Carrier-Grade NAT mainly because buying more IPv4 address space costs more than building large-scale translation infrastructure. The global IPv4 pool ran out over a decade ago, and legacy addresses now trade on secondary markets at prices that make per-subscriber allocation uneconomical for many providers. Rather than buy scarce addresses or speed up IPv6 migration, carriers insert CGNAT gateways to stretch existing allocations across growing subscriber bases. That's a rational call from a network-operations standpoint, but it shifts real technical burden onto end users who assumed they'd get direct internet connectivity.

The shared address space this creates concentrates risk in ways standard residential NAT doesn't. A typical home router maps maybe twenty local devices to one public IP, a small blast radius if that IP gets flagged. A CGNAT gateway can map dozens or hundreds of households to that same single IP, which multiplies the odds of malicious traffic, spam, or policy violations coming from neighboring accounts. When a target website rate-limits or blocks by IP reputation, legitimate users sharing that CGNAT exit take collateral damage, despite having done nothing wrong themselves.

This architecture also rules out running authoritative services directly on your connection. Hosting a web server, mail server, or game lobby needs predictable inbound reachability, and CGNAT explicitly denies that. Workarounds exist: reverse proxies, tunneling services, overlay networks. But they add latency, complexity, and dependency on third-party infrastructure that defeats the point of self-hosting. For users whose workflows depend on inbound access, CGNAT turns a broadband connection into a consumption-only pipe, no matter which bandwidth tier they bought.

The economics behind CGNAT show little sign of changing. As long as IPv4 addresses stay expensive and IPv6 adoption among content providers stays incomplete, carriers will keep treating shared translation as the default for new subscribers. Some providers sell dedicated public IPs as premium add-ons, but availability varies, and pricing often reflects the underlying scarcity rather than actual operating cost. CGNAT isn't a temporary glitch waiting to be fixed. It's a permanent feature of the late-stage IPv4 internet, and it shapes what's technically possible on standard residential connections.

IPv6 Removes Address Sharing and ColdProxy IPv6 Options

IPv6 removes the scarcity problem that makes CGNAT necessary in the first place, because it provides enough address space for every device to hold a unique public IP without translation layers. The technical consensus treats IPv6 as the real fix for IPv4 exhaustion: restoring end-to-end connectivity removes the shared-reputation risk and the inbound-access limits that carrier-grade translation creates. When both endpoints support IPv6, traffic flows directly, with no intermediate NAT gateway, preserving the original design assumptions behind internet protocols. This fix depends on both the ISP assigning IPv6 prefixes and the target service accepting IPv6 connections.

Your own ISP doesn't have to offer IPv6 for outbound work through a proxy: your device talks to the proxy over IPv4 or IPv6, and the proxy makes the outbound request over IPv6. For workflows whose targets publish IPv6 addresses or are served by a supported CDN, ColdProxy offers two IPv6 proxy products. Residential IPv6 is USA-only and includes a /32 IPv6 subnet with unlimited traffic at your chosen speed tier, a fit for targets that weigh residential IP reputation. Datacenter IPv6 spans 45+ locations, each order including a private /48 IPv6 subnet per location with unlimited traffic at the selected throughput, built for high-volume tasks where datacenter-class performance matters more than residential classification.

Before you commit to IPv6 proxies, use the free IPv6 Checker to see whether your target publishes IPv6 addresses or its DNS points to a recognized CDN. A detected CDN alone doesn't confirm support, because not every CDN works with ColdProxy's IPv6 plans. Cloudflare, Akamai, Fastly, and Amazon CloudFront are examples of supported CDNs, but you need to confirm compatibility per target rather than assume it from infrastructure detection. If you're still unsure after the check, test on the shortest paid billing window: hourly on Residential IPv6, or daily on Datacenter IPv6. That validates real-world compatibility before you scale up, so you don't waste spend on targets that silently reject IPv6 despite looking compatible.

Knowing the difference between IPv4 and IPv6 infrastructure stops you from blaming proxy quality when the real issue is a protocol mismatch. Readers weighing IPv6 versus IPv4 speed factors should know that neither protocol is faster by design: routing, peering and distance matter more than skipping NAT. For more on how IPv6 proxies work inside broader data collection workflows, the guide on what is an IPv6 proxy covers protocol-specific considerations. And the piece on private IP address ranges and proxy exit IPs explains why certain address blocks signal NAT layers while others mean direct allocation.

If your targets publish IPv6 addresses or are served by a supported CDN, IPv6 proxies send your outbound requests from a ColdProxy IPv6 exit, so your work no longer inherits the reputation of an IPv4 address shared with strangers. They don't open inbound ports on your own connection, so hosting and gaming still need the workarounds above. Check Residential IPv6 pricing for hourly rates or Datacenter IPv6 pricing for daily rates, so you can validate fit before committing to longer windows. Need a different speed or traffic allowance? Contact us through the channels on our website so we can assess whether a custom plan is possible.

Frequently Asked Questions

What is the 100.64.0.0/10 address range used for?

The 100.64.0.0/10 block is reserved specifically for Carrier-Grade NAT deployments under RFC 6598 to prevent routing conflicts with standard private networks. When your router displays a WAN IP in this range, it confirms your ISP is using shared translation infrastructure rather than assigning you a unique public IPv4 address. This range spans from 100.64.0.0 to 100.127.255.255 and should never appear as a routable public address on the open internet.

How can I tell if my ISP uses CGNAT?

Disable all VPNs and proxies, then compare the WAN IP shown in your router's admin panel against the public IPv4 address displayed on ColdProxy's My IP tool. If the router shows an address in the 100.64.0.0/10 range, your connection passes through CGNAT; any other private WAN IP that differs from the public result means another NAT layer upstream, often CGNAT or a second router. Matching values indicate standard single-layer NAT with a dedicated public IP assigned to your premises.

Can someone track my physical location using a shared CGNAT IP?

To websites and other outside observers, a shared CGNAT IP identifies only the ISP's regional gateway, not your specific household or geographic coordinates, because many unrelated subscribers route through the same exit point. Your ISP can still match that IP, port and time to your account from its own translation records. Geolocation databases typically resolve CGNAT IPs to the carrier's data center city rather than individual neighborhoods. However, combining IP data with browser fingerprints, account logins, or other identifiers can still enable tracking independent of the shared address.

Why does port forwarding fail even after configuring my router correctly?

CGNAT places an additional translation layer between your router and the public internet that you cannot configure or bypass from your premises. The ISP's gateway puts many customers behind one IP and does not expose mechanisms for individual subscribers to reserve inbound ports. No router setting will overcome this limitation; alternatives include tunneling services, reverse proxies, or requesting a dedicated public IP if your provider offers one.