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

Versions: 00 01 02 03

Network Working Group                                             Y. Cui
Internet-Draft                                                     M. Xu
Intended status: Standards Track                                 S. Wang
Expires: January 8, 2010                                           J. Wu
                                                                   X. Li
                                                     Tsinghua University
                                                                 C. Metz
                                                     Cisco Systems, Inc.
                                                            July 7, 2009


                 IPv4/IPv6 Coexistence Framework (PET)
                       draft-cui-softwire-pet-00

Status of this Memo

   This Internet-Draft is submitted to IETF in full conformance with the
   provisions of BCP 78 and BCP 79.  This document may contain material
   from IETF Documents or IETF Contributions published or made publicly
   available before November 10, 2008.  The person(s) controlling the
   copyright in some of this material may not have granted the IETF
   Trust the right to allow modifications of such material outside the
   IETF Standards Process.  Without obtaining an adequate license from
   the person(s) controlling the copyright in such materials, this
   document may not be modified outside the IETF Standards Process, and
   derivative works of it may not be created outside the IETF Standards
   Process, except to format it for publication as an RFC or to
   translate it into languages other than English.

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

Copyright Notice



Cui, et al.              Expires January 8, 2010                [Page 1]


Internet-Draft        PET for IPv4/IPv6 Coexistence            July 2009


   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.











































Cui, et al.              Expires January 8, 2010                [Page 2]


Internet-Draft        PET for IPv4/IPv6 Coexistence            July 2009


Abstract

   IPv6 offers significant advantages over IPv4.  However IPv4 and IPv6
   protocols are expected to coexist during a long period.  Currently,
   there are many IPv4/IPv6 transition/coexistence technologies, which
   can be generally devided into two kinds: translation and tunneling.
   In some typical transition scenarios, both tunneling and translation
   are needed.  However, either translation or tunneling has limitation
   and application scope.  In addition to the IP versions of source
   networks and destination networks, the IP version of transport
   network (the middle part along end-to-end path) also plays an
   important role during IPv4/IPv6 transition/coexistence.

   Therefore, we need to decide which transition methods should be used
   in different typical transition scenarios and how transition and
   tunneling collaborate for solving transition/coexistence problems.
   This draft presents an IPv4-IPv6 transition/coexistence framework
   named PET (short for Prefixing, Encapsulation and Translation), which
   is a network side solution.  PET includes fundamental elements needed
   in transition scenarios, which provides the flexibility for network
   operators to decide the proper transition technology.  In addition,
   this draft also addresses how to deploy PETs and analyze the
   advantages and disadvantages of typical transition technologies that
   PET may adopt.



























Cui, et al.              Expires January 8, 2010                [Page 3]


Internet-Draft        PET for IPv4/IPv6 Coexistence            July 2009


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  5
   2.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  6
   3.  Fundamental requirements of IPv4-IPv6 transition methods . . .  7
   4.  Descriptions of PET  . . . . . . . . . . . . . . . . . . . . .  8
   5.  PET Framework  . . . . . . . . . . . . . . . . . . . . . . . . 10
     5.1.  IPv4->IPv6->IPv4 . . . . . . . . . . . . . . . . . . . . . 10
     5.2.  IPv4->IPv6->IPv6 . . . . . . . . . . . . . . . . . . . . . 11
     5.3.  IPv6->IPv6->IPv4 . . . . . . . . . . . . . . . . . . . . . 13
     5.4.  IPv6->IPv4->IPv6 . . . . . . . . . . . . . . . . . . . . . 14
     5.5.  IPv4->IPv4->IPv6 . . . . . . . . . . . . . . . . . . . . . 14
     5.6.  IPv6->IPv4->IPv6 . . . . . . . . . . . . . . . . . . . . . 15
   6.  Implementation issues  . . . . . . . . . . . . . . . . . . . . 16
   7.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 17
   8.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 18
     8.1.  Normative References . . . . . . . . . . . . . . . . . . . 18
     8.2.  Informative References . . . . . . . . . . . . . . . . . . 18
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 19
































Cui, et al.              Expires January 8, 2010                [Page 4]


Internet-Draft        PET for IPv4/IPv6 Coexistence            July 2009


1.  Introduction

   Recently more and more IPv6 networks have been deployed, especially
   IPv6 backbone networks, while the existing IPv4 networks still carry
   the major network traffic and hold the major network services and
   applications, though facing serious address space problem and other
   problems.  It has been agreed that IPv4 and IPv6 networks will co-
   exist for a long term.  This leads to the need of IPv4-IPv6
   transition methods.

   There are many methods for IPv4-IPv6 transition, which can be roughly
   classified into two groups: translation and tunneling.  Translation
   is a technology that translates semantic between IPv4 and IPv6.
   There are many translation methods, such as SIIT [RFC 2765], NAT-PT
   [RFC 2766], BIS [RFC 2767], SOCKS64 [RFC 3089], BIA [RFC 3338], IVI
   [draft-ietf-xli-behave-ivi-02] and so on.  Translation technology can
   realize interworking between IPv4 and IPv6 directly, however, it will
   lead to information loss.

   Tunneling is a technology to encapsulate packets from a different
   protocol within the protocol of the route that delivers it to the
   target network.  There are many tunneling methods, such as IP-in-IP
   tunnel [RFC 2893, RFC 4213], GRE tunnel [RFC 1702], 6to4 tunnel [RFC
   2893], 6over4 tunnel [RFC 2529], softwire transition technology [RFC
   5565] and so on.  Tunneling technology can not realize the
   interworking between IPv4 and IPv6 directly.  It can only deal with
   the scenario where two IPv4 (IPv6) nodes want to communicate with
   each other through IPv6 (IPv4) network.  However, tunneling
   technology has several advantages, besides no information loss, it
   can be realized easily by hardware, and does not introduce routing
   information into a network with different address family.

   In some typical transition scenarios, both tunneling and translation
   are needed.  However, as described above, either translation or
   tunneling has limitation and application scope.  In addition, besides
   IP version of source, middle and destination network, the network
   property (a regular edge network or a backbone) has key impact on
   system performance.  Therefore, we need to decide which transition
   method should be used in some typical transition scenarios and how
   transition and tunneling collaborate for solving transition problems.
   This draft presents an IPv4-IPv6 transition framework, which is a
   network side transition solution.  It introduces a toolbox named PET
   (short for Prefixing, encapsulation and translation) to solve IPv4-
   IPv6 transition.  PET includes fundamental elements needed in
   transition scenarios, which provides the flexibility for network to
   decide the proper transition methods.  In addition, this draft also
   addresses how to deploy PETs and analyze the advantages and
   disadvantages of all transition methods that PET may adopt.



Cui, et al.              Expires January 8, 2010                [Page 5]


Internet-Draft        PET for IPv4/IPv6 Coexistence            July 2009


2.  Terminology

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
   NOT","SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in
   this document are to be interpreted as described in [RFC2119].














































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


Internet-Draft        PET for IPv4/IPv6 Coexistence            July 2009


3.  Fundamental requirements of IPv4-IPv6 transition methods

   There are two main IPv4-IPv6 transition scenarios.  One is to connect
   several edge networks with the same address family across a transit
   core network with another address family; the other scenario is to
   make hosts with one address family capable of directly communicating
   with hosts with the other address family.  We call the first scenario
   heterogeneous crossing.  The scenario where two IPv4 (IPv6) nodes
   want to communicate with each other through IPv6 (IPv4) network
   belongs to heterogeneous crossing.  We call the second scenario
   heterogeneous direct-connection.  The scenario where an IPv4 (IPv6)
   node wants to directly communicate with an IPv6 (IPv4) node belongs
   to heterogeneous direct-connection.

   In fact, most IPv4-IPv6 transition scenarios can be viewed as the
   combination of heterogeneous crossing and direct-connection.  Hence,
   the fundamental transition elements needed in heterogeneous crossing
   and direct-connection are those needed in most IPv4-IPv6 transition
   scenarios.

   In heterogeneous crossing scenario, tunneling technology can be used
   to transmit IPv4 (IPv6) packets through IPv6 (IPv4) networks.  In
   addition, through twice translations, IPv4 (IPv6) packets can also be
   transmitted through IPv6 (IPv4) networks in heterogeneous crossing
   scenario.  In heterogeneous direct-connection scenario, when IPv4
   (IPv6) nodes want to communicate with IPv6 (IPv4) nodes directly, it
   can only use translation technology.

   In addition, when adopting tunneling for supporting IPv4/IPv6
   interworking, some control operations involved with subnet prefix
   should be done beforehand.  These operations include prefix
   announcement, tunnel endpoint discovery, the selection of tunnel
   endpoint and tunnel belonging to the same tunnel endpoint, tunnel
   configuration, and so on.  Similarly, when adopting translation
   method for supporting IPv4/IPv6 interworking, some control operations
   involved with subnet prefix also should be done in advance.  These
   operations include the establishment of address mapping mechanism,
   prefix configuration and so on.  We call these control operations
   involved with subnet prefix prefixing.

   In conclusion, there are three fundamental elements needed in IPv4-
   IPv6 transition scenarios, i.e. prefixing, encapsulation and
   translation.  To realize a framework in network side for IPv4/IPv6
   translation, this draft introduces a toolbox named PET which includes
   the above fundamental elements.  The detailed descriptions are given
   in section 4.





