Based on: IP Geofeeds: Trust, Accuracy, and Abuse | NANOG 96
“We publish accurate geofeeds but why doesn’t IPinfo just trust them?” This deserves a technical answer backed by research data.
The Problem: Geofeeds Contain Significant Errors
We analyzed geofeeds at scale using two methods:
Active Measurement (1,330 probes, 27.7M RTTs):
- Country-level: 92.0% accurate → 8% wrong country
- City-level: 79.6% accurate → 20.4% wrong city
Mobile Device GPS (169 devices, 24 countries):
- Country-level: 84.5% accurate
- City-level: 29.9% accurate → 70% wrong city
If we blindly trusted geofeeds, nearly 1 in 5 city-level locations would be incorrect.
Three Categories of Errors
1. Innocent Mistakes (The Minority)
Real examples from our dataset:
66.118.40.0/24,AL-11,AL,Tirana— country and region fields swapped196.48.162.0/24,QA,Baladiyat ad DawÃÆ...— UTF-8 encoding failures2a12:bec4:12a5:137a::/6,FR,FR-84,Lyon— typo: /6 instead of /64
These are fixable through better tooling and validation.
2. Infrastructure vs. User Location (The Nuance)
Top mismatching geofeeds include:
- CDNs: Cloudflare, Fastly (anycast = user location ≠ server location)
- Privacy services: iCloud Private Relay, Cloudflare WARP
- Mobile carriers: T-Mobile (CGNAT, complex routing)
- Tier 1 networks: Cogent, GTT (BGP announcement point ≠ user location)
A network opertor’s geofeed might say “Chicago data center” but users are in Indiana. Both are correct for different purposes—we need to distinguish infrastructure location from user location.
3. Deliberate Fraud (The Crisis)
Real case: One geofeed mapped ~101k IPv6 prefixes to 249 countries, including:
2a12:bec4:12a7:3a::/64,AQ,,Villa Las Estrellas— Antarctica2a12:bec4:12a6:30db::/64,KP,,Pyongyang— North Korea
Our VPN report found 26% of VPN provider IPs have location mismatches between geofeed claims and measurement reality. Example: NordVPN claiming US location for Moldovan infrastructure.
Addressing Commong Network Operator Concerns
Geofeed gets country level location right 92% of the time. The problem: we can’t programmatically distinguish legitimate ISPs from VPN providers claiming Antarctica. When you flag mismatches, you’re not correcting errors—you’re providing signals that help us tune our system to recognize “legitimate operator + complex routing” vs. “misdirection”
“Active measurement can’t know my network better than I do.”
Correct. Active measurement fails for:
- Anycast networks
- Tunneled/VPN traffic
- Complex enterprise routing
- CGNAT and mobile networks
That’s why operator input matters. When measurement contradicts good geofeeds, we investigate and defer to your expertise. But without verification, we’d be importing the misdirected location data.
“Just use geofeed as tier-1/primary data.”
If we did, we’d accept 101k fraudulent prefixes. The 8-20% error rate isn’t acceptable for customers using our data in cybersecurity, content delivery, and fraud prevention.
How We Actually Use Geofeeds
Our data pipeline:
- Active measurement (primary source + verification layer)
- Geofeed ingestion (enhanced when measurement agrees or when measurement is noisy)
- Operator feedback (signals for tuning: distinguishes edge cases from adversarial submissions)
- Manual review (for flagged mismatches)
When legitimate operators report mismatches, we treat it as a system calibration signal, not an error report.
Moving Forward
We’re working with the IETF on geofeed improvements:
- Validation mechanisms and operator feedback loops
- Better tooling (geofeed-validator, OpenGeoFeed)
- Format enhancements (validity periods, location identifiers)
To network operators: If our data contradicts your accurate geofeed, please flag it. You’re helping us distinguish legitimate complexity from fraud. We’re not questioning your expertise—we’re trying to catch the bad actors while honoring your data.
The reality: IP geolocation requires verification because fraud exists at scale. We’re committed to working with legitimate operators to improve accuracy while protecting against abuse.
Full research presentation: NANOG 96