[Docs] [txt|pdf] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits]

Versions: (draft-baker-behave-v4v6-framework) 00 01 02 03 04 05 06 07 08 09 10 RFC 6144

behave                                                     F. Baker, Ed.
Internet-Draft                                             Cisco Systems
Intended status: Standards Track                              X. Li, Ed.
Expires: January 6, 2010                                     C. Bao, Ed.
                                       CERNET Center/Tsinghua University
                                                             K. Yin, Ed.
                                                           Cisco Systems
                                                            July 5, 2009


                  Framework for IPv4/IPv6 Translation
                  draft-ietf-behave-v6v4-framework-00

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

   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
   http://www.ietf.org/ietf/1id-abstracts.txt.

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

   This Internet-Draft will expire on January 6, 2010.

Copyright Notice

   Copyright (c) 2009 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
   Provisions Relating to IETF Documents in effect on the date of
   publication of this document (http://trustee.ietf.org/license-info).
   Please review these documents carefully, as they describe your rights
   and restrictions with respect to this document.





Baker, et al.            Expires January 6, 2010                [Page 1]


Internet-Draft     Framework for IPv4/IPv6 Translation         July 2009


Abstract

   This note describes a framework for IPv4/IPv6 translation.  This is
   in the context of replacing NAT-PT, which was deprecated by RFC 4966,
   and to enable networks to have IPv4 and IPv6 coexist in a somewhat
   rational manner while transitioning to an IPv6 network.


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
     1.1.  Why Translation? . . . . . . . . . . . . . . . . . . . . .  4
     1.2.  Terminology  . . . . . . . . . . . . . . . . . . . . . . .  4
     1.3.  Translation Objectives . . . . . . . . . . . . . . . . . .  7
     1.4.  Transition Plan  . . . . . . . . . . . . . . . . . . . . .  9
   2.  Scenarios of the IPv4/IPv6 Translation . . . . . . . . . . . . 11
     2.1.  Scenario 1: an IPv6 network to the IPv4 Internet . . . . . 12
     2.2.  Scenario 2: the IPv4 Internet to an IPv6 network . . . . . 13
     2.3.  Scenario 3: the IPv6 Internet to an IPv4 network . . . . . 13
     2.4.  Scenario 4: an IPv4 network to the IPv6 Internet . . . . . 14
     2.5.  Scenario 5: an IPv6 network to an IPv4 network . . . . . . 15
     2.6.  Scenario 6: an IPv4 network to an IPv6 network . . . . . . 15
     2.7.  Scenario 7: the IPv6 Internet to the IPv4 Internet . . . . 16
     2.8.  Scenario 8: the IPv4 Internet to the IPv6 Internet . . . . 17
   3.  Framework  . . . . . . . . . . . . . . . . . . . . . . . . . . 17
     3.1.  Translation Components . . . . . . . . . . . . . . . . . . 18
       3.1.1.  Address Translation  . . . . . . . . . . . . . . . . . 18
       3.1.2.  IP and ICMP Translation  . . . . . . . . . . . . . . . 19
       3.1.3.  Maintaining Translation States . . . . . . . . . . . . 19
       3.1.4.  DNS ALG  . . . . . . . . . . . . . . . . . . . . . . . 19
       3.1.5.  ALGs for Other Applications Layer Protocols  . . . . . 20
     3.2.  Operation Mode for Specific Scenarios  . . . . . . . . . . 20
       3.2.1.  Stateless Translation  . . . . . . . . . . . . . . . . 20
       3.2.2.  Stateful Translation . . . . . . . . . . . . . . . . . 22
     3.3.  Layout of the Related Documents  . . . . . . . . . . . . . 23
   4.  Translation in Operation . . . . . . . . . . . . . . . . . . . 25
   5.  Unsolved Problems  . . . . . . . . . . . . . . . . . . . . . . 26
   6.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 26
   7.  Security Considerations  . . . . . . . . . . . . . . . . . . . 26
   8.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 26
   9.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 27
     9.1.  Normative References . . . . . . . . . . . . . . . . . . . 27
     9.2.  Informative References . . . . . . . . . . . . . . . . . . 28
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 30







Baker, et al.            Expires January 6, 2010                [Page 2]


Internet-Draft     Framework for IPv4/IPv6 Translation         July 2009


1.  Introduction

   This note describes a framework for IPv4/IPv6 translation.  This is
   in the context of replacing NAT-PT [RFC2766], which was deprecated by
   [RFC4966], and to enable networks to have IPv4 and IPv6 coexist in a
   somewhat rational manner while transitioning to an IPv6-only network.

   NAT-PT was deprecated to inform the community that NAT-PT had
   operational issues and was not considered a viable medium or long
   term strategy for either coexistence or transition.  It wasn't
   intended to say that IPv4<->IPv6 translation was bad.  But the way
   that NAT-PT did it was bad, and in particular using NAT-PT as a
   general purpose solution was bad.  As with the deprecation of the RIP
   routing protocol [RFC1923] at the time the Internet was converting to
   CIDR, the point was to encourage network operators to actually move
   away from technology with known issues.

   [RFC4213] describes the IETF's view of the most sensible transition
   model.  The IETF recommends, in short, that network operators
   (transit providers, service providers, enterprise networks, small and
   medium business, SOHO and residential customers, and any other kind
   of network that may currently be using IPv4) obtain an IPv6 prefix,
   turn on IPv6 routing within their networks and between themselves and
   any peer, upstream, or downstream neighbors, enable it on their
   computers, and use it in normal processing.  This should be done
   while leaving IPv4 stable, until a point is reached that any
   communication that can be carried out could use either protocol
   equally well.  At that point, the economic justification for running
   both becomes debatable, and network operators can justifiably turn
   IPv4 off.  This process is comparable to that of [RFC4192], which
   describes how to renumber a network using the same address family
   without a flag day.  While running stably with the older system,
   deploy the new.  Use the coexistence period to work out such kinks as
   arise.  When the new is also running stably, shift production to it.
   When network and economic conditions warrant, remove the old, which
   is now no longer necessary.

   The question arises: what if that is infeasible due to the time
   available to deploy or other considerations?  What if the process of
   moving a network and its components or customers is starting too late
   for contract cycles to affect IPv6 turn-up on important parts at a
   point where it becomes uneconomical to deploy global IPv4 addresses
   in new services?  How does one continue to deploy new services
   without balkanizing the network?

   This document describes translation as one of the tools networks
   might use to facilitate coexistence and ultimate transition.




Baker, et al.            Expires January 6, 2010                [Page 3]


Internet-Draft     Framework for IPv4/IPv6 Translation         July 2009


1.1.  Why Translation?

   Besides dual stack deployment, there are two fundamental approaches
   one could take to interworking between IPv4 and IPv6: tunneling and
   translation.  One could - and in the 6NET we did - build an overlay
   network using the new protocol inside tunnels.  Various proposals
   take that model, including 6to4 [RFC3056], Teredo [RFC4380], ISATAP
   [RFC5214],and DS-Lite [I-D.durand-softwire-dual-stack-lite].  The
   advantage of doing so is that the new is enabled to work without
   disturbing the old protocol, providing connectivity between users of
   the new protocol.  There are two disadvantages to tunneling:

   o  Operators of old protocol networks are unable to offer services to
      users of the new architecture, and those users are unable to use
      the services of the underlying infrastructure - it is just
      bandwidth, and

   o  It doesn't enable new protocol users to communicate with old
      protocol users without dual-stack hosts.

   As noted, in this work, we look at Internet Protocol translation as a
   transition strategy.  [RFC4864] forcefully makes the point that many
   of the reasons people use Network Address Translators are met as well
   by routing or protocol mechanisms that preserve the end to end
   addressability of the Internet.  What it did not consider is the case
   in which there is an ongoing requirement to communicate with IPv4
   systems, but configuring IPv4 routing is not in the network
   operator's view the most desirable strategy, or is infeasible due to
   a shortage of global address space.  Translation enables the client
   of a network, whether a transit network, an access network, or an
   edge network, to access the services of the network and communicate
   with other network users regardless of their protocol usage - within
   limits.  Like NAT-PT, IPv4/IPv6 translation under this rubric is not
   a long term support strategy, but it is a medium term coexistence
   strategy that can be used to facilitate a long term program of
   transition.

1.2.  Terminology

   The following terminology is used in this document and other
   documents related to it.

   An IPv4 network:  A specific network that has IPv4-only
      implementation.  This could be an enterprise's IPv4-only network
      or an ISP's IPv4-only network.  The term is used to illustrate an
      IPv4 network under discussion is the small site comparing to the
      global IPv4 Internet.




Baker, et al.            Expires January 6, 2010                [Page 4]


Internet-Draft     Framework for IPv4/IPv6 Translation         July 2009


   An IPv6 network:  A specific network that has IPv6-only
      implementation.  This could be an enterprise's IPv6-only network
      or an ISP's IPv6-only network.  The term is used to illustrate an
      IPv6 network under discussion is the small site comparing to the
      global IPv6 Internet.

   Dual Stack implementation:  A Dual Stack implementation, in this
      context, comprises an enabled end system stack plus routing in the
      network.  It implies that two application instances are capable of
      communicating using either IPv4 or IPv6 - they have stacks, they
      have addresses, and they have any necessary network support
      including routing.

   IPv4-binding IPv6 addresses:  The IPv6 addresses which have temporal
      mapping relationship to specific IPv4 addresses.  This
      relationship is established and maintained as the states (mapping
      table between IPv4 address/transport port and IPv6 address/
      transport port) in the translator.  The states are session
      initiated, and the IPv4 and IPv6 address relationship is binding
      from session initiation to the end.

   IPv4-embedded IPv6 addresses:  The IPv6 addresses which have explicit
      mapping relationship to the IPv4 addresses.  This relationship is
      self described by embedding IPv4 address in the IPv6 address.  The
      IPv4-embedded IPv6 addresses can be used either in source address
      translation or in destination address translation or in both.

   IPv4-only:  An IPv4-only implementation, in this context, comprises
      an IPv4 enabled end system stack plus routing in the network.  It
      implies that two application instances are capable of
      communicating using IPv4, but not IPv6 - they have an IPv4 stack,
      addresses, and network support including IPv4 routing and
      potentially IPv4/IPv4 translation, but some element is missing
      that prevents communication with IPv6 hosts.

   IPv6-only:  An IPv6-only implementation, in this context, comprises
      an IPv6 enabled end system stack plus routing in the network.  It
      implies that two application instances are capable of
      communicating using IPv6, but not IPv4 - they have an IPv6 stack,
      addresses, and network support including routing in IPv6, but some
      element is missing that prevents communication with IPv4 hosts.

   LIR Prefix:  An IPv6 prefix assigned by a network operator for
      embedding IPv4 addresses into IPv6 addresses.  In this case, each
      network running a translator will create a representation of the
      whole IPv4 address space in the IPv6 address space.





Baker, et al.            Expires January 6, 2010                [Page 5]


Internet-Draft     Framework for IPv4/IPv6 Translation         July 2009


   LIR:  See Local Internet Registry.

   Local Internet Registry:  A Local Internet Registry (LIR) is an
      organization which has received an IP address allocation from a
      Regional Internet Registry (RIR), and which may assign parts of
      this allocation to its own internal network or those of its
      customers.  An LIR is thus typically an Internet service provider
      or an enterprise network.

   State:  "State" refers to dynamic information that is stored in a
      network element.  For example, if two systems are connected by a
      TCP connection, each stores information about the connection,
      which is called "connection state".  In this context, the term
      refers to dynamic correlations between IP addresses on either side
      of a translator, or {IP Address, Transport type, transport port
      number} tuples on either side of the translator.  Of stateful
      algorithms, there are at least two major flavors depending on the
      kind of state they maintain:

      Hidden state:  the existence of this state is unknown outside the
         network element that contains it.

      Known state:  the existence of this state is known by other
         network elements.

   Stateful Translation:  A translation algorithm may be said to
      "require state in a network element" or be "stateful" if the
      transmission or reception of a packet creates or modifies a data
      structure in the relevant network element.

   Stateless Translation:  A translation algorithm that is not
      "stateful" is "stateless".  It derives its needed information
      algorithmically from the messages it is translating.

   Stateful Translator:  A translator if it uses stateful translation
      algorithm in one side of address (either source or destination
      address) during its session initiating.  The stateful translator
      also uses the stateless translation algorithm for other side of
      address.  IPv4-binding IPv6 address procedure will be used in
      stateful address translation.

   Stateless Translator:  A translator if it uses only stateless
      translation algorithm in both destination address and source
      address.  The IPv4-embedded IPv6 addresses will be used in both
      destination address and source address translation.






Baker, et al.            Expires January 6, 2010                [Page 6]


Internet-Draft     Framework for IPv4/IPv6 Translation         July 2009


   Well-Known Prefix:  The prefix assigned by IANA for embedding IPv4
      addresses into IPv6 addresses.  In this case, there would be a
      single representation of a public IPv4 address in the IPv6 address
      space.

1.3.  Translation Objectives

   In any translation model, there is a question of objectives.
   Ideally, one would like to make any system and any application
   running on it able to "talk with" - exchange datagrams supporting
   applications with - any other system running the same application
   regardless of whether they have an IPv4 stack and connectivity or
   IPv6 stack and connectivity.  That was the model for NAT-PT, and the
   things it necessitated led to scaling and operational difficulties.

   So the question comes back to what different kinds of connectivity
   can be easily supported and what kinds are harder, and what
   technologies are needed to at least pick the low-hanging fruit.  We
   observe that applications today fall into three main categories:

   Client/Server Application:  Per whatis.com, "'Client/server'
      describes the relationship between two computer programs in which
      one program, the client, makes a service request from another
      program, the server, which fulfills the request."  In networking,
      the behavior of the applications is that connections are initiated
      from client software and systems to server software and systems.
      Examples include mail handling between an end user and his mail
      system (POP3, IMAP, and MUA->MTA SMTP), FTP, the web, and DNS name
      translation.

   Peer to Peer Application:  A P2P application is an application that
      uses the same endpoint to initiate outgoing sessions to peering
      hosts as well as accept incoming sessions from peering hosts.
      These in turn fall broadly into two categories:

      Peer to peer infrastructure applications:  Examples of
         "infrastructure applications" include SMTP between MTAs,
         Network News, and SIP.  Any MTA might open an SMTP session with
         any other at any time; any SIP Proxy might similarly connect
         with any other SIP Proxy.  An important characteristic of these
         applications is that they use ephemeral sessions - they open
         sessions when they are needed and close them when they are
         done.

      Peer to peer file exchange applications:  Examples of these
         include Limewire, BitTorrent, and UTorrent.  These are
         applications that open some sessions between systems and leave
         them open for long periods of time, and where ephemeral



Baker, et al.            Expires January 6, 2010                [Page 7]


Internet-Draft     Framework for IPv4/IPv6 Translation         July 2009


         sessions are important, are able to learn about the reliability
         of peers from history or by reputation.  They use the long term
         sessions to map content availability.  Short term sessions are
         used to exchange content.  They tend to prefer to ask for
         content from servers that they find reliable and available.

   If the question is the ability to open connections between systems,
   then one must ask who opens connections.

   o  We need a technology that will enable systems that act as clients
      to be able to open sessions with other systems that act as
      servers, whether in the IPv6->IPv4 direction or the IPv4->IPv6
      direction.  Ideally, this is stateless; especially in a carrier
      infrastructure, the preponderance of accesses will be to servers,
      and this optimizes access to them.  However, a stateful algorithm
      is acceptable if the complexity is minimized and a stateless
      algorithm cannot be constructed.

   o  We also need a technology that will allow peers to connect with
      each other, whether in the IPv6->IPv4 direction or the IPv4->IPv6
      direction.  Again, it would be ideal if this was stateless, but a
      stateful algorithm is acceptable if the complexity is minimized
      and a stateless algorithm cannot be constructed.

   o  In many situations, hosts are purely clients.  In those
      situations, we do not need an algorithm to enable connections to
      those hosts

   The complexity arguments bring us in the direction of hidden state:
   if state must be shared between the application and the translator or
   between translation components, complexity and deployment issues are
   greatly magnified.  The objective of the translators is to reduce, as
   much as possible, the software changes in the hosts necessary to
   support translation.

   NAT-PT is an example of a facility with known state - at least two
   software components (the data plane translator and the DNS
   Application Layer Gateway, which may be implemented in the same or
   different systems) share and must coordinate translation state.  A
   typical IPv4/IPv4 NAT implements an algorithm with hidden state.
   Obviously, stateless translation requires less computational overhead
   than stateful translation, and less memory to maintain the state,
   because the translation tables and their associated methods and
   processes exist in a stateful algorithm and don't exist in a
   stateless one.






Baker, et al.            Expires January 6, 2010                [Page 8]


Internet-Draft     Framework for IPv4/IPv6 Translation         July 2009


1.4.  Transition Plan

   While the design of IPv4 made it impossible for IPv6 to be compatible
   on the wire, the designers intended that it would coexist with IPv4
   during a period of transition.  The primary mode of coexistence was
   dual-stack operation - routers would be dual-stacked so that the
   network could carry both address families, and IPv6-capable hosts
   could be dual-stack to maintain access to IPv4-only partners.  The
   goal was that the preponderance of hosts and routers in the Internet
   would be IPv6-capable long before IPv4 address space allocation was
   completed.  At this time, it appears the exhaustion of IPv4 address
   space will occur before significant IPv6 adoption.

   Curran's "A Transition Plan for IPv6" [RFC5211] proposes a three-
   phase progression:

   Preparation Phase (current):  characterized by pilot use of IPv6,
      primarily through transition mechanisms defined in [RFC4213], and
      planning activities.

   Transition Phase (2010 through 2011):  characterized by general
      availability of IPv6 in provider networks which SHOULD be native
      IPv6; organizations SHOULD provide IPv6 connectivity for their
      Internet-facing servers, but SHOULD still provide IPv4-based
      services via a separate service name.

   Post-Transition Phase (2012 and beyond):  characterized by a
      preponderance of IPv6-based services and diminishing support for
      IPv4-based services.

   Various timelines have been discussed, but most will agree with the
   pattern of above three transition phases, also known as "S" curve
   transition pattern.

   In each of these phases, the coexistence problem and solution space
   has a different focus:

   Preparation Phase:  Coexistence tools are needed to facilitate early
      adopters by removing impediments to IPv6 deployment, and to assure
      that nothing is lost by adopting IPv6, in particular that the IPv6
      adopter has unfettered access to the global IPv4 Internet
      regardless of whether they have a global IPv4 address (or any IPv4
      address or stack at all.)  While it might appear reasonable for
      the cost and operational burden to be borne by the early adopter,
      the shared goal of promoting IPv6 adoption would argue against
      that model.  Additionally, current IPv4 users should not be forced
      to retire or upgrade their equipment and the burden remains on
      service providers to carry and route native IPv4.  This is known



Baker, et al.            Expires January 6, 2010                [Page 9]


Internet-Draft     Framework for IPv4/IPv6 Translation         July 2009


      as the early stage of the "S" curve.

   Transition Phase:  This is the last stage of "S" curve.  During the
      middle stage of "S" curve, while IPv6 adoption can be expected to
      accelerate, there will still be a significant portion of the
      Internet operating in IPv4-only or preferring IPv4.  During this
      phase the norm shifts from IPv4 to IPv6, and coexistence tools
      evolve to ensure interoperability between domains that may be
      restricted to IPv4 or IPv6.

   Post-Transition Phase:  In this phase, IPv6 is ubiquitous and the
      burden of maintaining interoperability shifts to those who choose
      to maintain IPv4-only systems.  While these systems should be
      allowed to live out their economic life cycles, the IPv4-only
      legacy users at the edges should bear the cost of coexistence
      tools, and at some point service provider networks should not be
      expected to carry and route native IPv4 traffic.

   The choice between the terms "transition" versus "coexistence" has
   engendered long philosophical debate.  "Transition" carries the sense
   that we are going somewhere, while "coexistence" seems more like we
   are sitting somewhere.  Historically with IETF, "transition" has been
   the term of choice [RFC4213][RFC5211], and the tools for
   interoperability have been called "transition mechanisms".  There is
   some perception or conventional wisdom that adoption of IPv6 is being
   impeded by the deficiency of tools to facilitate interoperability of
   nodes or networks that are constrained (in some way, fully or
   partially) from full operation in one of the address families.  In
   addition, it is apparent that transition will involve a period of
   coexistence; the only real question is how long that will last.

   Thus, coexistence is an integral part of the transition plan, not in
   conflict with it, but there will be a balancing act.  It starts out
   being a way for early adopters to easily exploit the bigger IPv4
   Internet, and ends up being a way for late/never adopters to hang on
   with IPv4 (at their own expense, with minimal impact or visibility to
   the Internet).  One way to look at solutions is that cost incentives
   (both monetary cost and the operational overhead for the end user)
   should encourage IPv6 and discourage IPv4.  That way natural market
   forces will keep the transition moving - especially as the legacy
   IPv4-only stuff ages out of use.  There will come a time to set a
   date after which no one is obligated to carry native IPv4 but it
   would be premature to attempt to do so yet.  The end goal should not
   be to eliminate IPv4 by fiat, but rather render it redundant through
   ubiquitous IPv6 deployment.  IPv4 may never go away completely, but
   rational plans should move the costs of maintaining IPv4 to those who
   insist on using it after wide adoption of IPv6.




Baker, et al.            Expires January 6, 2010               [Page 10]


Internet-Draft     Framework for IPv4/IPv6 Translation         July 2009


2.  Scenarios of the IPv4/IPv6 Translation

   It is important to note that the choice of translation solution and
   the assumptions about the network where they are used impact the
   consequences.  A translator for the general case has a number of
   issues that a translator for a more specific situation may not have
   at all.

   The intention of this document is to focus on the network-based
   translation solutions under all kinds of situations.  All IPv4/IPv6
   translation cases can be easily described in terms of "interoperation
   between a set of systems that only communicate using IPv4 and a set
   of systems that only communicate using IPv6", but the differences at
   a detail level make them interesting.

   Based on transition plan described in Section 1.4, there are four
   types of IPv4/IPv6 translation interoperation cases:

   a.  Interoperation between an IPv6 network and the IPv4 Internet

   b.  Interoperation between an IPv4 network and the IPv6 Internet

   c.  Interoperation between an IPv6 network and an IPv4 network

   d.  Interoperation between the IPv6 Internet and the IPv4 Internet

   Each one in the above can be divided into two scenarios, depends on
   whether the IPv6 initiates communication or the IPv4 initiates
   communication.  So there are totally eight scenarios.

   Scenario 1: an IPv6 network to the IPv4 Internet

   Scenario 2: the IPv4 Internet to an IPv6 network

   Scenario 3: the IPv6 Internet to an IPv4 network

   Scenario 4: an IPv4 network to the IPv6 Internet

   Scenario 5: an IPv6 network to an IPv4 network

   Scenario 6: an IPv4 network to an IPv6 network

   Scenario 7: The IPv6 Internet to the IPv4 Internet

   Scenario 8: The IPv4 Internet to the IPv6 Internet

   We will discuss each scenario in detail in next section.




Baker, et al.            Expires January 6, 2010               [Page 11]


Internet-Draft     Framework for IPv4/IPv6 Translation         July 2009


2.1.  Scenario 1: an IPv6 network to the IPv4 Internet

   Due to the lack of the public routable IPv4 addresses or under other
   technical or economical constrains, the ISP's or enterprise's network
   is IPv6-only, but the hosts in the network require communicating with
   the global IPv4 Internet.

   This is the typical scenario for what we sometimes call "greenfield"
   deployments.  One example is an enterprise network that wishes to
   operate only IPv6 for operational simplicity, but still wishes to
   reach the content in the IPv4 Internet.  The greenfield enterprise
   scenario is different in the sense that there is only one place that
   the enterprise can easily modify: the border between its network and
   the IPv4 Internet.  Obviously, the IPv4 Internet operates the way it
   already does.  But in addition, the hosts in the enterprise network
   are commercially available devices, personal computers with existing
   operating systems.  This restriction drives us to a "one box" type of
   solution, where IPv6 can be translated into IPv4 to reach the public
   Internet.

   Other cases that have been mentioned include wireless ISP networks
   and sensor networks.  This bears a striking resemblance to this
   scenario as well, if one considers the ISP network to simply be a
   very special kind of enterprise network.


               --------
             //        \\       -----------
            /            \     //          \\
           /             +----+              \
          |              |XLAT|               |
          |  The IPv4    +----+  An IPv6      |
          |  Internet    +----+  Network      |  XLAT: v4/v6
          |              |DNS |               |        Translator
           \             +----+              /   DNS:  DNS-ALG
            \            /     \\          //
             \\        //       -----------
                --------
                          <====

                           Figure 1: Scenario 1

   Currently, there are two proposed solutions for this scenario: NAT64
   [I-D.bagnulo-behave-nat64] as the stateful translation and IVI
   [I-D.xli-behave-ivi] as the stateless translation schemes,
   respectively.  The NAT64 can support any IPv6 addresses in an IPv6
   network communicate with the IPv4 Internet, while IVI can support a
   subset of the IPv6 addresses in an IPv6 network communicate with the



Baker, et al.            Expires January 6, 2010               [Page 12]


Internet-Draft     Framework for IPv4/IPv6 Translation         July 2009


   IPv4 Internet.  In addition, IVI can also support Scenario 2, while
   NAT64 cannot.

2.2.  Scenario 2: the IPv4 Internet to an IPv6 network

   This scenario is predicted to become increasingly important as the
   network administration under pressure to put the IPv6-only servers in
   its network, while the majority of the Internet users are still in
   the IPv4 Internet.  For example, for an IPv6 operator, it may be a
   difficult proposition to leave all IPv4-only devices without
   reachability.  Thus, with translator solution for this scenario, the
   benefits would be clear.  Not only could servers move directly to
   IPv6 without trudging through a difficult transition period, but they
   could do so without risk of losing connectivity with the IPv4-only
   Internet.


               --------
             //        \\        ----------
            /            \     //          \\
           /             +----+              \
          |              |XLAT|               |
          |  The IPv4    +----+  An IPv6      |
          |  Internet    +----+  Network      |  XLAT: v4/v6
          |              |DNS |               |        Translator
           \             +----+              /   DNS:  DNS-ALG
            \            /     \\          //
             \\        //        ----------
               --------
                          ====>

                           Figure 2: Scenario 2

   In general, this scenario presents the hard case for translation
   scheme.  The stateful translation such as NAT-PT [RFC2766] can be
   used in this scenario, but it requires tightly couple DNS ALG in the
   translator and this technique is deprecated by IETF [RFC4966].

   The stateless translation solution IVI [I-D.xli-behave-ivi] in
   Scenario 1 can also work in Scenario 2, since it can support IPv4
   initiated communications with the subset of the IPv6 addresses in an
   IPv6 network.

2.3.  Scenario 3: the IPv6 Internet to an IPv4 network

   There is a requirement for the legacy IPv4 network to provide
   services to the IPv6 hosts.




Baker, et al.            Expires January 6, 2010               [Page 13]


Internet-Draft     Framework for IPv4/IPv6 Translation         July 2009


                                -----------
              ----------       //         \\
            //          \\    /             \
           /             +----+              \
          |              |XLAT|               |
          |  An IPv4     +----+  The IPv6     |
          |  Network     +----+  Internet     |  XLAT: v4/v6
          |              |DNS |               |        Translator
           \             +----+               /  DNS:  DNS ALG
            \\         //      \             /
              ---------         \\         //
                                 -----------
                         <====

                           Figure 3: Scenario 3

   The IPv6 initiated communication can be achieved through stateful
   translator.  For example, NAT64 [I-D.bagnulo-behave-nat64] can
   support this scenario.

2.4.  Scenario 4: an IPv4 network to the IPv6 Internet

   Due to the technical or economical constrains, the ISP's or
   enterprise's network is IPv4-only, and the IPv4-only hosts may
   require the communicate with the global IPv6 Internet.


                                -----------
              ----------       //         \\
            //          \\    /             \
           /             +----+              \
          |              |XLAT|               |
          |  An IPv4     +----+  The IPv6     |  XLAT: v4/v6
          |  Network     +----+  Internet     |        Translator
          |              |DNS |               |  DNS:  DNS ALG
           \             +----+               /
            \\         //      \             /
              ---------         \\         //
                                 ----------
                         =====>

                           Figure 4: Scenario 4

   In general, this scenario presents the hard case for translation
   scheme.  The stateful translation such as NAT-PT [RFC2766] can be
   used in this scenario, but it requires tightly couple DNS ALG in the
   translator and this technique is deprecated by IETF [RFC4966].




Baker, et al.            Expires January 6, 2010               [Page 14]


Internet-Draft     Framework for IPv4/IPv6 Translation         July 2009


   From transition phase discussion in Section 1.4, this scenario will
   probably only occur when we well pass the early stage of "S" curve.
   The v4/v6 transition already move to right direction.  Therefore, the
   in-network translation is not viable for this scenario and other
   techniques should be considered.

2.5.  Scenario 5: an IPv6 network to an IPv4 network

   This is one of scenarios when both an IPv4 network and an IPv6
   network are within the same organization, or this interoperation
   especially as a service within a large network such as an enterprise
   or ISP network or between peer networks.

   The IPv4 addresses used are either public IPv4 addresses or [RFC1918]
   addresses.  The IPv6 addresses used are either public IPv6 addresses
   or ULA (Unique Local Address) [RFC4193].


              ---------          ---------
            //         \\      //          \\
           /             +----+              \
          |              |XLAT|               |
          |  An IPv4     +----+  An IPv6      |
          |  Network     +----+  Network      |  XLAT: v4/v6
          |              |DNS |               |        Translator
           \             +----+              /   DNS:  DNS ALG
            \\         //      \\          //
               --------          ---------
                         <====


                           Figure 5: Scenario 5

   The translation requirement from this scenario has no significant
   difference from scenario 1, so both the stateful and stateless
   translator schemes discussed in Section 2.1 apply here.

2.6.  Scenario 6: an IPv4 network to an IPv6 network

   This is another scenario when both an IPv4 network and an IPv6
   network are within the same organization, or this interoperation
   especially as a service within a large network such as an enterprise
   or ISP network or between peer networks.

   The IPv4 addresses used are either public IPv4 addresses or [RFC1918]
   addresses.  The IPv6 addresses used are either public IPv6 addresses
   or ULA (Unique Local Address) [RFC4193].




Baker, et al.            Expires January 6, 2010               [Page 15]


Internet-Draft     Framework for IPv4/IPv6 Translation         July 2009


               --------          ---------
            //         \\      //          \\
           /             +----+              \
          |              |XLAT|               |
          |  An IPv4     +----+  An IPv6      |
          |  Network     +----+  Network      |  XLAT: v4/v6
          |              |DNS |               |        Translator
           \             +----+              /   DNS:  DNS ALG
             \\        //      \\          //
               --------          ---------
                           ====>


                           Figure 6: Scenario 6

   The translation requirement from this scenario has no significant
   difference from scenario 2, so the translator scheme discussed in
   Section 2.2 applies here.

2.7.  Scenario 7: the IPv6 Internet to the IPv4 Internet

   This seems the ideal case for in-network translation technology,
   where any IPv6-only host on the global Internet can open connection
   to any IPv4-only host on the global Internet.


               --------          ---------
             //       \\        //        \\
            /           \      /            \
           /             +----+              \
          |              |XLAT|               |
          |  The IPv4    +----+  The IPv6     |
          |  Internet    +----+  Internet     |  XLAT: v4/v6
          |              |DNS |               |        Translator
           \             +----+              /   DNS:  DNS ALG
             \          /      \            /
              \\      //        \\        //
               --------          ---------
                         <====


                           Figure 7: Scenario 7

   Due to the huge difference between the address spaces of the IPv4
   Internet and the IPv6 Internet, there is no viable translation
   techniques to handle the unlimited IPv6 address translation.

   If we ever run into this scenario, fortunately, the IPv4-IPv6



Baker, et al.            Expires January 6, 2010               [Page 16]


Internet-Draft     Framework for IPv4/IPv6 Translation         July 2009


   transition already proceeds after early stage of "S" curve,
   therefore, there is no obvious business reason to demand translation
   solution as only transition strategy.

2.8.  Scenario 8: the IPv4 Internet to the IPv6 Internet

   This seems the ideal case for in-network translation technology,
   where any IPv4-only on the global Internet host can open connection
   to any IPv6-only host on the global Internet.


               --------          ---------
             //       \\        //        \\
            /           \      /            \
           /             +----+              \
          |              |XLAT|               |
          |  The IPv4    +----+  The IPv6     |
          |  Internet    +----+  Internet     |  XLAT: v4/v6
          |              |DNS |               |        Translator
           \             +----+              /   DNS:  DNS ALG
             \          /      \            /
              \\      //        \\        //
               --------          ---------
                           ====>


                           Figure 8: Scenario 8

   Due to the huge difference between the address spaces of the IPv4
   Internet and the IPv6 Internet, there is no viable translation
   techniques to handle the unlimited IPv6 address translation.

   If we ever run into this scenario, fortunately, the IPv4-IPv6
   transition already proceeds after early stage of "S" curve,
   therefore, there is no obvious business reason to demand translation
   solution as only transition strategy.


3.  Framework

   Having laid out the preferred transition model and the options for
   implementing it (Section 1.1), defined terms (Section 1.2),
   considered the requirements (Section 1.3), considered the transition
   model (Section 1.4), and considered the kinds of scenarios the
   facility would support (Section 2), we now turn to a framework for
   IPv4/IPv6 translation.  The framework contains the following
   components.




Baker, et al.            Expires January 6, 2010               [Page 17]


Internet-Draft     Framework for IPv4/IPv6 Translation         July 2009


   o  Address translation

   o  IP and ICMP translation

   o  Maintaining translation states

   o  DNS ALG

   o  ALGs for other applications layer protocols (e.g., FTP)

3.1.  Translation Components

3.1.1.  Address Translation

   When the IPv6/IPv4 translation is performed, we should specify how an
   individual IPv6 address is translated to a corresponding IPv4
   address, and vice versa, in cases where an algorithmic mapping is
   used.  This includes the choice of IPv6 prefix and the choice of
   method by which the remainder of the IPv6 address is derived from an
   IPv4 address. [translator-addressing-00] {Editor's Note: Waiting for
   the draft}

   Note that translating IPv4 address to IPv6 address and translating
   IPv6 address to IPv4 address are different for the stateless
   translation and the stateful translation.
   [I-D.xli-behave-v4v6-prefix].

   o  For the stateless translation, the algorithmic mapping algorithm
      is used both to translate IPv4 address to IPv6 address and to
      translate IPv6 address to IPv4 address.  In this case, blocks of
      service provider's IPv4 addresses are mapped into IPv6 and used by
      physical IPv6 hosts.  The original IPv4 form of these blocks of
      service provider's IPv4 addresses are used to represent the
      physical IPv6 hosts in IPv4.  Note that the stateless translation
      supports both IPv6 initiated as well as IPv4 initiated
      communications.

   o  For the stateful translation, the algorithmic mapping algorithm is
      used to translate IPv4 address to IPv6 address, while a session
      initiated state table is used to translate IPv6 address to IPv4
      address.  In this case, blocks of service provider's IPv4
      addresses are maintained in the translator as the IPv4 address
      pools and dynamically bind to the specific IPv6 addresses.  The
      original IPv4 form of these blocks of service provider's IPv4
      addresses are used to represent the physical IPv6 host in IPv4.
      However, due to the dynamical binging, the stateful translation
      only supports the IPv6 initiated communication.




Baker, et al.            Expires January 6, 2010               [Page 18]


Internet-Draft     Framework for IPv4/IPv6 Translation         July 2009


3.1.2.  IP and ICMP Translation

   The IPv6/IPv4 translator is based on the update to the Stateless IP/
   ICMP Translation Algorithm (SIIT) described in [RFC2765].  The
   algorithm translates between IPv4 and IPv6 packet headers (including
   ICMP headers) [I-D.ietf-behave-v6v4-xlate].

   The IP and ICMP translation document [I-D.ietf-behave-v6v4-xlate]
   addresses in both stateless and stateful modes.  In the stateless
   mode, translation information is carried in the address itself,
   permitting both IPv4->IPv6 and IPv6->IPv4 session establishment with
   neither state nor configuration in the IP/ICMP translator.  In the
   stateful mode, translation state is maintained between IPv4 address/
   transport port tuples and IPv6 address/transport port tuples,
   enabling IPv6 systems to open sessions with IPv4 systems.  The choice
   of operational mode is made by the operator deploying the network and
   is critical to the operation of the applications using it.

3.1.3.  Maintaining Translation States

   For the stateful translator, besides IP and ICMP translation, special
   action must be taken to maintain the translation states.  NAT64
   [I-D.ietf-behave-v6v4-xlate-stateful] describes a mechanism for
   maintaining states.

3.1.4.  DNS ALG

   [I-D.ietf-behave-dns64] describes the mechanisms by which a DNS
   Translator is intended to operate.  It is designed to operate on the
   basis of known but fixed state: the resource records, and therefore
   the names and addresses, are known to network elements outside of the
   data plane translator, but the process of serving them to
   applications does not interact with the data plane translator in any
   way.

   There are at least three possible implementations of a DNS ALG:

   Static records:  One could literally populate DNS with corresponding
      A and AAAA records.  This is most appropriate for stub services
      such as access to a legacy printer pool.

   Dynamic Translation of static records:  In more general operation,
      the expected behavior is for the application to request both A and
      AAAA records, and for an A record to be (retrieved and) translated
      by the DNS ALG if and only if no reachable AAAA record exists.
      This has ephemeral issues with cached translations, which can be
      dealt with by caching only the source record and forcing it to be
      translated whenever accessed.



Baker, et al.            Expires January 6, 2010               [Page 19]


Internet-Draft     Framework for IPv4/IPv6 Translation         July 2009


   Static or Dynamic Translation of Dynamic DNS records:  In Dynamic DNS
      usage, a system could potentially report the translation of a name
      using an IPv4 binding IPv6 Address, or using both an IPv4 binding
      IPv6 Address and some other address.  The DNS ALG has several
      options; it could store a AAAA record for an IPv4 binding IPv6
      address and depend on translation of that for A records inline, it
      could store both an A and a AAAA record, or (when there is another
      IPv6 address as well which is stored as the AAAA record) it could
      store only the A record.

3.1.5.  ALGs for Other Applications Layer Protocols

   In addition, some applications require special support.  An example
   is FTP.  FTP's active mode doesn't work well across NATs without
   extra support such as SOCKS.  Across NATs, it generally uses passive
   mode.  However, the designers of FTP inexplicably wrote different and
   incompatible passive mode implementations for IPv4 and IPv6 networks.
   Hence, either they need to fix FTP, or a translator must be written
   for the application.  Other applications may be similarly broken.

   As a general rule, a simple operational recommendation will work
   around many application issues, which is that there should be a
   server in each domain or an instance of the server should have an
   interface in each domain.  For example, an SMTP MTA may be confused
   by finding an IPv6 address in its HELO when it is connected to using
   IPv4 (or vice versa), but would perfectly well if it had an interface
   in both the IPv4 and IPv6 domains and was used as an application
   layer bridge between them.

3.2.  Operation Mode for Specific Scenarios

   Currently, the proposed solutions for the IPv6/IPv4 translation are
   classified into stateless translation and stateful translation.

3.2.1.  Stateless Translation

   For the stateless translation, the translation information is carried
   in the address itself, permitting both IPv4->IPv6 and IPv6->IPv4
   sessions establishment.  The stateless translation supports end-to-
   end address transparency and has better scalability compared with the
   stateful translation.  [I-D.ietf-behave-v6v4-xlate]
   [I-D.xli-behave-ivi].

   Although the stateless translation mechanisms typically put
   constraints on what IPv6 addresses can be assigned to IPv6 hosts that
   want to communicate with IPv4 destinations using an algorithmic
   mapping.  For the Scenarios 1 ("an IPv6 network to the IPv4
   Internet"), it is not a serious drawback, since the address



Baker, et al.            Expires January 6, 2010               [Page 20]


Internet-Draft     Framework for IPv4/IPv6 Translation         July 2009


   assignment policy can be applied to satisfy this requirement for the
   IPv6 hosts which need the communication ability to the IPv4 Internet.
   In addition, the stateless translator supports Scenario 2 ("the IPv4
   Internet to an IPv6 network"), it means that not only could servers
   move directly to IPv6 without trudging through a difficult transition
   period, but they could do so without risk of losing connectivity with
   the IPv4-only Internet.

   The stateless translator can be used for Scenario 1, 2, 5 and 6, i.e.
   it supports "an IPv6 network to the IPv4 Internet", "the IPv4
   Internet to an IPv6 network", "an IPv6 network to an IPv4 network"
   and "an IPv4 network to an IPv6 network".


              --------
           //        \\       -----------
          /            \     //          \\
         /             +----+              \
        |              |XLAT|               |
        |  The IPv4    +----+  An IPv6      |
        |  Internet    +----+  Network      |  XLAT: Stateless v4/v6
        |              |DNS |  (address     |        Translator
         \             +----+   subset)    /   DNS:  DNS-ALG
          \            /     \\          //
           \\        //        ----------
             --------
                       <====>



           Figure 9: Stateless translator for Scenarios 1 and 2



               --------          ---------
            //         \\      //          \\
           /             +----+              \
          |              |XLAT|               |
          |  An IPv4     +----+  An IPv6      |
          |  Network     +----+  Network      |  XLAT: v4/v6
          |              |DNS |               |        Translator
           \             +----+              /   DNS:  DNS ALG
             \\        //      \\          //
               --------          ---------
                         <====>






Baker, et al.            Expires January 6, 2010               [Page 21]


Internet-Draft     Framework for IPv4/IPv6 Translation         July 2009


           Figure 10: Stateless translator for Scenarios 5 and 6

   The implementation of the stateless translator needs to refer to
   [I-D.ietf-behave-v6v4-xlate], [translator-addressing-00] {Editor's
   Note: Waiting for the draft}, and [I-D.ietf-behave-dns64].

3.2.2.  Stateful Translation

   For the stateful translation, the translation state is maintained
   between IPv4 address/port pairs and IPv6 address/port pairs, enabling
   IPv6 systems to open sessions with IPv4 systems
   [I-D.ietf-behave-v6v4-xlate] [I-D.ietf-behave-v6v4-xlate-stateful].

   The stateful translator can be used for Scenario 1, 3 and 5, i.e. it
   supports "an IPv6 network to the IPv4 Internet", "the IPv6 Internet
   to an IPv4 network" and "an IPv6 network to an IPv4 network".

   For Scenario 1, any IPv6 addresses in an IPv6 network can use the
   stateful translator, however it typically only supports initiation
   from the IPv6 side, and does not result in stable addresses that can
   be used in DNS and other protocols and applications that do not deal
   well with highly dynamic addresses.


             --------
           //        \\       -----------
          /            \     //          \\
         /             +----+              \
        |              |XLAT|               |
        |  The IPv4    +----+  An IPv6      |
        |  Internet    +----+  Network      |  XLAT: Stateful v4/v6
        |              |DNS |               |        Translator
         \             +----+              /   DNS:  DNS-ALG
          \            /     \\          //
           \\        //       -----------
             --------
                        <====


               Figure 11: Stateful translator for Scenario 1

   For scenario 3, the servers using IPv4 private addresses [RFC1918]
   and being reached from the IPv6 Internet basically includes the cases
   that for whatever reason the servers cannot be upgraded to IPv6 and
   they don't have public IPv4 addresses and it would be useful to allow
   IPv6 nodes in the IPv6 Internet to reach those servers.





Baker, et al.            Expires January 6, 2010               [Page 22]


Internet-Draft     Framework for IPv4/IPv6 Translation         July 2009


                                -----------
              ----------       //         \\
             //          \\    /             \
           /             +----+              \
          |              |XLAT|               |
          |  An IPv4     +----+  The IPv6     |
          |  Network     +----+  Internet     |  XLAT: v4/v6
          |              |DNS |               |        Translator
           \             +----+               /  DNS:  DNS ALG
            \\         //      \             /
              ---------         \\         //
                                -----------
                          <====


               Figure 12: Stateful translator for Scenario 3

   Similarly, the stateless translator can also be used for Scenario 5.


               --------          ---------
            //         \\      //          \\
           /             +----+              \
          |              |XLAT|               |
          |  An IPv4     +----+  An IPv6      |
          |  Network     +----+  Network      |  XLAT: v4/v6
          |              |DNS |               |        Translator
           \             +----+              /   DNS:  DNS ALG
             \\        //      \\          //
               --------          ---------
                          <====


           Figure 13: Stateful translator for Scenarios 5 and 6

   The implementation of the stateful translator needs to refer to
   [I-D.ietf-behave-v6v4-xlate], [I-D.ietf-behave-v6v4-xlate-stateful],
   [translator-addressing-00] {Editor's Note: Waiting for the draft},
   and [I-D.ietf-behave-dns64].

3.3.  Layout of the Related Documents

   Based on the above analysis, the IPv4/IPv6 translation series
   consists of the following documents.

   o  Framework for IPv4/IPv6 Translation (This document).





Baker, et al.            Expires January 6, 2010               [Page 23]


Internet-Draft     Framework for IPv4/IPv6 Translation         July 2009


   o  Address translation (The choice of IPv6 prefix and the choice of
      method by which the remainder of the IPv6 address is derived from
      an IPv4 address) [translator-addressing-00] {Editor's Note:
      Waiting for the draft}.

   o  IP and ICMP Translation (SIIT update, Header translation and ICMP
      handling) [I-D.ietf-behave-v6v4-xlate].

   o  DNS64 (A to AAAA mapping and DNSSec discussion)
      [I-D.ietf-behave-dns64].

   o  Xlate-stateful (Stateful translation including session database
      and mapping table handing) [I-D.ietf-behave-v6v4-xlate-stateful].

   o  FTP ALG.

   o  Others (Multicast, etc).

   The relationship among these documents is shown in the following
   figure.


               -----------------------------------------
              |   Framework for IPv4/IPv6 Translation  |
               -----------------------------------------
                 ||                                 ||
    -------------------------------------------------------------------
   |             ||     stateless and stateful      ||                 |
   |   --------------------                   ---------------------    |
   |  |Address Translation |   <========     | IP/ICMP Translation |   |
   |   --------------------                   ---------------------    |
   |          /\                                        /\             |
   |          ||                      ------------------||------------ |
   |          ||                     |  stateful        \/             |
   |   -----------------             |        ---------------------    |
   |  |     DNS64       |            |       |  Xlate-stateful     |   |
   |   -----------------             |        ---------------------    |
    -------------------------------------------------------------------
              /\                                        /\
              ||                                        ||
       -----------------                       --------------------
      |     FTP ALG     |                     |      Others        |
       -----------------                       --------------------




                        Figure 14: Document Layout



Baker, et al.            Expires January 6, 2010               [Page 24]


Internet-Draft     Framework for IPv4/IPv6 Translation         July 2009


   In the document layout, the IP/ICMP Translation and DNS64 refer to
   Address Translation.  The Xlate-stateful and IP/ICMP Translation
   refer to each other.

   The FTP ALG and other documents refer to the stateless and/or
   stateful translation documents.


4.  Translation in Operation

   Operationally, there are two ways that translation could be used - as
   a permanent solution making transition "the other guy's problem", and
   as a temporary solution for a new part of one's network while
   bringing up IPv6 services in the remaining parts of one's network.
   The delay could, for example, be caused by contract cycles that
   prevent IPv6 deployment during the life of the contract.  We
   obviously recommend the latter.  For the IPv4 parts of the network,
   [RFC4213]'s recommendation holds: bringing IPv6 up in those domains,
   moving production to it, and then taking down the now-unnecessary
   IPv4 service when economics warrant remains the least risk approach
   to transition.


                           ----------------------
                    //////                        \\\\\\
                ///         IPv4 or Dual Stack           \\\
              ||    +----+      Routing          +-----+    ||
             |      |IPv4|                       |IPv4+|      |
             |      |Host|                       |IPv6 |      |
              ||    +----+                       |Host |    ||
                \\\                              +-----+ ///
                    \\\\\+----+ +---+ +----+ +----+/////
                         |XLAT|-|DNS|-|SMTP|-|XLAT|
                         |    |-|ALG|-|MTA |-|    |
                    /////+----+ +---+ +----+ +----+\\\\\
                ///                                      \\\
              ||    +-----+                     +----+      ||
             |      |IPv4+|                     |IPv6|        |
             |      |IPv6 |                     |Host|        |
              ||    |Host |                     +----+      ||
                \\\ +-----+  IPv6-only Routing           ///
                    \\\\\\                        //////
                           ----------------------


                 Figure 15: Translation Operational Model

   During the coexistence phase, as shown in Figure 15, one expects a



Baker, et al.            Expires January 6, 2010               [Page 25]


Internet-Draft     Framework for IPv4/IPv6 Translation         July 2009


   combination of hosts - IPv6-only gaming devices and handsets, older
   computer operating systems that are IPv4-only, and modern mainline
   operating systems that support both.  One also expects a combination
   of networks - dual stack devices operating in single stack networks
   are effectively single stack, whether that stack is IPv4 or IPv6, as
   the other isn't providing communications services.


5.  Unsolved Problems

   This framework could support multicast, some discussions are in
   [I-D.venaas-behave-mcast46] and [I-D.xli-behave-ivi].

   This framework could support stateless translation with IPv4 address
   and transport port number multiplexing technique, some discussions
   are in [I-D.xli-behave-ivi].


6.  IANA Considerations

   This memo requires no parameter assignment by the IANA.

   Note to RFC Editor: This section will have served its purpose if it
   correctly tells IANA that no new assignments or registries are
   required, or if those assignments or registries are created during
   the RFC publication process.  From the author's perspective, it may
   therefore be removed upon publication as an RFC at the RFC Editor's
   discretion.


7.  Security Considerations

   One "security" issue has been raised, with an address format that was
   considered and rejected for that reason.  At this point, the editor
   knows of no other security issues raised by the address format that
   are not already applicable to the addressing architecture in general.


8.  Acknowledgements

   This is under development by a large group of people.  Those who have
   posted to the list during the discussion include Andrew Sullivan,
   Andrew Yourtchenko, Brian Carpenter, Congxiao Bao, Dan Wing, Dave
   Thaler, Ed Jankiewicz, Fred Baker, Hiroshi Miyata, Iljitsch van
   Beijnum, John Schnizlein, Kevin Yin, Magnus Westerlund, Marcelo
   Bagnulo Braun, Margaret Wasserman, Masahito Endo, Phil Roberts,
   Philip Matthews, Remi Denis-Courmont, Remi Despres, and Xing Li.




Baker, et al.            Expires January 6, 2010               [Page 26]


Internet-Draft     Framework for IPv4/IPv6 Translation         July 2009


   Ed Jankiewicz described the transition plan.

   The definition of a "Local Internet Registry" came from the
   Wikipedia, and was slightly expanded to cover the present case.
   (EDITOR'S QUESTION: Would it be better to describe this as an
   "operator-defined prefix"?)


9.  References

9.1.  Normative References

   [I-D.bagnulo-behave-dns64]
              Bagnulo, M., Sullivan, A., Matthews, P., Beijnum, I., and
              M. Endo, "DNS64: DNS extensions for Network Address
              Translation from IPv6 Clients to  IPv4 Servers",
              draft-bagnulo-behave-dns64-02 (work in progress),
              March 2009.

   [I-D.bagnulo-behave-nat64]
              Bagnulo, M., Matthews, P., and I. Beijnum, "NAT64: Network
              Address and Protocol Translation from IPv6 Clients to IPv4
              Servers", draft-bagnulo-behave-nat64-03 (work in
              progress), March 2009.

   [I-D.baker-behave-v4v6-translation]
              Baker, F., "IP/ICMP Translation Algorithm",
              draft-baker-behave-v4v6-translation-02 (work in progress),
              February 2009.

   [I-D.ietf-behave-dns64]
              Bagnulo, M., Sullivan, A., Matthews, P., and I. Beijnum,
              "DNS64: DNS extensions for Network Address Translation
              from IPv6 Clients to  IPv4 Servers",
              draft-ietf-behave-dns64-00 (work in progress), July 2009.

   [I-D.ietf-behave-v6v4-xlate]
              Li, X., Bao, C., and F. Baker, "IP/ICMP Translation
              Algorithm", draft-ietf-behave-v6v4-xlate-00 (work in
              progress), June 2009.

   [I-D.ietf-behave-v6v4-xlate-stateful]
              Bagnulo, M., Matthews, P., and I. Beijnum, "NAT64: Network
              Address and Protocol Translation from IPv6 Clients to IPv4
              Servers", draft-ietf-behave-v6v4-xlate-stateful-00 (work
              in progress), July 2009.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate



Baker, et al.            Expires January 6, 2010               [Page 27]


Internet-Draft     Framework for IPv4/IPv6 Translation         July 2009


              Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC2460]  Deering, S. and R. Hinden, "Internet Protocol, Version 6
              (IPv6) Specification", RFC 2460, December 1998.

   [RFC4291]  Hinden, R. and S. Deering, "IP Version 6 Addressing
              Architecture", RFC 4291, February 2006.

