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/

Hi Ronan, you are right, BGP doesn't communicate any communities descriptions. In the case of bgp.tools, when you create an account and "claim" your AS, you can add these BGP community descriptions for your AS. They also seem to be sources from NLNOG Ring project (https://github.com/NLNOG/lg.ring.nlnog.net/tree/main/communities). January 22, 2026 9:38 PM, "Ronan Pigott via NANOG" <nanog@lists.nanog.org> wrote:

Hi,

First off, apologies if I'm completely lost. I'm not a network professional of any kind, just a random with a question I can't find the answer to on the internet.

Basically, I was poking around on this website called bgp.tools and many ASN have a page describing BGP communities known by the network, e.g. https://bgp.tools/communities/13335.

It includes descriptions for each one:

...

13335:10106 PoP: bos01 13335:10358 PoP: cwb03 13335:10712 PoP: den04 13335:10766 PoP: maa05 13335:10920 PoP: zrh02 [...]

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?

The background is that I live in AZ, USA, and am I subscribed to Cox for my internet service. I noticed that my ping to "example.com" (literally) is slower on IPv6 compared to IPv4:

$ ping -4 example.com PING example.com (104.18.27.120) 56(84) bytes of data. 64 bytes from 104.18.27.120: icmp_seq=1 ttl=251 time=9.58 ms 64 bytes from 104.18.27.120: icmp_seq=2 ttl=251 time=5.94 ms 64 bytes from 104.18.27.120: icmp_seq=3 ttl=251 time=7.76 ms 64 bytes from 104.18.27.120: icmp_seq=4 ttl=251 time=6.85 ms [...] $ ping -6 example.com PING example.com (2606:4700::6812:1b78) 56 data bytes 64 bytes from 2606:4700::6812:1b78: icmp_seq=1 ttl=57 time=20.0 ms 64 bytes from 2606:4700::6812:1b78: icmp_seq=2 ttl=57 time=19.0 ms 64 bytes from 2606:4700::6812:1b78: icmp_seq=3 ttl=57 time=20.8 ms 64 bytes from 2606:4700::6812:1b78: icmp_seq=4 ttl=57 time=19.8 ms [...] $ traceroute -IAen4 -z1 example.com traceroute to example.com (104.18.26.120), 30 hops max, 60 byte packets 1 10.3.0.254 [*] 0.249 ms 0.361 ms 0.362 ms 2 10.40.160.1 [*] 8.978 ms 8.658 ms 7.745 ms 3 100.127.73.232 [*] 6.957 ms 8.557 ms 6.881 ms 4 68.1.0.187 [AS22773] 8.067 ms 10.434 ms * 5 184.183.131.9 [AS22773] 13.818 ms 37.728 ms 17.832 ms 6 162.158.140.23 [AS13335] 16.822 ms 8.761 ms 16.768 ms 7 104.18.26.120 [AS13335] 8.813 ms 7.852 ms 9.451 ms $ traceroute -IAen6 -z1 example.com traceroute to example.com (2606:4700::6812:1b78), 30 hops max, 80 byte packets 1 2600:8800:1780:c000::1 [AS22773] 0.315 ms 0.360 ms 0.362 ms 2 2600:8800:17ff:ffff::1111 [AS22773] 6.601 ms 24.911 ms 9.655 ms 3 2001:578:800:6:8100::818 [AS22773] 31.164 ms 8.727 ms 9.075 ms 4 2001:578:900:4::2 [AS22773] 8.763 ms 7.661 ms 6.873 ms 5 2001:578:1:0:172:17:249:32 [AS22773] 29.991 ms 35.838 ms 19.517 ms 6 2001:578:20:a000::7:1 [AS22773] 21.781 ms 20.676 ms * 7 2400:cb00:12:3:: [AS13335] 20.474 ms 20.099 ms 19.824 ms 8 2606:4700::6812:1b78 [AS13335] 20.078 ms 19.747 ms 20.788 ms

