User:Jonathan de Boyne Pollard/Guide to blocking IP version 6 addresses

(English) This is an essay. It expresses the opinions and ideas of some Wikimedians but may not have wide support. This is not policy on Meta, but it may be a policy or guideline on other Wikimedia projects. Feel free to update this page as needed, or use the discussion page to propose major changes.

This is a Guide to administrators of Wikimedia Foundation wikis for blocking IP version 6 addresses. Edits from IP version 6 addresses have been occurring from the World IP version 6 Launch day (2012-06-06) onwards. This guide deals with the various issues of blocking edits from such addresses with the MediaWiki blocking tool.

A quick précis:

You'll have to recognize IP version 6 addresses properly; pseudonym accounts' usernames can resemble them.
Range blocking for IP version 6 addresses is more complex and you'll have to know some range blocking basics.

How to recognize IP version 6 addresses

As you can see from §2.2 of RFC 4291, there is a fair degree of flexibility in the human-readable representation of an IP version 6 address. MediaWiki, being a piece of software, doesn't make use of this, for consistency purposes. All IP version 6 addresses in MediaWiki follow a regular form:^{[note 1]}

MediaWiki doesn't employ the :: abbreviations from point #2.: IP version 6 addresses always have the fully-spelled-out address, with all eight 16-bit groups and without squashing groups that are zeroes. You'll see IP addresses represented as User:2001:DB8:0:0:0:0:0:0, not User:2001:DB8::.
MediaWiki doesn't add unnecessary leading zeroes.: IP version 6 addresses will only have a zero in the first place for a 16-bit group whose value is zero. You'll see addresses spelled as User:2001:DB8:16:5:0:ACE:BD1:7BE, not User:2001:0DB8:0016:0005:0000:0ACE:0BD1:07BE.
MediaWiki uses uppercase hexadecimal.: You'll see IP version 6 addresses spelled out as User:2001:DB8:16:5:0:0:ABCD:EF00, not User:2001:db8:16:5:0:0:abcd:ef00.

If you see something that looks like an IP version 6 address, but that has :: or unnecessary leading zeroes, or that uses lowercase hexadecimal, or that lacks the full eight groups, then it's possibly a pseudonym account, not an IP address. Several pseudonym accounts have been registered (over the past decade) with names that resemble human-readable forms of IP version 6 addresses. There's a pseudonym account named User:2001:db8 on the English Wikipedia, for example, registered in 2011. Don't mistake such accounts for IP version 6 addresses.

What to block and what not to block

A short backgrounder on how IP version 6 address space is parcelled out

Congratulations! You can put more devices on your LAN, and give them IPv6 addresses, than there are Ethernet cards in existence.

— Jonathan de Boyne Pollard, 2012-01

IP version 6 addresses are 128 bits long, with the upper (most significant) $N$ bits being a prefix and the lower $128-N$ bits having a prefix-determined meaning — usually, but not always, an ID of some sort. The way that (global unicast) address space is parcelled out is as follows:

The Internet Assigned Numbers Authority parcels out a short prefix, anywhere between 12 and 24 bits, to a Regional Internet registry (RIR) such as ARIN, APNIC, or RIPE.
The RIR parcels out longer prefixes, commonly 32 bits in length and that begin with one of its assigned prefixes, to a Local Internet registry (LIR), which is usually an Internet Service Provider.
The LIR parcels out even longer prefixes, anywhere between 48 and 64 bits (inclusively) and that begin with one of its assigned prefixes, to end user local area networks.

Don't rely upon stuff that's under the end-user's control.

Précis: End users have full control of everything following the prefix.

Technically, the remaining bits after the $N$ -bit prefix are an interface identifier. Received wisdom is that that's a MAC address and that it's 64 bits long. Actually it isn't, for three reasons:

It isn't always, or even often, 64 bits.: All residential customers of AT&T, for example, are allocated a 60 bit prefix.^{[note 2]} So they control the bottom 68 bits of their IP version 6 addresses. Most commonly, their routers are "customer premises equipment" owned by AT&T, and the 60-bit prefix is remotely programmed into their routers by AT&T. They can theoretically have 16 LANs, with every Ethernet card in existence on each one.
The use of MAC addresses has been optional since 2001.: There's an alternative scheme for end-user machines to construct their IP version 6 addresses, that generates them in a way that is unpredictable from outside of the machine. It is outlined in Narten, Draves, and Krishnan (2007), which is itself a successor to Narten and Draves (2001).
The bottom 64 bits are (if they are generated in the pre-2001 way) a modified EUI-64 address.: It's derived from a MAC address, using a simple arithemetic transformation, but it isn't the actual MAC address. It has 16 more bits than a MAC address, for a start.

