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

Versions: 00 draft-yang-v6ops-v4v6tran-bb-transition-guide

Internet Engineering Task Force                             G. Yang, Ed.
Internet-Draft                                                     L. Hu
Intended status: Informational                                    J. Lin
Expires: March 19, 2011                                    China Telecom
                                                      September 15, 2010


    IPv6 Transition Guide For A Large ISP Providing Broadband Access
              draft-yang-v4v6tran-ipv6-transition-guide-00

Abstract

   This document provides a transition guide for a large-scale provider
   of broadband access migrating its network from IPv4 to IPv6.

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.





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


Internet-Draft    Broadband Access Provider Transition    September 2010


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
     1.1.  Requirements Language  . . . . . . . . . . . . . . . . . .  5
   2.  Overview of Solutions for IPv6 Migration Mentioned In the
       China Telecom Use Case Document  . . . . . . . . . . . . . . .  5
     2.1.  Transition For the Backbone Network  . . . . . . . . . . .  6
       2.1.1.  Upgrade to Dual stack on existing IP Backbone  . . . .  6
       2.1.2.  Building New Native IPv6-Only Backbone Network . . . .  6
       2.1.3.  Enable 6PE On Existing MPLS Backbone . . . . . . . . .  7
     2.2.  Transition of Metro IP Network . . . . . . . . . . . . . .  8
       2.2.1.  Solution 1 . . . . . . . . . . . . . . . . . . . . . .  8
       2.2.2.  Solution 2 . . . . . . . . . . . . . . . . . . . . . .  9
       2.2.3.  Solution 3 . . . . . . . . . . . . . . . . . . . . . . 10
       2.2.4.  Solution 4 . . . . . . . . . . . . . . . . . . . . . . 11
     2.3.  Transition Of Access network . . . . . . . . . . . . . . . 12
       2.3.1.  Solution 1 . . . . . . . . . . . . . . . . . . . . . . 12
       2.3.2.  Solution 2 . . . . . . . . . . . . . . . . . . . . . . 12
       2.3.3.  Solution 3 . . . . . . . . . . . . . . . . . . . . . . 13
     2.4.  Transition of Subscriber Access Mode . . . . . . . . . . . 13
       2.4.1.  Solution 1 . . . . . . . . . . . . . . . . . . . . . . 13
       2.4.2.  Solution 2 . . . . . . . . . . . . . . . . . . . . . . 14
       2.4.3.  Solution 3 . . . . . . . . . . . . . . . . . . . . . . 15
       2.4.4.  Solution 4 . . . . . . . . . . . . . . . . . . . . . . 16
   3.  Backwards Compatibility  . . . . . . . . . . . . . . . . . . . 17
   4.  Conclusions  . . . . . . . . . . . . . . . . . . . . . . . . . 17
   5.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 17
   6.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 17
   7.  Security Considerations  . . . . . . . . . . . . . . . . . . . 17
   8.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 17
     8.1.  Normative References . . . . . . . . . . . . . . . . . . . 17
     8.2.  Informative References . . . . . . . . . . . . . . . . . . 17
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 17


















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


