IPv6 for Wikimedia
==================
## Overview ##
[IPv6](http://en.wikipedia.org/wiki/IPv6) is a new version of the
[Internet Protocol](http://en.wikipedia.org/wiki/Internet_Protocol),
designed to replace the ageing IPv4. IPv6 is designed to co-exist with
IPv4 on the Internet, to allow a gradual transition from one to the other.
Wikipedia, and the other projects, should be available as IPv6.
## First efforts ##
Once upon a time, for a very brief period, Wikipedia was available via
IPv6. Much of the same solutions proposed here were used, but a lack of
prior planning and testing breaved the result of the stability required
to offer a suitable quality of service to users:
+ Use of the [Hurricane Electric](http://www.he.net/) tunnel provider
meant that European users (who, currently, represent a very large
percentage of total IPv6 users) had very high latency to the site.
+ The `mod_proxy` systems were themselves serving other high-load
activities, leading to additional slowness and, sometimes, downtime.
Mainly because of these problems, IPv6 support was withdrawn from the site
after only one or two weeks of operation. Any future effort will need to
be planned and executed in such a way that this doesn't happen again.
## The problem ##
There are a number of problems to overcome before we can offer IPv6 services
to users:
+ An IPv6 connection is required. The most likely place to this to occur
is on the knams cluster, for several reasons. Firstly, it is nearly
directly connected to [SURFnet](http://www.surfnet.nl/). SURFnet, as
an education and research network, has a well-developed IPv6 infrastructure
already. Although Kennisnet (our network provider) has not yet deployed
IPv6, they are likely to do so at some point in the future.
Secondly, SURFnet offers IPv6 tunnels, to allow disparate networks to
connect to the IPv6 Internet without native connectivity. As SURFnet is
so close to our network, the result is that we have near-native IPv6
connectivity.
+ IPv6 support is required in our applications. There are two main places
it's needed: in Squid, and in MediaWiki. Squid is the most obvious; it needs
to support IPv6 in order to accept and forward requests from clients.
MediaWiki needs to provide support for identifying IPv6 IPs, and allowing
them to be blocked.
## The solution ##
### IPv6 connectivity ###
This is partially solved using an IPv6 tunnel. However, there are some design
decisions that need to be made. The most important is where the tunnel terminates.
Ideally, it would connect directly to our switch; however, Cisco's pricing for
IPv6-capable firmware is ridiculous (around US$10,000), which we cannot really
justify spending. A second choice solution, then, is to terminate it at a
stable host system. `pascal.knams.wikimedia.org` is the most likely candidate
here. This system will act as the router for all other systems.
### Software support ###
There was, at one time, an [IPv6 branch](http://squid.sourceforge.net/ipv6/) for
Squid. However, it appears to be based on an older version of Squid, and there
hasn't been any work done on it for a while.
While adding IPv6 support to Squid is the most obvious solution, there is another,
easier way of doing this: run another proxy server in front of Squid.
[Lighttpd](http://www.lighttpd.net/) and [Apache](http://httpd.apache.org/) both
provide IPv6 support and have proxying capabilities. By putting one of these
between the IPv6 Internet and Squid, IPv6 requests can be forwarded to Squid
for normal processing.
This leaves MediaWiki. An old version od MediaWiki (1.3.x) had some IPv6 support,
but this was never added to the HEAD branch, and does not exist in the current
versions. Hopefully, this should not be very difficult to re-implement.
## Progress ##
So far, the implementation is still at very early stages. A tunnelled connection,
using the [SixXS](http://www.sixxs.net) tunnel broker and SURFnet, has been
established for a single host, `zedler.knams.wikimedia.org`. If this works without
problems for some time, the tunnel can be reassigned to `pascal`, and basic IPv6
connectivity provided for the knams cluster.
After this, some non-essential services, such as mail and (non-wiki) WWW, can be
offered over IPv6.
And then... the world!
## Notes ##
+ Redundancy: Jeroen Massar (of SixXS) suggests using two tunnels with an IGP
routing protocol for failure between two machines. Combined with a failover
system at our end (VRRP, or something similar), this should provide good
reliability. At least until SURFnet breaks :-)
+ [Polipo](http://www.pps.jussieu.fr/~jch/software/polipo/) -- a lightweight
HTTP proxy which could go in front of Squid.