Geolocation with IPv6?

问题:

I'm working on an IP geolocation library that uses the first three octets of an IPv4 address to determine a user's country, city, lat, lon, etc. Works like a charm.

But it doesn't handle IPv6 addresses, and I'd like it to do so.

Is there any way to transform an IPv6 address to get the equivalent of the first three octets of an IPv4 address, or are they on an entirely different numbering scheme, requiring a completely different ipgeo mapping?

回答1:

The typical IPv6 allocation is a /32 (four octets) to an Internet provider (which can be a multinational company), then /48 (six octets) to an end site (typically a client organization). You can get a starting point in the IANA list of delegated blocks.

This is only for registrations found in the databases of the RIR. Assignment to end users is typically not recorded so, my current address, 2a01:e35:8bd9:8bb0:92b:8628:5ca5:5f2b will tell you only that my provider's headquarters are in Paris (since it is a national company, the clients can be anywhere in France).

Another exception is the PI (Provider-Independent) assignements, which are typically /48.

Also, there exists many databases of geolocation for IPv4 and, to my knowledge, none for IPv6. You will have to do everything yourself.

To summary: more work than you apparently believe.

回答2:

Friendly correction to Noah's comment (Jun 3 at 7:57)--

Per MaxMind's client services department (emphasis mine): "IPv6 is currently NOT supported. At some time in the future, we do plan to implement it but we do not have a date at this time."

回答3:

IPv6 uses a completely different addressing scheme compared to IPv4. There is no way you can map IPv6 addresses to IPv4 addresses, with one exception. If you see IPv6 addresses that start with 2002: then the address is a 6to4 address. You won't see a lot of those in use probably and they are being deprecated, but those are mappable to IPv4.

Each user of a public IPv4 address can use a /48 (65536 subnets) of IPv6 space. Those addresses always begin with 2002: and the next two hexadecimal numbers are the IPv4 address. So 2002:5389:1164: corresponds to my own webserver's IPv4 address (83.137.17.100):

0x53 = 83
0x89 = 137
0x11 = 17
0x64 = 100

But all 'normal' IPv6 addresses are completely unrelated to any IPv4 addresses. At least in a standard way. An ISP could define a relationship between IPv4 and IPv6 addresses when rolling out IPv6 to its customers. But you won't know about that relationship so it will be useless to you...

回答4:

maxmind.com's geolocation services and libraries handle IPv6 OK. Maybe their stuff is an option for you. (I don't have any affiliation with them.)

回答5:

Since there does not appear to be an easy way to do this yet, perhaps we get the opportunity to do something that wasn't done in the case of IPv4 (*)

We could stop and ask ourselves whether this is a good idea.

---

(*) Or if it was done, it didn't work!

回答6:

geolocation is bad, mmkay? the internet is location-agnostic, and i have never seen geolocation used for something non-trivial-non-evil. that is, the only good applications i've seen (language selection) were trivial (could just as easily be a dropdown). many evil applications exist (this video not available in your country, targeting my physical location for ads and tracking) we can't discourage something like this from existing, but we should push to make it illegal or at least socially unacceptable to use.

回答7:

If you read a number of ipv6, address and transition mechanism on wiki, you will find a few IPv6 addresses patterns that may infer an ipv4 (siit, ipv4-mapped ipv6, nat64, the 2002:* thing written above, etc.). One of them to start: http://en.wikipedia.org/wiki/IPv6_transition_mechanisms

I would not count on these schemes to be popular enough to do the usual geo reports, fraud protection, or incident detection, but I would definitely give precedence to an ipv4 geo lookup for such inferred ipv4 addresses over an ipv6 geo lookup (assuming the ipv4 db is more complete).

My concern with ipv6 geo information is the incredibly large number of subnets. Databases will get larger (more ip ranges), that is expected but for the same amount of terminal geo information, the databases will be sparser and the deeper tree is also longer to iterate (for implementation that uses binary or radix trees) which implies some performance cost. Geo databases using sql tables with ip ranges will probably also suffer, since we don't have big-bigint of 128bits, that I know of, to use arithmetic.

Another concern is the mobiles: ipv6 is designed to facilitate roaming, if I am not mistaking. You could change cell towers and keep your IP. maybe even while changing city, region or country. I somewhat doubt that since that a strong address affinity was the purpose of a MAC address. Ip addresses exist precisely for routing purpose, but I think it is fair to mention they could become invariant enough to cripple the accuracy of geo location, obviously.

I feel the collaboration of user agents/browsers at the application layer (some geo location header for example) is likely the future, even if this can be spoofed by mischievous people.

回答8:

There is a protocol called Referral Whois which allows providers to publish IP geolocation information and others to retrieve it.

For example, my current IP 2001:470:b4ea:babe:d57:15c8:97b:60c9 belongs to Hurricane Electric in the US. The actual server where the IPv4-IPv6 tunnel I use terminates is in Switzerland, but I am in Austria. HE publishes all of this, so if you enter the IP in a tool supporting RWhois like this, you will find the contact data of HE and somwhere near the bottom you see

contact:Name:Private Customer - Hurricane Electric

contact:Street-Address:Private Residence

contact:Country-Code:AT

which is my location.

Not many providers do publish that, and not many geolocation tools support it, but at least it exists.

Most of the IP geolocation providers (of those who support IPv6, some still don't) put this IP to Switzerland, some even in the US.