Internet-Draft    Broadband Access Provider Transition    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.  After the IPv4 addresses allocated by
   IANA are exhausted, China Telecom's broadband users will keep
   increasing at high speed, which will bring unprecedented pressure to
   the development of China Telecom's broadband service.

   In order to solve the problem of IPv4 address shortage, the network
   and service will eventually migrate to IPv6.  Until now there are no
   services and applications which must use IPv6.  In addition, most of
   Chinese broadband users (including China Telecom and other Chinese
   ISPs) are basically IPv4 only users before the IPv4 address
   exhaustion.  So the time the related industrial chain supporting IPv6
   will be later than the time the IPv6 in introduced into the
   operator's network.

   In the process of IPv6 migration, China Telecom focuses on the smooth
   transition of the existing services because the support from the
   related IPv6 industrial chain is relatively slow.  For example, it
   should be compatible with the existing internet services, maintain
   the high-speed increasing of the broadband users, guarantee user
   experience in the transition process, and protect existing network
   investments.  At the same time, China Telecom should consider that
   the transition technology and strategy should be consistent with the
   transition direction of future services and network.

   China Telecom provides broadband access by PPPoE dial-up
   authentication.  BRAS is the termination device of PPPoE, which
   allocates IP address for the user, provides the access authentication
   for broadband users, administration of users, IP edge function and
   etc.  Most of the broadband users use PC to make PPPoE dial up
   authentication.  Some broadband users who need to dial up from the
   Home Gateway, have to purchase the Home Gateway themselves because
   China Telecom does not provide the Home Gateway.  In the network and
   service transition to IPv6, the technologies and solutions selected
   have to be compatible with the existing access mode (PPPoE) and
   broadband service provisioning method (not provide HGW).

   The existing single transition technology is not suitable for the
   transition of China Telecom considering the specific feature of China
   Telecom's network.  Only the combination of multiple technologies can
   guarantee the smooth transition of China Telecom's network.  How to
   select appropriate technology combination to fit the network
   scenarios in China Telecom is the focus of this document.





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


Internet-Draft    Broadband Access Provider Transition    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 network structure of China Telecom is shown in Figure 1.  In the
   metro network of China Telecom, CR, as the exit router of the metro
   network, is connected to both ChinaNet and CN2 backbone networks.
   BRAS, as the IP edge device, provide the access authentication for



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


Internet-Draft    Broadband Access Provider Transition    September 2010


   the broadband users.  In most metro networks, BRAS is connected to CR
   directly, while for a small portion of large sale metro networks,
   BRAS is connected to CR via SR.  CR, SR and BRAS need to be sensitive
   to the IP protocols.  Between BRAS and broadband users, it is the
   layer 2 network which is not sensitive to IP protocols.

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


2.  Overview of Solutions for IPv6 Migration Mentioned In the China
    Telecom Use Case Document

   The following factors make the network and service transition to IPv6
   complicated in China Telecom:

   o  Large scale broadband subscribers and different capabilities of
      supporting IPv6 in terminals.

   o  Large number of network devices and different capabilities of
      supporting IPv6 in these devices.

   o  Various types of the Internet services and different capabilities
      and timing of supporting IPv6 in these services.

   o  The widespread ratio of broadband subscribers in different metro
      networks varies, which makes the smooth service and network
      transition to IPv6 complicated.

   In the transition to IPv6, existing terminals and access modes should
   be considered to guarantee the user experience.  Only by selecting
   proper technologies in different networks and in different transition
   phases, the network and service can be migrated to IPv6 smoothly.

   This section analyzes related transition technologies and transition
   roadmap regarding the network scenarios in the use case draft from
   the following aspects:

   o  Compatible with existing services (terminals, access mode and
      existing Internet service).

   o  Keep the high speed increasing of broadband subscribers.

   o  Guarantee the user experience in the transition procedure.




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


Internet-Draft    Broadband Access Provider Transition    September 2010


   o  Guarantee the existing network investment.

2.1.  Transition For the Backbone Network

   There are three main technologies for the transition of backbone
   network: dual stack, 6PE and Native IPv6.

2.1.1.  Upgrade to Dual stack on existing IP Backbone

   The device enables IPv4/IPv6 protocol stack at the same time.  IPv4
   and IPv6 routing are both in the routers which forward IPv4/IPv6
   packet separately based on the IPv4/IPv6 routing tables.

   Pros: Compatible with existing IPv4 service and new IPv6 service.

   o  The existing network device capability is high.  To support IPv6,
      it only needs to enable protocol stack, the cost of upgrade is
      low.

   o  It is useful for the smooth transition.

   Cons: Due to the large network traffic and each routing device has
   various capabilities in IP backbone network, there is big risk to
   directly upgrade to dual stack.

   o  Impact to existing service: When dual stack is enabled, any
      problem may have great impact to the existing services due to the
      large IP network traffic.

   o  Impact to existing network: The requirement of the existing
      network device capability is high.  It is a challenge for the
      routing table size, routing lookup/forwarding capability and
      routing convergence capability when the devices are upgraded to
      dual stack and IPv4/IPv6 share resources.

   o  The engineering of network modification takes much more work than
      6PE, not only modifying edge devices, but also the core devices.

   Application scenarios: Dual stack backbone network is applicable to
   the phase when IPv6 traffic is relatively large and the dual stack
   capability of the network device in dual stack backbone network is
   verified.