It's not really a problem, but still I just want to know... why? I thought it would be kind of odd to have example.com hosted only on IPv4 in the Phoenix area so I was trying to see if I could determine whether or not that was the case looking at https://bgp.tools/communities/13335?show-prefixes=13335:10066, but I think there just simply isn't enough information available online for me to find out.

Thanks,

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

On Thu, Jan 22, 2026 at 1:55 PM Ronan Pigott <ronan@rjp.ie> 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 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/

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:

On Thu, Jan 22, 2026 at 1:55 PM Ronan Pigott <ronan@rjp.ie> 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 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...

Hello, As has been mentioned in this thread there is currently no standardized way for networks to communicate the meaning of the BGP communities they support or attach to their prefixes. I have authored an IETF draft that attempts to change this: 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. There are currently two networks with published community definitions (RIPE NCC's AS25152 and AS197000) and one implementation that can parse published definitions (NLNOG Looking Glass[0][1]). To further this effort it would help if more networks started publishing their communities using this format. Kind regards, Martin [0] https://lg.ring.nlnog.net/ [1] https://github.com/NLNOG/lg.ring.nlnog.net

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: [..] 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

_______________________________________________ NANOG mailing list

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

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. Waiting weeks for a geodb to detect and publish a change costs money ; pulling the feed from the source of truth is worth the effort to create tooling and automation around it. BGP communities don't see anywhere near the same volume of change. An ASN may add/remove locations as they build their network, which then changes location comms, but those things happen over long time horizons. Customer actions comms may be added or deleted, but again over a long period of time. There is no ROI to develop tooling around hypothetical BGP comm feeds ; this data never needs to be updated in real time if it changes. Beyond that, even if we did assert that a BGP community feed similar to geofeeds existed, the only thing it should EVER be used for is detection that a given ASN's communities have changed. It should NEVER be integrated with policy/config generation, unless you enjoy nuking your own network. On Mon, Jan 26, 2026 at 2:04 PM Callahan Warlick <callahanwarlick@gmail.com> wrote:

...

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 <

...

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

...

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

nanog@lists.nanog.org> parse 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...

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

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.

And for a lot of my users/systems/address ranges, you will be entirely incorrect using those measurements. Let's say your measuring endpoint is in Baltimore. Let's say I'm announcing out of Raleigh for whatever reason. Let's say the end users of that ... ah, let's say, /24, are all in Baltimore, and that range is only used for Baltimore people. Are you going to pin me in NC (incorrect) or Baltimore (correct, as my geofeed publishes)? Or in the case of a /24 that's used as an endpoint for a facility in Boston, but can be announced out of Houston, Los Angeles, or Ashburn depending on the failover scenario, my geofeed publishes that range as Boston, not any of those three cities, because that's where the users and end network actually is. So geolocation provider data is horribly inaccurate when it comes to the end-site's actual location for that address range. Same I've seen with other places, as well. -----Original Message----- From: Mike via NANOG <nanog@lists.nanog.org> Sent: Tuesday, January 27, 2026 12:11 PM To: North American Network Operators Group <nanog@lists.nanog.org> Cc: Mike <deezknuts@yahoo.com> Subject: Re: Geofeeds are good — was Re: Publishing BGP communties for your network (Re: What's up with BGP communities?) 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/SD OEDEZ7UUM4FZNHQJQBFCIR4W3HEP2X/

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

On Tue, Jan 27, 2026 at 10:03 AM, Ca By <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.

A quick shout out to Massimo Candela, and the excellent https://geolocatemuch.com/. They walk the IRR databases, collect all of the GeoFeed: files, perform validation on them, and then publish all validated feeds in a single file: https://geolocatemuch.com/geofeeds/validated-all.csv This is a ~26MB file, containing the ~575131 prefixes with geofeeds… This page also has a nice "Test your geofeed" feature, which allows you to, um, check your geofeed. E.g: https://geolocatemuch.com/?resource=31.130.224.1 This is an address in the IETF Meeting network prefix - the next meeting, IETF 125 is in Shenzhen, and so we've pre-published a Geofeed file for this: https://noc.ietf.org/geo/google.csv W

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 <http://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/ SDOEDEZ7UUM4FZNHQJQBFCIR4W3HEP2X/

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

