Guidelines for Using IPv6 Transition Mechanisms during IPv6 Deployment
RFC 6180

RFC 6180               IPv6 Transition Guidelines               May 2011

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

   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 of
   IPv6-IPv4 translation (NAT-PT) [RFC2766] suffers from a number of
   drawbacks arising from, for example, its attempt to capture DNS
   queries on path [RFC4966].  Another example regarding the preference
   to employ tunneling instead of double translation will be discussed
   later in this document.

4.1.  Native Dual Stack

   The simplest deployment model is dual stack: one turns on IPv6
   throughout one's existing IPv4 network and allows applications using
   the two protocols to operate as ships in the night.  This model is
   applicable to most networks -- home, enterprise, service provider, or
   content provider network.

   The purpose of this model is to support any type of device and
   communication, and to make it an end-to-end choice which IP version
   is used between the peers.  There are minimal assumptions about the
   capabilities and configuration of hosts in these networks.  Native
   connectivity avoids problems associated with the configuration of
   tunnels and Maximum Transmission Unit (MTU) settings.  As a result,
   these networks are robust and reliable.  Accordingly, this is the
   recommended deployment model for most networks and is supported by
   IETF standards such as dual stack [RFC4213] and address selection
   [RFC3484].  Similarly, while there are some remaining challenges,
   this model is also preferred by many service providers and network
   managers [RFC6036] [IPv6-only-experience].

   The challenges associated with this model are twofold.  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

Arkko & Baker                 Informational                     [Page 8]
RFC 6180               IPv6 Transition Guidelines               May 2011

   situation where IPv6 has been turned on in a network, but there is
   little actual traffic.  One direct way to affect this situation is to
   ensure that major destinations of traffic are prepared to receive
   IPv6 traffic.  Current Internet traffic is highly concentrated on
   selected content provider networks, and making a change in even a
   small number of these networks can have significant effects.  This
   was recently observed when YouTube started supporting IPv6
   [networkworld.youtube].  There are scenarios where these means are
   insufficient.  The following sections discuss deployment models that
   enable parts of the network to deploy IPv6 faster than other parts.

   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 to resolve names to
   IPv6 addresses.  Such agreements are similar to peering agreements
   and have been seen as necessary by many content providers.  These
   "whitelisting" practices have some downsides as well, however.  In
   particular, they create a dependency on an external party for moving
   traffic to IPv6.  Nevertheless, there are many types of traffic in
   the Internet, and only some of it requires such careful coordination.
   Popular peer-to-peer systems can automatically and reliably employ
   IPv6 connectivity where it is available, for instance.

   Despite these challenges, the native dual-stack connectivity model
   remains the recommended approach.  It is responsible for a large part
   of the progress on worldwide IPv6 deployment to date.  The largest
   IPv6 networks -- notably, national research and education networks,
   Internet II, RENATER, and others -- employ this approach.

   The original intent of dual stack was to deploy both IP versions
   alongside each other before IPv4 addresses were to run out.  As we
   know, this never happened and deployment now has to take place with
   limited IPv4 addresses.  Employing dual stack together with a
   traditional IPv4 address translator (IPv4/IPv4 NAT) is a very common
   configuration.  If the address translator is acceptable for the
   network from a pure IPv4 perspective, this model can be recommended
   from a dual-stack perspective as well.  The advantage of IPv6 in this
   model is that it allows direct addressing of specific nodes in the
   network, creating a contrast to the translated IPv4 service, as noted
   in [RFC2993] and [shared-addressing-issues].  As a result, it allows
   the construction of IPv6-based applications that offer more
   functionality.

Arkko & Baker                 Informational                     [Page 9]
RFC 6180               IPv6 Transition Guidelines               May 2011

   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 [L2-NAT] [DS-extra-lite].  Other networks may require a
   combination of IPv4/IPv4 NAT 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 be established using tunnels.  Tunneling introduces some
   additional complexity.  It also increases the probability that the
   Path MTU algorithm will be used, as many implementations derive their
   default MTU from the Ethernet frame size; ICMP filtering interacts
   poorly with the Path MTU algorithm in [RFC1981].  However, its
   benefit is that it decouples addressing inside and outside the
   tunnel, making it easy to deploy IPv6 without having to modify
   routers along the path.  Tunneling should be used when native
   connectivity cannot be established, such as when crossing another
   administrative domain or a router that cannot be easily reconfigured.

   There are several types of tunneling mechanisms, including manually
   configured IPv6-over-IPv4 tunnels [RFC4213], 6to4 [RFC3056],
   automatic host-based tunnels [RFC4380], tunnel brokers [RFC3053],
   running IPv6 over MPLS with IPv6 Provider Edge Routers (6PE)
   [RFC4798], the use of Virtual Private Networks (VPNs) or mobility
   tunnels to carry both IPv4 and IPv6 [RFC4301] [RFC5454] [RFC5555]
   [RFC5844], and many others.  More advanced solutions provide a mesh-
   based framework of tunnels [RFC5565].

   On a managed network, there are no major challenges with tunneling
   beyond the possible configuration and MTU problems.  Tunneling is
   very widely deployed both for IPv6 connectivity and other reasons,
   and is 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.

