One document matched: draft-arkko-ipv6-transition-guidelines-06.xml
<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<rfc category="info" docName="draft-arkko-ipv6-transition-guidelines-06"
ipr="trust200902">
<?rfc toc="yes"?>
<?rfc symrefs="yes"?>
<?rfc autobreaks="yes"?>
<?rfc tocindent="yes"?>
<?rfc compact="yes"?>
<?rfc subcompact="no"?>
<front>
<title abbrev="IPv6 Transition Guidelines">Guidelines for Using IPv6
Transition Mechanisms during IPv6 Deployment</title>
<author fullname="Jari Arkko" initials="J" surname="Arkko">
<organization>Ericsson</organization>
<address>
<postal>
<street></street>
<city>Jorvas</city>
<code>02420</code>
<country>Finland</country>
</postal>
<email>jari.arkko@piuha.net</email>
</address>
</author>
<author fullname="Fred Baker" initials="F.J." surname="Baker">
<organization>Cisco Systems</organization>
<address>
<postal>
<street></street>
<city>Santa Barbara</city>
<code>93117</code>
<region>California</region>
<country>USA</country>
</postal>
<email>fred@cisco.com</email>
</address>
</author>
<!--
<author fullname="Brian Carpenter" initials="B." surname="Carpenter">
<organization>Department of Computer Science, University of Auckland</organization>
<address>
<postal>
<street>PB 92019</street>
<city>Auckland</city>
<code>1142</code>
<country>New Zealand</country>
</postal>
<email>brian.e.carpenter@gmail.com</email>
</address>
</author>
!-->
<date year="2010" />
<keyword>IPv6</keyword>
<abstract>
<t>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.</t>
</abstract>
</front>
<middle>
<section anchor="intro" title="Introduction">
<t>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.</t>
<t>John Curran, in his <xref target="RFC5211">Internet Transition
Plan</xref>, 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.</t>
<t>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.</t>
<t>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.</t>
<!-- <t>As a result, it is useful to provide guidance about the
applicability of various deployment models and migration tools.
This document discusses these models and tools, and recommends those
that have been found to work well in many common situations.</t> !-->
<t>The rest of this document is organized as follows. <xref
target="terms"></xref> introduces some terminology, <xref
target="principles"></xref> discusses some of the general principles
behind choosing particular deployment models and tools, and <xref
target="recommendations"></xref> goes through the recommended deployment
models for common situations<!-- , and <xref target="catalog"/> summarizes the applicability of various migration tools. !--></t>
<t>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.</t>
</section>
<section anchor="terms" title="Terminology">
<t>In this document, the following terms are used. <list style="hanging">
<t hangText="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 <xref
target="RFC2663"></xref>.</t>
<t hangText="Dual Stack:">refers to a technique for providing
complete support for both Internet protocols -- IPv4 and IPv6 -- in
hosts and routers <xref target="RFC4213"></xref>.</t>
<t hangText="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 <xref
target="I-D.ietf-softwire-dual-stack-lite"></xref>.</t>
<t hangText="IPv6 Rapid Deployment:">also called "6rd", refers to a
technique that employs tunneling to provide IPv6 connectivity over
IPv4 networks <xref target="RFC5969"></xref>.</t>
<t hangText="IPv4-only domain:">as defined in <xref
target="I-D.ietf-behave-v6v4-framework"></xref>, a routing domain in
which applications can only use IPv4 to communicate, whether due to
host limitations, application limitations, or network
limitations.</t>
<t hangText="IPv6-only domain:">as defined in <xref
target="I-D.ietf-behave-v6v4-framework"></xref>, a routing domain in
which applications can only use IPv6 to communicate, whether due to
host limitations, application limitations, or network
limitations.</t>
<t hangText="NAT-PT:">refers to a specific, old design of a Network
Address Translator - Protocol Translator defined in <xref
target="RFC4966"></xref>.</t>
</list></t>
</section>
<section anchor="principles" title="Principles">
<t>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.</t>
<t>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 <xref
target="recommendations"></xref>, 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.</t>
<section title="Goals">
<t>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, 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.</t>
<!-- Temporary
goals in support of this include interoperation between
applications using IPv4 and IPv6, both in the sense of an
IPv4-hosted application communicating with an IPv6-hosted
counterpart and applications hosted on IPv4 or IPv6 communicating
across networks of the other type. !-->
<!-- <t>The primary goal is to enable IPv6 for communications. For the
vast majority of networks there are two secondary goals, enabling
co-existence between IPv4 and IPv6, and to allow the IPv4 network
continue operate under address scarcity. However, we should not
make it desirable to stay on IPv4 indefinitely. As a result, good
deployment models both reduce pain from IPv4 address shortage and
have incentives for starting to move communications to IPv6.</t> !-->
<t>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.</t>
<t>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.</t>
<t>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.</t>
</section>
<section title="Choosing a Deployment Model">
<t>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.</t>
<t>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.</t>
<t>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.</t>
<t>Looking back on the deployment of Internet technology, some of the
factors that have been important for success include <xref
target="RFC5218"></xref><xref target="baker.shanghai"></xref> <list
style="symbols">
<t>The ability to offer a valuable service. In the case of the
Internet, connectivity has been this service.</t>
<t>The ability to deploy the solution in an incremental
fashion.</t>
<t>Simplicity. This has been a key factor in making it possible
for all types of devices to support the Internet protocols.</t>
<t>Openly available implementations. These make it easier for
researchers, start-ups and others to build on or improve existing
components.</t>
<t>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.</t>
<t>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.</t>
</list></t>
<t>These factors are also important when choosing IPv6 migration
tools.</t>
<t>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.</t>
<t>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.</t>
</section>
</section>
<section anchor="recommendations" title="Guidelines for IPv6 Deployment">
<t>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 on translation, at the application or
the network layer.</t>
<t>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) <xref target="RFC2766"></xref> suffers from a
number of drawbacks arising from, for example, its attempt to capture
DNS queries on path <xref target="RFC4966"></xref>. Another example
regarding the preference to employ tunneling instead of double
translation will be discussed later in this document.</t>
<section anchor="dualstack" title="Native Dual Stack">
<t>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.</t>
<t>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 <xref target="RFC4213"></xref> and address
selection <xref target="RFC3484"></xref>. Similarly, while there are
some remaining challenges, this model is also preferred by many
service providers and network managers <xref
target="I-D.ietf-v6ops-isp-scenarios"></xref> <xref
target="I-D.arkko-ipv6-only-experience"></xref>.</t>
<t>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 <xref
target="networkworld.youtube"></xref>.</t>
<t>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 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.</t>
<t>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.</t>
<t>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 <xref
target="RFC2993"></xref> and <xref
target="I-D.ietf-intarea-shared-addressing-issues"></xref>. As a
result, it allows the construction of IPv6-based applications that
offer more functionality.</t>
<t>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 <xref target="I-D.miles-behave-l2nat"></xref> <xref
target="I-D.arkko-dual-stack-extra-lite"></xref>. Other networks may
require a combination of IPv4/IPv4 NAT enhancements and tunneling.
These scenarios are discussed further in <xref
target="dslite"></xref>.</t>
</section>
<section title="Crossing IPv4 Islands">
<t>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.</t>
<t>There are several types tunneling mechanisms, including manually
configured IPv6-over-IPv4 tunnels <xref target="RFC4213"></xref>, 6to4
<xref target="RFC3056"></xref>, automatic host-based tunnels <xref
target="RFC4380"></xref>, tunnel brokers <xref
target="RFC3053"></xref>, and the use of Virtual Private Network (VPN)
or mobility tunnels to carry both IPv4 and IPv6 <xref
target="RFC4301"></xref> <xref target="RFC5454"></xref> <xref
target="RFC5555"></xref>. More advanced solutions provide a mesh-based
framework of tunnels <xref target="RFC5565"></xref>.</t>
<t>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.</t>
<t>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.</t>
<t>The <xref target="RFC5969">IPv6 Rapid Deployment</xref> 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.</t>
</section>
<section anchor="dslite" title="IPv6-Only Core Network">
<t>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: <list
style="symbols">
<t>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.</t>
<t>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.</t>
<t>It may be simpler for the service provider to employ a
single-version network.</t>
</list></t>
<t>The recommended tool for this model is Dual Stack Lite <xref
target="I-D.ietf-softwire-dual-stack-lite"></xref>. 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.</t>
</section>
<section title="IPv6-only Deployment">
<t>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: <list
style="symbols">
<t>There is a fact or requirement that there be an IPv4-only
domain and an IPv6-only domain.</t>
<t>There is a requirement that hosts in the IPv4-only domain
access servers or peers in the IPv6-only domain and vice
versa.</t>
</list></t>
<t>This is enhanced when the network operator is able to select user
devices and applications, enabling him to ensure that any
communication exchange is in fact predictable and translatable. In
such a case, full interoperability can be expected.</t>
<t>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.</t>
<t>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.</t>
<t>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 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.</t>
<t>The other approach is network layer IPv4/IPv6 translation as
described in <xref target="I-D.ietf-behave-v6v4-framework">IPv4/IPv6
Translation</xref> <xref target="I-D.ietf-behave-v6v4-xlate"></xref>
<xref target="I-D.ietf-behave-v6v4-xlate-stateful"></xref> <xref
target="I-D.ietf-behave-address-format"></xref> <xref
target="I-D.ietf-behave-dns64"></xref> <xref
target="I-D.ietf-behave-ftp64"></xref>. 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:
<list style="symbols">
<t>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</t>
<t>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.</t>
</list></t>
<t>The two likely are also used together. In this scenario, network
layer translation provides for straightforward services for most
applications crossing the IPv4-only/IPv6-only boundary. Communications
involving IPv4 referral, in particular 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. Current measurement for HTTP on the
public internet show that literals break 0.2% of the world wide web.
For these applications, the DNS64 implementation or host configuration
directs sessions to typical gateways - SMTP MTAs, proxies, or
whatever. The server must do something such servers usually do not do,
which is modify addresses as appropriate. However, they then forward
the traffic using typical proxy functionality, preserving end to end
behavior between themselves and the peers in the exchange.</t>
</section>
</section>
<!--
<section anchor="catalog" title="Applicability of Migration Tools">
<t>...</t>
<section title="Dual Stack">
- dual-stack
</section>
<section title="Tunneling">
- tunneling
- ds-lite
</section>
<section title="Protocol Translation">
- the theory of ipv6 deployment: individual adoption is possible but multiple stakeholders are required for actual use
- protocol translation
</section>
</section>
!-->
<section anchor="reading" title="Further Reading">
<t>Various aspects of IPv6 deployment have been covered in several
documents. Of particular interest may be the basic dual stack definition
<xref target="RFC4213"></xref>, application aspects <xref
target="RFC4038"></xref>, deployment in Internet Service Provider
Networks <xref target="RFC4029"></xref> <xref
target="I-D.ietf-v6ops-isp-scenarios"></xref>, deployment in enterprise
networks <xref target="RFC4057"></xref> <xref target="RFC4852"></xref>,
IPv6-only deployment <xref
target="I-D.arkko-ipv6-only-experience"></xref>, and considerations in
specific access networks such as cellular networks <xref
target="RFC3314"></xref> <xref target="RFC3574"></xref> <xref
target="RFC4215"></xref> or 802.16 networks <xref
target="RFC5181"></xref>.</t>
<t>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.</t>
</section>
<section anchor="seccons" title="Security Considerations">
<t>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.</t>
<t>This document has no impact on the security properties of specific
IPv6 transition tools.</t>
</section>
<section anchor="ianacons" title="IANA Considerations">
<t>This document has no IANA implications.</t>
</section>
</middle>
<back>
<references title="Normative References">
<?rfc include="reference.RFC.2663.xml"?>
<?rfc include="reference.RFC.3484.xml"?>
<?rfc include="reference.RFC.4213.xml"?>
<?rfc include="reference.RFC.4301.xml"?>
<?rfc include="reference.RFC.4380.xml"?>
<?rfc include="reference.RFC.5454.xml"?>
<?rfc include="reference.RFC.5555.xml"?>
<?rfc include="reference.RFC.5565.xml"?>
</references>
<references title="Informative References">
<?rfc include="reference.I-D.arkko-dual-stack-extra-lite.xml"?>
<?rfc include="reference.I-D.arkko-ipv6-only-experience.xml"?>
<?rfc include="reference.I-D.arkko-townsley-coexistence.xml"?>
<?rfc include="reference.I-D.ietf-behave-v6v4-framework.xml"?>
<?rfc include="reference.I-D.ietf-behave-address-format.xml"?>
<?rfc include="reference.I-D.ietf-behave-v6v4-xlate.xml"?>
<?rfc include="reference.I-D.ietf-behave-v6v4-xlate-stateful.xml"?>
<?rfc include="reference.I-D.ietf-behave-dns64.xml"?>
<?rfc include="reference.I-D.ietf-behave-ftp64.xml"?>
<?rfc include="reference.I-D.ietf-intarea-shared-addressing-issues" ?>
<?rfc include="reference.I-D.ietf-softwire-dual-stack-lite.xml"?>
<?rfc include="reference.I-D.ietf-v6ops-isp-scenarios.xml"?>
<?rfc include="reference.I-D.miles-behave-l2nat.xml"?>
<?rfc include="reference.RFC.2766.xml"?>
<?rfc include="reference.RFC.2993.xml" ?>
<?rfc include="reference.RFC.3053.xml"?>
<?rfc include="reference.RFC.3056.xml"?>
<?rfc include="reference.RFC.3314.xml"?>
<?rfc include="reference.RFC.3574.xml"?>
<?rfc include="reference.RFC.4029.xml"?>
<?rfc include="reference.RFC.4038.xml"?>
<?rfc include="reference.RFC.4057.xml"?>
<?rfc include="reference.RFC.4215.xml"?>
<?rfc include="reference.RFC.4852.xml"?>
<?rfc include="reference.RFC.4966.xml"?>
<?rfc include="reference.RFC.5181.xml"?>
<?rfc include="reference.RFC.5211" ?>
<?rfc include="reference.RFC.5218.xml"?>
<?rfc include="reference.RFC.5969.xml" ?>
<?rfc include="reference.baker.shanghai.xml"?>
<?rfc include="reference.networkworld.youtube.xml"?>
</references>
<section anchor="ack" title="Acknowledgments">
<t>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 <xref target="baker.shanghai"></xref>. In addition,
the authors would like to thank Mark Townsley with whom the Jari Arkko
wrote an earlier document <xref
target="I-D.arkko-townsley-coexistence"></xref>. 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.</t>
</section>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-23 08:34:41 |