Network Working Group J. Arkko
Internet-Draft Ericsson
Intended status: Informational F. Baker
Expires: February 19, 2011 Cisco Systems
August 18, 2010
Guidelines for Using IPv6 Transition Mechanisms during IPv6 Deployment
draft-arkko-ipv6-transition-guidelines-04
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 February 19, 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
Arkko & Baker Expires February 19, 2011 [Page 1]
Internet-Draft IPv6 Transition Guidelines August 2010
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 . . . . . . . . . . . . . . . . . . . . . . . . . . 4
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 . . . . . . . . . . . . . . . . . . 10
4.4. Unilateral Deployment . . . . . . . . . . . . . . . . . . 11
5. Further Reading . . . . . . . . . . . . . . . . . . . . . . . 12
6. Security Considerations . . . . . . . . . . . . . . . . . . . 13
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13
8.1. Normative References . . . . . . . . . . . . . . . . . . . 13
8.2. Informative References . . . . . . . . . . . . . . . . . . 14
Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . . 17
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 17
Arkko & Baker Expires February 19, 2011 [Page 2]
Internet-Draft IPv6 Transition Guidelines August 2010
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, the IANA "free pool" contained only 24
unallocated unicast IPv4 /8 prefixes. This is sufficient for the
next 2-3 years at best. 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.
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,
and Section 4 goes through the recommended deployment models for
common situations
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. Also, a systematic operational
plan for the transition is required, but the details depend entirely
on the individual network.
Arkko & Baker Expires February 19, 2011 [Page 3]
Internet-Draft IPv6 Transition Guidelines August 2010
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 [I-D.ietf-softwire-dual-stack-lite].
"IPv6 Rapid Deployment", also called "6rd", refers to a technique
that employs tunneling to provide IPv6 connectivity over IPv4
networks [RFC5969].
"NAT-PT" refers to a specific, old design of a Network Address
Translator - Protocol Translator defined in [RFC2766].
3. Principles
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
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.
3.1. Goals
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
Arkko & Baker Expires February 19, 2011 [Page 4]
Internet-Draft IPv6 Transition Guidelines August 2010
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, and the resulting
obsolescence of IPv4. 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.
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 a part 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 can
easily be deployed as IPv6-only networks. In most other networks
IPv4 has to be considered. A typical requirement is that older,
IPv4-only devices 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 or
proxy 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.
Arkko & Baker Expires February 19, 2011 [Page 5]
Internet-Draft IPv6 Transition Guidelines August 2010
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][baker.shanghai]
o The ability to offer a valuable service. In the case of the
Internet, connectivity has been this service.
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.
Arkko & Baker Expires February 19, 2011 [Page 6]
Internet-Draft IPv6 Transition Guidelines August 2010
These factors are also important when choosing IPv6 migration tools.
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 default,
simplest deployment situation where native connectivity is available
and both IP versions are used. Since native IPv6 connectivity 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 unilateral deployment of IPv6, i.e., being able to employ
IPv6 for a particular communication flow even if the other end is
still on IPv4.
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] 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
Arkko & Baker Expires February 19, 2011 [Page 7]
Internet-Draft IPv6 Transition Guidelines August 2010
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] and address selection
[RFC3484]. Similarly, while there are some remaining challenges,
this model is also preferred by many service providers and network
managers [I-D.ietf-v6ops-isp-scenarios]
[I-D.arkko-ipv6-only-experience].
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].
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 a requirement to
Arkko & Baker Expires February 19, 2011 [Page 8]
Internet-Draft IPv6 Transition Guidelines August 2010
resolve names to IPv6 addresses. Such agreements are similar to
peering agreements and are 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 forward progress on world-wide IPv6 deployment. The largest
IPv6 networks, notably NRENS like 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 [I-D.ietf-intarea-shared-addressing-issues]. 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] [I-D.arkko-dual-stack-extra-lite].
Other networks may require a combination of IPv4/IPv4 NAT
enhancements and tunneling. These scenarios are discussed further in
Section 4.3.
Arkko & Baker Expires February 19, 2011 [Page 9]
Internet-Draft IPv6 Transition Guidelines August 2010
4.2. Crossing IPv4 Islands
Native IPv6 connectivity is not always available, but fortunately it
can established using tunnels. Tunneling introduces some additional
complexity and has a risk of MTU or other mis-configurations. It
SHOULD only be used when establishment native connectivity is not
possible, such as when it involves crossing another administrative
domain or a router that cannot be easily re-configured.
There are several types tunneling mechanisms, including manually
configured IPv6-over-IPv4 tunnels [RFC4213], 6to4 [RFC3056],
automatic host-based tunnels [RFC4380], tunnel brokers [RFC3053], and
the use of Virtual Private Network (VPN) or mobility tunnels to carry
both IPv4 and IPv6 [RFC4301] [RFC5454] [RFC5555]. 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 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 be 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 [RFC5969] approach, originally developed
and deployed by Free.fr, has been used successfully to rapidly deploy
an IPv6 service based on tunneling from edge to edge over an existing
IPv4 infrastructure. The chief advantage of this approach is that it
deploys the service quickly while enabling the network administration
to manage its deployment outlays, and ensures the correspondence
between IPv4 and IPv6 routing.
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:
Arkko & Baker Expires February 19, 2011 [Page 10]
Internet-Draft IPv6 Transition Guidelines August 2010
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
[I-D.ietf-softwire-dual-stack-lite]. 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 this IPv6 connectivity, as a side-effect it becomes easy
to provide IPv6 connectivity all the way to the end users.
4.4. Unilateral Deployment
Our final deployment model breaks the requirement that all parties
must upgrade to IPv6 before any actual communications use IPv6. This
model makes sense when the following conditions are met:
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.
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
Arkko & Baker Expires February 19, 2011 [Page 11]
Internet-Draft IPv6 Transition Guidelines August 2010
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.
One obvious unilateral deployment approach applies to applications
that include proxies or relays. One might position a web proxy, a
mail server, or a voice transcoder 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 between gateways. 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 [I-D.ietf-behave-v6v4-framework]
[I-D.ietf-behave-v6v4-xlate] [I-D.ietf-behave-v6v4-xlate-stateful]
[I-D.ietf-behave-address-format] [I-D.ietf-behave-dns64]
[I-D.ietf-behave-ftp64]. This is currently used between CERNET and
CERNET2. IPv4/IPv6 translation at the network layer is similar in
its advantages and pitfalls to IPv4/IPv4 translation. It allows a
network to provide a service to two sets of 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 general IPv6 addresses, which can
access IPv4 servers using stateful translation but which are
inaccessible as peers or servers from the IPv4-only domain.
5. 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]
[I-D.ietf-v6ops-isp-scenarios], deployment in enterprise networks
[RFC4057] [RFC4852], unilateral IPv6-only deployment
[I-D.arkko-ipv6-only-experience], and considerations in specific
access networks such as cellular networks [RFC3314] [RFC3574]
[RFC4215] 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
Arkko & Baker Expires February 19, 2011 [Page 12]
Internet-Draft IPv6 Transition Guidelines August 2010
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.
6. 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 like 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.
7. IANA Considerations
This document has no IANA implications.
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.
Arkko & Baker Expires February 19, 2011 [Page 13]
Internet-Draft IPv6 Transition Guidelines August 2010
[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
[]
Arkko, J. and L. Eggert, "Scalable Operation of Address
Translators with Per-Interface Bindings",
draft-arkko-dual-stack-extra-lite-00 (work in progress),
February 2010.
[I-D.arkko-ipv6-only-experience]
Arkko, J. and A. Keranen, "Experiences from an IPv6-Only
Network", draft-arkko-ipv6-only-experience-01 (work in
progress), July 2010.
[I-D.arkko-townsley-coexistence]
Arkko, J. and M. Townsley, "IPv4 Run-Out and IPv4-IPv6 Co-
Existence Scenarios", draft-arkko-townsley-coexistence-03
(work in progress), July 2009.
[I-D.ietf-behave-v6v4-framework]
Baker, F., Li, X., Bao, C., and K. Yin, "Framework for
IPv4/IPv6 Translation",
draft-ietf-behave-v6v4-framework-10 (work in progress),
August 2010.
[I-D.ietf-behave-address-format]
Bao, C., Huitema, C., Bagnulo, M., Boucadair, M., and X.
Li, "IPv6 Addressing of IPv4/IPv6 Translators",
draft-ietf-behave-address-format-10 (work in progress),
August 2010.
[I-D.ietf-behave-v6v4-xlate]
Li, X., Bao, C., and F. Baker, "IP/ICMP Translation
Algorithm", draft-ietf-behave-v6v4-xlate-21 (work in
progress), August 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",
Arkko & Baker Expires February 19, 2011 [Page 14]
Internet-Draft IPv6 Transition Guidelines August 2010
draft-ietf-behave-v6v4-xlate-stateful-12 (work in
progress), July 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",
draft-ietf-behave-dns64-10 (work in progress), July 2010.
[I-D.ietf-behave-ftp64]
Beijnum, I., "IPv6-to-IPv4 translation FTP
considerations", draft-ietf-behave-ftp64-04 (work in
progress), July 2010.
[I-D.ietf-intarea-shared-addressing-issues]
Ford, M., Boucadair, M., Durand, A., Levis, P., and P.
Roberts, "Issues with IP Address Sharing",
draft-ietf-intarea-shared-addressing-issues-01 (work in
progress), June 2010.
[I-D.ietf-softwire-dual-stack-lite]
Durand, A., Droms, R., Haberman, B., Woodyatt, J., Lee,
Y., and R. Bush, "Dual-Stack Lite Broadband Deployments
Following IPv4 Exhaustion",
draft-ietf-softwire-dual-stack-lite-05 (work in progress),
July 2010.
[I-D.ietf-v6ops-isp-scenarios]
Carpenter, B. and S. Jiang, "Emerging Service Provider
Scenarios for IPv6 Deployment",
draft-ietf-v6ops-isp-scenarios-00 (work in progress),
April 2010.
[I-D.miles-behave-l2nat]
Miles, D. and M. Townsley, "Layer2-Aware NAT",
draft-miles-behave-l2nat-00 (work in progress),
March 2009.
[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.
Arkko & Baker Expires February 19, 2011 [Page 15]
Internet-Draft IPv6 Transition Guidelines August 2010
[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.
[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.
[RFC5218] Thaler, D. and B. Aboba, "What Makes For a Successful
Protocol?", RFC 5218, July 2008.
[RFC5969] Townsley, W. and O. Troan, "IPv6 Rapid Deployment on IPv4
Infrastructures (6rd) -- Protocol Specification",
RFC 5969, August 2010.
[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, http://
Arkko & Baker Expires February 19, 2011 [Page 16]
Internet-Draft IPv6 Transition Guidelines August 2010
ipv6ws.arkko.com/presentations/
3GPP-IETF-V6OPS-Discussion.pdf, Shanghai, China,
November 2009.
[networkworld.youtube]
Marsan, C., "YouTube support of IPv6 seen in dramatic
traffic spike", Network World article http://
www.networkworld.com/news/2010/020110-youtube-ipv6.html,
February 2010.
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 the Jari Arkko wrote an
earlier document [I-D.arkko-townsley-coexistence]. Brian Carpenter
submitted an in-depth review and provided significant new text. 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 Cameron Byrne,
Suresh Krishnan, Fredrik Garneij, and Mohamed Boucadair who have
commented on early versions of this draft.
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 Expires February 19, 2011 [Page 17]