9.2.  Informative References

   [I-D.baker-behave-ivi]
              Li, X., Bao, C., Baker, F., and K. Yin, "IVI Update to
              SIIT and NAT-PT", draft-baker-behave-ivi-01 (work in
              progress), September 2008.

   [I-D.durand-softwire-dual-stack-lite]
              Durand, A., Droms, R., Haberman, B., and J. Woodyatt,
              "Dual-stack lite broadband deployments post IPv4
              exhaustion", draft-durand-softwire-dual-stack-lite-01
              (work in progress), November 2008.

   [I-D.ietf-v6ops-addcon]
              Velde, G., Popoviciu, C., Chown, T., Bonness, O., and C.
              Hahn, "IPv6 Unicast Address Assignment Considerations",
              draft-ietf-v6ops-addcon-10 (work in progress),
              September 2008.

   [I-D.miyata-v6ops-snatpt]
              Miyata, H. and M. Endo, "sNAT-PT: Simplified Network
              Address Translation - Protocol Translation",
              draft-miyata-v6ops-snatpt-02 (work in progress),
              September 2008.

   [I-D.venaas-behave-mcast46]
              Venaas, S., "An IPv4 - IPv6 multicast translator",
              draft-venaas-behave-mcast46-00 (work in progress),
              December 2008.

   [I-D.xli-behave-ivi]
              Li, X., Bao, C., Chen, M., Zhang, H., and J. Wu, "The
              CERNET IVI Translation Design and Deployment for the IPv4/
              IPv6  Coexistence and Transition", draft-xli-behave-ivi-02
              (work in progress), June 2009.

   [I-D.xli-behave-v4v6-prefix]
              Bao, C., Baker, F., and X. Li, "IPv4/IPv6 Translation
              Prefix Recommendation", draft-xli-behave-v4v6-prefix-00
              (work in progress), April 2009.



