Network Working Group                                             Y. Cui
Internet-Draft                                                     M. Xu
Intended status: Standards Track                                 S. Wang
Expires: April 4, 2010                                             X. Li
                                                                   J. Wu
                                                     Tsinghua University
                                                                 C. Metz
                                                           Cisco systems
                                                               Oct. 2009


                   PET for IPv6 to IPv4 communication
                    draft-cui-softwire-pet64-00.txt

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














Cui, et al.               Expires April 4, 2010                 [Page 1]


Internet-Draft                    pet64                        Oct. 2009


Abstract

   This draft offers a solution using PET for the scenario that an IPv6-
   only client initiates a communication to an IPv4-only server through
   IPv6 backbone.  In this communication scenario,translation is needed.
   However, translation work has requirements on the performance
   (hardware or software) of PET and the size of network that the PET is
   charge for.  This draft introduces the concept of translation
   preference to express the PET's willing of performing translation
   according to some policies the network administrators constitute.
   Through exchanging the Translation preference among PETs, PET
   framework can decide which PET should act as a translator.  In
   addition, this draft also gives how the PET collaborates with DNS to
   solve the IPv6-to-IPv4 communication problem.


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3

   2.  PET Framework in IPv6-toIPv4 communication scenario  . . . . .  4

   3.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  5

   4.  IPv6-to-IPv4 communication in PET framework  . . . . . . . . .  7
     4.1.  IPv6-to-IPv4 communication scenario  . . . . . . . . . . .  7
     4.2.  IPv6-to-IPv4 communication using PETs  . . . . . . . . . .  8
     4.3.  PET and DNS collaboration for IPv6-to-IPv4
           communication  . . . . . . . . . . . . . . . . . . . . . .  9
       4.3.1.  PET1 Translation scenario  . . . . . . . . . . . . . . 10
       4.3.2.  PET2 Translation scenario  . . . . . . . . . . . . . . 11
     4.4.  Other considerations . . . . . . . . . . . . . . . . . . . 12

   5.  Filtering  . . . . . . . . . . . . . . . . . . . . . . . . . . 13

   6.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 14
     6.1.  Normative References . . . . . . . . . . . . . . . . . . . 14
     6.2.  Informative References . . . . . . . . . . . . . . . . . . 14

   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15













Cui, et al.               Expires April 4, 2010                 [Page 2]


Internet-Draft                    pet64                        Oct. 2009


1.  Introduction

   IPv6 offers significant advantages over IPv4, however it will take a
   long time to replace IPv4 with IPv6.  Therefore, these two protocols
   are expected to coexist during the transition period.

   On one hand, because it is difficult to update IPv4 applications, a
   lot of IPv6-only client will want to visit IPv4-only servers to enjoy
   the IPv4 applications.  On the other hand, to promote the transition
   from IPv4 and to propel IPv6 development, some countries are
   establishing large-scale pure IPv6 backbone networks.  So it is a key
   problem that an IPv6 client dwelled in an IPv6 network can
   efficiently communicate with an IPv4 server dwelled in an IPv4
   network through IPv6 backbone.

   This draft proposes a solution that using PET framework
   [I-D.draft-cui-softwire-PET-framework-00]to solve the problem that an
   IPv6-only client initiates a communication to an IPv4-only server
   through IPv6 backbone (we call this communication scenario is IPv6-
   to-IPv4 in the following draft).

   In IPv6-to-IPv4 communication scenario, translation is inevitably
   adopted.  Hence, which PET should act as a translator is a key
   problem to be considered.  The reason is described as follows:
   Translation mechanism usually needs application level gateway (ALG),
   which is an application specific agent that allows an IPv6 host to
   communicate with an IPv4 host and vice versa.  However, it is hard to
   use hardware to do the work of ALG.  Thus, translation has
   requirements on the performance (including hardware performance and
   software performance) of PET and the network size the PET charges
   for.  Usually, if a PET's performance is higher and the network's
   size which the PET charges for is smaller, the PET is supposed to
   perform translation, and vice versa.

   In this draft, we firstly give the PET framework in IPv6-to-IPv4
   communication scenario, based on which this draft discusses two
   communication modes in 6to4 scenario(different PET perform
   translation in different modes).  This draft introduces the concept
   of translation preference to express the PET's willing of performing
   translation according to some policies the network administrators
   constitute.  Through exchanging the Translation preference among
   PETs, PET framework can decide the communication mode.  In addition,
   this draft also gives how the PET collaborates with DNS to solve the
   IPv6-to-IPv4 communication problem.  At last, this draft describes
   the filtering of PET.






