Best Practice - IPv6 Turn Off? Windows 2008 (and R2) Servers

Thursday, April 21, 2011 3:25 PM

No, do not disable IPv6. There is no reason to do so unless you have a very specific application issue which is highly unlikely (although there are a few documented ones out there).

http://blogs.technet.com/b/ipv6/archive/2007/11/08/disabling-ipv6-doesn-t-help.aspx
http://blogs.technet.com/b/jlosey/archive/2011/02/02/why-you-should-leave-ipv6-alone.aspx

Jason | http://myitforum.com/cs2/blogs/jsandys | Twitter @JasonSandys

Marked As Answer by y2kBug_sp7 Thursday, June 09, 2011 12:03 PM

Wednesday, June 08, 2011 8:03 PM

0

In the same sense, there is no reason to keep it enabled if you're not going to use it, yet. It is actually very simple to disable it as well. TCP/IP Settings, uncheck IPv6. :)

Wednesday, June 08, 2011 11:56 PM

1

That doesn't disable IPv6, it merely unbinds it from an adapter -- not the same thing and it can lead to application issues. The above links cover this.

Jason | http://myitforum.com/cs2/blogs/jsandys | Twitter @JasonSandys

Thursday, July 14, 2011 6:38 PM

0

*No, do not disable IPv6. There is no reason to do so unless you have a very specific application issue which is highly unlikely*

Such as Exchange 2007? Seems if there is an IPv6 entry in DNS for our mail server new mail clients cannot resolve their alias's. OR Symantec Enterprise Vault which, again, will not work if there is an IPv6 entry in DNS.

Delete the entry, flush dns and everything works fine.

Thursday, July 14, 2011 7:02 PM

1

There are always exceptions. The Exchange 2007 issue was fixed in SP1 to my knowledge. As for the software graveyard...I mean Symantec, well that's up to them.

Jason | http://myitforum.com/cs2/blogs/jsandys | Twitter @JasonSandys

Friday, July 15, 2011 2:54 PM

0

Jason,

We are running Exch 2007 SP1 on the CAS/HUB server and SP3 on the mailbox server, the issue persists. Perhaps when I apply SP3 to the CAS server it will go away although I doubt it.

Thursday, August 18, 2011 3:07 PM

4

No, do not disable IPv6. There is no reason to do so unless you have a very specific application issue which is highly unlikely (although there are a few documented ones out there).

http://blogs.technet.com/b/ipv6/archive/2007/11/08/disabling-ipv6-doesn-t-help.aspx
http://blogs.technet.com/b/jlosey/archive/2011/02/02/why-you-should-leave-ipv6-alone.aspx

Jason | http://myitforum.com/cs2/blogs/jsandys | Twitter @JasonSandys

Whoever marked this as an "answer" obviously doesn't remember that bad-old-days of "Everything's on by default! It just works!!" and the billions of dollars in lost productivity that ensued from the hundreds (thousands?) of exploits that followed this painfully short-sighted decision. You'd think Microsoft would have learned their lesson from the "IIS is on by default!" debacle, but that doesn't seem to be the case.

Best practices for system administration say "turn off the services and protocols you don't use." As such, IPv6 should ALWAYS be disabled on servers and business workstations if you're not currently using it, just like any other protocol or service you haven't implemented or aren't using. Not using FTP? Don't install or enable an FTP server. Not using IPv6? Why would you have IPv6 enabled? Just because IPv6 is the newest, shiniest thing on the block doesn't mean you have to use, and it definitely shouldn't require you to start hacking about in the registry to turn it off.

The only exception to this rule would be laptops or mobile devices where the user might (conceivably) take them into an IPv6 environment. Even then, though, you have to balance the "convenience" of not having to switch-on IPv6 against the risk that your unconfigured IPv6 stack might be exploitable by nefarious patries. Even so, the fact that almost nobody has switched their internal networks to IPv6 means that turning it off on laptops is still probably a "good idea."

For example, my laptop wireless interface might make sense to leave IPv6 enabled--I don't have any idea when I'll walk into an environment that uses IPv6 and want to use my wireless. But in the office when I'm hard-connected? We don't use IPv6 so it needs to be "off." Even if it's just a bit of code in the Windows firewall that can be used to say "just reject IPv6 traffic on x interface" is still a big improvement. An absolute home-run would be the addition of logic that allows Windows to dynamically disable IPv6 when there aren't any NICs or WNICs that are allowed to use it.

