Skip to main content

Public IPv4-over-IPv6 Access Network

The information below is for an old version of the document that is already published as an RFC.
Document Type
This is an older version of an Internet-Draft that was ultimately published as RFC 7040.
Authors Yong Cui , Jianping Wu , Peng Wu , Olivier Vautrin , Yiu Lee
Last updated 2015-10-14 (Latest revision 2013-07-28)
RFC stream Internet Engineering Task Force (IETF)
Additional resources Mailing list discussion
Stream WG state Submitted to IESG for Publication
Document shepherd Suresh Krishnan
Shepherd write-up Show Last changed 2013-05-02
IESG IESG state RFC 7040 (Informational)
Consensus boilerplate Yes
Telechat date (None)
Responsible AD Ted Lemon
Send notices to (None)
IANA IANA review state IANA OK - No Actions Needed
IANA action state No IANA Actions
Network Working Group                                             Y. Cui
Internet-Draft                                                     J. Wu
Intended status: Informational                                     P. Wu
Expires: January 30, 2014                            Tsinghua University
                                                              O. Vautrin
                                                        Juniper Networks
                                                                  Y. Lee
                                                           July 29, 2013

                  Public IPv4 over IPv6 Access Network


   This document describes a mechanism called Public 4over6 which is
   designed to provide IPv4 Internet connectivity over an IPv6 access
   network using global IPv4 addresses.  Public 4over6 was developed in
   the IETF and is in use in some existing deployments, but is not
   recommended for new deployments.  Future deployments of similar
   scenarios should use Lightweight 4over6.  Public 4over6 follows the
   Hub and Spoke softwire model, and uses an IPv4-in-IPv6 tunnel to
   forward IPv4 packets over IPv6 access network.  The bi-directionality
   of the IPv4 communication is achieved by explicitly allocating global
   non-shared IPv4 addresses to end users, as well as maintaining IPv4-
   IPv6 address binding on the border relay.  Public 4over6 aims to
   provide uninterrupted IPv4 services to users, like Internet Content
   Providers, etc., while an operator makes the transition of the access
   network to an IPv6-only access network.

Status of This Memo

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

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at

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

   This Internet-Draft will expire on January 30, 2014.

Cui, et al.             Expires January 30, 2014                [Page 1]
Internet-Draft                Public 4over6                    July 2013

Copyright Notice

   Copyright (c) 2013 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.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  4
   3.  Scenario and Use Cases . . . . . . . . . . . . . . . . . . . .  5
   4.  Public 4over6 Address Provisioning . . . . . . . . . . . . . .  6
     4.1.  Basic Provisioning Steps . . . . . . . . . . . . . . . . .  6
     4.2.  Public IPv4 Address Allocation . . . . . . . . . . . . . .  7
   5.  4over6 CE Behavior . . . . . . . . . . . . . . . . . . . . . .  7
   6.  4over6 BR Behavior . . . . . . . . . . . . . . . . . . . . . .  8
   7.  Fragmentation and reassembly . . . . . . . . . . . . . . . . .  9
   8.  DNS  . . . . . . . . . . . . . . . . . . . . . . . . . . . . .  9
   9.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 10
   10. Security Considerations  . . . . . . . . . . . . . . . . . . . 10
   11. Change Log from the -09 Version (RFC Editors please remove
       this part) . . . . . . . . . . . . . . . . . . . . . . . . . . 10
   12. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 11
   13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12
     13.1. Normative References . . . . . . . . . . . . . . . . . . . 12
     13.2. Informative References . . . . . . . . . . . . . . . . . . 12

Cui, et al.             Expires January 30, 2014                [Page 2]
Internet-Draft                Public 4over6                    July 2013