Cui, et al.               Expires April 4, 2010                 [Page 3]


Internet-Draft                    pet64                        Oct. 2009


2.  PET Framework in IPv6-toIPv4 communication scenario

   Figure 1 shows the PET framework in IPv6-to-IPv4 scenario, which uses
   PET boxes between IPv6 backbone and its client networks.  The client
   networks include IPv4 network, IPv4 virtual private networks (VPNs),
   IPv6 network and dual stack networks.  In this draft, we only
   consider the scenario that one PET is charge of one client network.
   The scenario that Multiple PETs charge for one client network is out
   of consideration.

                             +------------------+
                             |                  |
                             |   IPv6 network   |
                             |                  |
                             +------------------+
                                      |
                                +-----------+
                                |    PET    |
                                |           |
                                +-----------+
                                       |
                         +-----------------------------+
                         |                             |
        +--------+   +--------+                   +--------+  +-------+
        | IPv6   |   |        |  IPv6 backbone    |        |  | IPv4  |
        |network |___|  PET   |                   |  PET   |__|network|
        |        |   |        |                   |        |  |       |
        |        |   +--------+                   +--------+  |       |
        +--------+       |                             |      +-------+
                         +-----------------------------+
                                       |
                                 +-----------+
                                 |    PET    |
                                 |           |
                                 +-----------+
                                       |
                             +------------------+
                             |                  |
                             |   IPv4 network   |
                             |                  |
                             +------------------+




              Figure 1: PET Framework in IPv6-to-IPv4 scenario







Cui, et al.               Expires April 4, 2010                 [Page 4]


Internet-Draft                    pet64                        Oct. 2009


3.  Terminology

   This section provides the definitions for all the terms used in
   draft.

   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 RFC 2119 [RFC2119].

   The following terms are used in this document:

   PET: a smart transition toolbox supporting IPv4/IPv6 inter-working.
   PET toolbox has the following functions:

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

   E: representing encapsulation.  E includes all tunneling operations
   of data plane, such as encapsulation, decapsulation and maximum
   transmission unit (MTU) processing and so on.

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

   A PET connects the IPv6 backbone to its client networks.  It is a
   dual stack gateway.  PETs can exchange their prefixes and Translation
   Preferences through softwire signaling [RFC 5565].When collaborating
   with DNSs, a PET charging for an IPv4 network MUST keep one-to-one
   mapping between the DNS's IPv4 address and its IPv6 mapping address.

   Translation Preference (TP): is a value set in a PET to show the
   preference degree that the PET would like to translate a packet.  The
   higher is the TP, the higher probability that the PET translates
   packets.

   PET prefix: a prefix of a network which a PET is charge for.  Through
   PET prefix, an IPv6 PET address is constructed.  PET prefixes should
   be announced by PETs through softwire signaling [RFC 5565], based on
   that other PETs can differentiate an IPv6 PET address and a regular
   IPv6 address and judge where a packet comes from or is destined to.

   IPv6 PET address: an IPv6 address constructed by concatenating the
   /96 prefix of the PET that is charging for the IPv4 network and the
   IPv4 address assigned to the IPv4 server.

   IPv6 mapping address: the IPv6 address representing the IPv4 target.
   In IPv6-to-IPv4 scenario, an IPv4 target's IPv6 mapping address is



Cui, et al.               Expires April 4, 2010                 [Page 5]


