I believe the bigger question here is: How does bgp.tools know what the specific communities shown on the page, e.g. https://bgp.tools/communities/13335 mean? I now have this question also. Some copied examples: Community Description 13335:10106 PoP: bos01 13335:10358 PoP: cwb03 13335:10712 PoP: den04 13335:10766 PoP: maa05 13335:10920 PoP: zrh02 And here's some other copied examples from AS174 Cogent https://bgp.tools/communities/174 : Community Description 174:21000 Route is learned from NA (North America) non-customer 174:21001 Route is NA internal or customer route 174:21100 Route is learned from EU (Europe) non-customer 174:21101 Route is an EU internal or customer route 174:21200 Route is learned from AP (Asia Pacific) non-customer 174:21201 Route is an AP internal or customer route 174:22009 Italy 174:22010 Netherlands 174:22011 Portugal 174:22012 United Kingdom 174:22013 United States 174:22014 Sweden As Ronan stated, I'm not aware either of a way this is communicated by BGP itself, so somehow this documentation must exist somewhere publicly - is it only known by bgp.tools when they specifically have a route peering connection with an AS and are given the community usage details? -Bruce Wainer On Thu, Jan 22, 2026 at 4:25 PM William Herrin via NANOG < nanog@lists.nanog.org> wrote:

On Thu, Jan 22, 2026 at 12:38 PM Ronan Pigott via NANOG <nanog@lists.nanog.org> wrote:

...

I want to know, where does this supplementary information about the communities come from, in this case the "PoP: blah" bits? I don't think it is communicated by BGP directly, so is there some standard out of band mechanism to describe the communities? Or am I just ignorant of this BGP feature?

Hi Ronan,

A BGP community is an arbitrary label attached to a route. It means whatever the person who wrote the label wants it to mean.

A BGP router has "route maps" which can use or set these "labels" on routes that it has received. For example, a route map may say, "If community X then make this route a lower priority than others." Or it might say, "If community Y, discard and don't use this route."

Route maps can also set communities. For example, they can say: "If the route came from this place, set community X." Then someone else on a different router can say, "If community X then I know the route came from that place and I want to do something non-default with it, such as discarding it."

Like so many things in routing, the use of the terminology "community" is weird and confusing. It's just an arbitrary label that means whatever the person who defined it wants it to mean.

Make sense?

Regards, Bill Herrin

-- For hire. https://bill.herrin.us/resume/ _______________________________________________ NANOG mailing list

https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/MKA7UTJW...

January 22, 2026 at 2:24 PM, "William Herrin" <bill@herrin.us> wrote:

A BGP router has "route maps" which can use or set these "labels" on routes that it has received. For example, a route map may say, "If community X then make this route a lower priority than others." Or it might say, "If community Y, discard and don't use this route."

Route maps can also set communities. For example, they can say: "If the route came from this place, set community X." Then someone else on a different router can say, "If community X then I know the route came from that place and I want to do something non-default with it, such as discarding it."

Hi Bill, Thanks for your response. That's helpful, but I think I'm still confused. IIUC, a "route map" is a configuration local to the BGP router. So, an operator may make some decision about the meaning of a community and then attach it to routes advertised to their peers, but no peer can reasonably act on the community information without understanding the meaning intended by the owner, right? So if I operated a network and my BGP peer advertises routes that belong to a bunch of communities, how can I possibly learn the intended meaning of those communities to configure a sensible route map for my router? E.g. given "If community X, then I know the route came from that place", how did I learn "the route came from that place" is the meaning of "community X"? I gather this meaning is purely the decision of the network operator, so we have to communicate that somehow if I am ever to act on the community information. Otherwise, why bother to advertise the community at all? It appears bgp.tools has some knowledge of the community meanings, but I don't understand how they learned that, or how it works between real networks. Cheers, Ronan

Many ASNs will publish some of their communities , along with their meaning or usage. There are generally two types. 1. Information communities. "This route came from FOO". FOO could be country, city, exchange, anything. You could use that information to make your own decisions about a route via routing policy, 2. Action communities. "If you add community FOO, I will take action BAR." This is a community you could add to an advertisement to a given ASN to tell them to take some specific action. Don't announce it here, black hole this, etc. Not every community that is in use has a publicly published meaning. There are tons of them that ASNs will use for their own purposes. It's usually good hygiene NOT to send those out to the DFZ, but sometimes it happens. ( Or is unavoidable for reasons. ) Sometimes the meaning of those communities can be inferred, sometimes asking the right person can give you an answer. But there will always be some out there that you won't ever know what they mean unless you work for that AS. You could ignore them, or strip them off when they enter your network, whatever makes the most sense in your case. On Thu, Jan 22, 2026 at 4:57 PM Ronan Pigott via NANOG < nanog@lists.nanog.org> wrote:

January 22, 2026 at 2:24 PM, "William Herrin" <bill@herrin.us> wrote:

...

A BGP router has "route maps" which can use or set these "labels" on routes that it has received. For example, a route map may say, "If community X then make this route a lower priority than others." Or it might say, "If community Y, discard and don't use this route."

Route maps can also set communities. For example, they can say: "If the route came from this place, set community X." Then someone else on a different router can say, "If community X then I know the route came from that place and I want to do something non-default with it, such as discarding it."

Hi Bill,

Thanks for your response. That's helpful, but I think I'm still confused.

IIUC, a "route map" is a configuration local to the BGP router. So, an operator may make some decision about the meaning of a community and then attach it to routes advertised to their peers, but no peer can reasonably act on the community information without understanding the meaning intended by the owner, right? So if I operated a network and my BGP peer advertises routes that belong to a bunch of communities, how can I possibly learn the intended meaning of those communities to configure a sensible route map for my router?

E.g. given "If community X, then I know the route came from that place", how did I learn "the route came from that place" is the meaning of "community X"? I gather this meaning is purely the decision of the network operator, so we have to communicate that somehow if I am ever to act on the community information. Otherwise, why bother to advertise the community at all?

It appears bgp.tools has some knowledge of the community meanings, but I don't understand how they learned that, or how it works between real networks.

Cheers,

Ronan _______________________________________________ NANOG mailing list

https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/RUACTUUR...

This page has compiled community guides from several network operators. Looks like a good resource. https://onestep.net/communities/ Gaël On Thu 22 Jan 2026 at 22:08, John Fraizer via NANOG <nanog@lists.nanog.org> wrote:

Read RFC1997 and RFC1998 for more info n depth understanding of communities and their value/use.

-- John Fraizer LinkedIn profile: http://www.linkedin.com/in/johnfraizer/

On Thu, Jan 22, 2026 at 5:02 PM William Herrin via NANOG < nanog@lists.nanog.org> wrote:

...

...

IIUC, a "route map" is a configuration local to the BGP router. So, an operator may make some decision about the meaning of a community and

On Thu, Jan 22, 2026 at 1:55 PM Ronan Pigott <ronan@rjp.ie> wrote: then

...

attach it to routes advertised to their peers, but no peer can reasonably act on the community information without understanding the meaning intended by the owner, right?

Correct.

...

So if I operated a network and my BGP peer advertises routes that belong to a bunch of communities, how can I possibly learn the intended meaning of those communities to configure a sensible route map for my router?

You ask your peer. In some cases, the peer writes a web page which explains what their communities mean so that they can just say, "look at this web page." And then you have sites like bgp.tools which collect the information from the various web pages individual networks have published into a large database.

Because the communities have arbitrary meanings, those meanings are communicated person to person, not machine to machine.

Regards, Bill Herrin

-- For hire. https://bill.herrin.us/resume/ _______________________________________________ NANOG mailing list

https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/IAFKURAF... _______________________________________________ NANOG mailing list

https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/N544SMUL...

On 25 Jan 2026, at 18:31, Martin Pels via NANOG <nanog@lists.nanog.org> wrote: [..] https://datatracker.ietf.org/doc/draft-ietf-grow-yang-bgp-communities/

Using the model described here, networks can publish a JSON file with descriptions for the communities they use for their Autonomous System.

I thought everybody just added a simple text file to: https://github.com/NLNOG/lg.ring.nlnog.net/tree/main/communities and called it a day? That file format is simple, succint and readable by humans. Is the intent of that YANG document to let a computer parse it and do automatic setting of action communities? Or is it just to see what the label is? For my own looking glass what I do is I parse the above directory and translate it to a little lookup array. The two YANG ones from RIPE I parse in a similar way, similar to what the NLNOG LG does, all the YANG markup is just tossed though. But in the end, for most purposes it is to turn the numbers into a label so that one can see what the community means. And unless it is an action policy, no computer will be acting upon those communities as one has to understand the full intent (and no, an LLM will not get that yet, and please do not let a LLM close to BGP :) ) Thus they should be good for humans setting an action community or viewing what the community means. Any other purposes and thus reason why to make it more complex than that? A WHOIS/RPSL way of being able to indicate where one stores their community.txt file for easy discovery would be cool though. Though that is likely something https://www.peeringdb.com <https://www.peeringdb.com/> could do and then it is solved too. And for LGs the above repo has them all :) Only other source is https://bgp.tools <https://bgp.tools/> which has sometimes more details on some networks when folks have entered them manually there. Regards, Jeroen

an entire YANG model for these is not especially beneficial

Having some structure for specific usecases of bgp communities might be useful- e.g. geo-based origin communities. This could be accomplished in a way similar to what was done for ip geolocation via rfc8805- which I've found is very useful for maintaining these datasets over time from known publishers. For more varied or generic community usecases, I totally agree that a unified model might be more difficult and less beneficial. On Mon, Jan 26, 2026 at 1:52 PM Tom Beecher via NANOG <nanog@lists.nanog.org> wrote:

...

And for LGs the above repo has them all :) Only other source is https://bgp.tools <https://bgp.tools/> which has sometimes more details on some networks when folks have entered them manually there.

BGP.Tools is not the only source. onestep.net used to be the defacto source that collated most of these.

I agree though that an entire YANG model for these is not especially beneficial. We store communities in a similar way, text file that is human readable but also parseable to translate when needed.

I could see a use case for this to detect WHEN an AS's published communities **CHANGED** without having to go look for that, but with as infrequently as most do it's kinda meh.

On Mon, Jan 26, 2026 at 11:36 AM Jeroen Massar via NANOG < nanog@lists.nanog.org> wrote:

...

...

On 25 Jan 2026, at 18:31, Martin Pels via NANOG <nanog@lists.nanog.org

wrote:

...

[..]

...

...

Using the model described here, networks can publish a JSON file with

descriptions for the communities they use for their Autonomous System.

I thought everybody just added a simple text file to: https://github.com/NLNOG/lg.ring.nlnog.net/tree/main/communities and called it a day? That file format is simple, succint and readable by humans.

Is the intent of that YANG document to let a computer parse it and do automatic setting of action communities? Or is it just to see what the label is?

For my own looking glass what I do is I parse the above directory and translate it to a little lookup array. The two YANG ones from RIPE I

https://datatracker.ietf.org/doc/draft-ietf-grow-yang-bgp-communities/ parse

...

in a similar way, similar to what the NLNOG LG does, all the YANG markup is just tossed though.

But in the end, for most purposes it is to turn the numbers into a label so that one can see what the community means. And unless it is an action policy, no computer will be acting upon those communities as one has to understand the full intent (and no, an LLM will not get that yet, and please do not let a LLM close to BGP :) )

Thus they should be good for humans setting an action community or viewing what the community means.

Any other purposes and thus reason why to make it more complex than that?

A WHOIS/RPSL way of being able to indicate where one stores their community.txt file for easy discovery would be cool though. Though that is likely something https://www.peeringdb.com <https://www.peeringdb.com/> could do and then it is solved too.

And for LGs the above repo has them all :) Only other source is https://bgp.tools <https://bgp.tools/> which has sometimes more details on some networks when folks have entered them manually there.

Regards, Jeroen

_______________________________________________ NANOG mailing list

https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/D727FQQX...

...

_______________________________________________ NANOG mailing list

https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/RN2G5OVZ...

Geofeeds are useful because they cut out the middleman in terms of geo info, and provide a mechanism for someone to detect and react to that change quickly, since a very large use case for these is targeted content and advertising.

I work for IPinfo. We use active measurements for IP geolocation as a primary source of data. We consider geofeeds as a second-tier source of information. We use it as a fallback data source when active measurements fail. The honest reality is that geofeed does not provide verification metadata of any form. They can be stale, wrong, or false, and maintaining them is a pain for ASN providers. Many large telecoms do not even have publicly accessible geofeed. For example, AS11260 (Eastlink.ca) does not have a publicly accessible geofeed to my knowledge, and I am not sure who to reach out to get one. Not all ASNs are going to publish geofeeds, and it is fine. Providing IP geolocation data has real value, and I do not believe it is the ASN or ISP's responsibility to have their data accurately reflected on third-party IP geolocation providers like us. The ideal operation that we have is this: we do IP geolocation based on building networks of servers running active measurements, working with ASNs, attending conferences and talking with as many ASNs and range operators as possible. Shake as many hands as possible. It sounds borderline impossible, but honestly, that is the only fair way to operate as an IP geolocation provider. If, in any case, an ASN does not want to help us, that is fine, but that does not excuse negligence on our part towards end users. Our responsibility is towards end users (the customers of ASNs; internet users) and ASNs can be just voluntary partners. The moment an ASN, ISP, or an end user has an issue, we have to jump into the conversation and fix the issue. That is why I am here. There is a mention of the word "geolocation" in the NANOG forum, and we have to come here and ask if everything is okay. Do you have any issues with us? Can you check your data with us? Can you help us fix the issue? This MO of IP geolocation as a service should be: aggressive outreach. But we also have to admit that we are not the only provider, and we are not even the largest provider out there. But we do not care, we have to be responsible to everyone. We have to back our data. — Abdullah | DevRel, IPinfo https://www.linkedin.com/in/reincoder/

