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

Versions: 00 draft-huang-v6ops-v4v6tran-bb-usecase

Internet Engineering Task Force                                  H. Tian
Internet-Draft                                            CC. Huang, Ed.
Intended status: Informational                                    XY. Li
Expires: March 19, 2011                                    China Telecom
                                                      September 15, 2010


    Use Case For IPv6 Transition For a Large-Scale Broadband Service
                                Provider
              draft-tian-v4v6tran-broadband-sp-usecase-00

Abstract

   This document describes an use case for migration from IPv4 to IPv6
   for China Telecom, a major operator serving both fixed and mobile
   subscribers.

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 March 19, 2011.

Copyright Notice

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



Tian, et al.             Expires March 19, 2011                 [Page 1]


Internet-Draft     Broadband Service Provider Use Case    September 2010


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
     1.1.  Requirements Language  . . . . . . . . . . . . . . . . . .  6
   2.  Experiments in Backbone Network Migration  . . . . . . . . . .  6
     2.1.  Solution 1: 6PE in the MPLS Network  . . . . . . . . . . .  6
     2.2.  Solution 2: Dual Stack in the IP Network . . . . . . . . .  6
     2.3.  Solution 3: Creating a New IPv6-only Network . . . . . . .  6
   3.  Experiments in Metro Network Migration . . . . . . . . . . . .  6
     3.1.  Solution 1 . . . . . . . . . . . . . . . . . . . . . . . .  7
     3.2.  Solution 2 . . . . . . . . . . . . . . . . . . . . . . . .  7
     3.3.  Solution 3 . . . . . . . . . . . . . . . . . . . . . . . .  7
     3.4.  Solution 4 . . . . . . . . . . . . . . . . . . . . . . . .  7
   4.  Experiments in Access Network Migration  . . . . . . . . . . .  7
     4.1.  Solution 1 . . . . . . . . . . . . . . . . . . . . . . . .  7
     4.2.  Solution 2 . . . . . . . . . . . . . . . . . . . . . . . .  8
     4.3.  Solution 3 . . . . . . . . . . . . . . . . . . . . . . . .  8
   5.  Experiments in UE Access Migration . . . . . . . . . . . . . .  8
     5.1.  Solution 1: Acquire Dual Stack Address From Dual Stack
           BRAS . . . . . . . . . . . . . . . . . . . . . . . . . . .  8
     5.2.  Solution 2: Acquire Dual Stack Address Via  IPv6-Only
           BRAS . . . . . . . . . . . . . . . . . . . . . . . . . . .  9
     5.3.  Solution 3: Acquire Dual Stack Addresses Via IPv4-Only
           BRAS . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
     5.4.  Solution 4: Acquire IPv6 Address From  IPv6-Only BRAS  . . 10
   6.  Experiments in Internet Content Provider (ICP) Migration . . . 11
     6.1.  Provide Protocol Translation at the ICP  . . . . . . . . . 11
   7.  Challenges Faced In Migrating To IPv6  . . . . . . . . . . . . 12
   8.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 12
   9.  Security Considerations  . . . . . . . . . . . . . . . . . . . 12
   10. Informative References . . . . . . . . . . . . . . . . . . . . 13
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13



















Tian, et al.             Expires March 19, 2011                 [Page 2]


Internet-Draft     Broadband Service Provider Use Case    September 2010


1.  Introduction

   China Telecom is one of the largest operators in the world, with more
   than 60 million broadband subscribers, increasing at a rate of 10
   million subscribers annually.

   China Telecom is facing unprecedented pressure in business aspect,
   with the Global IPv4 address exhaustion.  Therefore CT's network and
   services will migrate to IPv6 eventually.  However, during the
   transition procedure, China Telecom seriously concerned about the
   transition of existing services in order to support the v4v6
   coexistent environment, along with the researches and developments of
   new services and applications.  CT's network is so large with various
   types of service that the transition to IPv6 is doomed to be
   complicated and difficult.

   The network structure of China Telecom is shown in Figure 1.  As this
   figure shows, the network in China Telecom comprises three segments:
   backbone network, metro network(MAN) which includs Core Router(CR),
   Aggregation Router(AR) and Broadband Remote Access Server(BRAS), and
   access network that from BRAS to users' Customer Premises
   Equipment(CPE).





