Baker, et al.            Expires January 6, 2010               [Page 28]


Internet-Draft     Framework for IPv4/IPv6 Translation         July 2009


   [RFC1918]  Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and
              E. Lear, "Address Allocation for Private Internets",
              BCP 5, RFC 1918, February 1996.

   [RFC1923]  Halpern, J. and S. Bradner, "RIPv1 Applicability Statement
              for Historic Status", RFC 1923, March 1996.

   [RFC2428]  Allman, M., Ostermann, S., and C. Metz, "FTP Extensions
              for IPv6 and NATs", RFC 2428, September 1998.

   [RFC2765]  Nordmark, E., "Stateless IP/ICMP Translation Algorithm
              (SIIT)", RFC 2765, February 2000.

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

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

   [RFC3142]  Hagino, J. and K. Yamamoto, "An IPv6-to-IPv4 Transport
              Relay Translator", RFC 3142, June 2001.

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

   [RFC3493]  Gilligan, R., Thomson, S., Bound, J., McCann, J., and W.
              Stevens, "Basic Socket Interface Extensions for IPv6",
              RFC 3493, February 2003.

   [RFC3879]  Huitema, C. and B. Carpenter, "Deprecating Site Local
              Addresses", RFC 3879, September 2004.

   [RFC4192]  Baker, F., Lear, E., and R. Droms, "Procedures for
              Renumbering an IPv6 Network without a Flag Day", RFC 4192,
              September 2005.

   [RFC4193]  Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast
              Addresses", RFC 4193, October 2005.

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

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

   [RFC4862]  Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless



Baker, et al.            Expires January 6, 2010               [Page 29]


Internet-Draft     Framework for IPv4/IPv6 Translation         July 2009


              Address Autoconfiguration", RFC 4862, September 2007.

   [RFC4864]  Van de Velde, G., Hain, T., Droms, R., Carpenter, B., and
              E. Klein, "Local Network Protection for IPv6", RFC 4864,
              May 2007.

   [RFC4941]  Narten, T., Draves, R., and S. Krishnan, "Privacy
              Extensions for Stateless Address Autoconfiguration in
              IPv6", RFC 4941, September 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.

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

   [RFC5214]  Templin, F., Gleeson, T., and D. Thaler, "Intra-Site
              Automatic Tunnel Addressing Protocol (ISATAP)", RFC 5214,
              March 2008.


Authors' Addresses

   Fred Baker (editor)
   Cisco Systems
   Santa Barbara, California  93117
   USA

   Phone: +1-408-526-4257
   Fax:   +1-413-473-2403
   Email: fred@cisco.com


   Xing Li (editor)
   CERNET Center/Tsinghua University
   Room 225, Main Building, Tsinghua University
   Beijing,   100084
   China

   Phone: +86 62785983
   Email: xing@cernet.edu.cn









Baker, et al.            Expires January 6, 2010               [Page 30]


Internet-Draft     Framework for IPv4/IPv6 Translation         July 2009


   Congxiao Bao (editor)
   CERNET Center/Tsinghua University
   Room 225, Main Building, Tsinghua University
   Beijing,   100084
   China

   Phone: +86 62785983
   Email: congxiao@cernet.edu.cn


   Kevin Yin (editor)
   Cisco Systems
   No. 2 Jianguomenwai Ave, Chaoyang District
   Beijing,   100022
   China

   Phone: +86-10-8515-5094
   Email: kyin@cisco.com

































Baker, et al.            Expires January 6, 2010               [Page 31]


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