Wikipedia

User:Jasper Deng/IPv6

< User:Jasper Deng
This guide is for a rather technical audience. See /non-technical for a non-technical guide.

This page documents my proposed guidelines for when Wikipedia enables IPv6 access, which occured on 6/6/12, with limited production testing on 6/2/12-6/3/12.[1] Comments are welcome on the talk page.

Background information

edit

The IP addresses you see are normally IPv4 addresses, 32 bits long. The format is like 123.234.236.2, with each group of numbers representing 8 bits. However, this does not allow enough combinations to allow for sufficient addresses for the 50 billion Internet devices forecast for a few years from now.

IPv6, in contrast, has 128-bit addresses (so there are enough for the foreseeable future), in forms like 2001:db8:9023:acef:f90a::, where each group of numbers represents 16 bits, and each digit is base 16 (such that a,b,c,d,e, and f represent single-digit values of 10,11,12,13,14, and 15, respectively). IPv6 addresses can vary in spelling; see below for getting familiar with IPv6 and its addresses.

Use of rangeblocks

edit

All discussion of rangeblocks uses CIDR notation.

Rangeblocks are to be used based on whether the user gets uses his/her range or not, because each individual user often will get a full range of addresses (/64 or larger), instead of a single address. Blocks of addresses that do not start with 2 or 3 (outside of 2000::/3) may not normally be used, as no computer that edits Wikipedia will have such addresses. Exceptions include ::1, similar to 127.0.0.1.

However, do not block a range unless it is clear that multiple addresses in that range are being disruptive. Do not be tempted to block a /64 unless multiple IP addresses in the range are being disruptive. This is against common conceptions, but a big purpose of enabling IPv6 on a wiki is to reduce the collateral damage of blocking a single IPv4, which often has the effect of blocking an entire local area network for one user's offense. This does not, however, apply to most webhosts, and in fact, most large IPv6 rangeblocks are for webhosts, which tend to host open proxies.

Maximum range sizes

edit

The technical limit is /19 for rangeblocks. Normally, however, very large rangeblocks (in general, larger than /48) are to be only used in extreme cases, except for where the collateral damage is extremely minimal and/or where the range is a webhost range (which tends to host open proxies).

6to4 addresses

edit

6to4 uses the following format for its ranges: 

2002:(/16 of IPv4 address):(Remainder of IPv4 address)::/48

When an IPv4 address or range is blocked, its corresponding range in 6to4 may be blocked if it appears to be active. The ranges that would be used by the WMF's 6to4 gateways, 2002:d050:9800::/38 and 2002:5bc6:ae00::/40, must never be blocked.

IPv4 range size 6to4 IPv6 range size
/32 or single address /48
/31 /47
/30 /46
/29 /45
/28 /44
/27 /43
/26 /42
/25 /41
/24 /40
/23 /39
/22 /38
/21 /37
/20 /36
/19 /35
/18 /34
/17 /33
/16 /32

Teredo

edit

Teredo hosts present a major complication because they use an address format that does not work very well with rangeblocks based on CIDR notation. IPv6 hosts connecting through Teredo should have their server's prefix (a /64 in the form of 2001:0000:(/16 of IPv4 server address):(remainder of server address)::/64) blocked in the case of massive Teredo IP hopping. Rarely, if the server happens to occupy a large range in IPv4, a rangeblock up to /48 (corresponding to blocking the server's /16) may be used. Alternatively, a bot can find teredo servers, and block all single addresses containing a specific IPv4 client IP address and a server IPv4 address, which can be blocked as well as a signal to the bot.

While Teredo should not present much of a problem because it is not expected to be widely used, Teredo servers can be treated as open proxies if abused.

Some tunnelbrokers

edit

This section concerns guidelines for certain tunnelbrokers.

Tunnelbroker name Public IPv6 prefix(es) Subnet size Notes
Gogo6 (freenet6) (No longer operational) 2001:5c0::/32
2406:a000::/32		 /56 or /128, see notes 2001:5c0:1000:b::/64 is a static range. Block only single addresses in that range. 2001:5c0:1000:a::/64 is dynamic and you should block the whole range if possible, because this range is much like an open proxy. 2001:5c0:1100::/40 contains user ranges up to /56 in size, so make all blocks in this static range /56 in size. A similar range is 2406:a000:f000::/40. A user may get up to one /56 in the latter range, and up to two in 2001:5c0:1100::/40.
Hurricane Electric (tunnelbroker.net) 2001:470::/32 /48 or /64 Users may get up to 10 total /48 and 10 total /64 prefixes each (5 BGP tunnels, 5 regular tunnels). Do not block these addresses for very extended periods of time because they can change. However, consider each subnet static.
SixXS (sixxs.net) (No longer operational) Various /64 or /48 (/48 only to experienced users) This tunnelbroker provides WHOIS at whois.sixxs.net which also discloses the IPv4 address for the tunnel endpoint on the user side. Most users will have /64 tunnels (<prefix>::1 is the PoP, <prefix>::2 is the user) and /64 subnets routed toward that tunnel, optionally along with a routed /48 which can be requested with ISK. First contact abuse sixxs.net and report the problem, this way the problem can be properly resolved at SixXS already. Optionally block the ranges specified in each prefix listed on the page linked at left, as necessary (only when IP hopping occurs). Note that users can have both a /64 and /48. The number of tunnels one can create with this broker is theoretically unlimited (experience in the form of ISK is required to create tunnels and subnets).

