Are you ready for IPv6?
Written by Ed Fisher on February 15, 2011
In case you are one of the 17 people on the planet who frequent tech blogs but still haven’t heard, we actually are starting to run out of IPv4 addresses. IANA allocated the last ranges of IPv4 space to the regional registries last month, which many consider to be a sign of the end times…well, at least, a sign of the end of IPv4.
Does that mean the Internet is going to come to a halt? Hardly. The RRs have significant numbers (it varies from registrar to registrar) available to allocate. Do we need to start taking this seriously and get started with our IPv6 transitions and deployments? Absolutely. We’ve been hearing that IPv4 addresses were running out for ten years (at least) and that vendors would have to get it in gear to supporting IPv6. Those of you who have studied the OSI model may have bought into the belief that changes at layer 3 (the Network layer) would not require changes at higher levels, and that applications would continue to function as they always have. In theory, that is correct. But in reality; not so much.
While you should be testing IPv6 on your network now; getting your allocations, working with your WAN providers to start supporting IPv6, testing with tunnels (such as 6to4, Teredo, ISATAP) and evaluating your applications, note that even Exchange 2010 SP1 running on Windows Server 2008 R2 doesn’t fully support IPv6. There are some things you can do with Exchange 2010, and some things you cannot.
You can set up IPv6 tunnels between your locations and route email between sites using SMTP over IPv6. If your WAN provider offers IPv6, or you are using a publicly routed tunnel from a provider, you might be tempted to accept SMTP messages from others on your IPv6 network, however, Microsoft explicit recommends that you do not configure a receive connector to accept anonymous connections from an IPv6 address. If you wish to use SMTP across the IPv6 network, at present you should configure a separate receive connector and only permit email from known addresses, such as partner organization or affiliates that will be sending you email from known source addresses. That is rather limiting to say the least, and somewhat discouraging for early pioneers in the IPv6 space. Here’s a summary table, derived from http://technet.microsoft.com/en-us/library/gg144561.aspx
| Server role | Feature | IPv6 supported | Comments |
| Transport | IP Allow list and IP Block list | Yes | |
| Transport | IP Allow List providers and IP Block List providers | No | Most IP Block List providers don’t support IPv6 addresses yet. |
| Transport | Sender reputation | No | The Protocol Analysis agent doesn’t compute the sender reputation level (SRL) for messages that originate from IPv6 senders. |
| Transport | Sender ID | Yes | |
| Transport | Receive connectors | Yes | IPv6 addresses are accepted for the following components:
We strongly recommend against configuring Receive connectors to accept anonymous connections from unknown IPv6 addresses. If your organization must receive mail from senders who use IPv6 addresses, create a dedicated Receive connector that restricts the remote IP addresses to the specific IPv6 addresses that those senders use. |
| Transport | Send connectors | Yes | IPv6 addresses are accepted for the following components:
If you want to specify an IPv6 address for the SourceIPAddress parameter, make sure that the appropriate DNS AAAA and mail exchange (MX) records are configured correctly. |
| Transport | Incoming message rate limits | Partial | Incoming message rate limits that you can set on a Receive connector, such as the MaxInboundConnectionPercentagePerSourceparameter, the MaxInboundConnectionPerSource parameter, and the TarpitInterval parameter, only apply to a global IPv6 address. Link local IPv6 addresses and site local IPv6 addresses aren’t affected by any specified incoming message rate limits. |
| Unified Messaging | All features | No | Unified Messaging doesn’t support IPv6 in any version of Exchange 2010. Because the Unified Messaging server role doesn’t support IPv6, you may choose to disable IPv6 on those servers. |
| Mailbox (Database availability group member) | IPv6 addresses | Yes | Static IPv6 addresses are supported by Windows Server 2008 and the Cluster service. However, using static IPv6 addresses goes against best practices. Exchange 2010 on Windows Server 2008 doesn’t support the configuration of static IPv6 addresses during setup.Failover clusters support Intra-site Automatic Tunnel Addressing Protocol (ISATAP). They support only IPv6 addresses that allow for dynamic registration in DNS. Link local addresses can’t be used in a cluster.. |
Even with these limitations, you should still start evaluating the deployment of IPv6 on your network and include your email system in the testing. I hope we will see better support for IPv6 added in the next service pack for Exchange 2010 or perhaps even a hotfix, but to help ensure Microsoft understands this, ask your TAM about it every chance you get. Microsoft responds very well to customer requests, so let them know we need full IPv6 support in Exchange 2010, and are not willing to wait for the next major version.
What about your network? Have you started to use IPv6 yet?
February 15th, 2011 at 11:36 pm
I think you mean that IANA allocated the last of the IPv4 blocks this month, allocating a single /8 block to each of the 5 RIRs, rather than ARIN allocating the last of its addresses. Each /8 block consists of more than 16 million addresses, so it’s unlikely that ARIN have depleted their final allocation already.
February 17th, 2011 at 5:17 pm
Nice catch Richard, it is IANA and I updated the post. And IANA did allocate the last blocks to the RRs on 2011-01-31. ARIN and the other RRs do all have remaing addresses to allocate (as I mentioned in the second paragraph) but the source has been exhausted…what they have is all that there is left. Do we need to panic? No. Do we need to take IPv6 seriously? Absolutely. It’s time.