Today, I finally shed my ipv6 virginity. I did not act alone: friends encouragement, work provided impetus, and private charities provided the connectivity. But now, elastic.org has a proper IPv6 address in addition to its IPv4 one. So someday in 2050, when IPv4 is finally deprecated, this humble web site will remain accessible. Rejoice!

Some minor complications came up.

For the style of IPv6 tunnel being used, we got assigned both a /128 address for the tunnel endpoint, and a /64 network to be routed across the tunnel. That means that the server had two global-scope IPv6 addresses (the tunnel endpoint and another one on the /64 network). That in turn means that the IPv6 source addresses of outgoing connections become decided by coin tosses. But some lucky googling showed a working hack, involving labeling the tunnel address as “deprecated”.

Another issue is the choice of destination addresses for foreign servers that speak both IPv4 and IPv6. While RFC3484 defaults prefer IPv6, this is not appropriate if IPv6 is merely tunneled (thus lower performance than native IPv4). A hack to /etc/gai.conf fixed that mostly, except for some apps that do dns resolution on their own

Getting sendmail to listen on both IPv4 and IPv6 was obstructed at first by what seems like a sendmail bug. There were “cannot bind” errors. The following sendmail.mc bits got it working:

DAEMON_OPTIONS(`Name=MTA-v6, Family=inet6’)

DAEMON_OPTIONS(`Port=smtps, Name=TLSMTA, M=s, Family=inet6’)dnl

dnl commented out:

dnl DAEMON_OPTIONS(`Port=smtp, Name=MTA, Family=inet6’)dnl

Firewalling IPv6 was made easier by the near-substitutability of the iptables and ip6tables command lines.

Other stuff found so far was even simpler to reconfigure.