Guidelines for Using IPv6 Transition Mechanisms during IPv6 Deployment
draft-arkko-ipv6-transition-guidelines-14

Abstract

The Internet continues to grow beyond the capabilities of IPv4. An expansion in the address space is clearly required. With its increase in the number of available prefixes and addresses in a subnet, and improvements in address management, IPv6 is the only real option on the table. Yet, IPv6 deployment requires some effort, resources, and expertise. The availability of many different deployment models is one reason why expertise is required. This document discusses the IPv6 deployment models and migration tools, and recommends ones that have been found to work well in operational networks in many common situations.

Status of this Memo

This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at http://datatracker.ietf.org/drafts/current/.

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as “work in progress.”

This Internet-Draft will expire on July 1, 2011.

Copyright Notice

Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved.

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.

Table of Contents

1.  Introduction
2.  Terminology
3.  Principles
    3.1.  Goals
    3.2.  Choosing a Deployment Model
4.  Guidelines for IPv6 Deployment
    4.1.  Native Dual Stack
    4.2.  Crossing IPv4 Islands
    4.3.  IPv6-Only Core Network
    4.4.  IPv6-only Deployment
5.  Conclusions
6.  Further Reading
7.  Security Considerations
8.  IANA Considerations
9.  References
    9.1.  Normative References
    9.2.  Informative References
Appendix A.  Acknowledgments
§  Authors' Addresses

1.  Introduction

The Internet continues to grow beyond the capabilities of IPv4. The tremendous success of the Internet has strained the IPv4 address space, which is no longer sufficient to fuel future growth. At the time of this writing, August 2010, the IANA "free pool" contains only 14 unallocated unicast IPv4 /8 prefixes. Credible estimates based on past behavior suggest that the RIRs will exhaust their remaining address space by early 2012, apart from the development of a market in IPv4 address space. An expansion in the address space is clearly required. With its increase in the number of available prefixes and addresses in a subnet, and improvements in address management, IPv6 is the only real option on the table.

John Curran, in his Internet Transition Plan (Curran, J., “An Internet Transition Plan,” July 2008.) [RFC5211], gives estimated dates for significant points in the transition; while the tail of the process will likely be long, it is clear that deployment is a present reality and requirement.

Accordingly, many organizations have employed or are planning to employ IPv6 in their networks. Yet, IPv6 deployment requires some effort, resources, and expertise. This is largely a natural part of maintaining and evolving a network: changing requirements are taken into account in normal planning, procurement and update cycles. Very large networks have successfully adopted IPv6 alongside IPv4, with surprisingly little effort.

However, in order to successfully make this transition, some amount of new expertise is required. Different types of experience will be required: basic understanding of IPv6 mechanisms, debugging tools, product capabilities and caveats when used with IPv6, and so on. The availability of many different IPv6 deployment models and tools is an additional reason why expertise is required. These models and tools have been developed over the years at the IETF, some for specific circumstances and others for more general use. They differ greatly in their principles of operation. Over time, views about the best ways to employ the tools have evolved. Given the number of options, network managers are understandably confused. They need guidance on recommended approaches to IPv6 deployment.

The rest of this document is organized as follows. Section 2 (Terminology) introduces some terminology, Section 3 (Principles) discusses some of the general principles behind choosing particular deployment models and tools, Section 4 (Guidelines for IPv6 Deployment) goes through the recommended deployment models for common situations, and Section 5 (Conclusions) provides some concluding remarks about the choice between these models.

Many networks can follow one of the four scenarios described in this document. However, variations will certainly occur in the details, and there will be questions such as the particular choice of tunneling solution for which there is no "one size fits all" answer. Network managers must each take the responsibility of choosing the best solution for their own case. This document does not attempt to provide guidance for all possible networking situations. Also, a systematic operational plan for the transition is required, but the details depend entirely on the individual network.

2.  Terminology

In this document, the following terms are used.

IPv4/IPv4 NAT:

refers to any IPv4-to-IPv4 network address translation algorithm, both "Basic NAT" and "Network Address/Port Translator (NAPT)", as defined by [RFC2663] (Srisuresh, P. and M. Holdrege, “IP Network Address Translator (NAT) Terminology and Considerations,” August 1999.).

Dual Stack:

refers to a technique for providing complete support for both Internet protocols -- IPv4 and IPv6 -- in hosts and routers [RFC4213] (Nordmark, E. and R. Gilligan, “Basic Transition Mechanisms for IPv6 Hosts and Routers,” October 2005.).

Dual Stack Lite:

also called "DS-Lite", refers to a technique that employs tunneling and IPv4/IPv4 NAT to provide IPv4 connectivity over IPv6 networks [I‑D.ietf‑softwire‑dual‑stack‑lite] (Durand, A., Droms, R., Woodyatt, J., and Y. Lee, “Dual-Stack Lite Broadband Deployments Following IPv4 Exhaustion,” August 2010.).

IPv4-only domain:

as defined in [I‑D.ietf‑behave‑v6v4‑framework] (Baker, F., Li, X., Bao, C., and K. Yin, “Framework for IPv4/IPv6 Translation,” August 2010.), a routing domain in which applications can only use IPv4 to communicate, whether due to host limitations, application limitations, or network limitations.

IPv6-only domain:

as defined in [I‑D.ietf‑behave‑v6v4‑framework] (Baker, F., Li, X., Bao, C., and K. Yin, “Framework for IPv4/IPv6 Translation,” August 2010.), a routing domain in which applications can only use IPv6 to communicate, whether due to host limitations, application limitations, or network limitations.

NAT-PT:

refers to a specific, old design of a Network Address Translator - Protocol Translator defined in [RFC2766] (Tsirtsis, G. and P. Srisuresh, “Network Address Translation - Protocol Translation (NAT-PT),” February 2000.) and deprecated due to the reasons stated in [RFC4966] (Aoun, C. and E. Davies, “Reasons to Move the Network Address Translator - Protocol Translator (NAT-PT) to Historic Status,” July 2007.).

3.  Principles

The primary goal is to facilitate the continued growth of the networking industry and deployment of Internet technology at relatively low capital and operational expense without destabilizing deployed services or degrading customer experience. This is at risk with IPv4 due to the address runout; economics teaches us that a finite resource, when stressed, becomes expensive, either in the actual cost of the resource or in the complexity of the technology and processes required to manage it. It is also at risk while both IPv4 and IPv6 are deployed in parallel, as it costs more to run two technologies than one. To this end, since IPv4 clearly will not scale to meet our insatiable requirements, the primary technical goals are the global deployment of IPv6 both in the network, in its service infrastructure, and by applications, resulting in the end of the requirement to deploy two IP versions and the obsolescence of transitional mechanisms. Temporary goals in support of this focus on enabling parts of the Internet to employ IPv6 and disable IPv4 before the entire Internet has done so.

3.1.  Goals

The end goal is network-wide native IPv6 deployment, resulting in the obsolescence of transitional mechanisms based on encapsulation, tunnels, or translation, and also resulting in the obsolescence of IPv4. Transition mechanisms, taken as a class, are a means to an end, to simplify the process for the network administration.

However, the goals, constraints, and opportunities for IPv6 deployment differ from one case to another. There is no single right model for IPv6 deployment, just like there is no one and only model for IPv4 network design. Some guidelines can be given, however. Common deployment models that have been found to work well are discussed in Section 4 (Guidelines for IPv6 Deployment), and the small set of standardized IETF migration tools support these models. But first it may be useful to discuss some general principles that guide our thinking about what is a good deployment model.

It is important to start the deployment process in a timely manner. Most of the effort is practical -- network audit, network component choices, network management, planning, implementation -- and at the time of this writing, reasonably easily achievable. There is no particular advantage to avoiding dealing with IPv6 as part of the normal network planning cycle. The migration tools already exist, and while additional features continue to be developed it is not expected that they radically change what networks have to do. In other words, there is no point in waiting for an improved design.

There are only a few exceptional networks where co-existence with IPv4 is not a consideration at all. These networks are typically new deployments, strictly controlled by a central authority, and have no need to deal with legacy devices. For example, specialized machine-to-machine networks that communicate only to designated servers, such as Smart Grids, can easily be deployed as IPv6-only networks. Mobile telephone network operators, especially those using 3GPP, have seriously considered IPv6-only operation, and some have deployed it. Research networks that can be separated from the IPv4 Internet to find out what happens are also a candidate. In most other networks IPv4 has to be considered. A typical requirement is that older, IPv4-only applications, systems, or services must be accommodated. Most networks that cross administrative boundaries or allow end user equipment have such requirements. Even in situations where the network consists of only new, IPv6-capable devices it is typically required that the devices can communicate with the IPv4 Internet.

It is expected that after a period of supporting both IPv4 and IPv6, IPv4 can eventually be turned off. This should happen gradually. For instance, a service provider network might stop providing IPv4 service within its own network, while still allowing its IPv6 customers to access the rest of the IPv4 Internet through overlay, proxy, or translation services. Regardless of progress in supporting IPv6, it is widely expected that some legacy applications and some networks will continue to run only over IPv4 for many years. All deployment scenarios need to deal with this situation.