2.1.2.  Building New Native IPv6-Only Backbone Network

   The device enables IPv6 protocol stack only.  There is only IPv6
   routing in the router which does not carry IPv4 traffic.




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


Internet-Draft    Broadband Access Provider Transition    September 2010


   Pros: In line with the future network transition and enables IPv6
   protocol stack only:

   o  No impact to existing network and service

   o  Easy to maintain single network

   Cons: Cost is large and the period of the engineering is long; The
   network is difficult to maintain since there is no service driven at
   the initial stage, the money invested and management is little.

   Application scenario: In the last phase of IPv6 transition, most of
   the CP/SP services are IPv6.  Native IPv6 backbone network can be
   upgraded from dual stack backbone network, or by creating a new
   backbone network.

2.1.3.  Enable 6PE On Existing MPLS Backbone

   The IPv6 routing information is marked with MPLS labels through IBGP
   and is distributed into IPv4/MPLS backbone network.  The
   communication of IPv6 is achieved by the LSP among PEs.  Using 6PE
   and implementing IPv4 and IPv6 protocol stack at the PE device
   connecting to IPv6 network, the original IPv4/MPLS network in the
   backbone network could be adopted to provide access capability for
   the distributed IPv6 only user.

   Pros: Only the PE devices connecting to IPv6 network need to be
   upgraded to dual stack and make corresponding configuration.  The
   existing IPv4 MPLS network is utilized thoroughly to achieve the IPv6
   service carry in the backbone network.  The cost and risk of
   modifying the network is small.

   o  Little impact to the existing network carrying: quick deployment
      and small modification to the network.  There is no need to change
      core routers, and only PE routers having requirements need to be
      modified.

   o  Little impact to the existing service: in the initial stage of
      IPv6 deployment, there is no impact to the existing service

   o  Incremental deployment period is short.

   Cons:

   o  Change the service orientation of the original networks.  MPLS
      network is normally used to carry VPN traffic and the network is
      light load. 6PE is enabled to carry public service which changes
      the network orientation.  When the public traffic grows, there may



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


Internet-Draft    Broadband Access Provider Transition    September 2010


      be impact to the existing service.

   o  No way to deploy QoS policy for IPv6 traffic.

   o  Change the networking principle.

   Application scenarios: applicable in the starting point of supporting
   IPv6 but the main traffic is IPv4 in the operator's network.  The
   backbone network provides IPv6 carrying capability quickly.  That is,
   6PE is suitable for the first phase of IPv6 transition.

2.2.  Transition of Metro IP Network

   According to the chart in the introduction section, China Telecom's
   MAN is comprised of two parts:

   o  IP network: this part of network is composed of 2 sets of CRs and
      BRAS.  Some SR may be included in some large scale MANs.

   o  Layer 2 access network: this part of network is the layer 2
      network between BRAS and users' home gateway.

   This section introduces the transition of the IP network in metro
   networks.

2.2.1.  Solution 1

   The network is updated bases on existing network.  The network is
   updated to dual stack, and the BRAS added in future should support
   dual stack, too.  Solution: CR (core router) will be updated to dual
   stack, and some aggregation routers which may be deployed in large
   scale MAN will be updated to dual stack, too.  The update solution
   for BRAS is as follows:

   o  The existing BRASs which supports to be updated to dual stack will
      be updated to dual stack, and the BRAS added in future should
      support dual stack, too.

   o  Some BRASs which can not be upgraded to support dual-stack can
      redirect the dual-stack subscribers to dual-stack BRASs, and the
      PPP links of the dual-stack subscribers will be terminated on the
      dual-stack BRASs.

   After the exhaustion of IPv4 addresses, new BRASs distribute IPv4
   addresses for broadband subscribers, and NAT44 CGN is deployed to
   provide IPv4 services for subscribers who use private IPv4 addresses.
   IPv6 services are provided by this mechanism.  In the same time, the
   problem that the quantity of broadband subscribers keeps increasing



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


