Network Working Group                                             Q. Sun
Internet-Draft                                                    C. Xie
Intended status: Standards Track                           China Telecom
Expires: March 28, 2012                                           Y. Cui
                                                                   J. Wu
                                                                   P. Wu
                                                     Tsinghua University
                                                                 C. Zhou
                                                     Huawei Technologies
                                                                  Y. Lee
                                                                 Comcast
                                                      September 25, 2011


                   Stateless 4over6 in access network
                 draft-sun-softwire-stateless-4over6-00

Abstract

   This document specifies a stateless 4over6 mechanism which moves the
   translation function from tunnel concentrator (AFTR) to initiators
   (B4s).  It is used for service providers offering residual deployment
   of the IPv4 service across IPv6-only domains.  The concentrator will
   record the full set of prefix mapping rules independent of the number
   of subscribers, while the initiator will only keep a single rule of
   its own sub-domain.  The BNG devices can learn the rule set further,
   to achieve traffic optimization between initiators.  In this way, it
   not only achieve scalability and simplicity feature benefits from
   stateless address mapping, but also keep CPE functions simple.
   Besides, flexible addressing and scattered IPv4 address blocks can be
   supported as well.  Traffic optimization can be deployed
   incrementally when necessary.

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 http://datatracker.ietf.org/drafts/current/.

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




Sun, et al.              Expires March 28, 2012                 [Page 1]


Internet-Draft              stateless 4over6              September 2011


   This Internet-Draft will expire on March 28, 2012.