3.2.  Choosing a Deployment Model

The first requirement is that the model or tool actually allows communications to flow and services to appropriately be delivered to customers without perceived degradation. While this sounds too obvious to even state, it is sometimes not easy to ensure that a proposed model does not have failure modes related to supporting older devices, for instance. A network that is not serving all of its users is not fulfilling its task.

The ability to communicate is also far more important than fine-grained performance differences. In general, it is not productive to focus on optimization of a design that is designed to be temporary, such as a migration solution necessarily is. Consequently, existing tools are often preferred over new ones, even if for some specific circumstance it would be possible to construct a slightly more efficient design.

Similarly, migration tools that can be disposed after a period of co-existence are preferred over tools that require more permanent changes. Such permanent changes may incur costs even after the transition to IPv6 has been completed.

Looking back on the deployment of Internet technology, some of the factors that have been important for success include [RFC5218] (Thaler, D. and B. Aboba, “What Makes For a Successful Protocol?,” July 2008.)[Baker.Shanghai] (Baker, F., “The view from IPv6 Operations WG (and we’ll talk about translation),” November 2009.)

• The ability to offer a valuable service. In the case of the Internet, connectivity has been this service.
• The ability to deploy the solution in an incremental fashion.
• Simplicity. This has been a key factor in making it possible for all types of devices to support the Internet protocols.
• Openly available implementations. These make it easier for researchers, start-ups and others to build on or improve existing components.
• The ability to scale. The IPv4 Internet grew far larger than its original designers had anticipated, and scaling limits only became apparent 20-30 years later.
• The design supports robust interoperability rather than mere correctness. This is important in order to ensure that the solution works in different circumstances and in an imperfectly controlled world.

Similar factors are also important when choosing IPv6 migration tools. Success factors should be evaluated in the context of a migration solution. For instance, incremental deployability and lack of dependencies to components that are under someone else's control are key factors.

It is also essential that any chosen designs allow the network to be maintained, serviced, diagnosed and measured. The ability of the network to operate under many different circumstances and surprising conditions is a key. Any large network that employs brittle components will incur significant support costs.

Properly executed IPv6 deployment normally involves a step-wise approach where individual functions or parts of the network are updated at different times. For instance, IPv6 connectivity has to be established and tested before DNS entries with IPv6 addresses can be provisioned. Or specific services can be moved to support IPv6 earlier than others. In general, most deployment models employ a very similar network architecture for both IPv4 and IPv6. The principle of changing only the minimum amount necessary is applied here. As a result, some features of IPv6, such as the ability to have an effectively unlimited number of hosts on a subnet, may not be available in the short term.

4.  Guidelines for IPv6 Deployment

This section presents a number of common scenarios along with recommended deployment tools for them. We start from the most obvious deployment situation where native connectivity is available and both IP versions are used. Since native IPv6 connectivity is not available in all networks, our second scenario looks at ways of arranging such connectivity over the IPv4 Internet. The third scenario is more advanced and looks at a service provider network that runs only on IPv6 but which is still capable of providing both IPv6 and IPv4 services. The fourth and most advanced scenario focuses on translation, at the application or the network layer.

Note that there are many other possible deployment models and existing specifications to support such models. These other models are not necessarily frowned upon. However, they are not expected to be the mainstream deployment models, and consequently, the associated specifications are typically not IETF standards track RFCs. Network managers should not adopt these non-mainstream models lightly, however, as there is little guarantee that they work well. There are also models that are believed to be problematic. An older model to IPv6 - IPv4 translation (NAT-PT) [RFC2766] (Tsirtsis, G. and P. Srisuresh, “Network Address Translation - Protocol Translation (NAT-PT),” February 2000.) suffers from a number of drawbacks arising from, for example, its attempt to capture DNS queries on path [RFC4966] (Aoun, C. and E. Davies, “Reasons to Move the Network Address Translator - Protocol Translator (NAT-PT) to Historic Status,” July 2007.). Another example regarding the preference to employ tunneling instead of double translation will be discussed later in this document.

4.1.  Native Dual Stack

The simplest deployment model is Dual Stack: one turns on IPv6 throughout one's existing IPv4 network and allows applications using the two protocols to operate as ships in the night. This model is applicable to most networks - home, enterprise, service provider, or content provider network.

