Improve display of multiple IPv6 contributions by a single editor
Problem: A single IP editor using an IPv6 connection can have multiple IP addresses, which can change daily, usually without them knowing. However, all those assigned IP addresses fall within "the /64 range", and so all of these contributions belong to just that one user. Unfortunately, Special:Contributions will only display edits from just one of those IP addresses, unless specifically commanded to show them all. The full picture of an editor's contributions is therefore often missing. Without knowing that one can simply add /64 to the end of an IPv6 url at Special:Contributions, it is obvious that admins, vandalism patrollers and any editor interested in the full range of a user's edits are unable to see them, and probably unaware they can be found. The picture of editing is therefore often seriously incomplete. Warnings for bad faith edits can easily be scattered across multiple IP address, and remain hidden from view unless one knows the /64 trick. Even if one IPv6 address gets blocked by an admin, the user can still edit on a more recently assigned address unless the fully range of addresses is blocked (explained in plain English here).
A further problem arises when admins or patrollers work from a mobile phone. From a PC one has to click and manually add '/64' to the end of an IPv6 url in a browser window every time one needs to check an IPv6 editor's full contributions. But on a mobile phone in Desktop View (which most serious editors use) it is not feasible on at least some phones. On an iPhone (and probably many others), even in landscape mode, the url runs off the screen, making insertion of '/64' onto the end of that url quite impossible). Anti-vandalism patrolling of IPv6 users on a mobile phone is therefore severely restricted or impossible to fully achieve because there is no way to display the full contributions of an IPv6 user across the whole /64 range.
Even if IP anonymisation is implemented, there will still be a need to view all of one user's past contributions and talk page warnings related to multiple, changing IPv6 addresses. Knowing their actual IP addresses is not essential to this proposal; it's about seeing them all. Nick Moyes (talk) 15:33, 17 November 2020 (UTC)[reply]
Who would benefit: All admins, anti-vandalism patrollers, and any editor interested in understanding the range of editing contributions made by the huge number of users who have changing IPv6 addresses.
Proposed solution: Provide a clear and very visible button on the Special:Contributions page to permit the easy displaying of all IPv6 edits on the /64 range by that one IP user. e.g. a big, easy-to-click button labelled: Display full range of IP edits by this user which appears whenever IPv6 contributions are shown.
More comments: Related to this issue is the inability to see any previous warnings or discussion messages left for a user at an active IPv6 talk page address within the /64 range because it is no longer currently in use. A lot of separate IPv6 talk pages need to be individually opened up to see all those messages. Equally, the IPv6 editor won't be able to see earlier warnings or notices left for them. This closely-related proposal attempts to address that issue.
I will add is there a possibility that when I am at an ipV6 address, I can click on the block log to see not only the single ipv6 is blocked or not, but had the range be blocked before. In addition, I will like to be able to block a /64 without the need to remove the last few octets (i.e. a block the range /64) in special block. One more is that it will be ideal if there can be a page created to leave messages for a whole /64 range. These might be beyond the scope of this proposal but worth looking. Thanks much. Camouflaged Mirage (talk) 17:21, 17 November 2020 (UTC)[reply]
I support this wholly. As an English Wikipedia checkuser and admin, I am consistently shocked by the behavior of MediaWiki when it comes to IPv6 editing, especially within the same /64 block. In my opinion, /64 ranges should be treated by default for most purposes as a single IP address with a single talk page and a single block setting by default; dealing with /64 ranges within poor technical infrastructure wastes a lot of valuable volunteer administrator time that could be spent elsewhere. Best, KevinL (aka L235·t) 06:49, 1 December 2020 (UTC)[reply]
This is useful but care should be taken to avoid giving the impression that /64 blocks equal users; this is not always the case. --Tgr (talk) 03:22, 13 December 2020 (UTC)[reply]
You're correct that "/64 = one end user" may not be true for all cases, but also note that individual IPv4 addresses do not always equal individual users either. An IPv6 /64 matches closely with the scope of an individual IPv4 address (a /32). Best, KevinL (aka L235·t) 08:35, 17 December 2020 (UTC)[reply]
SupportStrong support. It is currently next to impossible for administrators to keep troublesome IPv6 users under control. Furthermore, bad faith unregistered editors have long been a problem from both dynamic IPv4 and IPv6 addresses. It is high time that Wikipedia found a way to determne when the same device was being used on different IPs so that they can be treated as a single user. SpinningSpark18:48, 8 December 2020 (UTC)[reply]
Oppose I think investing precious community directed development time before we know how IP masking is going to work is not a good choice. Additionally, I would hope that the team implementing IP masking could build this into that tool again saving us time now. Best, Barkeep49 (talk) 15:52, 20 December 2020 (UTC)[reply]
Support --Teukros (talk) 17:50, 11 December 2020 (UTC)
Strong support and please make also deleted contribs viewable. --Achim (talk) 09:15, 14 December 2020 (UTC)
Oppose I think investing precious community directed development time before we know how IP masking is going to work is not a good choice. Additionally, I would hope that the team implementing IP masking could build this into that tool again saving us time now. Best, Barkeep49 (talk) 15:52, 20 December 2020 (UTC)
