Export (0) Print
Expand All

Microsoft's Objectives for IP Version 6

Updated: February 12, 2008
On This Page

Introduction
Looking Forward
Getting There
Summary
Further Reading

Introduction

Microsoft® is delivering support for the update to the Internet Protocol, commonly referred to as IP version 6—or simply IPv6 (RFC 2460). This IETF standard protocol suite is designed to significantly increase the address space used to identify communication endpoints in the Internet, thereby allowing the Internet to continue its tremendous growth rate. This article provides an overview of the key capabilities and strategies for deployment that forms the foundation of Microsoft's implementation.

While the Internet continues its unprecedented exponential growth, the recent broad adoption of always-on broadband technologies such as Digital Subscriber Line (DSL) and cable modems, coupled with the pending integration of personal data assistants (PDAs) and cellular phones into always-addressable Mobile Information Appliances, significantly elevates the urgency to expand the address space that Internet-connected systems use to communicate. The address space currently used is defined as part of the Internet Protocol, or IP (the network layer of the TCP/IP protocol suite). The version of IP commonly used today is Version 4 (IPv4), which has not been substantially changed since RFC 791 was published in 1981. Over that time, IPv4 has proven to be robust, easily implemented and interoperable, and has stood the test of scaling an internetwork (a network of networks) to a global utility the size of today's Internet. While this is a tribute to its initial design, moving forward to an even grander scale requires laying a new foundation.

IPv6 will continue the tradition of the IPv4 protocol, which gained much of its acceptance by defining mechanisms to tie systems together over a wide variety of disparate networking technologies. Already defined link-layer mappings for transporting IPv6 include Ethernet, Point-to-Point Protocol (PPP), Fiber Distributed Data Interface (FDDI), Token Ring, Asynchronous Transfer Mode (ATM), Frame Relay, IEEE 1394, and IPv4. From the architectural perspective, an IPv4-based infrastructure appears to IPv6-enabled systems as a single segment non-broadcast multi-access (NBMA) network. The capability to send IPv6 traffic over existing IPv4 networks will provide an initial reach as broad as the current Internet, limited only by the endpoints' ability and readiness to make use of it.

New capabilities such as scoped addresses (useful for restricting the default range of file and printer sharing), stateless autoconfiguration (lowering the complexity and management burden), and mandatory IP security (permitting end-to-end data authentication and integrity and privacy of connections) are expected to drive rapid adoption. In addition to the new capabilities, the technologies currently used to extend the lifetime of IPv4 (such as Network Address Translators [NATs]) frequently break existing applications, and are already restricting the flexibility to deploy new ones. NATs are popular today because they allow multiple systems to share a single scarce public IPv4 address, but in doing so they tend to enforce a client/server usage model where the client uses private address space with only the server existing in public address space. IPv6 brings back the capability of 'end-to-end control of communications'; making networking applications simpler as the network again becomes transparent.

Looking Forward

Both the Windows Server� 2008 family and Windows Vista will continue Microsoft's leadership as the global standard for desktops and servers that are stable, reliable, and the ideal platform for supporting both new and legacy applications. Expanding on this solid base, Microsoft's .NET initiative is a revolutionary new platform built on open Internet protocols and standards, and using tools and services that meld computing and communications in new ways. Microsoft .NET will allow the creation of truly distributed services that will integrate and collaborate with a range of complementary services to serve customers in ways that can only be dreamt of today. Achieving this level of service distribution will require the interconnecting Internet infrastructure to provide transparent and consistent views of the environment to the participating systems, applications, and services.

For example, as the popularity of multi-player games conducted over the Internet increases, so does the need for consistent network layer addressing between the participating peers. IPv6 enables consistent views because there is no need for the address sharing which results in peers having differing views of the address for a participating system.

In addition to a consistent view of addresses, IPv6 allows multiple machines within a home to use the same port number (many services use a registered port number for inbound connections), whereas the currently prevalent IPv4 NATs restrict port number use to one machine at a time. Removing the possibility of interfering technologies from the environment frees the game developer and player to focus on the game.

Additional peer-to-peer applications that are made easier using IPv6 include IP telephony and video teleconferencing. These and similar applications are likely to take advantage of the Quality-of-Service (QoS) features defined for IPv6. While many of the QoS features have also been defined as add-ons for IPv4, the mechanism selected was to redefine the meaning for the Type of Service field of the IP header, causing collisions with historical implementations. The effort to provide QoS for IPv4 has struggled due to differing models of deployment. This effort is not wasted though, because it is forcing many details to be worked through from hardware capabilities to business practices. IPv6-enabled systems will be able to leverage this effort to provide an array of service levels that are consistent from end-to-end.