The purpose of this model is to support any type of device and communication, and to make it an end-to-end choice which IP version is used between the peers. There are minimal assumptions about the capabilities and configuration of hosts in these networks. Native connectivity avoids problems associated with the configuration of tunnels and Maximum Transfer Unit (MTU) settings. As a result, these networks are robust and reliable. Accordingly, this is the recommended deployment model for most networks, and supported by IETF standards such as dual stack [RFC4213] (Nordmark, E. and R. Gilligan, “Basic Transition Mechanisms for IPv6 Hosts and Routers,” October 2005.) and address selection [RFC3484] (Draves, R., “Default Address Selection for Internet Protocol version 6 (IPv6),” February 2003.). Similarly, while there are some remaining challenges, this model is also preferred by many service providers and network managers [RFC6036] (Carpenter, B. and S. Jiang, “Emerging Service Provider Scenarios for IPv6 Deployment,” October 2010.) [I‑D.arkko‑ipv6‑only‑experience] (Arkko, J. and A. Keranen, “Experiences from an IPv6-Only Network,” July 2010.).

The challenges associated with this model are two-fold. First, while dual-stack allows each individual network to deploy IPv6 on their own, actual use still requires participation from all parties between the peers. For instance, the peer must be reachable over IPv6, have an IPv6 address to itself, and advertise such an address in the relevant naming service (such as the DNS). This can create a situation where IPv6 has been turned on in a network but there is little actual traffic. One direct way to affect this situation is to ensure that major destinations of traffic are prepared to receive IPv6 traffic. Current Internet traffic is highly concentrated on selected content provider networks, and making a change in even a small number of these networks can have significant effects. This was recently observed when YouTube started supporting IPv6 [networkworld.youtube] (Marsan, C., “YouTube support of IPv6 seen in dramatic traffic spike,” February 2010.). There are scenarios where these means are insufficient. The following sections discuss deployment models that enable parts of the network deploy IPv6 faster than other parts.

The second challenge is that not all applications deal gracefully with situations where one of the alternative destination addresses works unreliably. For instance, if IPv6 connectivity is unreliable it may take a long time for some applications to switch over to IPv4. As a result, many content providers are shying away from advertising IPv6 addresses in DNS. This in turn exacerbates the first challenge. Long term, the use of modern application toolkits and APIs solves this problem. In the short term some content providers and user network managers have made a mutual agreement to resolve names to IPv6 addresses. Such agreements are similar to peering agreements and have been seen as necessary by many content providers. These "whitelisting" practices have some downsides as well, however. In particular, they create a dependency on an external party for moving traffic to IPv6. Nevertheless, there are many types of traffic in the Internet and only some of it requires such careful coordination. Popular peer-to-peer systems can automatically and reliably employ IPv6 connectivity where it is available, for instance.

Despite these challenges the native dual stack connectivity model remains the recommended approach. It is responsible for a large part of the progress on world-wide IPv6 deployment to date. The largest IPv6 networks; notably national research and education networks, Internet II, Renater, and others, employ this approach.

The original intent of dual stack was to deploy both IP versions alongside each other before IPv4 addresses were to run out. As we know, this never happened and deployment now has to take place with limited IPv4 addresses. Employing dual stack together with a traditional IPv4 address translator (IPv4/IPv4 NAT) is a very common configuration. If the address translator is acceptable for the network from a pure IPv4 perspective, this model can be recommended from a dual stack perspective as well. The advantage of IPv6 in this model is that it allows direct addressing of specific nodes in the network, creating a contrast to the translated IPv4 service as noted in [RFC2993] (Hain, T., “Architectural Implications of NAT,” November 2000.) and [I‑D.ietf‑intarea‑shared‑addressing‑issues] (Ford, M., Boucadair, M., Durand, A., Levis, P., and P. Roberts, “Issues with IP Address Sharing,” October 2010.). As a result, it allows the construction of IPv6-based applications that offer more functionality.

There may also be situations where a traditional IPv4 address translator is no longer sufficient. For instance, in typical residential networks, each subscriber is given one global IPv4 address, and the subscriber's IPv4/IPv4 NAT device may use this address with as many devices as it can handle. As IPv4 address space becomes more constrained and without substantial movement to IPv6, it is expected that service providers will be pressured to assign a single global IPv4 address to multiple subscribers. Indeed, in some deployments this is already the case. The dual stack model is still applicable even in these networks, but the IPv4/IPv4 Network Address Transition (NAT) functionality may need to be relocated and enhanced. On some networks it is possible to employ overlapping private address space [I‑D.miles‑behave‑l2nat] (Miles, D. and M. Townsley, “Layer2-Aware NAT,” March 2009.) [I‑D.arkko‑dual‑stack‑extra‑lite] (Arkko, J. and L. Eggert, “Scalable Operation of Address Translators with Per-Interface Bindings,” October 2010.). Other networks may require a combination of IPv4/IPv4 NAT enhancements and tunneling. These scenarios are discussed further in Section 4.3 (IPv6-Only Core Network).