Simply put, the two forms that you'll see of the subset of IP version 6 addresses that you'll need to deal with (more on which in a following section) are:

An IP v6 address with a "1" in bit #57 and FF:EF accross the 6th and 7th groups has a modified EUI-64 address in its bottom 64 bits. So, for example, User:2001:DB8:16:5:226:BBFF:FE12:2ACD is an IP version 6 address derived from the MAC address 00-26-BB-12-2A-CD.^{[note 3]}
An IP v6 address with a "0" in bit #57 has been generated by an end user machine in a fashion that cannot be predicted. So, for example, User:2001:DB8:16:5:55F8:1F6C:3C60:6FD6 is an RFC 3041 address.

The whole point of this mechanism was to prevent people in exactly your situation from being able to draw a correspondence between one IP version 6 address and another, by comparing the bottom 64 bits of addresses and tracing people from place to place around Internet by their personal computers'/mobile telephones'/tablet computers' mEUI-64 addresses; and it has been around longer than any of these WMF wikis have.

Don't expect talk pages to be a reliable way to contact people.

Précis: If an end user is using a recent version of Microsoft Windows NT, they usually won't have the same user talk page for more than 7 days in a row, because their IP version 6 addresses change every 7 days.

Microsoft calls IP version 6 address generated in the RFC 3941 way "temporary address interface identifiers" (see Microsoft (2003a)). A Windows computer will calculate a new address on a regular basis. By default, that's every time that it is bootstrapped and every 7 days it is running thereafter. That means that every 7 days the bottom 64 bits will change, in a way that neither you nor anyone else apart from that machine's system administrator, can (practically) predict.

In Windows Server 2003, whose manual page was just referenced, this is a mechanism that is disabled by default, and that end-users have to turn on with the

netsh interface ipv6 set privacy state=enabled

command, as you can see from the manual. In Windows Vista and Windows Server 2008, this changed. The default with Microsoft Windows is now, and has been since 2007, to use RFC 3941 by default. The use of modified EUI-64 addressing (the pre-2001 way of doing things that allows people to be traced around the Internet by their mEUI-64 addresses) is now something that has to be turned on, with the

netsh interface ipv6 set global randomizeidentifiers=disabled

command.^{[note 4]}

Don't block "everything else".

Précis: Don't block any IP version 6 address whose most significant 16 bits (the first group of hexadecimal digits) are outside the range 2001 to 2C0F.

The only IP version 6 addresses that you'll need to block are so-called global unicast addresses. Don't block IP version 6 addresses that are not global unicast addresses. In theory, every IP version 6 address that doesn't begin with the following prefixes is a global unicast address:^[2]

the 127-bit prefix of all zeros (0::/127)^{[note 5]}
the 10-bit prefix 1111111010 binary (FE80::/10)
the 8-bit prefix 11111111 binary (FF00::/8)
the 7-bit prefix 1111110 (FC00::/7)^[3]^[4]^{[note 6]}

Do not ever block IP version 6 addresses with those prefixes.^{[note 7]}

However: In practice, now and probably for the next decade at least, IANA is only handing out prefixes that begin with the 3-bit prefix 001 binary (2000::/3).^[5] Only (approximately) one seventh of the potential global unicast addresses specified by RFC 4291 §2.4 will be in use as such by IANA.^[3] If you see an IP version 6 address whose most significant 16 bits (first 4 hexadecimal digits) are outside the range 2000 to 3FFF, then beware. Someone is mucking around. Indeed, as of 2012, IANA has not handed out any prefixes whose most significant 16 bits are outside the range 2001 to 2C0F.^[5]

Range blocking is the norm.

Précis: Always remember the /N suffix when you block, and N must be between 32 and 64, usually somewhere between 48 and 64 (inclusively) in practice.

As noted in the preceding backgrounder, LIRs parcel out prefixes ranging from 48 bits to 64 bits in length to end user customers. End users are assigned control of anywhere between the bottom 64 and the bottom 80 bits of their IP version 6 addresses. This is intentional.^[6] Whereas in the IP version 4 world LIRs handed out single IP version 4 addresses, and multiple ones only at a premium, in the IP version 6 world LIRs hand out to end users address space for at least a whole LAN (a 64 bit prefix with a 64-bit node identifier) or even multiple LANs (e.g. a 56 bit prefix with an 8 bit net ID and a 64-bit node identifier).^{[note 8]}

So it's pointless blocking a single, 128-bit, IP version 6 address. The person being blocked has more IP version 6 addresses to play with, and easily switch to, than there are Ethernet cards in existence. Range blocking is the norm, not the exception, for IP version 6, so get used to that.

