[Docs] [txt|pdf|xml] [Tracker] [Email] [Nits]

Versions: 00 01 02 03 04 05 06 07 08 09 10 11 12 13 14 15 RFC 6180

Network Working Group                                           J. Arkko
Internet-Draft                                                  Ericsson
Intended status: Standards Track                       February 13, 2010
Expires: August 17, 2010

            Guidelines for Using IPv6 Transition Mechanisms


   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.

Status of this Memo

   This Internet-Draft is submitted to IETF in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-

   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."

   The list of current Internet-Drafts can be accessed at

   The list of Internet-Draft Shadow Directories can be accessed at

   This Internet-Draft will expire on August 17, 2010.

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

Arkko                    Expires August 17, 2010                [Page 1]

Internet-Draft         IPv6 Transition Guidelines          February 2010

   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the BSD License.

Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  3
   3.  Principles . . . . . . . . . . . . . . . . . . . . . . . . . .  4
     3.1.  Goals  . . . . . . . . . . . . . . . . . . . . . . . . . .  4
     3.2.  Choosing a Deployment Model  . . . . . . . . . . . . . . .  5
   4.  Guidelines for IPv6 Deployment . . . . . . . . . . . . . . . .  6
     4.1.  Native Dual Stack  . . . . . . . . . . . . . . . . . . . .  7
     4.2.  Crossing IPv4 Islands  . . . . . . . . . . . . . . . . . .  8
     4.3.  IPv6-Only Core Network . . . . . . . . . . . . . . . . . .  9
     4.4.  Unilateral Deployment  . . . . . . . . . . . . . . . . . .  9
   5.  Further Reading  . . . . . . . . . . . . . . . . . . . . . . . 10
   6.  Security Considerations  . . . . . . . . . . . . . . . . . . . 10
   7.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 10
   8.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 11
     8.1.  Normative References . . . . . . . . . . . . . . . . . . . 11
     8.2.  Informative References . . . . . . . . . . . . . . . . . . 11
   Appendix A.  Acknowledgments . . . . . . . . . . . . . . . . . . . 13
   Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 13

Arkko                    Expires August 17, 2010                [Page 2]

Internet-Draft         IPv6 Transition Guidelines          February 2010

1.  Introduction

   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.

   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.

   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.

   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.

   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

2.  Terminology

   "NAT44" in this document means an IPv4-to-IPv4 address translator,
   both "Basic NAT" and "Network Address/Port Translator (NAPT)" as
   defined by [RFC2663].

Arkko                    Expires August 17, 2010                [Page 3]

Internet-Draft         IPv6 Transition Guidelines          February 2010

3.  Principles

   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

3.1.  Goals

   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.

   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.

   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.

   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

Arkko                    Expires August 17, 2010                [Page 4]

Internet-Draft         IPv6 Transition Guidelines          February 2010

   service within its own network, while still allowing its IPv6
   customers to access the rest of the IPv4 Internet.

3.2.  Choosing a Deployment Model

   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

   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, fred.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

   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

Arkko                    Expires August 17, 2010                [Page 5]

Internet-Draft         IPv6 Transition Guidelines          February 2010

      controlled world.

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

   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

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,
   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.

   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.

Arkko                    Expires August 17, 2010                [Page 6]

Internet-Draft         IPv6 Transition Guidelines          February 2010

4.1.  Native Dual Stack

   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

   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

   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

   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

Arkko                    Expires August 17, 2010                [Page 7]

Internet-Draft         IPv6 Transition Guidelines          February 2010


   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.

   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

   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 [I-D.miles-behave-l2nat]
   [I-D.arkko-dual-stack-extra-lite].  Other networks may require a
   combination of NAT44 enhancements and tunneling.  These scenarios are
   discussed further in Section 4.3.

4.2.  Crossing IPv4 Islands

   Native IPv6 connectivity is not always available, but fortunately it
   can 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.

   There are several types tunneling mechanisms, including manually
   configured IPv6-over-IPv4 tunnels [RFC4213], automatic host-based
   tunnels [RFC4380] and the use of VPN or mobility tunnels to carry

Arkko                    Expires August 17, 2010                [Page 8]