4.2.  Crossing IPv4 Islands

Native IPv6 connectivity is not always available, but fortunately it can be established using tunnels. Tunneling introduces some additional complexity and has a risk of MTU or other mis-configurations. However, its benefit is that it decouples addressing inside and outside the tunnel, making it easy to deploy IPv6 without having to modify routers along the path. Tunneling should be used when native connectivity can not be established, such as when crossing another administrative domain or a router that cannot be easily re-configured.

There are several types of tunneling mechanisms, including manually configured IPv6-over-IPv4 tunnels [RFC4213] (Nordmark, E. and R. Gilligan, “Basic Transition Mechanisms for IPv6 Hosts and Routers,” October 2005.), 6to4 [RFC3056] (Carpenter, B. and K. Moore, “Connection of IPv6 Domains via IPv4 Clouds,” February 2001.), automatic host-based tunnels [RFC4380] (Huitema, C., “Teredo: Tunneling IPv6 over UDP through Network Address Translations (NATs),” February 2006.), tunnel brokers [RFC3053] (Durand, A., Fasano, P., Guardini, I., and D. Lento, “IPv6 Tunnel Broker,” January 2001.), running IPv6 over MPLS with IPv6 Provider Edge Routers (6PE) [RFC4798] (De Clercq, J., Ooms, D., Prevost, S., and F. Le Faucheur, “Connecting IPv6 Islands over IPv4 MPLS Using IPv6 Provider Edge Routers (6PE),” February 2007.), the use of Virtual Private Network (VPN) or mobility tunnels to carry both IPv4 and IPv6 [RFC4301] (Kent, S. and K. Seo, “Security Architecture for the Internet Protocol,” December 2005.) [RFC5454] (Tsirtsis, G., Park, V., and H. Soliman, “Dual-Stack Mobile IPv4,” March 2009.) [RFC5555] (Soliman, H., “Mobile IPv6 Support for Dual Stack Hosts and Routers,” June 2009.) [RFC5844] (Wakikawa, R. and S. Gundavelli, “IPv4 Support for Proxy Mobile IPv6,” May 2010.) and many others. More advanced solutions provide a mesh-based framework of tunnels [RFC5565] (Wu, J., Cui, Y., Metz, C., and E. Rosen, “Softwire Mesh Framework,” June 2009.).

On a managed network, there are no major challenges with tunneling beyond the possible configuration and MTU problems. Tunneling is very widely deployed both for IPv6 connectivity and other reasons, and well understood. In general, the IETF recommends that tunneling be used if it is necessary to cross a segment of IP version X when communicating from IP version Y to Y. An alternative design would be to employ protocol translation twice. However, this design involves problems similar to those created by IPv4 address translation and is largely untried technology in any larger scale.

On an unmanaged network there have been a number of problems, however. In general, solutions aimed at early adopters (such as 6to4) have at times caused IPv6 connectivity to appear to be available on a network when in fact there is no connectivity. This in turn has lead to need by the content providers to serve IPv6 results for DNS queries only for trusted peers with known high-quality connectivity.

The IPv6 Rapid Deployment (6RD) (Townsley, W. and O. Troan, “IPv6 Rapid Deployment on IPv4 Infrastructures (6rd) -- Protocol Specification,” August 2010.) [RFC5969] approach is a newer version of the 6to4 tunneling solution without the above drawbacks. It offers systematic IPv6 tunneling over IPv4 across an ISP, correspondence between IPv4 and IPv6 routing, and can be deployed within an ISP without the need to rely on other parties.

4.3.  IPv6-Only Core Network

An emerging deployment model uses IPv6 as the dominant protocol at a service provider network, and tunnels IPv4 through this network in a manner converse to the one described in the previous section. There are several motivations for choosing this deployment model:

• There may not be enough public or private IPv4 addresses to support network management functions in an end-to-end fashion, without segmenting the network into small parts with overlapping address space.
• IPv4 address sharing among subscribers may involve new address translation nodes within the service provider's network. IPv6 can be used to reach these nodes. Normal IPv4 routing is insufficient for this purpose, as the same addresses would be used in several parts of the network.
• It may be simpler for the service provider to employ a single-version network.

