Skip to main content

Deployment Considerations for Lightweight 4over6
draft-sun-softwire-lightweigh-4over6-deployment-01

The information below is for an old version of the document.
Document Type
This is an older version of an Internet-Draft whose latest revision state is "Expired".
Authors Qiong Sun , Chongfeng Xie , Yiu Lee
Last updated 2012-03-12
RFC stream (None)
Formats
Stream Stream state (No stream defined)
Consensus boilerplate Unknown
RFC Editor Note (None)
IESG IESG state I-D Exists
Telechat date (None)
Responsible AD (None)
Send notices to (None)
draft-sun-softwire-lightweigh-4over6-deployment-01
Network Working Group                                             Q. Sun
Internet-Draft                                                    C. Xie
Intended status: Standards Track                           China Telecom
Expires: September 13, 2012                                       Y. Lee
                                                                 Comcast
                                                          March 12, 2012

            Deployment Considerations for Lightweight 4over6
           draft-sun-softwire-lightweigh-4over6-deployment-01

Abstract

   Lightweight 4over6 is a mechanism which moves the translation
   function from tunnel Concentrator (AFTR) to Initiators (B4s), and
   hence reduces the mapping scale on the Concentrator to per-customer
   level.  This document discusses various deployment models of
   Lightweight 4over6.  It also describes the deployment considerations
   and applicability of the Lightweight 4over6 architecture.

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

   This Internet-Draft will expire on September 13, 2012.

Copyright Notice

   Copyright (c) 2012 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

Sun, et al.            Expires September 13, 2012               [Page 1]
Internet-Draft        lightweigh-4over6-deployment            March 2012

   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.  Requirements Language  . . . . . . . . . . . . . . . . . . . .  4
   3.  Case Studies . . . . . . . . . . . . . . . . . . . . . . . . .  5
     3.1.  case 1: Standalone Deployment Scenario . . . . . . . . . .  5
     3.2.  Case 2: Integrated Network Element with Lightweight
           4over6 and DS-Lite AFTR Scenario . . . . . . . . . . . . .  5
     3.3.  case 3: DS-Lite Coexistent scenario with Seperated AFTR  .  6
   4.  Overall Deployment Considerations  . . . . . . . . . . . . . .  8
     4.1.  Addressing and Routing . . . . . . . . . . . . . . . . . .  8
     4.2.  Port-set Management  . . . . . . . . . . . . . . . . . . .  8
     4.3.  Concentrator Discovery . . . . . . . . . . . . . . . . . .  8
   5.  Concentrator Deployment Consideration  . . . . . . . . . . . .  9
     5.1.  Logging at the Concentrator  . . . . . . . . . . . . . . .  9
     5.2.  Reliability Considerations of Concentrator . . . . . . . .  9
     5.3.  Placement of AFTR  . . . . . . . . . . . . . . . . . . . .  9
     5.4.  Port set algorithm consideration . . . . . . . . . . . . . 10
   6.  Acknowledgement  . . . . . . . . . . . . . . . . . . . . . . . 11
   7.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 12
   Appendix 1.  Appendix:Experimental Result  . . . . . . . . . . . . 14
     1.1.  Experimental environment . . . . . . . . . . . . . . . . . 14
     1.2.  Experimental results . . . . . . . . . . . . . . . . . . . 15
     1.3.  Conclusions  . . . . . . . . . . . . . . . . . . . . . . . 16
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 17

Sun, et al.            Expires September 13, 2012               [Page 2]
Internet-Draft        lightweigh-4over6-deployment            March 2012