Tian, et al.             Expires March 19, 2011                 [Page 3]


Internet-Draft     Broadband Service Provider Use Case    September 2010


   +-------------------------------------+  +-------------------+
   |           CT's backbone             |  |  External backbone|
   | +-----------+       +-------------+ |  |   +-----------+   |
   | |IP backbone|       |MPLS backbone| |  |   |  IPv6     |   |
   | |(Chinanet) |       |    (CN2)    | |  |   | Internet  |   |
   | +-----------+       +-------------+ |  |   +-----------+   |
   +-------------------------------------+  +-------------------+
   +------------------------------------------------------------+
   |           CT's Metro Area Network                          |
   |+---------------------------------------------------------+ |
   ||            Core Router                                  | |
   ||                           +-----------------------------+ |
   ||                           | +---------------------------+ |
   ||                           | |   Aggregation Router      | |
   |+---------------------------+ +---------------------------+ |
   |+-----------------------------------+ +-------------------+ |
   ||           BRAS                    | |  Service Router   | |
   |+-----------------------------------+ +-------------------+ |
   +------------------------------------------------------------+
   +------------------------------------------------------------+
   |           CT's Access Netrwork                             |
   | +--------------------------------------------------------+ |
   | |                    Aggregation Switch                  | |
   | +--------------------------------------------------------+ |
   | +--------------------------+ +---------------------------+ |
   | |       OLT                | |         DSLAM             | |
   | +--------------------------+ +---------------------------+ |
   | +--------------------------+ +---------------------------+ |
   | |       ONT                | |         ONU               | |
   | +--------------------------+ +---------------------------+ |
   +------------------------------------------------------------+
   +------------------------------------------------------------+
   |      Customer Premises Network                             |
   | +--------------------------+ +---------------------------+ |
   | | Routed Mode CPE          | |  Bridged Mode CPE         | |
   | +--------------------------+ +---------------------------+ |
   | +--------------------------------------------------------+ |
   | |             User End                                   | |
   | +--------------------------------------------------------+ |
   +------------------------------------------------------------+

             Figure 1: Structure of the China Telecom Network

   The backbone network provides long distance transmission for the
   broadbandtraffic, which includes an IP backbone (ChinaNet) and a MPLS
   one (CN2).  The former one provides Internet service for home users
   and SME (Small and Medium Enterprise) users (named as public users in
   CT) while the latter one provides VPN and leased line services for



Tian, et al.             Expires March 19, 2011                 [Page 4]


Internet-Draft     Broadband Service Provider Use Case    September 2010


   the enterprise customers.  Considering the IPv6 capability, MPLS
   backbone supports 6PE already, and the network devices in IP backbone
   supports IPv6 basic protocol though 90 percent of the software needs
   to be updated.

   The metro network is mainly composed of Core Routers, Aggregation
   Routers, and BRASs.  CR, as the egress router of the metro network,
   is connected to both IP backbone and MPLS backbone.  Most BRASs are
   connected directly to Core Routers, but a small portion of the BRASs
   in some large metro networks are connected to Core Routers via
   Aggregation Routers.  China Telecom operates over 300 metro networks.

   The access network provides broadband access service for the users.
   It mainly includes layer 2 devices (e.g., DSLAM, Aggregation Switch).
   Broadband access service is provided over ADSL, LAN, PON and so on.
   In China Telecom's access network, the IPv6 capability is limitated
   due to some security considerations (IP-Based ACLs or policies).
   However, hosts can acquire IPv6 address through PPPoE to avoid the
   problem.

   With respect to the terminals, the Windows(TM) OS dominates in the
   China market, 92% of which is Windows XP.  The PPPoE dial terminal
   can not support IPv6, and the CPE Home Gateway is purchased by the
   users themselves.  The CPE can operate either in routing or in
   bridged mode, which is unmanageable by China Telecom.  Although most
   CPE is in bridging mode designed for PPPoE dial-up from hosts, many
   users deployed a Wireless AP at home which can dial-up automatically.
   All these APs cannot support gathering IPv6 address via PPPoE., .  On
   the other hand, the costs of CPE replacement, with the number of more
   than 60 million subscribers are unacceptable by China Telecom.

   During the migration to IPv6, the transition strategies and
   technologies selection becomes one of the most significantissues for
   China Telecom due to the complexity of both the network and the
   services, the large number of scenarios and the multiple methods of
   terminal and user access.  However, there is no universally
   applicable solution or guideline for the migration of network and
   services to native IPv6 in the industry yet.  Each operator is
   looking for the appropriate transition strategy for itself.

   To investigate the impact of various transition technologies on
   network and services and select correct migration procedures, China
   Telecom has planned a number of IPv6 experiments, e.g., to support
   the world university summer games in Shenzhen in 2011, and to test UE
   access and multimedia IPv6 services for Shanghai EXPO, 2010.  China
   Telecom has also made a lot of experiments on its existing networks,
   covering the backbone network, metro network, packet area, terminals,
   service platforms, and the provisioning systems.  The most



