Why rücksichtlos disabling IPv6 is a bad idea

Since Windows Vista, Microsoft has bundled and enabled IPv6 by default. This means Windows Vista, Windows 7 Windows Server 2008, Windows Server 2008 R2 (and all their derivate SKUs like Small Business Server) out of the box talk IPv6.

Note:
Server Core installations do not have IPv6 enabled by default and are the one notable exception.

The implementation chosen by Microsoft in these Operating Systems is a dual stack configuration. This means IPv6 exists besides IPv4.

Paul has blogged about his troubles with IPv6 and explained how to disable IPv6 in depth for Windows Server 2008 (and Windows Vista). Besides disabling IPv6 in the Network properties (also available through netsh) he walks through a series of firewall policies, registry values and network services ordering steps.

While most of these steps may be performed through Group Policy Policies and Group Policy Preferences, Paul didn’t mention these. (Converting the steps is easy) After reading the information in the blog post, you may have gotten the idea that disabling IPv6 throughout the network is a best practice and you need to go through your network to frantically disable IPv6 everywhere. The German people have a word for that kind of behavior: rücksichtlos. It roughly translates to English as ‘without looking back’.

I, however, recommend making these changes through Group Policy, so the changes can be easily reverted. I believe you’ll want to revert disabling IPv6 on your internal networks in the next two to three years.

Here are some of the reasons:

  • Dynamic short name resolution in the post-WINS era
    Microsoft has deprecated WINS and introduced Global Names Zones (GNZs) and the Peer Name Routing Protocol (PNRP) for short name resolution. GNZs have some drawbacks (they need to be enabled per server, do not allow dynamic updates and records need to be created manually), where PNRP more resembles the dynamic nature of WINS short name resolution. PNRP requires IPv6. This makes phasing out WINS in a dynamic environment a matter of (re)enabling IPv6.
  • DirectAccess
    Introduced with Windows 7 and Windows Server 2008 R2, DirectAccess allows corporate connectivity, transparent to the end-user. DirectAccess relies on IPv6 on the internal network. To access IPv4-only hosts, a NAT-PT device (like Microsoft’s Unified Access Gateway) is required. With $15 per connecting device (or user) through UAG, a business case is easily made to (re)enable IPv6 to hosts on the internal network that need to be accessible through DirectAccess.
  • Compliancy
    In the near future, your company may be required to comply with regulations from governments, trade organizations or even business partners. September 28, 2010, already marked a step in that direction, when Vivek Kundra, the Federal Chief Information Officer (CIO), issued a directive to “expedite the operational deployment and use of IPv6”. This directive means US agencies need to support enterprise networks to operationally use native IPv6 (internet-facing applications) by the end of FY 2014.
  • Integrated security
    In many secure networks, IPSec is used to isolate network traffic from eavesdropping. In the IPv4 world IPSec is bolted onto IPv4. In IPv6, IPSec is an integrated and mandatory component for IPv6. Therefore, when implementing a secure network, the logical choice is to work towards increased IPv6 traffic.
  • HomeGroup
    While no self-respecting systems administrator will use the Windows 7 HomeGroup functionality for serious file sharing, if you want to use this functionality, you will need IPv6. HomeGroups rely on the Peer Name Resolution Protocol (PNRP) and as you read earlier, PNRP is an IPv6-only name resolution protocol. Serious admins, of course, will deploy Windows Server 2008 R2-based File servers with BranchCache and regularly back these up.

Of course, implementing IPv6 throughout the whole of the network isn’t an easy job. Many of you will run into the same walls Paul has run into. Working together with manufacturers, helps overcome these problems. Not just for your organization, but for everyone.

When you want to help improve IPv6 in Microsoft products, feel free to comment on the TechNet IPv6 blog or simply post a question or remark in the TechNet IPv6 Forum. Feel the need to share knowledge? Why not add to the IPv6 Survival Guide in the TechNet Wiki!

leave your comment

This site uses Akismet to reduce spam. Learn how your comment data is processed.