CGNAT: what it breaks and how to tell you’re behind it

Why your provider did this

IPv4 addresses ran out. ARIN, the regional internet registry whose service region includes the United States, saw its free pool deplete in September 2015. Since then, new IPv4 space here comes back mostly through revocations and is handed out from a waiting list — most recently on July 2, 2026, with the next distribution expected on or about October 1, 2026 — capped at a /22 aggregate per organization and locked against transfer for 60 months apart from Section 8.2 merger-and-acquisition transfers. A /22 is 1,024 addresses — not a growth plan for a provider adding subscribers, which is why sharing them became the default.

Carrier-grade NAT is what sharing looks like in practice. Your gateway is assigned an address that only exists inside your provider’s network, and a translator further upstream rewrites your outbound packets to one of a smaller pool of real public addresses, keeping a table of which subscriber and port each conversation belongs to. Cloudflare, which sees this from the server side, puts the scale plainly: a single IPv4 address today may represent hundreds or even thousands of users.

The link between that carrier translator and your equipment has its own reserved range. RFC 6598 set aside 100.64.0.0/10 as Shared Address Space specifically to number the interfaces that connect CGN devices to customer premises equipment. It is not globally routable, and packets carrying those addresses as source or destination “MUST NOT be forwarded across Service Provider boundaries”. That last rule is what makes it a reliable fingerprint: an address in that range can never be your real public address, so if your router reports one, something upstream is translating.

What CGNAT actually breaks

The rule is simple. Connections your devices start still work, because the translator creates a mapping the moment your packet leaves. Connections that start somewhere else have nowhere to land, because there is no mapping yet and the public address is not exclusively yours. Port forwarding fails not because a setting is wrong but because the rule you wrote is on a router that does not hold the address the world would connect to.

Somebody measured the consequences rather than guessing at them. CableLabs, Time Warner Cable and Rogers Communications ran applications through a carrier NAT in 2010, CableLabs repeated and extended the work in 2011, and the results were published in the RFC series as RFC 7021. Single-household console gaming worked. Peer-to-peer console gaming failed when two subscribers were translated to the same outside address — “Both users shared an outside IP address and tried to connect to the same port, causing a connection failure.” SIP calling directly between peers, with no proxy in the middle, failed; the same calls succeeded when a proxy server was involved. BitTorrent seeding failed across every scenario tested. FTP sessions to a server located inside the home, behind two layers of NAT, failed. The IPv6 transition mechanisms 6to4 and Teredo failed completely, and multicast traffic was not forwarded through the CGN at all.

That document is a snapshot, and it says so about itself: it records that Microsoft shipped an Xbox update in December 2011 after which upgraded consoles could “play head-to-head behind a CGN, at least for some games”. Treat the list as the shape of the failure — unsolicited inbound has nowhere to go — rather than as a current compatibility table for the app in front of you.

Two configuration choices in the carrier’s translator decide how much of that you feel, and both are written down as requirements. RFC 6888, published as BCP 127, requires a CGN to support a limit on the number of external ports assigned per subscriber, configurable by the CGN administrator (REQ-4), and recommends endpoint-independent filtering (REQ-7) on the explicit basis that “some games and peer-to-peer applications require EIF for the NAT traversal to work”. It also requires that the default address pooling behavior be “Paired” (REQ-2), so a subscriber keeps the same external address across their connections.

Those requirements explain most of the confusing behavior. The REQ-7 recommendation is why the same console can report Open or Moderate NAT on one provider and Strict or Type 3 on another with identical hardware. And the REQ-4 port limit is why a household can hit a wall that does not look like a bandwidth problem: when the quota is reached, new connections have no port to be assigned, so some pages hang while everything already open keeps working. A speed test in that state looks fine.

Why the damage spreads past hosting

The part nobody warns you about is reputation. Websites, ticket sellers, banks and streaming services rate-limit and challenge by IP address, and your address is not yours. Cloudflare’s measurement of this is the number worth carrying: across its own traffic between December 17, 2024 and January 9, 2025, addresses it identifies as CGNAT “are subject to rate limiting three times more often than non-CGNAT IPs”, even though their mean bot rate is lower — 7% for CGNAT against 13.1% for non-CGNAT, with medians almost identical at 4.8% and 4.7%. You are not being flagged for what you did. You are being flagged for the address you were assigned.

Symptom, cause, and what actually changes it

The two-minute test

Run this before you call anyone. It separates three problems people conflate: CGNAT, double-NAT you created yourself, and a public address behind a closed firewall.