Tian, et al.             Expires March 19, 2011                 [Page 5]


Internet-Draft     Broadband Service Provider Use Case    September 2010


   appropriate and operational end-to-end solutions will be worked out
   from the results of these experiments to guide the migration of
   network and services.

   In this document, several possible migration scenarios applicable to
   China Telecom are introduced.  Related testing solutions and problems
   are also introduced.  Note that all the scenarios have corresponding
   deployment solutions, but not all the solutions have been tested due
   to lack of device capability.

1.1.  Requirements Language

   This document is descriptive, and therefore contains no requirements
   language.


2.  Experiments in Backbone Network Migration

   As stated in Section 1, the backbone network is composed of an IP
   backbone (ChinaNet) and an MPLS backbone (CN2).  The migration
   solutions considered by China Telecom include 6PE in CN2, dual stack
   capability in ChinaNet, and building up a new IPv6-only backbone
   network.

2.1.  Solution 1: 6PE in the MPLS Network

   CN2 provides VPN service for the large scale enterprise customers.
   When the whole network deploys MPLS, 6PE [rfc4798] can be used to
   provide IPv6 transmission. 6PE is enabled in four nodes of the
   backbone network to carry IPv6 traffic.  There is no problem for 6PE
   to carry IPv6 traffic in the experiment.

2.2.  Solution 2: Dual Stack in the IP Network

   This is still in trial, not finished yet.

2.3.  Solution 3: Creating a New IPv6-only Network

   The new IPv6-only network covers seven POP nodes with no problem to
   support the basic IPv6 protocol.  The problem is that there is no
   enough traffic and no successive maintenance support.


3.  Experiments in Metro Network Migration

   The metro network here means the network from BRAS to metro exit
   router, including the network from BRAS to core router which is also
   the egress router to the backbone.



Tian, et al.             Expires March 19, 2011                 [Page 6]


Internet-Draft     Broadband Service Provider Use Case    September 2010


3.1.  Solution 1

   This solution requires modification of the existing network.  In this
   solution, the Core Routers in the original metro network should be
   upgraded to dual stack.  Old BRASs that can be upgraded to dual stack
   are also upgraded; BRASs that cannot be upgraded remain as IPv4.
   Newly added BRASs support dual stack.  Dual stack technology itself
   has no problem.  But not all the devices can be upgraded at the same
   time.

3.2.  Solution 2

   This also involves modification of the existing network.  The
   approach is the same for existing equipment as for solution 1.  The
   difference from solution 1 is that newly added BRASs support IPv6
   only.  Testing of this solution is planned for later.

3.3.  Solution 3

   Creation of a new dual stack network.  The new Core Routers and BRASs
   are dual stack and provide a dual stack overlay with no change to the
   existing network.  Testing of this solution is planned for later.