1.  Introduction

   When operators make the transition of their access networks to IPv6-
   only, they must continue to provide IPv4 services to their users to
   access IPv4 contents.  IPv4 connectivity is required when
   communicating with the IPv4-only Internet.  This document describes a
   mechanism called Public 4over6 for providing IPv4 connectivity over a
   native IPv6-only access network.  This memo focuses on interactions
   between Public 4over6 elements, as well as the deployment

   Public 4over6 is in active deployment in some environments,
   particularly in China Next Generation Internet (CNGI) and China
   Education and Research Network 2 (CERNET2), but is not recommended
   for new deployments.  Documenting this approach is to benefit users
   and operators of existing deployments, as well as readers of other
   IPv4-over-IPv6 documents.

   In addition to Public 4over6 and its deployment architecture
   described in this memo, the IETF is currently working on a more
   generic solution called Lightweight 4over6
   [I-D.ietf-softwire-lw4over6] that is classified as the binding
   approach in the Unified IPv4-in-IPv6 Softwire CPE
   [I-D.ietf-softwire-unified-cpe].  Lightweight 4over6 covers both
   sharing and non-sharing global IPv4 address in Hub-and-Spoke model.
   Future deployments should use [I-D.ietf-softwire-lw4over6].

   Public 4over6 utilizes the IPv4-in-IPv6 tunnel technique defined in
   [RFC2473], which enables IPv4 datagrams to traverse through native
   IPv6 network.  IPv4 nodes connect to the Tunnel Entry-Point Node and
   Tunnel Exit-Point Node to communicate over the IPv6-only network.
   Therefore, the Internet Service Providers (ISPs) can run an IPv6-only
   infrastructure instead of a fully dual-stack network, as well as
   avoiding the need to deploy scarce IPv4 address resources throughout
   the network.

   This mechanism focuses on providing full end-to-end transparency to
   the user-side.  Therefore, global IPv4 addresses are expected to be
   provisioned to end users and carrier-side address translation can be
   avoided.  Furthermore, global non-shared IPv4 address is preferred to
   shared IPv4 address so that user-side address translation is not
   necessary either.  It is important in particular to users which
   require to run their applications on IP protocol different from TCP
   and UDP (e.g., IPSec, L2TP) or on certain well-known TCP/UDP ports
   (e.g., http, smtp).  For many ISPs that are actually capable of
   provisioning non-shared unique IPv4 addresses, the mechanism provide
   a pure, suitable solution.

Cui, et al.             Expires January 30, 2014                [Page 3]
Internet-Draft                Public 4over6                    July 2013

   Another focus of this mechanism is deployment and operational
   flexibility.  Public 4over6 allows IPv4 and IPv6 address architecture
   to be totally independent of each other: the end user's IPv4 address
   is not embedded in its IPv6 address.  Therefore, the IPv4 address
   planning has no implication to the IPv6 address planning.  Operators
   can manage the IPv4 address resources in a flat, centralized manner.
   This requires the tunnel concentrator [RFC4925] to maintain the
   binding of IPv4 address and IPv6 address, i.e. maintaining per-
   subscriber binding state.

   The mechanism follows the Hub and Spoke softwire model [RFC4925], and
   uses IPv4-in-IPv6 tunneling as the basic data plane method.  Global
   non-shared IPv4 addresses are allocated from the ISP to end hosts or
   CPEs over IPv6 network.  Simultaneously, the binding between the
   allocated IPv4 address and the end user's IPv6 address is maintained
   on the tunnel concentrator for encapsulation usage.

2.  Terminology

   Public 4over6: Public 4over6 is a per-subscriber stateful, IPv4-in-
   IPv6 tunnel mechanism.  Public 4over6 supports bidirectional
   communication between the global IPv4 Internet and IPv4 hosts or
   customer networks via an IPv6 access network, by leveraging IPv4-in-
   IPv6 tunneling [RFC2473] and global IPv4 address allocation over
   IPv6.  The term 'public' means the allocated IPv4 address is globally

   Full IPv4 address: An IPv4 address that is not shared by multiple
   users.  The user with this IPv4 address has full access of all the
   available ports including the Well-Known ports.

   4over6 Customer Edge (CE): A device functioning as a Customer Edge
   equipment in Public 4over6 environment.  A 4over6 CE can be either a
   dual-stack capable host, or a dual-stack CPE device, both of which
   have a tunnel interface to support IPv4-in-IPv6 encapsulation.  In
   the former case, the host supports both IPv4 and IPv6 stacks but its
   uplink is IPv6 only.  In the latter case, the CPE has an IPv6
   interface connecting to the ISP network, and an IPv4 or dual-stack
   interface connecting to the customer network; hosts in the customer
   network can be IPv4-only or dual-stack.

   4over6 Border Relay (BR): A router deployed in the edge of the
   operator's IPv6 access network which supports IPv4-in-IPv6 tunnel
   termination.  A 4over6 BR is a dual-stack router which connects to
   both the IPv6 access network and the IPv4 Internet.  The 4over6 BR
   can also work as a DHCPv4-over-IPv6 [I-D.ietf-dhc-dhcpv4-over-ipv6]
   server/relay for assigning and distributing global IPv4 addresses to
   4over6 CEs.

