Disabling IPv6 And Exchange – Going All The Way


When we are performing the Exchange Risk Assessment, one of things PFE love to check is how servers have been configured for IPv6.  There have been numerous occasions where we have found servers whose admin has said that they have disabled IPv6, but when you look at the server it is not really disabled. 

When we take a look at the Exchange server, the initial clue is that the network card’s TCP/IPv6 configuration looks like this, where IPv6 is unselected from the NIC. 

IPv6 Unbound From Network Card

There seems to be a belief that the simple act of clearing this ticky box disables IPv6 on the server.  That is not the case.  If we check the IP information we quickly see something like this:

IPv6 Components Still Enabled With IPv6 Unbound Fron Network Card

ISATAP is part of the IPv6 protocol stack, so IPv6 is blatantly not disabled on this box…..

This is pretty frustrating, as this is a well documented process and a quick search using one’s favourite search engine quickly shows the steps required. 

But let’s ask if IPv6 really should be disabled. 

 

Stop, Hammer Time!

As Joseph Davies  very eloquently said back in 2009 :

It is unfortunate that some organizations disable IPv6 on their computers running Windows Vista or Windows Server 2008, where it is installed and enabled by default. Many disable IPv6-based on the assumption that they are not running any applications or services that use it. Others might disable it because of a misperception that having both IPv4 and IPv6 enabled effectively doubles their DNS and Web traffic. This is not true.

From Microsoft's perspective, IPv6 is a mandatory part of the Windows operating system and it is enabled and included in standard Windows service and application testing during the operating system development process. Because Windows was designed specifically with IPv6 present, Microsoft does not perform any testing to determine the effects of disabling IPv6. If IPv6 is disabled on Windows Vista, Windows Server 2008, or later versions, some components will not function. Moreover, applications that you might not think are using IPv6—such as Remote Assistance, HomeGroup, DirectAccess, and Windows Mail—could be.

Therefore, Microsoft recommends that you leave IPv6 enabled, even if you do not have an IPv6-enabled network, either native or tunneled. By leaving IPv6 enabled, you do not disable IPv6-only applications and services (for example, HomeGroup in Windows 7 and DirectAccess in Windows 7 and Windows Server 2008 R2 are IPv6-only) and your hosts can take advantage of IPv6-enhanced connectivity.

 

Exchange 2007, 2010, and Exchange 2013 support IPv6 with the details for each release contained within the documentation for the relevant product.  Note that a dual stack configuration is required.  In other words, for IPv6 to be supported IPv4 must also be enabled. 

 

Disabling IPv6

As discussed in KB 929852 the IPv6 configuration can be tuned or disabled via the registry.  This is the DisabledComponents entry which is located here:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip6\Parameters

Setting DisabledComponents to 0xff disables all IPv6 components except the IPv6 loopback interface. This value also configures Windows to prefer using IPv4 over IPv6 by changing entries in the prefix policy table

REG.exe query HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip6\Parameters /v DisabledComponents
 

One thing to note is the value specified above for DisabledComponents. It is 0xFF and not 0xFFFFFFFF. Why you may ask as 0xFFFFFFFF was what was documented, no?

Well yes it was, but it transpires that this adds a 5 second delay to the boot process. Way back with Vista 0xFF was the value used, and the documentation got out of alignment.

  

Concluding Notes

Unless there are specific reasons for disabling IPv6 please do not do it.  Microsoft tests Exchange with both IPv4 and IPv6 enabled, i.e. the default configuration. 

One common theme you will pick up from my blog posts, is that walking the most frequently trodden supported path is a good thing since issues are less likely to crop up.  If an issue does occur, then the priority of a fix being quickly developed is very high.  Corner cases will get less priority and this can cause the fix to be delayed. 

Please follow the official documentation and KB articles to disable or optimise the IP stack. 

If there is a business case for disabling IPv6 then do so using the above procedures.  For example there is a case for disabling specific IPv6 features in an Exchange 2007 and 2013 coexistence environment as discussed in KB 2794253

 

Cheers,

Rhoderick