Finally, none of this should be construed to mean I'm advising against implementing IPv6, because I'm not. However, like any major technology project you should plan carefully, making sure you understand ALL of the consequences (not just the marketing hype,) and making sure you'll be able to administer the changed environment as well as your administer the current one. You definitely should not let a vendor (of all things) force the decision to use it upon you because it's "on by default."

Proposed As Answer by tom_m_indy Thursday, August 18, 2011 3:20 PM

Thursday, August 18, 2011 3:34 PM

1

Tom,

I marked the answer ... and I still believe that it is the best answer based especially on this : http://blogs.technet.com/b/jlosey/archive/2011/02/02/why-you-should-leave-ipv6-alone.aspx

I don't think the IPv6 can be compared, apples to apples, to something like FTP or IIS.

Thursday, August 18, 2011 4:24 PM

1

You're right, it's not an apples to apples comparison--and it doesn't have to be.

I'm sure the "premier field engineer" you've cited means well, but he's probably also assuming that you have access to a network engineer who knows enoguh about IPv6 to secure your network properly with both protocols enabled. This is a dangerous assumption: Your shop (with 10,000 servers) probably does. Can you say the same for a company with 100 servers, 10 servers, or just one? Yes, of course they "should" have those skills but this is the real world--the smaller the shop, the more likely they don't have them. And that lack of skill in the small enterprise is consistent over time--it has basically paid for my house.

The problem isn't IPv6 in a vacuum, or any of the applications relying on IPv6 in a vacuum: The problem is the intersection of this new unused protocol that is enabled in a "default, out of box" configuration with the knowledge-gap between an admin's abilities with IPv4 and IPv6.

Remember, for the first 2/3 of the 1990's having IIS on by default was seen as "no big deal." Then along comes the wide-scale deployment of Internet access to millions of offices. That's when "on-by-default" hit the fan--not because "new tech is bad," or that on-by-default was a bad idea then, but because of the relative lack of sophistication that admins had in setting up and securing (or not securing) their Internet connections. Here the biggest problem wasn't "the Internet" it was the lack of sophistication of the administrators to understand what negative consequences were possible. Prior to plugging the entire world into every office, on-by-default might have been annoying, but was hardly catastrophic. Afterward? Obviously, we know how it panned out.

We're now in the same place with IPv6--it's new and powerful and feature-rich and I'd bet you 90+% of network admins have little or no idea how to use it correctly. There's a very real skill-gap between what admins know about IPv4, and what they know about IPv6. As such, the bad-guys of the world are literally drooling at the prospects for new exploits this will create. The only question, in my mind, for people electing to stay with IPv4 is "Do you want to make yourself a target or not?" If you answered "not" then your choice is clear.

I stand by my previous post.

Thursday, August 18, 2011 4:30 PM

1

I agree; the logic is flawed. IPv6 is not a service and is not something in of itself that can be exploited.

I definitely agree with Tom's last paragraph though (except the tone of the last line). Microsoft is not forcing you to do anything; but they are giving you solid recommendations for what you should do. Arbitrarily turning things off because you think you know better than the vendor is just as bad (if not worse). Unintended Consequences of Security Lockdowns: http://blogs.msdn.com/b/aaron_margosis/archive/2011/05/25/unintended-consequences-and-sysinternals-from-tech-ed-available-online.aspx

Security is about risk and risk assessment.

Jason | http://myitforum.com/cs2/blogs/jsandys | Twitter @JasonSandys

Thursday, August 18, 2011 7:37 PM

2

I agree; the logic is flawed. IPv6 is not a service and is not something in of itself that can be exploited.

I definitely agree with Tom's last paragraph though (except the tone of the last line). Microsoft is not forcing you to do anything; but they are giving you solid recommendations for what you should do. Arbitrarily turning things off because you think you know better than the vendor is just as bad (if not worse). Unintended Consequences of Security Lockdowns: http://blogs.msdn.com/b/aaron_margosis/archive/2011/05/25/unintended-consequences-and-sysinternals-from-tech-ed-available-online.aspx

Security is about risk and risk assessment.

Jason | http://myitforum.com/cs2/blogs/jsandys | Twitter @JasonSandys