1.  Introduction

   Lightweight 4over6 [I-D.cui-softwire-b4-translated-ds-lite] is an
   extension to DS-Lite which simplifies the AFTR module [RFC6333] with
   distributed NAT function among B4 elements.  The Initiator in
   Lightweight 4over6 is provisioned with an IPv6 address, an IPv4
   address and a port-set.  It performs NAPT on end user's packets with
   the provisioned IPv4 address and port-set.  IPv4 packets are
   forwarded between the Initiator and the Concentrator over a Softwire
   using IPv4-in-IPv6 encapsulation.  The Concentrator maintains one
   mapping entry per subscriber with the IPv6 address, IPv4 address and
   port-set.  Therefore, this extension removes the NAT44 module from
   the AFTR and replaces the session-based NAT table to a per-subscriber
   based mapping table.  This should relax the requirement to create
   dynamic session-based log entries.  This mechanism preserves the
   dynamic feature of IPv4/IPv6 address binding as in DS-Lite, so it
   won't require to couple IPv4 and IPv6 address schemas as MAP
   [I-D.mdt-softwire-mapping-address-and-port] requires.  This document
   discusses various deployment models of Lightweight 4over6.  It also
   describes the deployment considerations and applicability of the
   Lightweight 4over6 architecture.

   Terminology of this document follows the definitions and
   abbreviations of [I-D.cui-softwire-b4-translated-ds-lite].

Sun, et al.            Expires September 13, 2012               [Page 3]
Internet-Draft        lightweigh-4over6-deployment            March 2012

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 September 13, 2012               [Page 4]
Internet-Draft        lightweigh-4over6-deployment            March 2012

3.  Case Studies

   Lightweight 4over6 can be either deployed by itself, or combined with
   DS-Lite [RFC6333].  Lightweight 6over4 is suitable for operators who
   have many small and discontinued IPv4 blocks and would like to
   separate IPv4 and IPv6 address schemas.  Compared to other
   technologies such as [I-D.mdt-softwire-mapping-address-and-port] and
   [I-D.despres-softwire-4rd-u], this mechanism won't require operators
   to administrate and manage IPv4 and IPv6 mapping rules planning in
   CPE and in the network.

3.1.  case 1: Standalone Deployment Scenario

   Lightweight 4over6 can be deployed in a new residential network
   (depicted in Figure1).  In this scenario, an Initiator would acquire
   an IPv4 address and a port-set after successful user authentication
   process and IPv6 provisioning process.  Then, it establishes an IPv4-
   in-IPv6 softwire using the IPv6 address to deliver IPv4 services to
   its connected host via the Concentrator in the network.  The
   Concentrator supports only Lightweight 4over6 which keeps the mapping
   between Initiator's IPv6 address and its allocated IPv4 address +
   port set.

                    +---------------+--------------|
                    +               |              |
+---------+  +------+---+        +--+--+           |
|  Host   |  | LW 4over6|        |     |           |
|         |--| Initiator| ======-| BNG | === +---------+   +-----------+
+---------+  +----------+        +--|--+     |LW 4over6|   |   IPv4    |
                                             |Concen-  |---| Internet  |
+---------+  +------+---+        +--+--+     |trator   |   |           |
|  Host   |--| LW 4over6| =======|     | ====+---------+   +-----------+
|         |  | Initiator|        | BNG |           |
+---------+  +----------+        +--|--+           |
                    +               |              |
                    +---------------+--------------+

   Figure 1 Standalone Deployment Scenario

3.2.  Case 2: Integrated Network Element with Lightweight 4over6 and DS-
      Lite AFTR Scenario

   Lightweight 4over6 can be deployed incrementally in existing DS-Lite
   network (depicted in Figure2).  In this case, DS-Lite has been
   deployed in the network.  Later in the deployment schedule, the
   operator decided to implement Lightweight 4over6 Concentrator
   function in the same network element.  Therefore, the same network
   element needs to support both transition mechanisms.  Two transition

Sun, et al.            Expires September 13, 2012               [Page 5]
Internet-Draft        lightweigh-4over6-deployment            March 2012

   mechanisms can be distinguished using the client!_s source IPv4
   address.  The IPv4 address from Lightweight 4over6 is public address
   as NAT has been done in the Initiator, and IPv4 address for DS-lite
   is private address as NAT will be done on AFTR.  When the network
   element receives an encapsulated packet, it would de-capsulate packet
   and apply the transition mechanism based on the IPv4 source address
   in the packet.  This requires the network element to examine every
   packet and may introduce significant load to the network element.

   Lightweight 4over6 and DS-Lite use the same addressing scheme,
   routing policy, user management policy, etc.  Since Lightweight
   4over6 and DS-Lite is located in the same element network, both the
   B4 element and Lightweight 4over6 Initiator can use the same DHCPv6
   option [RFC6334] to discover the FQDN of the AFTR and Concentrator.

                    +---------------+--------------|
                    +               |              |
