Last modified: 2013-02-05 11:50:02 UTC
See also bug 35542 but I would bump severity for this. We already have IPv6 enabled on Wikimedia but we only gave sysops rights to do range blocks of /64. However with 6to4, holder of an IPv4 address can get an IPv6 range of /48, which renders IP blocking completely useless if vandals know about 6to4.
(In reply to comment #0) > See also bug 35542 but I would bump severity for this. > > We already have IPv6 enabled on Wikimedia but we only gave sysops rights to do > range blocks of /64. However with 6to4, holder of an IPv4 address can get an > IPv6 range of /48, which renders IP blocking completely useless if vandals know > about 6to4. The /64 limit will change next upgrade.
I think this can be resolved as "RESOLVED INVALID" based on Aaron's comment here. I once recommended 6to4 blocking like you described, but now I don't because the original purpose of IPv6 deployment for the WMF was to avoid collateral damage.
We should also consider applying IPv4 blocks to the XORed IPv4 on Teredos, or, at the very least, update the Checkuser plugin to take it into account. Otherwise, someone who'd otherwise be prevented from editing due to an IPv4 block could presumably just use IPv6.
Added the see also to https://bugzilla.wikimedia.org/show_bug.cgi?id=35542 I'd say the primary difference between 35542 and this one is that we could easily worry about the BIKESHED/display/UI aspects later, as long as we deal with any obvious security issues that can be actively exploited (e.g., an IPv4 user bouncing through a Teredo to avoid blocks/checkuser hits). Even worse, because the rest of the stuff comes *before* the XORed IPv4, parsing the Teredo space (2001:0::/32) separately from normal IPv6 addresses is even more important, as the same IPv4 could simply hop to different Teredo servers to avoid blocks, as well.
Not that many of our end-users know how to switch it on on-demand, and you could just block the corresponding 6to4 when needed ("when needed" is very important here). Collateral damage should be minimized as much as possible.
On the topic of Teredo, Teredo is very easy to rangeblock. It might be easy to just treat teredo users as open proxies. After all, teredo should be only temporary.
Rangeblocking Teredo would require blocking the entire server, as the XORed port precedes the IPv4 IP, and you can't use wildcards to skip over it. Regardless, I'd still strongly suggest that if the problem still exists, we just fix it quickly and never have to worry about the worst-case scenarios--of which there are no doubt plenty--or teaching people how to deal with Teredo blocks versus the rest of IPv6. Plus it would already apply to already-active blocklist entries and/or RC contribs that would be queried by the CU plugin. Whether or not Teredo, as a whole, should be blocked falls outside the scope of Mediawiki and/or its plugins, and is primarily a policy issue for the various wikis.
A possibility is a checkbox like "Apply this block to 6to4 tunnels from this address".
If an IPv4 block matches the XORed IPv4 address on a *Teredo* client, I can't think of any instance where you'd want to treat it any differently on a block-by-block basis. For example, even a legitimate IPv4 NAT that's using Teredo *should* be blocked by an IPv4 block, even if that block is anon-only. That said, a global wg* option would make sense for people who'd want to en-/dis-able the automagic functionality.
Someone could write an extension for such Teredo blocks, but MediaWiki currently supports none more than simply blocking the server range.
