By now, you have probably heard that Windows Vista features a dual stack, which allows it to run IPv4 and IPv6 simultaneously. Although Vista isn't the first Windows operating system to support IPv6 (I think Windows 2000 may have been the first), it is the first Windows OS to have IPv6 enabled by default.
The fact that IPv6 is enabled by default in Vista, combined with the notion that almost nobody is really using IPv6 (yet), raises the question: Why not just disable IPv6?
Why disable IPv6?
There are actually compelling arguments both for and against leaving IPv6 enabled. Let's start out by talking about some reasons for disabling IPv6. We all know that Windows Vista is a system resource hog. The IPv6 protocol consumes resources such as CPU time and system memory; it also consumes network bandwidth. Since the IPv6 protocol consumes system resources, and you may not even be using it, disabling the protocol seems like a no-brainer.
Conserving system resources is one possible reason for disabling the IPv6 protocol. Another is that disabling the IPv6 protocol may possibly increase the security of your system. At first, that statement probably sounds ludicrous. After all, IPv6 was specifically designed to overcome some of the security shortcomings of the IPv4 protocol. Even so, there is a law of computing that states that the larger the size of your code base, the greater the chance that the code will contain an exploitable security vulnerability. Adding an additional protocol to Windows increases the size of the Windows code base, which could potentially lead to security problems.
Keep in mind that at the time of this writing, I am not aware of any serious security problems specifically related to the IPv6 protocol in Windows Vista, but adding IPv6 to the mix does provide an additional method that a workstation can use to communicate across the network. It doesn't seem that farfetched to think that adding an extra protocol could potentially lead to security problems.
One more reason why you may want to disable the IPv6 protocol is that IPv6 is nothing like IPv4. The Windows Vista implementation of IPv6 is self configuring, but if the administrators in your company make a habit of monitoring network traffic, they will probably need additional training so that they can learn the anatomy of an IPv6 packet.
Why you should think twice before disabling IPv6
There are obviously some reasons why you might want to disable the IPv6 protocol, but Microsoft enabled the protocol by default in Windows Vista for a reason. In fact, IPv6 is not only enabled in Windows Vista, it is the preferred protocol. For example, if a Windows Vista workstation performs a DNS query, and the query returns an IPv4 address and an IPv6 address, Vista will use the IPv6 address every time.
This prompts the question: Why has Microsoft placed so much emphasis on IPv6 in Vista? I will be the first to admit that many of the reasons behind the IPv6 push are political. For example, the federal government has mandated that federal agencies make the transition to IPv6 by June 2008. Microsoft wants to sell software to the government, so why not offer an operating system in which IPv6 is already in place?
The reasons for including IPv6 go beyond politics, though. IPv6 offers the potential for better security than is available with IPv4, and the IPv6 protocol also overcomes the problem of a global shortage of IP addresses. (See this book chapter on IPv4/IPv6 myths and realities to learn more.)
Of course, I still have not given you any compelling reasons for leaving the IPv6 protocol enabled, if you are not actually using it. The main reason for leaving IPv6 enabled is that some Vista features break when it is disabled.
The reason for this is that Vista includes a new discovery service that is dependent on the IPv6 protocol. For now, the discovery service is mostly involved in peer networking. To see why this is important, imagine an end user trying to set up an ad hoc network for the purpose of collaborating on a project, or even accessing a resource that is stored on another user's PC.
Although the current wireless networking technology makes creating ad hoc networks simple, name resolution has always been a bit problematic. In an ad hoc network, there is no DNS server that can resolve host names into IP addresses. The discovery service overcomes this problem, though, by allowing ad hoc network participants to identify themselves to other network users and to get the identities of the other network participants.
For the most part, you won't have to worry too much about the discovery service right now if your users do not form ad hoc networks, but the discovery service is also involved in identifying resources on corporate networks. Windows Vista is capable of browsing a corporate network without using the IPv6 protocol or the discovery service, but some hardware manufacturers are starting to create network devices, such as switches and routers, that will respond to multicast discovery packets. This means that when users browse the network, they may eventually be able to identify specific devices, such as routers and switches, in addition to other PCs on the network.
So should you disable the IPv6 protocol or leave it enabled? I think that the answer really depends on your individual needs. My personal feeling is that as long as your workstations are not strapped for resources and your network's bandwidth isn't saturated, you should leave IPv6 enabled. Even if you aren't really doing anything with IPv6 right now, I think it's a safe bet that IPv6 will be much more heavily used in the future -- especially after Windows Server 2008 is released.
About the author:
Brien M. Posey, MCSE, is a Microsoft Most Valuable Professional for his work with Windows 2000 Server and IIS. Brien has served as CIO for a nationwide chain of hospitals and was once in charge of IT security for Fort Knox. As a freelance technical writer, he has written for Microsoft, CNET, ZDNet, TechTarget, MSD2D, Relevant Technologies and other technology companies. You can visit www.brienposey.comBrien Posey's website for more information.
This was first published in February 2009