Internet-Draft                    pet64                        Oct. 2009


   its IPv6 PET address.

   IPv4 mapping address: the IPv4 address representing the IPv6 target.

   DNS4: a DNS deployed in IPv4 network.  It has an IPv6 mapping
   address.  DNS4 SHOULD support for DNSSEC and some forms of IPsec.  A
   DNS4 SHOULD keep the DNS6's IPv4 mapping addresses.  This information
   MAY be set by static configuration.

   DNS6: a DNS deployed in an IPv6 network (including IPv6 backbone and
   IPv6 client networks).  DNS6 SHOULD support for DNSSEC and some forms
   of IPsec.It has an IPv4 mapping address.  A DNS4 SHOULD keep the
   DNS6's IPv4 mapping addresses.  This information MAY be set by static
   configuration.





































Cui, et al.               Expires April 4, 2010                 [Page 6]


Internet-Draft                    pet64                        Oct. 2009


4.  IPv6-to-IPv4 communication in PET framework

4.1.  IPv6-to-IPv4 communication scenario

   Figure 2 shows one kind of IPv6-to-IPv4 communication scenario.  A
   PET connects the IPv6 backbone to its client network, along with the
   deployment of a DNS6 in the IPv6 client network and a DNS4 in the
   IPv4 client network.



  +---------------+         +---------------+         +---------------+
  | IPv6 network  | +-----+ |               | +-----+ |IPv4 network   |
  |   +------+    |_| PET1|_|   IPv6 core   |_| PET2|_|  +------+     |
  |   | DNS6      | +-----+ |    network    | +-----+ |  | DNS4 |     |
  |   +------+    |         |               |         |  +------+     |
  +---------------+         +---------------+         +---------------+


   Figure 2: IPv6-to-IPv4 communication scenario (DNS6 deployed in
   client network

   Figure 3 shows the other kind of IPv6-to-IPv4 communication scenario.
   A PET connects the IPv6 backbone to its client network, along with
   the deployment of a DNS6 in the IPv6 backbones and a DNS4 in the IPv4
   client network.

   Of course, there can be multiple DNSs in the client networks though
   we only discuss the scenario that one DNS deployed in one client
   network.

   +---------------+         +---------------+          +---------------+
   | IPv6 network  |         |  IPv6 core    |          | IPv4 network  |
   |               | +-----+ |   network     | +------+ |               |
   |               |_| PET1|_|   +------+    |_| PET2 |_|  +------+     |
   |               | +-----+ |   | DNS6 |    | +------+ |  | DNS4 |     |
   |               |         |   +------+    |          |  +------+     |
   +---------------+         +---------------+          +---------------+




   Figure 3: IPv6-to-IPv4 communication scenario (DNS6 deployed in core
   network)

   PET has two interfaces, an IPv4 (IPv6) interface connects to the IPv4
   (IPv6) client network, and an IPv6 interface connects to the IPv6
   backbone.



Cui, et al.               Expires April 4, 2010                 [Page 7]


Internet-Draft                    pet64                        Oct. 2009


   Each PET should know the existence each other, and they communicate
   the following information through softwire signaling:

   i) PET prefix.  Through PET prefix announcement, PETs can
   differentiate an IPv6 PET address and a regular IPv6 address, and
   judge where the packet comes from or is destined to.

   ii)TP.  Through TP announcement, which PET performs translation is
   decided.

   When collaborating with DNS, a PET charging for an IPv4 network MUST
   keep one-to-one mapping between the DNS's IPv4 address and its IPv6
   mapping address.

4.2.  IPv6-to-IPv4 communication using PETs

   When an IPv6 initiator wants to communicate with an IPv4 host,
   translation is inevitably adopted.  Hence, which PET should act as a
   translator is a key problem to be considered.  The reason is
   described as follows: Translation mechanism usually needs ALG, which
   is an application specific agent that allows an IPv6 host to
   communicate with an IPv4 host and vice versa.  However, it is hard to
   use hardware to do the work of ALG.  Thus, translation has
   requirements on the performance (including hardware performance and
   software performance) of PET and the network size the PET charges
   for.  Usually, if a PET's performance is higher and the network's
   size which the PET charges for is smaller, the PET is supposed to
   perform translation, and vice versa.

   According to the requirements that performing translation on
   different PETs, there are two modes of IPv6-to-IPv4 communication
   using PETs as shown in Figures 4 and 5 respectively.  In the first
   mode, when an IPv6 packet arrives at PET 1, it will be translated
   into an IPv4 packet and then sent to PET2 using softwire mechanism
   (i.e. 4 over 6 method) [RFC 5565] through IPv6 backbone.  At last,
   this IPv4 packet will be forwarded directly to the IPv4 host in IPv4
   client network.














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