The recommended tool for this model is Dual Stack Lite [I‑D.ietf‑softwire‑dual‑stack‑lite] (Durand, A., Droms, R., Woodyatt, J., and Y. Lee, “Dual-Stack Lite Broadband Deployments Following IPv4 Exhaustion,” August 2010.). Dual Stack Lite provides both relief for IPv4 address shortage and makes forward progress on IPv6 deployment, by moving service provider networks and IPv4 traffic over IPv6. Given the IPv6 connectivity that Dual Stack Lite runs over, it becomes easy to provide IPv6 connectivity all the way to the end users as well.

4.4.  IPv6-only Deployment

Our final deployment model breaks the requirement that all parties must upgrade to IPv6 before any end-to-end communications use IPv6. This model makes sense when the following conditions are met:

• There is a fact or requirement that there be an IPv4-only domain and an IPv6-only domain.
• There is a requirement that hosts in the IPv4-only domain access servers or peers in the IPv6-only domain and vice versa.

This deployment model would fit well, for instance, a corporate or mobile network that offers IPv6-only networking but where users still wish to access content from the IPv4 Internet.

When we say "IPv4-only" or "IPv6-only", we mean that the applications can communicate only using IPv4 or IPv6; this might be due to lack of capabilities in the applications, host stacks, or the network; the effect is the same. The reason to switch to an IPv6-only network may be a desire to test such a configuration, or to simplify the network. It is expected that as IPv6 deployment progresses, the second reason will become more prevalent. One particular reason for considering an IPv6-only domain is the effect of overlapping private address space to applications. This is important in networks that have exhausted both public and private IPv4 address space and where arranging an IPv6-only network is easier than dealing with the overlapping address space in applications.

Note that the existence of an IPv6-only domain requires that all devices are indeed IPv6-capable. In today's mixed networking environments with legacy devices this can not always be guaranteed. But it can be arranged in networks where all devices are controlled by a central authority. For instance, newly built corporate networks can ensure that the latest device versions are in use. Some networks can also be engineered to support different services over an underlying network and as such, can support IPv6-only networking more easily. For instance, a cellular network may support IPv4-only connectivity for the installed based of existing devices and IPv6-only connectivity for incremental growth with newer IPv6 capable handsets. Similarly, a broadband ISP may support dual stack connectivity for customers that require both IPv4 and IPv6, and offer IPv6-only and NAT64 service for others. In the case of 3GPP and DOCSIS 3.0 access networks, the underling access network architecture allows the flexibility to run different services in parallel to suit the various needs of the customer and the network operator.

It is also necessary for the network operator to have some level of understanding of what applications are used in the network, enabling him to ensure that any communication exchange is in fact predictable, capable of using IPv6, and translatable. In such a case, full interoperability can be expected. This has been demonstrated with some mobile devices, for instance. Note that the requirements on applications are similar to those in networks employing IPv4 NAT technology.

One obvious IPv6-only deployment approach applies to applications that include proxies or relays. One might position a web proxy, a mail server, or a SIP (Session Initiation Protocol) and media stream back-to-back user agent across the boundary between IPv4 and IPv6 domains, so that the application terminates IPv4 sessions on one side and IPv6 sessions on the other. Doing this preserves the end-to-end nature of communications from the gateway to the communicating peer. For obvious reasons, this solution is preferable to the implementation of Application Layer Gateways in network layer translators.

The other approach is network layer IPv4/IPv6 translation as described in IPv4/IPv6 Translation (Baker, F., Li, X., Bao, C., and K. Yin, “Framework for IPv4/IPv6 Translation,” August 2010.) [I‑D.ietf‑behave‑v6v4‑framework] [I‑D.ietf‑behave‑v6v4‑xlate] (Li, X., Bao, C., and F. Baker, “IP/ICMP Translation Algorithm,” September 2010.) [I‑D.ietf‑behave‑v6v4‑xlate‑stateful] (Bagnulo, M., Matthews, P., and I. Beijnum, “Stateful NAT64: Network Address and Protocol Translation from IPv6 Clients to IPv4 Servers,” July 2010.) [RFC6052] (Bao, C., Huitema, C., Bagnulo, M., Boucadair, M., and X. Li, “IPv6 Addressing of IPv4/IPv6 Translators,” October 2010.) [I‑D.ietf‑behave‑dns64] (Bagnulo, M., Sullivan, A., Matthews, P., and I. Beijnum, “DNS64: DNS extensions for Network Address Translation from IPv6 Clients to IPv4 Servers,” October 2010.) [I‑D.ietf‑behave‑ftp64] (Beijnum, I., “An FTP ALG for IPv6-to-IPv4 translation,” September 2010.). IPv4/IPv6 translation at the network layer is similar in its advantages and disadvantages to IPv4/IPv4 translation. It allows a network to provide two types of services to IPv6-only hosts:

• a relatively small set of systems may be configured with IPv4-mapped addresses, enabling stateless interoperation between IPv4-only and IPv6-only domains, each of which can use the other as peers or servers, and
• a larger set of systems with global IPv6 addresses, which can access IPv4 servers using stateful translation but which are inaccessible as peers or servers from the IPv4-only domain.

The former service is used today in some university networks, and the latter in some corporate and mobile networks. The stateless service is naturally better suited for servers, and the stateful service for large numbers of client devices. The latter case occurs typically in a public network access setting. The two services can of course also be used together. In this scenario, network layer translation provides for straightforward services for most applications crossing the IPv4-only/IPv6-only boundary.

One challenge in this model is that as long as IPv4 addresses are still shared, issues similar to those caused by IPv4 NATs will still appear [I‑D.ietf‑intarea‑shared‑addressing‑issues] (Ford, M., Boucadair, M., Durand, A., Levis, P., and P. Roberts, “Issues with IP Address Sharing,” October 2010.). Another challenge relates to communications involving IPv4 referrals. IPv4-literals within certain protocols and formats such at HTML, will fail when passed to IPv6-only hosts since the host does not have an IPv4 address to source the IPv4 communications or an IPv4 route. Measurements on the public internet show that literals appear in a tiny but measurable part of web pages [I‑D.arkko‑ipv6‑only‑experience] (Arkko, J. and A. Keranen, “Experiences from an IPv6-Only Network,” July 2010.), though whether this poses a practical problem is debatable. If this poses a particular problem for the types of applications in use, proxy configurations could be modified to use a proxy for the traffic in question, hosts could be modified to understand how they can map IPv4 literals to IPv6 addresses, or native dual stack could be employed instead.

5.  Conclusions

The fundamental recommendation is to turn IPv6 on. Section 4 (Guidelines for IPv6 Deployment) described four deployment models to do that, presented in rough order of occurrence in the world at the time of this writing. The first models are the most widely deployed today. All four models are recommended by the IETF, though again the first models should be considered first.

As noted in Section 1 (Introduction), variations occur in details and network managers are ultimately in charge of choosing the best solution for their own case. Benefits and challenges discussed in the previous sections should be considered when weighing deployment alternatives. The transition mechanisms that operators have deployed have been a mixed blessing; native dual stack deployments are not used to their full extent if peers have not upgraded, tunnel mechanisms that don't follow the routing of the underlying network have been problematic, and translation has its faults as well. Nevertheless, operators have successfully deployed very large networks with these models.

Some additional considerations are discussed below.

• There is a tradeoff between ability to connect as many different types of devices as possible and the ability to move forward with deployment as independently as possible. As an example, native dual stack ensures best connectivity but requires updates in peer systems before actual traffic flows over IPv6. Conversely, IPv6-only networks are very sensitive to what kind of devices they can support, but can be deployed without any expectation of updates on peer systems.
• Greenfield networks and networks with existing IPv4 devices and users need to be treated differently. In the latter case turning on IPv6 in addition to IPv4 seems the rational choice. In the former case an IPv6-only model may make sense.
• The right deployment model choices also vary as time goes by. For instance, a tunneling solution that makes sense today may become a native dual stack solution as the network and devices in the network evolve. Or an IPv6-only network becomes feasible when a sufficient fraction of client devices become IPv6-enabled.

No matter which deployment model is chosen, many of the important implications of IPv6 deployment are elsewhere within the network: IPv6 needs to be taken into account in network management systems and operations, address assignments, service agreements, firewalls and intrusion detection systems, and so on.

6.  Further Reading

