Wikimedia Bugzilla is closed!

1) What's the X-Forwarded-For header actually look like?

2) What's the REMOTE_ADDR seen from Apache? Is it the same for IPv4 and IPv6 visits?

3) Note that any untrusted X-Forwarded-For entries are automatically ignored to avoid spoofing; only entries provided by a trusted proxy host will be taken into account.

Make sure that your proxy server is listed in $wgSquidServers or $wgSquidServersNoPurge -- if things come in through a different address on the IPv6 path it might actually not be seeing it as coming from a trusted server.

http://www.mediawiki.org/wiki/Manual:$wgSquidServers

This is what Squid/Apache is feeding to ProxyTools.php::wfGetForwardedFor()

Host=ipv6.example.org
User-Agent=Mozilla/5.0 (Windows NT 5.1; rv:6.0.1) Gecko/20100101 Firefox/6.0.1
Accept=text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language=en-GB,en;q=0.9,en-US;q=0.7,en-ca;q=0.6,fr-FR;q=0.4,fr;q=0.3,en;q=0.1
Accept-Encoding=gzip, deflate
Accept-Charset=ISO-8859-1,utf-8;q=0.7,*;q=0.7
Referer=http://ipv6.example.org/wiki/User:127.0.0.1
DNT=1
Pragma=no-cache
Via=1.1 server.example.org (squid/3.1.15)
X-Forwarded-For=2001:5c0:1000:a::133
Cache-Control=no-cache


obtained by inserting a 'print' statement as:

function wfGetForwardedFor() {
        if( function_exists( 'apache_request_headers' ) ) {
                // More reliable than $_SERVER due to case and -/_ folding
                $set = array ();
                foreach ( apache_request_headers() as $tempName => $tempValue )
{
                       $set[ strtoupper( $tempName ) ] = $tempValue;
                       print $tempName . "=" . $tempValue . ", \n";
                }

According to ProxyTools.php::wfGetIP() 
REMOTE_ADDR = 127.0.0.1 

and, according to the config files, 127.0.0.1 is in $wgSquidServersNoPurge (as it must, or IPv4 traffic would also be in [[special:recentchanges]] as coming from localhost - and some random admin would've tried to ban the address by now)

So, clearly $set['X-Forwarded-For'] = '2001:5c0:1000:a::133' is done in wfGetForwardedFor() and it's somewhere after this point that it doesn't like an IPv6 address.

This is weird, wfGetIP correctly determines $ipchain = {127.0.0.1 , 2001:5c0:1000:a::133 } and recognises 127.0.0.1 as a trusted proxy (localhost4) but then fails to recognise the IPv6 as compliant with IP::isPublic()

Set $wgUsePrivateIPs = 1 and suddenly [[special:mypage]] indeed does go to [[User:2001:5C0:1000:A:0:0:0:133]] (or whatever dynamic IP I'm browsing from).

Curious! IP::isPublic6() only lists fc:: - fdff:ffff.....ffff and 0:0:0:0:0:0:0:1 as private ranges, so the 2001:... one should come through ok.


Aho, looks like that should be 'fc00::' not 'fc::' ... http://en.wikipedia.org/wiki/Private_network#Private_IPv6_addresses

Adding need-unittest keyword; a prime candidate for adding to unit tests. :)

The problem would appear to be IP.php:isPublic( $ip ) which fails IPv6 addresses on this test:

   // ip2long accepts incomplete addresses, as well as some addresses
   // followed by garbage characters. Check that it's really valid.
   if( $ip != long2ip( $n ) ) {
       return false;
   }

I tried disabling the " $1p != long2ip ( $n ) " and going to http://ipv6.uncyclomedia.org/wiki/Special:Mypage - it successfully comes back at me now as http://ipv6.uncyclomedia.org/wiki/User:2001:5C0:1000:A:0:0:0:133

Clearly it's doing something that doesn't like IPv6 (for instance, if a 'long' is defined as 32-bits, as a machine word or as anything smaller than 128 bits this would ensure 'long2ip' to not be IPv6 friendly no matter what else takes place).

This is based on the MediaWiki 1.17alpha but I believe the same issue is in 1.19

The code never gets that far -- there's a check for isIPv6() right at the top which diverts execution into isPublic6. :)

Problem is simply that the range list it's checking against is incorrect, so the vast majority of potential network addresses are miscategorized as private.

The diversion to isPublic6 appears to exist in the 1.19alpha but not the 1.17alpha

I still have quite a few sites on the old code as some extensions break on the upgrade - I shall have to see what's up with the new (1.19) version of IP.php

Brion, I can confirm your "Aho, looks like that should be 'fc00::' not 'fc::'"

Indeed 00fc: to fdff:/16 is huge, but change this to:

if ( !$privateRanges ) {
   $privateRanges = array(
       array( 'fc00::', 'fdff:ffff:ffff:ffff:ffff:ffff:ffff:ffff' ), # RFC 4193 (local)
       array( '0:0:0:0:0:0:0:1', '0:0:0:0:0:0:0:1' ), # loopback
    );
}

to flag just fc00: to fdff:/16 as local and the code starts working.

This makes sense as global IPv6 addresses are prefixed 2xxx: or 3xxx: - thanks.

Awesome, good to confirm that fixes it in practice for you. :D I'm adjusting the tests and patching...

Perfect timing -- Aaron fixed it on trunk in r96386 and committed just before me. :)

It's marked for backport to 1.18 and 1.17 so should be in the next bug-fix and feature releases.