Friday, September 07, 2012

Put your Exchange lab on the IPV6 Internet

I've been working on a project with a United States Federal Government customer that requires their e-mail system to operate on the public IPv6 Internet. I've spent a lot of time waiting for the customer's network to be configured for IPv6, but now that the deadline is near I realized that putting an Exchange system on the Internet is one of the few things that I've never done before and I didn't want to do it for the first time on a customer system and that I would want a way to reliably test the customer's configuration. Putting my Microsoft Exchange 2010 lab onto the IPv6 public Internet would solve both problems.

IPv6 Tunnel

My 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 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 2010

I 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. MX preference = 10, mail exchanger =

Address: 2001:470:7:305::2

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 ( & 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).


Putting my lab on the IPv6 public internet was easier than I thought. More and more customers are considering IPv6 functionality, and many US government agencies are under a mandate to support IPv6 on their public facing systems. Even though it is easy, there is no reason to do it in production for the first time, put your lab on IPv6 and experiment, gaining experience as you go.

No comments: