Network Development Team

I bet you didn’t think you had IPv6 connectivity yet (certainly in any University department). After all we’re still working through our plan to light up IPv6 services in the core. Well, news flash: if you’re running Windows 7 in the University it’s likely you can already access IPv6 services.

How so? By means of what we call tunnelling mechanisms. The Internet standards designers realised that during the transition to full IPv6 access there would be islands of IPv4-only and IPv6-only systems. The idea was to create some simple transitioning mechanisms by which systems in these islands could still talk to the rest of the Internet, be it IPv4 or IPv6.

Windows 7 ships with a number of tunnelling mechanisms enabled by default, and they pretty much all work in the same way. Your client wraps up the IPv6 packet inside an IPv4 packet and fires it off to a Relay Server out on the Internet somewhere. The Relay Server has both IPv4 and IPv6 connectivity so extracts the IPv6 content and sends it natively to the target server. The reply is somewhat similar, and usually some fancy IP addressing rules are used to allow traffic to find its way back to your client.

Note that depending on local department and college firewall configurations, some of the tunnelling mechanisms may not work.

Teredo is a common tunnelling mechanism which is used when the client is on an RFC1918 IPv4 address (sometimes called private addressing), often what you get behind NAT. 6to4 is another mechanism, this time one which requires a publicly routable IPv4 address (so is common at our institution as most clients have that configuration).

There are a few issues with tunnelling mechanisms, however:

1. They don’t promote setting up native IPv6 connectivity
2. There are security concerns because your traffic (potentially local traffic between two University systems) goes via a Relay Server on the Internet
3. Performance may be poor because of the latency introduced by relaying out to the Internet or because the Relay Server is congested

The second point is particularly interesting to the Network Development and Network Security teams in OUCS. We’d much rather traffic local to the University didn’t relay via some untrusted server potentially on the other side of the world, and the tunnelling also makes it difficult for us to monitor for and catch malware-infected clients like we can do for IPv4.

Confider for example an IPv4 workstation in a department connecting to the IRC service irc.ox.ac.uk, which has now been IPv6 enabled. The Windows 7 client is on IPv4 and the server is on IPv6. Due to the default configuration of Windows and Microsoft’s interpretation of the RFCs a tunnelled IPv6 connection will be preferred to a native IPv4 connection (the IRC service still runs on IPv4, too!).

1. Client is on IPv4 and asks a DNS server for the IP(s) of irc.ox.ac.uk
2. DNS resolver replies with both 129.67.1.25 (A record) and 2001:630:440:129::407 (AAAA record used for IPv6 addresses)
3. Windows 7 spots it’s on a publicly routable IPv4 address so starts up a 6to4 tunnel
4. A connection to 2001:630:440:129::407 is made over the 6to4 tunnel, via a Relay Server on the Internet

By the way, one mitigation technique is to use an SSL connection to the IRC server, which we support 🙂

To protect collegiate University interests, OxCERT took the decision to place a block on Teredo traffic (udp/3544) at the University JANET-connection firewall. We’ve recently also been looking at the 6to4 mechanism — but then hit a stumbling block…

Ideally we’d like to run a local 6to4 relay so that University systems can still use this transition mechanism. I set one up on a development server at OUCS. This server needs, due to the way 6to4 works, to be able to send IPv6 traffic with source addresses in the IPv6 range 2002::/16. Fair enough, our backbone can deal with that.

However at our connection to JANET it turns out that the JANET-UK engineers implement some IP address filters (and quite rightly so). Only IPv6 addresses in Oxford’s 2001:630:440::/44 range are permitted onto JANET, and the 2002::/16 packets are dropped on the floor 🙁

The net effect is that sadly I can’t run a local 6to4 relay for us in Oxford, at least not without persuading JANET-UK to change their configuration policy for connected institutions. I’d quite like to do that: it seems a little unfortunate to assume we won’t want to use these transition mechanisms (and various other IPv6 goodies which use non site-specific addresses). However as I know what they’re likely to be doing in the configuration (uRPF) and I understand its limitations, I agree it would be more work for them, although not impossible by any means, to implement smarter access control lists.

Curiously, JANET-UK does not filter what we receive, only what we send. For instance we receive lots of spoofed packets from the Internet which are dropped by our JANET-connection backbone router. I suppose it’s their implementation of “be liberal in what you receive, conservative in what you send.”

The upshot of all this is that from a Windows 7 box on a publicly routed IPv4 address you probably can already ping6 ipv6.google.com, or visit http://www.kame.net/ and see a dancing turtle. I’m glad for that – IPv6 isn’t scary, and is here and alive and working well. However I’d much prefer us to be able to provide an improved and safer experience when you are inadvertently using IPv6, as will become all the more common in the future.

If we accept that use of 6to4 is inevitable then we (JANET-connected institutions) should also be able to run a local 6to4 relay for:

1. Network security – to monitor for and catch malware-infected clients
2. Network performance – to avoid “tromboning” local traffic via a remote (and untrusted/congested/etc) server on the Internet

Do any other institutions feel the same way? Are we barking up the wrong tree? I’d appreciate feedback in the comments section below. Regardless, good luck with your IPv6 transition — exciting times!