+---------+  +------+---+        +--+--+           |
|  Host   |  | LW 4over6|        |     |           |
|         |--| Initiator| ======-| BNG | === +-------------+   +-----------+
+---------+  +----------+        +--|--+     |LW 4over6    |   |   IPv4    |
                                             |Concentrator/|---| Internet  |
+---------+  +------+---+        +--+--+     |DS-Lite AFTR |   |           |
|  Host   |--| DS-Lite  | =======|     | ====+-------------+   +-----------+
|         |  |    B4    |        | BNG |           |
+---------+  +----------+        +--|--+           |
                    +               |              |
                    +---------------+--------------+

   Figure 2 DS-Lite Coexistence scenario with Integrated AFTR

3.3.  case 3: DS-Lite Coexistent scenario with Seperated AFTR

   This is similar to Case 2.  The difference is the Concentrator and
   AFTR functions won!_t be co-located in the same network element
   (depicted in Figure3).  This use case decouples the functions to
   allow more flexible deployment.  For example, an operator may deploy
   AFTR closer to the edge and Concentrator closer to the core.
   Moreover, it does not require the network element to pre-configure
   with the CPE's IPv6 addresses.  An operator can deploy more AFTR and
   Concentrator at needed.  However, this requires the B4 and Initiator
   to discover the corresponding network element.  B4 can continue to
   use [RFC6334] and [RFC6519] to discover AFTR.  It may require to
   define a new discover mechanism for Initiator to discover the
   Concentrator.  This discovery mechanism is out of scope.

                    +---+---------------+-----------------|
                    +                   |                 |

Sun, et al.            Expires September 13, 2012               [Page 6]
Internet-Draft        lightweigh-4over6-deployment            March 2012

+---------+  +------+---+        +------+-----+           |
|  Host   |  | LW 4over6|        |    BNG     |           |
|         |--| Initiator| ======-|DS-Lite AFTR| === +------------+   +-----------+
+---------+  +----------+        +------+-----+     |LW 4over6   |   |   IPv4    |
                                                    |Concentrator|---| Internet  |
+---------+  +------+---+        +------+-----+     |            |   |           |
|  Host   |--| DS-Lite  | =======|    BNG     | ====+------------+   +-----------+
|         |  |    B4    |        |DS-Lite AFTR|           |
+---------+  +----------+        +------+-----+           |
                    +                   |                 |
                    +-------------------+-----------------+

   Figure 3 DS-Lite Coexistence scenario with Integrated AFTR

Sun, et al.            Expires September 13, 2012               [Page 7]
Internet-Draft        lightweigh-4over6-deployment            March 2012

4.  Overall Deployment Considerations

4.1.  Addressing and Routing

   In Lightweight 4over6, there is no inter-dependency between IPv4 and
   IPv6 addressing schemes.  IPv4 address pools are configured
   centralized in Concentrator for IPv6 subscribers.  These IPv4 prefix
   must advertise to IPv4 Internet accordingly.

   For IPv6 addressing and routing, there are no additional addressing
   and routing requirements.  The existing IPv6 address assignment and
   routing announcement should not be affected, e.g. using PPPoE or
   IPoE, etc.