Internet-Draft    Broadband Access Provider Transition    September 2010


   quickly while IPv4 addresses is insufficient is solved.

   Pros:

   o  The change of network is simple.  The cost of the network change
      is low.  Both administration and maintenance of network are
      simple.

   o  IPv6 could be imported quickly.

   o  The technology of NAT44 is relatively mature.

   o  Major and existing services, such as MSN, Skype and OICQ, could
      support NAT44 traverse better.

   o  The existing access method does not need change, so China Telecom
      does not need to provide home gateway to users.

   o  In the condition that the time when the around industrial chain
      could support IPv6 will be later than the time when the IPv6
      migration of telecommunication network begins, users' experience
      could be guaranteed better.

   o  When the flow of IPv4 disappears in the future, the network could
      be migrated to native IPv6 network successfully.

   Some existing applications which do not consider NAT44 traverse may
   have some problems after the deployment of NAT44 CGN.  For example,
   after the deployment of NAT44 CGN, the service of PPTP VPN has
   malfunction.  Parts of P2P users may have worse experience.

   Applicable scenarios:After Ipv6 is imported and before the flow of
   Ipv4 disappears.

2.2.2.  Solution 2

   The network is updated bases on existing network.  The network is
   updated to dual stack, and the BRASs added newly support IPv6 only.
   CR (core router) will be updated to dual stack, and some aggregation
   routers which may be deployed in large scale MAN will be updated to
   dual stack, too.  The update solution for BRAS is as followed:

   o  The existing BRASs which support to be updated to dual stack will
      be updated to dual stack, and the BRAS added in future should
      support dual stack, too.

   o  Some BRASs which can not be upgraded to support dual-stack can
      redirect the dual-stack subscribers to dual-stack BRASs, and the



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


Internet-Draft    Broadband Access Provider Transition    September 2010


      PPP links of the dual-stack subscribers will be terminated on the
      dual-stack BRASs.

   o  the newly added BRAS support IPv6 only.  The users who connect to
      an IPv6 only BRAS will adopt DS-Lite mechanism to get IPv4 access.

   As time goes, those BRASs which could not be updated to dual stack
   will quit gradually from the network.

   Pros:

   o  The technology of NAT44 is relatively mature.

   o  Major and existing services, such as MSN, Skype and OICQ, could
      support NAT44 traverse better.

   o  The existing access method does not need change, so China Telecom
      does not need to provide home gateway to users.

   o  In the condition that the time when the around industrial chain
      could support IPv6 will be later than the time when the IPv6
      migration of telecommunication network begins, users' experience
      could be guaranteed better.

   o  When the flow of IPv4 disappears in the future, the network could
      be migrated to native IPv6 network successfully.

   Cons:

   o  Some existing applications which do not consider NAT44 traverse
      may have some problems after the deployment of NAT44 CGN.  For
      example, after the deployment of NAT44 CGN, the service of PPTP
      VPN has malfunction.  Part of P2P users may have bad experience.

   o  Home gateway is needed to provide to users.

   o  In the condition that both BRAS and the user are IPv6 only, other
      technology is needed to be imported to solve the transition
      problems.

   Applicable scenarios:After Ipv6 is imported and before the traffic of
   IPv4 disappears.

2.2.3.  Solution 3

   The solution is to build a new network with dual stacks, and all the
   equipments, such as CR/BRAS, adopt dual stacks.  The existing network
   does not need change, while the new network is used to provide IPv6



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


