使用 IPv6 进行地理定位?
我正在开发一个 IP 地理定位库,它使用 IPv4 地址的前三个八位字节来确定用户的国家/地区、城市、纬度、经度等。效果非常好。
但它不处理 IPv6 地址,我希望它能够处理。
有没有办法转换 IPv6 地址以获得 IPv4 地址的前三个八位字节的等效值,或者它们是否采用完全不同的编号方案,需要完全不同的 ipgeo 映射?
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?
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(8)
典型的 IPv6 分配 是互联网的 /32(四个八位字节)
提供商(可以是跨国公司),然后 /48(六个八位字节)
到最终站点(通常是客户组织)。 你可以获得一个
IANA 授权块列表中的起点。
这仅适用于
在 RIR 数据库中找到的注册。 分配到结束
用户通常不会被记录,所以我当前的地址,
2a01:e35:8bd9:8bb0:92b:8628:5ca5:5f2b
只会告诉你我的提供商的总部位于巴黎(因为它是一家全国性公司,
客户可以在法国的任何地方)。
另一个例外是 PI(独立于提供商)分配,它
通常为 /48。
此外,存在许多 IPv4 地理定位数据库,对我来说
知识,没有关于 IPv6 的知识。 你必须自己做所有事情。
总结一下:工作量比你想象的还要多。
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 myprovider'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.
对 Noah 评论的友好更正(6 月 3 日 7:57)——
MaxMind 的客户服务部门(强调我的):“目前不支持 IPv6。在未来的某个时候,我们确实计划实施它,但我们没有就在这个时候约会。”
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."
与 IPv4 相比,IPv6 使用完全不同的寻址方案。 没有任何方法可以将 IPv6 地址映射到 IPv4 地址,但有一个例外。 如果您看到以 2002: 开头的 IPv6 地址,则该地址是 6to4 地址。 您可能不会看到其中很多在使用中,并且它们已被弃用,但它们可映射到 IPv4。
公共 IPv4 地址的每个用户都可以使用 IPv6 空间的 /48(65536 个子网)。 这些地址始终以 2002: 开头,接下来的两个十六进制数字是 IPv4 地址。 所以 2002:5389:1164: 对应于我自己的网络服务器的 IPv4 地址 (83.137.17.100):
但是所有“正常”IPv6 地址与任何 IPv4 地址完全无关。 至少以标准方式。 ISP 在向其客户推出 IPv6 时可以定义 IPv4 和 IPv6 地址之间的关系。 但你不会知道这种关系,所以它对你来说毫无用处......
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):
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...
maxmind.com 的地理定位服务和库可以正常处理 IPv6。 也许他们的东西适合你。 (我和他们没有任何关系。)
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.)
如果您在 wiki 上阅读了大量的 ipv6、地址和转换机制,您会发现一些可以推断 ipv4 的 IPv6 地址模式(siit、ipv4 映射的 ipv6、nat64、上面写的 2002:* 等)。 其中之一开始:
http://en.wikipedia.org/wiki/IPv6_transition_mechanisms
我不会指望这些方案足够流行来进行通常的地理报告、欺诈保护或事件检测,但我肯定会优先考虑对此类推断的 ipv4 地址进行 ipv4 地理查找,而不是 ipv6 地理查找(假设 ipv4 数据库更完整)。
我对 IPv6 地理信息的担忧是子网数量惊人。 数据库将变得更大(更多的 ip 范围),这是预期的,但对于相同数量的终端地理信息,数据库将变得更稀疏,并且更深的树迭代也更长(对于使用二叉树或基数树的实现),这意味着一些性能成本。 使用具有 ip 范围的 sql 表的地理数据库可能也会受到影响,因为据我所知,我们没有 128 位的 big-bigint 来使用算术。
另一个问题是手机:如果我没记错的话,ipv6 的设计目的是为了方便漫游。 您可以更换手机信号塔并保留您的 IP。 甚至可能在改变城市、地区或国家时。 我有点怀疑,因为强地址亲和力就是 MAC 地址的目的。 IP 地址的存在正是为了路由目的,但我认为公平地说,它们可能会变得足够不变,从而削弱地理位置的准确性。
我认为用户代理/浏览器在应用程序层(例如某些地理位置标头)的协作可能是未来的趋势,即使这可能会被恶作剧的人欺骗。
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.
有一个名为 Referral Whois 的协议,该协议允许提供商发布 IP 地理位置信息和其他人来检索它。
例如,我当前的IP 2001:470:b4ea:babe:d57:15c8:97b:60c9属于美国的Hurricane Electric。 我使用的 IPv4-IPv6 隧道终止的实际服务器位于瑞士,但我在奥地利。
他发布了所有这些,因此如果您在支持 RWhois 的工具中输入 IP,例如 this,你会在你看到的底部附近找到HE的联系方式
这是我的位置。
没有多少提供商确实发布了这一点,也没有多少地理定位工具支持它,但至少它存在。
大多数 IP 地理定位提供商(其中支持 IPv6 的提供商,有些仍然不支持)将此 IP 放在瑞士,有些甚至放在美国。
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
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.
由于目前似乎还没有一种简单的方法可以做到这一点,也许我们有机会做一些 IPv4 中未完成的事情 (*)
我们可以停下来问问自己这是否是一个好主意。
(*) 或者即使完成了,它也不起作用!
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!
地理位置不好,嗯?
互联网与位置无关,我从未见过地理定位用于非平凡非邪恶的事情。 也就是说,我见过的唯一好的应用程序(语言选择)是微不足道的(也可以很容易地成为一个下拉菜单)。 存在许多邪恶的应用程序(该视频在您的国家/地区不可用,针对我的物理位置进行广告和跟踪)
我们不能阻止这样的东西存在,但我们应该努力使其成为非法或至少在社会上不可接受的使用。
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.