4.2.  Port-set Management

   In Lightweight 4over6, each Initiator will get its restricted IPv4
   address and a valid port-set.  This port-set assignment should be
   synchronized between port management server and the Concentrator.
   The port management server is responsible for allocating port
   restricted IPv4 address to the Initiator.  It can be new option to
   the DHCPv4 server [I-D.bajko-pripaddrassign].  The DHCPv4 server can
   either collocated in the Concentrator or a dedicated server.  If a
   dedicated server is used, the Concentrator must be the DHCP relay
   agent to the DHCPv4 server [I-D.ietf-dhc-dhcpv4-over-ipv6].

   Different mechanisms including PCP- extended protocol
   [I-D.tsou-pcp-natcoord], DHCP-extended protocol or IPCP-extended
   protocol, etc., can also be used.

   PCP-based mechanism is more flexible.  An Initiator can send multiple
   PCP requests simultaneously to acquire a number of ports or use
   [I-D.tsou-pcp-natcoord] for one-time port-set allocation.

4.3.  Concentrator Discovery

   A Lightweight 4over6 Initiator must discover the Concentrator's IPv6
   address before offering any IPv4 services.  This IPv6 address can be
   learned through an out-of-band channel, static configuration, and
   dynamic configuration.  For case 1 and case 2, Lightweight 4over6
   Initiator can use the same DHCPv6 option [RFC6334]to discover the
   FQDN of the Concentrator.  However, for case 3, a new discovery
   mechanism for Initiator to discover the Concentrator is required.

Sun, et al.            Expires September 13, 2012               [Page 8]
Internet-Draft        lightweigh-4over6-deployment            March 2012

5.  Concentrator Deployment Consideration

   As Lightweight 4over6 is an extension to DS-Lite, both technologies
   share similar deployment considerations.  For example: Interface
   consideration, MTU, Fragment, Lawful Intercept Considerations,
   Blacklisting a shared IPv4 Address, AFTR's Policies, AFTR Impacts on
   Accounting Process, etc., in [I-D.ietf-softwire-dslite-deployment]
   can also be applied here.  This document only discusses new
   considerations specific to Lightweight 4over6.

5.1.  Logging at the Concentrator

   In Lightweight 4over6, operators only log one entry per subscriber.
   The log should include subscriber!_s IPv6 address used for the
   softwire, the public IPv4 address and the port-set.  The port set
   algorithm implemented in Lightweight 4over6 Concentrator should be
   synchronized with the one implemented in logging system.  For
   example, if contiguous port set algorithm is adopted in the
   Concentrator, the same algorithm should also been applied to the
   logging system.

5.2.  Reliability Considerations of Concentrator

   In Lightweight 4over6, subscriber to IPv4 and port-set mapping must
   be pre-provisioned in the Concentrator before providing IPv4 serives.
   For redundancy, the backup Concentrator must either have the
   subscriber mapping already provisioned or notify the Initiator to
   create a new mapping in the backup Concentrator.  The first option
   can be consider as hot standby mode.  The second option may require a
   new notification mechanism which is outside the scope of this
   document.

5.3.  Placement of AFTR

   The Concentrator can be deployed in a "centralized model" or a
   "distributed model".

   In the "centralized model", the Concentrator could be located at the
   higher place, e.g. at the exit of MAN, etc.  Since the Concentrator
   has good scalability and can handle numerous concurrent sessions, we
   recommend to adopt the "centralized model" for Lightweight 4over6 as
   it is cost-effective and easy to manage.

   In the "distributed model", Concentrator is usually integrated with
   the BRAS/SR.  Since newly emerging customers might be distributed in
   the whole Metro area, we have to deploy Concentrator on all BRAS/SRs.
   This will cost a lot in the initial phase of the IPv6 transition
   period.

Sun, et al.            Expires September 13, 2012               [Page 9]
Internet-Draft        lightweigh-4over6-deployment            March 2012

5.4.  Port set algorithm consideration

   If each Initiator is given a set of ports, port randomization
   algorithm can only select port in the given port-set.  This may
   introduce security risk because hackers can make a more predictable
   guess of what port a subscriber may use.  Therefore, non-continuous
   port set algorithms (e.g. as defined in
   [I-D.mdt-softwire-mapping-address-and-port]) can be used to improve
   security.

Sun, et al.            Expires September 13, 2012              [Page 10]
Internet-Draft        lightweigh-4over6-deployment            March 2012