Wireless technologies are emerging which present the prospect of ad-hoc networks between personal devices. Setting up systems to work in an ad-hoc mode is challenging enough, but it is expected that many of these personal devices will also need to work in the managed environment of the workplace. Switching between these modes is frequently frustrating and is significantly more involved than either alone. To avoid the complexity, IPv6 has defined an architectural principle that systems are required to simultaneously support multiple addresses. Coupling this capability with scoped addresses results in the ability to move easily and automatically between ad-hoc and managed environments.

Another capability IPv6 brings to the wireless realm is efficient mobility. Many applications today expect the IP addresses to remain constant throughout the lifetime of their connection to a remote peer or server. While this is possible today using IPv4, the mechanisms are complex, and operationally very fragile. IPv6 removes much of the complexity and allows the end systems to efficiently redirect packets to the new address of the mobile node via a binding update. By maintaining the awareness of mobility in the endpoints, the tremendous power of a flexible transparent network is preserved.

When looking to expand their reach while lowering their costs, businesses large and small are frequently turning to the Internet. To facilitate this, the Microsoft .NET platform enables developers, businesses and consumers to harness technology that melds computing and communications. The fundamental idea behind Microsoft .NET is that the focus is shifting from individual Web sites or devices connected to the Internet to constellations of computers, devices, and services that work together to deliver broader, richer solutions. To make information available any time, any place and on any device, requires the constellations of devices to have a consistent view of each other, which will be possible using the globally unique addresses available with IPv6. With this capability, every application on any device can be exposed as a service on the Internet.

The programming model in Microsoft .NET gives developers the opportunity to focus fewer resources on where or how an application runs over the potential network impediments like NAT, and more on what it does. Like the rest of the Microsoft .NET tools, the IPv6 implementation will automatically adapt itself to the current needs, be it ad-hoc, home, or business connections.

To address concerns about security and privacy, IPv6 includes IP layer security known as Internet Protocol security (IPsec). IPsec is an industry standard security technology that provides for data authenticity and integrity as well as data confidentiality across the array of protocols used by the various applications. Providing the capability at the network layer frees the developer from having to add specific security capabilities to every application.

In addition, Microsoft has contributed to the standardization process a concept known as temporary addresses. To make stateless autoconfiguration work well, the standards community chose the underlying hardware address (the media access control [MAC] address) for use as part of an IPv6 address to ensure global uniqueness. This has the side effect that all communications are traceable to the specific hardware device.

While it is technically necessary to have a published (over some scope), globally unique address to receive incoming connections, the address of an originator only requires current global uniqueness (not publication). To alleviate this potential privacy concern, Microsoft has authored RFC 4941 to define a locally generated address mechanism where the result is only valid for a period determined by the local system or application. The ability of IPv6 systems to simultaneously support multiple addresses allows each application to use an independent address, and/or an application to use a different address for each service to which it connects.

Getting There

The conversion from IPv4 to IPv6 will be a larger task for the industry than the preparation for Year 2000. It will affect nearly all networked applications, end-systems, infrastructure systems, and network architectures. It is critical that this change be approached with responsibility to prevent costly unproductive missteps that result from broad premature availability of technologies. Unlike the Year 2000 issue, the conversion to IPv6 has no specific timeline. However, as noted earlier, the rate of IPv4 address consumption is rapidly increasing. Simplicity of deployment will be the key to rapid adoption.

Like IPv4 (where early deployments frequently transited X.25 networks), IPv6 deployment will start at the edge of the network, taking advantage of framing within any available network technology. It is anticipated that Internet service providers (ISPs) will react to customer demand as the deciding factor for when to deploy native IPv6 routing, but as it takes several years to replace the network equipment, this may be a slow process. To avoid a "chicken-and-egg problem," Microsoft is taking the approach that encapsulating IPv6 packets within IPv4 will allow incremental deployments of end systems that will in turn demonstrate the demand to the ISPs.

To stay on the high performance path of the existing routers, IPv6-enabled Windows systems will default to tunneling over IPv4 unless the ISP provides a specific indication to do otherwise and a native end-to-end IPv6 path exists. The only requirement is that the Windows systems directly connected to an ISP receive at least one public IPv4 address (the address ranges specified in RFC 1918 are not public). Subsequent systems in a home or business will receive 6to4 (RFC 3056) prefix router advertisements from the directly connected system.

In the presence of NATs that are not IPv6-enabled where only private addresses are available, a supplementary technology named Teredo (RFC 4380) tunnels IPv6 traffic over NATs by including a User Datagram Protocol (UDP) header in addition to an IPv4 header.

For enterprise networks, an incremental upgrade to IPv6 is possible using the Intra-Site Automatic Tunnel Addressing Protocol (ISATAP) (RFC 4214). ISATAP allows IPv6-only hosts and subnets to fully coexist and interoperate with IPv4 hosts and subnets in an intranet. In partnership with 6to4 technology, a comprehensive incremental migration solution is available to businesses transitioning their corporate networks.