On Tue, Jan 27, 2026 at 2:24 PM, Ben Cartwright-Cox <nanog@lists.nanog.org> wrote:

Depends on what your (from the geoip providers point of view) customers goals are really.

Yup, completely agree. GeoIP's original goals were to get users to the "closest" datacenter to minimize latency (yes, yes, network topology is not the same as geographic topology, but it's often good enough). It has been expanded (co-opted?!) to also get people to a close pizza parlor, and now also is being used (abused?) to implement content restrictions. These were not part of the original design, and so it's not surprising if they don't work well for that... This reminds me of one of my favorite quotes: "I don't think the execution is relevant when it was obviously a bad idea in the first place. This is like putting rabid weasels in your pants, and later expressing regret at having chosen those particular rabid weasels and that pair of pants. " -- maf W 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?

_______________________________________________ NANOG mailing list

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

Hi,

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?

IP geolocation needs to be: - Verifiable - Granular - Accurate That means we need to know just enough to point to the right ZIP code or the right city. Here is our organizational approach to IP geolocation service. - Active measurement involves building a network of 1320 servers across 555 cities and in 152 countries, continuously expanding. This network of servers, designed to generate continuous Internet measurements, is unique to us, not the industry. This is a continuously growing network of servers. - We have made massive investments in data processing and machine learning. - We have a research team dedicated to R&D to find new ways to improve the accuracy and granularity of IP geolocation. - We have complementary administrative teams dedicated to support and outreach. The reason goes back to the 3 points. - Verification: Geofeed cannot be verified. Geofeeds, in most cases, are not well-maintained. - Granularity: Geofeeds from major ISPs often point to the country level or the closest major town. - Accuracy: Geofeed does not come with an accuracy guarantee. We like geofeed. It is another source of data. Even with active measurement, we may need help from ASN. When active measurement fails we have to fall back to something. Geofeed is good. But geofeed is not universal solution. More often thatn geofeed can be misleading or the data insights may not be there. The smaller ISPs diligently publish geofeed and we deeply appreciate them. We constantly have ongoing conversations with them (like we are having here) about our data accuracy and what we can do to fix it. If they say your data is not good for us, we will run our tests and we will work out a solution with them. We are always there. At a global scale, geofeed is a trust-based system. But the internet is a concept verification-based system. Even though geofeed represents another data source for us, it is not the best data source. That is why we are investing in our generating first-party data sources for IP geolocation. — Abdullah | DevRel, IPinfo

Gary Sparkes wrote:

...

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. And for a lot of my users/systems/address ranges, you will be entirely incorrect using those measurements.

Let's say your measuring endpoint is in Baltimore. Let's say I'm announcing out of Raleigh for whatever reason.

Let's say the end users of that ... ah, let's say, /24, are all in Baltimore, and that range is only used for Baltimore people.

Are you going to pin me in NC (incorrect) or Baltimore (correct, as my geofeed publishes)?

Or in the case of a /24 that's used as an endpoint for a facility in Boston, but can be announced out of Houston, Los Angeles, or Ashburn depending on the failover scenario, my geofeed publishes that range as Boston, not any of those three cities, because that's where the users and end network actually is.

So geolocation provider data is horribly inaccurate when it comes to the end-site's actual location for that address range.

Same I've seen with other places, as well.

