summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc6180.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc6180.txt')
-rw-r--r--doc/rfc/rfc6180.txt1123
1 files changed, 1123 insertions, 0 deletions
diff --git a/doc/rfc/rfc6180.txt b/doc/rfc/rfc6180.txt
new file mode 100644
index 0000000..bb1bafe
--- /dev/null
+++ b/doc/rfc/rfc6180.txt
@@ -0,0 +1,1123 @@
+
+
+
+
+
+
+Internet Engineering Task Force (IETF) J. Arkko
+Request for Comments: 6180 Ericsson
+Category: Informational F. Baker
+ISSN: 2070-1721 Cisco Systems
+ May 2011
+
+
+ Guidelines for Using IPv6 Transition Mechanisms during IPv6 Deployment
+
+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 it recommends ones that have been found to work well in
+ operational networks in many common situations.
+
+Status of This Memo
+
+ This document is not an Internet Standards Track specification; it is
+ published for informational purposes.
+
+ This document is a product of the Internet Engineering Task Force
+ (IETF). It represents the consensus of the IETF community. It has
+ received public review and has been approved for publication by the
+ Internet Engineering Steering Group (IESG). Not all documents
+ approved by the IESG are a candidate for any level of Internet
+ Standard; see Section 2 of RFC 5741.
+
+ Information about the current status of this document, any errata,
+ and how to provide feedback on it may be obtained at
+ http://www.rfc-editor.org/info/rfc6180.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Arkko & Baker Informational [Page 1]
+
+RFC 6180 IPv6 Transition Guidelines May 2011
+
+
+Copyright Notice
+
+ Copyright (c) 2011 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 . . . . . . . . . . . . . . . . . . . . . . . . . 3
+ 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
+ 3. Principles . . . . . . . . . . . . . . . . . . . . . . . . . . 4
+ 3.1. Goals . . . . . . . . . . . . . . . . . . . . . . . . . . 5
+ 3.2. Choosing a Deployment Model . . . . . . . . . . . . . . . 6
+ 4. Guidelines for IPv6 Deployment . . . . . . . . . . . . . . . . 7
+ 4.1. Native Dual Stack . . . . . . . . . . . . . . . . . . . . 8
+ 4.2. Crossing IPv4 Islands . . . . . . . . . . . . . . . . . . 10
+ 4.3. IPv6-Only Core Network . . . . . . . . . . . . . . . . . . 11
+ 4.4. IPv6-Only Deployment . . . . . . . . . . . . . . . . . . . 11
+ 5. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 14
+ 6. Further Reading . . . . . . . . . . . . . . . . . . . . . . . 15
+ 7. Security Considerations . . . . . . . . . . . . . . . . . . . 15
+ 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16
+ 8.1. Normative References . . . . . . . . . . . . . . . . . . . 16
+ 8.2. Informative References . . . . . . . . . . . . . . . . . . 16
+ Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . . 20
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Arkko & Baker Informational [Page 2]
+
+RFC 6180 IPv6 Transition Guidelines May 2011
+
+
+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 Regional Internet Registries (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 "An Internet Transition Plan" [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
+ introduces some terminology, Section 3 discusses some of the general
+ principles behind choosing particular deployment models and tools,
+ Section 4 goes through the recommended deployment models for common
+ situations, and Section 5 provides some concluding remarks about the
+ choice between these models.
+
+
+
+
+Arkko & Baker Informational [Page 3]
+
+RFC 6180 IPv6 Transition Guidelines May 2011
+
+
+ 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].
+
+ Dual Stack: refers to a technique for providing complete support for
+ both Internet protocols -- IPv4 and IPv6 -- in hosts and routers
+ [RFC4213].
+
+ 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 [DS-lite].
+
+ IPv4-only domain: as defined in [RFC6144], 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 [RFC6144], 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] and
+ deprecated due to the reasons stated in [RFC4966].
+
+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
+
+
+
+Arkko & Baker Informational [Page 4]
+
+RFC 6180 IPv6 Transition Guidelines May 2011
+
+
+ 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, 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 coexistence 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 (Third
+ Generation Partnership Project), 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
+
+
+
+Arkko & Baker Informational [Page 5]
+
+RFC 6180 IPv6 Transition Guidelines May 2011
+
+
+ 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
+ be able to 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 allow
+ 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 far more important than fine-grained
+ performance differences. In general, it is not productive to focus
+ on the optimization of a design that is intended 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, as described in [RFC5218] and [Baker.Shanghai], that have
+ been important for success include:
+
+ o The ability to offer a valuable service. In the case of the
+ Internet, connectivity has been this service.
+
+
+
+
+Arkko & Baker Informational [Page 6]
+
+RFC 6180 IPv6 Transition Guidelines May 2011
+
+
+ o The ability to deploy the solution in an incremental fashion.
+
+ o Simplicity. This has been a key factor in making it possible for
+ all types of devices to support the Internet protocols.
+
+ o Openly available implementations. These make it easier for
+ researchers, start-ups, and others to build on or improve existing
+ components.
+
+ o 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.
+
+ o 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
+
+
+
+Arkko & Baker Informational [Page 7]
+
+RFC 6180 IPv6 Transition Guidelines May 2011
+
+
+ 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 that 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 of
+ IPv6-IPv4 translation (NAT-PT) [RFC2766] suffers from a number of
+ drawbacks arising from, for example, its attempt to capture DNS
+ queries on path [RFC4966]. 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 Transmission Unit (MTU) settings. As a result,
+ these networks are robust and reliable. Accordingly, this is the
+ recommended deployment model for most networks and is supported by
+ IETF standards such as dual stack [RFC4213] and address selection
+ [RFC3484]. Similarly, while there are some remaining challenges,
+ this model is also preferred by many service providers and network
+ managers [RFC6036] [IPv6-only-experience].
+
+ The challenges associated with this model are twofold. 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
+
+
+
+Arkko & Baker Informational [Page 8]
+
+RFC 6180 IPv6 Transition Guidelines May 2011
+
+
+ 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]. There are scenarios where these means are
+ insufficient. The following sections discuss deployment models that
+ enable parts of the network to 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 worldwide 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] and [shared-addressing-issues]. As a result, it allows
+ the construction of IPv6-based applications that offer more
+ functionality.
+
+
+
+Arkko & Baker Informational [Page 9]
+
+RFC 6180 IPv6 Transition Guidelines May 2011
+
+
+ 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 [L2-NAT] [DS-extra-lite]. Other networks may require a
+ combination of IPv4/IPv4 NAT enhancements and tunneling. These
+ scenarios are discussed further in Section 4.3.
+
+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. It also increases the probability that the
+ Path MTU algorithm will be used, as many implementations derive their
+ default MTU from the Ethernet frame size; ICMP filtering interacts
+ poorly with the Path MTU algorithm in [RFC1981]. 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 cannot be established, such as when crossing another
+ administrative domain or a router that cannot be easily reconfigured.
+
+ There are several types of tunneling mechanisms, including manually
+ configured IPv6-over-IPv4 tunnels [RFC4213], 6to4 [RFC3056],
+ automatic host-based tunnels [RFC4380], tunnel brokers [RFC3053],
+ running IPv6 over MPLS with IPv6 Provider Edge Routers (6PE)
+ [RFC4798], the use of Virtual Private Networks (VPNs) or mobility
+ tunnels to carry both IPv4 and IPv6 [RFC4301] [RFC5454] [RFC5555]
+ [RFC5844], and many others. More advanced solutions provide a mesh-
+ based framework of tunnels [RFC5565].
+
+ 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 is 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.
+
+
+
+Arkko & Baker Informational [Page 10]
+
+RFC 6180 IPv6 Transition Guidelines May 2011
+
+
+ On an unmanaged network, however, there have been a number of
+ problems. 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. In
+ turn, this has lead to the content providers needing to serve IPv6
+ results for DNS queries only for trusted peers with known high-
+ quality connectivity.
+
+ The IPv6 Rapid Deployment (6RD) [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:
+
+ o 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.
+
+ o 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.
+
+ o It may be simpler for the service provider to employ a single-
+ version network.
+
+ The recommended tool for this model is Dual Stack Lite [DS-lite].
+ Dual Stack Lite both provides 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:
+
+
+
+
+Arkko & Baker Informational [Page 11]
+
+RFC 6180 IPv6 Transition Guidelines May 2011
+
+
+ o There is a fact or requirement that there be an IPv4-only domain
+ and an IPv6-only domain.
+
+ o 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 cannot 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 base 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 underlying 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
+
+
+
+
+
+Arkko & Baker Informational [Page 12]
+
+RFC 6180 IPv6 Transition Guidelines May 2011
+
+
+ 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" [RFC6144] [RFC6145] [RFC6146]
+ [RFC6052] [RFC6147] [FTP64]. IPv4/IPv6 translation at the network
+ layer is similar to IPv4/IPv4 translation in its advantages and
+ disadvantages. It allows a network to provide two types of services
+ to IPv6-only hosts:
+
+ o 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
+
+ o 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 [shared-addressing-issues]. Another challenge relates to
+ communications involving IPv4 referrals. IPv4-literals within
+ certain protocols and formats, such as 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
+
+
+
+Arkko & Baker Informational [Page 13]
+
+RFC 6180 IPv6 Transition Guidelines May 2011
+
+
+ part of web pages [IPv6-only-experience], 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 on IPv6. Section 4
+ described four deployment models to do that, presented in rough order
+ of occurrence in the world at the time of this writing. The first
+ two models are the most widely deployed today. All four models are
+ recommended by the IETF, though, again, the first two models should
+ take priority where they are applicable.
+
+ As noted in Section 1, 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.
+
+ o 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 the 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.
+
+ o "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.
+
+ o 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.
+
+
+
+Arkko & Baker Informational [Page 14]
+
+RFC 6180 IPv6 Transition Guidelines May 2011
+
+
+ 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,
+ 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], application aspects [RFC4038], deployment in
+ Internet service provider networks [RFC4029] [RFC6036], deployment in
+ enterprise networks [RFC4057] [RFC4852], IPv6-only deployment
+ [IPv6-only-experience], and considerations in specific access
+ networks such as cellular networks [RFC3314] [RFC3574] [RFC4215]
+ [v6-in-mobile] or 802.16 networks [RFC5181].
+
+ 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], [RFC6147], [DS-lite], and [RFC6169].
+
+
+
+
+
+
+
+
+
+Arkko & Baker Informational [Page 15]
+
+RFC 6180 IPv6 Transition Guidelines May 2011
+
+
+8. References
+
+8.1. Normative References
+
+ [RFC2663] Srisuresh, P. and M. Holdrege, "IP Network Address
+ Translator (NAT) Terminology and Considerations",
+ RFC 2663, August 1999.
+
+ [RFC3484] Draves, R., "Default Address Selection for Internet
+ Protocol version 6 (IPv6)", RFC 3484, February 2003.
+
+ [RFC4213] Nordmark, E. and R. Gilligan, "Basic Transition Mechanisms
+ for IPv6 Hosts and Routers", RFC 4213, October 2005.
+
+ [RFC4301] Kent, S. and K. Seo, "Security Architecture for the
+ Internet Protocol", RFC 4301, December 2005.
+
+ [RFC4380] Huitema, C., "Teredo: Tunneling IPv6 over UDP through
+ Network Address Translations (NATs)", RFC 4380,
+ February 2006.
+
+ [RFC5454] Tsirtsis, G., Park, V., and H. Soliman, "Dual-Stack Mobile
+ IPv4", RFC 5454, March 2009.
+
+ [RFC5555] Soliman, H., "Mobile IPv6 Support for Dual Stack Hosts and
+ Routers", RFC 5555, June 2009.
+
+ [RFC5565] Wu, J., Cui, Y., Metz, C., and E. Rosen, "Softwire Mesh
+ Framework", RFC 5565, June 2009.
+
+8.2. Informative References
+
+ [Baker.Shanghai]
+ Baker, F., "The view from IPv6 Operations WG (and we'll
+ talk about translation)", Presentation in the China Mobile
+ Workshop on IPv6 Deployment in Cellular Networks,
+ Shanghai, China, November 2009, <http://ipv6ws.arkko.com/
+ presentations/3GPP-IETF-V6OPS-Discussion.pdf>.
+
+ [DS-extra-lite]
+ Arkko, J., Eggert, L., and M. Townsley, "Scalable
+ Operation of Address Translators with Per-Interface
+ Bindings", Work in Progress, February 2011.
+
+ [DS-lite] Durand, A., Droms, R., Woodyatt, J., and Y. Lee, "Dual-
+ Stack Lite Broadband Deployments Following IPv4
+ Exhaustion", Work in Progress, August 2010.
+
+
+
+
+Arkko & Baker Informational [Page 16]
+
+RFC 6180 IPv6 Transition Guidelines May 2011
+
+
+ [FTP64] Beijnum, I., "An FTP ALG for IPv6-to-IPv4 translation",
+ Work in Progress, March 2011.
+
+ [IPv6-only-experience]
+ Arkko, J. and A. Keranen, "Experiences from an IPv6-Only
+ Network", Work in Progress, April 2011.
+
+ [L2-NAT] Miles, D. and M. Townsley, "Layer2-Aware NAT", Work
+ in Progress, March 2009.
+
+ [RFC1981] McCann, J., Deering, S., and J. Mogul, "Path MTU Discovery
+ for IP version 6", RFC 1981, August 1996.
+
+ [RFC2766] Tsirtsis, G. and P. Srisuresh, "Network Address
+ Translation - Protocol Translation (NAT-PT)", RFC 2766,
+ February 2000.
+
+ [RFC2993] Hain, T., "Architectural Implications of NAT", RFC 2993,
+ November 2000.
+
+ [RFC3053] Durand, A., Fasano, P., Guardini, I., and D. Lento, "IPv6
+ Tunnel Broker", RFC 3053, January 2001.
+
+ [RFC3056] Carpenter, B. and K. Moore, "Connection of IPv6 Domains
+ via IPv4 Clouds", RFC 3056, February 2001.
+
+ [RFC3314] Wasserman, M., "Recommendations for IPv6 in Third
+ Generation Partnership Project (3GPP) Standards",
+ RFC 3314, September 2002.
+
+ [RFC3574] Soininen, J., "Transition Scenarios for 3GPP Networks",
+ RFC 3574, August 2003.
+
+ [RFC4029] Lind, M., Ksinant, V., Park, S., Baudot, A., and P.
+ Savola, "Scenarios and Analysis for Introducing IPv6 into
+ ISP Networks", RFC 4029, March 2005.
+
+ [RFC4038] Shin, M-K., Hong, Y-G., Hagino, J., Savola, P., and E.
+ Castro, "Application Aspects of IPv6 Transition",
+ RFC 4038, March 2005.
+
+ [RFC4057] Bound, J., "IPv6 Enterprise Network Scenarios", RFC 4057,
+ June 2005.
+
+ [RFC4215] Wiljakka, J., "Analysis on IPv6 Transition in Third
+ Generation Partnership Project (3GPP) Networks", RFC 4215,
+ October 2005.
+
+
+
+
+Arkko & Baker Informational [Page 17]
+
+RFC 6180 IPv6 Transition Guidelines May 2011
+
+
+ [RFC4798] De Clercq, J., Ooms, D., Prevost, S., and F. Le Faucheur,
+ "Connecting IPv6 Islands over IPv4 MPLS Using IPv6
+ Provider Edge Routers (6PE)", RFC 4798, February 2007.
+
+ [RFC4852] Bound, J., Pouffary, Y., Klynsma, S., Chown, T., and D.
+ Green, "IPv6 Enterprise Network Analysis - IP Layer 3
+ Focus", RFC 4852, April 2007.
+
+ [RFC4966] Aoun, C. and E. Davies, "Reasons to Move the Network
+ Address Translator - Protocol Translator (NAT-PT) to
+ Historic Status", RFC 4966, July 2007.
+
+ [RFC5181] Shin, M-K., Han, Y-H., Kim, S-E., and D. Premec, "IPv6
+ Deployment Scenarios in 802.16 Networks", RFC 5181,
+ May 2008.
+
+ [RFC5211] Curran, J., "An Internet Transition Plan", RFC 5211,
+ July 2008.
+
+ [RFC5218] Thaler, D. and B. Aboba, "What Makes For a Successful
+ Protocol?", RFC 5218, July 2008.
+
+ [RFC5844] Wakikawa, R. and S. Gundavelli, "IPv4 Support for Proxy
+ Mobile IPv6", RFC 5844, May 2010.
+
+ [RFC5969] Townsley, W. and O. Troan, "IPv6 Rapid Deployment on IPv4
+ Infrastructures (6rd) -- Protocol Specification",
+ RFC 5969, August 2010.
+
+ [RFC6036] Carpenter, B. and S. Jiang, "Emerging Service Provider
+ Scenarios for IPv6 Deployment", RFC 6036, October 2010.
+
+ [RFC6052] Bao, C., Huitema, C., Bagnulo, M., Boucadair, M., and X.
+ Li, "IPv6 Addressing of IPv4/IPv6 Translators", RFC 6052,
+ October 2010.
+
+ [RFC6127] Arkko, J. and M. Townsley, "IPv4 Run-Out and IPv4-IPv6
+ Co-Existence Scenarios", RFC 6127, May 2011.
+
+ [RFC6144] Baker, F., Li, X., Bao, C., and K. Yin, "Framework for
+ IPv4/IPv6 Translation", RFC 6144, April 2011.
+
+ [RFC6145] Li, X., Bao, C., and F. Baker, "IP/ICMP Translation
+ Algorithm", RFC 6145, April 2011.
+
+ [RFC6146] Bagnulo, M., Matthews, P., and I. Beijnum, "Stateful
+ NAT64: Network Address and Protocol Translation from IPv6
+ Clients to IPv4 Servers", RFC 6146, April 2011.
+
+
+
+Arkko & Baker Informational [Page 18]
+
+RFC 6180 IPv6 Transition Guidelines May 2011
+
+
+ [RFC6147] Bagnulo, M., Sullivan, A., Matthews, P., and I. Beijnum,
+ "DNS64: DNS extensions for Network Address Translation
+ from IPv6 Clients to IPv4 Servers", RFC 6147, April 2011.
+
+ [RFC6169] Krishnan, S., Thaler, D., and J. Hoagland, "Security
+ Concerns with IP Tunneling", RFC 6169, April 2011.
+
+ [networkworld.youtube]
+ Marsan, C., "YouTube support of IPv6 seen in dramatic
+ traffic spike", Network World article, February 2010,
+ <http://www.networkworld.com/news/2010/
+ 020110-youtube-ipv6.html>.
+
+ [shared-addressing-issues]
+ Ford, M., Boucadair, M., Durand, A., Levis, P., and P.
+ Roberts, "Issues with IP Address Sharing", Work in
+ Progress, March 2011.
+
+ [v6-in-mobile]
+ Koodli, R., "Mobile Networks Considerations for IPv6
+ Deployment", Work in Progress, May 2011.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Arkko & Baker Informational [Page 19]
+
+RFC 6180 IPv6 Transition Guidelines May 2011
+
+
+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]. In addition, the authors
+ would like to thank Mark Townsley with whom Jari Arkko wrote an
+ earlier document [RFC6127]. 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
+
+ Jari Arkko
+ Ericsson
+ Jorvas 02420
+ Finland
+
+ EMail: jari.arkko@piuha.net
+
+
+ Fred Baker
+ Cisco Systems
+ Santa Barbara, California 93117
+ USA
+
+ EMail: fred@cisco.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Arkko & Baker Informational [Page 20]
+