Adventures in Tech: Dive on in, the IPv6 is lovely
Blub blub blub, no really it's great
Part 2 In the previous part I explored why you should limber up to IPv6 sooner rather than later, and now here's my experience actually walking the talk.
Importantly, mine is not a big-bang approach. I'm not trying to have everything perfect for IPv6 immediately, but rather I want to do just enough to be visible in the brave new world, safely, and tie up loose ends later as I go along.
I expect you to die, Localhost
First, I tackled an issue that'll make you bury your face in your palm: I mentioned in part one that, during development, using
localhost rather than
127.0.0.1 in my URLs when testing caused a messy Java stacktrace of doom -
localhost was expanded to IPv6 address
So after a little time isolating that issue and similar ones where I used the generic Java
InetAddress but actually assumed IPv4, and a sprinkling of unit tests to make sure that the bug should stay dead, I was done.
I spent maybe an hour or two tackling the main bug, but probably the rest of a day on some triage and holding fixes on less obvious stuff such as geo-locating users by their IP address, and even some simple frontline anti-denial of service attack code, which identifies potential troublemakers by a prefix of their IP address.
In IPv4 that network prefix is of variable length, but simply masking out the last (least significant) 8 to 10 bits does a reasonable job of pinning down individual (misbehaving) users or even companies/groups with fancy proxies that spread out their accesses across multiple outbound addresses, and without too much collateral damage.
In IPv6 the network part is fixed to be the first 64 bits (though you might still want to drop some of the tail end of that for various reasons), which makes things simpler, but still required me to expand my troublemaker lookup keys from 32-bit
Integer to 64-bit
Long. Something similar will be needed for the geo-location stuff, but no one will cry into their soup with my temporary fix just to disable it for IPv6 for now and let it continue as-is for IPv4.
What not to write! This example real code fragment will fail for IPv6 (though relatively cleanly) even though the method's signature misleadingly accepts any IP address.
Next, I went to get IPv6 working on my slightly ageing Solaris 10 box co-located with Bogons. After discussion we decided to move my host into a new address range, though I then stupidly applied the old one which caused some head-scratching for a while. Even the smartest tech can be defeated by my idiocy.
That aside all that was really needed to put up my wanted static address was to create a file:
bge0 being the name of the network interface device) and put in it the magic incantation:
addif WWWW:XXXX:YYYY:ZZZZ::2/64 up
WWWW:XXXX:YYYY:ZZZZ is my 64-bit network prefix.
Now pings in and out (eg to
ipv6.google.com) work fine. Hello, world!
This is much less messing around than IPv4 even for a static server address; in particular no default route has to be set as that is auto-discovered in IPv6.
At this point I also added a new connector definition to my Tomcat server (in
conf/server.xml) to bind to and accept the IPv6 connections as well as the existing IPv4, and brought up the new code and did some quick testing with the magic of a telnet to port 80 at the new IPv6 address.
<!-- Existing IPv4 connector. --> <Connector executor="tomcatThreadPool" port="80" address="22.214.171.124" protocol="HTTP/1.1" enableLookups="false" /> <!-- New IPv6 connector. --> <Connector executor="tomcatThreadPool" port="80" address="WWWW:XXXX:YYYY:ZZZZ::2" protocol="HTTP/1.1" enableLookups="false" />
I did find some other latent bugs when I added that, and so did another quick release. And in fact I winkled out a few more bugs in a few rapid rounds of upgrades. Users will have seen a few brief glitches, but I now had a working IPv6 and IPv4 site, though no one except me yet knew about the IPv6. Mwaha-ha-ha!
Tunnel of LOv6
I now wanted to be able to get out to IPv6 land from my own development machine to do more testing. Thanks to the Jobsian touch, and the fact that I have static publicly routable IPv4 addresses at my desk, enabling the "6 to 4" thang in Mac OS X 10.7 network settings (in the same pull-down as the VPN stuff) just worked. (Well, on the second attempt, after a bizarre boiler-plate error about a cable being disconnected, which is what I get when I try from NATted IP addresses such as when on 3G wireless.)
But after that I could ping IPv6 addresses on the Net from my machine, and look at IPv6-hosted pages such as Google's ipv6.google.com. And, most importantly, test out my own co-lo IPv6 site from my desk by using the literal IPv6 address in the form:
Also on the site is a page that shows what the browser's IP address is, and in that case it shows my Mac's (tunnelled) IPv6 address, so all is working.
What's in AAAA name?
The final step to your 128 bits of fame is to set up DNS records for the IPv6-enabled server. Initially I'm not going to bother with reverse-lookup (PTR) records, though I will do so eventually.
So all I need is the forward mapping from my example.com name to the IPv6 raw address. For an IPv4 address that's an 'A' record in DNS lingo. For an IPv6 address, with 4 times as many bits, it's an 'AAAA' record. Humour: we've heard of it.
That new record looks something like this:
ipv6.example.com. IN AAAA WWWW:XXXX:YYYY:ZZZZ::2
All my DNS stuff is built with scripts which build BIND9 config files from a hosts file, and I haven't yet adjusted them to recognise IPv6 addresses yet, so I had to slip the new record by pretending it was a mail record for now. Another rough-edge to clear up later!
But now with that AAAA record published and propagated I can put...
...in the browser on my MacBook and, ta-da, I'm in like Flynn!
After I'd tested that to my satisfaction I also added an AAAA record for example.com alongside the existing A records, so anyone enabled for IPv6, without any further effort and using the same search engine or URL, may silently get to use a IPv6 connection to the site instead.
And indeed, after a day or so to let the DNS records finish propagating, about 0.2 per cent of the traffic to my example.com site is over IPv6 with no other changes. I can see from the logs what appear to be fairly normal browsing patterns.
The site has risen without a trace!
Scouting for browsers
As described above there are various jobs to be done to make everything more robust, such as the reverse lookup (from IPv6 address to name) PTR records, the geo-location stuff, even putting IPv6 glue records in DNS ensuring that an IPv6-only client could get to the new server starting with the URL.
There are some more subtle tasks such as not handing out IPv4 addresses or IPv4-only URLs to clients that arrive over IPv6, in case they are not dual-stack, though that should be very rare for now.
But, all in all, the upgrade was a fairly painless journey and ensures that I'm well prepared as more traffic, eg, from mobile devices, is over IPv6.
Give it a whirl yourself, with a stealthy IPv6 launch. Get your pilot projects done sooner than later: be prepared, not panicked. ®