Cui, et al.              Expires January 8, 2010                [Page 7]


Internet-Draft        PET for IPv4/IPv6 Coexistence            July 2009


4.  Descriptions of PET

   PET is a smart transition toolbox supporting IPv4/IPv6 inter-working.
   It can deal with the heterogeneous crossing and direct-connection
   scenarios.  Because all IPv4-IPv6 transition scenarios can be viewed
   as the combination of the heterogeneous crossing and direct-
   connection, the PET-based transition method is a generic solution for
   IPv4/IPv6 transition.  PET toolbox has the following functions:

   P: representing prefixing.  Prefixing includes all transition
   operations of control plane involved with subnet prefix.

   In detail, in tunneling technology, prefixing includes prefix
   announcement, tunnel endpoint discovery, the selection of tunnel
   endpoint and tunnel belonging to the same tunnel endpoint, and so on.
   For example, in softwire transition technology, the IPv6 prefix and
   IPv4 next-hop mapping information should be announced out through
   extended MP-BGP (Multi-protocol BGP) signaling beforehand.  Based on
   this prefixing operation, the automatic 4over6 tunnels can be
   established.  In translation technology, prefixing includes the
   establishment of address mapping mechanism, prefix configuration and
   so on.  For example, in IVI-based translation scheme, the global IPv6
   prefix should be configured in an autonomous domain (AS) beforehand,
   to form the global IVI address, thus realizing the stateless
   translation.

   E: representing encapsulation.  E includes all tunneling operations
   of data plane, such as encapsulation, decapsulation and maximum
   transmission unit (MTU) processing and so on.  Through this
   operation, packets from IPv6 (IPv4) network are encapsulated on the
   PET toolbox and sent across IPv4 (IPv6) backbone to another IPv6
   (IPv4) network according to the mappings stored on the PET box.

   T: representing translation.  It includes all translation operations
   of data plane, such as address mapping and protocol translation, MTU
   processing.

   Address mapping is to map IPv4 addresses to IPv6 addresses, and vice
   versa.  Based on address mapping, packets can be translated from one
   address family to another.  IPv4 and IPv6 are not directly
   compatible, so programs and systems designed on one standard can not
   communicate with those designed to the other.  Hence we need protocol
   translation.  Here, protocol translation includes IP layer
   translation and application layer translation.  Through protocol
   translation, the semantic of IP layer and application layer of an
   IPv4 packet is equivalent with that of the translated IPv6 packet and
   vice versa.  In addition, to implement translation, PET may
   collaborate with the domain name system (DNS).



Cui, et al.              Expires January 8, 2010                [Page 8]


Internet-Draft        PET for IPv4/IPv6 Coexistence            July 2009


   The basic idea of our solution is to deploy several PET toolboxes
   between backbone network and customer networks.  The following
   section will discuss how PET deals with different IPv4/IPv6
   translation scenarios in detail.















































Cui, et al.              Expires January 8, 2010                [Page 9]


Internet-Draft        PET for IPv4/IPv6 Coexistence            July 2009