When using CheckUser for tunnel-broker addresses, geolocation and WHOIS are not reliable sources of geographical location for these addresses.

*.sixxs.org IPv6 to IPv4 and IPv6 to IPv4 website proxy

edit

SixXS formerly provided the IPv6Gate and IPv4Gate services (http://www.sixxs.net/tools/gateway/). These allowed IPv4 users to access websites that are IPv6-only and vice versa.

Both the User-Agent and the Forwarded-For header indicated which type of proxy is used (IPv6Gate or IPv4Gate) and what the real source IP address is. This information is only available to CheckUsers.

Adding URLs that end in .sixxs.org has been blocked, since as those sites are identical to the real sites as they are proxied, the real sites thus should be used (thus without the .sixxs.org extension). Anonymous editing through IPv6Gate/IPv4Gate is blocked, but users who are logged in can edit if given global IP block exemption.

Blocking IPv4 and IPv6 simultaneously

edit

The correspondance of an IPv4 and IPv6 subnet can be found by seeing if their DNS names are similar enough, especially with businesses that get static addresses and have their own domain names. However, it is otherwise difficult to find the correspondance between two IPv4 and IPv6 addresses, especially when no DNS information is available. In any case, most browsers and operating systems prefer one protocol by default, so it is not necessary to block one of an IPv6/IPv4 pair pre-emptively due to abuse from its counterpart.

Tor nodes

edit

Tor officially supports IPv6[2], other hacks to make Tor IPv6 capable can and definitely do exist. An IPv6 Tor node, if verified, should be blocked for a limited period of time, especially for tunnelbrokers. The IPv4 address should be blocked similarly because TOR uses both kinds of addresses, although that may be difficult to find and the two may be treated as separate nodes.

Sensitive address ranges

edit

Block lengths

edit

Block lengths of 6to4 address ranges should be the same as their corresponding IPv4 address. Single IPv6 addresses, unless static, must not be blocked for long periods of time, but their subnets can be.

Unresolved issues

edit

The deployment of IPv6 is currently complicated by the following problems:

  • CheckUser is complicated by the presence of two IP versions, especially with tunnelbroker addresses. CheckUser can only check a /64 at most (CheckUser can now check ranges up to /48/32).
  • Autoblocks would have to be modified to cover an entire /64 instead of a single address. (bad idea)
  • When a teredo server is blocked, there is a lot of potential for collateral damage due to the number of users that could be blocked.
  • Twinkle, Huggle, and other tools will have to undergo extensive modification to gain IPv6 support.
    • There was no need for extensive modifications to Twinkle: this was seemingly the only change needed
  • IPv6 addresses may easily overflow edit summaries because of their potential length (39 characters, vs. IPv4's 15 characters), especially when one IPv6 address's edit(s) is/are rolled back to a version by another IPv6 address.
  • The increased use of CIDR notation, 6to4, and other technical terms will make it more difficult to understand.
  • The large number of users of tunneling and other transition mechanisms increases the number of hosts that fall under our definition of open proxies.
  • An IP address' subnet's talk page needs to trigger a "You have new messages" notice for all affected IP addresses; this can be done by a bot, or mw:Extension:AlternativeUserTalk can be used. (not feasible, nor a good idea)
  • Usernames are not restricted from being IPv6 addresses. This will automatically have to be prevented by the MediaWiki software, and older accounts renamed and/or blocked or locked. Accounts with the potential format of a valid IPv6 address or range will have to be renamed, blocked, and/or locked. (bugzilla:33853)
  • Issues that must be resolved off-wiki:
    • The GlobalBlocking extension does not implement IPv6 global blocks unless a potentially difficult schema change is made first (Schema change was accomplished on 16 May 2012).
    • The WMF's database needs schema changes to accommodate IPv6 addresses, it being created long before IPv6 was anticipated The schema changes were accomplished on 16 May 2012.
    • Squid, a web caching software used by the WMF, does not support IPv6 in its current configuration. It will have to be either upgraded to a newer version, or (at least for IPv6) superseded.
    • LVS, the load-balancer, needs to be upgraded. Unfortunately, its IPv6 support is still experimental.

Current status of IPv6 deployment on the Wikimedia Foundation

edit

There were conflicting reports on the target day for deployment on the Wikimedia Foundation. According to one WMF representative discussion, the Wikimedia Foundation then had plans to only do a temporary stack test instead of a permanent deployment.[3] However, according to the roadmap, there were conflicting reports that the system administrators indeed had plans to deploy IPv6 for testing purposes on the World IPv6 Launch day (6 June 2012), and only leaving it on if there are no huge issues discovered.

The WMF could not participate in World IPv6 Day because database schema changes could not be made in time.[4] Nevertheless, on 21/22 March 2012, ARIN CEO John Curran allegedly requested that the WMF be ready for World IPv6 Launch.

Required schema changes were completed by 17 May 2012.

Deployment was successfully complete by the end of 6 June 2012, but many of the issues on this page are still potentially valid. In addition, some services besides the production wikis, such as Gerrit Code Review and Wikimedia Labs, still do not support IPv6 access.

See also

edit

Notes

edit
  1. ^ E-mail from deputy director of WMF
  2. ^ Tor Project IPv6-related Blog posts
  3. ^ Talk page discussion with WMF member
  4. ^ Note from a WMF representative
Retrieved from "https://en.wikipedia.org/w/index.php?title=User:Jasper_Deng/IPv6&oldid=812154063"