Internet-Draft    Broadband Access Provider Transition    September 2010


   service for users.

   Pros: To avoid risk and difficulty in the process that existing IPv4
   MAN is updated to dual stacks.

   Cons:

   o  The cost is huge because the investment is duplicated.

   o  Input and output ratio is too lower when the quantity of new users
      in new network is small.

   o  The IPv6 transition of existing subscribers requires a large
      amount of switch from the old network to the new network.

   Applicable scenarios:(1) The existing network is hard to be updated.
   (2) The carrying capacity of the old IPv4 MAN is insufficient when
   the quantity of broadband users increases quickly, so the old network
   should be enlarged, and the traffic in the enlarged part is the same
   with the traffic of the newly creating dual stacks MAN.

2.2.4.  Solution 4

   Building a new IPv6 only network.  All the devices, such as CR/BRAS,
   will use IPv6-only.  The existing network does not need to change,
   while the new network is used to provide IPv6 service for users.
   Some devices, such as NAT64 or DS-Lite CGN, will be added in the old
   MAN, in order to provide IPv4 service for the users connected to new
   MAN.

   Pros: To avoid risk and difficulty in the process that existing IPv4
   MAN is updated to dual stacks.

   Cons:

   o  The cost is huge because the investment is duplicated.

   o  Input and output ratio is too lower when the quantity of new users
      in new network is small.

   o  The users are IPv6 only, so other technologies are needed to solve
      the smooth transition problems.

   Applicable scenarios: IPv6 traffic is large enough.







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


Internet-Draft    Broadband Access Provider Transition    September 2010


2.3.  Transition Of Access network

   The layer 2 network of China Telecom's metro network is between the
   BRAS and the CPE.  The layer 2 network is IP layer protocol unaware
   when PPPoE is used for broadband access.  But given that new services
   (e.g.  IPTV or others) may use IPoE for network access, the layer 2
   network may also need to support IPv6 aware during the IPv6
   transition.

2.3.1.  Solution 1

   Transform based on the existing network.  New devices will be IPv6
   aware.  Existing devices will keep unchanged.  But as time goes by,
   existing devices will be gradually removed from the network.  Thereby
   the whole layer 2 network will be IPv6 aware.

   Pros:(1) The network transformation will be simple and cost-effective
   (required only new devices to be IPv6 aware), and the network
   maintenance and management will be simple; (2) In the short term,
   since the access manner of existing services will not be changed
   largely, the layer 2 network won't be required to be transformed.
   Since new devices will be IPv6 aware and existing devices which are
   IPv6 unaware will be removed from the network as time goes by, a
   smooth evolution without investment increase will be reached.

   Cons: This solution can not meet short-term requirements (e.g.  IPoE)
   that require the layer 2 network to be IPv6 aware.

   Applicable scenarios: After IPv6 begins to be introduced.

2.3.2.  Solution 2

   Transform based on the existing network.  New devices will be IPv6
   aware and existing devices will be upgraded or replaced, thereby the
   whole layer 2 networks will be IPv6 aware.

   Pros:This solution can meet both the current and the future
   requirements.  The network will not need to be transformed again to
   support new services that require the layer 2 networks to be IPv6
   aware.

   Cons: The network transformation is difficult and the cost of the
   transformation is expensive.

   Applicable scenarios: When new services or new service providing
   manners that require the layer 2 network to be IPv6 aware are about
   to emerge.




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


Internet-Draft    Broadband Access Provider Transition    September 2010


2.3.3.  Solution 3

   The existing network keeps unchanged or is upgraded or evolved
   gradually.  A new layer 2 access network which is IPv6 aware will be
   built.  IPv6 aware services will be provided only to the subscribers
   who connect to the new layer 2 network directly or indirectly.

   Pros:Avoid the difficulties and risks of the transformation based on
   the existing network.

   Cons: (1) Duplicate investment with expensive cost. (2) The input-
   output ratio will be low when the number of subscribers attached to
   the network is low.

   Applicable scenarios: When services and service providing manners
   keep unchanged in the existing layer 2 network and meanwhile new
   services or new service providing manners that require the layer 2
   network to be IPv6 aware are about to emerge.