3.4.  Solution 4

   Creation of a new IPv6 network.  The new Core Routers and BRASs are
   IPv6 only and provide an IPv6 overlay with no change to the existing
   network.  Testing of this solution is planned for later.


4.  Experiments in Access Network Migration

   The access network includes the network from the user terminal to
   BRAS, including DSLAM, aggregation switch and so on.  The access
   network is layer 2 in China Telecom, and can transmit IPv6 traffic
   transparently.  As mentioned above, the access network cannot carry
   IPv6 traffic directly due to some security aspects, but the user can
   acquire an IP address by PPPoE dial-up [RFC2516] which avoids the
   above problem.

4.1.  Solution 1

   Modify the existing network, and add new IPv6 aware access devices
   without changing the old devices.  Not tested yet.







Tian, et al.             Expires March 19, 2011                 [Page 7]


Internet-Draft     Broadband Service Provider Use Case    September 2010


4.2.  Solution 2

   Modify the existing network and add new IPv6 aware access devices
   with upgrade or change of the old devices.  Not tested yet.

4.3.  Solution 3

   Create a new access network.  Not tested yet.


5.  Experiments in UE Access Migration

   The subscribers of China Telecom acquire IP addresses from the BRAS
   through PPPoE to visit the Internet.  The possible approaches to
   address acquisition can be categorized as follows.

5.1.  Solution 1: Acquire Dual Stack Address From Dual Stack BRAS

   The user acquires dual stack addresses from the BRAS in the following
   scenarios:

   1.  Scenario 1 of metro network migration

   2.  Old upgradable BRAS in scenario 2 of metro network migration

   3.  Scenario 3 of metro network migration.

   When not enough public IPv4 addresses are available, the BRAS
   allocates a private IPv4 address to the user, thus requiring a NAT44
   CGN device in the metro network.  The NAT44 CGN can be deployed at
   two locations based on the routing plan of metro network: centralized
   (collocated with the Core Router), or distributed (collocated with
   the BRAS).

   In the solution verification, some problems with NAT444 became
   apparent:

   o  Single-Sign-On (SSO) of the website:

      *  The user's IPv4 private address is allocated by the BRAS after
         the AAA process, so only the user's private IPv4 address is
         mapped with the user account in the AAA system.  In some cases,
         a website may carry out SSO authentication with the user's IP
         address via carrier's AAA server.

      *  The user accesses the Internet website with a public address,
         while the address in the carrier's AAA Server is a private
         address.  So the user cannot be authorized.



Tian, et al.             Expires March 19, 2011                 [Page 8]


Internet-Draft     Broadband Service Provider Use Case    September 2010


   o  VPN authentication:

      *  In L2TP [RFC3931] and NAT444 environments with the user
         creating the VPN itself, if the user wants to access the
         enterprise internal network via VPN, some authentication
         protocols such as EAP, may not be supported in these two
         environments.

   o  Flow Analysis System and Behavior Analysis System:

      *  The carrier's existing flow analysis and behavior analysis
         systems are centralized and deployed in the backbone.  In the
         NAT444 environment, they both need to be placed before the NAT
         device, in order to collect users' data and analyse their
         behavior accurately according to their IPv4 addresses.

   o  Internet users initiating access to private network users.

      Currently two access methods are considered in the metropolitan
      area network:

      *  Communication between private IP hosts.  The traffic will not
         go through a NAT444 device.

      *  Communication between private IP host and public one.  The
         traffic will go through a NAT444 device.

      If the user wants to visit a website which is provided by a
      private address host, it is not accessible.

   o  NAT444 doesn't support the current PPTP VPN.

5.2.  Solution 2: Acquire Dual Stack Address Via  IPv6-Only BRAS

   The user has to acquire dual stack addresses from an IPv6-only BRAS
   in the following scenarios:

   1.  Scenario 2 of metro network migration

       In this case, there are two methods to acquire IP addresses.  One
       is to create a L2TP tunnel from the IPv6-only BRAS to a dual
       stack BRAS which can allocate dual stack addresses for the user.
       Another way is to deploy a DS-Lite device in the metro network
       and CPE devices which can support DS-Lite
       [ID_softwire-dual-stack-lite].

   2.  Scenario 4 of metro network migration