5.  PET Framework

   Figure 1 shows the overall topology of PET framework, which uses PET
   boxes between IPv6 backbone and IPv4 customer networks.  In this
   topology, an IPv6 backbone is connected with several customer
   networks including IPv4 backbone, IPv4 virtual private networks
   (VPNs), IPv6 network and dual stack networks.

                           +------------------+
                           |   IPv4 backbone  |
                           |                  |
                           +------------------+
                               |           |
                               |           |
                          +--------+   +--------+
                          |  PET   |   |  PET   |
                       +--|        |---|        |--+
                       |  +--------+   +--------+  |
                       |                           |
       +--------+   +--------+                   +--------+  +-------+
       | IPv4   |   |  PET   |  IPv6 backbone    |  PET   |  | IPv4  |
       |network |___|        |                   |        |__|network|
       +--------+   +--------+                   +--------+  +-------+
                        |                           |
                        |  +--------+   +--------+  |
                        +--|  PET   |---|  PET   |--+
                           |        |   |        |
                           +--------+   +--------+
                               |     \ /    |
                               |      X     |
                               |     / \    |
                           +--------+   +--------+
                           |  IPv6  |   |  IPv4/ |
                           |        |   |  IPv6  |
                           | Network|   | Network|
                           +--------+   +--------+

   Figure 1 Topology of PET Framework

   For different transition scenarios, PET can provide different
   functionalities to ensure the inter-working of IPv4/IPv6 network.  We
   will analyze how PET works in some typical scenarios in the following
   subsections.

5.1.  IPv4->IPv6->IPv4

   This is the scenario where an IPv4 network wants to talk with another
   IPv4 network across IPv6 backbone.  There are two methods for PET to



Cui, et al.              Expires January 8, 2010               [Page 10]


Internet-Draft        PET for IPv4/IPv6 Coexistence            July 2009


   handle this scenario.  One is translation and the other is tunneling.
   If PET adopts translation method, we need twice translations.  In
   detail, an IPv4 packet need be translated by PET into an IPv6 packet
   for being delivered through IPv6 backbone.  When this packet arrives
   at another PET, it will be translated into an IPv4 packet again for
   being delivered through IPv4 network.

   The other method for IPv4-IPv6-IPv4 scenario is tunneling.  This
   requires a PET to encapsulate the packets and send them to the tunnel
   endpoint PET across IPv6 backbone.  When these packets arrive at the
   tunnel endpoint PET, they are de-capsulated and sent to IPv4 customer
   networks.

   Because translation method will incur information loss, PET prefers
   to use tunneling technology to handle IPv4-IPv6-IPv4 scenario.  Its
   operations are shown in Figure 2.

  +-------------+   +-------------+      +-------------+    +-------------+
  |IPv4 customer|   |     PET     |      |     PET     |    |IPv4 customer|
  |   network   |   |             |      |             |    |   network   |
  +-------------+   +-------------+      +-------------+    +-------------+
         |                 |                    |                  |
         |---forwarding--->|                    |                  |
         |           encapsulation              |                  |
         |                 |                    |                  |
         |                 |-------tunneling--->|                  |
         |                 |                    |                  |
         |                 |              decapsulation            |
         |                 |                    |------forwarding->|
         |                 |                    |                  |

   Figure 2 PET operations in IPv4-IPv6-IPv4 scenario

5.2.  IPv4->IPv6->IPv6

   This is the scenario where an IPv4 customer network wants to talk
   with an IPv6 customer network across IPv6 backbone.  There are two
   methods to deal with this scenario.  One is translation plus
   forwarding.  The other is tunneling plus translation.

   In the first method, when an IPv4 packet arrives at PET, it will be
   translated into an IPv6 packet and then sent to the IPv6 network
   through IPv6 backbone.  In the second method, when an IPv4 packet
   arrives at PET, it will be encapsulated as an IPv6 packet for being
   delivered through IPv6 backbone.  Once this packet arrives at the
   tunnel endpoint PET, it will be de-capsulated to the original IPv4
   packet and then be translated as an IPv6 packet to be delivered to
   the IPv6 customer network.



Cui, et al.              Expires January 8, 2010               [Page 11]


