Last modified: 2012-04-16 00:46:49 UTC
It would be really nice if CheckUser would record both the IPv4 and IPv6 addresses of a user, even if the user is only using one of those protocols to actually access a MediaWiki installation. With that, we can more easily resolve the problems of Teredo, 6to4, and other tunnels which would not give valid geolocation data.
I'm pretty sure we only get one or the other -- whichever was actually used to connect with.
There are websites that give both addresses, when connecting over IPv6. I don't know if it exists in PHP, but apparently it does exist in JS.
CheckUser now supports IPv6 just fine. There might be some performance improvements, like faster lookup for MySQL if you don't have a native data type. But remark re extended canonicalization of IPv6 is valid. We should also understand IPv6-to-IPv4 and IPv4-to-IPv6 proxies like SiXXS gateways. Opening bug 35542 for address canonicalization and 35544 for X-Forwared-For.
There are websites that give both addresses, when connecting over IPv6? They're most likely using a webpage for test purposes which points to different subdomains for individual pieces (such as embedded images or iframes) to be displayed within the same page. One of those subdomains will have only an IPv4 address, another will have only an IPv6 address. Each piece is a separate request to the web server and the address is captured from each. Suppose I create example.org in DNS with a few subdomains: www.example.org. IN AAAA 1:2:3:4:5:6:7:8 www.example.org. IN A 1.2.3.4 ipv6.example.org. IN AAAA 1:2:3:4:5:6:7:8 ipv4.example.org. IN A 1.2.3.4 and then create a webpage on example.org which contains code like: Your IPv4 address is: <iframe src="http://ipv4.example.org/whoami"></iframe> Your IPv6 address is: <iframe src="http://ipv6.example.org/whoami"></iframe> The browser retrieves the main web page in whichever protocol (IPv4 or IPv6) it prefers. That gives only the one client address (usually IPv6 if it's available) sent to the corresponding server address in that same protocol. The browser then tries to retrieve the individual pieces to fill the iframes... but it can't find an IPv6 address for ipv4.example.org because there isn't one on the domain name server. That request is therefore made in IPv4 only. Likewise, there's no IPv4 address for ipv6.example.org in the DNS so the request either goes through on IPv6 or (if no IP6 connectivity is available) fails entirely. I now have two client addresses from you but only as a result of two separate requests which I tricked your browser into making to two separate subdomains, each a ruse to force one or the other of IPv4 or IPv6. No individual request contained more than one address, but technically that was three requests to different subdomains (as every iframe, plus the page itself, is a separate web hit). Aren't I 1337? I am now going to HAXX0R your COOKIES, LOL! An actual test server might be using other tricks (such as running client-side javascript) but in general, the basic approach that a request to an IPv4 server must have only an IPv4 return address, a request to an IPv6 server must have only an IPv6 return address, and a test page which wants to check both protocols must fire off multiple requests to different addresses (at least one in each of IPv4 and IPv6) likely does still apply to all of those test sites.
As per comment 1 and comment 4 there is no way to cleanly obtain the "other" IP address except for cases described in bug 35542 and bug 35544 where we can derive IPv4 address of a proxied or tunnelled connection. Javascript above is I think similar to the IPv6 test ran for sometime on en.wikipedia.org; but I don't think it should be the basis for CheckUser. Besides, if this is was to be used to track some heavy abuse, turning JavaScript off (or just filtering some information on proxy/firewall) would completely defeat is purpose. I would propose a WONTFIX here.
Fair enough then, since I originally proposed this with "PHP has a function to get both addresses" on my mind.
