Some (large) networks notably allocate addressing for multiple users on a single /64. This would have a negative impact on those users.

The advent of temporary accounts has brought this from being a nice quality-of-life improvement to, IMO, a necessity if the TA system is going to continue. @kostajh I hope you don't mind if I ping you per your comment at en:WP:VPT pointing to this ticket. With /64 autoblocking, I think many of the concerns being expressed in that thread would go away quietly. There would be lower donwside to situations where admins neglect to look into an underlying IP/range when blocking a TA (@ScottishFinnishRadish' concern) and, at risk of stating the obvious, fewer TAs able to evade blocks without even trying (if they're doing one of any number of technical things that have the side-effect of bypassing a cookie-block). As a long-term goal, it might be nice to exempt ISPs known to split /64s, but in the short term I think the mild increase in collateral damage is worth it, and is comparable to what we already see with blocking schools, libraries, large mobile networks, etc. Alternatively, a middle-ground solution might be having TA autoblocks specifically affect the /64, although one would want to clearly document this divergent behavior.

I would be open to trying this. I'm not sure how we'd be able to effectively monitor for collateral damage, though.

As a long-term goal, it might be nice to exempt ISPs known to split /64s

We could potentially do this via a hardcoded list of known IPs, or by using IPoid's data.

In T377771#11491021, @kostajh wrote:

I'm not sure how we'd be able to effectively monitor for collateral damage, though.

We could include some tracking logic in the unblock process. Like, instead of serving MediaWiki:Autoblockedtext, we could create MediaWiki:Autoblockedtext-64, and ask at least the biggest Wikipedias to recommend a separate unblock template in that message, like {{unblock-auto-64}}. The way TAs are implemented already means that someone can't appeal a block through normal channels if they haven't already created a TA on that client pre-block, which artificially decreases the base rate of appeals, but I can't think of any reason that that rate would differ for /64 autoblocks versus other blocks, so we could then still do meaningful data analysis based on the rate of {{unblock-auto}} vs. {{unblock-auto-64}}.

Edited per correction below.

In T377771#11492206, @Tamzin wrote:

The way TAs are implemented already means that someone can't appeal a block through normal channels if they haven't already created a TA on that client pre-block, which artificially decreases the base rate of appeals

Logged out users should be able to use the default unblock process via user talk page even without already having a TA: T398673: Unregistered editors on blocked ranges need a way to interact on-wiki to appeal a block allows creating a TA for user talk page appeals even on blocked IPs / IP ranges (unless „prevent this user from editing their own talk page“ is enabled).

We should not assume that IPv6 /64 corresponds to exactly one customer, as RIPE (and other) documentation and operator practices show that IPv6 delegation varies significantly, including shared addressing (e.g. CGNAT64) and non-/64 allocation schemes.

In T377771#11491021, @kostajh wrote

We could potentially do this via a hardcoded list of known IPs, or by using IPoid's data.

See:

• APNIC blog 2024 : This perspective of subnet use is similar to Figure 3, where the use of /64 and /56 subnets is the most prevalent, while /60 and /48 subnets are far less common.
• RIPE database/RIPE 690: it outlines common deployment practices such as /48 for business customers and /56 for residential customers, while maintaining /64 as the standard IPv6 subnet boundary (with some variations depending on deployment context, including cellular networks).

In T377771#11491021, @kostajh wrote:

I would be open to trying this. I'm not sure how we'd be able to effectively monitor for collateral damage, though.

A similar situation applies to Talk:No open proxies/Unfair blocking: it is difficult to assess both how effectively wrongful blocks are handled (e.g. through VRT, administrators, etc.) and the overall rate of collateral impact.

An experiment could be conducted on the English Wikipedia; however, it would be advisable to have monitoring in place before considering a global deployment. It is not even certain that English-speaking editors are as affected as users in other regions.

In T377771#12062020, @LD wrote:

• APNIC blog 2024 : This perspective of subnet use is similar to Figure 3, where the use of /64 and /56 subnets is the most prevalent, while /60 and /48 subnets are far less common.
• RIPE database/RIPE 690: it outlines common deployment practices such as /48 for business customers and /56 for residential customers, while maintaining /64 as the standard IPv6 subnet boundary (with some variations depending on deployment context, including cellular networks).

Perhaps I'm missing something, but this sounds to me like autoblocking the /64 range is quite a cautious approach given that many customers are using larger subnets?