Arkko & Baker                 Informational                    [Page 10]
RFC 6180               IPv6 Transition Guidelines               May 2011

   On an unmanaged network, however, there have been a number of
   problems.  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.  In
   turn, this has lead to the content providers needing to serve IPv6
   results for DNS queries only for trusted peers with known high-
   quality connectivity.

   The IPv6 Rapid Deployment (6RD) [RFC5969] approach is a newer version
   of the 6to4 tunneling solution without the above drawbacks.  It
   offers systematic IPv6 tunneling over IPv4 across an ISP,
   correspondence between IPv4 and IPv6 routing, and can be deployed
   within an ISP without the need to rely on other parties.

4.3.  IPv6-Only Core Network

   An emerging deployment model uses IPv6 as the dominant protocol at a
   service provider network, and tunnels IPv4 through this network in a
   manner converse to the one described in the previous section.  There
   are several motivations for choosing this deployment model:

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

   o  IPv4 address sharing among subscribers may involve new address
      translation nodes within the service provider's network.  IPv6 can
      be used to reach these nodes.  Normal IPv4 routing is insufficient
      for this purpose, as the same addresses would be used in several
      parts of the network.

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

   The recommended tool for this model is Dual Stack Lite [DS-lite].
   Dual Stack Lite both provides relief for IPv4 address shortage and
   makes forward progress on IPv6 deployment, by moving service provider
   networks and IPv4 traffic over IPv6.  Given the IPv6 connectivity
   that Dual Stack Lite runs over, it becomes easy to provide IPv6
   connectivity all the way to the end users as well.

4.4.  IPv6-Only Deployment

   Our final deployment model breaks the requirement that all parties
   must upgrade to IPv6 before any end-to-end communications use IPv6.
   This model makes sense when the following conditions are met:

Arkko & Baker                 Informational                    [Page 11]
RFC 6180               IPv6 Transition Guidelines               May 2011

   o  There is a fact or requirement that there be an IPv4-only domain
      and an IPv6-only domain.

   o  There is a requirement that hosts in the IPv4-only domain access
      servers or peers in the IPv6-only domain and vice versa.

   This deployment model would fit well, for instance, a corporate or
   mobile network that offers IPv6-only networking but where users still
   wish to access content from the IPv4 Internet.

   When we say "IPv4-only" or "IPv6-only", we mean that the applications
   can communicate only using IPv4 or IPv6; this might be due to lack of
   capabilities in the applications, host stacks, or the network; the
   effect is the same.  The reason to switch to an IPv6-only network may
   be a desire to test such a configuration or to simplify the network.
   It is expected that as IPv6 deployment progresses, the second reason
   will become more prevalent.  One particular reason for considering an
   IPv6-only domain is the effect of overlapping private address space
   to applications.  This is important in networks that have exhausted
   both public and private IPv4 address space and where arranging an
   IPv6-only network is easier than dealing with the overlapping address
   space in applications.

   Note that the existence of an IPv6-only domain requires that all
   devices are indeed IPv6 capable.  In today's mixed networking
   environments with legacy devices, this cannot 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
   can ensure that the latest device versions are in use.  Some networks
   can also be engineered to support different services over an
   underlying network and, as such, can support IPv6-only networking
   more easily.  For instance, a cellular network may support IPv4-only
   connectivity for the installed base of existing devices and IPv6-only
   connectivity for incremental growth with newer IPv6-capable handsets.
   Similarly, a broadband ISP may support dual-stack connectivity for
   customers that require both IPv4 and IPv6, and offer IPv6-only and
   NAT64 service for others.  In the case of 3GPP and DOCSIS 3.0 access
   networks, the underlying access network architecture allows the
   flexibility to run different services in parallel to suit the various
   needs of the customer and the network operator.

   It is also necessary for the network operator to have some level of
   understanding of what applications are used in the network, enabling
   him to ensure that any communication exchange is in fact predictable,
   capable of using IPv6, and translatable.  In such a case, full
   interoperability can be expected.  This has been demonstrated with

