Mobile carrier proxies: how CGNAT makes phones share one IP

Say your US store's logs show dozens of failed sign-ins from one mobile address in an hour. Blocking it feels obvious. Yet you've probably read that mobile carrier proxies are the most trusted proxies, the addresses sites won't block. Carrier-grade NAT (CGNAT) is a translator inside a carrier's network that lets many customers share one public IPv4 address, and it explains both the logs and that reputation.

We'll start with why phones ran out of their own IPv4 addresses and how carrier-grade NAT packs many of them onto one. Then we look at why websites hesitate to block a mobile IP, with our own test, what IPv6 changes on US carriers, and rate limits that don't punish the crowd.

Why phones ran out of their own IPv4 addresses

The shortage starts with a fixed size. RFC 791, the original IPv4 spec, gives every address a fixed length of "four octets (32 bits)" and nothing more. Two to the power of 32 is 4,294,967,296. That ceiling has to cover every web server, home router, office network and phone in the world that wants a public IPv4 address of its own. RFC 8200 moved IPv6 to 128-bit addresses, which is why IPv6 keeps coming up as the real fix.

The free supply ran out in two steps. On February 3, 2011, the Number Resource Organization announced that the global free pool was "now fully depleted," meaning IANA had nothing left to hand the five regional registries. ARIN, the American Registry for Internet Numbers, issued the final IPv4 addresses in its free pool on September 24, 2015. Its IPv4 guide says it now meets requests only under special policies, from a waiting list, or through transfers. ARIN's waiting list page adds that space from the list "cannot be transferred to another organization for 60 months," with one exception. Section 4.1.8 of ARIN's Number Resource Policy Manual sets the same rule.

Phones made it worse. RFC 6269 is the IETF's list of problems that come with shared addresses. It says a newer provider needs "a much bigger multiplicative factor (e.g., 1000)" and adds that a mobile operator's addressing needs may "grow dramatically." A carrier adding phones faster than it can get addresses has to let customers share.

How carrier-grade NAT puts many phones on one address

That sharing works the way your home router already does, one level up. RFC 6269 describes the usual home setup, where the provider gives each router one public IPv4 address and the router translates the private addresses of every device inside. Carrier-grade NAT adds a second translator inside the carrier's own network, so many routers or phones end up behind one public address.

Those translators needed inside addresses that wouldn't clash with anyone's home network. So in April 2012, RFC 6598 set aside 100.64.0.0/10 as "Shared Address Space." The IANA special-purpose registry lists the block with Global set to False. It runs from 100.64.0.0 to 100.127.255.255, which is 4,194,304 addresses, or a little under 0.1% of all IPv4 space by our script's count. RFC 6598 says it's for numbering the links between CGN devices and customer equipment, and it "is distinct from RFC 1918 private address space." Packets using it mustn't cross from one provider's network into another's. RFC 6598 adds that a /10 is the smallest block that lets ISPs run CGNs regionally without nesting them.

So how does one public address carry so many customers? Ports. RFC 9293, the current TCP spec, gives each connection a 16-bit source port, so every address has 65,536 port numbers. UDP, in RFC 768, uses the same 16 bits. The carrier's translator gives each customer's connections different ports on the shared address and maps the replies back. RFC 6888, the IETF's requirement list for CGNs, says a CGN "MUST support limiting the number of external ports" per subscriber. A freed port should then wait at least 120 seconds before it goes to someone new. RFC 6888 also sets a "Paired" default, which RFC 4787 defines as one external address for all of an inside address's sessions.

Here's the math. Ports 1024 to 65535 leave 64,512 per public address once the low system ports are set aside. Divide that by the ports each customer gets, round down, and you've got the crowd size:

Halving the ports doubles the crowd. These rows are arithmetic, not any carrier's real settings, since no US carrier page we read publishes its ratio.

The first row isn't made up, though. RFC 7422 works through an example that reserves ports below 1024, splits the rest 16 ways, and gives each inside address 4,032 ports. Fixed ranges also keep a carrier's records small. An IETF draft on NAT64 port allocation, cited by RFC 7768, reports 60 days of logs from one network: 42.5 TB with per-session logging, 40.6 GB with port ranges. The two don't agree on the subscriber count, so we've left it out. That's about 1,047 times less data (42,500 GB ÷ 40.6 GB). Keep that in mind for later, because a carrier can only pick out one customer when you hand it the port.