For more information about 6to4, ISATAP, and Teredo, see the IPv6 Transition Technologies white paper.

Despite these approaches, the transition will not be easy. It is expected that for the foreseeable future, most manufacturers will produce systems supporting both IPv4 and IPv6, so that if connections are not possible using IPv6 they can fall back and succeed using IPv4 (providing IPv4 connectivity existed prior to the introduction of IPv6). The overall goal is to ensure a smooth transition and deployments where updated applications can take advantage of the new protocol, without breaking existing applications. To this end there have been new Windows APIs defined to specifically isolate the legacy applications from unintentional exposure to protocol differences, including the larger IPv6 addresses.

The key steps that has Microsoft taken to deliver IPv6 include:

  1. The transition to IPv6 began in 1998 with the availability of an IPv6 implementation from Microsoft Research. This release was provided to help the IPv6 standards development community understand and test the protocol during its definition.

  2. In March 2000, a technology preview was released for Windows 2000-based computers. This release allowed developers to become familiar with the concepts and capabilities they will encounter when enabling their applications to use IPv6.

  3. In October 2001, Windows XP was released with a developer preview IPv6 stack and some components of the system enabled for IPv6 so developers can begin the task of IPv6-enabling their applications.

  4. In September 2002, Windows XP Service Pack 1 was released with the first edition of a production IPv6 stack and some IPv6-enabled components.

  5. In March 2003, Windows Server 2003 was released with a production IPv6 stack and some IPv6-enabled components.

  6. In July 2003, the Advanced Networking Pack for Windows XP was released, which included the IPv6 Internet Connection Firewall, a Teredo client, and support for Windows Peer-to-Peer Networking.

  7. In August 2004, Windows XP Service Pack 2 was released. This service pack included the Teredo client, support for Windows Peer-to-Peer Networking (as originally provided with the Advanced Networking Pack for Windows XP), and integrated IPv6 traffic support with the new Windows Firewall (replacing the IPv6 Internet Connection Firewall).

  8. In March 2005, Windows Server 2003 Service Pack 1 was released. This service pack included the additional IPv6 features provided with Windows XP Service Pack 2.

  9. In July 2005, Beta 1 of Windows Vista™ and Beta 1 of Windows Server 2008 were released, which included the Next Generation TCP/IP stack, an integrated IPv4/IPv6 stack in a dual IP layer architecture. For more information, see Changes to IPv6 in Windows Vista and Windows Server 2008.

  10. In November 2006, Windows Vista was released.

  11. In February 2008, Windows Server 2008 was released.

  12. In July 2009, Windows 7 and Windows Server 2008 R2 were released.

Current releases, including Windows 7, Windows Vista, Windows Server 2008 R2, and Windows Server 2008, provide a production-capable IPv6 stack and IPv6 capability for built-in applications and system services.

Older releases, including Windows Server 2003 R2, Windows Server 2003, Windows XP with Service Pack 1 and later, and Windows CE version 4.1 and later, provide a production-capable IPv6 stack but limited IPv6 capability for built-in applications and system services.

For more information about developing applications to take advantage of IPv6, see the IPv6 Guide for Windows Sockets Applications.

The defining characteristic of Microsoft's IPv6 production implementation is simplicity of deployment. The technologies used to deliver those will include: stateless address autoconfiguration (including temporary addresses), automatic tunneling over existing IPv4 networks, and appropriate use of scoped addresses.

Because IP is a fundamental and pervasive technology within the operating system, it is not feasible to retrofit versions of Windows prior to the Windows Server 2003 family and Windows XP. But to maintain backwards compatibility, IPv6-enabled versions of Windows will also provide the capability to natively speak IPv4 for the foreseeable future. While it will become necessary to provide translation between IPv4 and IPv6 in some cases (such as late in a transition when new IPv6-only devices need to access yet-to-be-retired IPv4-only systems), it is not expected to be the norm for early deployments. Whenever the IPv6-only devices arrive, the issues surrounding address translation are typically specific to a given application. Thus as they arise, these scenarios will require targeted development on a case-by-case basis.

Summary

While this article only touches on the highlights of IPv6 technology, it provides some insight on Microsoft's focus to developers and network managers as they begin contemplating a transition. Replacing the core of the engine-of-efficiency while it is running is not a task to take lightly, nor will it happen quickly. To facilitate and smooth this transition, Microsoft is establishing a leadership position to help guide its partners and customers through this delicate task.

Further Reading

For the most up to date information on Microsoft's support for IPv6 and a selection of white papers and other documentation, please see the Microsoft IPv6 Web site.

Was this page helpful?
(1500 characters remaining)
Thank you for your feedback
Show:
© 2014 Microsoft