Tian, et al.             Expires March 19, 2011                 [Page 9]


Internet-Draft     Broadband Service Provider Use Case    September 2010


       Deploy DS-Lite in the edge of metro network and provide DS-Lite
       supported CPE to the user because the new Core Router and BRAS
       are both IPv6 only.

   In these two scenarios, NAT44 CGN device needs to be deployed in the
   metro network because the IPv4 addresses the user acquires are IPv4
   private addresses.  DS-Lite is not tested due to lack of DS-Lite-
   capable devices.

5.3.  Solution 3: Acquire Dual Stack Addresses Via IPv4-Only BRAS

   The user has to acquire dual stack addresses from an IPv4-only BRAS
   in the following scenarios:

   1.  Scenario 1 of metro network migration

       Create a L2TP tunnel from the old BRAS (which could not be
       upgraded to dual stack) to the dual stack BRAS to acquire dual
       stack addresses.

   2.  Scenario 2 of metro network migration

       Create a L2TP tunnel from the old BRAS (which could not be
       upgraded to dual stack) to the dual stack BRAS to acquire dual
       stack addresses, as above.

   3.  Scenario 3 of metro network migration

       Deploy 6RD in the old metro network and provide 6RD-supporting
       CPE to users served by the old BRAS to acquire dual stack
       address, since the old BRAS maintains IPv4 only.

   4.  Scenario 4 of metro network migration

       Same as the previous scenario.

5.4.  Solution 4: Acquire IPv6 Address From  IPv6-Only BRAS

   The user acquires an IPv6 address from an IPv6-only BRAS in the
   following scenarios:

   1.  Scenario 2 of metro network migration

       The user acquires an IPv6 address from the IPv6-only BRAS.  There
       are two ways to access the IPv4 Internet and communicate with
       IPv4 users.  One is to deploya protocol translation gateway in
       the old metro network and another one is to deploy DS-Lite and
       provide DS-Lite supported CPE to achieve IPv4/IPv6 communication.



Tian, et al.             Expires March 19, 2011                [Page 10]


Internet-Draft     Broadband Service Provider Use Case    September 2010


   2.  Scenario 4 of metro network migration

       The user acquires IPv6 address from the IPv6 only BRAS.  There
       are three ways to access IPv4 Internet and communicate with IPv4
       users.  One is to deploy a protocol translation gateway in the
       new IPv6 only metro network and at the edge of the old metro
       network.  Another one is to deploy a protocol translation gateway
       in the old metro network.  A third one is to deploy DS-Lite and
       provide DS-Lite supported CPE to achieve IPv4/IPv6 communication.


6.  Experiments in Internet Content Provider (ICP) Migration

   Internet Content Provider (ICP) migration to IPv6 is the most
   important step to break the deadlock in the IPv6 industry chain.  The
   ICP can migrate itself, or can be supported by the operatorthat
   provides typical Internet applications (e.g., web and email) to it.
   For the migration of ICP itself, China Telecom has modified its
   proprietary web mail 189.cn.  In addition, the solutions to provide
   protocol translation to assist ICP's migration include the following:

6.1.  Provide Protocol Translation at the ICP

   The operator can provide protocol translation service for the ICP
   inside the IDC [Internet Data Center] by deploying a protocol
   translation device at the IDC exit.

   We make some improvements to the existing NAT-PT devices since NAT-PT
   technology has been terminated and there is no mature commercial
   NAT64 device yet.  The AAAA record of the ICP's IPv6 address is
   stored in the ICP DNS authorization Server to substitute the DNS64
   function.  This IPv6 address is constituted by combining the ICP's
   IPv4 public address and the operator's prefix.  The procedure is as
   below:

   1.  The user queries the corresponding IP address of the ICP domain
       name from DNS.

   2.  The DNS cache server replies with the ICP's IPv6 address.  (This
       address is updated regularly by the ICP authorization server.)

   3.  The user will use this IPv6 address to visit the IPv4
       applications.  The BRAS will direct it to the IDC protocol
       translation server which will then drop the prefix to acquire the
       original IPv4 address of the ICP and forward the packet to the
       IPv4 server of the ICP.