Internet-Draft         IPv6 Transition Guidelines          February 2010

   both IPv4 and IPv6 [RFC4301] [RFC5454] [RFC5555].  More advanced
   solutions provide a mesh-based framework of tunnels [RFC5565].

   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.

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

   o  There may not be enough public or private addresses to support
      network management functions in an end-to-end fashion, without
      segmenting the network into small parts with overlapping address

   o  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.

   o  It may be simpler for the service provider to employ a single-
      version network.

   The recommended tool for this model, Dual Stack Lite, is in its final
   stages of specification in the SOFTWIRE working group
   [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.

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 two following three conditions are met:

Arkko                    Expires August 17, 2010                [Page 9]

Internet-Draft         IPv6 Transition Guidelines          February 2010

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

   o  The devices within the network need to access the global IPv4

   o  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

   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 [I-D.ietf-behave-v6v4-framework]
   [I-D.ietf-behave-v6v4-xlate] [I-D.ietf-behave-v6v4-xlate-stateful].
   This tool allows the translation of IPv6 traffic to IPv4.

5.  Further Reading

   Various aspects of IPv6 deployment have been covered in several RFCs.
   Of particular interest may be the basic dual stack definition
   [RFC4213], application aspects [RFC4038], deployment in Internet
   Service Provider Networks [RFC4029], deployment in enterprise
   networks [RFC4057] [RFC4852], and considerations in specific access
   networks such as cellular networks [RFC3314] [RFC3574] [RFC4215] or
   802.16 networks [RFC5181].

6.  Security Considerations

   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

Arkko                    Expires August 17, 2010               [Page 10]

Internet-Draft         IPv6 Transition Guidelines          February 2010

8.1.  Normative References

   [RFC2663]  Srisuresh, P. and M. Holdrege, "IP Network Address
              Translator (NAT) Terminology and Considerations",
              RFC 2663, August 1999.

   [RFC3484]  Draves, R., "Default Address Selection for Internet
              Protocol version 6 (IPv6)", RFC 3484, February 2003.

   [RFC4213]  Nordmark, E. and R. Gilligan, "Basic Transition Mechanisms
              for IPv6 Hosts and Routers", RFC 4213, October 2005.

   [RFC4301]  Kent, S. and K. Seo, "Security Architecture for the
              Internet Protocol", RFC 4301, December 2005.

   [RFC4380]  Huitema, C., "Teredo: Tunneling IPv6 over UDP through
              Network Address Translations (NATs)", RFC 4380,
              February 2006.

   [RFC5454]  Tsirtsis, G., Park, V., and H. Soliman, "Dual-Stack Mobile
              IPv4", RFC 5454, March 2009.

   [RFC5555]  Soliman, H., "Mobile IPv6 Support for Dual Stack Hosts and
              Routers", RFC 5555, June 2009.

   [RFC5565]  Wu, J., Cui, Y., Metz, C., and E. Rosen, "Softwire Mesh
              Framework", RFC 5565, June 2009.

8.2.  Informative References

   [RFC2766]  Tsirtsis, G. and P. Srisuresh, "Network Address
              Translation - Protocol Translation (NAT-PT)", RFC 2766,
              February 2000.

   [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.

Arkko                    Expires August 17, 2010               [Page 11]

Internet-Draft         IPv6 Transition Guidelines          February 2010

   [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.

              Durand, A., Droms, R., Haberman, B., Woodyatt, J., Lee,
              Y., and R. Bush, "Dual-stack lite broadband deployments
              post IPv4 exhaustion",
              draft-ietf-softwire-dual-stack-lite-03 (work in progress),
              February 2010.

              Baker, F., Li, X., Bao, C., and K. Yin, "Framework for
              IPv4/IPv6 Translation",
              draft-ietf-behave-v6v4-framework-06 (work in progress),
              February 2010.

              Li, X., Bao, C., and F. Baker, "IP/ICMP Translation
              Algorithm", draft-ietf-behave-v6v4-xlate-09 (work in
              progress), February 2010.

              Bagnulo, M., Matthews, P., and I. Beijnum, "Stateful
              NAT64: Network Address and Protocol Translation from IPv6
              Clients to IPv4 Servers",
              draft-ietf-behave-v6v4-xlate-stateful-08 (work in
              progress), January 2010.


Arkko                    Expires August 17, 2010               [Page 12]

Internet-Draft         IPv6 Transition Guidelines          February 2010

              Arkko, J. and M. Townsley, "IPv4 Run-Out and IPv4-IPv6 Co-
              Existence Scenarios", draft-arkko-townsley-coexistence-03
              (work in progress), July 2009.

              Miles, D. and M. Townsley, "Layer2-Aware NAT",
              draft-miles-behave-l2nat-00 (work in progress),
              March 2009.

              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.

              Baker, F., "The view from IPv6 Operations WG (and we'll
              talk about translation)", Presentation in the China Mobile
              Workshop on IPv6 Deployment in Cellular Networks,
               Shanghai, China, November 2009.

              Marsan, C., "YouTube support of IPv6 seen in dramatic
              traffic spike", Network World article http://
              February 2010.

Appendix A.  Acknowledgments

   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 [fred.shanghai].  In addition,
   the author would like to thank Mark Townsley with whom the author
   wrote an earlier document [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.

Arkko                    Expires August 17, 2010               [Page 13]

Internet-Draft         IPv6 Transition Guidelines          February 2010

Author's Address

   Jari Arkko
   Jorvas  02420

   Email: jari.arkko@piuha.net

Arkko                    Expires August 17, 2010               [Page 14]

Html markup produced by rfcmarkup 1.129d, available from https://tools.ietf.org/tools/rfcmarkup/