Jump to content

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

From Meta, a Wikimedia project coordination wiki
Browse history interactively
← Older editNewer edit →
Content deleted Content added
VisualWikitext
Let's have this over to the side.
various incorrect terms here, and still too technical.
Line 3: Line 3:


A quick précis:
A quick précis:
* You have to recognize IPv6 addresses.
* IP version 6 addresses now have accounts, just like IP version 4 addresses; you'll have to recognize them properly.
* Range blocking for IP version 6 addresses is the ''norm'', not the exception; you'll have to know some range blocking basics.
== How to recognize IP version 6 address accounts ==
== How to recognize IP version 6 address accounts ==
As you can see from §2.2 of [[#REFRFC4291|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 that flexibility, however. (It's a piece of software. It's consistent, not smart.) All IP version 6 accounts in MediaWiki follow a regular form:
As you can see from §2.2 of [[#REFRFC4291|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 that flexibility, however. (It's a piece of software. It's consistent, not smart.) All IP version 6 accounts in MediaWiki follow a regular form:
Line 22: Line 21:
:Précis: ''Don't block any IP version 6 address whose most significant 16 bits (first 4 hexadecimal digits) are outwith the range 2001 to 2C0F.''
:Précis: ''Don't block any IP version 6 address whose most significant 16 bits (first 4 hexadecimal digits) are outwith 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:<ref name="rfc4291-2-4" />
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:<ref name="rfc4291-2-4" />
* the 127-bit prefix of all zeroes (0::/127)
* the 127-bit prefix of all zeroes (0::/128)
* the 10-bit prefix 1111111010 binary (FE80::/10)
* the 10-bit prefix 1111111010 binary (FE80::/10)
* the 8-bit prefix 11111111 binary (FF00::/8)
* the 8-bit prefix 11111111 binary (FF00::/8)


Do not ''ever'' block IP version 6 addresses with those prefixes. They are [[w:en:loopback interface|loopback]]/unassigned, [[w:en:link-local address|link-local]], and [[w:en:IP multicast|multicast]] addresses, respectively.


''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).<ref name="IANA2012a" /> Only (approximately) one seventh of the potential global unicast addresses specified by [[#REFRFC4291|RFC 4291]] &sect;2.2 will be in use as such by IANA.<ref name="IANA2012b" /> If you see an IP version 6 address whose most significant 16 bits (first 4 hexadecimal digits) are outwith the range 2000 to 3FFF, then beware. Someone is mucking around. Indeed, as of 2012, IANA has not handed out any prefixes whose most signficant 16 bits are outwith the range 2001 to 2C0F.<ref name="IANA2012a" />
''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).<ref name="IANA2012a" /> Only (approximately) one seventh of the potential global unicast addresses specified by [[#REFRFC4291|RFC 4291]] &sect;2.2 will be in use as such by IANA.<ref name="IANA2012b" /> If you see an IP version 6 address whose most significant 16 bits (first 4 hexadecimal digits) are outwith the range 2000 to 3FFF, then beware. Someone is mucking around. Indeed, as of 2012, IANA has not handed out any prefixes whose most signficant 16 bits are outwith the range 2001 to 2C0F.<ref name="IANA2012a" />
=== Range blocking is the norm. ===
=== Range blocking is the norm. ===
:Pr&eacute;cis: ''Always remember the <code>/N</code> suffix when you block, and '''N''' must be between 32 and 64, usually somewhere between 47 and 64 in practice.''
:Pr&eacute;cis: ''Always remember the <code>/N</code> suffix when you block, and '''N''' must be between 32 and 64, usually somewhere between 47 and 64 in practice.''
As noted in the preceding backgrounder, LIRs parcel out prefixes ranging from 47 bits to 64 bits in length to end user customers. End users are assigned control of anywhere between the bottom 64 and the bottom 83 bits of their IP version 6 addresses. This is intentional.<ref name="rfc6177-2" /> 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).<ref group=note>The ISP of the person whom I congratulated had allocated a 64-bit prefix to its customer.</ref>
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.<ref name="rfc6177-2" /> Whereas in the IP version 5 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).<ref group=note>The ISP of the person whom I congratulated had allocated a 64-bit prefix to its customer.</ref>


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.
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 47 bits.
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 47 bits.

Revision as of 00:58, 5 June 2012

This is a Guide to administrators of Wikimedia Foundation wikis for blocking IP version 6 addresses. You will start seeing edits from IP version 6 addresses 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 have to recognize IPv6 addresses.

How to recognize IP version 6 address accounts

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 that flexibility, however. (It's a piece of software. It's consistent, not smart.) All IP version 6 accounts in MediaWiki follow a regular form:

MediaWiki doesn't employ the :: abbreviations from point #2.
IP version 6 account names always have the fully-spelled-out address, with all eight 16-bit groups and without squashing groups that are zeroes. You'll see accounts named User:2001:DB8:0:0:0:0:0:0, not User:2001:DB8::.
MediaWiki doesn't add unnecessary leading zeroes.
IP version 6 account names will only have a zero in the first place for a 16-bit group whose value is zero. You'll see accounts named User:2001:DB8:16:5:0:ACE:BD1:7BE:F532, not User:2001:0DB8:0016:0005:0000:0ACE:0BD1:07BE:F532.
MediaWiki uses uppercase hexadecimal.
You'll see accounts named 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 account. 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 address accounts.

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) bits being a prefix and the lower 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:

Don't block "everything else"

Précis: Don't block any IP version 6 address whose most significant 16 bits (first 4 hexadecimal digits) are outwith 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:[1]

  • the 127-bit prefix of all zeroes (0::/128)
  • the 10-bit prefix 1111111010 binary (FE80::/10)
  • the 8-bit prefix 11111111 binary (FF00::/8)


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).[2] Only (approximately) one seventh of the potential global unicast addresses specified by RFC 4291 §2.2 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 outwith the range 2000 to 3FFF, then beware. Someone is mucking around. Indeed, as of 2012, IANA has not handed out any prefixes whose most signficant 16 bits are outwith the range 2001 to 2C0F.[2]

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 47 and 64 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.[4] Whereas in the IP version 5 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 1]

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 47 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.
2002:1828:88FB:0:DCAD:BEFF:FEEF:202/128 Server Abscissa on ClueNet, which hosts English Wikipedia ClueBot.

Footnotes

  1. ↑ The ISP of the person whom I congratulated had allocated a 64-bit prefix to its customer.

References

Cross-reference

  1. ↑ Hinden and Deering (2006) §2.4
  2. ↑ a b IANA 2012a
  3. ↑ IANA 2012b
  4. ↑ Narten, Huston, and Roberts (2011) §2

Sources used

Retrieved from "https://meta.wikimedia.org/w/index.php?title=User:Jonathan_de_Boyne_Pollard/Guide_to_blocking_IP_version_6_addresses&oldid=3811142"