Mobile IP Geolocation Really Is Worse: What CGNAT Does to Location Data in Africa and Asia

The Internet Society's Pulse blog ran a post this week whose title takes a swing at the product category we work in: "Why IP Geolocation Can't Be Trusted for Mobile Networks and the Global South." The author, Syed Tauhidun Nabi, a PhD candidate at Virginia Tech and 2026 Pulse Research Fellow, is summarizing a measurement study he co-authored, "Lost in the Prefix", and its numbers are blunt. Across four widely used geolocation databases, mobile connections were placed a median of 179 to 207 km from where they really were, more than ten times the 3 to 16 km medians for fixed broadband. In Africa, 66 to 72 percent of measurements missed by more than 100 km. In Asia, 53 to 61 percent.

You might expect a geolocation provider to argue with the study. Mostly we will not. The measurements match what anyone who has worked with mobile address space already knows, and the mechanics behind them, carrier-grade NAT, centralized packet gateways, and databases that publish coarser prefixes than the routing table, deserve a proper explanation. The headline needs one qualifier, though. The same dataset put fewer than 1 percent of observations in the wrong country. What fails on mobile networks is city-level geolocation, and that distinction decides whether the answer an API gives you is useful or garbage.

What the study measured

The paper assembles 37,302 observations with known ground truth across 175 countries from two sources: RIPE Atlas probes (10,294 IPv4 and 5,716 IPv6 probe records, snapshotted on March 23, 2026) and connectivity measurements from 4,872 schools in 27 countries collected by UNICEF's Giga project. Each observation's true location was compared against four databases: MaxMind GeoLite2, IPinfo, IP2Location, and DB-IP. A lookup counted as failed when it landed more than 100 km from the truth.

By that yardstick, the regional gap is stark.

The most damning finding is not any single number but the agreement. All four databases fail at close to the same rate on the same networks. When four independently built datasets miss the same targets, the cause is not sloppiness at one vendor; it is structural, and the paper is right that "studies cannot escape it by switching geolocation providers." So what is the structure?

Your packets do not enter the internet where you stand

Almost every intuition people carry over from home broadband breaks on mobile. When your phone sends a packet, it does not pop onto the internet at the nearest cell tower. The base station wraps it in a GTP tunnel and carries it, still encapsulated, across the carrier's private backbone to a packet gateway: the P-GW in 4G networks, the UPF in 5G. Only there does it acquire a public source address and meet the internet. Geolocation can never see deeper than that gateway, because the internet never does.

Carriers have historically run very few of these gateways. Regional gateways cost money and, more painfully, public IPv4 addresses, so a national operator often terminates every subscriber in one or two sites, usually in the capital. A subscriber in Kisumu, about 265 km from Nairobi, and another in Mombasa, about 440 km away, can surface on the internet meters apart in the same Nairobi data center.

Carrier-grade NAT sits on top. Between the phone and the gateway, subscribers hold addresses from 100.64.0.0/10, the shared space RFC 6598 reserved for exactly this, and the gateway translates them onto a pool of public addresses. How many people share each public address depends on how starved the operator is. AFRINIC, the RIR for Africa, has been allocated on the order of 120 million IPv4 addresses for a continent of 1.4 billion people, so its carriers run some of the highest subscriber-to-address ratios in the world: one public IP can front hundreds of users scattered across an area the size of a European country.

Note what this means for the accuracy debate: a perfect database can still only return the gateway. On a centralized mobile network, a 200 km error is the topology, faithfully reported.

Databases round the error up

If topology were the whole story, every database would be wrong by exactly the gateway distance and no more. The paper found something worse: providers publish rows that are coarser than the network itself. A geolocation database is, at bottom, a list of prefixes with one location per row. Aggregate too eagerly and one row swallows address space that BGP announces as many separate prefixes from many different cities.

The study measured this directly. Depending on provider, 32 to 40 percent of database prefixes span more than 100 km of real user locations, wide rows are roughly twice as common in the Global South as in the Global North, and for mobile networks about 70 percent of prefixes span more than 100 km. The cost is not symmetric either: observations falling in coarser-than-announcement rows had median errors of 4 to 34 km in the Global North, against 101 to 179 km in the Global South.

