Fixed IP information URL: Remove "::ffff:" prefix from IPv4-mapped IPv6 addresses

[Steffen]

Affected version

2.0.0 Release Candidate 2

I've set the "IP information URL" to "https://ipinfo.io/{ip}". But ipinfo.io doesn't seem to support IPv4-mapped IPv6 addresses: https://ipinfo.io/::ffff:87.230.75.2

However, everything is fine if you strip the "::ffff:" prefix: https://ipinfo.io/87.230.75.2

This could be considered a bug with ipinfo.io but maybe XenForo could simply strip the prefix when building the URL?

 

[Mike]

While I could make a change here, ultimately, I think this problem is that we probably shouldn't actually be storing IPv4-mapped IPv6 as an IPv6 address internally. If we store it as the underlying IPv4 address, then I think that actually clears up a lot of issues, including issues surrounding IP banning and the like (where I'm not sure if we support the "mixed" display format). We also avoid wasting 12 bytes of storage per IP record.

Given that you appear to be using a hybrid IPv4/v6 system, is there any reason from your experience that we shouldn't do this?

 

[Steffen]

I would not worry about "wasting 12 bytes of storage per IP record" because IPv6 usage is growing like crazy and will probably dwarf legacy IPv4 traffic in just a few years. I've attached a graph that shows IPv6 usage on ComputerBase over time. IPv6 usage probably differs by country but the global trend is the same: https://www.google.com/intl/en/ipv6/statistics.html

I'd continue storing IPv4 addresses as "IPv4-mapped IPv6 addresses" and only special-case the formatting when displaying an IP address (and when passing it to an external site like in this issue). I don't know which "issues surrounding IP banning" you are referring to, maybe you can elaborate? When an admin bans an IPv4 address XenForo should store it as an "IPv4-mapped IPv6 address". You can then compare it to $_SERVER['REMOTE_ADDR'] like usual (if this variable is not in IPv6 format then convert it).

In the long term a dedicated "ipv4" database column would even waste some bytes because an empty "cell" does not use 0 bytes (but 1 byte, I guess).

 

[Lukas W.]

I would not worry about "wasting 12 bytes of storage per IP record" because IPv6 usage is growing like crazy and will probably dwarf legacy IPv4 traffic in just a few years. I've attached a graph that shows IPv6 usage on ComputerBase over time. IPv6 usage probably differs by country but the global trend is the same: https://www.google.com/intl/en/ipv6/statistics.html

That graphs show between 22% and 27% of users having an IPv6-connection. Thats a fourth of all connections, leaving your with three fourths of IPv4-connections and it has taken 6 years to get to that much. I wouldn't call that "dwarf legacy". The databases of my projects are full with IPv4-adresses and only a very little part actually has an IPv6-connection.

 

[Steffen]

I did not say that IPv6 dwarfs IPv4 right now but that it probably will in a few years. At the current rate, IPv6 will probably overtake IPv4 within 3-4 years on our website. And I said that your mileage may vary. However, I agree that "overtakes" or "surpases" would have been a more appropriate word than "dwarfs".

 

[Mike]

I've gone ahead and made the change I referenced in my previous post: a request from an IPv4-mapped IPv6 address will now be treated as if the request came from a "normal" IPv4 connection. This should clear up the reported issue implicitly for any new IP logs, though it won't change older ones. This also eliminates issues that would be caused by an IPv4-mapped IPv6 address not being considered equivalent to the same IPv4 address (such as with IP bans and some other things that do subnet matching).

The reduced space comment was really just an aside. This change actually fixes several other legitimate bugs and reduces confusion if you use a network stack that combines both types of connection into one socket (and unifies the behavior within XF to when distinct sockets are used).

 

[Steffen]

I did not know that there already was a special path for IPv4 addresses. Then it makes sense to treat IPv4-mapped IPv6 addresses like normal IPv4 addresses. Thanks, Mike!