User:Doug Weller/IPv6

You do the block on the actual contributions page. See [1]

Copied from I think WP:AN

Blocking policy and IPv6 ranges

I am usually an idiot about this, treating IPv6 addresses as though they are IP addresses and only blocking the one. Once in a blue moon I remember. We don't seem to say anything about this in our blocking policy. We'd also need to spell out how to identify the appropriate range, etc. I started a discussion at Wikipedia talk:Blocking policy#Should we include advice to block an IPv6 range, not a single address? and then realised people don't seem to read that page. Wikipedia:Blocking IP addresses also needs updating. Credit to Bish for this by the way who reminded me about it recently. Doug Weller talk 14:18, 9 September 2017 (UTC)

I wonder if a technical change would be feasible (and a good idea), to automatically offer the /64 range as an option when blocking an IPv6 address? Boing! said Zebedee (talk) 16:23, 9 September 2017 (UTC)

A technical change (as suggested by Boing) or at the very least some wording changes would be greatly appreciated. I think it's fair to say the number of IPv6s editing has increased year on year (75% of all percentages are made up on the spot), so this is probably more of an exposure thing -- There'sNoTime ^{(to explain)} 18:16, 9 September 2017 (UTC)

This is more complicated than people make it out to be. Generally, blocking the /64 is the right thing to do, but not always. A /64 could represent a large number of customers in certain unusual situations. I don't see any reason to deviate from our usual practice. If you see them using more than one IP address, block the range from the start. Otherwise, just do one IP. If you see them come back, then it justifies a range block. ~ Rob₁₃^Talk 18:26, 9 September 2017 (UTC)

@BU Rob13: What I'm suggesting is that we have a section in the blocking policy with advice on how to deal with IPv6 editors. I agree that there are times when blocking the range would be a bad idea, but wouldn't that show up if you check the contributions from the range? Doug Weller talk 18:29, 9 September 2017 (UTC)

As you almost suggested above, this would probably be an idea on the WP:IPB page, but I don't think it's good for a policy page. And I can give a handy example for not using /64 blocks (and indefinite blocks): Special:Contributions/2600:387:*. -- zzuuzz ^(talk) 18:52, 9 September 2017 (UTC)

zzuuzz for you information the above IP6 search is not a /64 subnet; it is a /32 subnet. as such is could represent as many as 4,294,967,296 different /64 connections. --Jules (Mrjulesd) 21:47, 9 September 2017 (UTC)

Yes, please pick any subnet within it. -- zzuuzz ^(talk) 21:53, 9 September 2017 (UTC)

Well you could pick Special:Contributions/2600:387:0:802:* , a /64 subnet, and it looks like a single user. --Jules (Mrjulesd) 21:56, 9 September 2017 (UTC)

Any subnet except that lone example. -- zzuuzz ^(talk) 22:05, 9 September 2017 (UTC)

Phabricator tasks of interest: RFC: IPv6 contributions and talk pages, Should block IPv6 addresses at /64 instead of /128, and Have one aggregated talk page for ipv6 /64. — JJMC89 (T·C) 20:13, 9 September 2017 (UTC)

• (edit conflict) I think we're seeing more and more IPv6 addresses editing the 'pedia and, yes, it would be helpful to incorporate some advice in the blocking guidance. mw:Help:Range blocks/IPv6 has some useful information. Typically, an IPv6 /64 subnet is allocated to a household or a location and we would block a /64 subnet as we would a single IPv4 address but only after checking the range, satisfying ourself that it is stable and that a single user is using that range. --Malcolmxl5 (talk) 18:56, 9 September 2017 (UTC)
• Any admin worried about blocking /64 subnets should not be overtly worried: it's roughly equivalent to blocking a single static IPv4 address. If you look at https://tools.ietf.org/html/rfc5375 at The Internet Engineering Task Force it quite clearly explains the reasons why:

Using a subnet prefix length other than a /64 will break many features of IPv6, including Neighbor Discovery (ND), Secure Neighbor Discovery (SEND) [RFC3971], privacy extensions [RFC4941], parts of Mobile IPv6 [RFC4866], Protocol Independent Multicast - Sparse Mode (PIM-SM) with Embedded-RP [RFC3956], and Site Multihoming by IPv6 Intermediation (SHIM6) [SHIM6], among others. A number of other features currently in development, or being proposed, also rely on /64 subnet prefixes.

Nevertheless, many IPv6 implementations do not prevent the administrator from configuring a subnet prefix length shorter or longer than 64 bits. Using subnet prefixes shorter than /64 would rarely be useful; see Appendix B.1 for discussion.

