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 (8)

  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.

Skip to main content