Internet-Draft                    pet64                        Oct. 2009


          +-------------+   +-----+ +--------+ +-----+    +-------------+
          |IPv6 client  |   | PET1| | IPv6   | |PET2 |    |IPv4 client  |
          |   network   |   |     | |backbone| |     |    |   network   |
          +-------------+   +-----+ +--------+ +-----+    +-------------+
                 |             |                  |                  |
                 |-forwarding->|                  |                  |
                 |        translation             |                  |
                 |          encap.                |                  |
                 |             |-----tunneling--->|                  |
                 |             |                  |                  |
                 |             |                decap.               |
                 |             |                  |------forwarding->|
                 |             |                  |                  |


   Figure 4: PET1 translation in IPv6-to-IPv4 communication

   In the second method, when an IPv6 packet arrives at PET 1, it will
   be directly delivered through IPv6 backbone.  Once this packet
   arrives at PET2, it will be translated in to an IPv4 and then
   destined to the target.

      +-------------+   +-----+ +--------+ +-----+    +-------------+
      |IPv6 client  |   | PET1| | IPv6   | |PET2 |    |IPv4 client  |
      |   network   |   |     | |backbone| |     |    |   network   |
      +-------------+   +-----+ +--------+ +-----+    +-------------+
          |             |                  |                  |
          |-forwarding->|                  |                  |
          |             |----forwarding--->|                  |
          |             |             translation             |
          |             |                  |-----forwarding-->|


   Figure 5: PET2 translation in IPv6-to-IPv4 communication

4.3.  PET and DNS collaboration for IPv6-to-IPv4 communication

   IF an IPv6 initiator does not know the IPv6 mapping address of the
   IPv4 target, DNS may be need.  In this case, PETs should collaborate
   with DNSs for IPv6-to-IPv4 communication.

   The following subsections introduce how PETs collaborate with DNSs in
   each communication mode.








Cui, et al.               Expires April 4, 2010                 [Page 9]


Internet-Draft                    pet64                        Oct. 2009


4.3.1.  PET1 Translation scenario

+---------+   +------+   +-----+   +-----+       +------+   +----------+
|v6network|   | DNS6 |   | PET1|   |PET2 |       | DNS4 |   |v4network |
|  host A |   |      |   |     |   |     |       |      |   |  host B  |
+---------+   +------+   +-----+   +-----+       +------+   +----------+
     |dstv6 addr?>|         |         |              |            |
     |            |---dstv6 addr?---> |              |            |
     |            |         |         |dstv6,v4addr?>|            |
     |            |         |         |<-IPv4 addr B-|            |
     |            |         |  prefixPET2::v4B=C     |            |
     |            |<---IPv6 addr C----|              |            |
     |         save C       |         |              |            |
     |<IPv6 addr C|         |         |              |            |
     |-IPv6 pkt/srcport:y ->|         |              |            |
     |           |       translate    |              |            |
     |           |src:PET1v4/srcport:x|              |            |
     |           |      dst:B         |              |            |
     |           |    map:A,y,x       |              |            |
     |           |       encap.       |              |            |
     |           |         |tunneling |              |            |
     |           |         |        decap.           |            |
     |           |         |          |-----------IPv4 pkt------->|

           Figure 6: PET operations ( translation+forwarding)

   In this scenario, if an IPv6 host (i.e. host A) does not know the
   IPv6 mapping address of IPv4 target, it will launch a name look up
   request for host B, the lookup query is directed to the DNS server on
   the V6 network.

   In case of DNS6 having no information about the IPv6 mapping address
   of IPv4 target, DNS6 forwards the name look up request to DNS4 (the
   DNS6 has the IPv6 mapping address of DNS4 beforehand maybe through
   static configuration).  This name look up request will be intercepted
   by PET2.  Since host B may have IPv6 and/or IPv4 addresses, PET2
   forwards the original AAAA/A6 query to DNS4 unchanged, as well as an
   A query for the same host.

   If an AAAA/A6 record exists for the destination, this will be
   returned to PET2 which will forward it, also unchanged, to the
   originating host.  If there is an A record for host B, the reply also
   returns to the PET 2, which translates the reply, adds the Prefix of
   itself (PET prefix) to construct the IPv6 PET address (prefixPET2::
   v4B=C) and finally forwards it (IPv6 addr C) to DNS6.

   Now host A can use this address like any other IPv6 address and the
   DNS6 server can even cache it as long as the PET Prefix does not