Arkko & Baker                 Informational                    [Page 12]
RFC 6180               IPv6 Transition Guidelines               May 2011

   some mobile devices, for instance.  Note that the requirements on
   applications are similar to those in networks employing IPv4 NAT
   technology.

   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 SIP (Session Initiation Protocol) and media stream
   back-to-back user agent 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 from the gateway to the communicating peer.
   For obvious reasons, this solution is preferable to the
   implementation of Application Layer Gateways in network-layer
   translators.

   The other approach is network-layer IPv4/IPv6 translation as
   described in "IPv4/IPv6 Translation" [RFC6144] [RFC6145] [RFC6146]
   [RFC6052] [RFC6147] [FTP64].  IPv4/IPv6 translation at the network
   layer is similar to IPv4/IPv4 translation in its advantages and
   disadvantages.  It allows a network to provide two types of services
   to IPv6-only hosts:

   o  a relatively small set of systems may be configured with IPv4-
      mapped addresses, enabling stateless interoperation between IPv4-
      only and IPv6-only domains, each of which can use the other as
      peers or servers, and

   o  a larger set of systems with global IPv6 addresses, which can
      access IPv4 servers using stateful translation but which are
      inaccessible as peers or servers from the IPv4-only domain.

   The former service is used today in some university networks, and the
   latter in some corporate and mobile networks.  The stateless service
   is naturally better suited for servers, and the stateful service for
   large numbers of client devices.  The latter case occurs typically in
   a public network access setting.  The two services can of course also
   be used together.  In this scenario, network-layer translation
   provides for straightforward services for most applications crossing
   the IPv4-only/IPv6-only boundary.

   One challenge in this model is that as long as IPv4 addresses are
   still shared, issues similar to those caused by IPv4 NATs will still
   appear [shared-addressing-issues].  Another challenge relates to
   communications involving IPv4 referrals.  IPv4-literals within
   certain protocols and formats, such as 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.  Measurements on the
   public Internet show that literals appear in a tiny but measurable

Arkko & Baker                 Informational                    [Page 13]
RFC 6180               IPv6 Transition Guidelines               May 2011

   part of web pages [IPv6-only-experience], though whether this poses a
   practical problem is debatable.  If this poses a particular problem
   for the types of applications in use, proxy configurations could be
   modified to use a proxy for the traffic in question, hosts could be
   modified to understand how they can map IPv4-literals to IPv6
   addresses, or native dual stack could be employed instead.

5.  Conclusions

   The fundamental recommendation is to turn on IPv6.  Section 4
   described four deployment models to do that, presented in rough order
   of occurrence in the world at the time of this writing.  The first
   two models are the most widely deployed today.  All four models are
   recommended by the IETF, though, again, the first two models should
   take priority where they are applicable.

   As noted in Section 1, variations occur in details, and network
   managers are ultimately in charge of choosing the best solution for
   their own case.  Benefits and challenges discussed in the previous
   sections should be considered when weighing deployment alternatives.
   The transition mechanisms that operators have deployed have been a
   mixed blessing; native dual-stack deployments are not used to their
   full extent if peers have not upgraded, tunnel mechanisms that don't
   follow the routing of the underlying network have been problematic,
   and translation has its faults as well.  Nevertheless, operators have
   successfully deployed very large networks with these models.

   Some additional considerations are discussed below.

   o  There is a tradeoff between ability to connect as many different
      types of devices as possible and the ability to move forward with
      deployment as independently as possible.  As an example, native
      dual stack ensures the best connectivity but requires updates in
      peer systems before actual traffic flows over IPv6.  Conversely,
      IPv6-only networks are very sensitive to what kind of devices they
      can support, but can be deployed without any expectation of
      updates on peer systems.

   o  "Greenfield" networks and networks with existing IPv4 devices and
      users need to be treated differently.  In the latter case, turning
      on IPv6 in addition to IPv4 seems the rational choice.  In the
      former case, an IPv6-only model may make sense.

   o  The right deployment model choices also vary as time goes by.  For
      instance, a tunneling solution that makes sense today may become a
      native dual-stack solution as the network and devices in the
      network evolve.  Or, an IPv6-only network becomes feasible when a
      sufficient fraction of client devices become IPv6-enabled.

Arkko & Baker                 Informational                    [Page 14]
RFC 6180               IPv6 Transition Guidelines               May 2011

   No matter which deployment model is chosen, many of the important
   implications of IPv6 deployment are elsewhere within the network:
   IPv6 needs to be taken into account in network management systems and
   operations, address assignments, service agreements, firewalls,
   intrusion detection systems, and so on.

