Editor's Note: After our test, we disabled ipv6. Currently ipv6 capable MX servers are not on our immediate roadmap, but we do plan to enable ipv6 sometime in the future.
This is a technical blog post about FastMail's support of an internet standard called ipv6. Most users shouldn't notice any difference at all, and can ignore this post. For those interested, we've included some description about what we've done to support ipv6.
We didn't actually get organised enough to register ourselves for world ipv6 day, but we got ipv6 up and running in time, so we've enabled it anyway. You can read more about ipv6 day here: http://www.worldipv6day.org/
Our prefix for NYI is 2610:1c0:0:1:: - and for convenience we're mapping all the IP addresses from our ipv4 space (220.127.116.11/24) as direct offsets into that ipv6 space. All the public service IPs are now bound in ipv4 and ipv6. There was some magic requried to support our failover system because Linux doesn't offer an option to bind non-local ipv6 addresses - so we do a little dance where the address is bound to the loopback interface on one machine as a /128 (host only) address - or to the external interface as a /64 (fully networked) address depending on where the service is located. It seems to work OK, which is the main thing!
Due to rbl issues and the lack of working reverse DNS, we have not enabled ipv6 for inbound or outbound SMTP, and our DNS server doesn't support ipv6 connectivity, so all your DNS queries will still be over ipv4.
The domains with ipv6 support (AAAA records) are:
This will pick up the majority of web, imap, pop and smtp authenticated traffic. If you have ipv6 connectivity, you should be transparently using ipv6 now. We are getting random bits of ipv6 traffic in the logs, so it's clearly working.
Our FTP server doesn't support ipv6 EPRT and EPSV commands, so I haven't added a record for ftp.messagingengine.com.
You can also try ipv6.messagingengine.com if you want to guarantee you're using ipv6 only. That host doesn't have an A record for ipv4.
Unless there are reports of significant problems with this experiment, we will remain dual stack into the future :)