Tian, et al.             Expires March 19, 2011                [Page 11]


Internet-Draft     Broadband Service Provider Use Case    September 2010


7.  Challenges Faced In Migrating To IPv6

   When upgrading from IPv4 to IPv6, China Telecom, like other carriers,
   faces a long list of challenges:

   o  The remaining stock of IPv4 addresses cannot support the
      development of existing services.  China Telecom not only cares
      about future service development, but also the transition of
      existing services to IPv6.

   o  Not enough sites are running IPv6.  ICP has deployed little IPv6,
      and almost no Content Provider/Service Provider (CP/SP) considers
      IPv6 when developing proprietary services because of the large
      code change.  The applications of ICPs are of various types and so
      complex that they cannot all support IPv6 in a short time.  In
      addition, many business websites are always linking to each other,
      creating a complex topology which will lead to many problems when
      one website migrates to IPv6 only.  Another reason ICP migration
      lacks motivation is that the CP/SP does not realize how urgent it
      is to migrate to IPv6.

   o  From the perspective of terminals, some specific terminals (e.g.,
      set top boxes) do not support IPv6 even if the main operating
      systems can do so.  Most mobile terminals (CDMA) do not currently
      support IPv6, although this is a temporary situation.

   o  No accumulated experience with IPv6 transition.Large scale network
      and large number of subscribers are the two key problems China
      Telecom has to face in IPv6 transition.  With large scale network
      and various service platforms, the transition involves multiple
      levels and broad scope, so the cost of modification will be huge
      and the return on investment will not be so evident.  The
      selection of transition technology and network modification
      solution is not clear for the transition roadmap of the whole
      network.


8.  IANA Considerations

   This memo includes no request to IANA.


9.  Security Considerations

   The IETF is specifying security considerations for the tools that it
   is providing for IPv6 migration.  However, it is possible that
   additional considerations arise due to the interaction of these
   tools, and the fact that the network is in a transitional state.



Tian, et al.             Expires March 19, 2011                [Page 12]


Internet-Draft     Broadband Service Provider Use Case    September 2010


   China Telecom has a particular incentive to discern and take account
   of any such considerations, because as a result of its scale, the
   potential losses due to loss of security can be very large.


10.  Informative References

   [ID_softwire-dual-stack-lite]
              Durand, A., droms, R., Woodyat, J., and Y. Lee, "Dual-
              Stack Lite Broadband Deployments Following IPv4 Exhaustion
              (Work in                          progress)", August 2010.

   [RFC2516]  Mamakos, L., Lidl, K., Evarts, J., Carrel, D., Simone, D.,
              and R. Wheeler, "A Method for Transmitting PPP Over
              Ethernet (PPPoE)", RFC 2516, February 1999.

   [RFC3931]  Lau, J., Townsley, M., and I. Goyret, "Layer Two Tunneling
              Protocol - Version 3 (L2TPv3)", RFC 3931, March 2005.


Authors' Addresses

   Hong Tian
   China Telecom
   No.31, Jinrong Ave,Xicheng District,100032
   Beijing,   100032
   P.R. China

   Phone:
   Email:


   Cancan Huang (editor)
   China Telecom
   109 East Zhongshan Road,
   Tiahne District, Guangzhou  510600
   P.R. China

   Phone:
   Email: cancanhuang110@gmail.com











Tian, et al.             Expires March 19, 2011                [Page 13]


Internet-Draft     Broadband Service Provider Use Case    September 2010


   XiaoYang Li
   China Telecom
   109 East Zhongshan Road,
   Tiahne District, Guangzhou  510600
   P.R. China

   Phone:
   Email:











































Tian, et al.             Expires March 19, 2011                [Page 14]


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