-----Original Message----- From: Mike via NANOG <nanog@lists.nanog.org> Sent: Tuesday, January 27, 2026 12:11 PM To: North American Network Operators Group <nanog@lists.nanog.org> Cc: Mike <deezknuts@yahoo.com> Subject: Re: Geofeeds are good — was Re: Publishing BGP communties for your network (Re: What's up with BGP communities?)

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/SD OEDEZ7UUM4FZNHQJQBFCIR4W3HEP2X/

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

If we are providing inaccurate data for you, please talk to us. Please understand that our active measurement has inherent fail-safe mechanisms. When the data is noisy, we will fail over to geofeed. We collect ping and traceroute data for IP addresses through servers hosted in various cities. We will not accept noisy data to generate IP geolocation data just because. The entire idea is based on a verifiability hierarchy. If a customer asks why an IP address is located in a certain place, we can show them our ping data, traceroute data, etc. If we see an average of 20ms+ RTT (for example) to the IP address, we will not use that to produce the IP geolocation data. That is not justifiable evidence for the geolocation. Then we can fall back on the geofeed data and state that the IP address operators/owners announced that the IP address is located there. Geofeed is great as a fallback data source but it is not our primary source of data. Let me know what you think, please. Thank you very much. — Abdullah | DevRel, IPinfo

Hi, Our updates are pushed within 24 to 48 hours, provided they pass our automated verification checks. If the verification checks fail, you can request a deeper investigation. We are not the poster child of the IP geolocation service industry. We are more frustrated than you are about the IP geolocation industry. We are trying to be responsible with our data, but not only do some enterprise organizations default to legacy providers, but because we are a very public company, we bear the brunt of end users' complaints about industry faults. We strive to do well and not accept industry faults. We have a great support team, and I act as the "account manager" for everyone impacted by our data. You do not have to pay us or anything. Just talk to us if there is any issue. — Abdullah | DevRel, IPinfo https://www.linkedin.com/in/reincoder/ https://x.com/reincdr

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

On Tue, 27 Jan 2026, Mike via NANOG wrote:

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?

Anyone else having deja vu? I feel like we had this topic (even with Abdullah @ IPinfo) some months ago. Having worked at various times for ISPs, CDNs, and VPN providers, I've been (well, my customers have been) inconvenienced by incorrect IP Geo sold by IP Geo providers, and I can understand Abdullah/IPinfo's reluctance to simply "trust the feeds" because it is so much easier/cheaper for a VPN provider to lie in their geofeed than to actually build POPs all around the world. I've also faced the frustration of IP Geo providers with outdated/incorrect data relating to our IPs with either no clear way for us to help update their data or a path is provided, but it takes weeks for that update to get pushed out. The latter seems unnecessary and unacceptable. The worst are the "set it up and forget it" installations of IP Geo data that never gets updated. We have a /16 that was bought years ago. Originally, it was RIPE space. I've dealt with a number of IP Geo end users with years out of date local copies of some IP Geo provider's data who have the /16 filtered as they don't want their networks/websites accessed by non-domestic eyeballs. For Abdullah, not knowing the layout of a service provider's network, I don't care how many points around the Internet you can measure RTT from, you're not going to accurately guess IP Geo from RTT down to the DMA. As a FTTH ISP, that's the level of accuracy our customers demand, 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. ---------------------------------------------------------------------- Jon Lewis, MCP :) | I route Blue Stream Fiber, Sr. Neteng | therefore you are _________ http://www.lewis.org/~jlewis/pgp for PGP public key_________

Therein lies the problem though - mind you, I'm speaking from past experience, not current data, but still..... In that three potential scenario, it may be 6 months to a year between failovers, but in every case, all three termination/announcement points aren't reflective of the actual end users/site the addresses are actually utilized under. So measurement may see it as Ashburn VA for a long time, even though the office/site utilizing that range is actually in Boston, MA as reflected in the geofeed. That's where it becomes a problem. I know a company that announces out of Ashburn, VA and Houston, TX as well, they have a slew of ranges and sometimes fail over between the two if tunnels fail or whatever other scenarios, planned maintenance, etc, but usually one side of the US goes through Houston, and the other through Ashburn. But the geofeed covers ranges and locations in all 50 states. (All sites tunnel back to the datacenters before going out their respective NAT pools and what have you before hitting the 'public' internet) -----Original Message----- From: Abdullah DevRel of IPinfo via NANOG <nanog@lists.nanog.org> Sent: Tuesday, January 27, 2026 10:13 PM To: 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?) Gary Sparkes wrote:

...

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. And for a lot of my users/systems/address ranges, you will be entirely incorrect using those measurements.

Let's say your measuring endpoint is in Baltimore. Let's say I'm announcing out of Raleigh for whatever reason.

Let's say the end users of that ... ah, let's say, /24, are all in Baltimore, and that range is only used for Baltimore people.

Are you going to pin me in NC (incorrect) or Baltimore (correct, as my geofeed publishes)?

Or in the case of a /24 that's used as an endpoint for a facility in Boston, but can be announced out of Houston, Los Angeles, or Ashburn depending on the failover scenario, my geofeed publishes that range as Boston, not any of those three cities, because that's where the users and end network actually is.

So geolocation provider data is horribly inaccurate when it comes to the end-site's actual location for that address range.

Same I've seen with other places, as well.

-----Original Message----- From: Mike via NANOG <nanog@lists.nanog.org> Sent: Tuesday, January 27, 2026 12:11 PM To: North American Network Operators Group <nanog@lists.nanog.org> Cc: Mike <deezknuts@yahoo.com> Subject: Re: Geofeeds are good — was Re: Publishing BGP communties for your network (Re: What's up with BGP communities?)

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/ SD OEDEZ7UUM4FZNHQJQBFCIR4W3HEP2X/

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

If we are providing inaccurate data for you, please talk to us. Please understand that our active measurement has inherent fail-safe mechanisms. When the data is noisy, we will fail over to geofeed. We collect ping and traceroute data for IP addresses through servers hosted in various cities. We will not accept noisy data to generate IP geolocation data just because. The entire idea is based on a verifiability hierarchy. If a customer asks why an IP address is located in a certain place, we can show them our ping data, traceroute data, etc. If we see an average of 20ms+ RTT (for example) to the IP address, we will not use that to produce the IP geolocation data. That is not justifiable evidence for the geolocation. Then we can fall back on the geofeed data and state that the IP address operators/owners announced that the IP address is located there. Geofeed is great as a fallback data source but it is not our primary source of data. Let me know what you think, please. Thank you very much. — Abdullah | DevRel, IPinfo _______________________________________________ NANOG mailing list https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/GW6VQ5CA...

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://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/>

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://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/>

I agree with Mr Hawker, that the operative phrase is "trust, but verify."  I understand Mr. DevRel's need to verify locations so his customers have some assurances, but the data broker will never know or care as much about that being accurate--for good actors--as the provider's customers and therefore the provider. I suspect the providers here would be happy if GeoIP companies defaulted to the Geofeed and used their proprietary tracking systems to confirm the information (and maybe even report to the provider if there is a mismatch, so they have an opportunity to cure or explain any discrepancy) instead of defaulting to their proprietary systems.  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. For example, we have IP blocks that cover a half dozen zip codes in central Illinois, while our upstream providers are in Chicago and St Louis--all three culturally a very different locations. The IPs are all static so we produce Geofeeds that give the correct zip code of each IP accurately. 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?).  Both of those can lead to real problems for customers.  For example, the wrong local TV channels may be offered on a TV streaming platform, or even worse the wrong sports teams!  It is a source of frustration for many of our users, and they blame us for it. Peter Folk, Volo.net Internet+Tech

We focus on the actual or real locations of IP addresses. A great example we show is through our VPN report.

You report what your testing methods determine to be the location, which may not be what it actually is. On Tue, Jan 27, 2026 at 11:29 PM Abdullah DevRel of IPinfo via NANOG < nanog@lists.nanog.org> 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...

Hi Hank, That is interesting that you mention that. We are working on "cruise" tag. We have various POI tags. https://ipinfo.io/tags IP Tags like satellites can be detected through internet measurements and behavior mapping. We have hotels, airports, airplanes, conferences etc. We are also working on train and cruises. However, we need some test data, though. Do you know which IP address you connected to while on the cruise? — Abdullah | DevRel, IPinfo