1. Read the WAN address off your router. Open the router or gateway admin page and find the WAN, Internet or Status section. Write down the IPv4 address it says the provider assigned. Menu names vary by manufacturer and firmware version.
2. Read the address the internet sees. From a device on that same network, open any what-is-my-IP lookup and write down the IPv4 address it reports.
3. Compare them. If they match, you are not behind CGNAT. Your inbound problem is a firewall rule, a port-forwarding mistake, or software on the target device. Fix it locally.
4. If they differ, check the range. A router WAN address inside 100.64.0.0/10 confirms carrier-grade NAT, because that range exists only between a carrier translator and customer equipment and can never be routed publicly.
5. If they differ but the WAN address is 10.x, 172.16–31.x or 192.168.x, keep going. Trace the cable out of your router. If it lands in another router or an all-in-one gateway rather than a bare modem or a fiber ONT, the second translation is yours, and bridging the upstream device removes it. If it goes straight to the provider’s equipment, you are behind CGNAT that simply is not numbered from the reserved range.

That last case is the caveat every glossary page skips. Shared Address Space proves CGNAT; its absence does not disprove it. RFC 6598 reserves that range for the carrier-to-customer link but does not require a provider to use it, so a carrier NAT can equally hand your router an ordinary private address. The mismatch between the two addresses is the reliable signal, not the specific range.

The remedy ladder, cheapest first

Ask for a public IPv4 address. Whether a public IPv4 address exists for your line, and whether it costs anything, is an account-level question only your provider can answer. Be specific on the call: “Is my connection behind carrier-grade NAT, and can I be moved to a public IPv4 address? If not free, what does a static IP cost on my plan?”

Ask about PCP. The Port Control Protocol is the standards-track answer to opening a port through a carrier NAT: it lets a host control how incoming packets “are translated and forwarded by a Network Address Translator (NAT) or simple firewall”, and it is “designed to be implemented in the context of Carrier-Grade NATs (CGNs) and small NATs (e.g., residential NATs)”. Naming it turns “we don’t support port forwarding” into a real answer. Ask the same way about endpoint-independent filtering if your problem is a console NAT type.

Accept that some products cannot do it. On August 28, 2026, T-Mobile’s own support page for its home internet gateways said they “do not have the ability to enable and disable NAT/port forwarding” and “do not have the ability to change NAT type”, and that T-Mobile Home Internet uses dynamic IP addressing which the company cannot change to static. That is a fact about one company’s equipment on that date, not a rule for 5G home internet generally — but where a provider says this, no configuration on your side will move it.

Route around it with an outbound connection. Everything that works under CGNAT works the same way: something inside your network opens the connection, so the translator builds a mapping and the far end has an existing conversation to answer into. A mesh VPN joining your own devices, a reverse tunnel to a small rented server, or your camera vendor’s cloud relay all use this shape. The trade-offs are added latency and a dependency on a third party, but the mechanism is sound and it asks nothing of your provider.

Where IPv6 helps, and where it does not

IPv6 is the actual fix for the scarcity: every device gets a globally unique address and there is no translation and no port quota to exhaust. What it does not do is open your door. The recommended model for a residential IPv6 gateway is stateful filtering. RFC 6092 states the general operating principle that “transport layer traffic is not forwarded into the interior network of a residential IPv6 gateway unless it has been solicited explicitly by interior transport endpoints”, or the administrator set a configured exception; the same document requires (REC-49) that a gateway with those simple security capabilities “provide an easily selected configuration option that permits a ‘transparent mode’ of operation that forwards all unsolicited flows regardless of forwarding direction”. That is a recommendation written for equipment makers rather than a statement about what your particular box shipped with, so check your own gateway rather than assuming. So there is usually a firewall to open on your own router, and separately a question only your provider can answer, in those words: “Do you route a delegated IPv6 prefix to my gateway, and do you permit unsolicited inbound IPv6 to it?” Treat that as a different question from the CGNAT one, because the answers are independent.

What this page cannot tell you

It cannot tell you whether your provider uses CGNAT on your line. That varies by provider, by access technology, by market, by your specific address and sometimes by the year you were connected, and only your provider can confirm it for your line — which is why the test above is the body of this guide rather than a lookup table. It also cannot promise a public IPv4 address is available to you at any price; that is an inventory question answered per account.

The RFC 7021 results are lab measurements of specific applications through a carrier NAT, from test runs in 2010 and 2011, and applications change. The failure mode itself has not changed: unsolicited inbound has nowhere to go, and every workaround is a way of making the connection outbound instead.