In fact, 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?  On Tuesday, January 27, 2026 at 07:03:45 AM PST, Ca By via NANOG <nanog@lists.nanog.org> wrote: On Mon, Jan 26, 2026 at 11:47 PM Abdullah DevRel of IPinfo via NANOG < nanog@lists.nanog.org> wrote:

...

Geofeeds are useful because they cut out the middleman in terms of geo info, and provide a mechanism for someone to detect and react to that change quickly, since a very large use case for these is targeted content and advertising.

I work for IPinfo. We use active measurements for IP geolocation as a primary source of data. We consider geofeeds as a second-tier source of information. We use it as a fallback data source when active measurements fail.

The honest reality is that geofeed does not provide verification metadata of any form.

The “honest reality”, as you say, is that geolocation firms like yours have failed to provide reliable data to paying customers for years. That is why the IETF made geofeeds. My customers started having outages because geolocation firms have bad data, and enterprises use that bad data in firewall and cdn rules which cause outages. For example, geolocation firms provide data that a customer IP is in xyz country but the firewall rules only allow abc country… Anyhow, as a person who publishes geofeed data representing 100s of millions of users, please …everyone… publish and consume first party geofeed data and do not listen to FUD from people trying to sell you the same data that we publish for free. They can be stale, wrong, or false, and maintaining them is a pain for ASN

providers. Many large telecoms do not even have publicly accessible geofeed. For example, AS11260 (Eastlink.ca) does not have a publicly accessible geofeed to my knowledge, and I am not sure who to reach out to get one. Not all ASNs are going to publish geofeeds, and it is fine.

Providing IP geolocation data has real value, and I do not believe it is the ASN or ISP's responsibility to have their data accurately reflected on third-party IP geolocation providers like us.

The ideal operation that we have is this: we do IP geolocation based on building networks of servers running active measurements, working with ASNs, attending conferences and talking with as many ASNs and range operators as possible. Shake as many hands as possible. It sounds borderline impossible, but honestly, that is the only fair way to operate as an IP geolocation provider.

If, in any case, an ASN does not want to help us, that is fine, but that does not excuse negligence on our part towards end users. Our responsibility is towards end users (the customers of ASNs; internet users) and ASNs can be just voluntary partners. The moment an ASN, ISP, or an end user has an issue, we have to jump into the conversation and fix the issue.

That is why I am here. There is a mention of the word "geolocation" in the NANOG forum, and we have to come here and ask if everything is okay. Do you have any issues with us? Can you check your data with us? Can you help us fix the issue?

This MO of IP geolocation as a service should be: aggressive outreach. But we also have to admit that we are not the only provider, and we are not even the largest provider out there. But we do not care, we have to be responsible to everyone. We have to back our data.

— Abdullah | DevRel, IPinfo

https://www.linkedin.com/in/reincoder/ _______________________________________________ NANOG mailing list

https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/SDOEDEZ7...

NANOG mailing list https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/3KXUUIAG...

On Tue, Jan 27, 2026 at 07:03:15AM -0800, Ca By via NANOG wrote:

That is why the IETF made geofeeds.

My customers started having outages because geolocation firms have bad data, and enterprises use that bad data in firewall and cdn rules which cause outages. For example, geolocation firms provide data that a customer IP is in xyz country but the firewall rules only allow abc country…

Anyhow, as a person who publishes geofeed data representing 100s of millions of users, please …everyone… publish and consume first party geofeed data and do not listen to FUD from people trying to sell you the same data that we publish for free.

Geofeed indeed makes for an interesting information source and seems a useful tool to have in the toolbox. Unfortunately, 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. I've come to suspect this failure in market adoption is because the Geofeed authenticator design is just too unergonomic. But whatever the reason, I've not seen anyone on this planet (other than myself) publish Geofeed data with an authenticator. I stopped signing mine. So, as it stands, Geofeed information generally is published & consumed with weak controls on semantic correctness, integrity & authenticity. Perhaps that's fine for what it is? Kind regards, Job ps. Geofeed's failure to take advantage of the RPKI doesn't bode well for the usability of other "Geofeed-inspired" authentication schemes. The IETF should do a better job weeding out such unpractical workflows, for instance by requiring demonstration of actual implementations before RFC publication.

Depends on what your (from the geoip providers point of view) customers goals are really. 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), but there is also a number of networks that are using geo feeds as a opportunistic way to get their prefix is into countries where copyright holders don't necessarily have a with sending notices to. If the goal of you using a geoip database is to sniff out customers who are accessing content the you are contractually obligated not to serve in their region, well, you would actually prefer your geoip provider do it's homework rather than taking geofeeds at face value. On 1/27/26 17:10, Mike via NANOG wrote:

Are you saying you know more about my prefixes than me?

Hi, Please do not lump us with the rest of the industry. We are not the singular representation of the industry. By methods, operations, and philosophy, we try to distance ourselves from the faults of the industry. If your customers are having issues with geolocation, just talk to us. We will investigate. We are not the representative of the entire industry. We are not a "benevolent monopoly", we are in the maybe top 3 IP geolocation providers in the world, and we are trying our absolute best to have as many interactions to fix our data.. We invested in a massive scale network infrastructure, research program, and huge data investment just because geofeed-based IP geolocation, which has been the standard model for the IP geolocation industry, causes so many headaches for end users. Even with that, we have a support team, social media, researchers going to conferences, and DevRel responding to user queries because no matter how much technical and research investment we make, there will be gaps, so we should be able to respond to user queries and help out. — Abdullah | DevRel, IPinfo

One pain in the ass part of geolocation is that it takes a company anywhere from 1 - 3 weeks until they push their “update” to their systems. If these are eyeball customers, that isn’t really acceptable. The geo-ip companies need to find a way to do near-instant updates. -Mike

On Jan 27, 2026, at 18:40, Abdullah DevRel of IPinfo via NANOG <nanog@lists.nanog.org> wrote:

Hi,

Please do not lump us with the rest of the industry. We are not the singular representation of the industry. By methods, operations, and philosophy, we try to distance ourselves from the faults of the industry. If your customers are having issues with geolocation, just talk to us. We will investigate.

We are not the representative of the entire industry. We are not a "benevolent monopoly", we are in the maybe top 3 IP geolocation providers in the world, and we are trying our absolute best to have as many interactions to fix our data..

We invested in a massive scale network infrastructure, research program, and huge data investment just because geofeed-based IP geolocation, which has been the standard model for the IP geolocation industry, causes so many headaches for end users. Even with that, we have a support team, social media, researchers going to conferences, and DevRel responding to user queries because no matter how much technical and research investment we make, there will be gaps, so we should be able to respond to user queries and help out.

— Abdullah | DevRel, IPinfo _______________________________________________ NANOG mailing list https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/HMQMBOTC...

Near-instant updates may be unrealistic as it would require monitoring of feeds for changes - 24 hours is more than suitable. Update your Geofeed data before your subnet goes live. Just to throw in my 2c on the topic - geofeed data should come from the Geofeed attribute on an INETNUM or INET6NUM Whois record. Failing that, fallback to manual data submitted from the network operator. As a last record, use the Country attribute from the Whois records. As I'm typing this, I have seen Abdullah's reply to Gary: Geofeed attributes SHOULD NOT (in the IETF/RFC sense) be the fallback. They should be the first source of GeoIP data, if it is available. This is IMO where the frustration lies with GeoIP data taking unacceptable amounts of time to update, not using it as the first method. Regards, Christopher Hawker ________________________________ From: Mike Lyon via NANOG <nanog@lists.nanog.org> Sent: Wednesday, 28 January 2026 2:08 PM To: nanog@lists.nanog.org <nanog@lists.nanog.org> Cc: devrel.ipinfo@gmail.com <devrel.ipinfo@gmail.com>; nanog@lists.nanog.org <nanog@lists.nanog.org>; Mike Lyon <mike.lyon@gmail.com> Subject: Re: Geofeeds are good — was Re: Publishing BGP communties for your network (Re: What's up with BGP communities?) One pain in the ass part of geolocation is that it takes a company anywhere from 1 - 3 weeks until they push their “update” to their systems. If these are eyeball customers, that isn’t really acceptable. The geo-ip companies need to find a way to do near-instant updates. -Mike

On Jan 27, 2026, at 18:40, Abdullah DevRel of IPinfo via NANOG <nanog@lists.nanog.org> wrote:

Hi,

Please do not lump us with the rest of the industry. We are not the singular representation of the industry. By methods, operations, and philosophy, we try to distance ourselves from the faults of the industry. If your customers are having issues with geolocation, just talk to us. We will investigate.

We are not the representative of the entire industry. We are not a "benevolent monopoly", we are in the maybe top 3 IP geolocation providers in the world, and we are trying our absolute best to have as many interactions to fix our data..

We invested in a massive scale network infrastructure, research program, and huge data investment just because geofeed-based IP geolocation, which has been the standard model for the IP geolocation industry, causes so many headaches for end users. Even with that, we have a support team, social media, researchers going to conferences, and DevRel responding to user queries because no matter how much technical and research investment we make, there will be gaps, so we should be able to respond to user queries and help out.

— Abdullah | DevRel, IPinfo _______________________________________________ NANOG mailing list https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/HMQMBOTC...

NANOG mailing list https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/JPHL2LF2...

Hi Christopher, Thank you very much. We take about 24-48 hours to verify. This involves a series of checks backed by active measurement. To be honest, it is quite instantaneous. But the issue involves update cycles and cache purging. Usually it is around 24 hours. But sometimes like ASN type verification, you have to do much more extensive reviews but those are automated as well. So, to stay safe we say 24-48 hours.

Failing that, fallback to manual data submitted from the network operator. As a last record, use the Country attribute from the Whois records.

If there is noise in the active measurement data, we will definitely fall back to geofeed. That is guaranteed. We are simply comparing the best possible data we have. We ingest a lot of data. And we pick the best. We also use WHOIS country. In fact, for unallocated ranges, we use the RIR country. There is a hierarchy of fallback values that make it a good system.

This is IMO where the frustration lies with GeoIP data taking unacceptable amounts of time to update, not using it as the first method.

We do not discourage geofeed submissions nor the geofeed. It is just that our active measurement data is generally more accurate, verifiable, and granular than what we observe in geofeed, on average. However, we do ingest geofeed and will pick it up when needed. Time to update is not a bottleneck for us; users can submit their geofeed or correction via a simple form on our website. — Abdullah | DevRel, IPinfo

Christopher, I get you, but again, when it comes to VPN providers or those who wish to cause trouble on the Internet, how does a GeoIP provider prevent bogus data from getting accepted? What stops you from putting prefixes into your geofeed, potentially conflicting or overriding my geofeed? Here's an analogy using the wording from your response: If I send you (via my BGP session) my prefixes to announce, you should be accepting it as-is. Not what you think is accurate or correct. Ryan Hamel ________________________________ From: Christopher Hawker via NANOG <nanog@lists.nanog.org> Sent: Tuesday, January 27, 2026 7:46 PM To: nanog@lists.nanog.org <nanog@lists.nanog.org> Cc: Abdullah DevRel of IPinfo <devrel.ipinfo@gmail.com>; Christopher Hawker <chris@thesysadmin.au> Subject: Re: Geofeeds are good — was Re: Publishing BGP communties for your network (Re: What's up with BGP communities?) Caution: This is an external email and may be malicious. Please take care when clicking links or opening attachments.

We do not discourage geofeed submissions nor the geofeed. It is just that our active measurement data is generally more accurate, verifiable, and granular than what we observe in geofeed, on average. However, we do ingest geofeed and will pick it up when needed.

If I tell you (via my Geofeed) my address space is being used in Sydney Australia, you should be presenting it as being used in Sydney Australia. Not what you think is accurate or correct. Regards, Christopher Hawker ________________________________ From: Abdullah DevRel of IPinfo via NANOG <nanog@lists.nanog.org> Sent: Wednesday, 28 January 2026 2:34 PM To: nanog@lists.nanog.org <nanog@lists.nanog.org> Cc: Abdullah DevRel of IPinfo <devrel.ipinfo@gmail.com> Subject: Re: Geofeeds are good — was Re: Publishing BGP communties for your network (Re: What's up with BGP communities?) Hi Christopher, Thank you very much. We take about 24-48 hours to verify. This involves a series of checks backed by active measurement. To be honest, it is quite instantaneous. But the issue involves update cycles and cache purging. Usually it is around 24 hours. But sometimes like ASN type verification, you have to do much more extensive reviews but those are automated as well. So, to stay safe we say 24-48 hours.

Failing that, fallback to manual data submitted from the network operator. As a last record, use the Country attribute from the Whois records.

If there is noise in the active measurement data, we will definitely fall back to geofeed. That is guaranteed. We are simply comparing the best possible data we have. We ingest a lot of data. And we pick the best. We also use WHOIS country. In fact, for unallocated ranges, we use the RIR country. There is a hierarchy of fallback values that make it a good system.

This is IMO where the frustration lies with GeoIP data taking unacceptable amounts of time to update, not using it as the first method.

We do not discourage geofeed submissions nor the geofeed. It is just that our active measurement data is generally more accurate, verifiable, and granular than what we observe in geofeed, on average. However, we do ingest geofeed and will pick it up when needed. Time to update is not a bottleneck for us; users can submit their geofeed or correction via a simple form on our website. — Abdullah | DevRel, IPinfo _______________________________________________ NANOG mailing list https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.nanog.org%2Farchives%2Flist%2Fnanog%40lists.nanog.org%2Fmessage%2FGUDWVNEAABEKVGBNY34U7O4OXHVKICXL%2F&data=05%7C02%7Cryan%40rkhtech.org%7Cfad4f80269294464148308de5e1fda13%7C81c24bb4f9ec4739ba4d25c42594d996%7C0%7C0%7C639051688066469527%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=Yk5jFegS7Icptcm%2BiCJVa8F3BJTt6sR9unUX3%2FMtncM%3D&reserved=0<https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/GUDWVNEAABEKVGBNY34U7O4OXHVKICXL/> _______________________________________________ NANOG mailing list https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.nanog.org%2Farchives%2Flist%2Fnanog%40lists.nanog.org%2Fmessage%2FAUHPGK3SGFCWGJLJGSTFGNARMIEATKM2%2F&data=05%7C02%7Cryan%40rkhtech.org%7Cfad4f80269294464148308de5e1fda13%7C81c24bb4f9ec4739ba4d25c42594d996%7C0%7C0%7C639051688066507122%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=xz2%2BH10VwhlsOpFoG0V%2BoR6aapYMzLo2%2F4uUHJJuQGc%3D&reserved=0<https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/AUHPGK3SGFCWGJLJGSTFGNARMIEATKM2/>

If I tell you (via my Geofeed) my address space is being used in Sydney Australia, you should be presenting it as being used in Sydney Australia. Not what you think is accurate or correct.

We focus on the actual or real locations of IP addresses. A great example we show is through our VPN report. https://ipinfo.io/blog/vpn-location-mismatch-report — Abdullah | DevRel, IPinfo

Sorry, but it's not for someone else to tell me where my space is (or is not) being used. I think I know where my space is being used, better than (what is effectively) a third-party data aggregator. Regards, Christopher Hawker ________________________________ From: Abdullah DevRel of IPinfo via NANOG <nanog@lists.nanog.org> Sent: Wednesday, 28 January 2026 3:28 PM To: nanog@lists.nanog.org <nanog@lists.nanog.org> Cc: Abdullah DevRel of IPinfo <devrel.ipinfo@gmail.com> Subject: Re: Geofeeds are good — was Re: Publishing BGP communties for your network (Re: What's up with BGP communities?)

