As a part of the he.net IPv6 certification program, you have an opportunity to earn extra points by daily activities: IPv6 traceroute, AAAA dig, IPv6 PTR dig, IPv6 ping, and IPv6 whois. Among those, I would say the most commonly used by me are ping and traceroute, then the digs and finally whois. But I use ping and ping6 everyday. Yes, the tool to ping something is actually 2 tools. It seems odd that while so many other programs seamlessly handle both network protocols just fine, this one requires a whole new binary. The ‘route’ command, is a single binary, using a command line argument ‘-4’ or ‘-6’ to determine which protocol to use. It defaults to IPv4, since that was around first. On the other hand, nc, dig, ssh/scp, telnet, mtr, wget, curl, ip (though it uses ‘inet’ and ‘inet6’), and many more default to IPv6, only choosing IPv4 if specified or if it is the only protocol available. Then we have the dark side: ping/ping6, traceroute/traceroute6, iptables/ip6tables (along with the -save and -store variants), and maybe some others.
What prompted the authors of those programs to fork the code to add IPv6 support? I would bet that most of the logic is the same. In fact the man page for ping lists ping6 too; they have the same options. Why can’t I just say `ping -6 he.net` or `traceroute -4 google.com`? Last night, I finally got fed up with ping and wrote a little python wrapper for ping, which parses the arguments, ignoring all except ‘-4’ and ‘-6’ and then passing everything else on to the appropriate ping. If neither ‘-4’ nor ‘-6’ are passed, it does a quick dig for an AAAA address to test if the remote host is even capable of IPv6 and then automatically chooses the right ping. I shouldn’t have to do this though. Please give me a reason besides breaking legacy stuff to have an entirely new program. Legacy is not a good enough reason, you can only pack around so much baggage before it pulls you down. Just ask Intel. 🙂
Finally, you have the ubiquitous browsers, which if they are well behaved do both IPv4 and IPv6, favoring the latter when it is available (and not even really letting you pick or telling you what you are using; the only way to know for sure is to have the webserver report you IP address). This is helpful for the chicken/egg scenario that we are seeing with this transition. We don’t need to support IPv6, nobody is using it. But if we can at least get all the dual-stack folks to use it by default, that will give a little push. This leads us to other services. Most of the services that I have come across now support IPv6 as well; http (apache2, lighttpd, cherokee, and more), smtp (postfix, exim, qmail, and more), imap (courier, uw-imap, and more), dns (bind, dnsmasq), and many more. The services vary on whether they listen by default on IPv6 if it is available. Most you have to configure to suppress IPv6 support; that is a good default.
The truth is, most people don’t care about the transition to IPv6; most don’t even know what IPv6 and don’t want to know. But the end of IPv4 is looming on the horizon and it may hurt when it gets here unless we, the geeks who run the networking backbone of the planet, make sure we are ready. The current policy of many applications to default to IPv4 for legacy’s sake needs to stop. If the computer has IPv6 connectivity, it should be using that by default and falling back to IPv4 only when explicitly requested or when the service is not available on IPv6. Then we just have to get all those lumbering service providers to move. But there’s no business justification for IPv6…. Make one and save the planet.