Copyright Notice

   Copyright (c) 2011 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
   (http://trustee.ietf.org/license-info) 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.



































Sun, et al.              Expires March 28, 2012                 [Page 2]


Internet-Draft              stateless 4over6              September 2011


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  4
   2.  Requirements Language  . . . . . . . . . . . . . . . . . . . .  6
   3.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  7
   4.  Stateless 4over6 Overview  . . . . . . . . . . . . . . . . . .  8
   5.  Port Restricted IPv4 Address Allocation  . . . . . . . . . . . 10
   6.  Address/Prefix Mapping . . . . . . . . . . . . . . . . . . . . 11
     6.1.  Address/Prefix Mapping format  . . . . . . . . . . . . . . 11
     6.2.  Address/Prefix Mapping Procedure . . . . . . . . . . . . . 11
     6.3.  Port mapping algorithm . . . . . . . . . . . . . . . . . . 12
   7.  Stateless 4over6 Initiator Behavior  . . . . . . . . . . . . . 13
   8.  Stateless 4over6 Concentrator Behavior . . . . . . . . . . . . 14
   9.  CPE-CPE optimization . . . . . . . . . . . . . . . . . . . . . 15
   10. Mechanism Analysis . . . . . . . . . . . . . . . . . . . . . . 16
   11. Security Considerations  . . . . . . . . . . . . . . . . . . . 17
   12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 20

































Sun, et al.              Expires March 28, 2012                 [Page 3]


Internet-Draft              stateless 4over6              September 2011


1.  Introduction

   Global IPv4 address exhaustion is becoming reality.  The dramatic
   growth of the Internet is accelerating the consumption of available
   IPv4 addresses together with the scattered IPv4 address blocks, which
   makes the address shortage problem even worse.  It is widely accepted
   that IPv6 is the only answer to solve the address shortage problem
   and sustain the long-term growth of the Internet.  However, IPv6
   deployment is a huge systematic project and a lot of challenges will
   arise, especially in large commercial operational network.

   In the course of IPv6 transition, CPE is always a big issue for the
   whole industry.  Since CPE is a customer-side device with restricted
   resource, it is cost sensitive.  Moreover, there is lots of legacy
   CPEs which are owned by customers, in this case, ISP can not upgrade
   them .  Besides, due to the huge number of CPEs, it is of vital
   importance to keep it simple for easy management and trouble
   shooting.

   As discussed in [I-D.ietf-softwire-stateless-4v6-motivation],
   stateless approaches would have good features of high scalability,
   reliability and robustness, etc.  It is easy to achieve multi-vendor
   redundancy.  However, since stateless solutions have essentially
   infered the mapping relationship between IPv4 address and IPv6
   address, it would have some kind of impact on network planning, e.g.
   address planning, routing, CPE, etc.  From service provider
   perspective, there are several operational requirements on stateless
   approaches.

   Firstly, flexible addressing is needed especially when the remaining
   IPv4 address blocks are rather scattered.  Network providers might do
   address reallocation in their network in the future, e.g. reallocate
   global IPv4 address for address sharing.  And this kind of addressing
   adjustment need to have little impact on the whole network
   infrastructure, e.g. informing thoudsands of CPEs within the same
   domain.

   Secondly, we need to keep CPE as simple as possible.  This will not
   only reduce the great burden on CPE management and trouble shooting,
   but also reduce cost and implemenation complexity.

   Thirdly, stateless solutions should be capable of covering a large
   area with centralized deployment.  Since stateless approaches can
   achieve high scalability and no performance bottleneck, centralized
   deployment is good for network management and multi-vendor industry.
   Given the fact that large scale service providers would normally have
   few thousand BNGs with different vendors and different versions, it
   is a huge burden to update all existing BNGs with the new service



Sun, et al.              Expires March 28, 2012                 [Page 4]


Internet-Draft              stateless 4over6              September 2011


   card.

   Finally, CPE-CPE traffic optimization should be deployed
   incrementally.  Currently, network architecture for some service
   providers is already rather flat, and there is no direct link between
   CPEs.  The traffic within the same BNG occupies a small percentage,
   so CPE-CPE traffic optimization is NOT a MUST in general.  It can be
   only deployed incrementally when necessary.

   In this document, we propose a stateless 4over6 approach for service
   providers offering residual deployment of the IPv4 service across
   IPv6-only domains.  In stateless 4over6, the concentrator will record
   the full set of prefix mapping rules including IPv4 prefix, IPv6
   prefix and multiplexing ratio, while the initiator will only keep a
   single rule of its own sub-domain.  Thus, all traffic will be firstly
   tunneled to concentrator by default.  The BNG devices can learn the
   rule set further, to achieve traffic optimization between initiators.

   This procedure keeps the advantages of stateless 4over6 mechanisms,
   and prevents the customer devices from complex configuration/
   delegation.  It "moves" the mapping rules from customer devices up to
   concentrator and BRAS devices, in which the amount of rules is
   acceptable.  It can still keep the flexible feature of centralized
   addressing.  This is also an extended case which covers stateless
   addressing sharing for [I-D.cui-softwire-host-4over6].  However, this
   extension will decrease IPv4 address utilization.  Moreover, since
   port randomization algorithm must use ports within this port-range,
   it may cause the port randomization algorithm more predictable.























Sun, et al.              Expires March 28, 2012                 [Page 5]


Internet-Draft              stateless 4over6              September 2011


2.  Requirements Language

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














































Sun, et al.              Expires March 28, 2012                 [Page 6]


Internet-Draft              stateless 4over6              September 2011


3.  Terminology

   Stateless 4over6: stateless 4over6 is an IPv4-over-IPv6 hub and spoke
   mechanism proposed in this document, which supports address sharing
   to alleviate the problem of IPv4 address exhaustion, and places the
   IPv4 translation on the initiator side.

   Stateless 4over6 initiator (or "initiator" for short): the tunnel
   client module of stateless 4over6 mechanism.  The stateless 4over6
   initiator could be a host directly connected to IPv6, or an dual-
   stack CPE in front of an IPv4 local network.  It is responsible for
   IPv4 public-private translation besides tunnel encapsulation and
   decapsulation.

   Stateless 4over6 concentrator (or "concentrator" for short): the
   tunnel servicing module in stateless 4over6 mechanism.  The stateless
   4over6 concentrator connects the ISP IPv6 network and IPv4 Internet.
   It provides tunnel encapsulation and decapsulation but no IPv4
   private-public translation.

   Stateless 4over6 domain(or "SL Domain" for short): The IPv6 network a
   concentrator covers.  Its coverage depends on the placement of the
   concentrator.  For example, if the concentrator is deployed at the
   Core of MAN, the Domain will cover the whole MAN.

   Stateless 4over6 sub-domain(or "sub-domain" for short): A IPv6 sub-
   network where different initiators can share a same IPv4/IPv6 prefix
   for stateless mapping.  It usually depends on the range of IPv4
   address block and multiplexing ratio.

   Stateless 4over6 subPre6(or "subPre6" for short): A common IPv6
   prefix in the sub-domain for stateless address mapping. subPre6 is
   only a part of IPv6 perfix/address delegated to customers, which will
   be followed by "user-id" , etc.(refer to section 6 for detail).

   Stateless 4over6 subPre4(or "subPre4" for short): A common IPv4
   prefix in the sub-domain for stateless address mapping.  Different
   subscribers in the common sub-domain will have a different identifier
   (indicated by "Free bits").  For example, if a given subPre4 is
   "202.112.1/24" and the shared public address for the specific
   subscriber is "202.112.1.5", then the "Free bits" is "5".

   Stateless sub-domain Rule(or "sub-domain rule" for short): A mapping
   rule inculding subPre6, subPre4 and Multiplexing ratio for a specific
   sub-domain.






Sun, et al.              Expires March 28, 2012                 [Page 7]


Internet-Draft              stateless 4over6              September 2011


4.  Stateless 4over6 Overview

   Figure 1 provides an overview of the stateless 4over6 mechanism.  A
   stateless 4over6 initiator which can be either an IPv6 hosts or CPE,
   and the stateless 4over6 concentrator are seperated by the IPv6
   network in the middle, so they use IPv4-in-IPv6 tunnel to build IPv4
   connectivity.  One concentrator will cover a SL Domain and there will
   be one or more sub-domains in it.  Each sub-domain will only have one
   sub-domain rule indicating the common subPre6, subPre4 and
   multiplexing ratio.  These sub-domains can be divided in a rather
   flexible way.  One BNG can have one or more sub-domains, and multiple
   BNGs can also belong to one sub-domain.  The only rule for sub-domain
   to follow is to have a unique sub-domain rule with a unified
   multiplexing ratio.

                  +------------------------------+
                  |    Stateless 4over6 Domain   |
              +---+---------------+--------------|
  +--------+  +     Sub-domain    |              |
  |        |  +---------+      +--+--+           |
  |IPv4 LAN|--|SL 4over6|      |     |           |
  |        |  |Initiator|======| BNG | ======+---------+   +-----------+
  +--------+  +---------+      +--|--+       |SL 4over6|   |   IPv4    |
  +--------+      +---------------+          |Concen-  |---| Internet  |
  |        |  +---|-----+      +--+--+       |trator   |   |           |
  |IPv4 LAN|--|SL 4over6|======|     | ======+---------+   +-----------+
  |        |  |Initiator|      | BNG |           |
  +--------+  +---------+      +--+--+           |
              +      Sub-domain   |              |
              +-------------------+--------------+

   Figure 1 Stateless 4over6 overview

   An initiator will get its sub-domain rule containing subPre6, subPre4
   and multiplexing ratio.  And it will also get a user prefix which
   includes a user-id via PPPoE, etc.  By combining the user-id and
   multiplexing ratio, we can deduce the vaule of the "Free bits" and
   "Port-set id".  SubPre4 and "Free bits" will then construct a public
   address for the customer, while "Port-set id" can be mapped to a
   certain port set by port mapping algorithm.

   In this way, an initiator has known its shared IPv4 address and valid
   port range.  For a IPv4 outbound packet arriving at initiator, it
   will do port-restricted NAT44, then encapuslate with IPv6 header and
   tunneled to the concentrator by default.  The source address and
   destination address format in IPv6 header will be discussed in the
   next section.  The concentrator will only do packet de-capsulation
   for outbound packet.  When the inbound traffic arriving at



Sun, et al.              Expires March 28, 2012                 [Page 8]


Internet-Draft              stateless 4over6              September 2011


   concentrator, it will lookup sub-domain rule table based on
   destination IPv4 address and find out its corresponding subPre6.
   Then it will construct an IPv6 header algorithmically.  Since the
   number of sub-domain rules is independent of subscriber numbers, it
   is still a algorithm-based stateless method.  Then the inbound
   traffic will be sent back to customer and perform NAT44 again.













































Sun, et al.              Expires March 28, 2012                 [Page 9]


Internet-Draft              stateless 4over6              September 2011


5.  Port Restricted IPv4 Address Allocation

   As described above, a stateless 4over6 initiator needs the sub-domain
   rule containing subPre6, subPre4 and multiplexing ratio.  Since these
   parameters are relatively stable, it can be configured in a variety
   of provisioning methods, including
   DHCPv6[I-D.cui-softwire-dhcp-over-tunnel], "TR-069", etc.  For
   customer's IPv6 prefix, it will be delegated just in traditional way,
   e.g.  DHCPv6, Prefix Delegation, etc.  And there is no impact on
   current IPv6 addressing model.  The concentrator address can be
   passed through the same option of ds-lite AFTR address.








































Sun, et al.              Expires March 28, 2012                [Page 10]


Internet-Draft              stateless 4over6              September 2011


6.  Address/Prefix Mapping

6.1.  Address/Prefix Mapping format

   The subscriber source address mapping format is in consistent with
   [I-D.xli-behave-divi-pd] expect for the last 64 bits.  Since
   stateless 4over6 is a tunnel-based solution, we just set the last 64
   bits to zero (depicted in Figure2).

   +--+---------+-------+------+-----+----+-----------+-----------+----+
   |PL| 0-------32------48-----56----64---72----------104---------120  |
   +--+---------+-------+------+-----+----+-----------+-----------+----+
   |64|           prefix             | u  |           0                |
   +--+---------+-------+------+-----+----+-----------+-----------+----+
   |e |  Prefix-sub |user(CPE)-id| 0 | u  |           0           | 0  |
   |x |-------------+------------+---+----+-----------+-----------+----|
   |t |(d) bits     |(s+k) bits  |(m)|(8) |          (48)         |(8) |
   +--+---------+-------+------+-----+----+-----------+-----------+----+

   Figure 2 Subscriber Source address mapping format

   The user-id is consisted of the "Free Bits" and "Port-set id".

   The destination address is the concentrator address in CPE.  However,
   when BRAS is processing traffic optimization, the destination address
   needs to be performed in a similar way with subscriber source
   address.

6.2.  Address/Prefix Mapping Procedure

+-----------------+---------+---+---------+---------+------------------+
|sub-doamin rule  |subPref6 |   |subPref4 |         |Multiplexing Ratio|
+-----------------+---------+---+---------+---------+--------|---------+
                                                             |
+-------------------------------+---------+--------+---------|---------+
|IPv6 user prefix               |subPref6 |user-id |         |         |
+-------------------------------+---------+----|---+---------|---------+
                                               |             |
                                +---------+    +------+------+
                                |subPref4 |    | Free | Port |
                                |         |    | Bits |Set id|
                                +---+-----+    +--+---+---+--+
                                    |            /        |
                                    |           /         |
                                +---+-----+---+--+    +---+--+
                                |subPref4 | Free |    | Port |
                                |         | Bits |    | Set  |
                                +---------+------+    +------+



Sun, et al.              Expires March 28, 2012                [Page 11]


Internet-Draft              stateless 4over6              September 2011


                                Shared IPv4 address


   Figure 2 Address/Prefix Mapping Procedure

   The above figure depicts address mapping procedure in stateless
   4over6.  An initiator will get its sub-domain rule containing
   subPre6, subPre4 and multiplexing ratio.  And it will also get a user
   prefix incluing subPref6 and user-id.  By combining the user-id and
   multiplexing ratio, we can deduce the vaule of the "Free bits" and
   "Port-set id".  SubPre4 and "Free bits" will then construct a public
   address for the customer, while "Port-set id" can be mapped to a
   certain "Port Set" by port mapping algorithm.

   Detailed descriptions will be added soon...

6.3.  Port mapping algorithm

   A unified Port mapping algorithms should be defined to determine the
   mapping rule between Port-set id and Port-set.  You can refer to
   [I-D.xli-behave-divi-pd] for example.  And we will complete this
   section soon ...





























Sun, et al.              Expires March 28, 2012                [Page 12]


Internet-Draft              stateless 4over6              September 2011


7.  Stateless 4over6 Initiator Behavior

   When requiring IPv4 access, the initiator needs to get its IPv6
   address/prefix via normal IPv6 address allocation precedure first,
   then it will calculate its port-restricted IPv4 address and valid
   port range.

   The data plane functions of the initiator includes translation and
   encapsulation/decapsulation.  For CPE initiator case, the initiator
   runs a standard local NAT44 with the address pool consist of the
   calculated port restricted address.  When sending out an IPv4 packet
   with private source address, it performs NAT44 function and
   translates the source address into public.  Then it encapsulates the
   packet with concentrator's IPv6 address as destination IPv6 address,
   and forwards it to the concentrator.  The source address of the IPv6
   packet will be generated as described above.  When receiving an IPv4-
   in-IPv6 packet from the concentrator, the initiator decapsulates the
   IPv6 packet to get the IPv4 packet with public destination IPv4
   address.  Then it performs NAT44 function and translates the
   destination address into private one.

   For host initiator case, it is suggested that the host runs a local
   NAT to map randomly generated ports into the restricted, valid port
   range.  Private-public address translation would not be needed in
   this NAT.  Another solution is to have the IP stack to only assign
   ports within the restricted, vailid range to applications.  Either
   way makes sure that every port number in the packets sent out by
   itself falls into the allocated port range.























Sun, et al.              Expires March 28, 2012                [Page 13]


Internet-Draft              stateless 4over6              September 2011


8.  Stateless 4over6 Concentrator Behavior

   The stateless 4over6 concentrator should record the full set of sub-
   domain rules.  They can also be configured in a variety of methods,
   and they can be refreshed or deleted once there is an adjustment on
   address planning (no Initiator needs to be informed with this
   adjustment).

   The data plane functions of the concentrator is purely encapsulation
   and de-capsulation.  When receiving an IPv4-in-IPv6 packet from an
   initiator, the concentrator de-capsulates it and forwards it to IPv4
   Internet.  When receiving an IPv4 packet from the Internet, it uses
   the destination address and port from this packet to lookup the sub-
   domain rules and calculate the specific "user-id" with port mapping
   algorithm.  Then the concentrator encapsulates this packet and
   forwards it to the correct initiator based on native IPv6 routing.
   The source address of IPv6 packet is just the concentrator address.


































Sun, et al.              Expires March 28, 2012                [Page 14]


Internet-Draft              stateless 4over6              September 2011


9.  CPE-CPE optimization

   In order to support CPE-CPE optimization, it will delegate the full
   sub-domain rules to BRAS device in the 4over6 domain.  When the IPv4
   destination of an IPv4-in-IPv6 packet is in the 4over6 domain, BRAS
   performs IPv6 destination address translation, according to sub-
   domain rules from the set, and the IPv4 destination address + port in
   the packet.  After the translation, the IPv6 packet can be forwarded
   to the destination CPE directly without going through the
   concentrator.  However, this functionality is not a must in cast the
   network is flat and there is no direct link between different CPEs.








































Sun, et al.              Expires March 28, 2012                [Page 15]


Internet-Draft              stateless 4over6              September 2011


10.  Mechanism Analysis

   Stateless 4over6 does not need to inform multiple prefix mapping
   rules to CPEs directly.  Thus, there is no need to introduce dynamic
   protocol for distributing and maintaining 4rd rules.  This will turn
   CPE to be a much simpler/dummier client, which will also
   significantly reduce the burden of CPE management and trouble
   shooting.

   Besides, stateless 4over6 would be easier for address planning.  SPs
   only need to pre-determine the mapping relationship between IPv4
   prefix and IPv6 prefix.  Only concentrators( and BRAS in CPE-CPE
   optimization case) need to be informed when changing a mapping rule.
   And it fits well for scattered IPv4 address blocks.  Moreover,
   incremental CPE-CPE optimization can be achieved when network
   providers would like to adjust their traffic when necessary.

   The costs of stateless 4over6 for achieving the above benefits are
   less optimized traffic by default.  All traffic will be tunneled to
   the concentrator when there is no prefix mapping BNGs.  This is still
   acceptable in flat network and few direct physical links between
   different BNGs.  However, if the network architecture is not flat and
   concentrator is in the upper level of the network, it is recommended
   that CPE-CPE optimization should be introduced.



























Sun, et al.              Expires March 28, 2012                [Page 16]


Internet-Draft              stateless 4over6              September 2011


11.  Security Considerations

   See security considerations presented in [RFC6052] and [RFC6145].
















































Sun, et al.              Expires March 28, 2012                [Page 17]


Internet-Draft              stateless 4over6              September 2011


12.  References

   [I-D.bajko-pripaddrassign]
              Bajko, G., Savolainen, T., Boucadair, M., and P. Levis,
              "Port Restricted IP Address Assignment",
              draft-bajko-pripaddrassign-03 (work in progress),
              September 2010.

   [I-D.bsd-softwire-stateless-port-index-analysis]
              Boucadair, M., Skoberne, N., and W. Dec, "Analysis of Port
              Indexing Algorithms",
              draft-bsd-softwire-stateless-port-index-analysis-00 (work
              in progress), September 2011.

   [I-D.cui-softwire-dhcp-over-tunnel]
              Cui, Y., Wu, P., and J. Wu, "DHCPv4 Behavior over IP-IP
              tunnel", draft-cui-softwire-dhcp-over-tunnel-01 (work in
              progress), July 2011.

   [I-D.cui-softwire-host-4over6]
              Cui, Y., Wu, J., Wu, P., Metz, C., Vautrin, O., and Y.
              Lee, "Public IPv4 over Access IPv6 Network",
              draft-cui-softwire-host-4over6-06 (work in progress),
              July 2011.

   [I-D.ietf-softwire-stateless-4v6-motivation]
              Boucadair, M., Matsushima, S., Lee, Y., Bonness, O.,
              Borges, I., and G. Chen, "Motivations for Stateless IPv4
              over IPv6 Migration Solutions",
              draft-ietf-softwire-stateless-4v6-motivation-00 (work in
              progress), September 2011.

   [I-D.murakami-softwire-4rd]
              Murakami, T., Troan, O., and S. Matsushima, "IPv4 Residual
              Deployment on IPv6 infrastructure - protocol
              specification", draft-murakami-softwire-4rd-01 (work in
              progress), September 2011.

   [I-D.sun-v6ops-laft6]
              Sun, Q. and C. Xie, "LAFT6: Lightweight address family
              transition for IPv6", draft-sun-v6ops-laft6-01 (work in
              progress), March 2011.

   [I-D.tsou-pcp-natcoord]
              Zhou, C., ZOU), T., Deng, X., Boucadair, M., and Q. Sun,
              "Using PCP To Coordinate Between the CGN and Home Gateway
              Via Port Allocation", draft-tsou-pcp-natcoord-03 (work in
              progress), July 2011.



