IPv6 – breaking down the DisabledComponents registry value

I’ve gotten an elevated number of requests recently on “how do I disable IPv6” or “what’s the best way to configure IPv6 in my environment”. I’m not entirely certain of why I’ve gotten so many recently, and I’m not sure if it’s a coincidence or if there’s more to it.

However, what I’ve found is that most IT departments I’ve come across over the years simply go and set IPv6 to completely disabled via setting the disabledcomponents registry value to 0xffffffff. While this does indeed disable IPv6 entirely, I have to warn everyone I come across with this set that Microsoft doesn’t test this setting at all, and support for resolving issues with this set have usually resorted to setting disabledcomponents back to 0x0 and retesting, where things magically work, and that’s the extent of what is done for obvious reasons. This can (and sometimes does) also break functionality in Windows, and the one that most customers eventually run across is DirectAccess (with Remote Assistance in second).

With the advent of a lot of my enterprise customers recently starting to roll out DirectAccess to their Windows 7 and (increasingly) Windows 8.1 clients, this of course is now being revisited for best practices (or at least best recommendations from the Microsoft guy), as DA requires IPv6 enabled in most cases, at least in some way, and especially on Windows 7. I made a handy breakdown of the disabledcomponents settings to satisfy a request for just this question recently, and figured I’d repost here my recommendations, and why.

There’s 8 bits to the disabledcomponents registry value, and each bit represents a feature or configuration of a functionality of the IPv6 stack in Windows.

• Bit 0 controls ALL of the IPv6 tunnel interfaces, which includes Teredo, ISATAP, 6to4, and IP-HTTPS. Setting this to 1 will disable ALL of the tunnel interfaces, which will also break DirectAccess full stop. This should *always* be 0 if you’re using IPv6 transition tunnels (and each tunnel interface can be controlled separately, which is the right way to handle them).  I generally don’t recommend this ever be set to 0 even if you aren’t using them, as they can each be configured separately.  Maybe it’s OCD, maybe it’s good practice, I dunno – but I don’t ever change this from 0 if I can help it because there are other levers for this, and I don’t like to paint in broad brushes when it comes to configuration, as it can sometimes be hard to track down the setting that’s keeping one I’m trying to enable from working in the future.
• Bit 1 controls 6to4
• Bit 2 controls ISATAP
• Bit 3 controls Teredo
• Bit 4 controls IPv6 for non-tunnel interfaces, which would include actual physical (or virtual, in a VM) network interfaces, dial-up/PPP interfaces, etc.
• Bit 5 controls preference of IPv6 or IPv4 in the prefix table – setting this to 1 will cause IPv4 to be preferred when creating a new network connection, and I do recommend setting this in mixed IPv4/IPv6 networks, at least on the client-side (server-side is a bit murkier, and I generally don’t recommend messing with IPv6 on the back end at all if at all possible).
• Bit 6 is listed as “reserved”, so…. yeah, don’t touch it.
• Bit 7 controls IP-HTTPS

Why is the above important? Well, 6to4, ISATAP, Teredo, and IP-HTTPS are all considered “IPv6 Transition technologies”, which means nothing other than these are the technologies that a DirectAccess server and client can (and will) use to get that tunnel connected when the client does not have an IPv6 address, or is connected to the internet via a NAT tunnel. 6to4 and Teredo both require the DirectAccess server to be connected directly to the internet, which was required prior to using Server 2012’s DirectAccess feature. The likelihood is, if you’re using a 2008R2 or UAG server to serve DirectAccess to your clients, you’re using 6to4 or Teredo, so do not disable these if you want DA to continue working. ISATAP is generally used when doing “manage-out” of DA clients, so if you’re doing that, again, do not disable ISATAP. IP-HTTPS allows DA to work when the 2012 or 2012R2 server is not directly connected to the public internet (and is using a private IP address), and is the only protocol that works in this scenario. I’ve seen a progression to this configuration in new DA installs, which is how this question came up in the first place – if you’re using DA servers situated behind a firewall or not connected to the public internet in any way, how do you configure IPv6 so that things work the way you need them to without leaving other IPv6 transition capabilities in place?

It’s questions like these that keep me coming back to this simple chart, when determining for someone what the best value for the disabledcomponents registry value is.  As is the case with most things, one size does not fit all.  Also, knowledge is power, so knowing what each bit controls will help you determine what (if anything) to set if you’re going to modify IPv6 behavior in a Windows environment.  Again, Microsoft’s best practice is to keep things configured as default, and if you’re capable of doing that, then that’s always the best recommendation.  However, if you really do feel that you need to change things, simply disabling IPv6 entirely is a bad idea – controlling it in a manageable way is far better.

So, without any further rambling, here are some examples I’ve used in the recent past that should help explain for the more visual among us how to configure disabledcomponents for certain configurations.  Remembering to list your binary from right to left (bit 7 will be the leftmost bit, and bit 0 the rightmost when you write it out), you would see something like this as your bit field (use the buit-in Windows calculator in “Programmer” mode if you’re bad at converting binary (bin) to hex):

if you wanted to disable IPv6 tunnel interfaces and prefer IPv4 across your network (you’re not using DirectAccess, and have no need for any tunnel creation), you would have a binary number that looked like this:

1 0 1 0 1 1 1 0  ==  0xAE

This has bits 7, 5, 3, 2, and 1 “enabled”, thus disabling IP-HTTPS, setting IPv4 preference, and disabling Teredo, ISATAP, and 6to4 as well.  You could set bit 0 as well, but that would be sort of redundant, and I prefer only making the changes I need to if possible, so I don’t generally recommend it.  You would thus put the value “0xAE” into the disabledcomponents registry value to configure this setting.

Let’s say you’re using DirectAccess with Windows 7 clients, and you needed to have 6to4 or Teredo enabled, but didn’t want ISATAP functionality and were not going to be using IP-HTTPS as your DA servers are attached directly to the internet:

1 0 1 0 0 1 0 0  ==  0xA4

This has bits 7, 5, and 2 “enabled”, thus disabling IP-HTTPS, setting IPv4 preference, and disabling ISATAP while leaving 6to4 and Teredo enabled.  You would thus put the value “0xA4” into the disabledcomponents registry value to configure this setting.

As a last example, let’s say you are using Server 2012 DA servers behind a firewall, and thus will be using IP-HTTPS to connect your external clients to your DA infrastructure.  You do not need any other tunnel technology (and in fact would want these disabled):

0 0 1 0 1 1 1 0  ==  2E

This has bits 5, 3, 2, and 1 “enabled” thus setting IPv4 preference, and disabling Teredo, ISATAP, and 6to4.

Hopefully this helps someone the next time they come across a request to “disable IPv6!” or help answer the question “which IPv6 settings do I actually need to set?”  Yes, this can be done with PowerShell and Group Policy as well, before the comments blow up about that.

Happy admin’ing.

Courtesy: Cluberti.com