Print

[kamil445]

Hi,

Since 3-4 days geolocation is wrong for "2001:470:71:447::/64".

3-4 days ago bgp.he.net says geoloc "89-650Czersk / Pomorskie / Poland".
Now is USA and i can't access sites restricted only for Poland IP's

Code: [Select]

contact:Street-Address:760 Mission Ct
contact:City:Fremont
contact:Province:CA
contact:Postal-Code:94539
contact:Country-Code:US
Please, if possible restore previous record.

Thanks!

[jwinius]

My network may have had the same problem for the past few days. Here in the Netherlands, my tunnel suddenly stopped working late Wednesday evening, However, late this afternoon it started again just as mysteriously. I was fairly certain the problem was with HE. Damned irritating!

[tjeske]

Also my prefix that was correctly attributed to Germany (using Berlin tunnel endpoint) is now showing Fremont, CA as location.

[broquea]

Looks like our rwhois wasn't responding correctly. It should be now, so ideally all those 3rd party systems that make up their databases, update.

[kamil445]

Again geolocation is wrong since maybe 6-7 days

[altadenamd]

One of my blocks is missing from rwhois (the other 3 main ones are fine; both /64s are fine)..  The look at this was prompted by ARIN wanting to cancel my HE contact (I assume that this is because the rwhois is considered working...)
The blocks are all properly routed (I'm using the missing one for this message).  As far as geolocation goes, I've had good luck using maxmind's web portal to correct things (the missing block gets assigned to hong kong fairly often for some reason)  Still wish that either (or both) of Verizon and Charter/Spectrum would turn up V6 for customers; both of them have dual-stack core (and Spectrum provides V6 just fine in former RR areas, just not Charter...)  (and VZW LTE is all V6, like TMobile pioneered..  VZ FIOS isn't VZW, though.)

[snarked]

Geolocation databases are THIRD party data.  HE has little control.

[kamil445]

Yes, i know that, but sites protected via cloudflare think i'm from US, not PL.
When geolocation been correct, like this (screenshot from bgp.he.net):

https://i.imgur.com/rmgRYgH.png

All worked good.

And now is

https://i.imgur.com/WrymSvn.png

Looks like routed /64 is wrongly geolocated or geolocation for routed /64 is missing (missing
network:ID;I:NET-2001:470:71:447:/64 from bgp.he.net output)

Please fix this if possible.
Thanks.

[kcochran]

Geolocation providers don't usually rely on administrative database such as WHOIS, but their own internal heuristics.  Thus, they're often less accurate than they would like to claim.  This is especially true on tunnels, as a number of factors of simply being a tunnel can complicate many of the common items used in such heuristics, such as latency, paths, etc.  Each provider uses their own mechanisms, and while some have correction forms, many do not, and with no single clearing house or "source of truth" for geolocation data.  There are some specifications for an ISP to be able to self-publish geoIP data, but that's not supported by many content providers as their content creators often define specific geolocation vendors they must use, or believe the IP locations may be 'adjusted' to avoid geoblocks.  As such, this isn't a situation likely to be simplified anytime soon.

[kamil445]

Thank you for reply,

So, there is no chance to change these values in rwhois ?

This really worked for cloudflare for example, so maybe cloudflare or cloudflare geolocation service respective these values.

Now workaround is to disable tunnel or use hosts to force domains to use ipv4 instead of ipv6.

[kcochran]

The information in rWHOIS looks correct for your information.

[kamil445]

Yes, looks like wrong data is because my fault

[kamil445]

If anynone want to correct geolocation, here is list with contact information to most popular geolocation providers

Google => https://support.google.com/websearch/workflow/9308722?hl=en
DB-IP.com => https://db-ip.com/__YOUR_IP__
MaxMind => https://support.maxmind.com/geoip-data-correction-request/
ipapi.co => https://ipapi.co/contact/
ip2location.com => support@ip2location.com
ipinfo.io => https://ipinfo.io/contact
ipgeolocation.io => https://ipgeolocation.io/contact.html
ipregistry.co => support@ipregistry.co
ipdata.co => https://ipdata.co/corrections.html
iphub.info => https://iphub.info/contact?ip=__YOUR_IP__&block=2
ipip.net => support@ipip.net
neustar => https://www.home.neustar/resources/tools/submit-to-global-ip-database
whoisxmlapi => service.desk@whoisxmlapi.com

[brianjmurrell]

Funny this topic should come up.

Geolocation providers don't usually rely on administrative database such as WHOIS, but their own internal heuristics.

Indeed.  I talked to somebody at MaxMind just the other day and he said they are prohibited from using ARIN (i.e. whois) data.

What he did say influences their location accuracy though are geofeeds.

Not entirely sure how they work, but the interesting question is whether HE is publishing such.  It seems there is no central exchange where publishers and consumers can meet to exchange data though, but rather it's point-to-point.  I.e. every IP provider has to contact every geolocation service to set up geofeed publishing.  That doesn't really scale.  :-(

[divad27182]

I believe that at least some geolocation information comes from shopping sites.  Your shipping address, or at least the town, and your IP address may get shared.

I think at one point my IP address got moved to the neighboring town because I ordered something for delivery to my father's house.