Why do websites hesitate to block a mobile IP?

So blocking a shared address hits everyone behind it, and the IETF spelled that out back in 2011. RFC 6269 describes the "penalty box," where a server that sees too many requests from one address denies it for a while. Some servers ask for a CAPTCHA instead.

Behind a shared address, though, it warns, "one user who fails a number of login attempts may block out other users." Its verdict: with large-scale sharing, penalty boxes "simply will not work."

Blocklists hit the same wall. RFC 7021 reports tests of shared addressing by CableLabs and two cable companies. It says a CGN address added to a blacklist "could negatively impact legitimate users," and so could a server's per-address connection limit.

Email takes a hit too. RFC 6269 says a blacklisted shared address leaves everyone on it with their "ability to source SMTP packets restricted to some extent."

We wanted to watch that happen, so we wrote a toy simulation. Here's the setup. Our nat_sim.py puts 32 simulated phones behind 203.0.113.10, a documentation address, with 2,016 ports each. Over 10 simulated minutes, 31 of the phones make 66 ordinary login attempts between them, and our script makes about one in five of those attempts a typo. One client sends 150 wrong passwords at a single account. The random seed's fixed, so every run gives the same result:

The results split three ways. A tight per-IP limit stopped the attacker fast and took 29 bystanders down with it. A loose one spared them but let all 150 guesses through. The per-account limit stopped the attack at 10 guesses and locked out one person, the owner of the account under attack, which is the cost any lockout carries.

So much for the "most trusted proxies" label. Sites don't trust a mobile address; they hesitate because it can stand for many paying customers at once.

This guide doesn't cover buying or routing traffic through mobile connections. We don't name or link any service that sells them, either.

If a firewall or plugin on your WordPress site blocks by IP, a customer on that carrier just sees an error. Our 403 Forbidden WordPress fix helps you find which layer said no. And an IP address was never strong proof of who's on the other end, as our page on IP address spoofing covers from the attacker's side.

What we tested

Besides the simulation above, three more checks ran on one laptop on October 30, 2026. A script confirmed the 100.64.0.0/10 row in our saved IANA registry file. Python 3.9.6 called the three samples inside it (100.64.0.1, 100.100.25.9 and 100.127.255.254) neither private nor global, and 10.20.30.40, 172.16.5.4 and 192.168.1.10 private. 100.63.255.255 and 100.128.0.1 came back global, and the documentation addresses 198.51.100.7 and 203.0.113.50 came back private. Last, dig found IPv6 (AAAA) records on all four official sites we tried: www.arin.net, www.iana.org, www.rfc-editor.org and www.nist.gov, from a resolver in India. Our DNS lookup tool runs that check for any domain.

What IPv6 changes on US carriers

That whole problem shrinks on IPv6, which removes the shortage that forced the sharing. RFC 6269 calls deploying IPv6 "the only perennial way" to ease pressure on IPv4 without address sharing. Even RFC 7422, which exists to make CGN logs smaller, says IPv6 "is, of course, the preferred solution." With 128-bit addresses, a carrier can give each phone its own.

By one public measure, the big US mobile networks are well along. APNIC Labs publishes measured IPv6 use by network. Its US table, read October 30, 2026, lists T-Mobile USA's AS21928 at 94.40% "IPv6 Capable" and 93.18% "IPv6 Preferred." AS6167, labeled CELLCO-PART - Verizon Business, shows 95.16% and 93.98%. AT&T Mobility's AS20057 shows 86.78% and 85.51%.

There's a catch. Phones on IPv6-only networks still need IPv4-only sites, and that path is shared again. RFC 6877, co-written by an engineer at T-Mobile USA, describes 464XLAT, which gives "limited IPv4 connectivity across an IPv6-only network" with stateful translation in the core.

Apple pushed apps the same way. Its IPv6 support page says all App Store apps "must support IPv6-only networks" as of June 1, 2016. Apple's May 4, 2016 notice agrees.

For you, that means one concrete step: publish an AAAA record. On the three networks above, APNIC's table puts IPv6 Preferred at 85% or more. Those visitors can then reach you on their own address instead of a shared one.

