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

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

<rfc ipr="trust200902"
     docName="draft-arkko-ipv6-transition-guidelines-01"
     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>

    <author fullname="Fred Baker" initials="F.J." surname="Baker">
      <organization>Cisco Systems</organization>
      <address>
        <postal>
          <street/>
          <city>Santa Barbara</city>
          <code>93117</code>
          <region>California</region>
          <country>USA</country>
        </postal>
        <email>fred@cisco.com</email>
      </address>
    </author>

<date month="February" 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 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, 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.</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"/> 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>In this document, the following terms are used. "NAT44" 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"/>.</t>

   <t>"Dual Stack" refers to a technique for providing complete support
   for both Internet protocols -- IPv4 and IPv6 -- in hosts and
   routers <xref target="RFC4213"/>.</t>

   <t>"Dual Stack Lite" refers to a technique that employs tunneling
   and NAT44 to provide IPv4 connectivity over IPv6 networks
   <xref target="I-D.ietf-softwire-dual-stack-lite"/>.</t>

   <t>"NAT-PT" refers to a specific, old design of a Network Address
   Translator - Protocol Translator defined in
   <xref target="RFC2766"/>.</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"/>, 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. 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 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 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 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 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.</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="baker.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,
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.</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"/>
suffers from a number of drawbacks arising from, for example, its
attempt to capture DNS queries on path <xref target="RFC4966"/>.
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"/> 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 mis-configurations. 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
Virtual Private Network (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 is Dual Stack Lite
<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. 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="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 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> 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 the absence of stacks in the hosts or routing in 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 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.</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 target="I-D.ietf-behave-v6v4-xlate-stateful"/>
<xref target="I-D.ietf-behave-address-format"/>
<xref target="I-D.ietf-behave-dns64"/>
<xref target="I-D.ietf-behave-ftp64"/>.  IPv4/IPv6 translation at the
network layer is similar in its advantages and pitfalls to IPv4/IPv4
translation. It is, however, stateless for interfaces in the IPv6-only
network with IPv4-mapped addresses, and allows IPv4 hosts to directly
initiate communication with those interfaces. </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-address-format.xml"?>
      <?rfc include="reference.I-D.ietf-behave-dns64.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-ftp64.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.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"/>. 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"/>. 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>