Sun, et al.              Expires March 28, 2012                [Page 18]


Internet-Draft              stateless 4over6              September 2011


   [I-D.xli-behave-divi-pd]
              Li, X., Bao, C., Dec, W., Asati, R., Xie, C., and Q. Sun,
              "dIVI-pd: Dual-Stateless IPv4/IPv6 Translation with Prefix
              Delegation", draft-xli-behave-divi-pd-01 (work in
              progress), September 2011.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

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

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

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
































Sun, et al.              Expires March 28, 2012                [Page 19]


Internet-Draft              stateless 4over6              September 2011


Authors' Addresses

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

   Phone: +86-10-58552936>
   Email: sunqiong@ctbri.com.cn


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

   Phone: +86-10-58552116>
   Email: xiechf@ctbri.com.cn


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

   Phone: +86-10-62603059
   Email: yong@csnet1.cs.tsinghua.edu.cn


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

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


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




Sun, et al.              Expires March 28, 2012                [Page 20]


Internet-Draft              stateless 4over6              September 2011


   Phone: +86-10-62785822
   Email: weapon@csnet1.cs.tsinghua.edu.cn


   Cathy Zhou
   Huawei Technologies
   Section B, Huawei Industrial Base, Bantian Longgang
   Shenzhen  518129
   P.R.China

   Phone: +86-10-58552116>
   Email: cathyzhou@huawei.com


   Yiu L. Lee
   Comcast
   One Comcast Center
   Philadelphia, PA  19103
   USA

   Email: yiu_lee@cable.comcast.com






























Sun, et al.              Expires March 28, 2012                [Page 21]