Comments (10)
  1. anonymouscommenter says:

    Since we are still in the early stages of the year, and Exchange 2013 SP1 is now available, we will see

  2. anonymouscommenter says:

    I have Server 2012 R2 installed running Exchange 2010 Sp3 , the DNS name resolution does not work if I have IPv6 enabled but when I disable IPv6 it starts working. Should I leave IPv6 disabled will it cause issues to my Exchange server??

  3. anonymouscommenter says:

    I have Server 2012 R2 installed running Exchange 2010 Sp3 , the DNS name resolution does not work if I have IPv6 enabled but when I disable IPv6 it starts working. Should I leave IPv6 disabled will it cause issues to my Exchange server??

  4. anonymouscommenter says:

    I have Server 2012 R2 installed running Exchange 2010 Sp3 , the DNS name resolution does not work if I have IPv6 enabled but when I disable IPv6 it starts working. Should I leave IPv6 disabled will it cause issues to my Exchange server??

  5. anonymouscommenter says:

    I have Server 2012 R2 installed running Exchange 2010 Sp3 , the DNS name resolution does not work if I have IPv6 enabled but when I disable IPv6 it starts working. Should I leave IPv6 disabled will it cause issues to my Exchange server??

  6. Sorry Israr – Exchange 2010 is not supported on that version of Windows.

    http://blogs.technet.com/b/rmilne/archive/2013/09/17/exchange-support-for-windows-server-2012-r2.aspx

    Cheers,
    Rhoderick

  7. Sean says:

    “Unless there are specific reasons for disabling IPv6 please do not do it. ”

    Here is a specific reason: Man Hours. The sheer amount of man hours involved in tracking down issues caused by IPV6 on windows server is ridiculous. If MS wants administrators to keep IPV6 enable they may want to think about properly implementing it in their products. If I ever meet Bill Gates I will punch him in the face for instilling stubborn arrogance as a corporate value.

  8. @Sean
    What are the issues that you are experiencing w/ enabled IPv6 and Exchange Server?

    1. dasoussan says:

      Let me give you a real world example. I have a client in Exchange 2010 R-latest as of a week ago. They were bought out, parent company forced them to switch a bunch of stuff including their internet connection to a particular AT&T managed network based firewall type product, DNS moved to another AT&T arm, etc. There was no mention of IPv6 prior to this migration and everything worked perfectly.

      In the migration, their IT admin lost the ability to do a lot of things they used to be able to do themselves or via a web portal… things like tweaking DNS records. Now it takes a trouble ticket entry that might happen in a few days or might not. Not a Microsoft problem but theirs.

      All of a sudden they are getting email bounces off many of their customers and supplier email servers:

      “550 5.7.1 Sender ID (PRA) Not Permitted”

      For some reason Exchange has started sending emails to some places via IPv6 instead of IPv4 and their SPF records don’t indicate any IPv6 records as valid. Everything is working like it is supposed to … except for the critical communications that are bouncing.

      The correct answer is to fix the SPF record. AT&T still hasn’t answered the IPv6 question (“What is their block?”) nor have they deleted the TXT/SPF record as we requested many days ago. AT&T Fail – huge – this is just one of many issues we’ve encountered.

      Since the correct fix isn’t something that can be implemented in a reasonable period of time, Plan B was to shut down IPv6 – the article referenced the registry tweak which did not work as the server was still sending IPv6 emails and they were still bouncing (and yes we rebooted the server just in case). In this case I call it a Microsoft Exchange Fail.

      Plan C: (what I did yesterday) was pull DNS hosting out of AT&T’s hands which goes against corporate’s desires but local management approved and was able to kill their SPF record for now until we hear back from AT&T and can then re-implement it with their entire IPv6 block properly allowed. In the interim, I could use info from the bounce message to detect the IPv6 addresses but I won’t until I hear back from AT&T because they might not yet be set to static.

      The real operating business world doesn’t always work well when inflexible parts appear or strange interoperability issues rear their ugly heads. Being able to adapt what is in your hands quickly and efficiently so “IT just works” is always preferable to becoming visible as a reason things aren’t getting done. The factory shutting down and losing millions of dollars because parts can’t be ordered due to some inflexible bit of IT infrastructure or interoperability problem is bad. It also adds fuel to “Lets just migrate to gmail” … until they experience some interoperability issue and then good luck getting it fixed in any reasonable timeframe.

      Just my thoughts, worth exactly what you paid for them…

Comments are closed.

Skip to main content