Followup on: What’s up with BGP communities? - NANOG - lists.nanog.org
Why should network operators help commercial IP geolocation providers improve their data?
It’s a fair question. And honestly? They shouldn’t have to.
Let me explain why that answer led us to build ProbeNet, and what it means for how we approach IP geolocation.
When a geolocation provider asks an ISP to “submit a correction” or “update your geofeed,” they’re essentially asking for free labor to fix their product. Network operators rightfully push back on this. You’re not in the business of maintaining data for commercial services. You’ve got networks to run.
This creates a fundamental tension in the IP geolocation industry. If providers rely on voluntary submissions from thousands of ISPs to maintain accuracy, they’re building on an unstable foundation. The ISPs most willing to help are often the ones who already maintain accurate geofeeds. The ones least likely to engage are often the largest networks where most internet users are located.
So the question becomes: how do you build an IP geolocation service that doesn’t depend on ISPs doing unpaid work?
The Geofeed Reality Check
Geofeeds were designed to solve this exact problem. RFC 8805 established a standard way for network operators to publish location data. In theory, geolocation providers could just ingest these feeds and have accurate data. Problem solved, right?
Not quite. Here’s what we found when we analyzed geofeed coverage and accuracy:
Coverage is sparse. Only about 1.5% of routed IPv4 address space and 0.7% of IPv6 space is covered by geofeeds. That means for 98.5% of the internet, geofeeds simply don’t exist.
Accuracy varies significantly. In our NANOG 96 research presentation, we analyzed geofeeds against our active measurement data across 180+ countries. What we found:
- Country-level accuracy: ~92%
- Region-level accuracy: ~76%
- City-level accuracy: ~58%
And this is just for the 1.5% of address space where geofeeds exist at all.
There’s no verification mechanism. Geofeeds are self-reported data. They can be stale, incorrect due to network changes, or deliberately falsified. We’ve observed cases where:
- Legitimate networks have outdated geofeeds from years ago
- Hosting providers claim locations they don’t actually operate in (for SEO or VPN positioning)
- Anycast configurations make geofeed data misleading for actual user location
Maintenance is inconsistent. Even well-intentioned networks struggle to keep geofeeds updated as their architecture changes. A geofeed that was accurate six months ago might not reflect current routing reality.
Why We Chose Active Measurement and Built ProbeNet
This brings us back to the original question: if we can’t ask ISPs to submit corrections, and geofeeds alone aren’t sufficient, what’s the alternative?
Build independent measurement infrastructure.
ProbeNet today consists of 1,300+ servers across 550+ cities in 152 countries. We’re not talking about cloud VPS instances in a handful of data centers. We’re talking about diverse network placements across ~520 different ASNs, including networks most people have never heard of because they’re in places like Solomon Islands, Papua New Guinea, or rural African markets.
This infrastructure lets us do something geofeeds can’t: generate verifiable, first-party evidence about where IP addresses are actually being used.
When someone asks us “why do you think this IP is in Dallas?” we can point to latency measurements from multiple probe points, traceroute data showing network paths, and a decision tree that weighs dozens of signals. We’re not just repeating what someone told us. We’re showing evidence.
How Geofeeds Fit Into Our System
Here’s where I want to be very clear: we’re not saying geofeeds are useless or that we ignore them.
Geofeeds are one input in our decision tree. When we have a geofeed for a prefix, we ingest it. We score it based on factors like:
- Is it verifiable against the ASN that announces the prefix?
- When was it last updated?
- Does it conflict with other signals we’re seeing?
- Has the network operator contacted us to flag issues?
When active measurements and geofeeds agree, great. When they conflict, we investigate. And here’s the important part: when an ISP contacts us and says “your data conflicts with our geofeed and here’s why we’re correct,” we adjust the scoring for that prefix.
We’ve done this multiple times. Not because we think ISPs are always wrong, but because no single data source is always right - including our measurements.
The Coverage Problem
Let’s talk about scale for a moment. There are roughly 70,000 ASNs globally. Even if every one of them published a perfect, up-to-date geofeed tomorrow, we’d still face challenges:
- Large ISPs often provide service across multiple cities/states/countries. A geofeed might say “this /16 is in New York” but actual users could be distributed across the entire East Coast.
- Anycast means the same IP can be in multiple locations depending on where you measure from.
Active measurement helps us handle these cases because we’re observing behavior, not just reading labels.
The Verification Question
I know some folks will read this and think: “You’re just saying you don’t trust us.”
That’s not it. It’s that in a system serving billions of queries per month for security, fraud detection, content delivery, and compliance use cases, our customers need more than trust. They need evidence.
When a security team blocks a login attempt because an IP geolocates to an unexpected country, they need to justify that decision. “We blocked it because the IP owner said it was in Country X” is different from “We blocked it because latency measurements, routing paths, and behavioral signals all indicate Country X.”
When a streaming service enforces geographic restrictions (which yes, we know is controversial, but that’s a discussion about media licensing, not geolocation technology), they need defensible data that holds up when challenged.
This isn’t about trusting or not trusting ISPs. It’s about building a verification layer that works at internet scale.
Where We Go From Here
So back to the original question: why should ISPs help us?
Short answer: you shouldn’t have to. We built ProbeNet specifically so that IP geolocation accuracy doesn’t depend on thousands of ISPs volunteering to maintain perfect geofeeds.
Longer answer: If you do engage with us - whether by publishing a geofeed, hosting a probe server, or just flagging when our data is wrong - it makes the entire system better. But that engagement should be on your terms, ideally with mutual benefit.
That’s why we:
- Pay ISPs to host probe servers (this is us buying hosting services, not asking for favors)
- Maintain a correction portal that doesn’t require lengthy back-and-forth
- Have a support team that investigates reported issues within 24-48 hours
- Adjust our scoring when ISPs flag legitimate conflicts
We’re trying to build a system where accuracy doesn’t depend on unpaid labor from network operators. Geofeeds are part of that system, but they can’t be the whole system.
Final Thoughts
The “why should I help you for free” critique is legitimate. It’s actually the reason ProbeNet exists.
We’re not asking ISPs to be our unpaid data quality team. We’re building infrastructure to generate independent, verifiable location data at global scale. When ISPs do choose to engage - through geofeeds, corrections, or probe hosting - we appreciate it and we listen. But the core system is designed to work without requiring that engagement.