• Sidebar: Why Is IPv6 Needed?
• Illustration: Windows Network Stack Diagram

All of Microsoft's current OSs—Windows XP SP2, Windows Server 2003, and Windows CE 4.2—now come with partial support for Internet Protocol version 6 (IPv6), and Microsoft's Customer Service and Support (CSS) group will now help customers resolve IPv6 issues. IPv6 is a set of standard network protocols that will eventually replace IPv4, the current standard, which is saddled with limitations such as inadequate address space, inefficient routing, difficulty configuring devices, and inability to prioritize real-time data, such as voice.

The current Windows IPv6 implementations are not intended for production use, but provide a rudimentary platform for learning, planning, development, and testing. Full IPv6 support won't come until the next major releases of Windows and Windows CE (code-named Longhorn and Cardhu, respectively), but Microsoft is supporting IPv6 now because it is becoming a checklist requirement, especially in Asia and for government contracts. However, migration to IPv6 will be a huge industry effort, and it involves much more than support in Windows. Migration will also affect routers and firewalls, and the ISPs, backbone carriers, and wireless carriers that operate the Internet. In addition, many Internet and intranet applications will have to be changed to make them IPv6-compatible. For this reason, the timing of different migration milestones is extremely uncertain.

This article explains why Microsoft is offering IPv6 and describes its general plans for it, but is not intended to provide readers with deep technical background on the protocol.

What Is IPv6 and Why Now?

Virtually all data networks today use the TCP/IP suite of protocols, standardized by the Internet Engineering Task Force (IETF). A key element of this suite is IPv4, which enables routing of data packets from one network to another and provides a global, media-independent addressing scheme for end-point devices (such as computers and network printers) and the intermediate devices (routers) that separate networks and bridge different types of media, such as from Ethernet-based LANs to Frame Relay WANs. Although IP (Internet Protocol) technically refers to a single protocol in the TCP/IP network stack of communications protocols, in practical terms it refers to the entire set of protocols, APIs, and supporting applications needed to perform its core routing and packet delivery functions.

The Internet explosion of the 1990s revealed limitations in IPv4. For example, it became clear that IPv4 cannot scale to accommodate growth of the Internet indefinitely, and that it lacks support for prioritizing real-time data traffic, such as voice-over-IP (VoIP). Thus, the IETF specified a new version, IPv6 (there is no IPv5), to address these issues and provide a protocol that could meet the data communications needs of the Internet for many decades to come.

At its core, IPv6 expands the addressing field from 32 bits to 128 bits for a massive increase in the number of possible addresses, thereby eliminating address shortages and allowing them to be grouped such that routing becomes more efficient. But the IP address issue is only the tip of the iceberg. At the same time, the IETF made IPv6 significantly easier to configure and manage than IPv4. (For more on the business and technical drivers and benefits of IPv6, see the sidebar "Why Is IPv6 Needed?".)

IPv6 is not a superset of IPv4, but rather is a complete replacement, and is not backward-compatible. However, the two protocols can work side by side, allowing a device configured with both protocols to communicate with both IPv4 and IPv6 devices.

Microsoft has been working on IPv6 since the late 1990s, and although it is difficult to predict the exact timetable of worldwide migration to IPv6, Microsoft and all other key OS vendors know they must fully support it as commercial demand for its advantages grows. Furthermore, Microsoft needs to show demonstrable progress now or may risk losing important contracts.

One key marker was a June 2003 five-year procurement plan announced by the U.S. Department of Defense stipulating that all future purchases of networking hardware and software need to either be IPv6-capable or be upgradeable to become IPv6-capable before the end of 2007. Cisco claims that South Korea, Japan, and China—countries most impacted by IPv4's address limits—are already looking at implementing IPv6 in some cases in 2005.

