An Internet Architecture Board workshop report published in July 2026 captures a tension many application teams already see: services still want regional context, while privacy proxies, satellite networks, mobile egress, and cloud architectures make an observed IP address less representative of a user’s actual location.
I work with the 98IP team. The report is useful because it frames this as an architecture problem, not simply a “bad IP database” problem.
IP addresses were built for routing
Geolocation systems infer location from registry data, routing, operator submissions, commercial observations, and other signals. No precise user coordinate is embedded in an IP address.
New deployment models widen the gap between network and user location:
- satellite traffic may exit through a distant gateway;
- privacy proxies intentionally hide the original client address;
- mobile networks may centralize egress;
- cloud prefixes can move between facilities or regions;
- databases refresh on different schedules.
A privacy proxy is doing its job
Privacy proxies reduce passive linkability by preventing a destination from seeing the client’s original address. If an application silently expects that address to reveal precise location, the privacy and location goals conflict.
The report suggests that applications which genuinely need location may need transparent, consent-based application signals instead of increasingly precise inference from a passive network identifier.
Three questions proxy evaluators should separate
- Where is the proxy exit network announced and operated?
- How do major databases classify the exit?
- What does the target infer after combining IP with account, language, device, and session signals?
These answers can disagree. A newly moved prefix may be correctly operated in one country while an older database still shows its previous location. A database match, meanwhile, does not prove physical proximity or residential network characteristics.
Country and city are different confidence levels
Country classification is generally more stable than city classification. Teams should define the minimum granularity required by the workflow.
For localization and market research, country or region may be enough. City claims need a broader evidence set: several datasets, ASN, DNS behavior, latency, and repeated sessions. Even then, city should be reported as a confidence range.
A better operational model
- IP for coarse routing and abuse controls;
- explicit, consented signals for user-facing location;
- clear fallback behavior when signals disagree;
- correction workflows for consistently misclassified prefixes;
- data minimization so the system does not collect more precision than needed.
What buyers should test
Test country, region, city, ASN, DNS, and session stability separately. Record the database and timestamp for every observation. Expect temporary disagreement after routing or prefix changes. Do not treat latency as proof of exact location, and do not assume a target site’s decision is universal.
For authorized regional testing, 98IP lists available location and session options at https://en.98ip.com/?k=dev.
Source: Internet Architecture Board, Report from the IAB Workshop on IP Address Geolocation, July 2026. It remains an Internet-Draft and may change.
Top comments (0)