IPv6 Gotchas, and 8th June 2011

IPv6 has been 'imminent' for a very long time. However it's shortly going to have a bit of a boost. 8th June, 2011 is 'World IPv6 day' when various big players (Google, Facebook, Yahoo!, Akamai, ...) will enable IPv6 access to their services alongside the existing v4 access as a world-wide test flight for a wider deployment. In Cambridge, some of the services run by the University Computing Service will be participating.

For almost everyone this will make no difference at all - if, like most people, you only have have access to IPv4 then you will just go on using that as you always have. Likewise if you have working IPv6 you should see no difference even though you'll be using it rather more than normal. But if you have broken IPv6 support you are likely to have problems on the day. If you want to check, the test pages at http://test-ipv6.com/ and http://omgipv6day.com/ seem to be useful, and the University's My IP page will at least tell you if have IPv6 connectivity with the University.

It's possible to think of IPv6 as just IPv4 with longer addresses, but there are enough differences and gotchas to make life difficult for both clients and servers. Here are some that we've identified:

• Auto-configuration. IPv6 natively supports auto-configuration, so if you connect most (recent) computers to an Ethernet that includes an IPv6 router the computer will acquire an IPv6 interface complete with address and default route without you having to do anything. A computer with an active IPv6 interface will normally try to use IPv6 when talking to a service that advertises a IPv6 address, so you may find ourself using IPv6 without knowing it. This has a couple of exciting consequences:
• If the IPv6 router you contacted isn't actually connected to the v6 Internet then your traffic isn't going to go anywhere useful. Your computer will probably fall back to using IPv4, but probably after a long (multiple tens of seconds) delay. This is going to look to users as if the internet is going very s l o w l y. It's rumoured that some versions of Windows will under some circumstances spontaneously advertise themselves as IPv6 routers.
• Even if you are successfully using v6 (knowingly or otherwise), unless you do something your address won't be in the DNS. So looking it up won't result in a .cam.ac.uk (or whatever) host name, and services that make access control decisions based on client host name aren't going to recognise you. [Even if the service makes decisions based on address rather than host name it will get things wrong if its access control lists haven't been extended to include the necessary IPv6 range(s)].
• If a service advertises a v6 address but doesn't actually respond to requests on that address then again there could be a longish delay before your computer falls back to trying IPv4.
• It's entirely possible (though probably not a good idea!) for a service to behave completely differently when accessed over IPv6 from how it does over IPv4. For a start, the process of resolving host names to addresses is entirely separate for IPv4 and IPv6 so there's no particular reason for the two addresses to end up on the same server. Further, web servers providing virtual hosts need a mapping between IP addresses and the corresponding virtual hosts and it's all to easy (as the operators of www.ja.net found some time ago) to forget to extend this mapping to include v6 addresses, with the result that v4 and v6 users end up seeing the content for different virtual hosts when requesting the same URL. 
• The IPv4 address 127.0.0.1 always corresponds to the local computer and conventionally has the name localhost. It's quite common for components of a server to communicate using this address (e.g. a web application and its database), and equally common to actively restrict communication to this address or name. The coresponding v6 address is '::1' - if this doesn't correspond to the name 'localhost' or if access lists only recognise 127.0.0.1 then, if IPv6 is enabled on a server, it may find that it can't tall to itself!
• There are a lot of programs out there, in particular log analysis programs, that implicitly expect IP addresses to look like 131.111.8.46. Such programs may be 'surprised' to come across addresses like 2001:630:200:8080::80:0. How they behave will depend on how well they have been written, but in some cases this may not be pretty. Further, note that library calls that lookup v4 addresses to find the coresponding host name may not work with v6 addresses.
• Firewalls and packet filters will need IPv6 configurations to match their IPv4 ones, and they are unlikely to be able to automatically derive one from the other. So, by default, they are likely to either block all IPv6 traffic or allow it - neither is likely to be what's wanted.
• A lot of networks (especially home ones) use RFC 1918 'private' addresses and network address translation (NAT) when talking to the wider Internet. While not intended as a security measure, this does somewhat shelter machines on such network from active attack from the Internet. Use of private addresses and NAT are a response to the shortage of IPv4 addresses which isn't a problem in the IPv6 world, and so they are not widely supported (if at all). So enabling v6 on a previously 'private' network may expose previously hidden security vulnerabilities to the world, which may be unfortunate.

IPv6 is probably finally coming. Some of us may get an early brush with it on 8th June. It really is time to start thing about the consequences.