On Tue, Jan 27, 2026 at 05:10:08PM -0600, Warren Kumari via NANOG wrote:

It has been expanded (co-opted?!) to also get people to a close pizza parlor, and now also is being used (abused?) to implement content restrictions.

These were not part of the original design, and so it's not surprising if they don't work well for that...

Concur. There's also an obvious disconnect here between network engineers who care about operating in as close to "correctly" (whatever that means at the moment, and of course we've debated that for decades) as they can possibly get, and people who only care about making as much money as they can as fast as they can by selling off the privacy of Internet users to the parasites in the data broker ecosystem. ---rsk

This GeoIP topic is one of the most frequent 'help please' things posted on the NANOG list, and often there is no recourse whatsoever, users/ISPs are just banned and there's nobody to even complain to. The reason operators don't like this is because the whole situation is backwards - instead of the user or operator being asked where their users are, somebody else is answering for them and we don't even know it's happening until users complain they're blacklisted. If GeoIP was used to default a country dropdown and the user was always asked what country, there would be no problem, but it's being used as a weapon and the arms dealers are the GeoIP providers.  So when content providers take this antagonistic approach it's no surprise that some operators are publishing geofeeds that may not be totally honest, but there is also no way to actually verify it and so the best source we have is the geofeed.  You can ping/traceroute all you want and you're measuring something, but not the right thing.  From my point of view, that is the problem - instead of asking where a user is, the consumers of GeoIP data are telling users where they are, usually with no way to override it - the data aggregators get paid, the users and ISPs are yelling into the void and life goes on.  Often they don't even tell you where they think you are, just that you're banned.  Abdullah is responsive and seems to care and maybe ipinfo will work with you, but the problem is still that they're not taking the operator's word for it and that's just one GeoIP provider.  There are other adversarial approaches like capturing location info from mobile phones and associating the IP with that - without the user or even the ISP being consulted. All of these lead to loss of control for the operator, punishments are dealt out based on this data (can't watch sports, can't access local site, etc), and the people who cause the problem (GeoIP vendors) aren't the ones that feel the pain so there's no reason to stop. 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. PS: What happened to being able to opt out?  RFC8805 2.1.2 says: " Feed publishers may indicate that some IP prefixes should not have any associated geolocation information. " but this doesn't seem to be respected by anybody either. -Laszlo On 1/28/26 3:34 AM, Abdullah DevRel of IPinfo via NANOG wrote:

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

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

Hi Peter, I agree with you. We do use geofeed as a data source. However, verifiable and good geofeed only represents a very small source of our data. I deeply respect your and NANOG community's opinion and expertise. For us, operating at a global scale where we have to process billions and billions of IP addresses from thousands of network operators. You will be surprised how little accuracy is in the geofeed. Active measurements represent a practical improvement over a theoretical geofeed system that is consistently true, verifiable, and accurate. Geofeed is a trust-based system, and our customer base largely is in cybersecurity where "zero trust" is their foundational principle. For example, you mentioned that we do not correctly map your prefixes. A single support chat message could help us fall back to using your geofeed as we get the region right based on active measurement. Just a single message from you to our support is why I am here. The active measurement will still be used as a foundational layer of data, while we will use your geofeed to improve the granularity of the data. But if you want me to make this mutually beneficial arrangement, sell us a server in your facility: https://forms.gle/kNYr2MBL8zRPgNrJ8 I am here for absolute accountability. The reason I am here is to ask you to please tell me if you see an error, like you have shared here. That added layer of verification of geofeed could be considered as someone just telling us that we are wrong, or ideally, allowing us to purchase a server with you. That way we can guarantee constant accuracy. — Abdullah | DevRel, IPinfo

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.