If I tell you (via my Geofeed) my address space is being used in Sydney Australia, you should be presenting it as being used in Sydney Australia. Not what you think is accurate or correct.

We focus on the actual or real locations of IP addresses. A great example we show is through our VPN report. https://ipinfo.io/blog/vpn-location-mismatch-report — Abdullah | DevRel, IPinfo _______________________________________________ NANOG mailing list https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/3YHUNXXK...

Hi,

I feel like we had this topic (even with Abdullah @ IPinfo) some months ago.

Yes, that is why I am here. To ensure our data is accurately represented and ASNs and ISPs are happy with how we report our geolocation data for their prefixes. After our last interaction at NANOG, I check all conversations in the community daily to ensure no ASN or ISP feels unheard by us. I am always happy to serve the community.

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, i.e. so that if they're getting live TV from an over the Internet provider like Hulu Live, they get the right local channel lineup.

Active measurement on a global scale of the Internet is the best way we can identify the real location of an IP address. An IP address geolocation provider needs to tell where an IP address is located. They are not supposed to be a data parsing service that points to where a geofeed points to. Our goal is simply to point to the real location of an IP address, not a perceived/reported location. We are not against geofeed; we respect geofeed and ingest geofeed. However, geofeed does not inherently have verification or evidence of truth. ASNs are not responsible for providing accurate or even truthful locations of the IP addresses they operate. If they can point the locations of IP addresses in random locations, what is the value of an IP address location service? We try our best to be accurate. And we do not have enough data to backup our location reporting, we will use geofeed data. *Hulu is not our customer (01/28/2026 - 10:44:02 UTC)* I am using them as a metaphor. If Hulu is our customer and your customer is complaining about IP geolocation, it is neither your responsibility nor Hulu's responsibility to fix the issue. It is our data, and we have to back it up. We are responsible for the end-user quality of internet experience. The reason I am here is because of this. I understand and respect you standing behind your customers, but the reality is that many organizations does not have a geofeed or even bother to maintain it properly. But that does not excuse negligence on our part, as enterprises are paying us for our location data service. Any company that uses our data expects us to provide accurate location data. We will talk to your customers to ensure we provide accurate location data for them. It would be incredibly helpful if you support us with a geofeed or hosting a probe server (which is a service we will buy from you), but that is entirely voluntary and optional. We would be grateful for your help, but it is not mandatory for you as an ISP to provide accurate geofeed reporting. But at the end of the day, we are selling a service to Hulu, and Hulu's customers are impacted. The idea is simple: accountability. There is no jumping between support desks when you want to watch the game. You talk to one support team that is providing the geolocation data. The reality is that we are not the largest company in the industry. The legacy provider, for years, has provided a consistently bad user experience that we just cannot shake off because we are part of the industry. We are actively present everywhere, addressing issues head-on, and our customers and end users rarely have complaints about our data or service. Even when they have complaints about us, we try our absolute best to resolve them. Our operations are quite solid. Our presence is solid, and that is why we do not have many complaints, and everyone seems to be generally satisfied. If you have IPinfo-specific complaints, let me know. General industry complaints are something that does not apply to us. — Abdullah | DevRel, IPinfo