2.4.  Transition of Subscriber Access Mode

   The transition of access mode should be compatible with the existing
   broadband access modes:

   o  China Telecom provides broadband access service through PPPoE
      dial-in authentication.  The user terminal initiates PPPoE dial-in
      authentication directly in China Telecom.

   o  China Telecom doesn't provide Home Gateway to broadband users (The
      user will purchase the Home Gateway device if there is
      requirement).

2.4.1.  Solution 1

   The user is accessed in dual stack mode, acquiring IPv4/IPv6
   addresses from dual stack BRAS.  Some users are connected to the BRAS
   which can not be upgraded to dual stack (IPv4 only BRAS).  In this
   case, a L2TP tunnel from such BRAS to dual stack BRAS is created to
   terminate the PPP link at the dual stack BRAS.

   Pros:

   o  There is no need to change the existing access method, and China
      Telecom does not need to provide the Home Gateway to the users.

   o  NAT is not needed and the user experience can be guaranteed.





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


Internet-Draft    Broadband Access Provider Transition    September 2010


   o  After IPv4 address exhaust in the future, most users are still
      using public IPv4 addresses.  For the users who use private IPv4
      addresses, NAT44 is relatively mature and mainstream services,
      e.g., MSN, Skype can support NAT44 well, so the user experience
      can be guaranteed.

   o  After the IPv4 traffic disappears, the network can migrate to
      Native IPv6 smoothly.

   Cons: Some applications not considering NAT44 may have problem when
   deploying NAT44 CGN.  For example, PPTP VPN may have service failure
   after deploying NAT44 CGN; Some P2P applications may have bad
   experience.

   Application scenario: corresponds to the dual stack metro IP network
   scenario.

2.4.2.  Solution 2

   The user acquires dual stack IP address from IPv6-only BRAS.  The
   user is accessed to IPv6-only BRAS which allocates IPv6 only for the
   user (if there is requirement, it can allocate IPv4 address as well).
   A L2TP tunnel from IPv6-only BRAS to dual stack BRAS is created to
   allocate dual stack address for the PC.  Alternatively, DS-Lite
   Gateway is set and DS-Lite CE is provided to user to acquire the
   Internet access capability of dual stack.

   Pros:

   o  BRAS is IPv6-only.

   o  NAT44 is relatively mature and mainstream services, e.g., MSN,
      Skype can support NAT44 well, so the user experience can be
      guaranteed.

   Cons:

   o  China Telecom needs to provide Home Gateway for the user which
      costs much.

   o  DS-Lite has not been verified in large scale commercial sites.

   o  All the IPv4 services have to make NAT44.  Some applications which
      have not considered NAT44 may have problems after deploying NAT44
      CGN.

   o  In the metro network with large number of subscribers, more DS-
      Lite CGN devices, more requirements for the performance.  The cost



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


Internet-Draft    Broadband Access Provider Transition    September 2010


      is high.

   o  Considering the scenarios introduced in the China Telecom use case
      draft, CR has to be dual stack and only BRAS is simplified (not
      dual stack).  But the complexity of DS-Lite CGN is higher.

   Application scenarios: Metro IP network is dual stack or IPv6 only.
   Some users can be dual stack and some can be DS-Lite.

2.4.3.  Solution 3

   The user acquires dual stack addresses from IPv4 only BRAS.  The user
   is accessed to IPv4 only BRAS which allocates IPv4 address for the
   user. 6RD Gateway is deployed in the metro network and 6RD CPE is
   provided to the user.  IPv6 packet is de-capsulated at the 6RD
   Gateway.  NAT44 CGN can be deployed in the network to solve the
   problem of IPv4 address shortage.

   Pros:

   o  There is no need to upgrade BRAS.

   o  When deploying NAT44 CGN, the user experience can be guaranteed
      because NAT44 is relatively mature and mainstream services, e.g.,
      MSN, Skype can support NAT44 well.

   Cons:

   o  How to be compatible with the existing access modes?  As the
      termination device of PPPoE, BRAS allocates IPv4 and IPv6
      addresses for the user.  BRAS needs to be upgraded to support 6RD.

   o  Need to provide Home Gateway to the users (or the user is
      unwilling to use IPv6 access due to the more investment on the
      Home Gateway).  The cost of modification is high.

   o  The network should be modified and upgraded when the network
      migrates to Native IPv6 in the future which leads to repeating
      investment of network.

   o  When the IP traffic grows larger, each metro network may need a
      great number of 6RD Gateways to meet the IPv6 user requirement.

   o  Some applications which have not considered NAT44 may have
      problems after deploying NAT44 CGN.  For example, PPTP VPN may
      have service failure after deploying NAT44 CGN; Some P2P
      applications may have bad experience.




