IP geolocation APIs, at APNIC 62, the IAB’s workshop report highlights why model is broken and possible fixes

Mumbai, India : At APNIC 62 in Mumbai this week, the Cooperation SIG session Behind the Pin: The Reality of IP Geolocation put a long-standing industry assumption on the table: that an IP-to-geo API can reliably answer “where is this user?” IAB Chair Dhruv Dhody walked operators, CDNs, and geo vendors through the draft IAB workshop report and the architectural gaps that commercial IP2Geo APIs inherit.

The session sat on top of the IAB Workshop on IP Address Geolocation (3–5 December 2025), which gathered operators, researchers, RIRs, and database vendors. The message from both venues is the same: country-level guesses are often good enough; city pins, coordinates, and security decisions built on those APIs are not.

Why this matters for every IP2Geo Location API

IP2Geo APIs sit behind fraud scoring, content licensing, tax and VAT rules, CDN steering, ad targeting, emergency routing, and “block this country” controls. Product teams treat the JSON as ground truth:

JSON

{ "country": "IN", "city": "Mumbai", "lat": 19.07, "lon": 72.87, "accuracy": "city" }

The IAB work, restated at APNIC 62, says that payload is an inference about network infrastructure, not a measurement of the person. IP addresses were never designed to represent physical location, and there is no stable one-to-one mapping from address to user or geography.

That is the architectural starting point. Everything else is a workaround.

Architecture: the pin was never the place

Dhody’s architecture slides at APNIC 62 grouped the problems that every commercial IP2Geo API still has to live with.

IP is not location. Dynamic addressing, CGNAT, carrier-grade sharing, mobile handoff, VPNs, privacy proxies, and LEO satellite gateways all break the “one IP, one place” model. The API still returns a city because the database must return something.

Accuracy collapses as you zoom in. Workshop participants put country-level accuracy above 95% in many datasets. City and coordinate accuracy drop sharply. Missing data is often snapped to a country or state centroid, the so-called “digital sinkhole,” where millions of addresses land on a single farm, park, or downtown intersection.

Physical proximity is not network proximity. Steering a user to the “nearest” PoP based on a geo database can produce worse latency than anycast or RTT-based selection. The API confuses civil geography with routing topology.

It is a weak security signal. Access control and compliance systems still use IP country as a gate. The data is hard to validate, easy to spoof with a VPN or residential proxy, and unsuitable as a standalone control. Using it that way is a documented misuse, not a feature.

Protocol evolution did not bake geo in. IPv6 privacy addresses, Apple Private Relay–style proxies, and similar deployments force vendors into heuristics and workarounds instead of a first-class location primitive.

Geofeeds: the “official” fix is still too thin

RFC 8805 geofeeds and RFC 9632 discovery were supposed to let operators publish the truth. APNIC even documents a geofeed: attribute on inetnum objects. Adoption is growing, but the format cannot say what APIs need to say.

Problems called out in the IAB report and on the APNIC 62 slides:

• One prefix cannot be mapped to multiple locations (anycast, roaming pools, shared CGNAT).
• There is no standard confidence or uncertainty field, so APIs invent precision they do not have.
• City and region names vary by language, transliteration, and geopolitics; typos and swapped ISO fields are common in the wild.
• Feeds overstate precision: a statewide or national pool is labelled as a single city.
• Entries go stale. There is no standard TTL or refresh contract. IPv4 secondary-market transfers can take weeks or months to show up, so legacy locations persist.

Network architecture makes this worse. CGNAT, mobile core, and satellite user terminals map thousands of subscribers to a gateway city. The geofeed, and therefore the API, describes infrastructure, not the handset.

A fragmented market with no correction loop

Commercial IP2Geo APIs do not share a format, methodology, or correction channel.

Providers use proprietary pipelines. ISPs cannot reliably push a fix into MaxMind, IP2Location, IPinfo, and a dozen others at once. Errors therefore persist across vendors. Database drops are asynchronous and often manual. When a block moves from one economy to another on the IPv4 transfer market, APIs keep serving the old country until someone notices customer tickets.

