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)
 * It looks like IPv6 bug fixes (like this one, needed to run MediaWiki behind a Squid/Varnish cache) are being backported to MW 1.17 but not to earlier versions. --Carlb 00:46, 7 September 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)
 * This is a problem given that when Wikimedia switches completely to IPv6, /64 and larger rangeblocks will become very common (For example, blocking a /16 in IPv4 might have the same magnitude as a /36 in IPv6). Most ISPs will give end-users anything from a /48 to /64.Jasper Deng 00:21, 5 September 2011 (UTC)

I do expect /64 to be common to address the hosts in an individual LAN because IPv6 subnets provide for a stateless address autoconfiguration which works specifically with /64 prefixes. A Router Advertisement Daemon announces a /64 block and the lower 64 bits are set automatically based on a MAC address or a random value. That leaves a pattern where an ISP gets /32 or larger and an individual network at least a /64 under this system. --Carlb 00:34, 7 September 2011 (UTC)

Rewrite this page?
This IPv6 support page was created four years ago; in 2007, IPv6 in MediaWiki likely had yet to be implemented so much text which remains from the original article is either irrelevant (it was written in the form of a developer's to-do list and the tasks were done years ago) or outdated. As such, subsequent edits have left a somewhat-contradictory page which wavers from "it will be necessary to support the new IP format in the future" (ie: it's still on the drawing board but not extant") to "ARIN operates its own IPv6 Wiki as www.getipv6.info" using MediaWiki and IPv6 (ie: it's real and exists now in the field). Is the "to-do list" style even still useful? --Carlb 05:07, 7 September 2011 (UTC)
 * That was merely a roadmap written by Aaron, you might want to contact him. Hashar 08:07, 7 September 2011 (UTC)

Done. Not sure if a rewrite should be here on IPv6 support or simply a new page Manual:IPv6 support saying basically yes, it exists, here's how to deploy it for various often-used configurations (Apache-only, Apache+Squid3, Apache+Varnish). --Carlb 19:17, 7 September 2011 (UTC)