Internet-Draft        PET for IPv4/IPv6 Coexistence            July 2009


   If the IPv4 customer network is not an IPv4 backbone, PET prefers to
   adopt the first method because the complexity of second method is
   higher than that of the first method.  Its operation is shown in
   Figure 3.

  +-------------+   +-------------+      +-------------+    +-------------+
  |IPv4 customer|   |     PET     |      |     PET     |    |IPv6 customer|
  |   network   |   |             |      |             |    |   network   |
  +-------------+   +-------------+      +-------------+    +-------------+
         |                 |                    |                  |
         |-----forwarding->|                    |                  |
         |           translation                |                  |
         |                 |                    |                  |
         |                 |------forwarding--->|                  |
         |                 |                    |                  |
         |                 |                    |                  |
         |                 |                    |                  |
         |                 |                    |-----forwarding-->|
         |                 |                    |                  |

   Figure 3 PET operations in IPv4-IPv6-IPv6 scenario (IPv4 customer
   network is not a backbone)

   if the IPv4 customer network is a backbone, PET prefers to adopt the
   second method for the following reasons:

   i) Translation mechanism usually needs application level gateway
   (ALG), which is an application specific agent that allows an IPv6
   node to communicate with an IPv4 node and vice versa.  Backbone
   network requires hardware forwarding for high speed transmission.
   However, it is hard to use hardware to do the work of ALG.

   ii) To avoid single point of failure, several PETs usually be
   deployed among networks.  They improve performance and robustness
   using dynamic routing mechanism.  However, translation is a static
   process.  It is hard to use dynamic routing mechanism.

   iii) At last, some translation mechanisms, such as IVI-based scheme,
   require IPv4 routing information to be introduced into IPv6 backbone,
   which will increase the routing base size.  Based on the above
   analyses, PET refers to adopt the second method to deal with this
   scenario.  Its operations are shown in Figure 4.









Cui, et al.              Expires January 8, 2010               [Page 12]


Internet-Draft        PET for IPv4/IPv6 Coexistence            July 2009


   +-------------+   +-------------+      +-------------+    +-------------+
   |IPv4 customer|   |     PET     |      |     PET     |    |IPv6 customer|
   |   network   |   |             |      |             |    |   network   |
   +-------------+   +-------------+      +-------------+    +-------------+
          |                 |                    |                  |
          |----forwarding-->|                    |                  |
          |                 |                    |                  |
          |           encapsulation              |                  |
          |                 |------tunneling---->|                  |
          |                 |                    |                  |
          |                 |              decapsulation            |
          |                 |               translation             |
          |                 |                    |------forwarding->|
          |                 |                    |                  |

   Figure 4 PET operations in IPv4-IPv6-IPv6 scenario (IPv4 customer
   network is a backbone)

5.3.  IPv6->IPv6->IPv4

   This is the scenario where an IPv6 customer network wants to talk
   with an IPv4 customer network across IPv6 backbone.  In this
   scenario, when an IPv6 packet arrives at PET, it will be translated
   as an IPv4 packet and then the PET encapsulates it and sends it to
   the tunnel endpoint PET.  When the translated IPv4 packet arrives at
   the tunnel endpoint PET, it will be de-capsulated and sent to the
   IPv4 customer network.  The operations are shown in Figure 5.

   +-------------+   +-------------+      +-------------+    +-------------+
   |IPv6 customer|   |     PET     |      |     PET     |    |IPv4 customer|
   |   network   |   |             |      |             |    |   network   |
   +-------------+   +-------------+      +-------------+    +-------------+
        |                 |                    |                  |
        |---forwarding--->|                    |                  |
        |            translation               |                  |
        |           encapsulation              |                  |
        |                 |------tunneling---->|                  |
        |                 |                    |                  |
        |                 |                    |                  |
        |                 |              decapsulation            |
        |                 |                    |--forwarding----->|
        |                 |                    |                  |

   Figure 5 PET operations in IPv6-IPv6-IPv4 scenario







Cui, et al.              Expires January 8, 2010               [Page 13]


Internet-Draft        PET for IPv4/IPv6 Coexistence            July 2009