Various aspects of IPv6 deployment have been covered in several documents. Of particular interest may be the basic dual stack definition [RFC4213] (Nordmark, E. and R. Gilligan, “Basic Transition Mechanisms for IPv6 Hosts and Routers,” October 2005.), application aspects [RFC4038] (Shin, M-K., Hong, Y-G., Hagino, J., Savola, P., and E. Castro, “Application Aspects of IPv6 Transition,” March 2005.), deployment in Internet Service Provider Networks [RFC4029] (Lind, M., Ksinant, V., Park, S., Baudot, A., and P. Savola, “Scenarios and Analysis for Introducing IPv6 into ISP Networks,” March 2005.) [RFC6036] (Carpenter, B. and S. Jiang, “Emerging Service Provider Scenarios for IPv6 Deployment,” October 2010.), deployment in enterprise networks [RFC4057] (Bound, J., “IPv6 Enterprise Network Scenarios,” June 2005.) [RFC4852] (Bound, J., Pouffary, Y., Klynsma, S., Chown, T., and D. Green, “IPv6 Enterprise Network Analysis - IP Layer 3 Focus,” April 2007.), IPv6-only deployment [I‑D.arkko‑ipv6‑only‑experience] (Arkko, J. and A. Keranen, “Experiences from an IPv6-Only Network,” July 2010.), and considerations in specific access networks such as cellular networks [RFC3314] (Wasserman, M., “Recommendations for IPv6 in Third Generation Partnership Project (3GPP) Standards,” September 2002.) [RFC3574] (Soininen, J., “Transition Scenarios for 3GPP Networks,” August 2003.) [RFC4215] (Wiljakka, J., “Analysis on IPv6 Transition in Third Generation Partnership Project (3GPP) Networks,” October 2005.) [I‑D.ietf‑v6ops‑v6‑in‑mobile‑networks] (Koodli, R., “Mobile Networks Considerations for IPv6 Deployment,” October 2010.) or 802.16 networks [RFC5181] (Shin, M-K., Han, Y-H., Kim, S-E., and D. Premec, “IPv6 Deployment Scenarios in 802.16 Networks,” May 2008.).

This document provides general guidance on IPv6 deployment models that have been found suitable for most organizations. The purpose of this document is not to enumerate all special circumstances that may warrant other types of deployment models or the details of the necessary transition tools. Many of the special cases and details have been discussed in the above documents.

7.  Security Considerations

While there are detailed differences between the security properties and vulnerabilities between IPv4 and IPv6, in general they provide a very similar level of security, and are subject to the same threats. With both protocols, specific security issues are more likely to be found at the practical level than in the specifications. The practical issues include, for instance, bugs or available security mechanisms on a given product. When deploying IPv6, it is important to ensure that the necessary security capabilities exist on the network components even when dealing with IPv6 traffic. For instance, firewall capabilities have often been a challenge in IPv6 deployments.

This document has no impact on the security properties of specific IPv6 transition tools. The security considerations relating to the transition tools are described in the relevant documents, for instance, [RFC4213] (Nordmark, E. and R. Gilligan, “Basic Transition Mechanisms for IPv6 Hosts and Routers,” October 2005.) [I‑D.ietf‑behave‑dns64] (Bagnulo, M., Sullivan, A., Matthews, P., and I. Beijnum, “DNS64: DNS extensions for Network Address Translation from IPv6 Clients to IPv4 Servers,” October 2010.) [I‑D.ietf‑softwire‑dual‑stack‑lite] (Durand, A., Droms, R., Woodyatt, J., and Y. Lee, “Dual-Stack Lite Broadband Deployments Following IPv4 Exhaustion,” August 2010.) [I‑D.ietf‑v6ops‑tunnel‑security‑concerns] (Krishnan, S., Thaler, D., and J. Hoagland, “Security Concerns With IP Tunneling,” October 2010.).

8.  IANA Considerations

This document has no IANA implications.

9.  References

9.1. Normative References

9.2. Informative References

Appendix A.  Acknowledgments

The authors would like to thank the many people who have engaged in discussions around this topic over the years. Some of the material in this document comes originally from Fred Baker's presentation in a workshop in Shanghai [Baker.Shanghai] (Baker, F., “The view from IPv6 Operations WG (and we’ll talk about translation),” November 2009.). In addition, the authors would like to thank Mark Townsley with whom the Jari Arkko wrote an earlier document [I‑D.arkko‑townsley‑coexistence] (Arkko, J. and M. Townsley, “IPv4 Run-Out and IPv4-IPv6 Co-Existence Scenarios,” October 2010.). Brian Carpenter submitted an in-depth review and provided significant new text. Cameron Byrne provided significant feedback on the key recommendations in this memo. The authors would also like thank Dave Thaler, Alain Durand, Randy Bush, and Dan Wing who have always provided valuable guidance in this field. Finally, the authors would like to thank Suresh Krishnan, Fredrik Garneij, Mohamed Boucadair, Remi Despres, Kurtis Lindqvist, Shawn Emery, Dan Romascanu, Tim Polk, Ralph Droms, Sean Turner, Tina Tsou, Nevil Brownlee, and Joel Jaeggli who have commented on early versions of this memo.

Authors' Addresses