IPinfo Geolocation Advice Needed
Greetings, Does anyone have any suggestions on how to get IPinfo to properly report Geolocation for NNI pint to point type circuits? I have a geofeed that they are ignoring, but I have two prevailing theories. One - someone put our entire ARIN aggregate in it last month and now it overlaps everything in the feed. I read that overlapping prefixes cause confusion. I took it out of the feed today, but IPinfo is so secretive I have no idea if they will remove it. Two, and the more likely theory based on their boast on how they beat the competitor by thousands of miles, is they are reporting on the wrong end based on their ping scans. They ping the hub end of a /31 and disregard the other end that is usually two to three states away. Therefore , they are the ones horrible off an their competitors are spot on. Should I not be reporting the point to point /31 and only use he customer /32 end? Any other advice in properly identifying the location for Ipinfo would be awesome. All the other providers seem to properly follow my geofeed, and I have no issues with them. Thank you very much, Mark Blackford
If your issue is only with IPinfo, you should try to reach out to them. I'll say I've seen that name come up recently and they've had some pretty bad data/poor customer experiences. On Tue, Oct 21, 2025 at 8:24 PM Mark Blackford via NANOG < nanog@lists.nanog.org> wrote:
Greetings,
Does anyone have any suggestions on how to get IPinfo to properly report Geolocation for NNI pint to point type circuits? I have a geofeed that they are ignoring, but I have two prevailing theories.
One - someone put our entire ARIN aggregate in it last month and now it overlaps everything in the feed. I read that overlapping prefixes cause confusion. I took it out of the feed today, but IPinfo is so secretive I have no idea if they will remove it.
Two, and the more likely theory based on their boast on how they beat the competitor by thousands of miles, is they are reporting on the wrong end based on their ping scans. They ping the hub end of a /31 and disregard the other end that is usually two to three states away. Therefore , they are the ones horrible off an their competitors are spot on.
Should I not be reporting the point to point /31 and only use he customer /32 end?
Any other advice in properly identifying the location for Ipinfo would be awesome. All the other providers seem to properly follow my geofeed, and I have no issues with them.
Thank you very much, Mark Blackford _______________________________________________ NANOG mailing list
https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/5FNHPXSU...
Hi Josh, Thanks for the reply. I should have mentioned that I have been feeding them manual corrections and opening support tickets the past few days, but they pride themselves on ignoring ISPs in favor of their own probes and ping times. I'm at a total loss at what to do since IPinfo ignores the geofeed, ignores all the other providers that are correct, and takes pride in being wrong because they ping the wrong end. I was hoping another point to point provider has had success in getting their data corrected with IPinfo. It's odd to me how IPinfo can be highly recommended by developers on this list, but their data is so far off. I can see how their method would work for an enterprise, BNG or cable provider, but not at all for an NNI ISP provider. Thanks again, Mark Blackford On Tue, Oct 21, 2025 at 9:16 PM Josh Luthman <josh@imaginenetworksllc.com> wrote:
If your issue is only with IPinfo, you should try to reach out to them. I'll say I've seen that name come up recently and they've had some pretty bad data/poor customer experiences.
On Tue, Oct 21, 2025 at 8:24 PM Mark Blackford via NANOG < nanog@lists.nanog.org> wrote:
Greetings,
Does anyone have any suggestions on how to get IPinfo to properly report Geolocation for NNI pint to point type circuits? I have a geofeed that they are ignoring, but I have two prevailing theories.
One - someone put our entire ARIN aggregate in it last month and now it overlaps everything in the feed. I read that overlapping prefixes cause confusion. I took it out of the feed today, but IPinfo is so secretive I have no idea if they will remove it.
Two, and the more likely theory based on their boast on how they beat the competitor by thousands of miles, is they are reporting on the wrong end based on their ping scans. They ping the hub end of a /31 and disregard the other end that is usually two to three states away. Therefore , they are the ones horrible off an their competitors are spot on.
Should I not be reporting the point to point /31 and only use he customer /32 end?
Any other advice in properly identifying the location for Ipinfo would be awesome. All the other providers seem to properly follow my geofeed, and I have no issues with them.
Thank you very much, Mark Blackford _______________________________________________ NANOG mailing list
https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/5FNHPXSU...
Lookup their execs on LinkedIN (Ben Dowling) and send them messages letting them know how much their support sucks. Continue to do that until you get a resolution. I have found that doing this works with companies where i can’t get resolution elsewhere. Good luck! -Mike
On Oct 21, 2025, at 19:42, Mark Blackford via NANOG <nanog@lists.nanog.org> wrote:
Hi Josh,
Thanks for the reply. I should have mentioned that I have been feeding them manual corrections and opening support tickets the past few days, but they pride themselves on ignoring ISPs in favor of their own probes and ping times. I'm at a total loss at what to do since IPinfo ignores the geofeed, ignores all the other providers that are correct, and takes pride in being wrong because they ping the wrong end.
I was hoping another point to point provider has had success in getting their data corrected with IPinfo. It's odd to me how IPinfo can be highly recommended by developers on this list, but their data is so far off. I can see how their method would work for an enterprise, BNG or cable provider, but not at all for an NNI ISP provider.
Thanks again, Mark Blackford
On Tue, Oct 21, 2025 at 9:16 PM Josh Luthman <josh@imaginenetworksllc.com> wrote:
If your issue is only with IPinfo, you should try to reach out to them. I'll say I've seen that name come up recently and they've had some pretty bad data/poor customer experiences.
On Tue, Oct 21, 2025 at 8:24 PM Mark Blackford via NANOG < nanog@lists.nanog.org> wrote:
Greetings,
Does anyone have any suggestions on how to get IPinfo to properly report Geolocation for NNI pint to point type circuits? I have a geofeed that they are ignoring, but I have two prevailing theories.
One - someone put our entire ARIN aggregate in it last month and now it overlaps everything in the feed. I read that overlapping prefixes cause confusion. I took it out of the feed today, but IPinfo is so secretive I have no idea if they will remove it.
Two, and the more likely theory based on their boast on how they beat the competitor by thousands of miles, is they are reporting on the wrong end based on their ping scans. They ping the hub end of a /31 and disregard the other end that is usually two to three states away. Therefore , they are the ones horrible off an their competitors are spot on.
Should I not be reporting the point to point /31 and only use he customer /32 end?
Any other advice in properly identifying the location for Ipinfo would be awesome. All the other providers seem to properly follow my geofeed, and I have no issues with them.
Thank you very much, Mark Blackford _______________________________________________ NANOG mailing list
https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/5FNHPXSU...
_______________________________________________ NANOG mailing list https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/G3AA2MLF...
We have similar issues with IPinfo and customer devices which are in different countries. IPinfo ignores our geofeed file and have not responded favorably to our support tickets requesting they user our geofeed data or fix their database entries. Whenever a customer complains specifically about IPinfo, we tell them we will try to get the issue resolved but they should use a more reputable geolcation provider such as MaxMind for their geolocation needs. Good luck getting your issues resolved! 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. If you find a spelling or grammatical error, you may keep it.
Hi Michael, Thanks for sharing. I completely agree IPinfo has created a "random city generator" based on ping times of all things. I was told by IPinfo support that my geofeed has been elevated to a more trusted status "for now". However, it hasn't helped, and who knows how long "for now" is? We went through all the trouble of setting up GeoBox on Netbox to push an accurate geofeed tied directly to the IPAM, and this IPinfo rogue company is the only one not using it. Mark
Lookup their execs on LinkedIN (Ben Dowling) and send them messages letting them know how much their support sucks. Continue to do that until you get a resolution.
I have found that doing this works with companies where i can’t get resolution elsewhere.
IP geolocation database providers have zero incentive to care about an individual ISP's data being incorrect, UNLESS the companies that are paying them for access to that data complain about it. Yelling at their execs changes nothing ; this is the business model. On Tue, Oct 21, 2025 at 11:11 PM Mike Lyon via NANOG <nanog@lists.nanog.org> wrote:
Lookup their execs on LinkedIN (Ben Dowling) and send them messages letting them know how much their support sucks. Continue to do that until you get a resolution.
I have found that doing this works with companies where i can’t get resolution elsewhere.
Good luck!
-Mike
On Oct 21, 2025, at 19:42, Mark Blackford via NANOG < nanog@lists.nanog.org> wrote:
Hi Josh,
Thanks for the reply. I should have mentioned that I have been feeding them manual corrections and opening support tickets the past few days, but they pride themselves on ignoring ISPs in favor of their own probes and ping times. I'm at a total loss at what to do since IPinfo ignores the geofeed, ignores all the other providers that are correct, and takes pride in being wrong because they ping the wrong end.
I was hoping another point to point provider has had success in getting their data corrected with IPinfo. It's odd to me how IPinfo can be highly recommended by developers on this list, but their data is so far off. I can see how their method would work for an enterprise, BNG or cable provider, but not at all for an NNI ISP provider.
Thanks again, Mark Blackford
On Tue, Oct 21, 2025 at 9:16 PM Josh Luthman < josh@imaginenetworksllc.com> wrote:
If your issue is only with IPinfo, you should try to reach out to them. I'll say I've seen that name come up recently and they've had some pretty bad data/poor customer experiences.
On Tue, Oct 21, 2025 at 8:24 PM Mark Blackford via NANOG < nanog@lists.nanog.org> wrote:
Greetings,
Does anyone have any suggestions on how to get IPinfo to properly report Geolocation for NNI pint to point type circuits? I have a geofeed that they are ignoring, but I have two prevailing theories.
One - someone put our entire ARIN aggregate in it last month and now it overlaps everything in the feed. I read that overlapping prefixes cause confusion. I took it out of the feed today, but IPinfo is so secretive I have no idea if they will remove it.
Two, and the more likely theory based on their boast on how they beat the competitor by thousands of miles, is they are reporting on the wrong end based on their ping scans. They ping the hub end of a /31 and disregard the other end that is usually two to three states away. Therefore , they are the ones horrible off an their competitors are spot on.
Should I not be reporting the point to point /31 and only use he customer /32 end?
Any other advice in properly identifying the location for Ipinfo would be awesome. All the other providers seem to properly follow my geofeed, and I have no issues with them.
Thank you very much, Mark Blackford _______________________________________________ NANOG mailing list
https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/5FNHPXSU...
_______________________________________________ NANOG mailing list
https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/G3AA2MLF... _______________________________________________ NANOG mailing list
https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/J7EMHH6A...
Hey all, Ben, founder of IPinfo here. We care deeply about the quality and accuracy of our data, so I definitely want to get the issues flagged on this thread fixed. The best way to submit geolocation feedback to us in general is via https://ipinfo.io/corrections. By default we perform a lot of verification and filtering to geofeeds, and there's a surprising amount of adversarial data in geofeeds, from providers who are incentivised to pretend their IPs are in locations that they're not (mostly from proxy and vpn providers, and some hosting providers). It sounds like that creating problems for some operators though, and we'll look into how we can balance that. Happy to jump on a call to discuss our data quality and approach to geolocation with anyone. And feel free to escalate any data quality issues you see directly to me over email too - ben@ipinfo.io Thanks, Ben
Hi, I am Abdullah, the DevRel of IPinfo. Let me go through each message one by one. Thank you.
Hi Josh, I am sorry to hear that. I have never had a bad experience with customers or developers before and I am a bit surprised. Maybe I have missed something. Can you give me specific cases, please? I am happy to address them one by one. We monitor all forums and conversations and we have a great support team as well. So, I am surprised that there is any negative sentiment about us out there. I could be missing something, please point them out to me. In case there is an issue, please reach out to me personally as well. I prefer Linkedin based communications over emails for our users: https://www.linkedin.com/in/reincoder/ Thank you. — Abdullah | DevRel, IPinfo
Ben - Do you know if there has been research or studies done regarding the "surprising amount of adversarial data in geofeeds,from providers who are incentivised to pretend their IPs are in locations that they're not” I ask because this would make a fascinating topic for a paper or session at NANOG, as it would help provide the ISP community a better understanding of what you’re up against in terms of trying to collate reliable data. Thoughts? /John
On Oct 22, 2025, at 7:31 PM, ben--- via NANOG <nanog@lists.nanog.org> wrote:
Hey all,
Ben, founder of IPinfo here. We care deeply about the quality and accuracy of our data, so I definitely want to get the issues flagged on this thread fixed.
The best way to submit geolocation feedback to us in general is via https://ipinfo.io/corrections.
By default we perform a lot of verification and filtering to geofeeds, and there's a surprising amount of adversarial data in geofeeds, from providers who are incentivised to pretend their IPs are in locations that they're not (mostly from proxy and vpn providers, and some hosting providers). It sounds like that creating problems for some operators though, and we'll look into how we can balance that.
Happy to jump on a call to discuss our data quality and approach to geolocation with anyone. And feel free to escalate any data quality issues you see directly to me over email too - ben@ipinfo.io
Thanks, Ben _______________________________________________ NANOG mailing list https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/CO2TITVY...
Thank you Ben and Abdullah for joining the discussion. I understand the balance IPinfo has to make, but hopefully what I have explained to Abdullah on LinkedIn and your support team about the nature of hub and spoke EVPL/NNI networks, point to point IP assignments in /31 ranges, and automatic geofeeds from IPAM product like Netbox helps clarify how your probes do not paint the whole Geo IP picture. For example from my support case, an IPinfo probe in Charlotte, NC sends data to my customer also Charlotte, but has to traverse Internet providers to first get to my network hub in Dallas, and then make the trip over my EVPL/NNI back to my end user in Charlotte who is the one that needs accurate Geo IP location for content providers. I am sure this ping time should be about twice the expected 25-30ms round trip latency expected. Meanwhile, an IPinfo probe in Dallas pings the other end of the /31 with < 1ms latency, which is just on a gateway on a router with no users, and simply concludes I am lying in the geofeed, the /31 must be in Dallas and not Charlotte. You are only half correct in that one end of /31 is in Dallas, but it's not the end that matters to your clients or mine. The end that matters is in Charlotte who is looking at content provided by your clients to my clients. I have offered to Abdullah that I would be willing to work with your developers in any way to make this operationally sound for all that are involved. Thank you again, Mark Blackford On Wed, Oct 22, 2025 at 6:32 PM ben--- via NANOG <nanog@lists.nanog.org> wrote:
Hey all,
Ben, founder of IPinfo here. We care deeply about the quality and accuracy of our data, so I definitely want to get the issues flagged on this thread fixed.
The best way to submit geolocation feedback to us in general is via https://ipinfo.io/corrections.
By default we perform a lot of verification and filtering to geofeeds, and there's a surprising amount of adversarial data in geofeeds, from providers who are incentivised to pretend their IPs are in locations that they're not (mostly from proxy and vpn providers, and some hosting providers). It sounds like that creating problems for some operators though, and we'll look into how we can balance that.
Happy to jump on a call to discuss our data quality and approach to geolocation with anyone. And feel free to escalate any data quality issues you see directly to me over email too - ben@ipinfo.io
Thanks, Ben _______________________________________________ NANOG mailing list
https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/CO2TITVY...
Ben, Specifically to us, we found that some IPs come up as Troy, MI when we are in Troy, OH. I recognize the one in Ohio is a tiny town, but we still exist in this state! It was a short while ago a customer couldn't access some baseball thing (MLB?) because their service (our ticket did not specify how they were getting it - the customer just said it didn't work because of a location issue) said they were in the wrong state. We have a geofeed if you do a whois on the ip/block, I don't know if you're honoring it or not. To be frank, there's no way us or most any ISP is going to go through every single IP with a webform. Just look at the geofeed. For one customer or even many I would be unlikely to spend hours of my time fixing your service. You can look at 142.248.40.0/22 which was just allocated to us by ARIN a couple of weeks ago. You won't see much or any traffic in recent weeks. This is on our geofeed, however. On Wed, Oct 22, 2025 at 7:32 PM ben--- via NANOG <nanog@lists.nanog.org> wrote:
Hey all,
Ben, founder of IPinfo here. We care deeply about the quality and accuracy of our data, so I definitely want to get the issues flagged on this thread fixed.
The best way to submit geolocation feedback to us in general is via https://ipinfo.io/corrections.
By default we perform a lot of verification and filtering to geofeeds, and there's a surprising amount of adversarial data in geofeeds, from providers who are incentivised to pretend their IPs are in locations that they're not (mostly from proxy and vpn providers, and some hosting providers). It sounds like that creating problems for some operators though, and we'll look into how we can balance that.
Happy to jump on a call to discuss our data quality and approach to geolocation with anyone. And feel free to escalate any data quality issues you see directly to me over email too - ben@ipinfo.io
Thanks, Ben _______________________________________________ NANOG mailing list
https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/CO2TITVY...
On Wed, 22 Oct 2025, Mark Blackford via NANOG wrote:
Thank you Ben and Abdullah for joining the discussion. I understand the balance IPinfo has to make, but hopefully what I have explained to Abdullah on LinkedIn and your support team about the nature of hub and spoke EVPL/NNI networks, point to point IP assignments in /31 ranges, and automatic geofeeds from IPAM product like Netbox helps clarify how your probes do not paint the whole Geo IP picture.
For example from my support case, an IPinfo probe in Charlotte, NC sends data to my customer also Charlotte, but has to traverse Internet providers to first get to my network hub in Dallas, and then make the trip over my EVPL/NNI back to my end user in Charlotte who is the one that needs accurate Geo IP location for content providers. I am sure this ping time should be about twice the expected 25-30ms round trip latency expected.
Meanwhile, an IPinfo probe in Dallas pings the other end of the /31 with < 1ms latency, which is just on a gateway on a router with no users, and simply concludes I am lying in the geofeed, the /31 must be in Dallas and not Charlotte.
It sounds like your geofeed needs "higher resolution" if you want it to be honest about where the IPs are in use. Instead of the /31s, break those into /32s each at the appropriate location. Where I work currently, we've had quite a bit of difficulty both with stale IP Geo data on end-user systems and IP Geo providers with stale data for a former RIPE /16 $work purchased via a broker several years ago. Prior to this thread, I was unaware of ipinfo.io, and I was pleased to see on their website that they allow ISPs to "register" their geofeed...so I did that last night. I also did test lookups (another welcome feature not all IP Geo providers provide) and found that most of what I checked was correct, but not all. I got an email early this morning thanking me for sharing our feed. It'll be interesting to see if/how soon it corrects their incorrect data. At a previous job, $work had a VPN division, and I know VPN was popular for bypassing streaming service content restrictions based on IP Geo. We actually did have a global network, and so we had VPN servers all around the world. I can easily imagine a smaller VPN provider might lie in their geofeed to try to trick IP Geo providers in essentially saying the VPN provider has a wider footprint than they do (servers in countries where they're really not). I hope that doesn't keep them from trusting a broadband ISP's geofeed. We don't provide VPN (other than for staff to be able to work) and depend on accurate IP Geo data so that our customers get the right local channel lineups from streaming TV services and don't get blocked from websites that have decided to block access from "abroad". ---------------------------------------------------------------------- Jon Lewis, MCP :) | I route Blue Stream Fiber, Sr. Neteng | therefore you are _________ http://www.lewis.org/~jlewis/pgp for PGP public key_________
On Oct 23, 2025, at 10:13, Josh Luthman via NANOG <nanog@lists.nanog.org> wrote:
You can look at 142.248.40.0/22 which was just allocated to us by ARIN a couple of weeks ago.
Looking at that range via whois I am not seeing a Geofeed remark as specified in RFC 9632. If I was a geolocation provider I would 100% ignore an IP range listed in someone else’s feed unless the geofeed URL matches the entry specified in the whois database, in your current case there is none on that IP range. I’d highly recommend reading https://www.rfc-editor.org/rfc/rfc9632.html if you haven’t already and see if ARIN will fix your whois entry because right now they are returning the most specific entry at 142.0.0.0/8 rather than 142.248.40.0/22.
On Thu, 23 Oct 2025, Josh Luthman via NANOG wrote:
We have a geofeed if you do a whois on the ip/block, I don't know if you're honoring it or not. To be frank, there's no way us or most any ISP is going to go through every single IP with a webform. Just look at the geofeed. For one customer or even many I would be unlikely to spend hours of my time fixing your service.
https://ipinfo.io/corrections has a "Send us your Geofeed" section where you can give them the URL for your geofeed and a contact email for it. We also have our geofeed mentioned in the comments section of each of our ARIN networks. You would think that would be the "low hanging fruit" for IP Geo providers, but I don't know if ipinfo utilizes geofeeds mentioned in RIR registrationes. NetRange: 57.135.0.0 - 57.135.255.255 CIDR: 57.135.0.0/16 NetName: BSF-CUST-V401 NetHandle: NET-57-135-0-0-1 Parent: RIPE-ERX-57 (NET-57-0-0-0-1) NetType: Direct Allocation OriginAS: Organization: Blue Stream (BSCL-11) RegDate: 2022-03-28 Updated: 2024-10-30 Comment: Geofeed: https://geofeed.bluestreamfiber.net/ Ref: https://rdap.arin.net/registry/ip/57.135.0.0 ... ---------------------------------------------------------------------- Jon Lewis, MCP :) | I route Blue Stream Fiber, Sr. Neteng | therefore you are _________ http://www.lewis.org/~jlewis/pgp for PGP public key_________
Maybe our approach with MaxMind could be relevant here. We previously had major trust issues with them due to one problematic customer, so we changed how we manage our geolocation data. LARUS leases IPs to many types of customers. Some, like VPN or proxy providers, may submit false or unclear location data. Others—mainly regional ISPs and telecoms—serve real end users in fixed locations. To handle this, we divided our geolocation data into two separate geofeeds: - Trusted: Customers whose location data we have independently verified and are 100% confident about. - Normal: Customers whose claimed locations are passed through as-is, leaving MaxMind to decide how to handle them. We also told MaxMind that for the trusted data, any technical signal (e.g., ping latency) that doesn’t align should be considered inaccurate—not the data itself. This ensures high accuracy for home-user networks, while keeping strict control over which customers qualify for the trusted list. https://larus.net/ipv4/geofeed https://larus.net/geofeed-trusted -- Kind regards. Lu On Thu, Oct 23, 2025 at 15:26 Jon Lewis via NANOG <nanog@lists.nanog.org> wrote:
On Wed, 22 Oct 2025, Mark Blackford via NANOG wrote:
Thank you Ben and Abdullah for joining the discussion. I understand the balance IPinfo has to make, but hopefully what I have explained to Abdullah on LinkedIn and your support team about the nature of hub and spoke EVPL/NNI networks, point to point IP assignments in /31 ranges, and automatic geofeeds from IPAM product like Netbox helps clarify how your probes do not paint the whole Geo IP picture.
For example from my support case, an IPinfo probe in Charlotte, NC sends data to my customer also Charlotte, but has to traverse Internet providers to first get to my network hub in Dallas, and then make the trip over my EVPL/NNI back to my end user in Charlotte who is the one that needs accurate Geo IP location for content providers. I am sure this ping time should be about twice the expected 25-30ms round trip latency expected.
Meanwhile, an IPinfo probe in Dallas pings the other end of the /31 with < 1ms latency, which is just on a gateway on a router with no users, and simply concludes I am lying in the geofeed, the /31 must be in Dallas and not Charlotte.
It sounds like your geofeed needs "higher resolution" if you want it to be honest about where the IPs are in use. Instead of the /31s, break those into /32s each at the appropriate location.
Where I work currently, we've had quite a bit of difficulty both with stale IP Geo data on end-user systems and IP Geo providers with stale data for a former RIPE /16 $work purchased via a broker several years ago.
Prior to this thread, I was unaware of ipinfo.io, and I was pleased to see on their website that they allow ISPs to "register" their geofeed...so I did that last night. I also did test lookups (another welcome feature not all IP Geo providers provide) and found that most of what I checked was correct, but not all. I got an email early this morning thanking me for sharing our feed. It'll be interesting to see if/how soon it corrects their incorrect data.
At a previous job, $work had a VPN division, and I know VPN was popular for bypassing streaming service content restrictions based on IP Geo. We actually did have a global network, and so we had VPN servers all around the world. I can easily imagine a smaller VPN provider might lie in their geofeed to try to trick IP Geo providers in essentially saying the VPN provider has a wider footprint than they do (servers in countries where they're really not).
I hope that doesn't keep them from trusting a broadband ISP's geofeed. We don't provide VPN (other than for staff to be able to work) and depend on accurate IP Geo data so that our customers get the right local channel lineups from streaming TV services and don't get blocked from websites that have decided to block access from "abroad".
---------------------------------------------------------------------- Jon Lewis, MCP :) | I route Blue Stream Fiber, Sr. Neteng | therefore you are _________ http://www.lewis.org/~jlewis/pgp for PGP public key_________ _______________________________________________ NANOG mailing list
https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/ZUT2UKZ5...
Are you sure? # whois 142.248.40.1|grep -i cidr CIDR: 142.248.40.0/22 On Thu, Oct 23, 2025 at 10:31 AM Francis Booth <boothf@caramelfox.net> wrote:
On Oct 23, 2025, at 10:13, Josh Luthman via NANOG <nanog@lists.nanog.org> wrote:
You can look at 142.248.40.0/22 which was just allocated to us by ARIN a couple of weeks ago.
Looking at that range via whois I am not seeing a Geofeed remark as specified in RFC 9632.
If I was a geolocation provider I would 100% ignore an IP range listed in someone else’s feed unless the geofeed URL matches the entry specified in the whois database, in your current case there is none on that IP range.
I’d highly recommend reading https://www.rfc-editor.org/rfc/rfc9632.html if you haven’t already and see if ARIN will fix your whois entry because right now they are returning the most specific entry at 142.0.0.0/8 rather than 142.248.40.0/22.
On Thu, 23 Oct 2025, Francis Booth via NANOG wrote:
On Oct 23, 2025, at 10:13, Josh Luthman via NANOG <nanog@lists.nanog.org> wrote:
You can look at 142.248.40.0/22 which was just allocated to us by ARIN a couple of weeks ago.
Looking at that range via whois I am not seeing a Geofeed remark as specified in RFC 9632.
NetRange: 142.248.40.0 - 142.248.43.255 CIDR: 142.248.40.0/22 NetName: INXFIBER-02 NetHandle: NET-142-248-40-0-1 Parent: NET142 (NET-142-0-0-0-0) NetType: Direct Allocation OriginAS: Organization: Imagine Networks (INL-18) RegDate: 2025-10-10 Updated: 2025-10-10 Comment: Geofeed: https://inxfiber.com/geofeed/ ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Ref: https://rdap.arin.net/registry/ip/142.248.40.0 ... ---------------------------------------------------------------------- Jon Lewis, MCP :) | I route Blue Stream Fiber, Sr. Neteng | therefore you are _________ http://www.lewis.org/~jlewis/pgp for PGP public key_________
Hi Francis, I do not believe ARIN has the capability at present to comply with RFC 9632. At least, I'm not seeing where I can set a geofeed attribute in my portal. Perhaps I am wrong though? 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. If you find a spelling or grammatical error, you may keep it.
Hi Ben, I too would like to see this. Everybody knows IP geolocation is not a trivial task and is rife with inaccuracies. If such a presentation were made, it would allow us poor operators a valuable insight into the minefield which is geolocation and might even help some of us avoid some of the more common pitfalls. Just food for thought... 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. If you find a spelling or grammatical error, you may keep it.
Ah looks like a problem with MacOS’s whois utility when running "whois 142.248.40.0/22”. I just tried on another machine running Linux and the entry returned correctly this time. I see your Geofeed remark and that definitely looks correct and UTF-8 so that all looks good. Thanks for the catch! I use that tool almost daily and this is the first time I’ve seen it not work properly. Sorry for the confusion.
On Oct 23, 2025, at 10:46, Josh Luthman <josh@imaginenetworksllc.com> wrote:
Are you sure?
# whois 142.248.40.1|grep -i cidr CIDR: 142.248.40.0/22 <http://142.248.40.0/22> On Thu, Oct 23, 2025 at 10:31 AM Francis Booth <boothf@caramelfox.net <mailto:boothf@caramelfox.net>> wrote:
On Oct 23, 2025, at 10:13, Josh Luthman via NANOG <nanog@lists.nanog.org <mailto:nanog@lists.nanog.org>> wrote:
You can look at 142.248.40.0/22 <http://142.248.40.0/22> which was just allocated to us by ARIN a couple of weeks ago.
Looking at that range via whois I am not seeing a Geofeed remark as specified in RFC 9632.
If I was a geolocation provider I would 100% ignore an IP range listed in someone else’s feed unless the geofeed URL matches the entry specified in the whois database, in your current case there is none on that IP range.
I’d highly recommend reading https://www.rfc-editor.org/rfc/rfc9632.html if you haven’t already and see if ARIN will fix your whois entry because right now they are returning the most specific entry at 142.0.0.0/8 <http://142.0.0.0/8> rather than 142.248.40.0/22 <http://142.248.40.0/22>.
*shrug* works for every other provider, Google, etc... On Thu, Oct 23, 2025 at 10:50 AM Jon Lewis via NANOG <nanog@lists.nanog.org> wrote:
On Thu, 23 Oct 2025, Francis Booth via NANOG wrote:
On Oct 23, 2025, at 10:13, Josh Luthman via NANOG <
nanog@lists.nanog.org> wrote:
You can look at 142.248.40.0/22 which was just allocated to us by ARIN
a
couple of weeks ago.
Looking at that range via whois I am not seeing a Geofeed remark as specified in RFC 9632.
NetRange: 142.248.40.0 - 142.248.43.255 CIDR: 142.248.40.0/22 NetName: INXFIBER-02 NetHandle: NET-142-248-40-0-1 Parent: NET142 (NET-142-0-0-0-0) NetType: Direct Allocation OriginAS: Organization: Imagine Networks (INL-18) RegDate: 2025-10-10 Updated: 2025-10-10 Comment: Geofeed: https://inxfiber.com/geofeed/ ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Ref: https://rdap.arin.net/registry/ip/142.248.40.0 ...
---------------------------------------------------------------------- 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/QAWTXAU4...
On Thu, Oct 23, 2025 at 10:48:28AM -0400, Jon Lewis via NANOG wrote:
On Thu, 23 Oct 2025, Francis Booth via NANOG wrote:
On Oct 23, 2025, at 10:13, Josh Luthman via NANOG <nanog@lists.nanog.org> wrote:
You can look at 142.248.40.0/22 which was just allocated to us by ARIN a couple of weeks ago.
Looking at that range via whois I am not seeing a Geofeed remark as specified in RFC 9632.
NetRange: 142.248.40.0 - 142.248.43.255 CIDR: 142.248.40.0/22 NetName: INXFIBER-02 NetHandle: NET-142-248-40-0-1 Parent: NET142 (NET-142-0-0-0-0) NetType: Direct Allocation OriginAS: Organization: Imagine Networks (INL-18) RegDate: 2025-10-10 Updated: 2025-10-10 Comment: Geofeed: https://inxfiber.com/geofeed/ ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Ref: https://rdap.arin.net/registry/ip/142.248.40.0
If I'm reading RFC 9632 section 3 correctly, that ':' between 'Geofeed' and 'https://inxfiber..' should not be there. DO THIS: Comment: Geofeed https://inxfiber.com/geofeed/ NOT THIS: Comment: Geofeed: https://inxfiber.com/geofeed/ I have no idea if omitting the colon will make a material difference to the case at hand, I just wanted to point out this syntax issue. Kind regards, Job
On Thu, 23 Oct 2025, Job Snijders wrote:
Comment: Geofeed: https://inxfiber.com/geofeed/ ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Ref: https://rdap.arin.net/registry/ip/142.248.40.0
If I'm reading RFC 9632 section 3 correctly, that ':' between 'Geofeed' and 'https://inxfiber..' should not be there.
DO THIS:
Comment: Geofeed https://inxfiber.com/geofeed/
NOT THIS:
Comment: Geofeed: https://inxfiber.com/geofeed/
I have no idea if omitting the colon will make a material difference to the case at hand, I just wanted to point out this syntax issue.
This seems to be a common "error" in formatting. I see I did the same thing...and am about to update all our records. :( ---------------------------------------------------------------------- Jon Lewis, MCP :) | I route Blue Stream Fiber, Sr. Neteng | therefore you are _________ http://www.lewis.org/~jlewis/pgp for PGP public key_________
Hi Jon, Thanks for weighing in. I asked about using /32 in the beginning of the post, but in the essence of why location matters, the /32 end in say Dallas is a gateway router and the /32 end in Charlotte is where the proverbial eyeballs are. Do we really need to be that granular to the host level for a router that will not make any CDN requests? A /31 seems close enough for all intents and purposes. I think following the geofeed RFCs should be sufficient, but at this point, I just need my customers to be able to watch NFL and MLB games they should be able to watch. However, as is the crux of this post, IPinfo ignores geofeeds when their probe ping times do not align. In their current setup, let's say I assigned a /32 as Charlotte in my geofeed today, the ping time of an IPinfo Charlotte probe is still way off from what they expect. They expect < 1ms if the /32 is truly in Charlotte but get 50ms and that "noise" just kicks it out. Their current solution offered to me is for me to host a probe at every customer site is not feasible. So while I agree that if we are splitting hairs, a /32 makes for a more granular location, it does not solve the problem that IPinfo has bad data solely due to basing geolocation on ping times. And the current IPinfo stance boasted about on their website is that when an ISPs geofeed doesn't align with their probe system, it must be wrong because their assumption is that all ISPs are liars. I am hopeful Ben and Abdullah will come to a solution on the matter very soon. The NFL season is ticking away. Mark On Thu, Oct 23, 2025 at 9:25 AM Jon Lewis <jlewis@lewis.org> wrote:
On Wed, 22 Oct 2025, Mark Blackford via NANOG wrote:
Thank you Ben and Abdullah for joining the discussion. I understand the balance IPinfo has to make, but hopefully what I have explained to Abdullah on LinkedIn and your support team about the nature of hub and spoke EVPL/NNI networks, point to point IP assignments in /31 ranges, and automatic geofeeds from IPAM product like Netbox helps clarify how your probes do not paint the whole Geo IP picture.
For example from my support case, an IPinfo probe in Charlotte, NC sends data to my customer also Charlotte, but has to traverse Internet providers to first get to my network hub in Dallas, and then make the trip over my EVPL/NNI back to my end user in Charlotte who is the one that needs accurate Geo IP location for content providers. I am sure this ping time should be about twice the expected 25-30ms round trip latency expected.
Meanwhile, an IPinfo probe in Dallas pings the other end of the /31 with < 1ms latency, which is just on a gateway on a router with no users, and simply concludes I am lying in the geofeed, the /31 must be in Dallas and not Charlotte.
It sounds like your geofeed needs "higher resolution" if you want it to be honest about where the IPs are in use. Instead of the /31s, break those into /32s each at the appropriate location.
Where I work currently, we've had quite a bit of difficulty both with stale IP Geo data on end-user systems and IP Geo providers with stale data for a former RIPE /16 $work purchased via a broker several years ago.
Prior to this thread, I was unaware of ipinfo.io, and I was pleased to see on their website that they allow ISPs to "register" their geofeed...so I did that last night. I also did test lookups (another welcome feature not all IP Geo providers provide) and found that most of what I checked was correct, but not all. I got an email early this morning thanking me for sharing our feed. It'll be interesting to see if/how soon it corrects their incorrect data.
At a previous job, $work had a VPN division, and I know VPN was popular for bypassing streaming service content restrictions based on IP Geo. We actually did have a global network, and so we had VPN servers all around the world. I can easily imagine a smaller VPN provider might lie in their geofeed to try to trick IP Geo providers in essentially saying the VPN provider has a wider footprint than they do (servers in countries where they're really not).
I hope that doesn't keep them from trusting a broadband ISP's geofeed. We don't provide VPN (other than for staff to be able to work) and depend on accurate IP Geo data so that our customers get the right local channel lineups from streaming TV services and don't get blocked from websites that have decided to block access from "abroad".
---------------------------------------------------------------------- Jon Lewis, MCP :) | I route Blue Stream Fiber, Sr. Neteng | therefore you are _________ http://www.lewis.org/~jlewis/pgp for PGP public key_________
Hi John, Thank you for the idea. We have a research program and regularly present at NOG conferences. Ben, our founder, flagged this to Oliver Gasser, our head of research. We will reach out to ARIN and NANOG soon. Thank you. — Abdullah | DevRel, IPinfo
Hi Josh, I connected via LinkedIn with you. Currently, for you all your IPs (AS35860 and 142.248.40.0/22), we locate them to Troy, Ohio. Please see the results here: https://ipinfo.io/tools/summarize-ips/6fbbb955-0fa2-471f-9e69-66a2be55d915 If there are any issues, please flag them for our support team so they can investigate. They have the right tools. --- Well, the issue with MLB is that they are not our customers (as far as I know). They use a service that is quite poor at geolocation. People often come to us asking how we can assist them, but our hands are tied. It would be nice if MLBtv and MLB used our data. I am extremely active in social media and online forums. Our forum presence is very good, and we actively work with end users. Your customers will come to us before they go to their ISP. For example in all Cloudflare's IP geolocation discussion, you will see a comment from me: https://community.cloudflare.com/search?q=ipinfo%20order%3Alatest Again. Ping me if you have any questions. Thank you. — Abdullah | DevRel, IPinfo
Hi Jon, Thank you for checking us out. It would be incredible if you could give some advice so we can establish a presence in the ISP community. I thought we were quite popular because we processed around 2 trillion requests last year. However, I believe I was tunnel-visioned. So, any advice you can provide on helping us reach out to ISPs, particularly smaller ISPs, would be greatly appreciated. In terms of registering your geofeed, it is likely that we are already ingesting your geofeed, considering the size of your ISP. I appreciate you submitting it.
I also did test lookups (another welcome feature not all IP Geo providers provide) and found that most of what I checked was correct, but not all.
I will flag this to the team. Your ASN has more than 200,000 IPs. Now, we need to investigate this carefully. As we conduct active measurements, our data is not going to match 1:1 to your geofeed. But if there is room for improvement, we will find it. Thank you. — Abdullah | DevRel, IPinfo
As we conduct active measurements, our data is not going to match 1:1 to your geofeed. But if there is room for improvement, we will find it.
It seems from a cursory glance that you guys are using RTT to IPs as your primary signal for location. Is that accurate? On Thu, Oct 23, 2025 at 1:26 PM devrel.ipinfo--- via NANOG < nanog@lists.nanog.org> wrote:
Hi Jon,
Thank you for checking us out. It would be incredible if you could give some advice so we can establish a presence in the ISP community.
I thought we were quite popular because we processed around 2 trillion requests last year. However, I believe I was tunnel-visioned. So, any advice you can provide on helping us reach out to ISPs, particularly smaller ISPs, would be greatly appreciated.
In terms of registering your geofeed, it is likely that we are already ingesting your geofeed, considering the size of your ISP. I appreciate you submitting it.
I also did test lookups (another welcome feature not all IP Geo providers provide) and found that most of what I checked was correct, but not all.
I will flag this to the team. Your ASN has more than 200,000 IPs. Now, we need to investigate this carefully. As we conduct active measurements, our data is not going to match 1:1 to your geofeed. But if there is room for improvement, we will find it.
Thank you.
— Abdullah | DevRel, IPinfo _______________________________________________ NANOG mailing list
https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/HVDVZE6X...
Hi Tom, We use a combination of ping, traceroute, and other network diagnostic measurements from the servers. For each IP address, we take internet measurements for it across multiple different servers. — Abdullah | DevRel, IPinfo
On 23/10/2025 17:54, Michael Greenup via NANOG wrote: If you are looking for accurate geolocation, without "fibbing", why not purchase a service like: https://yandex.com/maps-api/products/locator [maybe there are others?] which uses Wifi and cell tower triangulation? No idea how accurate it is - have never tried it. Not a recommendation for use - just posting another possible avenue for geolocation. -Hank
Hi Ben,
I too would like to see this. Everybody knows IP geolocation is not a trivial task and is rife with inaccuracies. If such a presentation were made, it would allow us poor operators a valuable insight into the minefield which is geolocation and might even help some of us avoid some of the more common pitfalls.
Just food for thought...
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. If you find a spelling or grammatical error, you may keep it. _______________________________________________ NANOG mailing list https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/YRJMIKOE...
Mike's suggestion of reaching out via LinkedIn has proven to be a winner in this case, but I think only because IPinfo really cared about this problem. I have not seen the level of responsiveness by IPinfo has done here in quite a while. Yes, I was snarky and defiant in my first LinkedIn posts in my anger at not getting this resolved by IPinfo's online correction forms, but Ben and Abdullah's engagement by actually listening to the data I presented has not only fixed my issue, but hopefully will benefit other EVPL/NNI providers soon. So, kudos to IPinfo for listening and being open to change. As of yesterday afternoon, my geofeed data is active in their DBs, and I am in the "pending verification" state with our customers. I just want to say thank you to everyone who responded and engaged here to help a desperate operator out. Mark On Tue, Oct 21, 2025 at 10:10 PM Mike Lyon <mike.lyon@gmail.com> wrote:
Lookup their execs on LinkedIN (Ben Dowling) and send them messages letting them know how much their support sucks. Continue to do that until you get a resolution.
I have found that doing this works with companies where i can’t get resolution elsewhere.
Good luck!
-Mike
On Oct 21, 2025, at 19:42, Mark Blackford via NANOG < nanog@lists.nanog.org> wrote:
Hi Josh,
Thanks for the reply. I should have mentioned that I have been feeding them manual corrections and opening support tickets the past few days, but they pride themselves on ignoring ISPs in favor of their own probes and ping times. I'm at a total loss at what to do since IPinfo ignores the geofeed, ignores all the other providers that are correct, and takes pride in being wrong because they ping the wrong end.
I was hoping another point to point provider has had success in getting their data corrected with IPinfo. It's odd to me how IPinfo can be highly recommended by developers on this list, but their data is so far off. I can see how their method would work for an enterprise, BNG or cable provider, but not at all for an NNI ISP provider.
Thanks again, Mark Blackford
On Tue, Oct 21, 2025 at 9:16 PM Josh Luthman < josh@imaginenetworksllc.com> wrote:
If your issue is only with IPinfo, you should try to reach out to them. I'll say I've seen that name come up recently and they've had some pretty bad data/poor customer experiences.
On Tue, Oct 21, 2025 at 8:24 PM Mark Blackford via NANOG < nanog@lists.nanog.org> wrote:
Greetings,
Does anyone have any suggestions on how to get IPinfo to properly report Geolocation for NNI pint to point type circuits? I have a geofeed that they are ignoring, but I have two prevailing theories.
One - someone put our entire ARIN aggregate in it last month and now it overlaps everything in the feed. I read that overlapping prefixes cause confusion. I took it out of the feed today, but IPinfo is so secretive I have no idea if they will remove it.
Two, and the more likely theory based on their boast on how they beat the competitor by thousands of miles, is they are reporting on the wrong end based on their ping scans. They ping the hub end of a /31 and disregard the other end that is usually two to three states away. Therefore , they are the ones horrible off an their competitors are spot on.
Should I not be reporting the point to point /31 and only use he customer /32 end?
Any other advice in properly identifying the location for Ipinfo would be awesome. All the other providers seem to properly follow my geofeed, and I have no issues with them.
Thank you very much, Mark Blackford _______________________________________________ NANOG mailing list
https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/5FNHPXSU...
_______________________________________________ NANOG mailing list
https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/G3AA2MLF...
Hi Mark and everyone here, I genuinely appreciate your patience and eagerness to work with us. Thank you very much. We have identified a couple of issues that have triggered an engineering effort to fix. We want to work with every single ISP. EVERY SINGLE ISP, regardless of size or operation. I am trying to figure out how to do the outreach. Our approach of doing verification based on active measurement is not going to change significantly; at the same time, I need to work with all ISPs across NANOG (and the world) to identify how to provide great service and great data to everyone. We are aiming for one hundred percent accuracy, and we will not compromise at all. All ISPs need to be happy with our data. Our founder, engineering, and research team are planning to do presentations, publish research and attend conferences at ARIN and NANOG and to meet you folks in person. At the same time, please REACH OUT TO ME on LinkedIn. I prefer LinkedIn over emails because I have the communication history, and I can keep up with every change you make for your network. You do not have to sift through your inbox to reach out to me. https://www.linkedin.com/in/reincoder/ We also have our community platform, but it is mostly for our users to ask about services. https://community.ipinfo.io/ In terms of our probe network, we are continually looking to expand it. If you can, or know someone who can, help host a probe server in a city where we currently do not have one, it would be greatly appreciated. https://ipinfo.io/probe-network Again, thank you for your patience. Please reach out to me anytime. — Abdullah | DevRel, IPinfo
participants (13)
-
ben＠ipinfo.io -
devrel.ipinfo＠gmail.com -
Francis Booth -
Hank Nussbacher -
Job Snijders -
John Curran -
Jon Lewis -
Josh Luthman -
Lu Heng -
Mark Blackford -
Michael Greenup -
Mike Lyon -
Tom Beecher