Cui, et al.               Expires April 4, 2010                [Page 10]


Internet-Draft                    pet64                        Oct. 2009


   change.

   After getting the IPv6 mapping address, the host A sends a packet to
   host B with source port 'y'.  When PET 1 receives this packet, it
   performs translation and select an unused port 'x' to create the
   mapping entry (IPv6 address of host A, source port y and source port
   x).  After that, PET 1 sends the packet to PET 2 through softwire
   mechanism (4over6 tunneling).  When PET 2 receive this packet, it
   will directly deliver the packet to Host B.

   In the opposite direction, when a packet sent by host B arrives at
   PET 2, PET2 uses the softwire mechanism to send this packet to PET1.
   Because having the mapping information, PET 1 performs translation
   and then sends this packet to host A.

   The TTL values on all DNS resource records (RRs) passing through PET
   SHOULD be set to 0 so that DNS servers/clients do not cache
   temporarily assigned RRs.  Note, however, that due to some buggy DNS
   client implementations a value of 1 might in some cases work better.
   The TTL values should be left unchanged for statically mapped.

4.3.2.  PET2 Translation scenario

 +---------+   +------+   +-----+   +-----+      +------+   +---------+
 |v6network|   | DNS6 |   | PET1|   |PET2 |      | DNS4 |   |v4network|
 |  host A |   |      |   |     |   |     |      |      |   |  host B |
 +---------+   +------+   +-----+   +-----+      +------+   +---------+
     |dstv6 addr?->|         |        |              |           |
     |             |---dstv6 addr?--->|              |           |
     |             |         |        |dstv6,v4addr?>|           |
     |             |         |        |<-IPv4 addr B-|           |
     |             |         |   prefixPET2::v4B=C   |           |
     |             |<--IPv6 addr C----|              |           |
     |           save C      |        |              |           |
     |<-IPv6 addr C|         |        |              |           |
     |--IPv6 pkt/srcport:y ->|        |              |           |
     |             |         | IPv6pkt/srcport:y     |           |
     |             |         |      translate        |           |
     |             |         | src:PET1v4/srcport:x  |           |
     |             |         |       dst:B           |           |
     |             |         |      map:A,y,x        |           |
     |             |         |        |-------------IPv4 pkt---->|


   Figure 7:PET operations in IPv6-IPv6-IPv4 scenario(forwarding
   +translation)

   In this case, PET 2 performs translation, to that end, PET 2 selects
   an unused port 'x' to create the mapping entry (IPv6 address of host
   A, source port y and source port x).  Such binding state is created



Cui, et al.               Expires April 4, 2010                [Page 11]


Internet-Draft                    pet64                        Oct. 2009


   when the first packet flowing from the IPv6 network to the IPv4
   network is translated.  After the binding state has been created,
   packets flowing in either direction on that particular flow are
   translated.

   The other progress is same as that in subsection 4.3.1.