Cui, et al.             Expires January 30, 2014                [Page 4]
Internet-Draft                Public 4over6                    July 2013

3.  Scenario and Use Cases

   The general scenario of Public 4over6 is shown in Figure 1.  Users in
   an IPv6 network take IPv6 as their native service.  Some users are
   end hosts which face the ISP network directly, while the others are
   in private networks behind CPEs, such as a home Local Area Network
   (LAN), an enterprise network, etc.  The ISP network is IPv6-only
   rather than dual-stack, which means the ISP cannot provide native
   IPv4 service to users.  In order to support legacy IPv4 transport,
   some routers on the carrier side are dual-stack and are connected to
   the IPv4 Internet.  These routers act as 4over6 Border Relays.
   Network users that require IPv4 connectivity obtain it through these

                         |    IPv6 ISP Network     |
                         |                         |
                      +------+                     |
                      |4over6|Host             +-------+   +-----------+
                      |  CE  |=================|       |   |           |
                      +------+                 |       |   |           |
                         |                     |4over6 |   |   IPv4    |
    +--------------+  +------+  IPv4-in-IPv6   |  BR   |---| Internet  |
    |   Customer   |  |4over6|                 |       |   |           |
    | Private IPv4 |--|  CE  |=================|       |   |           |
    |   Network    |  |      |CPE              +-------+   +-----------+
    +--------------+  +------+                     |
                         |                         |
                         |                         |

                      Figure 1 Public 4over6 scenario

   Public 4over6 can be applicable in several use cases.  If an ISP that
   switches to IPv6 still has plenty of global IPv4 address resource, it
   can deploy Public 4over6 to provide transparent IPv4 service for all
   its customers.  If the ISP does not have enough IPv4 addresses, it
   can deploy Dual-Stack Lite [RFC6333] as the basic IPv4-over-IPv6
   service.  Along with Dual-Stack Lite, Public 4over6 can be deployed
   as a value-added service, overcoming the service degradation caused
   by the Carrier Grade NAT (CGN).  An IPv4 application server is a
   typical high-end user of Public 4over6.  Using a full, global IPv4
   address brings significant advantages in this case, which is
   important for Internet Content Providers (ICPs) to make the
   transition to IPv6:

Cui, et al.             Expires January 30, 2014                [Page 5]
Internet-Draft                Public 4over6                    July 2013

   o  The DNS registration can be direct using dedicated address;

   o  Access of the application service can be straightforward, with no
      translation involved;

   o  There will be no need to provide NAT traversal mechanisms for
      incoming traffic, and no special handling is required for the
      Well-Known ports.

4.  Public 4over6 Address Provisioning

4.1.  Basic Provisioning Steps

   The following figure shows the basic provisioning steps for Public

          4over6                  DHCPv6         4over6         DHCPv4
            CE                    Server           BR           Server
            |Assign IPv6 Addr/Pref +|              |              |
            |  BR's IPv6 Addr Info  |              |              |
            |<----------------------|              |              |
            |     DHCPv6/Other      |              |              |
           WAN                                     |              |
        IPv6 Configure                             |              |
            |                                      |              |
            | Assign Public IPv4 Addr(DHCPv4-over-v6/Static Conf) |
            |                                      | IPv4-IPv6    |
            |                                      | Binding SYN  |
           Tunnel                                  |
        IPv4 Configure                       Binding Update
            |                                      |
            |          IPv4-in-IPv6 Tunnel         |
            |                                      |

                Figure 2 Public 4over6 Address Provisioning

   The main steps are:

   o  Provision IPv6 address/prefix to 4over6 CE, along with knowledge
      of 4over6 BR's IPv6 address, using DHCPv6 or other means.

   o  4over6 CE configures its WAN interface with globally unique IPv6
      address which is a result of IPv6 provisioning, including DHCPv6,