However, some network administrators have used prefixes longer than /64 for links connecting routers, usually just two routers on a point-to-point link. On links where all the addresses are assigned by manual configuration, and all nodes on the link are routers (not end hosts) that are known by the network, administrators do not need any of the IPv6 features that rely on /64 subnet prefixes, this can work. Using subnet prefixes longer than /64 is not recommended for general use, and using them for links containing end hosts would be an especially bad idea, as it is difficult to predict what IPv6 features the hosts will use in the future.

So any ISPs worth their salt are going to allocate /64 subnets for connections, as allocating any larger subnet could cause all sorts of end-user problems. Of course this doesn't mean you're necessarily going to be blocking a single user, but neither did blocking a single static IPv4 address necessarily imply this either. --Jules (Mrjulesd) 16:41, 10 September 2017 (UTC)

Unfortunately, by this definition of "worth their salt", many ISP's, especially in Asia and Africa, are not. I've seen IP-hopping throughout much greater ranges (e.g. Wikipedia:Sockpuppet investigations/N R Pavan Kumar). One of our incentives for enabling IPv6 was to allow more granular targeting of a single user not possible with IPv4 - we shouldn't impose IPv4's limitation here.--Jasper Deng (talk) 17:42, 10 September 2017 (UTC)

Sorry but can you explain how Wikipedia:Sockpuppet investigations/N R Pavan Kumar demonstrates this? I can't understand how it does, there are no IPv6 socks at all listed. --Jules (Mrjulesd) 17:51, 10 September 2017 (UTC)

I should've been more clear. Look at the investigation on June 13 where a CheckUser says a rangeblock won't be feasible. I linked the contributions page of an IPv6 sock during that investigation.--Jasper Deng (talk) 18:13, 10 September 2017 (UTC)

I'm not convinced that that indicates a greater than /64 subnet, there could be other explanations such as a mix of Ipv4 and IpV6 addresses, or uncertainty about Ipv6 rangeblocks. I'm not sure this is a good place to discuss it, but you can on my talk page if yo so wish. --Jules (Mrjulesd) 18:49, 10 September 2017 (UTC)

There are many ISPs that fail to live up to your expectations of how things should work. Although many ISPs allocate a /64 for each customer, others allocate customer IP addresses from a very wide pool, typically a /40 or /42, though I've seen them range anywhere from a /60 to a /36. These are a pain to deal with. User:NinjaRobotPirate/Animation hoaxer#Copycat is one particularly frustrating example. There are many others. NinjaRobotPirate (talk) 09:57, 11 September 2017 (UTC)

NinjaRobotPirate Looking at User:NinjaRobotPirate/Animation hoaxer#Copycat, these less than /64 (i.e. wider) ranges seem to be for wireless broadband. Now wireless broadband suppliers can use many /64 connections for the supply: the end result is that the range is far greater (or/<64). The reason for this is because in these circumstances radio towers (or combination of radio towers) will have access to many /64 connections; just like a wireless radio tower IPv4 would use a large variety of dynamic IPv4 addresses. Basically this is analogous to using several dynamic IPv4 connections, it implies nothing about connection subnets.

I see no particular evidence that ranges with a greater than /64 subnet are active; but even these can be explained by router alllocations giving a bigger than /64 (or narrower range) which is well within protocols; routers have no compulsion to use entire /64 ranges when allocating /128 addresses, only the connection itself must be at least /64. All this gives the impression of non-/64 connections which is simply not true.

Another way of looking at this: let's say I had a router with a /64 connection which allocated the same IPv6 address each time to my laptop. Now as far as my editing goes it would look like I was using a /128 subnet (i.e. a single IPv6 connection). While this would be true, nevertheless my connection to the ISP would be /64. --Jules (Mrjulesd) 17:34, 11 September 2017 (UTC)

The theoretical role of /64's is subordinate to their roles in practice, which is that since they don't necessarily represent single users and we want to utilize the finer granularity of IPv6 to reduce collateral damage, we can't treat /64's the same way we have been treating single IPv4 addresses.--Jasper Deng (talk) 05:08, 12 September 2017 (UTC)

That's true in theory but in practice Wikipedia has to be defended from brain-numbing nonsense that will eventually wear down the most dedicated editors. My suggestion would be to block IPv6 /64 when that is shown to be needed after blocking one or two individual IPs. Anyone adversely affected would have to make their case. Or, any concerned registered editor could point to a case where blocking a /64 resulted in a loss of encyclopedic content. Johnuniq (talk) 08:15, 12 September 2017 (UTC)

If I may try to summarise the above - would most people agree that if after directly blocking a single disruptive IPv6, another IPv6 from the /64 continues being disruptive, a /64 rangeblock would be the next step (as opposed to how we deal with IPv4s)? -- There'sNoTime ^{(to explain)} 08:22, 12 September 2017 (UTC)

Imo the best practice would be:

1. Check for collateral as a /64 block could definitely cause this (e.g. a corporation). Use the Gadget-contribsrange.js gadget to do so, and other whois services.
2. Check it's not a public mobile wireless connection: blocking these is like blocking dynamic IPv4 addresses, a bit pointless with the capability of causing collateral.

If you do these two steps then it should be OK to use /64 rangeblocks; appeals can be made on talkpages if users suffer significant collateral, just like Ipv4 blocks. --Jules (Mrjulesd) 10:57, 12 September 2017 (UTC)

FYI native support for range contributions (phab:T163562) is going out on this week's MediaWiki train. It is already on mediawiki.org (example). If all goes well, later this week you'll be able to query for IP ranges at Special:Contribs here on the English Wikipedia without the need for a gadget or wildcards. It will take a while for the data to backfill, so don't count on it working at Thursday's normal deploy time. I'll make a proper announcement once it finishes :) See also phab:T145912 which is like a power user range contributions tool. It's a long ways away but feel free to follow that task for progress updates — MusikAnimal ^talk 22:54, 12 September 2017 (UTC)

Copied from emails

I will block an IPv6 /64 range without a qualm, as it is practically always assigned to a single user. A block on such a range won't inconvenience anybody else. If you look at the three IPs in question, you'll see that their first four groups of figures are the same, 2a02:c7d:5d47:f900. That's the sign of a /64 range, and I have therefore, as I mentioned above, blocked the 2a02:c7d:5d47:f900::/64 range. Not just the three separate IPs, which would be like trying to empty the ocean with a teaspoon. If disruption from the range continues after the block expires, I'll be glad to re-block it for longer. (I made the first block pretty short so as to respect the block time Ian Thomson had applied to the Zjec account.) The new IP, 113.210.52.218, from Thailand, is something else. Darkknight, 113.210.52.218 has been blocked, and if Zjec comes back from yet another open proxy (which I suspect 113.210.52.218 is, because I don't think his ass is in Thailand; the IPv6 range he originally used geolocates to Suffolk), I suggest that should be the breaking point for semi.

You cut off the IP you have after the fourth group and add ::/64. So, block this:

2605:E000:99D5:B800::/64

Copied from 2016 CU nomination

Sure. We don't currently have an IPv6 range contribs tool, but it's really not that complex. This is a very basic, generalized statement so don't hammer me too hard on it, but the first hexadecimal block of an IPv6 address is a continent code (think ARIN or RIPE), the second is an ISP, and the third is an organization. If the /64 is the same (the first four blocks of hexadecimals), it's really, really, really, really likely we're dealing with one end user, even though there are still thousands of possible addresses in that /64 block. It can be broken down further into a /128, but that's not done very often and only under special circumstances. The CheckUser tool gives more information than just the IP address, though, and that will be very helpful in deciding when and how to place larger IPv6 rangeblocks. We don't have to do a lot of IPv6 rangeblocks larger than a /64 – I think I did a /47 once, which is an organization-level block, and I'm pretty sure that was the largest I've made. As to the collateral damage question for IPv4 ranges, I usually take a look at the last 30 to 45 days, sometimes a little less. If I see that 80-85% of the edits from that range are disruptive, I'll place the block. There are other factors I consider, including the history of the problem (there's a particularly troublesome LTA case that drives MILHIST crazy, and I've made a pretty big block for a pretty long period for that guy), how big the range is, and what kind of disruption it is (LTA vs. simple annoying vandalism vs BLP violations vs something else). Katietalk 2:05 pm, 29 September 2016, last Thursday (4 days ago) (UTC+1)

but the answer to my question wasn't exactly what I was looking for. "/64 implies same user" is not true as often as one would think it is, because webhosts, offices, mobile networks, and schools may have large number of hosts under the same /64 prefix (due to physical proximity) - these have to be handled on a case by case basis by checking WHOIS. Also, not every organization receives their allocation from an ISP (the US Department of Defense has an aggregate equivalent to roughly one /13!) and one should be ready to make large rangeblocks (on the order of /32) for webhosts. The largest non-webhost IPv6 rangeblock I've seen is a /38 currently in place against some mobile ranges. CheckUsers are permitted to check up to /32 for a reason.

'm only so familiar with the CheckUser tool (screenshots, etc), so should I be granted checkuser rights I would have a better answer for you. Based on what I do know, I think the current functionality should in many (most?) cases offer sufficient technical evidence, but for me anyway more weight is given to behavourial evidence, even if the technical evidence contradicts it. For instance, we may be dealing with a sock operating from multiple unique ranges while spoofing user agents. This surely is less common but it could happen, and in that case we have only behavioural evidence to go by. I'm not sure how much the planned overhaul would help in that scenario, but I believe we would still favour behavioural evidence given it is something we fundamentally need before doing checks — MusikAnimal t

Describe how much expertise you have with IPv6, especially as it pertains to how you would determine collateral damage.--Jasper Deng (talk) 5:45 am, 29 September 2016, last Thursday (4 days ago) (UTC+1) I've done a lot of reading about the advantages of IPv6 over IPv4, which I find very interesting, but for the purposes of range blocks I have a sufficient understanding. mw:Help:Range blocks/IPv6 is of some help, showing /64 range blocks and others that would generally safely belong to one customer of an ISP, but I believe this may vary provider to provider. This seems to hold true with the major ones however, such as Comcast, AT&T/U-verse, etc. Let's assume this isn't the case, or that we are unsure; Then you really have no idea the extent of collateral damage that may occur, especially at the organizational level, as there is no easy way to check the contributions. Hopefully we will soon have a solution, see phab:T145912. Full disclosure: I'll likely be a primary author of this tool. Being able to compute IPv6 ranges, assert collateral damage is minimal, etc, are currently important skills but I don't believe this should be a prerequisite for admins to issue range blocks, given the increasing prominence of IPv6 means your day to day patrolling at AIV (or as a checkuser) might require one to be effective. I could blab on about how the new tool will make this process easy for everyone, but in short, you won't find me issuing any range blocks unless I'm certain only the target end user is being affected (broadly speaking). See also phab:T5233 which means for your average end user a simple block will prevent further disruption without the need for a range block. In conjunction with the abuse filter we should be able to gauge how effective it is, but as you could imagine it will not work for our more prolific and tech-savvy LTAs — MusikAnimal talk

Describe how you would deal with IPv6 differently from IPv4.--Jasper Deng (talk) 6:12 am, 29 September 2016, last Thursday (4 days ago) (UTC+1) @Jasper Deng: Can you be more precise? I don't know what exactly you mean. Can you give some example? Vanjagenije (talk) 5:40 pm, 29 September 2016, last Thursday (4 days ago) (UTC+1) @Vanjagenije: In terms of assessing collateral damage, doing rangeblocks, determining identicalness of users, and the like.--Jasper Deng (talk) 5:50 pm, 29 September 2016, last Thursday (4 days ago) (UTC+1) I'm still not sure what exactly you mean, but I'll try to give an answer. As far as I know, IPv4 address has 32 bits, while IPv6 address has 128 bits. Address is made of two parts: first part identifies the network (range of addresses), while the second part identifies unique device. The range is denoted as, for example, "/24" which means that first 24 bits identify the network, while the rest identifies the host. Thus, in IPv4, a /24 network has 28 addresses, while in IPv6, a /24 network has 2104 addresses available. In IPv6, whole /64 subnetwork is usually assigned to the same user (single person or an organization), while in IPv4 it depends. A single user often has only one address assigned to them all the time (in IPv4), but sometimes the user gets a new address from the same network assigned to them every time they connect. Thus, in IPv6, a "/64" range of addresses (264 addresses) usually belongs to the same person, while in IPv4, a "/24" range (28 addresses) may belong to hundreds of users who share them. So, greater attention should be paid when blocking IPv4 ranges because of potential collateral damage. Also, in IPv4 it is harder to identify unique user by their IP address because a small range or even a single address may be shared by several users, while in IPv6, it is easier as the whole /64 range is usually used by one person. Vanjagenije (talk) 6:21 pm, 29 September 2016, last Thursday (4 days ago) (UTC+1)

Experienced SPI clerk, but not impressed by the answer to my question. The answer to "is this one user?" in IPv6 is also "it depends", it just depends on different things from IPv4. Despite the recommendation that each enduser receive a /64, this must be taken with a grain of salt. For example, mobile hotspots may each use a single /64 despite there being many users in close proximity. Use of WHOIS to find out the ISP and their allocation policy is very important.--Jasper Deng (talk) 6:26 pm, 29 September 2016, last Thursday (4 days ago) (UTC+1)

I can give you the technical description of the differences between IPv4 and IPv6 without having to look this up in the Wikipedia. This sort of thing was covered in my GSEC course (listed above). I can tell you, for example, that IPv6 addresses often contain the MAC address and that the MAC address is "guaranteed" to uniquely identify a network card (and therefore useful for checkuser investigations), though this guarantee is fairly easy to violate. I do want to be clear, though; my professional expertise with IPv4 is significantly stronger. IPv6 uptake in North America is significantly less than in other areas of the world, so I have not had to spend as much time with it. --Yamla

IPv6 users invariably use operating systems that enable privacy extensions, so as far as I know, few of the addresses can be relied upon to be the exact MAC address, and CheckUsers probably wouldn't find it that useful.--Jasper Deng