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

    Question

  • Hi,

    I work for a large organization.  We have close to 10,000 servers globally.  A question has come up if we should disable IPv6 on our Windows 2008 servers.  Our network is not yet capable of using IPv6.

    It seems like you have to go out of your way to disable IPv6; therefore, I would assume that it is best to leave IPv6 turned on.

    Does anyone have any thoughts about this.  It would be most helpful to have links to pros/cons - best practice.

     

    Thank you.

    Thursday, April 21, 2011 2:58 PM

Answers

All replies

  • 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
    Thursday, April 21, 2011 3:25 PM
  • 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 8:03 PM
  • 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
    Wednesday, June 08, 2011 11:56 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*

    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 6:38 PM
  • 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
    Thursday, July 14, 2011 7:02 PM
  • 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.

     

    Friday, July 15, 2011 2:54 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


    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:07 PM
  • 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 3:34 PM
  • 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:24 PM
  • 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 4:30 PM
  • 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 7:37 PM
  • 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
    Thursday, August 18, 2011 8:25 PM
  • "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.

    Friday, August 19, 2011 3:54 PM
  • @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).


    Tuesday, October 23, 2012 2:51 PM
  • @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

    Tuesday, October 23, 2012 2:57 PM
  • 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

    Thursday, March 07, 2013 10:05 PM
  • @tom_n_indy -

    A couple of years after the fact, but the basic concepts of security you refer to are exactly correct.  If you don't need a service or protocol, disable it.  I normally don't write in postulation, but a "period" statement is appropriate in my mind.

    The question was "how to I disable IPv6."  An "answer" of "don't do that" is *not* an answer, and marking it as such does a disservice to the people who come here for answers.  It is "Technet," not "Don'tDoThatNet." 

    @Sandy J. - it's not your place to tell other people "there's not reason to do that."  Either don't post, or at least be honest with the answer.  It is absolutely not because "there's no reason to" (I'm quite surprised you would say that).   Unchecking "IPv6" doesn't even "unbind" it - you can still ping local resources with IPv6.  That means it's enabled and bound. 

    Microsoft dev made a conscious decision to intrinsically bind IPv6 functionality into the OS much like they did IE. 

    To answer the question (this mostly for future visitors) you can follow the instructions here:

    http://support.microsoft.com/kb/929852?wa=wsignin1.0

    Articles of "doesn't help" and "don't do it" simply substantiate justifications defending development teams making poor choices in regard to what is supposed to be a professional, data-center production operating system.  Case at point (and only one) is the fact that during the posting of this original question was an IPv6 vulnerability which allows attackers to leverage IPv6 in order to capture IPv4 traffic. 

    Anyone with IPv6 enabled had to scramble to patch production systems out of cadence, or simply wait out public exposure until they could patch, and THEN go through the pain of actually disabling it.

    As MVPs, please don't argue against "secure by default" and best practices (except Jason J. - he seems pretty straight up).  And please don't mark questions as "answered" when the post doesn't do anything at all to speak to the question.

    t

    Monday, May 27, 2013 8:10 PM
  • "you can still ping"

    Sorry Thor, totally not true. Please look up what binding and unbinding a protocol to a network adapter does and how network traffic traverses a system. Pinging (or connecting to) a local resource never touches the network adapter.

    As explicitly mentioned in the article you posted: "We do not recommend disabling IPv6". I continue to agree with Microsoft on this and just because you don't ... well, given your knowledge of how network traffic traverses the networking stack ...

    Not sure what vulnerability you are referring to but I'm assuming it has to do with the ability to tunnel IPv6 over IPv4 using Teredo (and other protocols). By definition, this is not a problem with IPv6, it's a method to bypass security in place by tunneling traffic which is effectively similar to a VPN and isn't a vulnerability, but a bypass of sorts that users can use. Without knowing exactly what you are talking about, it's hard to comment.

    As for "secure by default", why not? Microsoft's SDL is ranked the best in the world and has been for many years now as has their security response team. It's always been popular to bash Microsoft and those that agree with them, but their track record speaks for itself particularly in the years since the trustworthy computing initiative was launched (2002) and the last handful of years where they are clearly the class of the industry in security. 


    Jason | http://blog.configmgrftw.com

    Monday, May 27, 2013 9:38 PM
  • Seeing how I opened this question, I thought that I would give an update.  I agree with Jason S. in that you should leave IPv6 completely enabled if you are not experiencing any problems on your network.

    My network currently does not support IPv6.  We found that IPv6 records were being registered in DNS (and there is no way to prevent this.)  At times, client machines would try to resolve names and get the IPv6 AAAA records.  Then when the client tried to connect to the remote device, the connection could not be established (our network is not capable to routing IPv6).

    The reason, the IPv6 records were being registered is because of the built in backwards compatibility built into the network stack of Windows Vista and higher OS;s (vista, 7, 8, windows 2008 and highers Os's).  Microsoft makes it possible for IPv6 records to be registered over an IPv4 network.  The problem is that we have older Os's like Widnows 2003 and Windows XP on our network too.  So having the IPv6 records became a big problem for us.

    After working with Microsoft and thoroughly testing behaviors in our network, we decided to disable COMPONENTS of Ipv6 (not to completely disable IPv6 -- but disable the ability to IPv6 to function over an IPv4 network -- to disable to transition technologies.

    To do this, set DisabledComponents to 1 in the registry and reboot.

    http://support.microsoft.com/kb/929852

    "By default, the 6to4 tunneling protocol is enabled in Windows 7, Windows Vista, Windows Server 2008 R2, and Windows Server 2008 when an interface is assigned a public IPv4 address (that is, an IPv4 address that is not in the ranges 10.0.0.0/8, 172.16.0.0/12, or 192.168.0.0/16). 6to4 will automatically assign an IPv6 address to the 6to4 tunneling interface for each such address that is assigned, and 6to4 will dynamically register these IPv6 addresses on the assigned DNS server. If this behavior is not desired, we recommend disabling IPv6 tunnel interfaces on the affected hosts."

    We have decided to implement this on all new server being built today.  We are also implementing this on any systems showing the above problem.  In the future, we plan to implement this on all existing servers in our environment.

    • Proposed as answer by DmitroBark Tuesday, September 03, 2013 6:09 PM
    Tuesday, May 28, 2013 11:38 AM
  • We have been disabling IPv6 on all of the servers we have deployed pretty much since we started deploying Windows 2008.  We do this by setting DisabledComponents to FFFFFFFF. 

    I'm not interested in debating whether or not we should do this as it wasn't my decision and I don't know the best answer, but I want to point out that it appears as though disabling IPv6 and leaving the 6to4 adapter or Teredo Tunneling adapter enabled subjects the system to potential crashes.  I don't have proof that this is so, but disabling these adapters seems to have solved the problem for us, so our server images for the last 2 years have had them disabled.  I mention this as something to watch out for.  Also, if anyone can confirm this to be an issue that would be appreciated.

    Thanks.

    • Proposed as answer by Stevenrowe6 Saturday, December 14, 2013 11:39 AM
    • Unproposed as answer by Stevenrowe6 Saturday, December 14, 2013 11:39 AM
    Thursday, September 26, 2013 3:12 PM
  • Why are some of you MVP's always coming with newbie answers?
    If someone ask "how?" the answer is "like this" and not "you should not, period!".

    The answer would be a reference to KB 929852.

    I bet you guys don't even consider that there might be network equipment in the production environment that is not ipv6 compatible and even might conflict with it.
    Not to forget that going trough additional steps before continuing to ipv4 hampers performance, as well as 6to4 does.
    So if the network infrastructure is unable to handle ipv6 it is more an advantage then disadvantage to disable it.
    If you can't see the logic in that I suggest that you start to take CCNP and learn something instead of blindly following some loosely written MS bullshit.

    Someone else wrote about ipv4 security and Microsoft code.. ,the "hacks" are directly up against the protocol, which is not something that MS developers define, they can only follow guide lines to build protection around it.
    Further most of these "hacks" should have been blocked at the border router in first place, so no reason to blame Microsoft.

    As for ipv6, it has quite some security advantages over ipv4.


    Friday, October 18, 2013 9:25 AM
  • *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. 

    That is not an IPv6 issue, that is a DNS issue. Do not confuse the two.

    Ed


    Sunday, November 10, 2013 3:54 AM
  • Hi Joerg.

    Part of what we try to do as MVP's, is provide guidance for a question's topic.

    I could describe the exact steps needed for someone to do something very wrong that could cause problems or harm an implementation, but I will not do that. Just because it can be done does not mean that it should be done and the implications of that need to be understood.

    This is true with respect to IPv6 and the attempt/goal of disabling it has almost always been driven by fear, misunderstanding and doubt about the technology. The right answer is always: Understand the implications of what you are doing before clicking on the buttons.

    That includes upgrading your infrastructure and replacing those components needed to implement what is needed. And if someone understands how IPv6 works and how the modern MS operating systems use it, it would become apparent that the systems work fine until you start changing what you do not understand.

    Thanks

    Ed

    Sunday, November 10, 2013 4:11 AM
  • My background is that I have an Exchange 2007 server on Win2008R2 and sometime after early 2013 there was a problem creating an Outlook profile to access a mailbox on the Exchange server.  Why the difference sometime after early 2013 I don't know. 

    However, the reason I am posting here is because the fix was to delete the ipv6 address in dns that the Exchange server had registered (fyi, note that the NIC on the Exchange server is not bound to ipv6).  However, in time, the server will re-register the ipv6 address, even though not bound to ipv6, and the Outlook problem starts again (cannot create a new Outlook profile - however, note that there is no problem using email for profiles already created).  So, after looking at many posts regarding pros/cons of ipv6 and to what extent it might be disabled, and the best approach to deal with the unwanted ipv6 dns registration, your post about disabling 6to4 sounds exactly what I am looking for, since I was leary about disabling ipv6 altogether since who knows what that might break (now or in the future).  I will give it a try and post back. 

    Also, one thing I found about preventing the unwanted ipv6 dns registration for statically-configured NICs, such as on a server, is that if you manually create the ipv4 dns entry yourself, then the ipv6 6to4 address does not get registered, I think maybe because the machine account does not have permissions for the ipV4 dns entry (since it was made manually) and then by some logic it does not (or cannot) register the ipv6 6to4 address.  Obviously this is not a solution for machines using DHCP.  I'd be interested if anyone has used this as a workaround to prevent the unwanted ipv6 6to4 address dns registration.

    Tuesday, February 11, 2014 9:00 PM