Yang, et al.             Expires March 19, 2011                [Page 15]


Internet-Draft    Broadband Access Provider Transition    September 2010


   Application scenarios: IPv6 is just introduced into network and the
   IPv4 traffic is dominant in the network.

2.4.4.  Solution 4

   The user acquires IPv6-only address from the IPv6-only BRAS.  BRAS is
   upgraded to IPv6 only and the user terminal is upgraded to support
   IPv6 only.  Only IPv6 address is allocated to the user who visits
   IPv4 service through NAT64 or IVI.  This solution can provide IPv6
   service and can solve the problem of IPv4 address shortage due to
   high speed increasing numbers of broadband users.

   Pros:

   o  The operator does not need to allocate IPv4 address for the users.

   o  Push the ICP to transit to IPv6.

   Cons:

   o  All the user terminals have to support IPv6 which is unpractical
      at the initial stage of IPv6.

   o  The time supporting IPv6 for the related industry chain is later
      than the time IPv6 is introduced into the operator's network.
      Therefore, this solution may lead to the failure of some
      applications and Internet services after IPv6 is only introduced
      for a while..

   o  The timing supporting NAT64 for the related industry chain is much
      later which will also lead to the failure of some applications and
      Internet services after IPv6 is only introduced for a while.

   o  NAT64 and IVI have not been verified in large scale commercial
      sites.  DNS64 accompanied with NAT64/IVI has not been verified as
      well.

   o  There is high requirement for the performance of the NAT device
      because a great amount of traffic has to make NAT translations duo
      to the major IPv4 traffic in the network after IPv6 is only
      introduced for a while.

   Application scenarios: Most ICP and terminals support IPv6.  NAT64 is
   relatively mature and IPv4 traffic is little.  In this case, the
   operators disable IPv4 protocol stack of the dual stack devices,
   deploying NAT64 device at several sites to meet the requirement of
   IPv6 users who would like to visit IPv4 services.




Yang, et al.             Expires March 19, 2011                [Page 16]


Internet-Draft    Broadband Access Provider Transition    September 2010


3.  Backwards Compatibility


4.  Conclusions


5.  Acknowledgements


6.  IANA Considerations

   This memo includes no request to IANA.


7.  Security Considerations

   All drafts are required to have a security considerations section.
   See RFC 3552 [RFC3552] for a guide.


8.  References

8.1.  Normative References

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

   [min_ref]  authSurName, authInitials., "Minimal Reference", 2006.

8.2.  Informative References

   [RFC2629]  Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629,
              June 1999.

   [RFC3552]  Rescorla, E. and B. Korver, "Guidelines for Writing RFC
              Text on Security Considerations", BCP 72, RFC 3552,
              July 2003.

   [RFC5226]  Narten, T. and H. Alvestrand, "Guidelines for Writing an
              IANA Considerations Section in RFCs", BCP 26, RFC 5226,
              May 2008.










Yang, et al.             Expires March 19, 2011                [Page 17]


Internet-Draft    Broadband Access Provider Transition    September 2010


Authors' Addresses

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

   Phone:
   Email: iamyanggl@gmail.com


   LeMing Hu
   China Telecom
   109 East Zhongshan Road,
   Tiahne District, Guangzhou  510600
   P.R. China

   Phone:
   Email:


   JinYan Lin
   China Telecom
   109 East Zhongshan Road,
   Tiahne District, Guangzhou  510600
   P.R. China

   Phone:
   Email: jasonlin.gz@gmail.com





















Yang, et al.             Expires March 19, 2011                [Page 18]


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