I think this title is better.

Makes sense, and I've been thinking about this for a while. My question is whether this should be enabled by default, or via a checkbox in the block options. The former would be trivial to implement (just a simple check at runtime), whereas the second would require more effort, both for updating the UI and keeping BC with filters where this option isn't set.

In T276877#6895991, @Daimona wrote:

Makes sense, and I've been thinking about this for a while. My question is whether this should be enabled by default, or via a checkbox in the block options. The former would be trivial to implement (just a simple check at runtime), whereas the second would require more effort, both for updating the UI and keeping BC with filters where this option isn't set.

I think we should get the consent of the communities first. I am now consulting the community consensus in enwiki.

My only concern would be ranges which don't adhere to the /64 rule. A notable example is AT&T, for example 2600:387::/32, where users generally hop around within a /48 or larger, and a limited number of /64s are shared. If a filter is being pestered by such an IP hopper, this is going to rapidly propagate throughout the entire usable customer range, causing certain collateral. I've seen other ranges like this, but admittedly there's not many. If this was on enwiki, where we don't currently have any filter blocking enabled, we'd probably sometimes want to exclude these ranges from any blocking filter Saying that, I don't see a checkbox as a particularly useful way of achieving this.

@IN: Please provide links for statements - thanks.

In T276877#6899692, @Zzuuzz wrote:

My only concern would be ranges which don't adhere to the /64 rule. A notable example is AT&T, for example 2600:387::/32, where users generally hop around within a /48 or larger, and a limited number of /64s are shared. If a filter is being pestered by such an IP hopper, this is going to rapidly propagate throughout the entire usable customer range, causing certain collateral. I've seen other ranges like this, but admittedly there's not many. If this was on enwiki, where we don't currently have any filter blocking enabled, we'd probably sometimes want to exclude these ranges from any blocking filter Saying that, I don't see a checkbox as a particularly useful way of achieving this.

Fair point. However, a solution to this would be to basically have a map of (range an IP belongs to) => (what range should be blocked). I think this might even be good for a MW core feature. After all, blocking the whole /64 should also happen when manually blocking IPs. Perhaps this might be implemented via the map mentioned above, with the possibility to override it on-wiki; on Special:Block you might have an option, turned on by default, to apply the hardcoded rangeblock. At which point, AbuseFilter would just use that.

I wonder if work on this isn't premature re IP hiding.

In T276877#6895991, @Daimona wrote:

Makes sense, and I've been thinking about this for a while. My question is whether this should be enabled by default, or via a checkbox in the block options. The former would be trivial to implement (just a simple check at runtime), whereas the second would require more effort, both for updating the UI and keeping BC with filters where this option isn't set.

We can deploy this behavior first and do an A/B test. That is, every time the filter block IPV6 address, there is a 50% chance that it will be block a single IP address, and a 50% chance that it will be block /64 range IP addresses. In addition, aboutthe problem of randomness, since most of the actions of starting a block are edits, we can use the number of edits to determine to let the filter decide whether to block a single IP address or range block.