Followup on: What’s up with BGP communities? - NANOG - lists.nanog.org
Geofeed (RFC 8805) was designed to solve a real problem: give network operators a standardized way to publish the geographic locations of their IP ranges. In theory, it’s elegant. Operators know their networks best, so let them declare where their IPs are used, and IP geolocation providers can consume that data.
In practice, the picture is more complicated.
In a recent NANOG thread, operators pushed back hard on IP geolocation providers who don’t treat geofeed as the authoritative source. Mike argued:
“Geolocation providers should be using geofeed data as tier 1 data since they are self-published. Are you saying you know more about my prefixes than me?”
Sometimes, yes.
When we have a ProbeNet server hosted in a specific data center, we can pinpoint that facility’s street address. We may not know the rack or the room, but we know the building. And through active measurement, we can geolocate neighboring IP addresses to that same facility based on sub-millisecond RTT. This level of granularity isn’t available in geofeeds, which typically specify a city or region rather than a specific facility.
That said, Mike’s broader point stands for many operators. The problem is that operators who maintain accurate, granular geofeeds are the exception, not the rule.
The maintenance problem
There are over 70,000 ASNs in the global routing table. How many maintain accurate geofeeds? That is just ASN; those prefixes are operated by hundreds of thousands of companies and network operators, and the location of those prefixes ASNs does not have a definite overview of. They can be located anywhere, and the ASN has a generalized assumption of where they could be located.
Jon Lewis described what diligent maintenance looks like: “We use an IPAM that allows us to tag every subnet with a ‘location’, and each location has a full street address. The coworker who setup our geofeed wrote a script that pulls all the allocated subnets and their locations from IPAM and builds the geofeed.”
That’s excellent. It’s also rare. Most large telecoms don’t publish geofeeds at all. Many that do publish only country-level data. Others set it up once and never update it. When we process geofeed data at scale, we see everything from meticulously maintained files to feeds that haven’t been touched in years.
Peter Folk described the ISP frustration with this reality: “Unfortunately, more often than not that information is ignored and instead all of our IPs show up as coming from a small town 20 miles from our main customer concentration… or from Chicago. Both of those can lead to real problems for customers.”
He’s right to be frustrated. But the solution isn’t to blindly trust all geofeeds—it’s to build systems that can distinguish good data from bad.
The verification gap
Job Snijders raised a critical point about geofeed’s infrastructure: “The approach described in the RFC how to authenticate Geofeed data using the RPKI turned out to be a dud: in the last few years I’ve been unable to find any other people willing to implement & support the scheme.”
This matters. Without authentication, anyone can publish a geofeed claiming their IPs are anywhere. There’s no cryptographic proof that the publisher actually controls those ranges. There’s no mechanism to detect when a geofeed has been compromised or is being used deceptively.
Ben Cartwright-Cox explained why this creates problems: “A very much non-zero amount of geofeeds from providers opportunistically putting their prefixes in countries they are not, mostly for VPN placement (it sure is a lot nicer to VPN in the USA that everybody thinks is in South Africa, than actually running a VPN in South Africa).”
For use cases like content licensing enforcement, this isn’t a theoretical concern. Streaming services pay for regional rights. If they rely on geofeed data that VPN providers have manipulated, they’re violating their contracts.
The granularity problem
Even accurate geofeeds often lack the granularity that modern use cases demand. Country-level data might be fine for basic content localization, but it’s useless for local TV channel lineups, regional advertising, or fraud detection.
Jon Lewis made this point: “For Abdullah, not knowing the layout of a service provider’s network, I don’t care how many points around the Internet you can measure RTT from, you’re not going to accurately guess IP Geo from RTT down to the DMA. As a FTTH ISP, that’s the level of accuracy our customers demand.”
He’s right that active measurement has limitations. RTT-based triangulation can’t pinpoint a ZIP code with certainty. But neither can a geofeed that only specifies “United States” or “California.” When we have a probe server in a specific facility and can measure single-digit millisecond RTT to a target IP, that’s often more granular than what the geofeed provides.
Why fallback makes sense
Our approach at IPinfo: active measurement as the primary source, geofeed as a fallback when measurement data is noisy or unavailable.
This isn’t about disrespecting operator knowledge. It’s about building a system that works at scale, across tens of thousands of networks with varying levels of geofeed quality.
When our measurements align with a geofeed, confidence is high. When they conflict, we investigate. Sometimes our measurement is wrong—network architecture can create misleading RTT patterns. Sometimes the geofeed is wrong—outdated, misconfigured, or intentionally false. Having both sources lets us cross-reference and catch errors that either source alone would miss.
Laszlo H captured the operator frustration well: “Instead of asking where a user is, the consumers of IP geolocation data are telling users where they are, usually with no way to override it.”
This is why we maintain open support channels and respond to correction requests. The system isn’t perfect. But building on a foundation of verifiable measurement, with geofeed as a fallback, produces better outcomes than building on a foundation of unverified declarations.
Geofeed is a valuable tool. It’s just not a sufficient one.
Want guaranteed accuracy for your prefixes? Help us improve IP geolocation accuracy and host a ProbeNet server: Host a IPinfo Probe Server