This is the half of the problem a provider controls. Nothing forces a database row to be wider than the BGP announcement that covers it, and announcements are public. Keeping granularity at or below announcement boundaries, and modeling a mobile carrier's space as per-gateway pools rather than one national blob, does not repair CGNAT. It just stops adding hundreds of kilometers on top of it.

Where "can't be trusted" overreaches

Now the pushback, because the headline claims more than the data does.

Country-level accuracy held. Fewer than 1 percent of observations, per provider, landed in the wrong country. The decisions most production systems make on mobile traffic, which content catalog to serve, which currency to charge, which regulatory regime applies, whether a login is even plausible, are country decisions. Those keep working, in Africa and Asia included, and a reader who stops at the title will conclude the opposite.

The tested databases also skew free. GeoLite2 and DB-IP Lite are the no-cost tiers of their vendors' products, published at deliberately reduced granularity. To be fair to the authors, the uniformity of the failure across all four is genuine evidence that the cause sits upstream of any one vendor's craft, and no paid tier repeals the physics of a centralized gateway. But "IP geolocation" in the headline was measured substantially on data you can download for free.

The paper's own recommendation is the sensible trust model: avoid sub-national claims for mobile and Global South IPs, and treat the size of the matched prefix as a per-observation accuracy bound. A /31 row and a /13 row should not be consumed with the same confidence, and a database that returns honest granularity gives you the means to tell them apart.

Operators can fix the map with a text file

The strange thing about this problem is how cheap the network-side fix is. RFC 8805 defines the geofeed: a CSV file, one line per prefix, mapping address space to country, region, and city. RFC 9632 standardizes discovery, a geofeed: attribute on the RIR database object pointing at the file, so consumers can find it without being told. A carrier that assigns each regional gateway its own public pool and publishes a few hundred lines of CSV moves its subscribers from "somewhere in the country" to the right metro in every database that consumes feeds.

# geofeed, one line per regional CGNAT pool (documentation prefixes)
203.0.113.0/25,KE,KE-30,Nairobi,
203.0.113.128/25,KE,KE-17,Kisumu,

The prerequisite is regionalized pools: a geofeed can only describe structure that exists. That part costs address space, which is exactly what is scarce, but 5G softens it by letting the UPF sit regionally instead of in one national site, and IPv6, with no NAT at all, removes the sharing problem outright. We wrote a guide to the format, and our free geofeed checker validates a feed against the RFC grammar. The operators best placed to publish are the mobile carriers this study describes; nobody else knows which pool egresses where.

What we do with the half we control

At Ipregistry we crawl and merge published geofeeds daily, we keep prefix granularity tied to what networks announce rather than aggregating past announcement boundaries, and we take data corrections for ranges no feed covers.

The rest is admitting what a gateway address cannot tell you. Every Ipregistry lookup returns the mobile carrier's name, MCC, and MNC when an address carries carrier traffic, alongside the connection type and autonomous system. A non-null carrier field is the cue to switch trust models: believe the country, treat the city as a hint.

Practical rules for consuming mobile geolocation

• Detect mobile first: if the carrier field is set, score city and coordinates as low-confidence before using them for anything.
• Gate by country on mobile IPs, never by city. Catalog, currency, and compliance decisions are safe; city-level targeting and geofencing are not.
• Do not distance-match a mobile IP against a GPS fix or a billing address. A legitimate user 300 km from their egress gateway is the normal case in much of the world, not an anomaly.
• Cross-check the carrier's MCC against the geolocated country. MCC 639 means a Kenyan network regardless of where any database pins the IP, and a mismatch there is a stronger fraud signal than coordinates ever were.

The honest summary for mobile networks in 2026 is: country, yes; city, only where the operator's footprint or a geofeed supports it. Ipregistry returns location together with the carrier, connection-type, and network signals this article leans on, so you can apply that policy per lookup, and you can try it with 100,000 free lookups to get started.