The longest prefix that you'll have to range block in practice is 64 bits. As for the shortest prefix: Remember from the backgrounder that usually RIRs parcel out 32-bit prefixes to LIRs. You'll in practice never want to block anything higher up the hierarchy than an LIR (an ISP, a large business, or another large organization). If you do, you'll be range blocking entire continents. Indeed, it's rare that you'll want to block an entire LIR. So don't even consider prefix lengths shorter than 32 bits, and be very wary of considering prefix lengths shorter than 48 bits.

There's a whole load of new "sensitive" addresses to remember.

Here are some of them:

"Sensitive" IP version 6 addresses
Address(es)	Reason
2620:0:860::/46	The 46-bit prefix for IP version 6 addresses used by the Wikimedia Foundation. Bear in mind that this prefix terminates halfway through the last hexadecimal digit, so that last digit can be 0, 1, 2, or 3.^{[note 9]}
2002:1828:88FB:0:DCAD:BEFF:FEEF:202/128	Server Abscissa on ClueNet, which hosts English Wikipedia ClueBot.

Your wiki may have additional "sensitive" IP addresses that you should not block. The English Wikipedia, for example, has a list at Wikipedia:Blocking IP addresses#Sensitive IP addresses of governmental and other organizations that it would be politically embarrassing to block. Such lists will vary from wiki to wiki, according to readership, language, and other factors, and you'll need to check the specifics for the wiki that you are blocking on.^{[note 10]}

It is unfortunate that, as of June 2012, none of those wiki-local lists contain the IP version 6 addresses used by the organizations listed. So it is necessary to check first, by looking the IP version 6 address up in the various Internet Registry databases, the WWW lookup tools for some of which (depending from your wiki's administrators) may be conveniently hyperlinked on the contributions list page for the IP address. It is — alas! — also unfortunately the case that, as of June 2012, several Internet Registries do not provide IP version 6 lookup capability.^{[note 11]} So such database lookups are not as simple an exercise as is the case for IP version 4 addresses.

Footnotes

↑ Note that MediaWiki does not use the canonical IP version 6 human-readable form recommended by RFC 5952 § 4. That RFC mandates lowercase hexadecimal and the use of :: to shorten as much as possible where there are two or more successive zero groups.
↑ In the 2010 Google IPv6 implementors conference, Chris Chase of AT&T stated that AT&T's planned deployment of IP version 6 was to use IPv6 rapid deployment (known collquially as "6RD"), with trials in 2011 and deployment in 2012.^[1] AT&T allocated the 24-bit prefix 2602:300::/24 in June 2011. In 6RD, the ISP's prefix is followed by 32 more bits, making a total of 60 bits as the prefix length that AT&T gives to each customer.
↑ From its first three octets, 00-26-BB, one can then further deduce that this MAC address has something to do with Apple Computers.
↑ See Davies (2008) for more information.
↑ i.e. both ::0/128 and ::1/128
↑ This is not specified in RFC 4291 §2.2.
↑ They are loopback/unassigned, link-local, and multicast addresses, respectively.
↑ The ISP of the person whom I congratulated had allocated a 64-bit prefix to its customer.
↑ The WMF has what is known as a "direct allocation from ARIN, rather than an allocation via a LIR, which it obtained under older ARIN rules in 2006. Hence the short 46-bit prefix despite the fact that current ARIN policy is to prefer prefix lengths that are multiple of 4 and so.^[7]
↑ On the Macedonian Wikipedia, for example, its list at w:mk:Википедија:Блокирање на IP адреси#Сензитивни IP адреси includes the government of the Republic of Macedonia.
↑ For one example: TWNIC, the Internet Registry for Taiwan, has not provided IP version 6 address lookup capability, as of June 2012, and erroneously thinks that IP version 6 addresses are domain names.

References

Sources used

Number Resource Policy Manual. 2012-02-10. Version 2012.2
R. Hinden and R. Haberman (2005). Unique Local IPv6 Unicast Addresses. RFC 4193. IETF.
R. Hinden and S. Deering (2006). IP Version 6 Addressing Architecture. RFC 4291. IETF.
S. Kawamura and M. Kawashima (2010). A Recommendation for IPv6 Address Text Representation. RFC 5952. IETF.
T. Narten, G. Huston, and L. Roberts (2011-03). IPv6 Address Assignment to End Sites. BCP 157/RFC 6177. IETF.
IANA (2012a). IPv6 Global Unicast Address Assignments. 2012-05-30.
IANA (2012b). Internet Protocol Version 6 Address Space. 2012-05-30.
Chase, Chris (2010-06-10). AT&T broadband transition to IPv6 using 6rd Google IPv6 Implementors Conference 2010.