"IPv6 is not a service and is not something in of itself that can be exploited."

IPv6 itself can't be exploited, but that's because a protocol is a written set of requirements for how a compliant implementation of that protocol should be created. The only exploit I can think of for a piece of paper is origami.

However, a particular vendor's implementation of IPv6 can very easily be exploited. The Microsoft IPv4 implementation has already been compromised multiple times, and some of those have been "Critical" bugs that allowed remote code execution. What has changed at Microsoft that makes you think that their IPv6 implementation is totally unexploitable? It hasn't been exploited yet, but that doesn't mean it won't ever be. Having two versions of the IP protocol running at the same time (with one being unconfigured and ignored) almost gaurantees you'll be vulnerable when those bugs are discovered and exploited by the bad-guys.

Here's a recent proof-of-concept for vulnerability in the Microsoft IPv6 implementation: https://www.infosecisland.com/blogview/12798-MITM-Attack-Exploits-Windows-IPv6-Protocols.html

"Arbitrarily turning off things because you think you know better than the vendor" & "Microsoft is not forcing you to do anything; but they are giving you solid recommendations for what you should do."

There is nothing arbitrary about turning off an unused, superfluous protocol. If your environment doesn't use IPv6, that makes IPv6 superfluous, despite Microsoft claims to the contrary. In fact, what got me started down this path was a series of conversations with Microsoft support.

There are already at least a dozen problems where MS support tells you to turn off IPv6 on the affected system(s) to solve or workaround whatever the particular problem is. See also Exchange 2010 Hub Transport servers as the first example that comes to mind. Specifically, if you're not on SP 1, the Hub role won't install if IPv6 is enabled on the server. There are others, but the point is: Microsoft does not universally say "leave IPv6 alone," they do in fact sometimes recommend turning it off.

Thursday, August 18, 2011 8:25 PM

1

Nothing is perfect and all code is exploitable. It's all about risk and risk assessment as I said before. Each and every case is distinct and based on the particular environment and posture of that environment. Security is about layers though, not a single piece of code. Each layer mitigates issues in other layers. If you take any service, protocol, piece of code, etc. in isolation it can be "hacked" and exploited.

I disagree that it is not arbitrary. Simply doing something because you think it is best without a specific example is by definition arbitrary particularly when it goes against the recommendations of other "experts". None of the problems where Microsoft recommends disabling IPv6 are security related (to my knowledge) so citing them adds no weight to either side. POC code almost always assumes a great many things like physical access, no other security, admin privileges, etc. which are the true security issues and not the service that is supposedly comprised.

Still, you are correct that the number one thing is for folks to become educated and make educated decisions. It's like turning UAC off because you think it's too noisy without actually knowing what UAC even does.

Jason | http://myitforum.com/cs2/blogs/jsandys | Twitter @JasonSandys

Friday, August 19, 2011 3:54 PM

1

"Nothing is perfect and all code is exploitable."

Exactly my point. IPv4 and IPv6 are each threat surfaces, neither is inherently "More" or "less" secure than the other, but having both when you're only using one is inherently less-secure because you've increased your threat-surface for no appreciable gained features. It doesn't matter how many "layers" are in your security-cake, eventually somebody through malice, ignorance, or accident will introduce a compromised device to your environment and it will wreak havoc. The point isn't to achieve "perfection" but rather to control risk through research, testing, and critical thinking. If you don't approach a vendor's advice skeptically (especially as one with as... colorful of a track record as Microsoft has) you're not exercising critical thinking.

A real issue for companies that are below, let's say 500 servers, is that a decade of endless budget-cutting means there simply are fewer well-implemented-layers between a superfluous threat-surface (in this case IPv6) and the bad-guys because the engineer responsible for it is now doing the work of 5 people and simply doesn't have time to do it all, plus his other four roles, and sleep in a 24-hour period. In this scenario, if you're giving advice without a full-scale evaluation of their environment, I'd rather advise them to turn it "off" and risk a waste of some admin-time than to leave it "on" and risk vulnerability to the raft of as-yet-unknown exploits that are coming.

