Part 1 The threat from the fast-dwindling supply of mainstream "IPv4" Internet addresses for new users is a bit like Y2K creeping up on us all over again. Almost no one can see beyond the cost of code review, systems change, hardware upgrades and general upheaval into the brave fairly-old world of IPv6 - but putting it off forever isn't really an option either. And like Y2K, if it's handled well, no one will ever notice or thank us "IT professionals" for it: we'll be accused of make-work, scare-mongering and overcharging. What's not to like?
Ultimately IPv6 will do away with the much of the annoyance of NATing, dynamic IP addresses, address rationing, etc, and should make for more efficient and cheaper communications. IPv6 support may soon be necessary to be reachable at all by some users.
IPv6 (or IPng: Next Generation) has been the future of the Internet for a decade and a half, so why the hesitation to get with the programme? It's probably a case of "if it ain't broken" and Y2K backlash, but the existing IPv4 address scheme is now broken and Y2K wasn't a figment of the imagination (I fixed a lot of finance-related bugs around then, trust me).
Anecdotally it seems relatively safe, for example, to implement dual-stack (ie with both IPv4 and IPv6 address) Web sites immediately. See the "heise online" IPv6 experience which was largely positive.
"The small number of flaws was so encouraging that heise online decided to adopt dual-stack for production use as soon as possible ... [users] do occasionally report problems. The majority of these continue to revolve around the flawed IPv6 implementations in Mac OS X, iOS and in the firmware of AirPort base stations. But the number of cases is far smaller than previously feared. Overall, heise online considers the switch a complete success, and would recommend it to any similar site."
8th June this year was "World IPv6 Day" http://www.worldipv6day.org/faq/ which was a global test of the new world order. It mainly worked, and almost no one noticed. In particular, bringing up IPv6 support didn't in practice hurt IPv4 users much or at all.
And just failing to plan for IPv6 at all doesn't just lose traffic and potential customers. It may also undermine your security too. You'd better plan those IPv6 security policies, keep an eye on rogue 6-in-4 tunnels (failing to upgrade your external links doesn't necessarily stop IPv6 getting in and out), and work to minimise the attack surface of already-IPv6-capable services and applications in house.
Netalyzr poised to start looking at my Internets
Let's put aside for the moment the matter of whether you're going to upgrade your client or app or server to support IPv6, what would need consideration if you did?
- Does your host/connection/routing even support IPv6 yet? And don't forget to include your connection, your servers' and your customers'/users' too.
- Do your routers, bridges and switches support IPv6?
- Does your DNS service support IPv6 (eg AAAA records, RFC3596) yet?
- Will your WiFi / IP phone / hot-desk systems work with IPv6?
- What parts of your code/system/logging are likely to break or otherwise need TLC?
- Are you intending to run dual-stack (ie both IPv6 and IPv4) from any/all hosts (servers, workstations, phones, gadgets)?
- How will you deal with IPv6 tunnelling, planned and rogue?
- How will your performance monitoring and user-tracking tools cope? (For example, do you track approximate user location by IPv4 address prefix?)
- Will your anti-DoS/anti-abuse mechanisms based on client address work?
- Have you the expertise to craft watertight IPv6 firewall rules, especially if you no longer use NAT and the protection it provides to internal machines as a side-effect?
- Since one way that hosts can create their own IPv6 addresses is to use their Ethernet MAC address, have you thought about the information leak that this represents, eg for road-warrior mobile users?
THE WEAKEST LINK IS YOU
Recent commodity operating system versions such as Windows and *nix (including Linux and Mac OS X), and language libraries (eg C/C++/C#, Java, etc) support IPv6 one way or another, and network tools and browsers generally do too.
So the weakest points are likely to be:
- Old in-house servers/OSes and routers/bridges/switches.
- Your ISP and its routers to the Internet cloud.
- Your in-house code, server- and client-side.
The first may not matter if those parts of your infrastructure can ignore the IPv6 world and, for example, talk only to other internal machines.
Do make sure that your ISP or hosting company can support IPv6: I can't get it over ADSL to my home office (yet) but it's been available at one of my colos (Bogons) for a while, though I was not taking advantage of it.
You may still be able to tunnel out to IPv6-land even if your ISP or hosting company can't deliver it directly. For example, moderately-recent Mac OS X contains a "6 to 4" tunnel that can be turned on from the "Network" System Preferences with a couple of clicks provided that your machine has a public IPv4 address and a tolerant firewall: job done.
Try http://test-ipv6.com/ to test your IPv6 connectivity quickly from your desk.
How http://test-ipv6.com/ looks in your browser when IPv6 tunnelling is working!
The real IPv6 Gordian Knot is likely in many cases to be that soup of half-brained it-kinda-works stuff known as in-house code. It may assume that an IP address is always 4 bytes (or can be entered or displayed as a dotted-quad) for example; think of space on reports, in database fields, log formatting, etc, etc.
So here is where you should start that Y2K-like testing: look for any references to, storage and logging of, and conversions to and from network names and addresses, especially IPv4, in the code: a decent IDE or static code analyser will help no end, but so can 'grep'.
And of course there is the magic of manual and automated testing: look at existing system unit and other tests, and write some more while you poke around.
For example, the (Java-based) site that I am adding IPv6 support to (it makes a slight effort not to be v6-foolish, but not much more) falls over spectacularly sometimes when I run up a local dev copy and connect to it locally as "localhost" rather than "127.0.0.1" because localhost sometimes gets expanded to the "::1" IPv6 loopback address and blows my code out of the water expecting a 4-byte address. So there's one area I could attempt to unit-test once I've drilled down to fix the root cause for example.
MY WAY ON THE SUPERHIGHWAY
So how was my experience in upgrading to support IPv6?
Well, it's not that I haven't thought about the coming upgrade fleetingly on and off for several years, so I didn't knowingly build anything stupidly incompatible. For example, for every OS install I did I made sure to enable IPv6 if that wasn't automatic, and all the variants of *nix, and the Java language that this site runs on, and my Tomcat servlet containers are all IPv6-friendly too.
But I kept running out of round tuits.
This time I stuck at it and spent maybe a day or two spread over 10 days to get to a working (not pretty, lots of rough edges to sand down) IPv6 server with its own DNS entries and ... ahem ... about 0.2% of my visitors!
The upgrade work was not that difficult in the end, especially as I wasn't in an externally-imposed panic. Do it before it does you!
In the next part I'll explain in more detail how I got on... ®
Some light IPv6 reading to warm up!
- WTF is IPv6?
- IPv6 tunnelling (see image)
- The Netalyzr detailed connectivity check (Java-based)
- The "heise Online" dual-stack experience
- Wiki goodness on IPv6 addressing
- World IPv6 Day FAQ
- After World IPv6 Day "the consensus was that more work needed to be done before IPv6 could consistently be applied".
- For RFC3596: DNS Extensions to Support IP Version 6.