Even though the three current Microsoft OS implementations of IPv6 are incomplete, partial support now is important, because Microsoft needs time to make sure that its implementations of the IPv6 protocols are solid and secure. In addition, Microsoft, ISVs, and even some corporate developers need to modify applications and other OS components, such as Internet Information Server (IIS), that communicate directly with TCP/IP APIs to make them work with IPv6. The current Microsoft IPv6 stacks give developers a platform for testing those changes, and also provide a platform for interoperability testing with non-Windows IPv6 devices and for academic teaching and research.

Lastly, by including support for IPv6 now, Microsoft takes a key step toward breaking the circular dependency between network infrastructure upgrades and application upgrades for IPv6. So, by the time IPv6 adoption becomes widespread, users won't be prevented from migrating to it simply because today's Windows systems (which may be legacy systems by then) lack IPv6 support.

What Windows IPv6 Includes

Although Microsoft provided some unsupported, add-on IPv6 features in earlier OSs, Windows Server 2003, Windows XP SP2, and Windows CE 4.2 now all come with partial IPv6 implementations that Microsoft feels are solid enough to be supported by CSS. When installed, these IPv6 components do not interfere with existing IPv4-based data communications. (For the relationships among the various components, see the illustration "Windows Network Stack Diagram".)

Specifically, Microsoft has begun to implement IPv6 by incorporating direct OS support for core IPv6 protocols, making necessary modifications to Windows sockets (Winsock) APIs and applications-layer protocols, supplying protocols that ease the transition from IPv4, and creating administration and troubleshooting tools. Some of these aspects are supported at different levels by each of the company's three current OSs. However, Microsoft's implementation of IPv6 still lacks some key components.

Core IP Protocols

The main function of both versions of the IP protocol is to provide a device addressing scheme that is independent of the various types of network media (such as Ethernet, Frame Relay, DSL, and Wi-Fi) used in the overall end-to-end path. The sending device labels each packet of data with both its IP address and the IP address of the final destination device; intermediate IP-enabled devices called routers can read the destination address of each packet and independently route it toward its destination, eliminating the need for some central device or the sending device to specify how every data packet gets to its destination.

The IP protocol requires the assistance of several other protocols to get its job done. Because manually assigning unique addresses to every device is impractical and prone to human error, both IPv4 and IPv6 have protocols to automatically assign unique IP addresses to computers and other intelligent devices (such as network printers) as they connect to the network. These protocols can also configure devices with important IP information, such as the address of the routers to which a device should send any network data that is intended for a remote destination not on the local network. The IP protocol also needs a control protocol that allows devices to test their ability to reach each other and to deal automatically with common traffic flow problems, such as suppressing transmissions when a router is getting packets faster than it can process them.

All three current Microsoft OSs include IETF-compliant implementations of the IPv6 protocols that perform these core functions. These implementations also comply with the Mobile IPv6 specification, which separates device identity from network location. This provides a sort of "call forwarding" that allows devices to remain reachable by a quasi-permanent IP address even as they roam from network to network.

Winsock 2

Any OS component or application that needs to communicate with other network devices over TCP/IP does so directly or indirectly through an API called sockets. In Microsoft OS implementations, the sockets API goes by the name of Winsock. The three current Microsoft OSs include a new version of the API, Winsock 2, that provides new calls that abstract higher-layer protocols from needing to know the version of IP that is actually carrying the data. This allows programs communicating with Winsock 2 to be written such that they are IP-version agnostic.

To work over both IPv6 and Ipv4, every OS component written to talk over Winsock must be modified to eliminate any IP-version specific calls and parameters. For example, the calls must refer to other network devices by their fully qualified names (such as www.directionsonmicrosoft.com) rather than by IP addresses. That's because the device name is the same in either case, but the format of an IPv4 address (e.g., 64.38.128.30) is much different from that of an IPv6 address (e.g., fe80::20d:56ff:fe3c:f430). However, Winsock 2 is backward-compatible so that unmodified applications will continue to run over IPv4.

This ability to use both IP versions simultaneously on each computer is critical because the transition to IPv6 will take years, and until all senders and recipients are on IPv6, traffic must still work properly over IPv4.