That is why two APIs can disagree on the same address, and why both can still be wrong.

Location, consent, and the privacy collision

The APNIC 62 / IAB privacy slides are the part most API buyers skip.

• Inference is passive. The user never consented to “you are in this city.”
• An IP is already a tracking identifier; attaching a city or coordinate raises the sensitivity. In many legal regimes that combination looks like personal data.
• Borders and timezones are unstable. A user a few kilometres from a frontier can flip country or tax region depending on which vendor you query.
• Privacy tools (VPNs, MASQUE, iCloud Private Relay, corporate proxies) exist specifically to break this mapping. Services that hard-depend on IP geo then degrade for the users who care most about privacy.
• Some privacy systems try to publish a coarse location via geofeeds. That is a trade-off, not a solution.

Eric Rescorla’s pushback when the workshop was briefed at IETF 125 is the blunt version: treating consent as a grey area while designing new geo mechanisms risks deepening a privacy hole instead of closing it.

What APNIC 62 added to the IAB story

The IAB workshop was virtual and Chatham House. APNIC 62 put the same findings in front of Asia-Pacific operators, with Dhody presenting the workshop report in the Cooperation SIG alongside practitioners from Fastah, Tata Communications, and MaxMind.

That mix matters in this region. CGNAT is normal, IPv4 transfers are active, mobile-first access dominates, and content and tax rules increasingly assume a country pin. An API that is “95% at country, much worse at city” is not a rounding error for an Indian, Indonesian, or Philippine ISP. It is a support queue.

The IAB report’s caution still stands: no single new protocol will cover pizza-near-me, CDN steering, licensing, and emergency calling at once. Different use cases need different signals.

How to fix IP2Geo, practical recommendations

A replacement “perfect location API” is the wrong goal. The fix is to make the signal honest, give operators a way to correct it, and stop asking IP for jobs it cannot do.

1. Treat country as the default contract, city as best-effort. API responses should carry granularity, confidence, and scope (user / infrastructure / egress / jurisdiction). If the prefix is a national CGNAT pool, return the country and refuse a fake city pin.

2. Extend geofeeds instead of abandoning them. Add: multiple locations per prefix, confidence, a stated meaning (user vs PoP vs gateway), a TTL, and stable location IDs (GeoNames, H3, or similar) instead of free-text city names. Work already pointing this way includes JSON-geofeed drafts that cite the IAB report.

3. Build a real correction loop. RIRs, operators, and API vendors need a signed, authenticated “this prefix moved” channel, not a support ticket. WHOIS geofeed: plus RFC 9632 discovery should be the default ingest path, with validators that reject swapped ISO codes, impossible prefixes, and adversarial Antarctica jokes before they hit production databases.

4. Separate routing decisions from civil geography. CDNs and anycast should prefer RTT, BGP, and measured performance. Use IP geo only as a hint, never as the sole steering input.

5. Stop using IP country as a security control. Fraud and access systems should combine device signals, authentication, payment risk, and (where the user opts in) client-provided location. IP geo can be a weak prior. It cannot be the lock.

6. Put consent on the use cases that need precision. Licensing and emergency services need a different primitive: user-asserted or OS-mediated location with purpose limitation, not a silent WHOIS lookup. Coarse, operator-published geo can remain for CDN and language defaults.

7. Publish disagreement. APIs should expose when vendors conflict, when the record is older than N days, and when the mapping is a sinkhole centroid. Silent precision is the product defect.

8. Operators: ship geofeeds and keep them current. Especially after IPv4 transfers, CGNAT pool moves, and new mobile gateways. An unpublished prefix will be guessed. A stale feed will be believed.

Bottom line

IP2Geo Location APIs are useful coarse hints. They are not a map of people.

APNIC 62 and IAB Chair Dhruv Dhody’s workshop readout make that official for the operator community: the architecture never supported the pin, geofeeds cannot express uncertainty, the vendor market has no shared correction path, and privacy tools will keep punching holes in the model.

The industry does not need a more confident latitude. It needs APIs that say “country, medium confidence, infrastructure gateway, data 40 days old”, and applications that are designed to live with that answer.