Author: wiki
Description:
The current "design" for an IP block (in IPv4 and MediaWiki) is to block that specific IP. Problem is that IPv6 is much bigger. The recommendation is currently to issue a /64 for everything, even for a Point-to-point link. So in the case of IPv6, blocking the /128 is effectively pointless. The default when handling IPv6 addresses probably should be to block the /64.
Version: 1.17.x
See also:
| Status | Subtype | Assigned | Task | ||
|---|---|---|---|---|---|
| Resolved | None | T37540 Enable full IPv6 support on Wikimedia wikis | |||
| Open | None | T26294 Should block IPv6 addresses at /64 instead of /128 |
brovvnout+bugzilla wrote:
You don't necessarily want to block an entire subnet, an optional flag would be better.
(In reply to comment #0)
The current "design" for an IP block (in IPv4 and MediaWiki) is to block that
specific IP. Problem is that IPv6 is much bigger. The recommendation is
currently to issue a /64 for everything, even for a Point-to-point link. So in
the case of IPv6, blocking the /128 is effectively pointless. The default when
handling IPv6 addresses probably should be to block the /64.
Were is this recommendation?
Be careful. My ISP (free.fr) allocate a /60 per end user. A /48 mask will block 4096 end users 2^(60-48).
Some companies might have a /64 dedicated to internet access. In this case you will have to block per /128 :(
Rethinking about it, we might have to implement a system to collect the end user allocation size per ISP.
As an example, given an ISP with a /20 allocation and sub allocating a /60 to each of its end users. When blocking the user IP address we could whois it to find out the ISP superblock (/20 in my example) and then prompt to collect the end user allocation size (/60 in my example, could be /64 per default).
The next time we try to block an end user for this ISP, we could internally look up the default end user allocation size and use /60 as a default.
Most companies would be allocated a /48 from their ISP and have a different policy. So we have to find the smallest possible block and set the default end user allocation size for this block. We should probably query the whois database from time to time to detect networks changes.
Ideally, such a field should be available in the RIR databases. I have not found any plan to implements it as of January 2011.
carlb613 wrote:
I'd think that /64 is rather common due to rfc4291 [[IPv6 address#Stateless_address_autoconfiguration]] by which any individual router is given a /64 and the individual clients suffix this with a 64-bit extended MAC address or a random suffix.
I've only seen a /128 once; the lowest-level of "anonymous" tunnel on gogo6 acts as a dynamic IP address for one Windows PC and semi-randomly allocates a different /128 from [2001:5c0:1000:a]/64 each time the PC re-connects to the network. Even there, all of their other "tunnel" offerings are at least a ::/64; I believe ::/64 as the smallest allocation is also true of Hurricane Electric. For that matter, my co-lo provider will be offering a ::/64 for my three servers.
Oh, drats, that only leaves me with 2^64 - 3 free addresses? What if I run out? If my upstream provider only has [2605:ac00]/32 they might've assigned all four billion ::/64's by the time that happens, then I'm really in trouble!
In any case, we should expect many (or even the majority) of blocks to be rangeblocks (with /64 the smallest viable) unless we're dealing with the most casual of vandalism from someone who has no idea how either wiki or IPv6 works.
wiki wrote:
Maybe it should be a configurable variable in LocalSettings.php, the size of the default ipv6 range block, that is. /64 is the RFC suggestion and that seems to be what most groups are handing out (so far all of mine are, HE, Linode, other providers) so for my personal wiki's I'd want to do /64 block. On the other hand the WMF may want to be more lenient and only block /80 or /96?.
But yea, single IP blocks in IPv6 will be a thing of the past.
carlb613 wrote:
Hard to know if blocking /80 or /96 makes sense... if /64 is enough to narrow down to one individual router (a LAN subnet) the lower 64 bits seem to typically be either:
a) mostly zeroes, with the low word a sequential or arbitrary number identifying an individual machine using just the lower few bits as meaningful data.
b) a network card's hardware MAC address or a randomly-selected number.
A local network may well be 2001:db8:1234:5678::1 as router with ::2, ::3 and ::4 as the individual computers; in this case a /64 vs. a /125 actually produce the same result as all that's in all those extra bits is a whole lot of zeroes.
The most likely options are:
a) block one computer (a /128) - weak as the rest of the same LAN retains access
b) block one individual subnet (a /64) - usually takes out one router or LAN
c) a range block of anything larger (a /32 would likely block a local ISP)
I've proposed a /32 as the technical maximum because GoDaddy and other webhosts get ranges of that size. I do not believe the WMF should give leniency with /80 or /96 because one single user never will have a range of that size. If a /64 represents a group, just block single addresses.
The default should indeed be a /64, but we have to be careful about ISPs who issue /56, /48, and 6to4 addresses.
I think blocking of IPv6 should assume /64 "by default", but it should be modifiable.
Probably out subnet/host block distinction should go away, even for IPv4 (just have /32 as kind of special default case).
If possible, I request that this feature request be withdrawn ("WONTFIX"'d) as a significant number of ISPs break this convention, especially for VPS and dedicated server providers.
Although not common, there are times that a /64 doesn't mean one user. I've even had a CheckUser query be too big to run on a /64 that I think was some kind of proxy.