Internet Engineering Task Force G. Yang, Ed. Internet-Draft L. Hu Intended status: Informational J. Lin Expires: April 1, 2011 China Telecom September 28, 2010 IPv6 Transition Guide For A Large-scale Broadband Network draft-yang-v6ops-v4v6tran-bb-transition-guide-00 Abstract This document discusses about different IPv6 migrating solutions for each part of the Large-scale broadband infrastructure with layer 2 access network. They are based on the requirements of providing existing broadband services in v4v6-coexisting or IPv6-only situations. The document provides analysis of different solutions and also describes the suitable scenarios that each solution may be deployed in. 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 April 1, 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 Yang, et al. Expires April 1, 2011 [Page 1] Internet-Draft Broadband Network Transition September 2010 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 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 6 2. Overview of Solutions . . . . . . . . . . . . . . . . . . . . 6 2.1. Transition For the Backbone Network . . . . . . . . . . . 7 2.1.1. Transition to Dual-stack on existing IP Backbone . . . 7 2.1.2. Building A New Native IPv6-Only Backbone Network . . . 8 2.1.3. Deploy 6PE On Existing MPLS Backbone . . . . . . . . . 8 2.2. Transition of Metro IP Network . . . . . . . . . . . . . . 9 2.2.1. Solution 1 . . . . . . . . . . . . . . . . . . . . . . 10 2.2.2. Solution 2 . . . . . . . . . . . . . . . . . . . . . . 11 2.2.3. Solution 3 . . . . . . . . . . . . . . . . . . . . . . 12 2.2.4. Solution 4 . . . . . . . . . . . . . . . . . . . . . . 13 2.3. Transition Of Layer 2 Access network . . . . . . . . . . . 14 2.3.1. Solution 1 . . . . . . . . . . . . . . . . . . . . . . 14 2.3.2. Solution 2 . . . . . . . . . . . . . . . . . . . . . . 15 2.3.3. Solution 3 . . . . . . . . . . . . . . . . . . . . . . 15 3. Subscriber Access Mode in IPv6 Transition . . . . . . . . . . 16 3.1. Solution 1 . . . . . . . . . . . . . . . . . . . . . . . . 16 3.2. Solution 2 . . . . . . . . . . . . . . . . . . . . . . . . 17 3.3. Solution 3 . . . . . . . . . . . . . . . . . . . . . . . . 18 3.4. Solution 4 . . . . . . . . . . . . . . . . . . . . . . . . 19 4. Backwards Compatibility . . . . . . . . . . . . . . . . . . . 20 5. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 20 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 20 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20 8. Security Considerations . . . . . . . . . . . . . . . . . . . 20 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 20 9.1. Normative References . . . . . . . . . . . . . . . . . . . 20 9.2. Informative References . . . . . . . . . . . . . . . . . . 20 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 21 Yang, et al. Expires April 1, 2011 [Page 2] Internet-Draft Broadband Network Transition September 2010 1. Introduction As we known, the broadband subscriber is one of the largest parts of the Internet participant. It is a significant issue to migrate them to IPv6, which will seem as an important step on IPv6 development. This document describes an IPv6 transition guide for a large-scale broadband infrastructure with Layer 2 access network. And it will focus on the cases that the network infrastructure is large and widely covered, and the new subscriber!_s number is still increasing very fast. In some cases, the broadband network is serving several dozen millions of subscribers with more than 20% annual increases in next few years. It is predicted that after the IPv4 addresses allocated by IANA are exhausted, the broadband users in these cases will still keep a high increasing rate, which will bring unprecedented pressure to the development of broadband services. Due to IPv4 addresses shortage, the network infrastructure and Internet services will no doubt to migrate to IPv6 eventually. And it is also our final goal. However, IPv6-based new services and applications provided are few and far between on Internet. In addition, most of the broadband terminals, including PCs and CPEs, will still be IPv4-only. Even if most PC Operating System declared that they already supported IPv6, there is still a very serious problem on supporting PPPoE with IPv6. Until now, PPPoE is the most widely used access method in layer 2 access network, though some access the broadband network via IPoE. Most users dial-up via PPPoE on PC, but some deployed a Home Gateway by themselves and set up an automatically dial-up from it. Not only the most widely used PC operating system, Windows(TM) XP, but also nearly all CPEs in the market, does not support PPPoE in IPv6 environment, which will be a significant bottleneck of the development of IPv6 broadband with this kind of network architecture. During the IPv6 transition, large-scale broadband network basically would like to be taken a smooth transition of the existing network infrastructure and Internet content services because of the inactive IPv6 industrial chain. For example, the first rule to the IPv6 transition could be customer-oriented which means any changes to the network infrastructure should guarantee the users!_ experience. At the same time, the transition technology and strategy should be consistent with the future direction in order to protect the investments and maintain the network stability. During the network and service transition to IPv6, the technologies and solutions should be compatible with the existing access mode (PPPoE) and broadband service provisioning method (not providing Yang, et al. Expires April 1, 2011 [Page 3] Internet-Draft Broadband Network Transition September 2010 CPE). It is difficult to find a suitable completely solution for the transition of large-scale broadband network considering its specific features. The combination of one or more existing transition technologies could be the best practices to guarantee the smooth transition and good performance corresponding to different scenarios. How to figure out the appropriate technologies combination to fit each network scenario is the focus of this document. In general, IP backbone and MPLS backbone are two major types of backbone network in the large scale broadband network. Yang, et al. Expires April 1, 2011 [Page 4] Internet-Draft Broadband Network Transition September 2010 +============================================================+ | +----------------+ +---------------------------+ | | Internet | IPv4 Internet | | IPv6 Internet | | | +----------------+ +---------------------------+ | +============================================================+ +============================================================+ | ISP's Network | | +--------------------------+ +---------------------------+ | | | IP backbone | | MPLS backbone | | | +--------------------------+ +---------------------------+ | +------------------------------------------------------------+ +------------------------------------------------------------+ | Regional Broadband Network | | +--------------------------------------------------------+ | | | Metro Core Router | | | | +-----------------------------+ | | | | +---------------------------+ | | | | | Aggregation Router | | | +--------------------------+ +---------------------------+ | | +----------------------------------+ +-------------------+ | | | BRAS | | Service Router | | | +----------------------------------+ +-------------------+ | +============================================================+ +============================================================+ | Access Netrwork (Layer 2) | | +--------------------------------------------------------+ | | | Aggregation Switch | | | +--------------------------------------------------------+ | | +--------------------------+ +---------------------------+ | | | OLT | | DSLAM | | | +--------------------------+ +---------------------------+ | +============================================================+ +============================================================+ | Customer Premises Network | | +--------------------------+ +---------------------------+ | | | Routing Mode CPE | | Bridging Mode CPE | | | +--------------------------+ +---------------------------+ | | +--------------------------------------------------------+ | | | User End | | | +--------------------------------------------------------+ | +============================================================+ Figure 1: Typical Large-scale Broadband Network Architecture The network architecture of a large-scale broadband network with L2 access network is shown in Figure 1. In the ISP!_s backbone, Metro Core Router (CR) is connected to both IP backbone and MPLS backbones. Yang, et al. Expires April 1, 2011 [Page 5] Internet-Draft Broadband Network Transition September 2010 BRAS (Broadband Remote Access Server) acts as the aggregation point for the subscriber traffic. It provides aggregation capabilities between the L2 Access Network and the ISP!_s Backbone. Beyond aggregation, it is also the injection point for access authentication, policy management and IP QoS. In most situations, BRAS is directly connected to CR, while in some cases, BRAS could be connected to an Aggregation Router (AR) that connected to CR. Service Router (SR) is basically the access nodes for different services. CR, SR and BRAS need to be sensitive to IP protocols. Between BRAS and the edge of customer premises network, the L2 Access Network, is not sensitive to IP protocols in theory. 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 In this section, it is described the overview of solutions for IPv6 Migration mentioned in the Use Case for Large-Scale Broadband Network. [I-D.huang-v6ops-v4v6tran-bb-usecase] The following factors make the networks!_ and services!_ IPv6 transition complicated and difficult: o Large number of broadband subscribers and their terminals with diverse IPv6 capabilities; o Large number of network devices and their different capabilities of supporting IPv6; o Various types of the Internet services with different IPv6 capabilities and they will not migrated to IPv6 synchronized. During the IPv6 transition, the user experience should be guaranteed. It is important to take the terminals!_ problems into consideration. Moreover, in order to migrate both of network infrastructures and Internet services smoothly, it is significant to select the proper technologies at each point of time on the IPv6 roadmap according to different network environment. This section analyzes related transition technologies and transition roadmap regarding the network scenarios in the use case from the following aspects: Yang, et al. Expires April 1, 2011 [Page 6] Internet-Draft Broadband Network Transition September 2010 o Compatible with existing services (access mode and existing Internet service). o Keep the high growth rate of the number of broadband subscribers. o Guarantee the user experience in the transition procedure. o Guarantee the existing network investment and avoid the duplicated implementation. 2.1. Transition For the Backbone Network Basically, there are three main ways for the transition of backbone network: dual-stack on existing IP backbone, 6PE on MPLS backbone and new IPv6-only IP backbone. 2.1.1. Transition to Dual-stack on existing IP Backbone This approach requires enable IPv6 capability on the existing IP Backbone routers in order to support both IPv4 and IPv6 related protocols. Until now, the routers that supported dual-stack will usually route IPv4 and IPv6 traffic separately based on the IPv4 routing table and the IPv6 one respectively. Pros: Compatible with existing IPv4 traffic and new IPv6 traffic. o The existing network devices have high capability to this. To support IPv6, it only needs to make some configurations or, in some cases, to upgrade the software version to support a better performance. The cost of such kind of upgrades is low compared to other approaches. o It is helpful for the smooth transition. Cons: Because the high volume of network traffic on the backbone and each router has various capabilities, there is still a high risk to upgrade all the routers to dual-stack without careful considerations. o Impact to existing services: When dual-stack is enabled on the routers, any problem may have considerable impact to the existing services due to the large IP network traffic. And these impacts could be difficult to be predicted and avoided. o Impact to existing network: The existing network devices usually have capability to dual-stack. But it is still a challenge for the performance and stability, for example, the size of routing table, routing lookup/forwarding capability and routing convergence capability due to the sharing of resources. Yang, et al. Expires April 1, 2011 [Page 7] Internet-Draft Broadband Network Transition September 2010 o The reengineering of network takes much more workload than the 6PE approach, which will be introduced below, because it is not only make changes to edge devices, but also all of the core devices. Applicable scenarios: Dual stack backbone network is applicable to the phase when IPv6 traffic is relatively large. And the dual stack capability, performance, and stability of the network device are reasonable high enough in dual-stack backbone network. 2.1.2. Building A New Native IPv6-Only Backbone Network The routers in a new backbone enables IPv6 protocol stack only. There is only IPv6 routing in the router which does not carry IPv4 traffic. Pros: In line with the future network transition and enables IPv6 protocol stack only: o Nearly with no impact to the existing network and services o Easy to maintain a single IPv6-only network separated from the existing one. Cons: o The cost of rebuilding a new backbone network is considerable high and the engineering cycle could be very long. o It is difficult to support the network by the small number of IPv6-only services and subscribers, because there is small business driven at the IPv6 initial stage. o The lifecycle of the Return over Investment (ROI) could also be very long. Such kind of considerations cannot be avoidable for any kind of commercial services, no matter for network providers, content providers or devices vendors. Applicable scenarios: In the last phase of IPv6 transition, most of the CP/SP services are IPv6. Native IPv6 backbone network can be upgraded from a dual-stack already backbone, or by creating a new IPv6 backbone. 2.1.3. Deploy 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. Implementing both of IPv4 and IPv6 at the PE router connecting to IPv6 networks, Yang, et al. Expires April 1, 2011 [Page 8] Internet-Draft Broadband Network Transition September 2010 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 routers connecting to IPv6 networks need to be implemented dual-stack and make some corresponding configurations. The existing IPv4 MPLS network is highly utilized to carry IPv6 traffic. The reengineering cost and risk of this kind of changes is comparable low. o Little impact on the existing network: Quick deployment and small modification to the network. There is no need to make changes on core routers, and only PE routers to be modified as needed. o Little impact to the existing services: There is little impact to the existing services in the initial stage of IPv6 deployment. o Supporting incremental deployment, the time for implementation is short. Cons: o This approach changes the original purpose of the MPLS network. MPLS network is normally used to carry VPN traffic and the network is light load. 6PE is enabled to carry public traffic. When the public traffic grows, there may be impact to the existing services. o Unable to deploy QoS policy for IPv6 traffic. o Change the networking principle. Applicable scenarios: It could be applicable in IPv6 initial stage while the most traffic is still IPv4 in the backbone. The backbone network could provide IPv6 traffic carrying with less deployment time. 2.2. Transition of Metro IP Network According to Figure 1, the typical Metro Network in the broadband architecture is comprised of three kinds of elements: o CR: The Core Router is usually the egress router of the metro network and connected to BRASs or SRs for both users!_ and CPs!_ access. o BRAS: BRAS is the aggregation point for the subscriber traffic. It provides aggregation capabilities between the Access Network Yang, et al. Expires April 1, 2011 [Page 9] Internet-Draft Broadband Network Transition September 2010 and the Metro Network. Beyond aggregation, it is also the injection point for access authentication, policy management and IP QoS. o SR: Service Router is basically the access nodes for different services. o AR: A small portion of the BRASs in some large metro networks may connect to a Aggregation Router. And the AR is usually connected to the CRs. The network is transition to dual-stack from the existing network. 2.2.1. Solution 1 In this solution, CRs and ARs will be transition to dual-stack while the new BRAS will implement dual-stack. Besides, the existing BRASs could be upraded with the solution as follows: o The existing BRAS will upgrade to dual-stack if it is able to do so. o For the BRAS that is unable to upgrade to dual-stack, it can redirect the dual-stack subscribers to another dual-stack BRAS, and the PPP links of the dual-stack subscribers will be terminated on that dual-stack BRAS.GBP"e.g. L2TPGBP(C) After the IPv4 addresses exhaustion, new BRASs could allocate private IPv4 addresses for broadband subscribers, and a NAT44 CGN will be deployed to provide IPv4 NAT services for subscribers who use private IPv4 addresses. The IPv6 services can be provided by this approach while providing IPv4 services with private IPv4 addresses. Pros: o It is easy for incremental deployment. And the cost for this solution is comparable low. Besides, the network operation and management will also be simple. o IPv6 could be introduced as soon as possible. o The technology of NAT44 is relatively mature. The major existing applications, such as MSN, Skype and QQ, are already supporting NAT traverse very well. Yang, et al. Expires April 1, 2011 [Page 10] Internet-Draft Broadband Network Transition September 2010 o The existing access method does not need to be changed, so it is no need to replace the CPEs for subscribers. o The point of time when the IPv6 related industrial chain being active could be later than that of the IPv6 transition of the network infrastructures. Under such situation, the users experience with this solution could be better. The reason may be the immature NAT64 technologies. o When the IPv4 traffic disappears in the future, the network could be migrated to native IPv6 network gradually. 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. Parts of P2P users may have worse experience. Applicable scenarios: After IPv6 is introduced and before the traffic of IPv4 disappears. 2.2.2. Solution 2 The existing network is upgraded to dual-stack, and the new BRASs support IPv6-only, not the dual-stack. In this solution, CR will be updated to dual-stack, and some AR which may be deployed in large scale metro network will be updated to dual stack, too. The update solution for BRASs is as followed: o The existing BRASs which support to be transition to dual-stack will be transition to dual-stack. o For the BRAS that is unable to upgrade to dual-stack, it can redirect the dual-stack subscribers to another dual-stack BRAS, and the PPP links of the dual-stack subscribers will be terminated on that dual-stack BRAS.GBP"e.g. L2TPGBP(C) o The newly added BRASs will implement IPv6 only. The users who connect to an IPv6 only BRAS will adopt DS-Lite mechanism to get IPv4 access. o As time goes, those BRASs which could not be upgraded to dual- stack will be eliminated from the network gradually. Pros: Yang, et al. Expires April 1, 2011 [Page 11] Internet-Draft Broadband Network Transition September 2010 o The technology of NAT44 is relatively mature. The major existing applications, such as MSN, Skype and QQ, are already supporting NAT traverse very well. o The access method for existing subscribers does not need to be changed, so providers does not need to provide home gateway to existing users. o The point of time when the IPv6 related industrial chain being active could be later than that of the IPv6 transition of the network infrastructures. Under such situation, the users experience with this solution could be better. The reason may be the immature NAT64 technologies. o When the IPv4 traffic disappears in the future, the network could be migrated to native IPv6 network gradually. 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. Parts of P2P users may have worse experience. o Home gateway could be needed to provide to users when DS-Lite is deployed. It will draw a great amount of operational cost for the devices replacement based on the great number of subscribers. o In the case of both BRAS and the user are IPv6-only, other technology like NAT64 or IVI is needed to be implemented for the transitioning problems. Applicable scenarios: This solution could be suitable for the intermediate stage of the IPv6 transition. After IPv6 is introduced and before the traffic of IPv4 disappears. 2.2.3. Solution 3 This solution is to build a new completely dual-stack metro network. The existing network does not need to be changed, while the new network could be mainly providing IPv6 services for users. Pros: o The risk due to changes of the existing metro network is low. Yang, et al. Expires April 1, 2011 [Page 12] Internet-Draft Broadband Network Transition September 2010 o It is much easier to build up a completely new metro network than to upgrade the existing one. Cons: o The cost is huge and the investment is duplicated with the existing one. o Cost/income ratio is considerable low when the quantity of new users in new network is small. o The IPv6 transition of existing subscribers requires a large amount of switchovers from the old network to the new one. Applicable scenarios: (1) The existing metro network is difficult to be upgraded. (2)In the case of fast increasing rate of broadband subscribers and traffic, the existing metro network could be insufficient, which may lead to the network expanding. If the traffic in the extension network is large enough, building up a new metro network could be a better idea. 2.2.4. Solution 4 This solution is to build up a new native IPv6 network. The existing network does not need to be changed, while the new network is used to provide IPv6 services for subscribers. Some components, such as NAT64 device or DS-Lite CGN, will be deployed in the existing metro network, in order to provide IPv4 services for the users connected to new metro network. Pros: o This solution could avoid the risk and difficulty from the changes of the existing metro network. Cons: o The cost is huge and the investment is duplicated with the existing one. o Cost/income ratio is considerable low when the quantity of new users in new network is small. o Some transition technologies may be deployed to solve the intercommunication problem between IPv6 and IPv4 for the IPv6-only subscribers. Yang, et al. Expires April 1, 2011 [Page 13] Internet-Draft Broadband Network Transition September 2010 Applicable scenarios: This solution may be suitable for the situation that the IPv6 traffic is large enough. 2.3. Transition Of Layer 2 Access network Most of the broadband access networks are layer 2 networks in this use case. It is defined that the access network is from BRAS, the IP network edge, to the CPE at the edge of Customer Premises Network. Basically, a layer 2 network device is IP layer protocol unaware when PPPoE is used for broadband access. However, the IPv6 capability is compulsory due to some security policies implemented on the access network devices (e.g. IP-Based ACLs). On the other hand, some future services (e.g. IPTV or M2M) may access the network via IPoE. Therefore, the layer 2 network for these kinds of services may also need to support IPv6 aware. 2.3.1. Solution 1 This solution is transitioning based on the existing network. In the access network, the new devices will be IPv6 aware while the existing devices will keep unchanged. But according to their lifecycle, historical devices will be gradually removed from the existing network. Thereby the whole layer 2 network will be IPv6 aware finally. Pros: o The network transition will be simple and cost-effective, only required new devices in the access network to be IPv6 aware. o The network maintenance and management will be comparable simple; o In a short term, since the access method of the existing services will not be changed, the layer 2 network won't be required to be transition. 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: o This solution cannot meet the short-term requirements for some services (e.g. IPoE)that require a IPv6 aware layer 2 network. Applicable scenarios: This solution is suitable for the initial stage of the IPv6 transition. Yang, et al. Expires April 1, 2011 [Page 14] Internet-Draft Broadband Network Transition September 2010 2.3.2. Solution 2 This solution is transitioning based on the existing network. In the access network, the new devices will be IPv6 aware while the existing devices will also upgraded or replaced. Thereby the whole layer 2 network will be IPv6 aware. Pros: o This solution can meet both the current and the future requirements. The network will not need to be reengineering again to support new services that require IPv6 aware on access network. Cons: o The access network transition is difficult with great amount of workload due to the subscribers scale. And the cost of the reengineering of access network is also 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. 2.3.3. Solution 3 This solution will build up a new layer 2 access network which is IPv6 aware. On the other hand, it keeps the existing access network unchanged or upgrading or evolving gradually. IPv6 aware services will be provided only to the subscribers who connect to the new layer 2 network. Pros: o This solution could avoide the risk and difficulty from the changes of the existing metro network. Cons: o The cost is huge and the investment is duplicated with the existing one. o Cost/income ratio is considerable low when the quantity of new users in new network is small. 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. Yang, et al. Expires April 1, 2011 [Page 15] Internet-Draft Broadband Network Transition September 2010 3. Subscriber Access Mode in IPv6 Transition 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. The following factors should be considered: o As the most widely used broadband access method, users dial-up via PPPoE and are authenticated at a centralized AAA System. o The CPE, including two kinds of mode, is usually provided by subscribers themselves. o Many broadband users dial-up via PPPoE on PC which connected to a bridged-mode CPE. However, some broadband users deployed a Home Gateway (e.g. WLAN AP) at home and make an automatically dial-up from it. And some other subscribers deployed a routing-mode CPE to share the broadband service with different hosts. 3.1. Solution 1 In this solution, the host is accessed with dual-stack mode, acquiring both IPv4 and IPv6 addresses from dual-stack BRAS. There are thousands of BRAS all over the typical large scale broadband network. So, it is very difficult to ensure the dual-stack capability for all these BRASs. For this circumstance, L2TP could be used to initial a tunnel from the IPv4-only BRAS to a dual-stack one. And the PPP connection initialed by PC or CPE would be terminated at the dual-stack BRAS. Pros: o There is no need to change the existing access mode, and the Home Gateways do not need to be replaced. o NAT64 can be avoided and the user experience can be guaranteed. o After IPv4 address exhaust, most existing users are still using public IPv4 addresses. The new users may have to use private IPv4 addresses for the IPv4 services. NAT44 is relatively mature, and the mainstream services, e.g., MSN, Skype can support NAT44 well. Therefore, the user experience could be guaranteed. o After the IPv4 traffic disappears, the network can migrate to Native IPv6 smoothly. Cons: Yang, et al. Expires April 1, 2011 [Page 16] Internet-Draft Broadband Network Transition September 2010 o Some applications not considering NAT-traversal issue may have problem when deploying a NAT44 CGN. For example, PPTP VPN may have service failure after deploying NAT44 CGN; Some Peer-to-Peer applications may have worse experience. Applicable scenarios: corresponds to the dual-stack metro network scenario. 3.2. Solution 2 In this solution, the user-end host with dual-stack enabled connected to an IPv6-only BRAS. The host will be allocated an IPv4 address and an IPv6 address by a remote dual-stack BRAS. A L2TP tunnel is used from the IPv6-only BRAS to the remote dual-stack BRAS. Alternatively, DS-Lite CGNs and DS-Lite CPEs could be deployed to provide dual-stack services with a native IPv6 access network for subscribers. Pros: o BRAS is IPv6-only, which will benefit the IPv6 development. o NAT44 is relatively mature, and the mainstream services, e.g., MSN, Skype can support NAT44 well. Therefore, the user experience could be guaranteed. Cons: o The replacement of all the CPEs for great amount of subscribers seems to be an impossible mission for a large scale broadband network, not only because the distribution of subscribers is scattered over a large area but also as the high costs for this solution is unacceptable. o DS-Lite has not been deployed and verified in any large scale commercial trail. o After the private IPv4 address is used, all the IPv4 services with private address have to go through the NAT44 device. Some applications not considering NAT-traversal issue may have problem when deploying a NAT44 CGN. o In the metro network with a large number of dual-stack subscribers, a number of DS-Lite CGN devices with high performance is needed. The reengineering cost for this solution may be very high. Yang, et al. Expires April 1, 2011 [Page 17] Internet-Draft Broadband Network Transition September 2010 o Considering the scenarios introduced in the use case for large scale broadband network[I-D.IETF-huang-v4v6tran-broadband- usecase], CRs in metro network have to be upgraded to dual-stack for providing dual-stack broadband service on existing metro network, though the BRAS could be IPv6-only. Moreover, the metro network could be more complexity due to the DS-Lite CGN!_s deployment. Applicable scenarios: This subscriber access mode is suitable for the scenarios that the metro network is with dual-stack CRs and providing IPv6-only BRASs for dual-stack users. Users!_ hosts can be dual- stack or is accessing by DS-Lite CPEs. 3.3. Solution 3 In this solution, the user-end host with dual-stack enabled connected to an IPv4-only BRAS. The IPv4 address is allocated from the IPv4- only BRAS, while 6RD Gateway is deployed in the metro network for IPv6 services. The 6RD CPE for subscribers is needed. The IPv6 packet is de-capsulated at the 6RD Gateway. NAT44 CGN could be also deployed in the metro network if the IPv4 addressed which allocated by BRAS is a private IPv4 address. Pros: o There is no need to upgrade the thousands of BRASs in a large scale broadband network. o NAT44 is relatively mature, and the mainstream services, e.g., MSN, Skype can support NAT44 well. Therefore, the user experience could be guaranteed. Cons: o The compatible issue with the existing access mode need to be solved. As the termination of the PPPoE link, the BRAS is also need 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 implementation is high. o The network should be reengineering and upgraded when the network migrates to IPv6-only in the future which may lead to repeated investment on the transition. o When the IPv6 traffic is extremely high, each metro network may need a number of 6RD Gateways to meet the IPv6 user requirement. Yang, et al. Expires April 1, 2011 [Page 18] Internet-Draft Broadband Network Transition September 2010 o After the private IPv4 address is used, all the IPv4 services with private address have to go through the NAT44 device. Some applications not considering NAT-traversal issue may have problem when deploying a NAT44 CGN. Applicable scenarios: This solution is suitable for the initial stage of the IPv6 transition when the IPv4 traffic is still dominant in the network. 3.4. Solution 4 In this solution, the user-end host with IPv6-only enabled is connected to an IPv6-only BRAS. It is required that the BRASs are upgraded to IPv6-only and the users!_ terminals are also upgraded to support IPv6. Only IPv6 address is allocated to the users. For the requirement of visiting IPv4 services, it is needed to deploy a NAT64 (stateful/IVI) device. This solution can provide IPv6 services and also solve the problem of IPv4 address shortage due to the high-speed growth of broadband users. Pros: o It is no need to allocate IPv4 address for the users. o Push the IPv6 transition of ICPs. Cons: o All the user terminals including CPEs have to support IPv6 which is unpractical at the initial stage of IPv6. o The point of time when the IPv6 related industrial chain being active could be later than that of the IPv6 transition of the network infrastructures. Under such situation, the users experience with this solution could be worse. The reason may be the immature NAT64 technologies. o Stateful NAT64 and IVI/DIVI have not been deployed and verified in large scale commercial trails. DNS64 accompanied with NAT64/IVI has not been verified as well. o The performance requirement of the NAT device deploying in a metro network with large amount of subscribers is considerable high. The situation could be much worse because the IPv4 traffic is still the majority at the IPv6 initial stage. Yang, et al. Expires April 1, 2011 [Page 19] Internet-Draft Broadband Network Transition September 2010 Applicable scenarios: This solution is suitable in case of most ICPs and terminals have been supporting IPv6 already. Besides, NAT64/IVI technology is relatively mature and the IPv4 traffic is little. In this case, IPv4 protocol stack of the dual-stack devices could be disabled, and NAT64 devices could also be deployed at several sites to meet the requirement of IPv6-only users who are visiting the historical IPv4 services. 4. Backwards Compatibility 5. Conclusions TBD... 6. Acknowledgements 7. IANA Considerations This memo includes no request to IANA. 8. Security Considerations The IETF is specifying security considerations for the solutions that it is providing for IPv6 migration. However, it is possible that additional considerations arise due to the interoperation of these solutions, and the fact that the network is in a transitional state. 9. References 9.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. 9.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 Yang, et al. Expires April 1, 2011 [Page 20] Internet-Draft Broadband Network Transition September 2010 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. Authors' Addresses GuoLiang Yang (editor) China Telecom 109, Zhongshan Ave. Wast, Guangzhou, Tianhe District 510630 P.R. China Phone: Email: yanggl@gsta.com LeMing Hu China Telecom 109, Zhongshan Ave. Wast, Guangzhou, Tianhe District 510630 P.R. China Phone: Email: hulm@gsta.com JinYan Lin China Telecom 109, Zhongshan Ave. Wast, Guangzhou, Tianhe District 510630 P.R. China Phone: Email: jasonlin.gz@gmail.com Yang, et al. Expires April 1, 2011 [Page 21]