Cui, et al.             Expires January 30, 2014                [Page 6]
Internet-Draft                Public 4over6                    July 2013

      SLAAC or manual configuration.

   o  Provision IPv4 address to 4over6 CE, by DHCPv4 over IPv6 or static

   o  4over6 BR obtains the IPv4 and IPv6 addresses of the 4over6 CE
      using information provided by the DHCPv4 sever.

   o  4over6 CE configures its tunnel interface, as a result of IPv4

   o  4over6 BR updates the IPv4-IPv6 address binding table, as a result
      of address binding information acquired from the DHCPv4 server.

4.2.  Public IPv4 Address Allocation

   Usually each CE is provisioned with one global IPv4 address.  However
   it is possible that a CE would require an IPv4 prefix.  The key
   problem here is the mechanism for IPv4 address provisioning over IPv6

   There are two possibilities: DHCPv4 over IPv6, and static
   configuration.  Public 4over6 supports both these methods.  DHCPv4
   over IPv6 allows DHCPv4 message to be transported in IPv6 rather than
   IPv4; therefore, the DHCPv4 process can be performed over an IPv6
   network, between the BR and the relevant CE.
   [I-D.ietf-dhc-dhcpv4-over-ipv6] describes the DHCP protocol
   extensions needed to support this operation.  For static
   configuration, 4over6 users and the ISP operators negotiate
   beforehand to authorize the IPv4 address(es).  Then the tunnel
   interface and the address binding are configured by the user and the
   ISP respectively.

   While regular users would probably opt for DHCPv4 over IPv6, the
   static configuration is particularly applicable in two cases: for
   application servers, which require a stable IPv4 address, and for
   enterprise networks, which usually require an IPv4 prefix rather than
   one single address (Note that DHCPv4 does not support prefix

5.  4over6 CE Behavior

   A CE is provisioned with IPv6 before Public 4over6 process.  It also
   learns the BR's IPv6 address beforehand.  This IPv6 address can be
   configured using a variety of methods, ranging from an out-of-band
   mechanism, manual configuration, or via a DHCPv6 option.  In order to
   guarantee interoperability, the CE element implements the AFTR-Name
   DHCPv6 option defined in [RFC6334].

Cui, et al.             Expires January 30, 2014                [Page 7]
Internet-Draft                Public 4over6                    July 2013

   A CE supports DHCPv4 over IPv6 [I-D.ietf-dhc-dhcpv4-over-ipv6], to
   dynamically acquire an IPv4 address over IPv6 and assign it to the
   IPv4-in-IPv6 tunnel interface.  The CE regards the BR as its DHCPv4-
   over-IPv6 server/relay, which is used to obtain its global IPv4
   address allocation; its IPv6 address is learned by the CE as
   described above.

   A CE also supports static configuration of the tunnel interface.  In
   the case of prefix provisioning, the tunnel interface is assigned
   with the Well-Known IPv4 Address defined in section 5.7 of [RFC6333],
   rather than using an address from the prefix.  If the CE has multiple
   IPv6 addresses on its WAN interface, it uses the same IPv6 address
   for DHCPv4-over-IPv6/negotiation of manual configuration, and for
   data plane encapsulation.

   A CE performs IPv4-in-IPv6 encapsulation and decapsulation on the
   tunnel interface.  When sending out an IPv4 packet, it performs the
   encapsulation, using the IPv6 address of the 4over6 BR as the IPv6
   destination address, and its own IPv6 address as the IPv6 source
   address.  The decapsulation on the 4over6 CE is simple.  When
   receiving an IPv4-in-IPv6 packet, the CE just removes the IPv6
   header, and either hands it to a local upper layer or forwards it to
   the customer network according to the IPv4 destination address.

   A CE runs a regular IPv4 Network Address and Port Translation (NAPT)
   for its customer network when it is provisioned with one single IPv4
   address.  In that case, the assigned IPv4 address of the tunnel
   interface would be the external IPv4 address of the NAPT.  Then the
   CE performs IPv4 private-to-public translation before encapsulation
   of IPv4 packets from the customer network, and IPv4 public-to-private
   translation after decapsulation of IPv4-in-IPv6 packets.

   IPv4 NAPT is not necessary when the CE is provisioned with an IPv4
   prefix.  In this case, the detailed customer network planning is out
   of scope.

   The 4over6 CE supports backward compatibility with DS-Lite.  A CE can
   employ the Well-Known IPv4 Address for Basic Bridging BroadBand (B4)
   element [RFC6333] and switch to Dual-Stack Lite for IPv4
   communications, if it can't get a global IPv4 address from the DHCPv4
   server (for instance, if the DHCPv4-over-IPv6 process fails or the
   DHCPv4 server refuses to allocate a global IPv4 address to it, etc.).

6.  4over6 BR Behavior

   The 4over6 BR maintains the bindings between the CE IPv6 address and
   CE IPv4 address (prefixes).  The bindings are used to provide the
   correct encapsulation destination address for inbound IPv4 packets,

Cui, et al.             Expires January 30, 2014                [Page 8]
Internet-Draft                Public 4over6                    July 2013

   as well as validating the IPv6-IPv4 source of the outbound IPv4-in-
   IPv6 packets.

   The BR acquires the binding information through the IPv4 address
   provisioning process.  For static configuration, the operator
   manually configures the BR using the binding information obtained
   through negotiation with the customer.  As for DHCPv4-over-IPv6,
   there are multiple possibilities which are deployment-specific:

   o  The BR can be co-located with the DHCPv4-over-IPv6 server.  Then
      the synchronization happens within the BR.  It installs a binding
      when sending out an ACK for a DHCP lease, and deletes it when the
      lease expires or a DHCP RELEASE message is received.

   o  The BR can play the role of IPv6-Transport Relay Agent (TRA) as
      described in [I-D.ietf-dhc-dhcpv4-over-ipv6], and snoop for the
      DHCPv4 ACK and RELEASE messages, as well as keep a timer for each
      binding according to the DHCP lease time.

   On the IPv6 side, the BR decapsulates IPv4-in-IPv6 packets coming
   from 4over6 CEs.  It removes the IPv6 header of every IPv4-in-IPv6
   packet and forwards it to the IPv4 Internet.  Before the
   decapsulation, the BR checks the inner IPv4 source address against
   the outer IPv6 source address, by matching such a binding entry in
   the binding table.  If no binding is found, the BR silently drops the
   packet.  On the IPv4 side, the BR encapsulates the IPv4 packets
   destined to 4over6 CEs.  When performing the IPv4-in-IPv6
   encapsulation, the BR uses its own IPv6 address as the IPv6 source
   address, uses the IPv4 destination address in the packet to look up
   IPv6 destination address in the address binding table.  After the
   encapsulation, the BR sends the IPv6 packet on its IPv6 interface to
   reach a CE.

   The BR supports hairpinning of traffic between two CEs, by performing
   de-capsulation and re-encapsulation of packets.

   In the case that the BR manages the global IPv4 address pool, it
   advertises the routing information of IPv4 addresses to the IPv4

7.  Fragmentation and reassembly

   The same considerations as described in section 5.3 and section 6.3
   of [RFC6333] are taken into account for the CE and the BR

8.  DNS

Cui, et al.             Expires January 30, 2014                [Page 9]
Internet-Draft                Public 4over6                    July 2013

   The procedure described in Section 5.5 and Section 6.4 of [RFC6333]
   is followed by the CE and the BR respectively.

9.  IANA Considerations

   This document has no IANA actions.

10.  Security Considerations

   The 4over6 BR implements methods to limit service only to registered
   customers.  On the control plane, the BR allocates IPv4 addresses
   only to registered customers.  The BR can filter on the IPv6 source
   addresses of incoming DHCP requests and only respond to the ones that
   are conveyed by registered IPv6 source addresses.  But this doesn't
   work in situations where multi-homing is present.  In the networks
   that Public 4over6 is deployed, multi-homing is disallowed to avoid
   this issue.

   Alternatively, the BR can filter out the unregistered CEs' requests
   during the DHCP process.  For data packets, the BR does the ingress
   filtering by looking up the IPv4-IPv6 address binding table for the
   related matches as described in Section 6.

   In the case of fallback to DS-Lite, security considerations in
   Section 11 of [RFC6333] is followed.

11.  Change Log from the -09 Version (RFC Editors please remove this

   1.  Update the Abstract and the Introduction to specify the purpose
   of the doc.

   2.  Add the definition of 'Full IPv4 Address' in the Terminology.

   3.  Update the definition of '4over6 Border Relay' in the

   4.  Replace 'public IPv4 address' with 'global IPv4 address' to
   consistent with RFC1918.

   5.  Polish the text in the Introduction to make it more RFC

   6.  Update the Security Considerations to make it more accurate.  And
   add the reference to RFC6333 in the case of fallback to DS-Lite.

   7.  Correct some nits.

Cui, et al.             Expires January 30, 2014               [Page 10]
Internet-Draft                Public 4over6                    July 2013

   8.  Update the references.

12.  Contributors

   The following are those who have made contributions to the effort:

      Huiling Zhao
      China Telecom
      Room 502, No.118, Xizhimennei Street
      Beijing 100035

      Phone: +86-10-58552002

      Chongfeng Xie
      China Telecom
      Room 708, No.118, Xizhimennei Street
      Beijing 100035

      Phone: +86-10-58552116

      Qiong Sun
      China Telecom
      Room 708, No.118, Xizhimennei Street
      Beijing 100035

      Phone: +86-10-58552936

      Qi Sun
      Tsinghua University
      Beijing 100084

      Phone: +86-10-62785822

Cui, et al.             Expires January 30, 2014               [Page 11]
Internet-Draft                Public 4over6                    July 2013

      Chris Metz
      Cisco Systems
      3700 Cisco Way
      San Jose, CA 95134


13.  References

13.1.  Normative References

   [RFC2473]                        Conta, A. and S. Deering, "Generic
                                    Packet Tunneling in IPv6
                                    Specification", RFC 2473,
                                    December 1998.

   [RFC4925]                        Li, X., Dawkins, S., Ward, D., and
                                    A. Durand, "Softwire Problem
                                    Statement", RFC 4925, July 2007.

   [RFC6333]                        Durand, A., Droms, R., Woodyatt, J.,
                                    and Y. Lee, "Dual-Stack Lite
                                    Broadband Deployments Following IPv4
                                    Exhaustion", RFC 6333, August 2011.

   [RFC6334]                        Hankins, D. and T. Mrugalski,
                                    "Dynamic Host Configuration Protocol
                                    for IPv6 (DHCPv6) Option for Dual-
                                    Stack Lite", RFC 6334, August 2011.

13.2.  Informative References

   [I-D.ietf-dhc-dhcpv4-over-ipv6]  Cui, Y., Wu, P., Wu, J., and T.
                                    Lemon, "DHCPv4 over IPv6 Transport",
                                    (work in progress), March 2013.

   [I-D.ietf-softwire-lw4over6]     Cui, Y., Sun, Q., Boucadair, M.,
                                    Tsou, T., Lee, Y., and I. Farrer,
                                    "Lightweight 4over6: An Extension to
                                    the DS-Lite Architecture",
                                    (work in progress), July 2013.

   [I-D.ietf-softwire-unified-cpe]  Boucadair, M., Farrer, I.,
                                    Perreault, S., and S. Sivakumar,
                                    "Unified IPv4-in-IPv6 Softwire CPE",

Cui, et al.             Expires January 30, 2014               [Page 12]
Internet-Draft                Public 4over6                    July 2013

                                    (work in progress), May 2013.

Authors' Addresses

   Yong Cui
   Tsinghua University
   Department of Computer Science, Tsinghua University
   Beijing  100084

   Phone: +86-10-6260-3059

   Jianping Wu
   Tsinghua University
   Department of Computer Science, Tsinghua University
   Beijing  100084

   Phone: +86-10-6278-5983

   Peng Wu
   Tsinghua University
   Department of Computer Science, Tsinghua University
   Beijing  100084

   Phone: +86-10-6278-5822

   Olivier Vautrin
   Juniper Networks
   1194 N Mathilda Avenue
   Sunnyvale, CA  94089


   Yiu L. Lee
   One Comcast Center
   Philadelphia, PA  19103

Cui, et al.             Expires January 30, 2014               [Page 13]
Internet-Draft                Public 4over6                    July 2013



Cui, et al.             Expires January 30, 2014               [Page 14]