Applications Layer Protocols

Microsoft has modified many but not all of the most frequently used Windows network communications protocols and applications for Winsock 2, including the remote procedure call (RPC), Distributed Component Object Model (DCOM), and Server Message Block (SMB) protocols, plus the protocols used by IIS, Internet Explorer, Windows Media Player, and Windows Media Services (the media server application included with Windows Server). These protocols support most of the more commonly used methods of Windows network file transfer and interprocess communication. The .NET Framework has also been written to use only the IP-version-agnostic Winsock 2 calls. This means that all .NET applications are automatically IPv6-enabled.

Because Winsock 2 must first decide whether to use IPv4 or IPv6 to communicate with another device and then get the appropriate version of its IP address, Winsock 2 always depends on Domain Name Services (DNS) to get the appropriate IP address for the name supplied. (DNS services translate fully qualified computer names into their associated IP address so that data can be properly routed to its destination.) Therefore, to send data using IPv6, Winsock 2 requires an IPv6-compatible version of DNS, which is supplied in Windows Server 2003.

Transition Protocols

Microsoft's three IPv6-capable OSs include support for two important protocols: the 6to4 protocol and the Intrasite Automatic Tunnel Addressing Protocol (ISATAP). Both of these protocols encapsulate IPv6 data packets inside IPv4 data packets, thereby enabling IPv6 data to tunnel through older IPv4 networks. These protocols are critical to gradual migration during which many parts of the network, especially the Internet, will still be on IPv4. They enable basic connectivity and jump-start the migration with minimal effort, cost, and disturbance to an existing network infrastructure.

Windows XP also supports the Teredo client protocol, which allows IPv6 communications to tunnel through devices that use Network Address Translation (NAT), a scheme for enabling devices on private IP networks (which do not have globally unique addresses) to communicate with other devices over the public Internet.

Windows Server 2003 also supports the PortProxy protocol, which allows administrators to configure it to act as a proxy for various unmodified Winsock applications. PortProxy converts IPv6 packets into IPv4 equivalents and then relays them to the IPv4 application running locally or on another computer.

Administration and Troubleshooting Tools

Microsoft's IPv6-capable OSs include command-line utilities to configure IPv6, report on status, and perform diagnostics, such as an IPv6 ping utility to test connectivity with other IPv6-enabled devices.

The Microsoft Network Monitor packet-capture tool included with Windows XP, Windows Server 2003, and Systems Management Server 2003 comes with IPv6 parsers that allow network technicians and developers to analyze IPv6 packet captures.

What's Missing?

Although the bulk of the protocols and tools needed to test IPv6 and IPv6-enabled applications are present in the three Windows OSs, Microsoft's IPv6 implementation lacks the following features:

Support for key applications. Because they have not yet been modified for Winsock 2, many Microsoft products, including Exchange (which uses the Simple Mail Transport Protocol, SMTP), Internet Security and Acceleration (ISA) Server, Host Integration Server (HIS), Microsoft Operations Manager (MOM), and Systems Management Server (SMS) cannot be accessed directly over IPv6 (although they could be indirectly accessed using the Windows Server 2003 PortProxy service). Windows Server 2003's File Transfer Protocol (FTP) and Telnet server services are also not IPv6-enabled. However, SQL Server 2000 is already IPv6-compliant.

IPSec encryption. IPv4 and IPv6 both support the Secure IP (IPSec) protocol, which allows devices to check the authenticity and integrity of each packet, and has the option for the data payload to be encrypted to protect against eavesdropping. (IPSec support is optional for IPv4 but is mandatory in IPv6.) However, in Microsoft's current IPv6 implementations, IPSec packet encryption is not supported.

Graphical administration tools. Other than the DNS management console, all other IPv6 configuration and administration tasks must be done using command-line tools.

