Maybe our approach with MaxMind could be relevant here. We previously had major trust issues with them due to one problematic customer, so we changed how we manage our geolocation data. LARUS leases IPs to many types of customers. Some, like VPN or proxy providers, may submit false or unclear location data. Others—mainly regional ISPs and telecoms—serve real end users in fixed locations. To handle this, we divided our geolocation data into two separate geofeeds: - Trusted: Customers whose location data we have independently verified and are 100% confident about. - Normal: Customers whose claimed locations are passed through as-is, leaving MaxMind to decide how to handle them. We also told MaxMind that for the trusted data, any technical signal (e.g., ping latency) that doesn’t align should be considered inaccurate—not the data itself. This ensures high accuracy for home-user networks, while keeping strict control over which customers qualify for the trusted list. https://larus.net/ipv4/geofeed https://larus.net/geofeed-trusted -- Kind regards. Lu On Thu, Oct 23, 2025 at 15:26 Jon Lewis via NANOG <nanog@lists.nanog.org> wrote:
On Wed, 22 Oct 2025, Mark Blackford via NANOG wrote:
Thank you Ben and Abdullah for joining the discussion. I understand the balance IPinfo has to make, but hopefully what I have explained to Abdullah on LinkedIn and your support team about the nature of hub and spoke EVPL/NNI networks, point to point IP assignments in /31 ranges, and automatic geofeeds from IPAM product like Netbox helps clarify how your probes do not paint the whole Geo IP picture.
For example from my support case, an IPinfo probe in Charlotte, NC sends data to my customer also Charlotte, but has to traverse Internet providers to first get to my network hub in Dallas, and then make the trip over my EVPL/NNI back to my end user in Charlotte who is the one that needs accurate Geo IP location for content providers. I am sure this ping time should be about twice the expected 25-30ms round trip latency expected.
Meanwhile, an IPinfo probe in Dallas pings the other end of the /31 with < 1ms latency, which is just on a gateway on a router with no users, and simply concludes I am lying in the geofeed, the /31 must be in Dallas and not Charlotte.
It sounds like your geofeed needs "higher resolution" if you want it to be honest about where the IPs are in use. Instead of the /31s, break those into /32s each at the appropriate location.
Where I work currently, we've had quite a bit of difficulty both with stale IP Geo data on end-user systems and IP Geo providers with stale data for a former RIPE /16 $work purchased via a broker several years ago.
Prior to this thread, I was unaware of ipinfo.io, and I was pleased to see on their website that they allow ISPs to "register" their geofeed...so I did that last night. I also did test lookups (another welcome feature not all IP Geo providers provide) and found that most of what I checked was correct, but not all. I got an email early this morning thanking me for sharing our feed. It'll be interesting to see if/how soon it corrects their incorrect data.
At a previous job, $work had a VPN division, and I know VPN was popular for bypassing streaming service content restrictions based on IP Geo. We actually did have a global network, and so we had VPN servers all around the world. I can easily imagine a smaller VPN provider might lie in their geofeed to try to trick IP Geo providers in essentially saying the VPN provider has a wider footprint than they do (servers in countries where they're really not).
I hope that doesn't keep them from trusting a broadband ISP's geofeed. We don't provide VPN (other than for staff to be able to work) and depend on accurate IP Geo data so that our customers get the right local channel lineups from streaming TV services and don't get blocked from websites that have decided to block access from "abroad".
---------------------------------------------------------------------- Jon Lewis, MCP :) | I route Blue Stream Fiber, Sr. Neteng | therefore you are _________ http://www.lewis.org/~jlewis/pgp for PGP public key_________ _______________________________________________ NANOG mailing list
https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/ZUT2UKZ5...