Rate limits and abuse reports when visitors share an IP

That leaves the practical part: limits that hit the attacker, not the crowd. NIST SP 800-63B-4, the federal guideline for logins, keys its limit to the account. A verifier must cap consecutive failed attempts "on a single subscriber account to no more than 100." NIST lists a claimant's IP address and geolocation among the inputs to risk-based checks, but the limit itself is written per account, and it isn't per address.

When you do slow someone down, say so in a standard way. RFC 6585 defines 429 Too Many Requests, and the response "MAY include a Retry-After header" saying how long to wait. RFC 9110 lets Retry-After be a date or a number of seconds. RFC 6585 doesn't tie a 429 to an IP address either, since it says a server "might identify the user by its authentication credentials, or a stateful cookie." Our HTTP header checker shows whether your server sends both.

Here's how the usual keys for a limit hold up when many visitors share one address:

Keep the first row as a loose backstop with a high ceiling, and put the real limit on the account.

Logging is the other half. RFC 6302 recommends that servers log the source port and a timestamp "accurate to the second" from a traceable clock, preferably in UTC. Without the port, RFC 6269 says, a report that an address did something bad at a given time "is not enough information to uniquely identify the subscriber." So when you report abuse to a carrier, send the public IP, the source port, the exact UTC time and your server's port, so it can match its records. Apache records the source port with the %{remote}p field in a custom log format, per RFC 7768 and Apache's log module docs. Add it before you need it.

Your clock matters too. That 120-second port reuse means a timestamp a few minutes off can point at the wrong customer, so sync the server with NTP. If an attack's already under way, our walk-through of incident detection and response covers what to collect first. Our cybersecurity tips for small businesses cover the basics around it.

Our take: treat a mobile IP like a whole neighborhood, not one person. Count failures per account, answer with 429 and Retry-After, log ports, and save IP blocks for addresses that clearly aren't shared. Want per-account limits and port logging built into your site? The DigitalTreed web development team does that as paid work, and that's our stake in the advice above.

Shared mobile IP FAQ

How we made this guide: Our numbers come from IETF and IANA documents, ARIN, the NRO, NIST, Apple and APNIC Labs, plus our own scripts. Those scripts parsed the registry, did the port math, ran the rate-limit simulation and called dig, all locally. No proxy service was opened, named or linked. Facts checked by the DigitalTreed team on October 30, 2026.

First published March 2026 as an essay on why mobile IPs are hard to block. Rewritten October 30, 2026: sourced to RFCs and registries, with a local rate-limit test and the site owner's side.

Sources

• RFC 791: Internet Protocol
• RFC 8200: Internet Protocol, Version 6 (IPv6) Specification
• NRO, February 3, 2011: Free pool of IPv4 address space depleted
• ARIN, September 24, 2015: ARIN IPv4 free pool reaches zero
• ARIN: IPv4 addressing options
• ARIN: Waiting List for Unmet Requests
• ARIN Number Resource Policy Manual, section 4.1.8
• RFC 6269: Issues with IP Address Sharing
• RFC 6598: IANA-Reserved IPv4 Prefix for Shared Address Space
• IANA IPv4 Special-Purpose Address Registry
• RFC 6890: Special-Purpose IP Address Registries
• RFC 9293: Transmission Control Protocol (TCP)
• RFC 768: User Datagram Protocol
• RFC 6888: Common Requirements for Carrier-Grade NATs
• RFC 7422: Deterministic Address Mapping to Reduce Logging in CGN Deployments
• RFC 7768: Port Management to Reduce Logging in Large-Scale NATs
• IETF draft: Analysis of NAT64 Port Allocation Methods for Shared IPv4 Addresses (January 2016)
• RFC 7021: Assessing the Impact of Carrier-Grade NAT on Network Applications
• APNIC Labs: Use of IPv6 for United States of America
• RFC 6877: 464XLAT
• Apple Developer: Supporting IPv6-only Networks
• Apple Developer News, May 4, 2016: IPv6-only networks
• NIST SP 800-63B-4: Authentication and Authenticator Management
• RFC 6585: Additional HTTP Status Codes
• RFC 9110: HTTP Semantics, Retry-After
• RFC 6302: Logging Recommendations for Internet-Facing Servers
• Apache HTTP Server 2.4: mod_log_config