4.4.  Other considerations

   Address mappings for incoming sessions, as described above, are
   subject to denial of service attacks since one can make multiple
   queries for nodes residing in the V6 network causing the PETs to map
   and thus block legitimate incoming sessions.  Thus, address mappings
   for incoming sessions should time out to minimize the effect of
   denial of service attacks.

   In fact, an IPv6 host can learn the address of IPv4 target from the
   DNS4 or from the DNS6.  In this draft, we learn the idea from NAT64
   [draft-ietf-behave-v6v4-xlate-stateful-01] that DNS6 servers maintain
   a mapping of names to IPv6 addresses for internal nodes and possibly
   cache mappings for some external nodes.  In the case where the DNS6
   contains the mapping for external IPv4 hosts, the DNS queries will
   not cross the IPv6 domain and that would obviate the need for PET
   intervention.  Otherwise, the queries will cross the IPv6 domain and
   are subject to PET intervention.  We also learn the idea from NAT64
   [draft-ietf-behave-v6v4-xlate-stateful-01] that DNS4 servers cache
   name mapping for external nodes (i.e., V4 nodes) only.

   For basic functionality, the approach only requires the deployment of
   PETs connecting the IPv6 backbone to its client networks, along with
   the deployment of a DNS6 in the IPv6 client network and a DNS4 in the
   IPv4 client network.  However, some advanced features such as support
   for DNSSEC validating stub resolvers or support for some IPsec modes,
   require software updates to the IPv6-only hosts.

   We recommend the time to failure of DNS is no longer than that of
   mapping in PETs to guarantee the available of IPv6 mapping address
   (i.e.  PET address) of IPv4 target.

   It is important to note that the translation still works if the IPv6
   initiator learns the IPv6 mapping address of IPv4 address (i.e.
   Pref64::X) through some schemes other than a DNS look-up.  This is
   because the DNS processing does NOT result in any state installed in
   the PET box and because the IPv6 mapping address is constructed by
   concatenating the PET prefix to the original IPv4 address.






Cui, et al.               Expires April 4, 2010                [Page 12]


Internet-Draft                    pet64                        Oct. 2009


5.  Filtering

   Similar to the NAT64 [draft-ietf-behave-v6v4-xlate-stateful-01], a
   PET box may do filtering, which means it only allows some kinds of
   packets through the interface according to the appropriate policies.

   Similar to the NAT64 [draft-ietf-behave-v6v4-xlate-stateful-01], a
   PET may do no filtering, or it may filter on its IPv4 interface.
   Filtering on the IPv6 interface is not supported because mappings are
   only created by packets traveling in the IPv6 --> IPv4 direction.

   Similar to the NAT64 [draft-ietf-behave-v6v4-xlate-stateful-01],PET
   filtering is consistent with the recommendations of RFC 4787
   [RFC4787], and the ones of RFC 5382 [RFC5382].





































Cui, et al.               Expires April 4, 2010                [Page 13]


Internet-Draft                    pet64                        Oct. 2009


6. References

6.1. Normative References

   [RFC4787]  Audet, F. and C. Jennings, "Network Address Translation
              (NAT) Behavioral Requirements for Unicast UDP", BCP 127,
              RFC 4787, January 2007.

   [RFC5382]  Guha, S., Biswas, K., Ford, B., Sivakumar, S., and P.
              Srisuresh, "NAT Behavioral Requirements for TCP", BCP 142,
              RFC 5382, October 2008.

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

6.2. Informative References

   [I-D. draft-cui-softwire-PET-framework-00.txt]

            Y.Cui,M.Xu,S.Wang, X.Li,J. Wu, C. Metz, "PET-based framework
            for IPv4/IPv6 coexistence", July 2, 2009.

   [I-D. draft-ietf-behave-v6v4-xlate-stateful-01.txt]

            M.Bagnulo, P. Matthews,I. van Beijnum. "NAT64: Network Address
            and Protocol Translation from IPv6 Clients to IPv4 Servers",
            July 11, 2009.







































Cui, et al.               Expires April 4, 2010                [Page 14]


Internet-Draft                    pet64                        Oct. 2009


Authors' Addresses

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

   Phone: +86-10-6278-5983
   Email: cuiyong@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


   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











Cui, et al.               Expires April 4, 2010                [Page 15]


Internet-Draft                    pet64                        Oct. 2009


   Jianping Wu
   Tsinghua University
   Department of Electronic Engineering, Tsinghua University
   Beijing  100084
   P.R.China

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


   Chris Metz
   Cisco systems
   170 West Tasman Drive
   San Jose  95134-1706
   CA

   Email: chmetz@cisco.com


































Cui, et al.               Expires April 4, 2010                [Page 16]