6.  Acknowledgement

   TBD

Sun, et al.            Expires September 13, 2012              [Page 11]
Internet-Draft        lightweigh-4over6-deployment            March 2012

7.  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]
              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-dhc-dhcpv4-over-ipv6]
              Cui, Y., Wu, P., Wu, J., and T. Lemon, "DHCPv4 over IPv6
              transport", draft-cui-dhc-dhcpv4-over-ipv6-00 (work in
              progress), October 2011.

   [I-D.cui-softwire-b4-translated-ds-lite]
              Boucadair, M., Sun, Q., Tsou, T., Lee, Y., and Y. Cui,
              "Lightweight 4over6: An Extension to DS-Lite
              Architecture", draft-cui-softwire-b4-translated-ds-lite-05
              (work in progress), February 2012.

   [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.despres-softwire-4rd-u]
              Despres, R., Penno, R., Qin, J., Lee, Y., and G. Chen,
              "IPv4 Residual Deployment via IPv6 - Unified Solution
              (4rd)", draft-despres-softwire-4rd-u-05 (work in
              progress), March 2012.

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

   [I-D.ietf-pcp-base]
              Cheshire, S., Boucadair, M., Selkirk, P., Wing, D., and R.
              Penno, "Port Control Protocol (PCP)",
              draft-ietf-pcp-base-23 (work in progress), February 2012.

   [I-D.ietf-softwire-dslite-deployment]

