IPv6 TunnelMy lab is on a small business connection from the local cable company. We have a small range of fixed IPv4 addresses, but no IPv6 support. I solved this problem by obtaining a free IPv6 tunnel from Hurricane Electric Internet Services www.tunnelbroker.net. They make it easy to configure, and even give you the netsh commands to configure your server to use the tunnel.
netsh interface teredo set state disabled
netsh interface ipv6 add v6v4tunnel IP6Tunnel
netsh interface ipv6 add address IP6Tunnel 2001:470:7:305::2
netsh interface ipv6 add route ::/0 IP6Tunnel 2001:470:7:305::1
Since my server is NATted, I had to use the internal IPv4 address in the netsh command.
Exchange 2010I would like to say that there was a lot of configuration involved, but it just worked. I had learned earlier that Exchange 2010 automatically looks for AAAA records when doing DNS delivery. This lab environment is a pretty basic install, a single multi-role Exchange 2010 on Windows Server 2008 R2. Of course, to receive e-mail, you will need to have an MX record. The tunnel provider assigns a quad A record to your IPv6 address, I simply changed the MX record to point to that FQDN.
exchangelab.info MX preference = 10, mail exchanger = JosephDurnal-1-pt.tunnel.tserv13.ash1.ipv6.he.net
Of course, you could configure your own AAAA record if you'd like (I did this too).
I did some additional experimenting with mixing IPv4 & IPv6 in the MX record. In doing so, I also created a separate receive connector for IPv6 to make it easy to figure out what was what. Testing Testing my lab was also pretty easy. First, gmail supports IPv6, so when I sent my first e-mail to gmail, the headers were all IPv6! Additionally, there are some test reflectors out there (email@example.com & firstname.lastname@example.org) that are only supposed to receive e-mail on IPv6 and will send a response with the headers, both use IPv6 for the reply by default, so looking at the headers of their replies will let you know if your IPv6 is working. In addition, I have configured protocol logging on my send and receive connectors to verbose, enabling me to verify in the logs that IPv6 was being used for message transfer (you can also see this in the message tracking log).