One document matched: draft-arkko-ipv6-transition-guidelines-00.xml

<?xml version="1.0" encoding="iso-8859-1" ?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">

<rfc ipr="trust200902"
     docName="draft-arkko-ipv6-transition-guidelines-00"
     category="std">

<?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</title>

<author initials="J" surname="Arkko" fullname="Jari Arkko">
<organization>Ericsson</organization>
<address>
<postal>
<street/>
<city>Jorvas</city> <code>02420</code>
<country>Finland</country>
</postal>
<email>jari.arkko@piuha.net</email>
</address>
</author>

<date month="February" year="2010" />

<keyword>IPv6</keyword>

<abstract>

<t>IPv6 is essential as the Internet continues to grow beyond its
originally envisioned design limits. 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 many
common situations.</t>

</abstract>

</front>
<middle>

<section anchor="intro" title="Introduction">

  <t>IPv6 is essential as the Internet continues to grow beyond its
  originally envisioned design limits. 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 writing this, the
  IANA "free pool" contained only 24 unallocated unicast IPv4 /8
  prefixes. This is sufficient only for the next 2-3 years at best.</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: new requirements simply have to be
  taken into account in the 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 large number of possible options and ongoing
  development for more, network managers are understandably confused
  about what the recommended approach for IPv6 deployment is.</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"/> introduces some terminology,
  <xref target="principles"/> discusses some of the general principles
  behind choosing particular deployment models and tools, and
  <xref target="recommendations"/> goes through the recommended
  deployment models for common situations
  <!-- , and  <xref target="catalog"/> summarizes the applicability of various migration tools. !-->
  </t>

</section>

<section anchor="terms" title='Terminology'>

   <t>"NAT44" in this document means an IPv4-to-IPv4 address
   translator, both "Basic NAT" and "Network Address/Port Translator
   (NAPT)" as defined by <xref target="RFC2663"/>.</t>

</section>

<section anchor="principles" title='Principles'>

   <t>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"/>, 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 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 component
   choices, network management, planning, implementation -- and at the
   time of writing this, reasonably easily achievable. There is no
   particular advantage to avoiding dealing with IPv6 as a part the
   normal network planning cycle. The primary 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
   instance, specialized sensor 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.</t>

   <t>It is expected that after a period of supporting both IPv4 and
   IPv6, IPv4 can eventually be turned off. This happens
   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.</t>

   </section>

   <section title="Choosing a Deployment Model">

   <t>The first requirement is that the model or tool actually allows
   communications to flow. 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 target="fred.shanghai"/></t>

   <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>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. For instance, it is
  generally a bad assumption that large number of devices have
  specific software or configuration.</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 entered. 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.</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,
most simple 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.</t>

<t>Note that there are many other possible deployment models and
existing specifications to support such models. These other models are
by no means 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.</t>

<section title="Native Dual Stack">

<t>In this deployment model there is direct connectivity to both the
IPv4 and IPv6 Internet, and a desire to support both IP versions
within the network. This model is applicable to most networks - be it
a home, enterprise, service provider, or a 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"/> and address selection
<xref target="RFC3484"/>.</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"/>.</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 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
necessary for the time being. 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 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 (NAT44) 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 and allowing 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 NAT44 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 NAT44 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 target="I-D.arkko-dual-stack-extra-lite"/>. Other networks may
require a combination of NAT44 enhancements and tunneling. These scenarios
are discussed further in <xref target="dslite"/>.</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 misconfigurations. It should
only be used when establishing native connectivity is not
possible. Typically, this 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"/>,
automatic host-based tunnels <xref target="RFC4380"/> and the use of
VPN or mobility tunnels to carry both IPv4 and IPv6
<xref target="RFC4301"/> <xref target="RFC5454"/>
<xref target="RFC5555"/>. More advanced solutions provide a mesh-based
framework of tunnels <xref target="RFC5565"/>.</t>

<t>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>

</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 similar to the one described in the previous section. There are
several motivations for choosing this deployment model:</t>

<list style="symbols">

<t>There may not be enough public or private 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>IP 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>The recommended tool for this model, Dual Stack Lite, is in its
final stages of specification in the SOFTWIRE working group
<xref target="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. As a result, providing IPv6 service becames
easy.</t>

</section>

<section title="Unilateral 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 two following three conditions are met:</t>

<list style="symbols">

<t>There is sufficient control of the devices in the network so that
it can be guaranteed they all support IPv6.</t>

<t>The devices within the network need to access the global IPv4 network.</t>

<t>There is a reason to switch to a single IP version network. This 
reason may be a desire to test such an advanced configuration, or
merely the desire to simplify the network. It is expected that as IPv6
deployment progresses, the second reason comes more prevalent.</t>

</list>

<t>There are two types of recommended tools for this model. One type
of a tool is appropriate if all traffic is web-based; a simple web
proxy is then capable of mapping all internal IPv6 traffic to the
appropriate global Internet traffic (either IPv4 or IPv6). Another
type of a tool is more general purpose, and is being progressed in the
BEHAVE working group <xref target="I-D.ietf-behave-v6v4-framework"/>
<xref target="I-D.ietf-behave-v6v4-xlate"/>
<xref target="I-D.ietf-behave-v6v4-xlate-stateful"/>. This tool allows
the translation of IPv6 traffic to IPv4.</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
   RFCs. Of particular interest may be the basic dual stack definition
   <xref target="RFC4213"/>, application aspects
   <xref target="RFC4038"/>, deployment in Internet Service Provider
   Networks <xref target="RFC4029"/>, deployment in enterprise
   networks <xref target="RFC4057"/> <xref target="RFC4852"/>, and
   considerations in specific access networks such as cellular
   networks <xref target="RFC3314"/> <xref target="RFC3574"/>
   <xref target="RFC4215"/> or 802.16 networks
   <xref target="RFC5181"/>.</t>

</section>

<section anchor="seccons" title='Security Considerations'>

   <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.RFC.2766.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.5218.xml"?>
      <?rfc include="reference.I-D.ietf-softwire-dual-stack-lite.xml"?>
      <?rfc include="reference.I-D.ietf-behave-v6v4-framework.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.arkko-townsley-coexistence.xml"?>
      <?rfc include="reference.I-D.miles-behave-l2nat.xml"?>
      <?rfc include="reference.I-D.arkko-dual-stack-extra-lite.xml"?>
      <?rfc include="reference.fred.shanghai.xml"?>
      <?rfc include="reference.networkworld.youtube.xml"?>
</references>

<section anchor="ack" title='Acknowledgments'>

   <t>The author would like to thank the many people who have engaged
   in discussions around this topic over the years. This work is
   particularly in debt to Fred Baker and his November 6th, 2009
   presentation in a workshop in Shanghai
   <xref target="fred.shanghai"/>. In addition, the author would like
   to thank Mark Townsley with whom the author wrote an earlier
   document <xref target="I-D.arkko-townsley-coexistence"/>, and thank
   Dave Thaler, Alain Durand, Randy Bush, and Dan Wing who have always
   provided valuable guidance in this field.
   </t>

</section>

</back>
</rfc>