I think the point was that you should accept the geofeed data, but only prefixes that AS is allowed to announce. -----Original Message----- From: Ryan Hamel via NANOG <nanog@lists.nanog.org> Sent: Tuesday, January 27, 2026 11:58 PM To: Christopher Hawker <chris@thesysadmin.au>; nanog@lists.nanog.org Cc: Abdullah DevRel of IPinfo <devrel.ipinfo@gmail.com>; Ryan Hamel <ryan@rkhtech.org> Subject: Re: Geofeeds are good — was Re: Publishing BGP communties for your network (Re: What's up with BGP communities?) Christopher, Your "trust but verify" / "accept but confirm", and "not use it as one source of information along with others", completely contradicts what you're saying. What is the point of confirmation/verification if the default action is to "trust" ? Kind regards, Ryan Hamel ________________________________ From: Christopher Hawker <chris@thesysadmin.au> Sent: Tuesday, January 27, 2026 8:48 PM To: Ryan Hamel <ryan@rkhtech.org>; nanog@lists.nanog.org <nanog@lists.nanog.org> Cc: Abdullah DevRel of IPinfo <devrel.ipinfo@gmail.com> Subject: Re: Geofeeds are good — was Re: Publishing BGP communties for your network (Re: What's up with BGP communities?) Caution: This is an external email and may be malicious. Please take care when clicking links or opening attachments. Hi Ryan, It comes down to "trust but verify". If I tell you that my space is being used in and advertised from a location, you should accept this info but confirm the data is correct. Not use it as one source of information along with others.

What stops you from putting prefixes into your geofeed, potentially conflicting or overriding my geofeed?

If I have an inetnum object for 203.0.113.0/24 with a geofeed attribute listing https://example.com/geofeed.csv, and that file lists multiple prefixes such as 198.51.100.0/24 then the GeoIP operator should only be accepting the GeoIP data for the prefix in the inetnum object and discard the rest. Regards, Christopher Hawker ________________________________ From: Ryan Hamel <ryan@rkhtech.org> Sent: Wednesday, 28 January 2026 3:05 PM To: nanog@lists.nanog.org <nanog@lists.nanog.org> Cc: Abdullah DevRel of IPinfo <devrel.ipinfo@gmail.com>; Christopher Hawker <chris@thesysadmin.au> Subject: Re: Geofeeds are good — was Re: Publishing BGP communties for your network (Re: What's up with BGP communities?) Christopher, I get you, but again, when it comes to VPN providers or those who wish to cause trouble on the Internet, how does a GeoIP provider prevent bogus data from getting accepted? What stops you from putting prefixes into your geofeed, potentially conflicting or overriding my geofeed? Here's an analogy using the wording from your response: If I send you (via my BGP session) my prefixes to announce, you should be accepting it as-is. Not what you think is accurate or correct. Ryan Hamel ________________________________ From: Christopher Hawker via NANOG <nanog@lists.nanog.org> Sent: Tuesday, January 27, 2026 7:46 PM To: nanog@lists.nanog.org <nanog@lists.nanog.org> Cc: Abdullah DevRel of IPinfo <devrel.ipinfo@gmail.com>; Christopher Hawker <chris@thesysadmin.au> Subject: Re: Geofeeds are good — was Re: Publishing BGP communties for your network (Re: What's up with BGP communities?) Caution: This is an external email and may be malicious. Please take care when clicking links or opening attachments.

We do not discourage geofeed submissions nor the geofeed. It is just that our active measurement data is generally more accurate, verifiable, and granular than what we observe in geofeed, on average. However, we do ingest geofeed and will pick it up when needed.

If I tell you (via my Geofeed) my address space is being used in Sydney Australia, you should be presenting it as being used in Sydney Australia. Not what you think is accurate or correct. Regards, Christopher Hawker ________________________________ From: Abdullah DevRel of IPinfo via NANOG <nanog@lists.nanog.org> Sent: Wednesday, 28 January 2026 2:34 PM To: nanog@lists.nanog.org <nanog@lists.nanog.org> Cc: Abdullah DevRel of IPinfo <devrel.ipinfo@gmail.com> Subject: Re: Geofeeds are good — was Re: Publishing BGP communties for your network (Re: What's up with BGP communities?) Hi Christopher, Thank you very much. We take about 24-48 hours to verify. This involves a series of checks backed by active measurement. To be honest, it is quite instantaneous. But the issue involves update cycles and cache purging. Usually it is around 24 hours. But sometimes like ASN type verification, you have to do much more extensive reviews but those are automated as well. So, to stay safe we say 24-48 hours.

Failing that, fallback to manual data submitted from the network operator. As a last record, use the Country attribute from the Whois records.

If there is noise in the active measurement data, we will definitely fall back to geofeed. That is guaranteed. We are simply comparing the best possible data we have. We ingest a lot of data. And we pick the best. We also use WHOIS country. In fact, for unallocated ranges, we use the RIR country. There is a hierarchy of fallback values that make it a good system.

This is IMO where the frustration lies with GeoIP data taking unacceptable amounts of time to update, not using it as the first method.

We do not discourage geofeed submissions nor the geofeed. It is just that our active measurement data is generally more accurate, verifiable, and granular than what we observe in geofeed, on average. However, we do ingest geofeed and will pick it up when needed. Time to update is not a bottleneck for us; users can submit their geofeed or correction via a simple form on our website. — Abdullah | DevRel, IPinfo _______________________________________________ NANOG mailing list https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/GUDWVNEAABEKVGBNY34U7O4OXHVKICXL/<https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/GUDWVNEAABEKVGBNY34U7O4OXHVKICXL/> _______________________________________________ NANOG mailing list https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/AUHPGK3SGFCWGJLJGSTFGNARMIEATKM2/<https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/AUHPGK3SGFCWGJLJGSTFGNARMIEATKM2/> _______________________________________________ NANOG mailing list https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/OLVSZFUP...

On 28/01/2026 6:28, Abdullah DevRel of IPinfo via NANOG wrote:

...

If I tell you (via my Geofeed) my address space is being used in Sydney Australia, you should be presenting it as being used in Sydney Australia. Not what you think is accurate or correct. We focus on the actual or real locations of IP addresses. A great example we show is through our VPN report.

https://ipinfo.io/blog/vpn-location-mismatch-report

— Abdullah | DevRel, IPinfo _______________________________________________ NANOG mailing list https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/3YHUNXXK...

I recently took a cruise.  Paid for the 10G package.  How exactly do you list an IP that keeps moving from country to country? Do you have a tag:satellite?  Is there a blog about this corner case? Thanks, Hank

Hi,

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 (I have no idea why the GeoIP people chose that town...), or from Chicago (perhaps because they have test servers in Chicago?).

The whole reason I am here is because of this. Please check your data with us. If it is incorrect, let us know, please. Active measurement by design should be better than geofeed, but if it is not due to network architecture or some reason, you need to tell us. We will investigate.

They should only default to the proprietary system if there is evidence of subterfuge on the part of the provider. Doing otherwise is bound to lead to inaccurate information.

Our active measurement system is our primary source of information that also serves as the verification method. This system is dynamic, processing many dozens of sources of data. If, in any scenario, our active measurement system cannot produce accurate data, we will use geofeed. It is a score-based model for selecting the location hint. Smaller ISPs should never feel like we ignore their reporting. If we are wrong, just flag it; we will work out a solution. We will honor your geofeed reporting. But inherently, the system is designed for evidence-based accuracy. The scenario you have described. You may not be right for your ranges, but please check out your data with us. It is not your responsibility, nor the media companies' responsibility, to ensure that the data is accurate. We operate under the assumption that data accuracy is our responsibility. Moreover, we are public about which companies use our data for which services. So, end users can find us and talk to us directly. The dozens of streaming companies and TV channels that use our data, you will not hear a single complaint from them publicly, because our data is so accurate we are practically invisible to end-users. Just check out my Cloudflare community responses, please: https://community.cloudflare.com/search?q=ipinfo%20order%3Alatest It is mostly about us providing explanations there. And please remember, Cloudflare end-users are not paying customers for us. We do it, because it is our data they are impacted by. Our existence in communities and forums is about accountability. In fact, check out OPNsense or any major open-source software that uses our data. We provide data for free to support the open-source initiatives and public access to data, but that does not excuse us in any way. We are absolutely accountable for our data, and we stand by it. Again, it is not you, as an ISP, to be blamed for bad IP geolocation data. Absolutely not. It is the responsibility of the IP geolocation data provider for bad data. But not all companies use our data. We are one of the top providers of IP geolocation data, but we are not the only provider of it. It is an industry issue that bad IP geolocation exists, and ISPs receive complaints and are not heard by companies and IP geolocation providers. THIS IS NOT THE CASE WITH IPINFO. We are always there to listen and help. — Abdullah | DevRel, IPinfo

On Wed, 28 Jan 2026 09:01:33 -0000 Abdullah DevRel of IPinfo via NANOG <nanog@lists.nanog.org> wrote:

Please check your data with us. If it is incorrect, let us know, [...] If we are wrong, just flag it; [...] but please check out your data with us.

You have asked many times before and multiple times in just this message for help improving your data. Some, probably many, networking companies might have little incentive to do work for free for you so you can succeed in your business. And providing "data" is a worthwhile barter only for a few - presumably, primarily for those that have a real need on a defensive basis? Akin to, I better implement all these anti-spam mechanisms so my mail won't get bounced by Google. Does anyone actually bother to check and fix their data with you if they aren't being harmed by it? If so, I'd be genuinely interested in hearing about those cases.

It is not your responsibility, nor the media companies' responsibility, to ensure that the data is accurate. We operate under the assumption that data accuracy is our responsibility.

You took the words right out of my mouth. :-) John

On 1/28/26 3:01 AM, Abdullah DevRel of IPinfo via NANOG wrote:

The whole reason I am here is because of this. Please check your data with us. If it is incorrect, let us know, please. Active measurement by design should be better than geofeed, but if it is not due to network architecture or some reason, you need to tell us. We will investigate. ... inherently, the system is designed for evidence-based accuracy.

I appreciate you coming here to engage. If you're looking for evidence-based accuracy, I don't think you are going to beat trusting someone's geofeed.  Assuming you are not using cellphone GPS data, which you haven't said you are, it is not EVEN IN THEORY possible for "active measurement" as you have described it to be better than geofeed in the case of non-mobile services provided by ISPs that take geofeeds seriously (and if they don't, why would they publish them?). Active measurement as described by you depends on having servers close enough to "triangulate" location by ping time, but: * Every microsecond of jitter amounts to approximately 100m of uncertainty.  If typical jitter is 1 millisecond (which strikes me as LOW), that's 100km of uncertainty * Traffic doesn't following straight line paths to your servers--it goes from the customer to their ISP's head-end, from there to an exchange point, and that's about as close to you as it will likely get.  There's no reason to believe any of those paths are even remotely straight so even the best case of triangulation will be only triangulating to the ISP's head-end Google suggests that you have approximately 1000 probe points in your probe network, and that gets you to a typical accuracy of 20-100 miles--better than the "Region" field of a geofeed in the middle of some large regions, but worse for small regions (eg, New England) and near region edges (what do you want to bet 1/3 of Indiana, Michigan, and Wisconsin IPs are classified as Chicago?) and worse than the City and (deprecated) Postal Code fields.  A geofeed in an urban area that is accurate to the granularity of "zip code" will be accurate to less than 1 mile, and may be precise up to a few meters at the boundary of the ZCTA.  In suburban and rural areas the geofeeds will be somewhat less precise, but so will your "active measurements" due to the longer backbone runs, lower probe density, etc. I think the message from the experts here is clear: if you want accurate data, you should be trusting the geofeeds, unless you have substantial other evidence that the traffic is not originating where the geofeed says it is, and that it's not a mistake the provider will remedy. Perhaps taking that good advice to heart will allow IPInfo to dramatically improve its accuracy, and take over the IP geolocation market! Peter p.s. You show my IP--probably all of our IPs--in Chicago. That's like 130 miles away. So what am I supposed to do now to correct your error? Perhaps you can see why this is frustrating given that we literally ALREADY TOLD YOU where we are via our geofeed, the standards-compliant method for conveying this information to you!

Once upon a time, Laszlo H <laszlo@heliacal.net> said:

So if we only used it for pre-filling but always asked to confirm, it would be no problem.  The problem is taking somebody else's word over the user's or even the ISP's.

The problem is largely the traditional media companies of various types trying to continue to apply cable-TV-centric geographical limitations to streaming. Whether it's a streaming provider only having rights to show a movie in certain countries or live sports streams being limited to certain cities, it's inherently an adversarial action, where the streaming company cannot trust the attempted viewer. It's a never-ending match-up between streamers/GeoIP companies and viewers and VPN providers, with lots of legitimate would-be viewers blocked out from things they should have access to but GeoIP has wrong data. I remember trying to explain why geographic boundaries and network boundaries were not connected to a marketing person in the 1990s, nothing has really changed, but there's big money in pretending it has. -- Chris Adams <cma@cmadams.net>

As an ISP I don't mind providing a geofeed. We are small so that plays a factor - we're in a few counties of Ohio and not in multiple states nor countries. If the geofeed fixes all of the issues with an IP labeled as VPN, Xbox connection stuff, porn permitting Ohio but not Utah, etc. I'm more than happy to spend a few minutes every new IP block to keep customers happy and operating. On Wed, Jan 28, 2026 at 1:51 PM Abdullah DevRel of IPinfo via NANOG < nanog@lists.nanog.org> wrote:

IP geolocation is a hot button issue that all ISPs are not happy about. This "not happy about"ness stems from IP geolocation providers historically not showing any incentive to support ISPs about their data. ISPs feel like they are unheard and that they could not help their customers who blame the ISPs for not being able to watch the game on the weekend due to a blackout or something.

That is the intention of why I am here. My history in the NANOG community is about ISPs and ASNs saying all IP geolocation providers are the same - invisible and slow to move. I am here to say do not lump us with the rest of the industry, please. We are tangible and visible. If you have an issue with us, talk to us directly.

...

Some, probably many, networking companies might have little incentive to do work for free for you so you can succeed in your business.

Thank you for saying this.

What the system is:

Geofeed is designed for ISPs to systematically inform IP geolocation providers where their prefixes are located for free in the first place. The issue largely relates ASNs just maintaining a public record of sorts.

Now, in terms of our data, our primary source and verification systems revolve around active measurements through ProbeNet. This means that based on RTT, we geolocate an IP address in Richmond, VA, but the geofeed says it is Casper, WY. We will show Richmond, VA. Both the sourcing and verification method relies on active measurements.

But if the ASN operation says there is a network architecture issue, then we will investigate to see if there actually is noise in the active measurement and if trusting your geofeed is a reliable method. Geofeed as a system does not have a verification system.

Now, say you do not maintain a geofeed, and based on the available location hints we have, we point to the location we have evidence for. Your customer could come to you (rarely happens with us) and ask why they cannot see the game because of geofencing or other issues. How do you respond to that question? Talk with the streaming company support? That is just wrong, in my opinion. You need your customer to talk to the IP geolocation provider or at least help the IP geolocation provider in the first place to avoid such conversations. In fact, I do not believe there should be any conversations in the first place. IP geolocation data should be right from the get-go. And that is what we are trying to do.

It is the IP geolocation providers' data, and they are responsible. It is entirely up to you what decisions you make. You are not obligated to tell us anything.

What we do at IPinfo:

I am very happy you brought up the idea of an incentive. We operate 1320 servers around the world using a small VPS through which we take internet measurements. Geofeed does not have a monetary incentive and rather something ISPs should maintain. But because we need a system that is verifiable, we built our own system which involves buying hosting services directly with ASNs/ISPs to allow us to provide good data for the ASN. As far as everyone is concerned, paying for the server is the best mutually financially beneficial situation you can imagine.

- For us, we get the data and we always ensure we have your prefix locations right and your ASN's prefix locations correct. - For you, you get to sell us hosting services and we always get your location right.

And this arrangement of paying for hosting is our best way to provide consistent, high-quality data for you and your customers. We are happy to pay for your service and generosity in hosting us on your platform by purchasing a server from you. Even when we are paying for the server, I feel like ISPs end up doing much more of the heavy lifting in our partnerships, as many ISPs do not have commercial hosting offerings. They have to make special arrangements just for us. To me it is always the ISPs and ASNs helping us more than we could.

Here is our form: https://forms.gle/kNYr2MBL8zRPgNrJ8

There are 70 thousand ASNs out there. Ideally, we need a server hosted in every possible data center. We are willing to pay for this. Our goal is to reach 200 countries and reach 2,000 PoPs this year.

Let me know what you think, please. We are trying our best to find incentive-first systems with ASNs. We have some pilot programs planned out as well. We appreciate the unconditional help ASNs provide, but we want to move towards a mutually beneficial system. Us being accurate about IP geolocation is not a service towards ISPs, it is an absolute requirement.

— Abdullah | DevRel, IPinfo _______________________________________________ NANOG mailing list

https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/CC2PCO4G...

Every piece of advice and message shared with me helps our team. We are responsible for our data, and your help comes from generosity and kindness. You do not owe anything to us. Ideally, we should not have any conversations at all. Our data should be so accurate in the first place that we are invisible to you and your customers. If the location data is correct, there should be no point of friction. We are trying to reach absolute accuracy but there are going to be some systematic errors. So, what do we do? We focused on building our own active measurement-based independent systems that do not require thousands of network operators to be individually responsible by maintaining super accurate geofeeds. If we are producing the data, we should be responsible for the entire supply chain of data from source to delivery. We are trying everything from research to data to create an independent system that makes every internet user happy. We should be a company that is never complained about. But that is not possible. The internet is a massive system and there are going to be systematic gaps. So, we have to be present in every conversation and every forum because there are going to be systematic accuracy errors. It is a data and a human issue. The goal is "Zero Complaints" about IP geolocation period. That means, we focus on research, data and human interactions. We are tangible and accessible. The reason I am sharing about my LinkedIn is that I want ISPs to have a direct line to me. I check the NANOG message board each day. Every day. I may be slow to reply, but I do check it every day. And it is not just NANOG, Reddit, Hacker News, Twitter... you do not have to reach out with a problem. We will proactively provide a solution. There will never be a situation where IPinfo, as a company, comes off as invisible. We welcome being blamed because we want to be accountable for every piece of data we produce. Bad IP geolocation is frustrating. You as an ISP do not have a stake in this situation but you are forced in to the conversation. I completely understand what you are saying. We want to buy hosting services. Allow us to pay for the privilege of providing good data for your customers. You do not owe us anything. Geofeed is great. But the fundamental nature of it is trust-based. So, we are more than happy to pay for this support by purchasing a server with ISPs. We need to reach 200 countries this year. You mentioned an adversarial approach. Let us go for a consented approach by allowing us to host a server in your facility. We are not the biggest player in the industry (unfortunately) and I am extremely frustrated that I talk to community members who cannot relax and watch the game. It is not you as an ISP getting blamed, but because we are so public, some customers blame us thinking that we, being so public, represent the entire industry.

The idea is absolute accountability for the data we provide. What you are doing is generosity by maintaining a good geofeed. We deeply appreciate your generosity. Again, we like geofeed, but we are focused on building an independent system which involves allowing us to host a server in your ASN.

IP geolocation providers exist because parts of the industry made decisions that the location of an IP was needed for their product/service, and even though it should never have happened, the cat is out of the bag and that had to be dealt with. Geolocation providers are simply just collecting information about our networks, and monetizing that data. ASN published geofeeds exist because it was costing too much time and effort for ASNs to constantly correct the myriad of errors that the geolocation DBs had, so we came up with a way for ourselves, the people who KNOW where the IPs are, to publish that to the world. We didn't do it out of generosity, we did it because it made business sense. With all possible respect, there will NEVER be a time that a 3rd party company has more accurate information about the location that IPs are used than the network who has deployed those IPs.

We envision that we are approaching a stage where we are nearly invisible to internet users and ISPs/ASNs, reminiscing about the days when IP geolocation used to be a headache.

IP geolocation will always be a headache, because IP geolocation itself is a terrible technical solution to the problem it attempts to solve. On Wed, Jan 28, 2026 at 3:02 PM Abdullah DevRel of IPinfo via NANOG < nanog@lists.nanog.org> wrote:

The idea is absolute accountability for the data we provide. What you are doing is generosity by maintaining a good geofeed. We deeply appreciate your generosity. Again, we like geofeed, but we are focused on building an independent system which involves allowing us to host a server in your ASN.

We are not the only participant in the industry, so you are borderline forced to maintain a geofeed to help out the industry. But our approach is largely focused on independence and accountability. We own the supply chain from end to end. We want to have a great partnership with everyone who is focused on one thing: to ensure that internet users are not frustrated.

We envision that we are approaching a stage where we are nearly invisible to internet users and ISPs/ASNs, reminiscing about the days when IP geolocation used to be a headache. _______________________________________________ NANOG mailing list

https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/WHG3YFMG...

Using your own measurement is fine but where it gets a push back from some of us, is your statement that geofeed data is treated as tier 2.   I for one publish geofeeds in an automated fashion.  I would like this data to not be considered a red-headed stepchild. On Wednesday, January 28, 2026 at 11:48:19 AM PST, Abdullah DevRel of IPinfo via NANOG <nanog@lists.nanog.org> wrote: Every piece of advice and message shared with me helps our team. We are responsible for our data, and your help comes from generosity and kindness. You do not owe anything to us. Ideally, we should not have any conversations at all. Our data should be so accurate in the first place that we are invisible to you and your customers. If the location data is correct, there should be no point of friction. We are trying to reach absolute accuracy but there are going to be some systematic errors. So, what do we do? We focused on building our own active measurement-based independent systems that do not require thousands of network operators to be individually responsible by maintaining super accurate geofeeds. If we are producing the data, we should be responsible for the entire supply chain of data from source to delivery. We are trying everything from research to data to create an independent system that makes every internet user happy. We should be a company that is never complained about. But that is not possible. The internet is a massive system and there are going to be systematic gaps. So, we have to be present in every conversation and every forum because there are going to be systematic accuracy errors. It is a data and a human issue. The goal is "Zero Complaints" about IP geolocation period. That means, we focus on research, data and human interactions. We are tangible and accessible. The reason I am sharing about my LinkedIn is that I want ISPs to have a direct line to me. I check the NANOG message board each day. Every day. I may be slow to reply, but I do check it every day. And it is not just NANOG, Reddit, Hacker News, Twitter... you do not have to reach out with a problem. We will proactively provide a solution. There will never be a situation where IPinfo, as a company, comes off as invisible. We welcome being blamed because we want to be accountable for every piece of data we produce. Bad IP geolocation is frustrating. You as an ISP do not have a stake in this situation but you are forced in to the conversation. I completely understand what you are saying. We want to buy hosting services. Allow us to pay for the privilege of providing good data for your customers. You do not owe us anything. Geofeed is great. But the fundamental nature of it is trust-based. So, we are more than happy to pay for this support by purchasing a server with ISPs. We need to reach 200 countries this year. You mentioned an adversarial approach. Let us go for a consented approach by allowing us to host a server in your facility. We are not the biggest player in the industry (unfortunately) and I am extremely frustrated that I talk to community members who cannot relax and watch the game. It is not you as an ISP getting blamed, but because we are so public, some customers blame us thinking that we, being so public, represent the entire industry. _______________________________________________ NANOG mailing list https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/LYSER56I...

On Wed, 28 Jan 2026 18:50:47 -0000 Abdullah DevRel of IPinfo via NANOG <nanog@lists.nanog.org> wrote:

We operate 1320 servers around the world using a small VPS [...] we built our own system which involves buying hosting services directly with ASNs/ISPs to allow us to provide good data for the ASN. As far as everyone is concerned, paying for the server is the best mutually financially beneficial situation you can imagine.

I know and use many of the small VPS providers you do. A few $5/month servers isn't a lot of business, and I'd wager those providers are rarely the ones with the most interest in using or buying the geoip data unless maybe they are VPN providers? Isn't it the content and eyeball networks, plus enterprise and security groups that are the primary users of this data? If so, the relationships are asymmetrically triangular if you will. There are (a) geoip data providers, (b) geoip data users/buyers, and (c) networks in the middle that bear much of the cost of what a and c are doing. I'm surely coming off as more adversarial than I really intend. I appreciate what you are trying to do, and especially communicating with netops in good faith. These sorts of triangular relationships exist all over and I'm hopefully being clear and helpful in pointing out the asymmetry and challenge of them. John

Active measurements act as an enhancement and extension of geofeed when it comes to three factors: verification, accuracy, and granularity.

You've already said multiple times that you treat geofeeds as second class, and believe your active measurement is 'better'. In fact, your Google form linked says exactly that again : If active measurements provide contradictory information to geofeed or

reported data, we will prioritize our active measurement data.

You are essentially saying "I run a business that sells data about other people networks , except I will always use MY data that could be wrong , and ignore YOUR data that probably isn't." Allowing us to host a server with you will always guarantee data accuracy. Respectfully, nobody in your industry seems to understand the concept of anycast , so I'm not sure I would use 'guarantee' so liberally. On Wed, Jan 28, 2026 at 6:39 PM Abdullah DevRel of IPinfo via NANOG < nanog@lists.nanog.org> wrote:

Hi Mike,

I am absolutely sorry if my tone or approach about geofeed came across that way. We do ingest and respect geofeed. Active measurements act as an enhancement and extension of geofeed when it comes to three factors: verification, accuracy, and granularity.

If your geofeed is more granular than our data, of course we will ingest it. That is why I am here. You should check your data with us. And if you see that us choosing your geofeed over our active measurement will yield better results, just tell our support, please. We will prioritize it.

You are generously dedicating your time to helping us, and we are not ignoring you. Just help us here by checking your data and contacting support if improvements are possible, please. Active measurement is not a foolproof system; you need to help us get there when it fails.

But, ultimately, if you can just allow us to host a server with you, that will help us even more: https://forms.gle/Ja64QWrJuW8PkUzK6

Allowing us to host a server with you will always guarantee data accuracy. Thank you very much. Again, I apologize for my tone and approach.

— Abdullah | DevRel, IPinfo _______________________________________________ NANOG mailing list

https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/GSEMBAPB...

In our case, the cost of (C) is pissed off eyeball customers that cancel service with us because they can’t get to their destined content service because the IP geolocation company thinks we are lying on our geofeed data and that their system of geolocation data is “better” than our geofeed data. -Mike

On Jan 28, 2026, at 19:20, Abdullah DevRel of IPinfo via NANOG <nanog@lists.nanog.org> wrote:

Hi,

I think I failed to demonstrate the scale of the ProbeNet operations.

For us, having a handful of servers in each data center is enough and will reduce the RTT of the peering ASN and nearby networks. So, we constantly need to expand to other diverse networks. It is pretty easy to buy a few servers in Western Europe, the East coast, and the South coast of the United States. However, when you want to buy a server in the Caribbean, Oceania, or African countries outside of South Africa and Nigeria, I think the procurement effort, maintenance, and service costs are much more complex than you can imagine.

We have some servers that cost $5, maybe a dozen. However, I really don't want to use our financial investment in ProbeNet as a scale to show the complexities of running an operation with 1,300 servers

We currently PoP presence in ~520 ASNs. I think this fact largely demonstrates that no VPN companies, nor any CDN companies, nor any companies outside of crowdsourced research network have reached the level of network diversity that we currently have. It is not 1,300 X $5 .

...

There are (a) geoip data providers, (b) geoip data users/buyers, and (c) networks in the middle that bear much of the cost of what a and c are doing.

I am not sure I understand your logic: - (a) IP geolocation data providers: IPinfo - (b) IP geolocation data users/buyers: IPinfo Customers - (c) Networks in the middle: You

What (c) Networks in the middle are bearing the cost of (a) IPinfo and (c) you are doing. I am not sure I understand the logic. What cost are we talking about?

— Abdullah | DevRel, IPinfo _______________________________________________ NANOG mailing list https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/73CUGUBC...

Folks, I am going to sign off from this thread. Again, do reach out to me if you have any critical feedback, please. Links! Please help us by hosting a probe server: https://forms.gle/Ja64QWrJuW8PkUzK6 (this will guarantee constant accuracy for your prefixes and helps us a lot as well) If you want to reach out to me, I am available on LinkedIn: https://www.linkedin.com/in/reincoder/ I get a lot of emails so I would like everyone to add me on LinkedIn. This way I can stay in touch on a personal level. I am the Developer Relations guy at IPinfo, which technically means that I am sort of like the account manager for everyone who is impacted by our data. If you need technical support or corrections, reach out to this links: - https://ipinfo.io/corrections (Self serve portal) - https://ipinfo.io/support We have a fantastic community: https://community.ipinfo.io/ Please, if you need help with our data or have questions, drop them there. At the end of the day, I assume that everyone already uses our data. So, the community is the best place to ask questions and have long form discussions. Also, just keep in touch we host hackathons and give out merchs. I have a year-round sticker budget. In hackathons, we give out t-shirts and hoodies, though. We are trying our best to bring our data to firewall services for free. So, if you know someone at a firewall software company, please recommend them IPinfo Lite: https://ipinfo.io/lite. Not only will end users get the best data, but we will also support them with our data issues and questions. We are expanding our ProbeNet. If you know someone in a place where we do not have a marker (ipinfo.io/probenet), please let me know. If you operate an IXP and want to explore our raw measurements for peering and routing policies, please reach out. We are launching a pilot partnership program to help global and regional peering and routing efforts. Our research team will be present at NANOG 96. If you want to say hi, please do. Have a great night! Thank you very much. — Abdullah | DevRel, IPinfo

Once upon a time, Tom Beecher <beecher@beecher.cc> said:

Every time an ASN has to deal with a support issue caused by incorrect data , it costs them time and money.

You left out: step 3: GEO-PROVIDER profit! Since there's very little way for end users or ISPs to get feedback into the companies paying GEO-PROVIDERs, there's little impact to a GEO-PROVIDER's bottom line for selling bad data. -- Chris Adams <cma@cmadams.net>

Hi Jeroen, On 26/01/2026 17:35, Jeroen Massar wrote:

[..] But in the end, for most purposes it is to turn the numbers into a label so that one can see what the community means. And unless it is an action policy, no computer will be acting upon those communities as one has to understand the full intent (and no, an LLM will not get that yet, and please do not let a LLM close to BGP :) )

Thus they should be good for humans setting an action community or viewing what the community means.

Any other purposes and thus reason why to make it more complex than that?

Apart from parsing by looking glasses there has been interest to use this in router cli's to do things like tab-complete available policy options for peer ASNs. Having a structured and validatable model is required for this. The communities YANG model augments the larger ietf-bgp YANG model[0], so any application making use of this would benefit as well. I understand that for simple networks with a couple of static communities the YANG/JSON approach seems overengineered. Perhaps having a conversion tool available would make it less daunting for the more basic use cases? I'd love to hear suggestions (direct or on the IETF GROW list) on how to make this more useful. Kind regards, Martin [0] https://datatracker.ietf.org/doc/draft-ietf-idr-bgp-model/

It'll be a small percentage of IPs, netblocks or ASNs, but it'll be the most important ones. Nobody cares if Verizon users are correctly placed 99% of the time, if any of those users can sign up to NordVPN and use it for the 1% of the time they want to get around any geoblocks. Correct location is all-or-nothing. If you don't get the adversarial cases right, you may as well get none of it right. Right now, it's the residential proxy industry, but it's very expensive. How will you detect a Verizon user is proxying traffic at the TCP layer for someone in Saudi Arabia? That's very difficult, as they won't proxy your ping packets. You'd need to be an MITM to measure layer-7 latency. If residential proxy prices were to fall, the entire GeoIP industry would be exposed as snake oil. Though I think it's more likely that media companies would team up with ISPs to hunt down proxies with a vengeance. This is already what happens in places like Spain where the same company owns the football games that are getting pirated and the biggest ISPs, and they block half the internet during live football, just in case. On 29/01/2026 03:32, Jon Lewis via NANOG wrote:

On Wed, 28 Jan 2026, Mike via NANOG wrote:

...

Using your own measurement is fine but where it gets a push back from some of us, is your statement that geofeed data is treated as tier 2. I for one publish geofeeds in an automated fashion.  I would like this data to not be considered a red-headed stepchild.

"Some people might lie in their geofeeds" seems to have poisoned their view of geofeed reliability.  I really suspect the "geofeed fraud" is a small minority.  Other than low end VPN providers hoping to fool streaming content providers, I don't know why anyone would lie in their geofeed.

Ours is automated too.  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.  As long as we don't screw up in IPAM (which happens), the geofeed is automatic and correct.  I did end up having to write a geofeed auditor that catches when someone screws up and emails us so the improperly formatted (and improperly parsed) locations get fixed almost immediately.

The headaches of IP Geo providers "getting it wrong" impacting our customers is good motivation for making sure we publish accurate data.

----------------------------------------------------------------------  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/WPNYIT75...

Hi, Neither the end user nor the ISP has any way to know that IPinfo is at fault. Neither party knows that IPinfo even exists. Your contractual relationship is only with the media distributor, and so is the end user's, and the ISP only had a contractual relationship with the end user. (*sometimes* also with the media distributor but not for this purpose) There's a concept known as diffusion of accountability, and it applies here. You are saying end users must inform you, but they don't know you exist. You are saying ISPs must inform you, but they mostly don't know you exist. And when an ISP does inform you, you push back on them anyway, saying you trust the probe network more than the ISP. The apparent purpose of all this, is to ensure that problems do not need to be fixed, responded to, or even acknowledged. There's another saying: the purpose of a system is what it does. If you think media distributors must inform the end user to contact you first in the event of an IP geolocation problem, you must write that into your contracts with them. Did you? If not then it seems you don't actually intend that. Does it even matter when the end user doesn't know what IP geolocation is? You say you are trying to distance yourselves from the rest of the industry, but you are only saying this with your words, not showing it with your actions. On 12 February 2026 04:37:47 CET, Abdullah DevRel of IPinfo via NANOG <nanog@lists.nanog.org> wrote:

Hi Kevin,

...

I can confirm that streaming companies don't like it any more than users or ISPs. It's all on the contractual requirements forced by the media content providers, and they even specify which geoIP companies the distribution company may use.

Yep, it is part of DRM. However, we are as frustrated as end-users are here. Our data is the best product in the IP geolocation industry (ref: https://dl.acm.org/doi/10.1145/3676869) and we do get a lot of flak for being so public. But the reality is that many major streaming companies actually do not use our data. The ones that do use our data, you never actually hear any complaints from them, to be honest.

The process: - We should not be wrong in the first place. - If we are wrong, let us help you before you go to your streaming server support.

Like you rarely see us have those conversations in public forums (we check Reddit, Twitter, Facebook several times a day, along with our customer forums)

...

Given the generally self-destructive state of that industry, it wouldn't surprise me, if geoIP companies ceased existing, media content providers would ban streaming altogether, lose all their viewers and go bankrupt themselves.

Our primary user base is cybersecurity and network architecture applications (CDNs). Even streaming companies use our data, adopting us based on our presence in the cybersecurity industry first, and then adopting us into DRM data services.

...

It'll be a small percentage of IPs, netblocks or ASNs, but it'll be the most important ones.

To us all IP addresses are equal.

...

Nobody cares if Verizon users are correctly placed 99% of the time, if any of those users can sign up to NordVPN and use it for the 1% of the time they want to get around any geoblocks. Correct location is all-or-nothing. If you don't get the adversarial cases right, you may as well get none of it right.

We offer VPN detection services. It is up to the streaming companies if they want to use it or not. We operate 1,300+ servers worldwide. The network is diverse, we can pinpoint each specific data center endpoint for VPN exit nodes. Our privacy detection service is our second most important product.

...

Right now, it's the residential proxy industry, but it's very expensive. How will you detect a Verizon user is proxying traffic at the TCP layer for someone in Saudi Arabia? That's very difficult, as they won't proxy your ping packets. You'd need to be an MITM to measure layer-7 latency.

We offer residential proxy detection service as well. We connect through these services and/or use enhanced detection methods to verify active exit nodes. The dataset includes provider name, last seen date, and percentage of days seen. We attend a lot of research and industry conferences, so our technical team would be quite happy to talk to you in person about our exact methods.

We can observe the "exit node" for the residential proxy. But please look into the residential proxy business monetization plans. Residential proxies charge by GB transfers. It is prohibitively expensive to be applied in average users streaming shows.

...

If residential proxy prices were to fall, the entire GeoIP industry would be exposed as snake oil. Though I think it's more likely that media companies would team up with ISPs to hunt down proxies with a vengeance. This is already what happens in places like Spain where the same company owns the football games that are getting pirated and the biggest ISPs, and they block half the internet during live football, just in case.

Resproxy data transmission costs $0.5-$8 / GB (https://proxyway.com/best/residential-proxies). Resproxy services do not allow unlimited data transmission, unlike VPN services.

Our goal is to work with the greater community and stakeholders. If a nation is frustrated by government actions, we maintain an open-door policy for networks and governments to talk to us. It is not commercial discussions, but we are happy to advise and share our insights based on what we have learned observing the internet from a data point of view.

Please understand, the points I am making are about IPinfo, not the IP geolocation industry at large. If IP geolocation went away, we hope people/companies will move to us and whatever industry we represent. The IP geolocation industry has left such a bad taste for ISPs, end users, and services, we are trying to distance ourselves from the stereotypes of the industry.

— Abdullah | DevRel, IPinfo _______________________________________________ NANOG mailing list https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/WASMD3Z2...

You keep talking about probe servers and how accurate the data is, but the whole approach is arbitrary and adversarial toward ISPs. You're undermining what people publish, trying to convince the world that they're all liars except you, and building an illusion that it's possible to determine the location of an IP with technical solutions so you can sell it. The same way that hostile actors want to locate users (not IPs) in order to block them, users want a virtual presence in another country to evade those blocks, and one of your goals is to prevent that from working and to make money while doing it.  It's walls and ladders and you're selling walls.  This causes endless problems for everybody involved and whatever profits are earned from this don't go back to the affected users and operators - it just increases the cost for everybody. Operators have to dance around this geo location business any time we deal with IP addresses and it only helps the people selling the databases. -Laszlo On 2/15/26 7:02 AM, Abdullah DevRel of IPinfo via NANOG wrote:

Hi,

...

Neither the end user nor the ISP has any way to know that IPinfo is at fault. Neither party knows that IPinfo even exists. You are right. IP geolocation should be invisible. Our approach fundamentally relies on the fact data is so good, we do not even exist. But the issue is that even with a million probe servers, IP geolocation can never be fully accurate in real time. How do we address the issue?

...

Your contractual relationship is only with the media distributor, and so is the end user's, and the ISP only had a contractual relationship with the end user. For our enterprise customers, we have established multi-channel escalation processes. I can describe what this looks like using Cloudflare as an example, since they are the largest internet company in the world:

- Cloudflare's support and product teams have direct communication channels with our engineering and support teams. - Issues are escalated to us through automated processes. - Their community moderators and MVP users are aware of us and can flag issues directly.

In the Cloudflare community, we see roughly one issue per month that involves our data, and most of those require explanation rather than correction.

Example: https://community.cloudflare.com/search?q=ipinfo%20order%3Alatest

Please understand that is Cloudflare and all their scale.

OPNsense adopted our data as well. We made it clear to them that IP geolocation accuracy is our responsibility, not theirs. The issues I have seen in their forums have been cases requiring investigation and explanation, not systematic data failures: https://forum.opnsense.org/index.php?action=ipinfo

Our accountability extends beyond paying customers to include users accessing our free data - IPinfo Lite (Country + ASN). We are actively reaching out to firewall companies to encourage them to adopt our free data, because end-users often experience frustration due to inaccurate IP geolocation data services. So, we are willing to provide our data for free in order to support their end-users.

...

You are saying end users must inform you, but they don't know you exist. You are saying ISPs must inform you, but they mostly don't know you exist. I am not saying either must inform us.

For end users: our enterprise customers are instructed to maintain an escalation process. When an end user reports a location issue, the customer identifies whether it is an IP geolocation problem and forwards it to us through an automated channel. We investigate and resolve or explain within 24 hours. The end user does not need to know we exist for this to work.

For ISPs: this is the reason we invested in active measurement rather than relying exclusively on geofeeds. Many ISPs do not publish geofeeds, do not maintain them, and do not know which IP geolocation providers are serving data about their prefixes. We chose to build a system that does not depend on ISP participation to produce accurate data. When ISPs do engage with us, it helps. But their participation is voluntary, not required.

Again, we appreciate all the ISPs for their due diligence and effort to keep their geofeed.

...

And when an ISP does inform you, you push back on them, saying you trust the probe network more than the ISP. When our active measurement data conflicts with a geofeed or an ISP correction, we investigate. If the ISP's information is more accurate, we fall back to their geofeed and increase its priority score in our system to avoid the same issue recurring. This is not pushback — it is a verification step.

...

If you think media distributors must inform the end user to contact you first in the event of an IP geolocation problem, you must write that into your contracts with them. We do not require end users to contact us. The escalation path is: end user contacts the service provider, the service provider's support identifies an IP geolocation issue, and it is forwarded to us. This is part of our operational process with enterprise customers.

Again, you are absolutely not required to talk to us. Nobody is required to talk to us. And the only path towards that on a systematic and macro level is active measurement.

Our data is getting more granular and accurate. It is a continuous investment. We are only limited by how universal adoption of our data has been.

ISPs, end users, network operators who are not our direct customers — we monitor public forums daily. This includes NANOG, Reddit (https://old.reddit.com/user/reincdr/), Hacker News, and customer community platforms for services that use our data. When someone has a complaint about IP geolocation, even if it is not specifically about us, we investigate. That is how we entered this thread. The original discussion was about BGP communities, not about us.

...

You say you are trying to distance yourselves from the rest of the industry, but you are only saying this with your words, not showing it with your actions. I understand that perspective. Here is what we are doing:

- We maintain public presence in operator forums and respond to complaints, including complaints that are not directed at us. - We have a self-serve correction portal: https://ipinfo.io/corrections - We have a support channel: https://ipinfo.io/support - We are expanding ProbeNet to improve measurement accuracy so that fewer issues arise in the first place. - When our data is wrong and an ISP or end user flags it, we fall back to geofeed data and adjust the priority scoring to prevent recurrence.

I acknowledge that forum monitoring is not the same as systematic routing of complaints. We are working on improving discoverability. If you have specific suggestions on how we can make it easier for affected parties to reach us, we are genuinely interested.

— Abdullah | DevRel, IPinfo _______________________________________________ NANOG mailing list https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/FFG63JXF...

But the issue is that even with a million probe servers, IP geolocation can never be fully accurate in real time. How do we address the issue?

The large web companies/hyperscalers have been doing this for years. There are functions in applications that send telemetry back from anyone who hits their websites or opens their applications. We can collect billions of data points directly from our users, orders of magnitude more than you as a 3rd party could ever collect from just ping tests, and I can tell you that none of us can reach 100% accuracy. Nobody ever will. We chose to build a system that does not depend on ISP participation to

produce accurate data.

You keep saying that your method 'produces accurate data' . But you provide no evidence to support this claim. Again, your company's business model is to sell access to a database of information. All of the geolocation providers have their own method of producing that data. However you (and all other geolocation providers) shift the burden of CORRECTING that data to external parties , which costs THEM time and money to do, just so you can flex about 'accuracy' and sell more. On Sun, Feb 15, 2026 at 2:03 AM Abdullah DevRel of IPinfo via NANOG < nanog@lists.nanog.org> wrote:

Hi,

...

Neither the end user nor the ISP has any way to know that IPinfo is at fault. Neither party knows that IPinfo even exists.

You are right. IP geolocation should be invisible. Our approach fundamentally relies on the fact data is so good, we do not even exist. But the issue is that even with a million probe servers, IP geolocation can never be fully accurate in real time. How do we address the issue?

...

Your contractual relationship is only with the media distributor, and so is the end user's, and the ISP only had a contractual relationship with the end user.

For our enterprise customers, we have established multi-channel escalation processes. I can describe what this looks like using Cloudflare as an example, since they are the largest internet company in the world:

- Cloudflare's support and product teams have direct communication channels with our engineering and support teams. - Issues are escalated to us through automated processes. - Their community moderators and MVP users are aware of us and can flag issues directly.

In the Cloudflare community, we see roughly one issue per month that involves our data, and most of those require explanation rather than correction.

Example: https://community.cloudflare.com/search?q=ipinfo%20order%3Alatest

Please understand that is Cloudflare and all their scale.

OPNsense adopted our data as well. We made it clear to them that IP geolocation accuracy is our responsibility, not theirs. The issues I have seen in their forums have been cases requiring investigation and explanation, not systematic data failures: https://forum.opnsense.org/index.php?action=ipinfo

Our accountability extends beyond paying customers to include users accessing our free data - IPinfo Lite (Country + ASN). We are actively reaching out to firewall companies to encourage them to adopt our free data, because end-users often experience frustration due to inaccurate IP geolocation data services. So, we are willing to provide our data for free in order to support their end-users.

...

You are saying end users must inform you, but they don't know you exist. You are saying ISPs must inform you, but they mostly don't know you exist.

I am not saying either must inform us.

For end users: our enterprise customers are instructed to maintain an escalation process. When an end user reports a location issue, the customer identifies whether it is an IP geolocation problem and forwards it to us through an automated channel. We investigate and resolve or explain within 24 hours. The end user does not need to know we exist for this to work.

For ISPs: this is the reason we invested in active measurement rather than relying exclusively on geofeeds. Many ISPs do not publish geofeeds, do not maintain them, and do not know which IP geolocation providers are serving data about their prefixes. We chose to build a system that does not depend on ISP participation to produce accurate data. When ISPs do engage with us, it helps. But their participation is voluntary, not required.

Again, we appreciate all the ISPs for their due diligence and effort to keep their geofeed.

...

And when an ISP does inform you, you push back on them, saying you trust the probe network more than the ISP.

When our active measurement data conflicts with a geofeed or an ISP correction, we investigate. If the ISP's information is more accurate, we fall back to their geofeed and increase its priority score in our system to avoid the same issue recurring. This is not pushback — it is a verification step.

...

If you think media distributors must inform the end user to contact you first in the event of an IP geolocation problem, you must write that into your contracts with them.

We do not require end users to contact us. The escalation path is: end user contacts the service provider, the service provider's support identifies an IP geolocation issue, and it is forwarded to us. This is part of our operational process with enterprise customers.

Again, you are absolutely not required to talk to us. Nobody is required to talk to us. And the only path towards that on a systematic and macro level is active measurement.

Our data is getting more granular and accurate. It is a continuous investment. We are only limited by how universal adoption of our data has been.

ISPs, end users, network operators who are not our direct customers — we monitor public forums daily. This includes NANOG, Reddit ( https://old.reddit.com/user/reincdr/), Hacker News, and customer community platforms for services that use our data. When someone has a complaint about IP geolocation, even if it is not specifically about us, we investigate. That is how we entered this thread. The original discussion was about BGP communities, not about us.

...

You say you are trying to distance yourselves from the rest of the industry, but you are only saying this with your words, not showing it with your actions.

I understand that perspective. Here is what we are doing:

- We maintain public presence in operator forums and respond to complaints, including complaints that are not directed at us. - We have a self-serve correction portal: https://ipinfo.io/corrections - We have a support channel: https://ipinfo.io/support - We are expanding ProbeNet to improve measurement accuracy so that fewer issues arise in the first place. - When our data is wrong and an ISP or end user flags it, we fall back to geofeed data and adjust the priority scoring to prevent recurrence.

I acknowledge that forum monitoring is not the same as systematic routing of complaints. We are working on improving discoverability. If you have specific suggestions on how we can make it easier for affected parties to reach us, we are genuinely interested.

— Abdullah | DevRel, IPinfo _______________________________________________ NANOG mailing list

https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/FFG63JXF...

The what-is-my-ip-address gives a 404 https://ipinfo.io/what-is-my-ip is correct, which was a redirect from the /my that you later mentioned. David -- https://dprall.net On 2/15/2026 12:10 PM, Abdullah DevRel of IPinfo via NANOG wrote:

Hi Tony,

Thank you for raising this. You are right that the /lite page (ipinfo.io/lite) is a product page focused on the dataset and API access. It does not have a lookup interface on it, and I can see how that would give the impression we do not offer one.

We do have a free, public web lookup that does not require an account:

- Any IP address can be looked up directly via URL: https://ipinfo.io/8.8.8.8 (replace with any IP) - Our homepage (ipinfo.io) has a search bar in the navigation bar - We have a "What is my IP address" page: https://ipinfo.io/what-is-my-ip-address

All these are already mentioned across all our website pages. No API key, no account, no sign-up required for any of these.

Additionally, our IPinfo Lite data (Country + ASN) is published under CC-BY-SA 4.0, so several open-source projects and platforms already use and redistribute it freely.

That said, your feedback is helpful. If visitors land on the /lite page expecting a lookup tool and do not find one, that is something we should address on our end. When end-users come to us with issues, we ask them to visit ipinfo.io/my page, not a product page.

— Abdullah | DevRel, IPinfo _______________________________________________ NANOG mailing list https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/KGH34ER7...

Once upon a time, Abdullah DevRel of IPinfo <devrel.ipinfo@gmail.com> said:

- Any IP address can be looked up directly via URL: https://ipinfo.io/8.8.8.8 (replace with any IP)

Tried that, you have my residential service in another state. Not particularly accurate. -- Chris Adams <cma@cmadams.net>

On 15/02/2026 20:07, Tony Patti via NANOG wrote:

I compared IPinfo’s answers to MaxMind’s https://www.maxmind.com/en/geoip-demo answers, for a random recent visitor from 44.198.66.156 to my website https://cryptosystemsjournal.com/ and one notable difference is that you specify a larger CIDR block of 44.192.0.0/11 (2,097,152 addresses) whereas MaxMind specifies a much smaller CIDR block 44.198.64.0/19 (8,192 addresses).

Tony Patti

Unfortunately, there is not a quality academic paper that has come out yearly comparing the various geo-location DBs and their accuracy (IPv4 & IPv6) down to the 100m-1km level.  So in the interim, we will continue to see geo-location DB wars - just like we have had OS wars and IP vs OSI wars. Regards, Hank

Hi Chris, Thank you for flagging this. You can submit a correction if you want: https://ipinfo.io/corrections — Abdullah | DevRel, IPinfo

Interesting results I'm getting here on a variety of ranges..... I'm testing 5 different nets, one residential ISP /24, two of my own /24's and two /48's (from the same /36). Of those, the first each of the /24 and /48 have geofeed data, the second two do not (I will be fixing that) Of these, I'd give DB-IP the highest marks, and the most reliable data. But that's still, to me, a wild amount of discrepancies for the two prefixes I had current geofeed data up (for almost a year now!) between some providers Maxmind, gave.... Residential /24 -> Correct local town 2nd Owned /24 -> US, NA 1st Owned /24 -> US, NA 1st Owned /48, -> US, NA 2nd Owned /48, -> US, NA Using iplocation.net to query: (I did double check these with ipinfo's own tool to make sure their results presented were accurate responses for them) Residential /24: IP2Location: Wrong state, ARIN org fallback data. Ipinfo.io: Same wrong state, correct state for ARIN org fallback data, but wrong town for ARIN data (?) DB-IP: Correct IPregistry.co: Same as IPinfo IPGeolocation.io: Same state as ARIN org fallback data., but unrelated town IPapi.co: Correct state, nearby town - close enough Criminalip.io: Correct 1st owned /24: IP2Location: Correct Ipinfo.io: Incorrect, by about 2500-3000 miles DB-IP: ARIN fallback data, it seems IPregistry.co: Correct IPGeolocation.io: Correct IPapi.co: ARIN org fallback data. Criminalip.io: N/A 2nd owned /24: All identical, ARIN org fallback data. Criminalip.io: N/A 1st owned /48: All correct. 2nd owned /48: All ARIN org fallback data except: IPapi.co: Incorrect, by about 2500-3000 miles -----Original Message----- From: Abdullah DevRel of IPinfo via NANOG <nanog@lists.nanog.org> Sent: Monday, February 16, 2026 12:29 AM To: nanog@lists.nanog.org Cc: Abdullah DevRel of IPinfo <devrel.ipinfo@gmail.com> Subject: RE: Geofeeds are adversarial — was Re: Geofeeds are good Hi Tony,

I compared IPinfo's answers to MaxMind's answers, for a random recent visitor from 44.198.66.156 to my website and one notable difference is that you specify a larger CIDR block of 44.192.0.0/11 (2,097,152 addresses) whereas MaxMind specifies a much smaller CIDR block 44.198.64.0/19 (8,192 addresses).

That is an AWS IP address, and it brings up an interesting point. The /11 we display reflects the actual BGP announcement for that IP. You can verify this yourself on bgp.tools: https://bgp.tools/prefix-selector?ip=44.198.66.156 bgp.tools shows two overlapping prefixes for that IP: - AS14618: 44.192.0.0/11 (High visibility) - AS16509: 44.192.0.0/10 (High visibility) There is no /19 announcement visible in the BGP routing table for that IP. The /19 that the other provider displays appears to be derived from a source other than BGP, possibly their own internal prefix segmentation or geofeed data. We show the BGP-announced prefix because that reflects how the IP address is actually routed on the internet. The geolocation data (city, country) is determined separately from the CIDR displayed on the page, so the larger prefix does not mean less granular geolocation. — Abdullah | DevRel, IPinfo _______________________________________________ NANOG mailing list https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/4RKVQ44Q...

Large-scale ground truth evaluations require access to data that is typically only available to enterprises internally. Our NANOG 96 presentation (https://nanog.org/events/nanog-96/content/5678/) and our peer-reviewed research (https://dl.acm.org/doi/10.1145/3676869) present what we can share publicly about our methodology and accuracy. We would welcome an independent academic benchmark if one were to emerge.

The information presented in the paper and preso is nothing about the accuracy of IPInfo's data. What you present is a comparison between the results from your probe network, and published geofeeds. If your test and the geofeed AGREE on the location, you classify that geofeed as 'correct' , if they do not agree, you classify it as 'incorrect'. This is nonsensical. Your multilateration method of taking the straight line distance and speed of light in fiber to create distance polygons is flawed. This works in radio when waves do propagate in straight lines, but terrestrial fiber networks don't work this way. The physical network infra between two points is never a great circle route. There are locations all over the world where two endpoints are in the same city, but would show RTTs in the hundreds of ms simply because the two networks involved don't connect on the same continent. Any statements about the 'accuracy of geofeeds' therefore mean nothing. For example, you claim that 92% of geofeeds are accurate to the country level. But what that really means is 92% of your tests agree with geofeeds. It tells us nothing about if your test was accurate or not. It is also important to point out that even if we assert that your test are correct , you point out that geofeeds only cover 1.5% of IPv4, and 0.7% of IPv6 addresses are covered by geofeeds. This means that for basically 99% of all addresses possible, your only reference is your ping/multilateration method, which as stated previously will have issues accurately placing an address, meaning for almost the entire internet, your statement of accuracy is 'just trust me bro'. On Mon, Feb 16, 2026 at 12:48 AM Abdullah DevRel of IPinfo via NANOG < nanog@lists.nanog.org> wrote:

Hi Hank,

Large-scale ground truth evaluations require access to data that is typically only available to enterprises internally. Our NANOG 96 presentation (https://nanog.org/events/nanog-96/content/5678/) and our peer-reviewed research (https://dl.acm.org/doi/10.1145/3676869) present what we can share publicly about our methodology and accuracy. We would welcome an independent academic benchmark if one were to emerge.

— Abdullah | DevRel, IPinfo _______________________________________________ NANOG mailing list

https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/EE5AB4UE...

Hi Tom, Thank you for the detailed methodological feedback. These are questions our research team is best equipped to address. Calvin Ardi presented the work at NANOG 96 and I believe you spoke with him there. If you are willing, please reach out to research@ipinfo.io so he can follow up on the specific points you raised. — Abdullah | DevRel, IPinfo

I'm sorry but there are lots of use cases that require accurate IP geolocation. DNS routing of users to the closest server in cases anycast is not doable or too expensive. Fighting abuse, a user claiming is from the USA, with a UK credit card and an IP resolved to China should at bare minimum be reviewed by a human. And of course there's plenty of legislation requiring the proper identification of user location to either require a local VAT number, show cookie banners, block adult content access and more. And hundreds more... I've looked into using geofeeds directly internally for some projects but most networks are not covered, or don't provide them to randoms like me or some outright lie to sell SEO IPs or charge more for rare hosting locations without having to actually have infrastructure there. So I don't really get the outrage here. On Mon, Feb 16, 2026, 14:16 Rich Kulawiec via NANOG <nanog@lists.nanog.org> wrote:

On Sun, Feb 15, 2026 at 10:25:56PM -0800, Owen DeLong via NANOG wrote:

...

Personally, I???ve always thought that IP Geolocation was a bad idea and nothing I???ve seen in the usage of it to date has changed my mind.

Agree. We've spent decades trying to build a network that allows everyone to access everything independent of geographical location, and now people have come along with broken business models which demand that we abandon this fundamental principle of the Internet in order to accomodate them.

---rsk _______________________________________________ NANOG mailing list

https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/TDHIXTY5...

It would be nice if bad laws were impossible to comply with. Then nobody would comply with them. Then someone comes along and finds there's a way to sell the appearance of complying with the law (even though actual compliance is impossible) as a service, and everybody is forced to buy the service so they don't get prosecuted. Just one more instance of bad politics and capitalism messing everything up for everybody. On 16 February 2026 15:08:46 CET, Michael Greenup via NANOG <nanog@lists.nanog.org> wrote:

It is important to consider the extent to which US state government mandates influence the regulation of content access. For instance, numerous states now require identity verification for viewers of adult content to confirm their age. Many of these laws are formulated such that any viewer within the state's jurisdiction must be verified, necessitating IP address-based geolocation to ensure compliance.

Not saying I agree or disagree here, just laying out a regulated use case.

YMMV.

Regards,

Michael

The views and opinions included in this email belong to the author and are not representative of the views and opinions of the company which employs me. If you find a spelling or grammatical error, you may keep it.

Rich Kulawiec wrote:

...

...

Personally, I???ve always thought that IP Geolocation was a bad idea and nothing I???ve seen in the usage of it to date has changed my mind. Agree. We've spent decades trying to build a network that allows everyone to access everything independent of geographical location, and now people have come along with broken business models which demand that we abandon

On Sun, Feb 15, 2026 at 10:25:56PM -0800, Owen DeLong via NANOG wrote: this fundamental principle of the Internet in order to accomodate them.

---rsk

---

NANOG mailing list https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/VT47D47C...

The business models predate widespread consumer use of the internet, though, right? Region-based live sports blackouts go all the way back to broadcast TV. So the business models may have been expanded and adapted to internet video streaming, but they didn't "come along" afterward. On Mon 2026-02-16 06:15 AM MST -0700, <nanog@lists.nanog.org> wrote:

decades trying to build a network that allows everyone to access everything independent of geographical location, and now people have come along with broken business models

That regulation doesn’t require you to know where the user is unless you are trying to avoid age verification for users not subject to their jurisdiction. It’s also questionable, if you are outside their jurisdiction whether they can subject you to such extra-territorial overreach, but in the tRump/Putin/Shi world order, sovereignty and jurisdiction seem to be less relevant and rule of law may no longer matter as much in restricting government power, so all bets are off. Owen

On Feb 16, 2026, at 06:09, Michael Greenup via NANOG <nanog@lists.nanog.org> wrote:

It is important to consider the extent to which US state government mandates influence the regulation of content access. For instance, numerous states now require identity verification for viewers of adult content to confirm their age. Many of these laws are formulated such that any viewer within the state's jurisdiction must be verified, necessitating IP address-based geolocation to ensure compliance.

Not saying I agree or disagree here, just laying out a regulated use case.

YMMV.

Regards,

Michael

The views and opinions included in this email belong to the author and are not representative of the views and opinions of the company which employs me. If you find a spelling or grammatical error, you may keep it.

Rich Kulawiec wrote:

...

...

On Sun, Feb 15, 2026 at 10:25:56PM -0800, Owen DeLong via NANOG wrote: Personally, I???ve always thought that IP Geolocation was a bad idea and nothing I???ve seen in the usage of it to date has changed my mind. Agree. We've spent decades trying to build a network that allows everyone to access everything independent of geographical location, and now people have come along with broken business models which demand that we abandon this fundamental principle of the Internet in order to accomodate them.

---rsk

---

NANOG mailing list https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/VT47D47C...

One observation from watching similar debates over the years – the period in which the Internet technical community could simply respond “that isn’t technically possible” or “that won’t work as intended” and expect the proposed law or regulation to stall seems largely behind us. In many jurisdictions, if policymakers perceive a requirement as necessary, they now proceed regardless. The practical effect of disengagement is often not the abandonment of the mandate, but its advancement with less operational and technical input. I recognize this is not particularly pleasant for those operating networks, but it does suggest that the strategic choice that technical communities now face is deciding how and when to participate to shape discussions toward more pragmatic outcomes – since there will be outcomes, and fewer & more feasible approaches definitely beats the alternative. FYI, /John p.s. Disclaimers: my views alone; your mileage may vary; this email composed with 100% recycled electrons...

On Feb 16, 2026, at 11:21 PM, nanog--- via NANOG <nanog@lists.nanog.org> wrote:

It would be nice if bad laws were impossible to comply with. Then nobody would comply with them.

Then someone comes along and finds there's a way to sell the appearance of complying with the law (even though actual compliance is impossible) as a service, and everybody is forced to buy the service so they don't get prosecuted.

Just one more instance of bad politics and capitalism messing everything up for everybody.

On 16 February 2026 15:08:46 CET, Michael Greenup via NANOG <nanog@lists.nanog.org> wrote:

...

It is important to consider the extent to which US state government mandates influence the regulation of content access. For instance, numerous states now require identity verification for viewers of adult content to confirm their age. Many of these laws are formulated such that any viewer within the state's jurisdiction must be verified, necessitating IP address-based geolocation to ensure compliance.

Not saying I agree or disagree here, just laying out a regulated use case.

YMMV.

Regards,

Michael

The views and opinions included in this email belong to the author and are not representative of the views and opinions of the company which employs me. If you find a spelling or grammatical error, you may keep it.

Rich Kulawiec wrote:

...

...

Personally, I???ve always thought that IP Geolocation was a bad idea and nothing I???ve seen in the usage of it to date has changed my mind. Agree. We've spent decades trying to build a network that allows everyone to access everything independent of geographical location, and now people have come along with broken business models which demand that we abandon

On Sun, Feb 15, 2026 at 10:25:56PM -0800, Owen DeLong via NANOG wrote: this fundamental principle of the Internet in order to accomodate them.

---rsk

---

NANOG mailing list https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/VT47D47C...

---

NANOG mailing list https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/LYLXWZI7...

Geofeeds are automated submissions and corrections, which helps them regardless. Are you not going to produce and maintain a geofeed, because it helps for-profit businesses? Ryan Hamel Kind regards, Ryan Hamel ________________________________ From: Chris Adams via NANOG <nanog@lists.nanog.org> Sent: Monday, February 16, 2026 11:38:31 AM To: nanog@lists.nanog.org <nanog@lists.nanog.org> Cc: Chris Adams <cma@cmadams.net> Subject: Re: Geofeeds are adversarial — was Re: Geofeeds are good Caution: This is an external email and may be malicious. Please take care when clicking links or opening attachments. Once upon a time, Abdullah DevRel of IPinfo via NANOG <nanog@lists.nanog.org> said:

Hi Chris,

Thank you for flagging this. You can submit a correction if you want: https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Fipinfo.io%2Fcorrections&data=05%7C02%7Cryan%40rkhtech.org%7C8c3fca1e214a4ca61cee08de6d930bb6%7C81c24bb4f9ec4739ba4d25c42594d996%7C0%7C0%7C639068675489912412%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=Blw4zlHWpusg7w6jnXookA4YP0h7S5woFaKFz%2BPnyEE%3D&reserved=0<https://ipinfo.io/corrections>

Why should I provide free help for your for-profit service? -- Chris Adams <cma@cmadams.net> _______________________________________________ NANOG mailing list https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.nanog.org%2Farchives%2Flist%2Fnanog%40lists.nanog.org%2Fmessage%2F6NP56MG2FOBFYBPV6GIKDKOUGGPNYZ5I%2F&data=05%7C02%7Cryan%40rkhtech.org%7C8c3fca1e214a4ca61cee08de6d930bb6%7C81c24bb4f9ec4739ba4d25c42594d996%7C0%7C0%7C639068675489957338%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=LIX%2BVbBEh4pjfIHvvTtYbopxAJ9qv5rTzLTdUbBSjls%3D&reserved=0<https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/6NP56MG2FOBFYBPV6GIKDKOUGGPNYZ5I/>

Which is a lot like my comment on the law: If a judge in their court room orders you to raise your right leg you are well-advised to raise your right leg. If they order you to also raise your left leg they don't have a problem, you have a problem. On February 17, 2026 at 04:24 nanog@lists.nanog.org (John Curran via NANOG) wrote:

One observation from watching similar debates over the years – the period in which the Internet technical community could simply respond “that isn’t technically possible” or “that won’t work as intended” and expect the proposed law or regulation to stall seems largely behind us.

In many jurisdictions, if policymakers perceive a requirement as necessary, they now proceed regardless. The practical effect of disengagement is often not the abandonment of the mandate, but its advancement with less operational and technical input.

I recognize this is not particularly pleasant for those operating networks, but it does suggest that the strategic choice that technical communities now face is deciding how and when to participate to shape discussions toward more pragmatic outcomes – since there will be outcomes, and fewer & more feasible approaches definitely beats the alternative.

FYI, /John

p.s. Disclaimers: my views alone; your mileage may vary; this email composed with 100% recycled electrons...

...

On Feb 16, 2026, at 11:21 PM, nanog--- via NANOG <nanog@lists.nanog.org> wrote:

It would be nice if bad laws were impossible to comply with. Then nobody would comply with them.

Then someone comes along and finds there's a way to sell the appearance of complying with the law (even though actual compliance is impossible) as a service, and everybody is forced to buy the service so they don't get prosecuted.

Just one more instance of bad politics and capitalism messing everything up for everybody.

On 16 February 2026 15:08:46 CET, Michael Greenup via NANOG <nanog@lists.nanog.org> wrote:

...

It is important to consider the extent to which US state government mandates influence the regulation of content access. For instance, numerous states now require identity verification for viewers of adult content to confirm their age. Many of these laws are formulated such that any viewer within the state's jurisdiction must be verified, necessitating IP address-based geolocation to ensure compliance.

Not saying I agree or disagree here, just laying out a regulated use case.

YMMV.

Regards,

Michael

The views and opinions included in this email belong to the author and are not representative of the views and opinions of the company which employs me. If you find a spelling or grammatical error, you may keep it.

Rich Kulawiec wrote:

...

...

Personally, I???ve always thought that IP Geolocation was a bad idea and nothing I???ve seen in the usage of it to date has changed my mind. Agree. We've spent decades trying to build a network that allows everyone to access everything independent of geographical location, and now people have come along with broken business models which demand that we abandon

On Sun, Feb 15, 2026 at 10:25:56PM -0800, Owen DeLong via NANOG wrote: this fundamental principle of the Internet in order to accomodate them.

---rsk

---

NANOG mailing list https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/VT47D47C...

---

NANOG mailing list https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/LYLXWZI7...

_______________________________________________ NANOG mailing list https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/2UKQXS3S...

-- -Barry Shein Software Tool & Die | bzs@TheWorld.com | http://www.TheWorld.com Purveyors to the Trade | Voice: +1 617-STD-WRLD | 800-THE-WRLD The World: Since 1989 | A Public Information Utility | *oo*

Hey Abdullah, A lot of network operators here highlighted the fact they specifically maintain their geofeeds to ensure GeoIP services to serve accurate information. Also, it was mentioned in the thread that not many networks publish geofeed (or share one with you). Therefore, why wouldn't your team consider flagging "adversial" geofeeds/networks instead of relying onto whatever your active probing network is? If ipinfo genuinely cares about feedback, this is the only way forward to somewhat improve the situation for legitimate home internet service providers.

On Tuesday, February 17th, 2026 at 1:02 AM, Abdullah DevRel of IPinfo via NANOG <nanog@lists.nanog.org> wrote:

Hi Serhii,

[...] snip [...]

When an ISP contacts us saying "your data conflicts with our geofeed and here's why we're correct," we investigate and adjust the scoring for that prefix. I've done this several times during this thread - reviewing evidence with ISPs, presenting it to our data team, and updating the geofeed priority scoring.

[...] snip [...] — Abdullah | DevRel, IPinfo

Funny, in this single email thread with only a handful of people you've had to make corrections "several times". I thought your data was super accurate? It's crazy that there's apparently a viable business model in creating bad data and selling it. And when that bad data inevitably causes issues... you force others to correct it! All while ignoring the correct data operators are _already providing_. Best of all, you somehow manage to pat yourself on the back afterwards? The whole geoip business model is pure slime. -mu

Abdullah - Just curious, when you find "Legitimate networks “ with "inaccurate geofeeds” (as per below), do you ever inform the networks of their errant geofeed entries? If not, why not? Thanks, /John p.s. Disclaimers: my views alone; contents may be hot - use caution when opening.

On Feb 17, 2026, at 1:01 AM, Abdullah DevRel of IPinfo via NANOG <nanog@lists.nanog.org> wrote:

Hi Serhii,

Thank you for the question. I'll share our approach, but since you've raised an important design question, I'd genuinely welcome your thoughts on how we could improve this - perhaps a portal for ASN operators or geofeed providers to flag issues directly.

We use a scoring model that weighs multiple data sources: active measurements, geofeeds, WHOIS data, and others. When they conflict, we make decisions based on what we can verify. In our NANOG 96 talk, my colleague described this more precisely as a "decision tree" where multiple data points are aggregated and scored.

Legitimate networks can have inaccurate geofeeds for non-malicious reasons - stale data, network architecture changes, anycast configurations. Meanwhile, adversarial actors can forge geofeed data that appears legitimate. We do score geofeed sources based on factors like ASN verification, history, last update time etc.

When an ISP contacts us saying "your data conflicts with our geofeed and here's why we're correct," we investigate and adjust the scoring for that prefix. I've done this several times during this thread - reviewing evidence with ISPs, presenting it to our data team, and updating the geofeed priority scoring.

Should active measurement or self-reported data be the default? We chose measurement because it scales globally and provides verifiable evidence. Geofeeds remain part of the scoring model, but not the only factor.

I understand this may not be the answer you were hoping for. If you have specific prefixes where you think we're making the wrong choice, please reach out: abdullah@ipinfo.io

— Abdullah | DevRel, IPinfo _______________________________________________ NANOG mailing list https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/NJSJG3SW...

What is marketed is being more correct than the next company so there is incentive for performative data generation.

Being more correct or not is less important as long as you perform the correction ritual in public to maintain appearances, or at least tell everyone to take it to DMs. How close such corrections take you to being more correct is unverifiable.

Exactly this. ( Also bravo for 'performative data generation' . So well said. ) There's not really any incentive for any of these providers to be 100% correct. They just need to be 'good enough' that subscribers continue to pay for their data. On the flip side, users of geo data do the same thing. Thats why we always see posts here about 'my geo is wrong and I can't get SoAndSo to talk to me, pls help'. If everyone used the available geo data they'd have nothing to sell. Sorta. Very small percentage of IP space is covered by geofeeds. If this increases and people start to use that instead it should start to move the needle, but not yet. On Tue, Feb 17, 2026 at 11:20 AM Brandon Butterworth via NANOG < nanog@lists.nanog.org> wrote:

On 17/02/2026 15:40:32, "Mu via NANOG" <nanog@lists.nanog.org> wrote:

...

Funny, in this single email thread with only a handful of people you've had to make corrections "several times".

There are probably many more, I did not bother responding then or correcting their bad data for me.

...

It's crazy that there's apparently a viable business model in creating bad data and selling it.

What is marketed is being more correct than the next company so there is incentive for performative data generation.

Being more correct or not is less important as long as you perform the correction ritual in public to maintain appearances, or at least tell everyone to take it to DMs. How close such corrections take you to being more correct is unverifiable.

...

And when that bad data inevitably causes issues... you force others to correct it!

The public correction ritual is important for marketing that you have the freshest data so constant fixing is good. Buyers don't want stale data.

...

All while ignoring the correct data operators are _already providing_.

If everyone used the available geo data they'd have nothing to sell.

brandon

_______________________________________________ NANOG mailing list

https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/62ZNG7WJ...

On Feb 17, 2026, at 12:18 PM, Abdullah DevRel of IPinfo via NANOG <nanog@lists.nanog.org> wrote: …. The limitation you’re identifying is real. We could do more proactive outreach when we detect conflicts. That's valuable feedback. Would you recommend a specific approach - perhaps flagging high-confidence conflicts in a report ISPs could opt into?

“I know what I don’t know” (i.e. there’s no reason my opinion here would be either well-informed or particularly relevant) – but I am certain that some of the operators on this list will have timely suggestions… Thanks! /John p.s. Disclaimers: my views alone; may cause drowsiness – use caution when operating heavy machinery.

Hi Tom, You're right. The form language contradicts what I've been saying in this thread. That's on me for not catching the inconsistency. The form was written before our recent discussions about how we communicate our methodology. I've just updated it to better reflect our actual decision process: we use multiple data sources including active measurements and geofeeds, and when they conflict, we investigate rather than automatically prioritizing one over the other. Thank you for flagging the discrepancy. — Abdullah | DevRel, IPinfo

Hi Peter, Thank you for the thoughtful RFC improvement suggestions. Points 1 through 4 align well with discussions already underway in the IETF community, and we would be glad to see you participate in that process. For your specific ASN - we did start using your geofeed following our private conversation a few weeks ago. Please check your data and let us know if it looks better. I also reached out about hosting a probe server (from abdullah@ipinfo.io). Please do reply when you get a chance. — Abdullah | DevRel, IPinfo

Hi all, Just to add some information to the geofeed discussion, I found could be valuable: At LACNIC, there is already +5 years of operational support for geofeeds aligned with the IETF work in this space. RFC 8805 ( https://datatracker.ietf.org/doc/html/rfc8805 ) defines the standard CSV format for geofeeds, and RFC 9632 (https://www.rfc-editor.org/rfc/rfc9632.html) specifies the use of the geofeed: attribute in RPSL objects (e.g., inetnum / inet6num) so that operators can reference their geofeed directly from WHOIS/RDAP data. * Within the LACNIC region, members can: * Publish geofeed information through MiLACNIC. * Associate geolocation data with their IP resources. * Make this information publicly available in a structured and machine-readable way. By the way, there is a raw file you can download here: https://milacnic.lacnic.net/lacnic/geofeeds This allows operators to provide first-party location data in a standards-based manner, without relying solely on third-party inference. Of course, adoption and operational practices vary (clear low adoption), but the important is that functionality is available and aligned with the relevant RFCs. I thought this might be useful context for the ongoing discussion around trust, verification, and the role of RIRs in facilitating accurate geolocation data. Best regards, Nicolás Fiumarelli

Nonetheless, it would be nice that some neutral Internet measurement organization (of which there are a few) would take up this effort on a yearly basis.

The most likely outcome of that would be quite predictable. The companies on the low end of the scorecard would complain and say the analysis is flawed. The companies on the high end of the scorecard would use it in their marketing. On Fri, Feb 20, 2026 at 1:34 AM Hank Nussbacher via NANOG < nanog@lists.nanog.org> wrote:

...

Hi Hank,

Large-scale ground truth evaluations require access to data that is typically only available to enterprises internally. Our NANOG 96

On 16/02/2026 7:47, Abdullah DevRel of IPinfo via NANOG wrote: presentation (https://nanog.org/events/nanog-96/content/5678/) and our peer-reviewed research (https://dl.acm.org/doi/10.1145/3676869) present what we can share publicly about our methodology and accuracy. We would welcome an independent academic benchmark if one were to emerge.

I recently came across:

https://ipapi.is/blog/ip-geolocation-accuracy.html

which analyzed 10 geolocation DBs for accuracy based on ground-truth.

I assume it is biased and many here will point out the holes in their analysis.

Nonetheless, it would be nice that some neutral Internet measurement organization (of which there are a few) would take up this effort on a yearly basis.

Regards,

Hank

_______________________________________________ NANOG mailing list

https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/XMAJ26EX...