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.
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:
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.
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:
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_MACHINESYSTEMCurrentControlSetServicesTcpip6Parameters /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?
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.
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.