Routing protocols. Windows Server 2003's Routing and Remote Access Service (RRAS) allows the OS to act as a router for both IPv4 and IPv6, but the current RRAS has no support for IPv6 routing protocols to automatically maintain its routing tables. (Routing tables provide the basis for routers to decide how to forward packets efficiently toward their destinations, and they use multiple protocols to automatically configure and update their IP routing tables.) This means that RRAS IPv6 routing tables must be entered manually as static routes, making this version of RRAS impractical for complex, frequently changing IPv6 networks.

DHCPv6. The Dynamic Host Configuration Protocol (DHCP), which under IPv4 allows devices to dynamically acquire IP addresses, becomes less important with IPv6. That's because IPv6 includes a supporting protocol that allows devices to configure themselves with IPv6 addresses automatically without the risk of duplicating an existing address.

Alternatively, organizations can use an IETF standard for DHCPv6 services, which can be used to centrally configure IPv6 device addresses and other network configuration information, rather than using IPv6's built-in auto-addressing mechanisms. However, Microsoft has not included support for DHCPv6 server or client support in its current OSs.

Production Quality IPv6 Coming in Longhorn

So when does Microsoft expect the industry to begin broad IPv6 adoption? Although the company is not publicly prognosticating on the timing of major IPv6 industry milestones, some insight can be gleaned from its IPv6 roadmap.

Microsoft plans to have full production-ready IPv6 support built into Windows CE 6.0 (code-named Cardhu) and into the Longhorn versions of Windows client (expected in 2006) and server (scheduled for roughly the end of 2007). In these versions, IPv6 will be installed by default and will be the preferred transport. All OS network services and APIs will be IPv6-enabled and, while IPv4 will still be fully supported, the OSs will have no dependencies on IPv4, allowing them to run in pure IPv6 environments.

The current IPv6-supported OSs will be able to communicate with these future OS releases over IPv6, but they are unlikely to get updates that fill in the missing IPv6 capabilities.

Full Microsoft support for IPv6 will not emerge until post-Longhorn releases of Office and almost all of the company's server products, including Exchange, Internet Security and Acceleration Server, and Live Communications Server.

Microsoft's own internal IT group has already rolled IPv6 out internally for limited production ("dogfood" testing). As of January 2004, Microsoft claimed to have the entire Redmond, WA, campus network IPv6-enabled, with more than 40,000 IPv6-equipped Windows devices running on it. Once Longhorn and "Longhorn wave" server applications ship, the company plans to move IPv6 into full production use.

Who Should Take Action Now

At present, people in any of the following three roles should begin working with the current IPv6 support in Windows:

Developers of applications that use Winsock directly. ISVs and corporate developers who have built or currently maintain applications that communicate directly with the Winsock API should begin making and testing the necessary modifications to use only the new IP-version-agnostic calls in Winsock 2. However, applications that communicate with Winsock indirectly through other Windows APIs will not require any modifications to work properly over IPv6 networks once all Microsoft network APIs are IPv6-compliant. Microsoft has made free tools available to scan source code for problematic Winsock calls.

Developers stymied by today's IPv4 limitations. IPv6 will enable new peer-to-peer communications scenarios, especially in the consumer and mobile spaces, that are difficult or impossible with IPv4, especially because of NAT issues or IPv4's lack of a standard way to handle roaming addresses. Developers and corporations considering these projects for Windows devices should be gaining experience with IPv6 now. However, since commercial viability of IPv6-only devices and application scenarios is still years off, these must be long-range projects.

Network engineers and architects. IPv6 is a big departure from IPv4, and it will take time for individuals responsible for designing and operating Windows-based networks to become familiar with IPv6. The current Windows OS provides enough to get them started and allows them to begin learning and testing migration procedures.

Resources

Links to more information on IPv6 and Microsoft's implementations of it can be found at www.microsoft.com/ipv6.

A good overview of IPv6 is at www.cisco.com/en/US/about/ac123/ac114/ac173/Q4-04/tech_transitioning.html.

IPSec is described in more detail in "IPSec Enhances Windows Virtual Private Network Security" on page 3 of the Feb. 2002 Update.