5.4.  IPv6->IPv4->IPv6

   This is the scenario where an IPv6 network wants to talk with another
   IPv6 network across IPv4 backbone.  This scenario is similar to IPv4-
   IPv6-IPv4 scenario.  Hence, PET prefers to use tunneling technology
   to handle this scenario.  Its operations are shown in Figure 6.

+-------------+   +-------------+      +-------------+    +-------------+
|IPv6 customer|   |     PET     |      |     PET     |    |IPv6 customer|
|   network   |   |             |      |             |    |   network   |
+-------------+   +-------------+      +-------------+    +-------------+
      |                 |                    |                  |
      |---forwarding--->|                    |                  |
      |           encapsulation              |                  |
      |                 |------tunneling---->|                  |
      |                 |                    |                  |
      |                 |                    |                  |
      |                 |              decapsulation            |
      |                 |                    |                  |
      |                 |                    |--forwarding----->|
      |                 |                    |                  |

   Figure 6 PET operations in IPv6-IPv4-IPv6 scenario

5.5.  IPv4->IPv4->IPv6

   This is the scenario where an IPv4 customer network wants to talk
   with an IPv6 customer network across IPv4 backbone.  This scenario is
   similar to IPv6-IPv6-IPv4 scenario.  Hence, PET adopts the similar
   method to deal with this scenario.  Its operations are shown in
   Figure 7.

   +-------------+   +-------------+      +-------------+    +-------------+
   |IPv4 customer|   |     PET     |      |     PET     |    |IPv6 customer|
   |   network   |   |             |      |             |    |   network   |
   +-------------+   +-------------+      +-------------+    +-------------+
          |                 |                    |                  |
          |---forwarding--->|                    |                  |
          |            translation               |                  |
          |           encapsulation              |                  |
          |                 |------tunneling---->|                  |
          |                 |                    |                  |
          |                 |              decapsulation            |
          |                 |                    |---forwarding---->|
          |                 |                    |                  |

   Figure 7 PET operations in IPv4-IPv4-IPv6 scenario




Cui, et al.              Expires January 8, 2010               [Page 14]


Internet-Draft        PET for IPv4/IPv6 Coexistence            July 2009


5.6.  IPv6->IPv4->IPv6

   This is the scenario where an IPv6 customer network wants to talk
   with an IPv4 customer network across IPv4 backbone.  This scenario is
   similar to IPv4-IPv6-IPv6 scenario.  Hence, PET adopts the similar
   method to deal with this scenario.  Its operations are shown in
   Figures 8 and 9.

  +-------------+   +-------------+      +-------------+    +-------------+
  |IPv6 customer|   |     PET     |      |     PET     |    |IPv4 customer|
  |   network   |   |             |      |             |    |   network   |
  +-------------+   +-------------+      +-------------+    +-------------+
         |                 |                    |                  |
         |--forwarding---->|                    |                  |
         |           translation                |                  |
         |                 |                    |                  |
         |                 |------forwarding--->|                  |
         |                 |                    |                  |
         |                 |                    |                  |
         |                 |                    |                  |
         |                 |                    |----forwarding--->|
         |                 |                    |                  |

   Figure 8 PET operations in IPv6-IPv4-IPv4 scenario (IPv6 customer
   network is not a backbone)

   +-------------+   +-------------+      +-------------+    +-------------+
   |IPv6 customer|   |     PET     |      |     PET     |    |IPv4 customer|
   |   network   |   |             |      |             |    |   network   |
   +-------------+   +-------------+      +-------------+    +-------------+
          |                 |                    |                  |
          |----forwarding-->|                    |                  |
          |                 |                    |                  |
          |           encapsulation              |                  |
          |                 |------tunneling---->|                  |
          |                 |                    |                  |
          |                 |                    |                  |
          |                 |              decapsulation            |
          |                 |               translation             |
          |                 |                    |---forwarding---->|
          |                 |                    |                  |

   Figure 9 PET operations in IPv6-IPv4-IPv4 scenario (IPv6 customer
   network is a backbone)







Cui, et al.              Expires January 8, 2010               [Page 15]


Internet-Draft        PET for IPv4/IPv6 Coexistence            July 2009