My assessment of the situation is based on interactions with MS employees from PSS (their verdict? "Nothing" is harmed by turning off IPv6 in your server environment,) real-life testing on literally thousands of machines over the course of several years, and my own ability to compare dissimilar things that can be expected to have similar consequences. If that seems "arbitrary" to you then I'd posit you're just annoyed that my assessment didn't yield the same output as yours did. Unfortunately, there isn't much I can do about that: I've seen the linked article and done more than a little research on the topic and simply don't agree with your point of view.

I'm approaching my third decade of supporting, implementing, and integrating products from Microsoft (and several other vendors as well) and can tell you on some authority that what's best for customers and what the vendor advises them to do aren't always the same thing. Even with the best vendors, you must take their employees advice and run it past the "smell-test." If it doesn't pass that smell-test you should remain skeptical until you test it yourself and can make yourself comfortable with the conclusions. Remember that Microsoft's initial response to IIS-on-by-default worms was "Just use a firewall" rather than the risk-reducing "just uninstall IIS" because they had a financial interest in having IIS on the widest number of servers as possible. The perception that IIS was insecure and needed to be uninstalled wasn't good for business, so they advised customers to do what was best for Microsoft, which wasn't necessarily best for the customers. They came around to the better-for-customers position, eventually, but only after hundreds of millions in lost productivity had already occurred.

Tuesday, October 23, 2012 2:51 PM

0

@Thread

Let me share my experience on this topic.

We had several problems accessing a Win2008R2 server from Win7 workstations by a program doing TCP/IP connection (i.e. nothing high level like RDP, VNC...).

The problem was that the workstations had disconnections al least once a day, this on different workstations, not at the same time for all them.

I spent a lot of time checking the whole setup: DNS, routeurs, switches...

Since I disabled IPv6 everywhere, I had not one single disconnection.

Second story:

After I added a 2008R2 server that I had to promote as a new DC, and unpromoting an old Win2003, I couldn't issue the command "repadmin /syncall" to force the replication.

I disabled IPv6 and I could issue the command.

All this does not necessarily mean that IPv6 is bad but at least it is a lot better to disable it than to leave it with the default settings.

In my company, it will probably never be set up because it's not used anyway so I now disabled it on all computers (well "unbind" it on the NICs if you prefer).

Edited by GimelLavergne Tuesday, October 23, 2012 2:54 PM
Edited by GimelLavergne Tuesday, October 23, 2012 2:56 PM

Tuesday, October 23, 2012 2:57 PM

0

@Thread

Let me share my experience on this topic.

We had several problems accessing a Win2008R2 server from Win7 workstations by a program doing TCP/IP connection (i.e. nothing high level like RDP, VNC...).

The problem was that the workstations had disconnections al least once a day, this on different workstations, not at the same time for all them.

I spent a lot of time checking the whole setup: DNS, routeurs, switches...

Since I disabled IPv6 everywhere, I had not one single disconnection.

Second story:

After I added a 2008R2 server that I had to promote as a new DC, and unpromoting an old Win2003, I couldn't issue the command "repadmin /syncall" to force the replication.

I disabled IPv6 and I could issue the command.

All this does not necessarily mean that IPv6 is bad but at least it is a lot better to disable it than to leave it with the default settings.

In my company, it will probably never be set up because it's not used anyway so I now disabled it on all computers.

So, did you disable it properly or just unbind the IPv6 protocol in the NIC bindings?

Jason Jones | Microsoft MVP | Silversands Ltd | My Blogs: http://blog.msedge.org.uk and http://blog.msfirewall.org.uk

Thursday, March 07, 2013 10:05 PM

0

I had a similar problem as Gimel Lavergne described. A new Exchange 2010 installation, we unbound IPV6 from the NICs but the Tunnel adapter 6TO4 Adapter kept registering itself with DNS with an IPV6 address. This broke our Windows NLB for the CAS Array and caused DAG members to lose connectivity resulting in failovers. I disabled the adapter with netsh interface 6to4 set state disabled to resolve the issue. Unless your organization is ready to fully implement IPV6 it can cause problems.

Our issues could have been caused by old clients and a poorly configured Enterprise DNS, but I have to work with what I have and have to make Exchange reliably accessible.

TBrennan

Best Practice - IPv6 Turn Off? Windows 2008 (and R2) Servers

All Replies

Products

Resources

Solutions

Updates

Trials

Related Sites

Training

Certifications

Other resources

Support by product

Other support links

Not an IT pro?