Hey, y’all, Mark back with some new info on two of my favorite topics, IPv6 and Slow Boot Slow Logon (SBSL). If you’ve disabled IPv6 long ago this post is one you’ll want to pay attention to. Let’s dig in and get you up to speed.
What’s Microsoft Recommend Setting for IPv6?
The long standing recommendation has been to leave IPv6 and IPv4 enabled on post XP Windows clients and server. The point is covered in the “What are Microsoft’s recommendation about disabling IPv6” section of the IPV6 FAQ:
“It is unfortunate that some organizations disable IPv6 on their computers running Windows 7, Windows Vista, Windows Server 2008 R2, 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 7, Windows Vista, Windows Server 2008 R2, or 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.”
Leaving IPv6 enabled on current Windows client and server operating systems remains the best practice configuration. The PFE blog team has written several posts around IPv6:
Why you need to care about IPv6- http://blogs.technet.com/b/askpfeplat/archive/2013/06/17/ipv6-for-the-windows-administrator-why-you-need-to-care-about-ipv6.aspx
IPv6 Fundamentals- http://blogs.technet.com/b/askpfeplat/archive/2013/06/24/ipv6-for-the-windows-administrator-ipv6-fundamentals.aspx
IPv6 Subnetting, address autoconfiguration, router advertisements- http://blogs.technet.com/b/askpfeplat/archive/2013/07/08/ipv6-for-the-windows-administrator-more-ipv6-subnetting-zones-address-autoconfiguration-router-advertisements-and-ipv4-comparisons.aspx
The 2002 Address and its impact- http://blogs.technet.com/b/askpfeplat/archive/2013/11/18/ipv6-for-the-windows-administrator-the-2002-6to4-tunnel-address-and-its-impact.aspx
How name resolution works in a dual IPv4/IPv6 scenario- http://blogs.technet.com/b/askpfeplat/archive/2013/11/11/ipv6-for-the-windows-administrator-how-name-resolution-works-in-a-dual-ipv4-ipv6-scenario.aspx
The “slow” way to disable IPV6
For years, KB 929852 has documented manual and fix-it methods to disable IPv6 by setting DisabledComponents = 0xFFFFFFFF under HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip6\Parameters\.
It was recently discovered that disabling IPv6 with the above registry value causes a 5 second boot delay in the Pre-Session Init Phase of OS startup.
(The long-running Winlogon init phase tells us this machine has ‘other’ issues)
OS versions impacted by the 5 second boot delay include Windows Vista, Windows 7, Windows 8 and Windows 8.1 clients. Affected server versions include Windows Server 2008, Server Windows Server 2008 R2, Windows Server 2012 and Windows Server 2012 R2. 5 second boot delays aren’t very interesting on servers that rarely reboot but are increasingly interesting on client operating systems, especially those that are configured with SSD disk drives where full OS (as opposed to wake from hibernate) boot times are approaching 30 seconds.
The “fast” way to disable IPv6
Took me long enough but we are finally getting to the point. The correct setting to use in environments that legitimately need to disable IPv6 and IPv6 transition technologies is to configure the DisabledComponents registry key with a value of 0xFF. It should look like the following.
The reason for the delay is that underlying code requires the upper 24-bits to be zero. Since the upper 24-bits have no meaning, setting a value of 0xFF is functionally identical to the 0xFFFFFFFF setting. Unfortunately, the DisabledComponents setting got documented with an all “F” bitmask. If you used this documented setting this unnecessarily results in a 5 second boot delay.
Both the Fixit and the manual steps in KB 929852 have been updated with this new information.
This setting has been in place for years, why did this delay just get discovered now?
Back when OS boots and user logons where running 120 seconds each, the primary focus was eliminating 30-to 60 second or longer delays. As Microsoft and application developers have steadily whittled away longer running delays and Windows computers have transitioned from slower analog to faster SSDs disk drives with optimized OS images, such big delays can be increasingly rare. The 5 second delay discussed in this blog represents one of the longer remaining delays on SSD-enabled computers which can experience boot times as short as 30 seconds.
Some more thoughts on IPv6
If you disabled IPv6 back in the day by setting DisabledComponents = 0xFFFFFFFF, take this opportunity to revisit whether that setting needs to remain in place.
Many customers disabled IPv6 when deploying Windows 7 or Windows 8.X in a false effort to reduce network I/O or because applications or the underlying network infrastructure were not IPv6 compatible.
It is good practice to re-evaluate broad configuration changes from time to time. If IPv6 was disabled on Windows computers by setting DisabledComponents, ask yourself whether that setting should be removed completely or whether to remove the delay by changing the DisabledComponents bitmask to a value of 0xFF. Some questions to guide your decision might include:
• “Are we currently disabling IPv6 for sound technical reasons?”
• “Do we still have application versions that are not IPv6 compatible?”
• “Does the network infrastructure still require that IPv6 be disabled?”
Don’t take “because we do” or “it slows things down” as legitimate answers. Refer to the articles above to arm yourself with the correct information about IPv6. If IPv6 does need to remain disabled, consider setting Disabledcomponents to a value of 0xFF.
Mark “the right reasons” Morowczynski