6.  Implementation issues

   In this draft, we recommend how to use tunneling and translation
   method in each scenario using PETs.  However, we do not restrict the
   specific tunneling and translation technology that PET adopts.  It
   can be any transition technology, such as SIIT [RFC 2765], NAT-PT
   [RFC2766], BIS [RFC 2767], SOCKS64 [RFC 3089], BIA [RFC 3338],
   IVI[draft-ietf-xli-behave-ivi-02], iP-in-IP tunnel [RFC 2893, RFC
   4213],GRE tunnel [RFC 1702], 6to4 tunnel [RFC 2893], 6over4 tunnel
   [RFC2529], softwire transition technology [RFC 5565] and so on.

   In addition, this draft does not address how PET collaborates with
   DNS, ALG and other transition devices, as well as inter domain
   transition problems, which will discuss in the next version.





































Cui, et al.              Expires January 8, 2010               [Page 16]


Internet-Draft        PET for IPv4/IPv6 Coexistence            July 2009


7.  Acknowledgements

   The authors would like to thank Lixia Zhang for her valuable comments
   on this draft.















































Cui, et al.              Expires January 8, 2010               [Page 17]


Internet-Draft        PET for IPv4/IPv6 Coexistence            July 2009


8.  References

8.1.  Normative References

   [RFC1702]  Hanks, S., Li, T., Farinacci, D., and P. Traina, "Generic
              Routing Encapsulation over IPv4 networks", RFC 1702,
              October 1994.

   [RFC2529]  Carpenter, B. and C. Jung, "Transmission of IPv6 over IPv4
              Domains without Explicit Tunnels", RFC 2529, March 1999.

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

   [RFC2767]  Tsuchiya, K., HIGUCHI, H., and Y. Atarashi, "Dual Stack
              Hosts using the "Bump-In-the-Stack" Technique (BIS)",
              RFC 2767, February 2000.

   [RFC2893]  Gilligan, R. and E. Nordmark, "Transition Mechanisms for
              IPv6 Hosts and Routers", RFC 2893, August 2000.

   [RFC3089]  Kitamura, H., "A SOCKS-based IPv6/IPv4 Gateway Mechanism",
              RFC 3089, April 2001.

   [RFC3338]  Lee, S., Shin, M-K., Kim, Y-J., Nordmark, E., and A.
              Durand, "Dual Stack Hosts Using "Bump-in-the-API" (BIA)",
              RFC 3338, October 2002.

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

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

8.2.  Informative References

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






Cui, et al.              Expires January 8, 2010               [Page 18]


Internet-Draft        PET for IPv4/IPv6 Coexistence            July 2009


Authors' Addresses

   Yong Cui
   Tsinghua University
   Department of Computer Science, Tsinghua University
   Beijing  100084
   P.R.China

   Phone: +86-10-6278-5822
   Email: cy@csnet1.cs.tsinghua.edu.cn


   Mingwei Xu
   Tsinghua University
   Department of Computer Science, Tsinghua University
   Beijing  100084
   P.R.China

   Phone: +86-10-6278-5822
   Email: xmw@csnet1.cs.tsinghua.edu.cn


   Shengling Wang
   Tsinghua University
   Department of Computer Science, Tsinghua University
   Beijing  100084
   P.R.China

   Phone: +86-10-6278-5822
   Email: slwang@csnet1.cs.tsinghua.edu.cn


   Jianping Wu
   Tsinghua University
   Department of Computer Science, Tsinghua University
   Beijing  100084
   P.R.China

   Phone: +86-10-6278-5983
   Email: jianping@cernet.edu.cn











Cui, et al.              Expires January 8, 2010               [Page 19]


Internet-Draft        PET for IPv4/IPv6 Coexistence            July 2009


   Xing Li
   Tsinghua University
   Department of Electronic Engineering, Tsinghua University
   Beijing  100084
   P.R.China

   Phone: +86-10-6278-5983
   Email: xing@cernet.edu.cn


   Chris Metz
   Cisco Systems, Inc.
   3700 Cisco Way
   San Jose, Ca.  95134
   USA

   Email: chmetz@cisco.com


































Cui, et al.              Expires January 8, 2010               [Page 20]


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