6.  Further Reading

   Various aspects of IPv6 deployment have been covered in several
   documents.  Of particular interest may be the basic dual-stack
   definition [RFC4213], application aspects [RFC4038], deployment in
   Internet service provider networks [RFC4029] [RFC6036], deployment in
   enterprise networks [RFC4057] [RFC4852], IPv6-only deployment
   [IPv6-only-experience], and considerations in specific access
   networks such as cellular networks [RFC3314] [RFC3574] [RFC4215]
   [v6-in-mobile] or 802.16 networks [RFC5181].

   This document provides general guidance on IPv6 deployment models
   that have been found suitable for most organizations.  The purpose of
   this document is not to enumerate all special circumstances that may
   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.

7.  Security Considerations

   While there are detailed differences between the security properties
   and vulnerabilities between IPv4 and IPv6, in general they provide a
   very similar level of security and are subject to the same threats.
   With both protocols, specific security issues are more likely to be
   found at the practical level than in the specifications.  The
   practical issues include, for instance, bugs or available security
   mechanisms on a given product.  When deploying IPv6, it is important
   to ensure that the necessary security capabilities exist on the
   network components even when dealing with IPv6 traffic.  For
   instance, firewall capabilities have often been a challenge in IPv6
   deployments.

   This document has no impact on the security properties of specific
   IPv6 transition tools.  The security considerations relating to the
   transition tools are described in the relevant documents, for
   instance, [RFC4213], [RFC6147], [DS-lite], and [RFC6169].

Arkko & Baker                 Informational                    [Page 15]
RFC 6180               IPv6 Transition Guidelines               May 2011

8.  References

8.1.  Normative References

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

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

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

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

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

   [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

   [Baker.Shanghai]
              Baker, F., "The view from IPv6 Operations WG (and we'll
              talk about translation)", Presentation in the China Mobile
              Workshop on IPv6 Deployment in Cellular Networks,
              Shanghai, China, November 2009, <http://ipv6ws.arkko.com/
              presentations/3GPP-IETF-V6OPS-Discussion.pdf>.

   [DS-extra-lite]
              Arkko, J., Eggert, L., and M. Townsley, "Scalable
              Operation of Address Translators with Per-Interface
              Bindings", Work in Progress, February 2011.

   [DS-lite]  Durand, A., Droms, R., Woodyatt, J., and Y. Lee, "Dual-
              Stack Lite Broadband Deployments Following IPv4
              Exhaustion", Work in Progress, August 2010.

Arkko & Baker                 Informational                    [Page 16]
RFC 6180               IPv6 Transition Guidelines               May 2011

   [FTP64]    Beijnum, I., "An FTP ALG for IPv6-to-IPv4 translation",
              Work in Progress, March 2011.

   [IPv6-only-experience]
              Arkko, J. and A. Keranen, "Experiences from an IPv6-Only
              Network", Work in Progress, April 2011.

   [L2-NAT]   Miles, D. and M. Townsley, "Layer2-Aware NAT", Work
              in Progress, March 2009.

   [RFC1981]  McCann, J., Deering, S., and J. Mogul, "Path MTU Discovery
              for IP version 6", RFC 1981, August 1996.

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

   [RFC2993]  Hain, T., "Architectural Implications of NAT", RFC 2993,
              November 2000.

   [RFC3053]  Durand, A., Fasano, P., Guardini, I., and D. Lento, "IPv6
              Tunnel Broker", RFC 3053, January 2001.

   [RFC3056]  Carpenter, B. and K. Moore, "Connection of IPv6 Domains
              via IPv4 Clouds", RFC 3056, February 2001.

   [RFC3314]  Wasserman, M., "Recommendations for IPv6 in Third
              Generation Partnership Project (3GPP) Standards",
              RFC 3314, September 2002.

   [RFC3574]  Soininen, J., "Transition Scenarios for 3GPP Networks",
              RFC 3574, August 2003.

   [RFC4029]  Lind, M., Ksinant, V., Park, S., Baudot, A., and P.
              Savola, "Scenarios and Analysis for Introducing IPv6 into
              ISP Networks", RFC 4029, March 2005.

   [RFC4038]  Shin, M-K., Hong, Y-G., Hagino, J., Savola, P., and E.
              Castro, "Application Aspects of IPv6 Transition",
              RFC 4038, March 2005.

   [RFC4057]  Bound, J., "IPv6 Enterprise Network Scenarios", RFC 4057,
              June 2005.

   [RFC4215]  Wiljakka, J., "Analysis on IPv6 Transition in Third
              Generation Partnership Project (3GPP) Networks", RFC 4215,
              October 2005.

