Talk:IPv6 support roadmap

Actual IPv6 status
...I've been using IPv6 for years and it works out-of-the-box with MW 1.6.x, 1.7.x, 1.8.x - it's totally broken in 1.9.x. So IPv6 was supported (and is in previous) until version v1.9.x.

As pointed out on the main page, MW versions up to 1.9.x do work with IPv6. As for the "coming very slowly", part in the introduction, realize that there already is at least 5 MW sites that I know of who are using IPv6. These sites can't upgrade beyond MW 1.8.x - because IPv6 support broke when 1.9.x was released.

Also, the IPv6 "coming very slowly" is a bit like someone suddenly becoming aware that "oh there is this new thing called the wheel being used, we should probably support that", sites who do support IPv6 do have the history pages full of IPv6 IPs. So it seems that a whole lot of users already have IPv6, while there isn't that many sites on the Official 6bone Webserver List list yet (But there are like 5 MediaWiki's on that list as of now). --Xiando 20:19, 13 March 2007 (UTC)
 * I was refering to the rate IPv6 was overhauling IPv4 worldwide, not "software support". Also, while history pages/contribs may have IPv6, the current issues around ranges and consistency have not been addressed since now. 1.10 should have full IPv6 support for blocks/checkuser. Voice of All 22:01, 13 March 2007 (UTC)

I am using also ipv6. I run in the same problem with version 1.9.3.

Please do not longer ignore ipv6. It is slowly, because of the most popular sites like wikipedia are running only on ipv4.

Thomas Schäfer
 * The indexes can be dropped and redone, all the rest is now in 1.10 already, full support. Voice of All 20:01, 23 April 2007 (UTC)

Mediawiki 1.16.0 and IPv6
Dear colleagues, so may I set up MediaWiki 1.16.0 to IPv6 or not? I am planning to upgrade from version 1.13.3 and would like to do that together.
 * 1.16 has more v6 bugs than I'd have hoped. There has actually been a lot of work on fixing v6 bugs in 1.17 lately. Aaron 22:59, 20 November 2010 (UTC)
 * Hi, now that some time has passed it would be interesting to know the current status of IPv6 implementation on MW. I am sure something has happened in the meantime. Thank you and cheers --&#91;&#91;kgh&#93;&#93; 14:14, 14 March 2011 (UTC)

Range blocks?

 *  "IPv6 addresses, when padded out, are 32 characters, rather than 8 for IPv4. This partial index will likely be fine for a long time, as there are few range blocks, usually they are not permanent, and few are IPv6." 

Actually, I can envision many or most IPv6 blocks being /48 or /64 range blocks, as using something as narrow as a sole /128 leaves so many other IP's for an abusive user or a spammer to play with. All that /128 is going to keep out is the casual " bold italic I wonder what this button does Image:Example.jpg " sort of noise from someone more clueless than actively malicious. The task of combating spam and vandalism is also complicated by most currently-extant outside lists of bad 'bots and open proxies being IPv4-centric; there is no IPv6 "check spambots" until the underlying data exists. --Carlb 21:55, 3 September 2011 (UTC)


 * The problem is a bit harder than that. You really want to block at the /128 level and then raise the netmask step by step until you find out which mask is used by an user. Once you have find out the range, you can probably assume that all users of this ISP have the same sub-allocation (ie: /60 for free). So the next time you block someone in the same ISP block, you can block his /60 directly. Others ISP might allocate a /56 or just a /64.
 * Ideally, the sub allocation sizes should be filled in the LIR databases (RIPE, APNIC, ARIN ...). As of Septembre 2011 there is no such field so we will have to build it up ourself.
 * We really need to find out the overall ISP block (lookup the LIR database) and then assume all of that block got allocated the same way. free.fr got assigned 2a01:e00::/26, so on blocking we will know that any IP in that block should use a /60 mask.
 * Hashar 10:21, 4 September 2011 (UTC)