Hi,

thank you for notifying us about this.

The reason why we display "US" for these prefixes is the database situation at ARIN: That RIR only publishes a so-called "delegated-extended-latest" file, which is intended for statistical purposes, and lacks accuracy when it comes to the geographic allocation of suballocated networks.

Unfortunately, there is no better data available for free, and ARIN's ToS forbid derivative work from their _actual_ database, which would be available upon request.

This is why IPFire Location lacks accuracy on countries served by ARIN, and such manual corrections are necessary.

I just have one minor question: Where did you get "AS536679" from? According to a Whois query, that AS is not allocated.

Thanks, and best regards,
Peter Müller

Sorry [AS536679] was a typo on german keyboard.
9 and ] are on one button.

Should be:
[AS53667] IPv6 Country: Luxembourg City: Roost

Hi,

thanks for your reply.

Deduplicated, the IP ranges in question are:

104.244.72.0/21
107.189.0.0/21
107.189.8.0/22
107.189.12.0/23
107.189.14.0/24
107.189.30.0/23

2605:6400:3::/48
2605:6400:30::/48
2605:6400:300::/48
2605:6400:c000::/34

While I am completely fine with the IPv4 networks (they either have "LU" as country code set or trace back to Luxembourg with a very high level of confidence), how do you reach the conclusion of the IPv6 networks?

ARIN only contains a single object for the entire /28, and I was unable to find anything regarding the IP allocation on BuyVM's website.

As soon as this question is solved, I will prepare a patch to fix these.

Thanks, and best regards,
Peter Müller

I have my own KVM's at Frantech/BuyVM in Las Vegas and Luxembourg. In Luxembourg all my IPv6 are from the 2605:6400:30::/48 range.
For example 2605:6400:30:f78b::2, 2605:6400:30:f78b::2, 2605:6400:30:f503::1

Because of the others I submitted a support ticket to Francisco and his staff. I'll report when I have an answer.

My question in the ticket with a link to this bug report:

8<
Can you help me with the IPv6?
OK 2605:6400:30::/48 is clear. All my Luxembourg KVM are in this IP range.

Are these IPs in Luxembourg too?

2605:6400:3::/48
2605:6400:300::/48
2605:6400:c000::/34
>8

Got response from Francisco (Owner, Frantech Inc.):

"Yes those are all in LUX and should be marked as such in our geofeed."

I found 2 current databases to check:
2605:6400:3:: 2605:6400:30:: 2605:6400:300:: 2605:6400:c000::

https://ipgeolocation.io
https://www.maxmind.com/en/geoip2-precision-demo
Maxmind has these prefixes:
2605:6400:3::/48
2605:6400:30::/49
2605:6400:300::/48
2605:6400:c000::/37

The current bgp routes for this are a bit different:
https://bgp.he.net/AS53667#_prefixes6

https://git.ipfire.org/?p=location/location-database.git;a=commit;h=14c804a97b3aa0af163e0b1d8e1a5a94e9fed337

Thank you for reporting back. I just commited the necessary overrides - any database generated tomorrow or after should display these networks correctly in LU.

OK thanks.

I just got an updated list. There are a few more IPv4 ranges in LUX
https://frantech.ca/geofeed.csv

Sorry for the confuse.

Thanks, three missing IPv4 ranges have been added: https://git.ipfire.org/?p=location/location-database.git;a=commit;h=6bb76288d4b153aeb6683f1cf3e182777e4a4498

These changes should be live tomorrow. I will close this ticket then.

Wow, thank you very much. That was damn fast. The changes are already in Tor Metrics. :-)

>  The changes are already in Tor Metrics.

Unless they use a different data source in addition and/or compile their
own location database (more often than we at IPFire do), I would be puzzled
to see this. (Time travel would be an option as well... :-)

The overrides I commited today _cannot_ be visible in the output of an
IPFire Location database query until tomorrow morning.

Or were you referring to the overrides I made earlier? In this case, it
is pretty likely that they show up in Tor Metrics - which would mean they
update the database on a regular basis (last time I checked they didn't).
Yay. :-)

Yes, I meant the first overrides. A few days ago there were 16 relays in Luxembourg and now, nearly 200 corrected:
https://metrics.torproject.org/rs.html#search/country:lu%20
Tor Metrics update command for local DB runs daily.

> Tor Metrics update command for local DB runs daily.

Glad to hear that. :-)

Closing this as being fixed then. Please do not hesitate to file a new ticket, should you encounter any inaccuracies in IPFire Location in the future.

All the best,
Peter Müller