Sun, et al.            Expires September 13, 2012              [Page 12]
Internet-Draft        lightweigh-4over6-deployment            March 2012

              Lee, Y., Maglione, R., Williams, C., Jacquenet, C., and M.
              Boucadair, "Deployment Considerations for Dual-Stack
              Lite", draft-ietf-softwire-dslite-deployment-03 (work in
              progress), March 2012.

   [I-D.mdt-softwire-mapping-address-and-port]
              Bao, C., Troan, O., Matsushima, S., Murakami, T., and X.
              Li, "Mapping of Address and Port (MAP)",
              draft-mdt-softwire-mapping-address-and-port-03 (work in
              progress), January 2012.

   [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., Tsou, 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-04 (work in
              progress), January 2012.

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

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

   [RFC6431]  Boucadair, M., Levis, P., Bajko, G., Savolainen, T., and
              T. Tsou, "Huawei Port Range Configuration Options for PPP
              IP Control Protocol (IPCP)", RFC 6431, November 2011.

Sun, et al.            Expires September 13, 2012              [Page 13]
Internet-Draft        lightweigh-4over6-deployment            March 2012

1.  Appendix:Experimental Result

   We have deployed Lightweight 4over6 in our operational network of
   HuNan province, China.  It is designed for broadband access network,
   and different versions of Initiator have been implemented including a
   linksys box, a software client for windows XP, vista and Windows 7.
   It can be integrated with existing dial-up mechanisms such as PPPoE,
   etc.  The major objectives listed below aimed to verify the
   functionality and performance of Lightweight 4over6:

   o  Verify how to deploy Lightweight 4over6 in a practical network.

   o  Verify the impact of applications with Lightweight 4over6.

   o  Verify the performance of Lightweight 4over6.

1.1.  Experimental environment

   The network topology for this experiment is depicted in Figure 2.

                                             +--------+
+-----+  +---------+                         | Syslog |
|Host1+--+Initiator|--+                      | Server |     --------
+-----+  +---------+  |                      +---+----+   ///       \\\
                      |         /------\         |       //           \\
                      |        //      \\    +---+----+ |               |
+-----+  +---------+  +-+--+  |   IPv6   |   |        | | IPv4 Internet |
|Host2+--|Initiator|--+BRAS+--|  Network |---| Concen-+-+               |
+-----+  +---------+  +-+--+   \\      //    | trator |  \\            //
                       |        \---+--/     +--------+   \\\        ///
                       |           |                        ---------
+-----+  +---------+   |           |
|Host3+--+Initiator+---+           |
+-----+  +---------+               |                         --------
                                   |                       //        \\
                                   |                      /            \
                                   +---------------------+IPv6 Internet +
                                                         |              |
                                                          \            /
                                                           \\        //
                                                             -------

   Figure 2 Lightweight 4over6 experiment topology

   In this deployment model, Concentrator is co-located with a extended
   PCP server to assign restricted IPv4 address and port set for
   Initiator.  It also triggers subscriber-based logging event to a
   centrilized syslog server.  IPv6 address pools for subscribers have

Sun, et al.            Expires September 13, 2012              [Page 14]
Internet-Draft        lightweigh-4over6-deployment            March 2012

   been distributed to BRASs for configuration, while the public
   available IPv4 address pools are configured by the centralized
   Concentrator with a default address sharing ratio.  It is rather
   flexible for IPv6 addressing and routing, and there is little impact
   on existing IPv6 architecture.

   In our experiment, Initiator will firstly get its IPv6 address and
   delegated prefix through PPPoE, and then initiate a PCP-extended
   request to get public IPv4 address and its valid port set.  The
   Concentrator will thus create a subscriber-based state accordingly,
   and notify syslog server with {IPv6 address, IPv4 address, port set,
   timestamp}.

1.2.  Experimental results

   In our trial, we mainly focused on application test and performance
   test.  The applications have widely include web, email, Instant
   Message, ftp, telnet, SSH, video, Video Camera, P2P, online game,
   voip and so on.  For performance test, we have measured the
   parameters of concurrent session numbers and throughput performance.

   The experimental results are listed as follows:

   +--------------------+----------------------+-----------------------+
   |  Application Type  |   Test Result        |Port Number Occupation |
   +--------------------+----------------------+-----------------------+
   |   Web              |         ok           | normal websites: 10~20|
   |                    | IE, Firefox, Chrome  | Ajex Flash webs: 30~40|
   +--------------------+----------------------+-----------------------+
   |   Video            |   ok, web based or   |      30~40            |
   |                    |   client based       |                       |
   +--------------------+----------------------+-----------------------+
   |   Instant Message  |         ok           |                       |
   |                    | QQ, MSN, gtalk, skype|       8~20            |
   +--------------------+----------------------+-----------------------+
   |   P2P              |         ok           | lower speed: 20~600   |
   |                    |utorrent,emule,xunlei | (per seed)            |
   |                    |                      | higher speed: 150~300 |
   +--------------------+----------------------+-----------------------+
   |   FTP              | need ALG for active  |       2               |
   |                    |  mode, flashxp       |                       |
   +--------------------+----------------------+-----------------------+
   |   SSH, TELNET      |         ok           |1 for SSH, 3 for telnet|
   +--------------------+----------------------+-----------------------+
   |   online game      | ok for QQ, flash game|    20~40              |
   +--------------------+----------------------+-----------------------+

   Figure 3 Lightweight 4over6 experimental result

Sun, et al.            Expires September 13, 2012              [Page 15]
Internet-Draft        lightweigh-4over6-deployment            March 2012

   The performance test for Concentrator is taken on a normal PC.  Due
   to limitations of the PC hardware, the overall throughput is limited
   to around 800 Mbps.  However, it can still support more than one
   hundred million concurrent sessions.

1.3.  Conclusions

   From the experiment, we can have the following conclusions:

   o  Lightweight 4over6 has good scalability.  As it is a lightweight
      solution which only maintains per-subscriber state information, it
      can easily support a large amount of concurrent subscribers.

   o  Lightweight 4over6 can be deployed rapidly.  There is no
      modification to existing addressing and routing system in our
      operational network.  And it is simple to achieve traffic logging.

   o  Lightweight 4over6 can support a majority of current IPv4
      applications.

Sun, et al.            Expires September 13, 2012              [Page 16]
Internet-Draft        lightweigh-4over6-deployment            March 2012

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

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

   Email: yiu_lee@cable.comcast.com

Sun, et al.            Expires September 13, 2012              [Page 17]