Page MenuHomePhabricator

IPv6 range blocks should be limited to /48s, not /19s
Closed, DeclinedPublic

Description

IPv4 range blocks are limited to a /16 - i.e. up to 2^16 == 64k nominal customer addresses. This was picked intentionally to reduce the damage potentially caused by an erroneous block, following the attempted application of a /0 block(!). It's a balance between too large and too little, and there are NAT issues with some ISPs, but it's worked well enough.

Following the same logic, given that most(ish) customers are being granted a /64, MW should limit IPv6 blocks to /(128-64-16) = /48s. However, IPv6 range blocks are currently allowed for up to /32s, which allows for some very considerable collateral damage.


Version: 1.22.0
See also:

Details

Reference
bz56252

Event Timeline

bzimport raised the priority of this task from to Medium.Nov 22 2014, 2:12 AM
bzimport set Reference to bz56252.
bzimport added a subscriber: Unknown Object (MLST).

It's actually /19, as of https://gerrit.wikimedia.org/r/#/c/10856/.

Tim gave the reason:

  • For IPv6, RFC 3177 recommends that a /48 be allocated to every residential
  • customer, so range blocks larger than /64 (half the number of bits) will
  • plainly be required. RFC 4692 implies that a very large ISP may be
  • allocated a /19 if a generous HD-Ratio of 0.8 is used, so we will use that
  • as our limit. As of 2012, blocking the whole world would require a /4 range.

(In reply to comment #1)

It's actually /19, as of https://gerrit.wikimedia.org/r/#/c/10856/.

Thanks, Chris; corrected.

Tim, do you want to discuss this with Leslie?

lcarr wrote:

To be fair, especially since for a while ARIN was allocating /48's per datacenter, many people only hand out a /64 or /56, not a /48. A /48 could take out an entire ISP

That large of a block is crazy 2^(64-19) allocations could be blocked.

The RFC doesn't actually match the reality of current IP allocations.

The range block feature is meant to be used for blocking entire ISPs, that is the point of it. For IPv4, /16 was actually a bit too small, and sometimes on the English Wikipedia, ISPs were blocked using a series of adjacent /16 blocks. Are you saying that this feature should be abandoned for IPv6?

lcarr wrote:

I'm afraid of administrators going overboard and blocking an ISP for one user.

(In reply to comment #5)

I'm afraid of administrators going overboard and blocking an ISP for one
user.

I'm sure it happens sometimes. The first range block was for a single person -- the block of Bell Canada in the whole of Nova Scotia:

https://en.wikipedia.org/w/index.php?title=Wikipedia:Village_pump_archive_2004-09-26&diff=prev&oldid=2063547

I still believe that it was the right move for the community at that time -- the block was effective, Hubley left, and we kept some valuable admins who we might otherwise have lost due to burnout.

Now that we have IP block exemptions and anon-only blocks, blocks of large ranges are pretty common. There is already a block of a /29 IPv6 range on the English Wikipedia:

https://en.wikipedia.org/w/index.php?title=Special%3ALog&type=block&user=&page=User%3A2A00%3AF48%3A0%3A0%3A0%3A0%3A0%3A0%2F29

Anyway, the point is, the community has some experience in administering this kind of block, they are not as naive as you think.

The limit should be set at /32 if it is to be more restrictive than /19.

It is often the case that an entire webhost, which tends to have a /32 or more, is blocked because they tend to host open proxies.

The largest range for one user by Deutsche Telekom I detected till now was /40.

@Harald

However, the largest rangeblocks I've seen (both global and local) have been /28 in IPv6.

On a related note, $wgCheckUserCIDRLimit is currently set to /48 for IPv6, and it may be a good idea to make this consistent with $wgBlockCIDRLimit, which as it at /19.

One admin on the Dutch Wikipedia loves big blocks:

MariaDB [nlwiki_p]> SELECT COUNT(ipb_address) FROM ipblocks WHERE ipb_address LIKE '%:%/27' OR ipb_address LIKE '%:%/28' OR ipb_address LIKE '%:%/29' OR ipb_address LIKE '%:%/30' OR ipb_address LIKE '%:%/31' OR ipb_address LIKE '%:%/32';
+--------------------+
| COUNT(ipb_address) |
+--------------------+
|                 70 |
+--------------------+
1 row in set (0.06 sec)

MariaDB [nlwiki_p]>

English Wikipedia doesn't seem to like ipv6 either:

MariaDB [enwiki_p]> SELECT COUNT(ipb_address) FROM ipblocks WHERE ipb_address LIKE '%:%/27' OR ipb_address LIKE '%:%/28' OR ipb_address LIKE '%:%/29' OR ipb_address LIKE '%:%/30' OR ipb_address LIKE '%:%/31' OR ipb_address LIKE '%:%/32';
+--------------------+
| COUNT(ipb_address) |
+--------------------+
|                 20 |
+--------------------+
1 row in set (7.14 sec)

German, French, Spanish, Japanese, Portuguese are all zero.

With T95857 being fixed recently, I think that this bug (limiting from a /19 block to a /48) should not be done.

Or, in case it is being changed, then the other bug should be reopened so that both the block limit and CU limit are normalized.

I am not sure that CU viewfinder and maximum block ranges should be necessarily in sync. If CheckUsers can't easily see a wider range, they won't event know if the current maximum block range is sufficient. But this is mostly theoretical as those ranges are pretty large and CheckUser queries should not cause performance issues.

PS. Note also T116414 and T46836 + this was discussed in SF two months ago... (ping @hoo)

Rangeblocks should allow blocking a whole ISP at time. It's, of course, an extraordinary countermeasure but still we should be able to apply it. Dealing with IPv6 you should consider /64 to be, roughly, comparable to single IPv4 address, with /48 being similar to /20. I'd say a /32 (6) is similar to /16 (4).