I understand your frustration, but in general, and in some specific cases, active measurement at our scale (1300+ servers, self-operated, 550+ cities) is going to be better than geofeed. Again, we appreciate geofeed and we accept geofeed to be important. But we are approaching data granularity for some cases that have never been seen or even imagined to be possible in the IP geolocation industry, even though this industry is nearing three decades old. Please understand that a portion of network operators being attentive and vigilant about geofeed is not universal. We definitely appreciate them, but they are a positive outlier. We absolutely respect them for their vigilance and contribution. For us, we operate on a global scale and our data impacts everyone. Bigger telecoms do not maintain geofeed accuracy. Outside of active and conscious participants a lot of time we do not see geofeed's existence, let alone maintenance of it. Our product is not specific to a handful of willing and geneorus network operators; it is specific to all IP addresses for which we have to provide data. Geofeed's data verification is such a significant issue; we have focused on active measurements, which have resulted in universal gross accuracy improvement for our data. The infrastructure, the data, the team, and the mission require massive investments. For a hosting IP address, we cannot point to the rack or room, but we can at least point to a data center because we have a PoP hosted in the data center. With active measurement, we can also point the neighboring IP addresses to the data center. In general terms, active measurements the way IPinfo does (not the industry as a whole) is a superior method to the current status quo. And when active measurement has gaps, we can always refer to geofeed. We are not ignoring geofeed; we extend and enhance it to a degree. When geofeeds are used to misdirect, we do ignore it. It goes back to three things: Verification, accuracy, and granularity. For now, active measurements are the reasonable path that makes every internet user happy. We are not representative of the industry. My opinions are about IPinfo's approach to IP geolocation. We are trying to carve out a separate path for because of the challenges we have seen in the industry. We are trying to be present in every discussion with network operators because we do not want frustration to be the reason for collaboration. We genuinely are trying our best for network operators to be happy with us. If your data is wrong with us, tell us, reach out to us, we will work out a solution. But our current approach to IP geolocation has in general been largely satisfactory in practice. — Abdullah | DevRel, IPinfo Help us improve our data: https://forms.gle/Ja64QWrJuW8PkUzK6

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

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_________

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

On Thu, 29 Jan 2026 03:20:30 -0000 Abdullah DevRel of IPinfo via NANOG <nanog@lists.nanog.org> wrote:

...

bear much of the cost of what a and c are doing. Oops, I meant to say "what a and b 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

c is everyone else. John

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 .

Even low end CDNs have more reach than that. Let's move on though. - ISP publishes geofeed of their IPs. - ISP starts getting support calls from customers that go to WEBSITE, and it's the version from another country. Techs spend time troubleshooting this. They reach out to WEBSITE. After much back and forth, it's determined that WEBSITE is using geolocation data from GEO-PROVIDER. >> ISP has spent time and money dealing with the support problem. << - ISP has someone reach out to GEO-PROVIDER to get the data corrected. >> ISP has spent time and money fixing the incorrect geo information . << - At a future point in time, GEO-PROVIDER reverts to the wrong information, because they decided their data is 'better' than what the ISP published. - ISP starts getting support calls from customers that go to WEBSITE, and it's the version from another country. Techs spend time troubleshooting this. They reach out to WEBSITE. After much back and forth, it's determined that WEBSITE is using geolocation data from GEO-PROVIDER. >> ISP has spent time and money dealing with the support problem. << - ISP has someone reach out to GEO-PROVIDER to get the data corrected. >> ISP has spent time and money fixing the incorrect geo information . << Every time an ASN has to deal with a support issue caused by incorrect data , it costs them time and money. On Wed, Jan 28, 2026 at 10:21 PM 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...

Hi, Apologies for the early exit. My colleague Calvin Ardi, research scientist at IPinfo, will be presenting a full talk on Monday (Feb 2, 2026) at NANOG96: IP Geofeeds: Trust, Accuracy, and Abuse: https://nanog.org/events/nanog-96/content/5678/ Please join the talk. There will be a Q&A. I was unable to answer some technical questions here. Calvin is your guy! Thank you very much. — Abdullah | DevRel, IPinfo