Sunday, May 8, 2011

Is IPv6 Another Y2K-like Effort?

This weekend I spent a significant amount of time enabling my personal server systems for IPv6.  IPv6 is the next generation Internet Protocol (IP) system with the most visible change being a new style network address.

For those unaware, a (very) brief background (since you can search online and get much more details):  Right now you use addresses that look something like (4 sets of number separated by dots).  Each computer that speaks IP - the "language" of the Internet - has one of these addresses.  When you type something like, the name you type gets translated to one of these addresses.  When the system was rolled-out in the early 1980s, nobody expected that the Internet would grow to what it is now.  At this point, the number of systems exceed the useful capability of that addressing system, and we have run out of addresses.  This system was called IP version 4 (IPv4).

A new addressing system was developed as part of IPv6 that expands that address significantly.  IPv4's address is 32 bits long, whereas IPv6 has a 128 bit address. IPv4 has 4 numbers from 0 to 255 separated by dots, and IPv6 has 8 sets of 4 hexadecimal numbers separated by colons (as in 0123:4567:89ab:cdef:0123:4567:89ab:cdef).  This address space is, for all reasonable purposes, effectively unlimited, and provides ample growth for the current Internet and what is expected in the future.  Again, this is a simplification of IPv4 vs. IPv6 and there are additional improvements, but the most significant change is the addressing.

The problem:  The IPv4 and IPv6 addressing systems are not compatible.  This has been the biggest obstacle to moving the Internet as a whole to IPv6 over the past 15+ years that the topic has been discussed and implementation done.  We have been using some tricks (NAT, for example) to extend the IPv4 space to avoid the eventual IPv6 adoption...but we have now reached the exhaustion of the IPv4 space and the conversion to IPv6 is inevitable.

This problem is much like the Y2K problem that peaked 11 years ago:  Most computer programs prior to 2000 were written with the idea that they wouldn't last until the year 2000 and beyond.  When the mid-1990s approached and it was clear that people would still be using this software in the year 2000 ("Y2K"), an extensive (and expensive) effort was undertaken to convert all the older software the function properly when the calendar advanced to the year 2000.  This magnitude of effort will be necessary for the IPv4 to IPv6 transition.  Much of the software we use is not currently capable of supporting the new IPv6 addressing, and fixing some of it will be a major undertaking.

As I mentioned previously, I decided to proceed with updating my personal server systems to support IPv6 and connect them to the IPv6-enabled Internet backbone via a tunnel provided by Hurricane Electric (  These are Linux-based systems that support an e-mail, web, time, and secure shell services.  One server is my home server that also handles some of my web browsing and other home management services.  Getting the IPv6 tunnel working was very easy thanks to Hurricane Electric's excellent documentation and sign-up process.  Getting the tunnel going really was the easy part, though.  Here are some things I didn't initially think about that had to be done:
  • Firewall - My Linux-based iptables-based firewall had to be set-up to filter the IPv6 traffic as I have been doing with IPv4.  Thankfully, Linux provides ip6tables with the more recent kernels that allows this to be easily done.  Most of the rules I used for IPv4 were applicable to IPv6.  However, be aware that there is no firewalling by default, even when iptables has been used for IPv4.  So setting up an IPv6 firewall should be done prior to bringing-up IPv6 on your system.
  • sendmail - My sendmail configuration is somewhat complex, with a custom-designed milter interface to spamassassin.  Unfortunately, there were portions of the milter that were not written to handle IPv6 addresses (and needed to do so), so a small part of that C code needed to be rewritten.  That small part took about 3 hours to re-code and test.  Furthermore, it was not straightforward to get sendmail to listen to both IPv4 and IPv6 addresses.  The following (non-obvious) configuration was necessary:

    FEATURE(`no_default_msa', `dnl')dnl
    DAEMON_OPTIONS(`Port=submission, M=Ea, Name=MSA, Family=inet6')dnl
    DAEMON_OPTIONS(`Port=smtp,Name=MTA, Family=inet6')dnl

    It seems that sendmail automatically listens on the IPv4 interfaces as well as IPv6 when IPv6 is enabled...but that also wasn't readily apparent.

    I also had a perl-based procmail script that went into an infinite loop when it encountered IPv6 addresses in one of the headers, which took about an hour or so to locate (I kept blaming sendmail).  Also don't forget about things like the accessdb that may have hard-coded IP addresses in it (you may also need to include IPv6 addresses in there!).
  • DNS/bind - AAAA records needed to be set-up for the new IPv6 addresses...but what took the most amount of time (something like 2 hours) was trying to get the localhost records coded correctly.  I would document my work here, but I'm still not convinced I have it working correctly yet.  I also had to explicitly tell named to listen on IPv6 addresses using the following line in the options section:

    listen-on-v6 { any; };

    Again, obvious, but not the default, and leaving it out means the nameserver won't answer requests from IPv6 hosts.
  • web server - I use lighttpd as my web server software (not apache) on my Internet-facing server.  Again, what seemed like it should have been obvious took an obscure configuration option.  To make the web server listen on the IPv6 interfaces, I had to add the following to the lighttpd.conf file:

    $SERVER["socket"] == "[::]:80" { }  # bind to IPv6 also!

    This line forces the server to listen to the "zero" (meaning any) IPv6 address as is done with IPv4.
While I have gotten a good deal accomplished, I still have a number of things to do on my non-Internet-facing server.  There, I have MySQL, the apache web server, Asterisk PBX, and MythTV, among other things, to IPv6-enable, if even possible.  What worked perfectly right away was the Firefox web browser.  Note that to go directly to an IPv6 address directly (instead of by name) in Firefox, you need to enclose the address in brackets, as in:


Otherwise, it thinks you're trying to go to a weird symbolic name of some kind.

I think it is definitely time to start moving to IPv6...and in order to do that, we need people who have expertise in doing so.  My suggestion to network and system administrators is to use your home systems as test cases now so you understand some of the pitfalls of IPv6 implementation on a smaller scale.  Doing a more large-scale enterprise is going to require a more substantial effort, and if you don't have the basics mastered the effort will be much more difficult.  IPv6 conversion is not forgiving at all.  However, preparing for the transition of the global Internet to IPv6 needs to happen, and once the task is complete, it will quietly fade into the background as yet another major effort in computing history (just like Y2K).


Interceptor said...

I've always wondered what ever happened to IPV5.......

cpu said...

There's a whole bunch of articles on the 'net dealing with this topic (just google ipv5).

In short, IPv5 was an experimental stream protocol (see RFC1190) that was designed for guaranteed quality-of-service for multimedia-type applications. It doesn't appear to have really gone anywhere.

If you ask me, just a brief browse of RFC1190 makes me kind of glad that IPv5 never really went anywhere...