Last modified: 2013-09-02 20:22:09 UTC
There are some tunneling protocols, like: * 6to4 * Teredo * ISATAP where it is possible to derive real IPv4 address of the user even if he's connecting via IPv6 to us. While we *may* use their IPv6 address for contributions, we definitely should canonicalize those addresses for purposes like blocking and CheckUser. We might need to have something like "79.163.138.172 (via 2002:4fa3:8aac::4fa3:8aac)" to be available (at least to CheckUsers if not broader). We might end up needing a proxy gateway IP address somewhere as well, to block some bad proxies (see bug 23343) or to trust them by the means of similar to current XFF whitelist features (like https://meta.wikimedia.org/wiki/XFF_project and https://www.mediawiki.org/wiki/Manual:$wgSquidServersNoPurge)
That's assuming that the embedded IPv4 address is both valid and externally routeable... likely true today, but new ISP's requesting IPv4 space from APNIC are now merely being rationed out blocks of 1k addresses instead of being given as much IPv4 as they need. That could mean that in future we could see entire providers putting their retail clients behind NAT at the carrier level, so we will have to watch for weirdness such as non-routeable addresses "10.x.x.x" or "192.168.x.x" which mean nothing unless we know which gateway they're behind.
We deal with RFC 1918 addresses alredy (see $wgUsePrivateIPs) - if the users are not expected to come from behind trusted proxies with private IP addresses this should be set to off. A proxy address will be then used. In case of tunnels it should be IPv6 address. This is just to provide some kind of equivalence of a public, reachable IPv4 address (if available) with IPv6 address. Certainly IPv4-in-IPv6 mapping schemes can be used here. Didn't check with Teredo yet, but I presume it does not give out private IP address of the user embedded in the Teredo IPv6 address. Of course, we should checks the resulting IPv4 against $wgUsePrivateIPs anyway (in case some large enterprise network runs private IP addresses _and_ internal Teredo gateway used to reach some internal MediaWiki installation over IPv6, highly unlikely though). No checks about proper reachability can be done, though. That's why gateway information (i.e. real IP address obtained via socket's getpeername()) should be recorded somewhere for auditing purposes (certainly for CheckUser). Maybe even we could provide new UI for such IP addresses, displaying: 2001:0db8::1234:5678 via a.b.c.d Blocks could be checked for both a.b.c.d and 2001:0db8::1234:5678, which would be similar to blocking mechanism proposed by bug 23343.
I would personally use a $wgMatchv6v4TunnelAddresses or some other configuration variable to enable/disable such functionality. If enabled, I'd like to see an IPv4 block affecting everyone using 6to4 or Teredo on that address (client addresses, not server addresses, for Teredo - especially Teredo because the client address is the last, not the first, part of the address, making it impossible to block a single Teredo client via rangeblocking, only a server), and vice versa (for example, if I block a /48 in 2002::/16, the corresponding IPv4 address is blocked; if I block a /32 in 2002::/16, the corresponding IPv4 /16 is also blocked; likewise, if I block a.b.c.d, the corresponding /48 in IPv6 is also blocked). But I would only support the proposed "via" notation for these special classes of addresses. It has no meaning for other addresses.