Arkko & Baker                 Informational                    [Page 17]
RFC 6180               IPv6 Transition Guidelines               May 2011

   [RFC4798]  De Clercq, J., Ooms, D., Prevost, S., and F. Le Faucheur,
              "Connecting IPv6 Islands over IPv4 MPLS Using IPv6
              Provider Edge Routers (6PE)", RFC 4798, February 2007.

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

   [RFC5211]  Curran, J., "An Internet Transition Plan", RFC 5211,
              July 2008.

   [RFC5218]  Thaler, D. and B. Aboba, "What Makes For a Successful
              Protocol?", RFC 5218, July 2008.

   [RFC5844]  Wakikawa, R. and S. Gundavelli, "IPv4 Support for Proxy
              Mobile IPv6", RFC 5844, May 2010.

   [RFC5969]  Townsley, W. and O. Troan, "IPv6 Rapid Deployment on IPv4
              Infrastructures (6rd) -- Protocol Specification",
              RFC 5969, August 2010.

   [RFC6036]  Carpenter, B. and S. Jiang, "Emerging Service Provider
              Scenarios for IPv6 Deployment", RFC 6036, October 2010.

   [RFC6052]  Bao, C., Huitema, C., Bagnulo, M., Boucadair, M., and X.
              Li, "IPv6 Addressing of IPv4/IPv6 Translators", RFC 6052,
              October 2010.

   [RFC6127]  Arkko, J. and M. Townsley, "IPv4 Run-Out and IPv4-IPv6
              Co-Existence Scenarios", RFC 6127, May 2011.

   [RFC6144]  Baker, F., Li, X., Bao, C., and K. Yin, "Framework for
              IPv4/IPv6 Translation", RFC 6144, April 2011.

   [RFC6145]  Li, X., Bao, C., and F. Baker, "IP/ICMP Translation
              Algorithm", RFC 6145, April 2011.

   [RFC6146]  Bagnulo, M., Matthews, P., and I. Beijnum, "Stateful
              NAT64: Network Address and Protocol Translation from IPv6
              Clients to IPv4 Servers", RFC 6146, April 2011.

Arkko & Baker                 Informational                    [Page 18]
RFC 6180               IPv6 Transition Guidelines               May 2011

   [RFC6147]  Bagnulo, M., Sullivan, A., Matthews, P., and I. Beijnum,
              "DNS64: DNS extensions for Network Address Translation
              from IPv6 Clients to IPv4 Servers", RFC 6147, April 2011.

   [RFC6169]  Krishnan, S., Thaler, D., and J. Hoagland, "Security
              Concerns with IP Tunneling", RFC 6169, April 2011.

   [networkworld.youtube]
              Marsan, C., "YouTube support of IPv6 seen in dramatic
              traffic spike", Network World article, February 2010,
              <http://www.networkworld.com/news/2010/
              020110-youtube-ipv6.html>.

   [shared-addressing-issues]
              Ford, M., Boucadair, M., Durand, A., Levis, P., and P.
              Roberts, "Issues with IP Address Sharing", Work in
              Progress, March 2011.

   [v6-in-mobile]
              Koodli, R., "Mobile Networks Considerations for IPv6
              Deployment", Work in Progress, May 2011.

Arkko & Baker                 Informational                    [Page 19]
RFC 6180               IPv6 Transition Guidelines               May 2011

Appendix A.  Acknowledgments

   The authors would like to thank the many people who have engaged in
   discussions around this topic over the years.  Some of the material
   in this document comes originally from Fred Baker's presentation in a
   workshop in Shanghai [Baker.Shanghai].  In addition, the authors
   would like to thank Mark Townsley with whom Jari Arkko wrote an
   earlier document [RFC6127].  Brian Carpenter submitted an in-depth
   review and provided significant new text.  Cameron Byrne provided
   significant feedback on the key recommendations in this memo.  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 Suresh Krishnan,
   Fredrik Garneij, Mohamed Boucadair, Remi Despres, Kurtis Lindqvist,
   Shawn Emery, Dan Romascanu, Tim Polk, Ralph Droms, Sean Turner, Tina
   Tsou, Nevil Brownlee, and Joel Jaeggli, who have commented on early
   versions of this memo.

Authors' Addresses

   Jari Arkko
   Ericsson
   Jorvas  02420
   Finland

   EMail: jari.arkko@piuha.net

   Fred Baker
   Cisco Systems
   Santa Barbara, California  93117
   USA

   EMail: fred@cisco.com

Arkko & Baker                 Informational                    [Page 20]