Internet Engineering Task Force G. Yang, Ed. Internet-Draft L. Hu Intended status: Informational J. Lin Expires: April 23, 2011 China Telecom October 20, 2010 IPv6 Transition Guide For A Large-scale Broadband Network draft-yang-v6ops-v4v6tran-bb-transition-guide-01 Abstract This document discusses about different IPv6 migrating solutions for each part of the Large-scale broadband network with layer 2 access infrastructure. They are based on the requirements of providing existing broadband services in v4v6-coexisting or IPv6-only scenarios. 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 23, 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 23, 2011 [Page 1] Internet-Draft Broadband Network Transition October 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 . . . . . . . . . . . . . . . . . . 3 2. Terminologies . . . . . . . . . . . . . . . . . . . . . . . . 4 3. High Level Architecture . . . . . . . . . . . . . . . . . . . 5 4. Overview of Solutions . . . . . . . . . . . . . . . . . . . . 7 5. Transition For the Backbone Network . . . . . . . . . . . . . 8 5.1. Dual-stack IP Backbone . . . . . . . . . . . . . . . . . . 9 5.2. IPv6-Only Backbone . . . . . . . . . . . . . . . . . . . . 10 5.3. 6PE on MPLS Backbone . . . . . . . . . . . . . . . . . . . 11 5.4. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . 13 6. Transition of Regional IP Network . . . . . . . . . . . . . . 13 6.1. Dual-Stack and L2TP . . . . . . . . . . . . . . . . . . . 15 6.2. Dual-Stack over IPv6 - DS-lite . . . . . . . . . . . . . . 18 6.3. Dual-Stack over IPv4 - 6rd . . . . . . . . . . . . . . . . 20 6.4. IPv6 and NAT64 . . . . . . . . . . . . . . . . . . . . . . 22 7. Backwards Compatibility . . . . . . . . . . . . . . . . . . . 24 8. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 24 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 24 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24 11. Security Considerations . . . . . . . . . . . . . . . . . . . 24 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 24 12.1. Normative References . . . . . . . . . . . . . . . . . . . 24 12.2. Informative References . . . . . . . . . . . . . . . . . . 25 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 26 Yang, et al. Expires April 23, 2011 [Page 2] Internet-Draft Broadband Network Transition October 2010 1. Introduction As we known, broadband subscriber is one of the largest parts of the Internet participants. It is significant 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 network with Layer 2 accessing. And it will focus on the cases that the network infrastructure is large and widely covered, and the new subscriber's number is very large and 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 not only the development of broadband services, but also the development of Internet. 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 are few and far between. During the IPv6 transition, large-scale broadband network basically should take a smooth transition strategy because of the inactive IPv6 industrial chain. The first rule 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. And the technologies and solutions should be compatible with the existing broadband service access method and provisioning method. This document is aimed to identify the pros and cons of all possible solutions in every part of the broadband network with considering its features. And it also provides the applicable scenarios for each solution. 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]. Yang, et al. Expires April 23, 2011 [Page 3] Internet-Draft Broadband Network Transition October 2010 2. Terminologies Backbone network: Backbone network interconnects various regional broadband networks, providing a path for the exchange of information between different networks. Regional Broadband Network: Regional broadband network interconnects the central offices in a geographical area. L2 Access Network: L2 Access Network is the broadband access infrastructure which is a Layer 2 network. Customer Premises Network: Customer Premises Network will contain one or more terminal equipment devices possibly interconnected by a customer premises network. POP: Internet point of presence, POP, is the access point to the backbone network for regional broadband network. MPLS PE routers: Provider edge router in a MPLS backbone network. BRAS: Broadband Remote Access Server, BRAS, is the aggregation point for the subscriber traffic. It provides aggregation capabilities between the Access Network and the Metro Network. Beyond aggregation, it is also the injection point for access authentication, policy management and IP QoS. CR: Core Router in a regional broadband network is the egress router of the regional broadband network and connecting to a POP of the backbone in upstream and connecting to BRASs for downstream. SR: Service Router, SR, is the access nodes for different services providers (e.g. Internet Contents Provider). AR: Aggregation Router is connected to CRs and provide traffic aggregation for BRASs in a large-scale regional broadband network. DSLAM: Digital Subscriber Line Access Multiplexer, DSLAM, is the access node for Digital Subscriber Lines (DSL) subscribers. OLT: An optical line termination (OLT) is a device which serves as the endpoint of a passive optical network (PON). Yang, et al. Expires April 23, 2011 [Page 4] Internet-Draft Broadband Network Transition October 2010 CPE: Customer Premises Equipment, CPE, is the edge of Customer Premises Network. In this document, there are two types of CPEs, Routing mode CPE and Bridging mode CPE. User End: In this document, we consider the user end is a PC with a popular operating system like Windows, MAC OS, or Linux. 3. High Level Architecture In this section, a High Level Broadband Architecture with layer 2 (L2) access network is shown in Figure 1. There are basically five parts in this architecture, Customer Premises Network, Layer 2 Access Network, Regional Broadband Network, Backbone and the Internet. We don't discuss the physical layer infrastructures in this document. (e.g.Main Distribution Frame (MDF), and Optical Network Terminal (ONT)). Yang, et al. Expires April 23, 2011 [Page 5] Internet-Draft Broadband Network Transition October 2010 +============================================================+ | +----------------+ +---------------------------+ | | Internet | IPv4 Internet | | IPv6 Internet | | | +----------------+ +---------------------------+ | +============================================================+ +============================================================+ | Backbone | | +--------------------------+ +---------------------------+ | | | IP backbone | | MPLS backbone | | | +--------------------------+ +---------------------------+ | +============================================================+ +============================================================+ | Regional Broadband Network | | +--------------------------------------------------------+ | | | Metro Core Router | | | | | | | | ..............................| | | | . Aggregation Router | | | +--------------------------------------------------------+ | | +------------------------------------------------------+ | +==| BRAS |==+ +==| |==+ | +------------------------------------------------------+ | | Access Netrwork (Layer 2) | | +--------------------------------------------------------+ | | | Aggregation Switch | | | +--------------------------------------------------------+ | | +--------------------------+ +---------------------------+ | | | OLT | | DSLAM | | | +--------------------------+ +---------------------------+ | +============================================================+ +============================================================+ | Customer Premises Network | | +--------------------------+ +---------------------------+ | | | Routing Mode CPE | | Bridging Mode CPE | | | +--------------------------+ +---------------------------+ | | +--------------------------------------------------------+ | | | User End | | | +--------------------------------------------------------+ | +============================================================+ Figure 1: High Level Broadband Architecture with L2 Access network In general, IP backbone and MPLS-enabled Layer 3 IP backbone (to simplify discuss, we call it "MPLS backbone" in this document) [RFC3031] are two major types of backbone for long distance transmission in the large scale broadband network. We classified two Yang, et al. Expires April 23, 2011 [Page 6] Internet-Draft Broadband Network Transition October 2010 types of MPLS backbone here, the combined backbone forwarding both the non-labeled packets by IP switching and the labeled packets by label switching (MPLS+IP backbone), or a MPLS backbone with label switching only. In the Regional Broadband Network, Metro Core Router (CR) is connected to IP backbone, MPLS+IP backbone or both IP backbone and MPLS backbone. In most situations, Broadband Remote Access Server (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. As this document is focus on the IPv6 transition of broadband service, it does not discuss about the transition of SR. BRAS acts as the aggregation point for the subscriber traffic. It provides aggregation capabilities between the L2 Access Network and the Regional Broadband Network. Beyond aggregation, it is also the injection point for access authentication, policy management and IP QoS. The access network in this architecture is a L2 network. It is from the BRAS to the Customer Premises Equipment (CPE) located at the edge of customer premises network. The most popular access method in this architecture currently could be PPPoE [RFC2516]. In theory, the devices in the access network have no needs to be IPvX protocol aware. Note that although the IPoE access method may be using the same L2 access network, the discussion of IPv6 transition with IPoE is out- of-scope in this document. And it does not consider the transition from a layer 2 access network to a layer 3 one as well. This document will focus on the IPv6 transition of the Backbone Network and the Regional Broadband Network in the architecture above [Figure 1]. And it will also discuss how to provide IPv6 service for broadband subscribers in such kind of architecture. 4. Overview of Solutions This document describes the IPv6 transition solutions and related technologies for the Use Case for Large-Scale Broadband Network. [I-D.huang-v6ops-v4v6tran-bb-usecase] By analysing the features of the case, 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; Yang, et al. Expires April 23, 2011 [Page 7] Internet-Draft Broadband Network Transition October 2010 o Large number of network devices with diverse IPv6 capabilities; o Various types of the Internet services and applications have diverse IPv6 capabilities and they will not migrated to IPv6 synchronized. During the IPv6 transition, the user experience should be guaranteed. So, it is important to take the terminal into consideration besides the networking issues. Moreover, in order to migrate both of the network infrastructures and the Internet services smoothly, it is significant to select the proper technologies at each point of time on the IPv6 roadmap according to different network scenarios. Because the global IPv4 addresses is depleting, and most of the Internet contents and applications are not ready yet, carrier graded NAT44 technologies and Large Scale NAT devices (LSN) may be deployed in the network during the initial stage of the IPv6 transition. So, the issues that are brought from NAT44 technology itself and the interoperating with other IPv6 transition technologies should be considered. 5. Transition For the Backbone Network According to the architecture in Figure 1 above, there are three possible backbones in a large-scale broadband network: o There is an IP backbone only; o There is a MPLS+IP combined backbone; o There is an IP backbone and a MPLS backbone. The discussion on backbone will focus onthe scenario that there is an IP backbone and a MPLS backbone separately. When there is an IP backbone only, it can use the Dual-stack solution or the IPv6 solutions. And when there is a MPLS+IP combined backbone, the solutions are similar. It can use the Dual-stack solution or the IPv6 solutions with IP-based switching; alternatively, it use the 6PE solution with labeled switching for the IPv6 traffic. Basically, there are three main ways for the transition of backbone network: o Dual-stack IP Backbone Yang, et al. Expires April 23, 2011 [Page 8] Internet-Draft Broadband Network Transition October 2010 o IPv6-Only Backbone o 6PE in MPLS Backbone 5.1. Dual-stack IP Backbone The Dual-stack IP Backbone Solution includes two implementation options, building a completely new Dual-Stack IP backbone or upgrading the existing routers in the IP backbone to Dual-Stack by enabling IPv6. Technically, the main idea is carrying both the IPv6 and IPv4 traffic on one backbone. Except the management issue and engineering cost, there may be little difference on technical aspect. The upgrade implementation could be incrementally to reduce the risk on each Internet point of presence (POP), but it can not avoid the risk on provider (P) routers. In the new-built implementation, the new POPs and P routers are sperately with the existing backbone. Therefore, the risk of upgrading the P routers, which is considerable high, will be avoided. The upgrade implementation will be much more complicated, and this section will focus on it. Upgrading the existing backbone to a Dual-stack IP backbone requires enable IPv6 on the all the routers and support both IPv4 and IPv6 routing protocols. In some cases, the routers may upgrade to a new software and hardware version to support a better performance and functionality. So, the changes will contains two parts, devices upgrade and reconfiguration. Figure 2 presents the architecture after the upgrade implementation. +----------------+ +-------------------+ | IPv4 Internet | | IPv6 Internet | +-------||-------+ +--------#----------+ +-------||------------------#----------+ | Dual-stack IP backbone | | +--------------+ | +---------|Dual-Stack POP|-------------+ +--/\-----/\---+ || # IPv4 IPv6 Traffic Traffic Figure 2: Dual-stack IP Backbone Generally, the pros and cons of this solution are: Pros: o According the the use CASE [I-D.huang-v6ops-v4v6tran-bb-usecase], most of existing routers have IPv6 capability already (but not Yang, et al. Expires April 23, 2011 [Page 9] Internet-Draft Broadband Network Transition October 2010 enabled). To support IPv6, it only needs to make some configurations or upgrade the software version. It does not need the extra engineering cost for the new infrastructure. It is no need to build or expand the existing facilities like power, air conditioning and transmission infrastructures, which may take a long engineering period. o The existing IP backbone is usually covering a widely area already. So, this solution is flexible and can conduct a rapid deployment of IPv6 services anywhere it covered. o The upgraded IP backbone is compatible with the existing IPv4 traffic and the new IPv6 traffic. There is no extra new backbone which will lead a large amount of extra management cost. o The upgraded dual-stack backbone can be upgraded to IPv6-only by turning off the IPv4 after the IPv4 traffic is disappeared. Cons: o Until now, the routers in the IP backbone that supported Dual- stack will usually route IPv4 and IPv6 traffic separately based on the IPv4 routing table and the IPv6 one respectively. The router may have challenges for the performance and stability after they are upgraded to dual-stack, for example, the size of routing table, routing lookup/forwarding capability and routing convergence capability due to the sharing of resources. o There is lack of technical and management experience of large- scale changing in a high volume traffic backbone, even though the change is very little. o There is a high risk to upgrade the P router to dual-stack because of its high volume traffic. Any fault (hardware or software) may lead a significant impact to the existing services. And these impacts is difficult to predict. 5.2. IPv6-Only Backbone It seems impossible to upgrade the existing IPv4 backbone to a native IPv6 backbone. This section will discuss a solution of building a new IPv6-only backbone network and keeping the original IPv4 infrastructure unchanged. There is only IPv6 routing in the new backbone, and the IPv4 traffic will be kept going through the legacy IPv4 backbone. Figure 3 presents the architecture of co-existing of IPv4 backbone and IPv6 backbone. Yang, et al. Expires April 23, 2011 [Page 10] Internet-Draft Broadband Network Transition October 2010 +----------------+ +-------------------------+ | IPv4 Internet | | IPv6 Internet | +-------||-------+ +------------#------------+ +-------||-------+ +------------#------------+ | IPv4 backbone | | new IPv6 backbone | +---[IPv4 POP]---+ +--------[IPv6 POP]-------+ /\ /\ || IPv4 Traffic || IPv6 Traffic Figure 3: New IPv6 Backbone Pros: o In line with the future network; It is a one-step solution and no need the second step which will also brings the risks (e.g. dual- stack backbone upgrade to IPv6 only); o Nearly with no impact on the existing IPv4 backbone and the services on it; o Simple to maintain two physically separated infrastructures compared with a complex dual-stack network with two logical network. Cons: o The cost of building a new backbone is considerable high and the engineering cycle could be very long. o If the IPv6 services are still very few, the subscribers' IPv4 traffic will not be forwarded to the new IPv6 backbone. The inefficiency of the new IPv6 backbone could be a waste. Moreover, there may be a separate network operation and management cost for the new backbone. 5.3. 6PE on MPLS Backbone The Multiprotocol Label Switching (MPLS) [RFC3031] is a popular networking technology that forwards packets by label switching instead of by IP switching. In this solution, the provider edge (PE) routers are dual-stack. The egress routers of the regional broadband network are connected to the PE router via a normal interface. The IPv6 routing distribution between two IPv6 enabled PE routers is done via Multiprotocol iBGP (MP-iBGP). The iBGP sessions distribute the IPv6 prefixes and the associated MPLS label. This is known as IPv6+ label and is encoded according to [RFC3107]. The communication of IPv6 is achieved by the label switched path (LSP) among PE Yang, et al. Expires April 23, 2011 [Page 11] Internet-Draft Broadband Network Transition October 2010 routers.Figure 4 presents the architecture of 6PE solution over a MPLS backbone. +------------+ +------------+ / MPLS CORE \ +------------+ |6PE Router A|-->......LSP.......-->|6PE Router B| +-----/\-----+ \ (IPv4) / +------/\----+ || +------------+ || IPv6 Traffic IPv6 Traffic & IPv4 Traffic & IPv4 Traffic Figure 4: 6PE in MPLS backbone Pros: o 6PE technology [RFC4798] is relatively mature compared to other tunnel technology in backbone. o There is no need to make changes on P routers which the LSP goes through. Only the PE router connecting to IPv6-enabled networks needs to implement Dual-stack and make some corresponding configurations for 6PE. The reengineering cost and risk of this kind of changes is comparable low. o Little impact to the existing services: There is little impact to the existing services. It is similar to the existing MPLS network is carrying a new service with a new label. o According to the use case [I-D.huang-v6ops-v4v6tran-bb-usecase], the MPLS backbone covers a widely area already which means it can provide IPv6 servces with a rapid deployment when there is an IPv6 demand in some regional broadband networks. Therefore, this solution is flexible and supporting incremental deployment. Cons: o This solution changes the original designed purpose of the MPLS network which is normally used to carry VPN traffic and usually light load. 6PE brings the public traffic in to the MPLS infrastructure. When the this kind of traffic grows, there may be significant to the existing services. o Unable to deploy QoS policy for IPv6 traffic. o It may bring some inconvenient for troubleshooting. Yang, et al. Expires April 23, 2011 [Page 12] Internet-Draft Broadband Network Transition October 2010 5.4. Conclusion The 6PE solution may be applicable in the IPv6 initial stage while the most traffic is still IPv4 in the backbone and there is a demand for the rapid deployment of IPv6 service. The Dual-stack solution may be applicable to the intermediate stage when IPv6 traffic is relatively large. And for the network devices, the Dual-stack capability, performance, and stability need to be reasonable high enough to support two IP stacks. The native IPv6 solution may be suitable to the latter phase of IPv6 transition with most of the services being IPv6 capable. It can also be upgraded from the Dual-stack backbone by turning off the IPv4 after the IPv4 traffic is disappeared. 6. Transition of Regional IP Network According to the use case [I-D.huang-v6ops-v4v6tran-bb-usecase], The Overview of the solutions in the Regional Broadband Network can be summarized into the following three types: o Providing IPv6 service by Large-scale upgrading the existing regional broadband network infrastructure; o Providing IPv6 service by little changes on the existing regional broadband network infrastructure; o Providing IPv6 service by building a completely new IPv6 regional broadband network infrastructure; Large-scale | Little | unchange Upgrade | changes | +New Net +--------------------+ | +---------+ | +------+ CR | Dual-Stack | | | DS/IPV4 | | | IPv6 | +--------------------+ | +---------+ | +------+ +----+ +----+ +------+ | +---------+ | +------+ BRAS |IPv6| | DS | | IPv4 | | | IPv4 | | | IPv6 | +----+ +----+ +------+ | +---------+ | +------+ | | | | | | | DS-Lite/ DS 6rd 6rd NAT64/ L2TP+DS /L2TP+DS DS-Lite Note: "DS" stands for "Dual-Stack". Yang, et al. Expires April 23, 2011 [Page 13] Internet-Draft Broadband Network Transition October 2010 Figure 5: Overview of Solutions in Regional Broadband Network In each transition solution of regional broadband network, it can connect to one of the following backbone described in section 3.1??: o Connect to the Dual-stack IP backbone; o Connect to the IPv6-only backbone for IPv6 traffic and to the existing IP backbone for IPv4 traffic if it has; o Connect to the 6PE on the MPLS backbone for IPv6 traffic and to the existing IP backbone for IPv4 traffic if it has. Some less possible transition solutions haven't been listed above: o Upgrade the existing regional broadband network to IPv6-only; It will lead to a huge influence to existing network and services. o Create a new regional broadband network with native IPv6 CRs and Dual-Stack BRASs; It has very low possibilities because if we create a new regional broadband network to provide dual-stack service with new dual-stack BRAS, the simplest solution will be let the new CRs to be dual-stack too. If the new CRs are IPv6- only, they need other transition technologies working together which seem to be more complicated. o Create a new regional broadband network with Dual-stack CRs and native IPv6 BRASs; It also has very low possibilities and the reason is same as the above one. In the following sections, the technical solutions based on the scenarios in Figure 5 are discussed. Although there may be many technical options in each scenario, the discussion will focus on one of them. The possible solutions referred to Figure 5 that we will discuss: o Solution 1: Dual-Stack and L2TP o Solution 2: Dual-Stack over IPv6 - DS-lite o Solution 3: Dual-Stack over IPv4 - 6rd o Solution 4: IPv6 and NAT64 In this document, it is considering that the CPE is basically purchased by customers. In the PPPoE dial-up cases, most users dial-up from PC, but there is some deployed a Home Gateway (e.g. Yang, et al. Expires April 23, 2011 [Page 14] Internet-Draft Broadband Network Transition October 2010 WLAN AP) by themselves and set up an automatically dial-up from it. Until now, most terminals, including PCs and CPEs, will still be IPv4-only. Although most PC operating system (OS) declared that they already supported IPv6, there is still a problem on supporting PPPoE with IPv6. Not only the most widely used OS, Windows(TM) XP, doesn't support PPPoE with IPv6, but also nearly all CPEs in the market does not support this function. This problem will be a significant bottleneck of the development of IPv6 broadband with PPPoE access method. 6.1. Dual-Stack and L2TP In this solution, both the CRs and BRASs will be transition to Dual- stack by upgrading or replacing the existing devices. However, there are so many different BRASs with diverse IPv6 capability in a large- scale broadband network. So there is a possibility that some BRASs cannot upgrade to Dual-stack and support PPPoE with IPv6. In the Figure 6 below, there are two scenarios in this solution. o Scenario 1: A Dual-stack or IPv6 terminal accessing to a Dual- stack BRAS. o Scenario 2: A Dual-stack or IPv6 terminal accessing to a legacy IPv4-only BRAS. +-----------------------------------------+ CR/AR | Dual-Stack | +-----------------------------------------+ +----------------------+ +----------------+ BRAS | Dual-Stack | | IPv4-only | +----------------------+ +----------------+ +-----------------------------------------+ CPE | Legacy bridged CPE/upgraded routed CPE | +-----------------------------------------+ +-------------------+ +----------------+ User End | Dual-Stack/IPv6 | | Dual-Stack/IPv6| +-------------------+ +----------------+ Scenario1 Scenario2 Figure 6: Dual-stack Transition Solution The Scenario 1 is very simple. But the routing CPE at the edge of customer premises network need to be upgraded to support IPv6 and PPPoE with IPv6. And the PC operation system (OS) also need to Yang, et al. Expires April 23, 2011 [Page 15] Internet-Draft Broadband Network Transition October 2010 support PPPoE with IPv6. The Scenario 2 is a little bit complicated. The BRAS which the subscriber is connecting to is not support IPv6 and PPPoE with IPv6. So, one possible solution could be terminating the point-to-point protocol (PPP) [RFC1661] link at a remote Dual-stack BRAS. A tunnel technology like Layer Two Tunneling Protocol (L2TP) [RFC2661] can be used in this scenario. Other technologies could be an alternative. But considering the device capabilities and the maturity of the technology, the following discussion will focus on the solution that Dual-stack network with L2TP to provide Dual-stack services. [SeeFigure 7] +----------------------+ CR/AR | Dual-Stack | +----------------------+ +------------+_________+----------------+ BRAS | Dual-Stack |___L2TP__| IPv4-only | +------------+ +----------------+ +---------------------------------------+ CPE |Legacy bridged CPE/upgraded routed CPE | +---------------------------------------+ +----------------+ User End | Dual-Stack/IPv6| +----------------+ Figure 7: The L2TP Solution in partly Dual-Stack network Although tunnel technologies can solve this problem, it is considered as a temporary solution. The legacy IPv4-only BRASs will be replaced eventually. For the Dual-stack service, IPv4 address is still need to allocate to terminal. After the IPv4 addresses exhaustion, Dual-stack BRASs could allocate private IPv4 addresses for broadband subscribers, and a NAT44 Large Scale NAT (LSN) [I-D.kuarsingh-lsn-deployment] device will be deployed to provide IPv4 NAT services for subscribers who are using private IPv4 addresses. The operating system (OS) of the new subscriber is recommended to support PPPoE with IPv6. Third-party dial-up software could be provided if the OS is not support PPPoE with IPv6. The routing mode CPE of new subscriber is required to support PPPoE with IPv6. Otherwise, they are required to turn off the auto-dialup function, and initial the PPPoE dial-up session from the host that supports PPPoE with IPv6. Yang, et al. Expires April 23, 2011 [Page 16] Internet-Draft Broadband Network Transition October 2010 The legacy subscribers are recommended to upgrade their OSs and CPEs, but not required. They can still access by IPv4-only. Third-party dial-up software could also be provided to support PPPoE with IPv6. The benefits and drawbacks for this solution could be: Pros: o L2TP can be a temporary solution to provide Dual-stack services with fast and incremental deployment. The BRASs that are unable to upgraded to Dual-stack can be replaced at the end of its lifecycle. o When the IPv4 traffic disappears in the future, the network could be migrated to native IPv6 network gradually. o There is no need to change the existing access method. Although many existing routing mode CPEs are not supporting auto-dialup via PPPoE with IPv6, they can be replaced by existing subscribers smoothly or waiting for new technologies because the network still providing IPv4 service. When the IPv6 contents are abundant enough, legacy subscribers would like to replace or upgrade their CPEs and OSs to gain more services. o Although NAT44 technology is needed after the IPv4 address exhaustion, NAT[RFC3022] is relatively mature compared with IPv4/ IPv6 Translation (e.g. stateful NAT64 [I-D.ietf-behave-v6v4-xlate-stateful], or stateless NAT64 [I-D.xli-behave-ivi]. The major existing applications, such as Instant Messengers, E-mail Terminals and P2P downloaders are already supporting NAT traverse. Transitioning with providing Dual-stack service is much smoother than providing IPv6-only service, especially at the initial stage of the IPv6 transition. o There is no extra cost on the network operation and management. There is still only one physical network in each regional area and the operation and management team can use the original one, though some compulsory training is needed. Cons: o The requirment is that there is at least one Dual-Stack BRAS in the network. And if the BRASs that cannnot support Dual-stack is the majority, when the Dual-stack/IPv6 subscribers grows there could be many L2TP tunnels across the network and the traffic load among BRASs is not balanced which may impact the customer experience. Incremental replacement of the old BRAS should be considered. Yang, et al. Expires April 23, 2011 [Page 17] Internet-Draft Broadband Network Transition October 2010 o Although it is the same issue for any protocol translation technology, some existing applications which do not consider NAT44 traverse may have some problems after the deployment of NAT44 LSN. For example, after the deployment of NAT44 LSN, the service of PPTP VPN has malfunction. Parts of P2P users have worse experience. Applicable scenarios: This solution could be suitable for the initial stage or the intermediate stage of the IPv6 transition when the IPv4 traffic is still very large in the network. And the broadband network is going to provide Dual-stack services with incremental deployment. It is also suitable when the number of subscribers is increasing very fast, and there is a large amount of CPEs and OSs that do not support PPPoE with IPv6. 6.2. Dual-Stack over IPv6 - DS-lite In this solution, the CRs in the regional broadband network are Dual- stack or IPv6-only and the BRASs are IPv6-only. This network is providing a Dual-stack service or an IPv6-only service for subscribers. [See Figure 8] o A Dual-stack or IPv6 terminal accessing to an IPv6-only BRAS. +----------------------+ +---------------+ CR/AR | Dual-Stack | | new IPv6 | +----------------------+ +---------------+ AFTR device somewhere +----------------------------------------+ BRAS | IPv6 | +----------------------------------------+ +-------------------------+ +------------+ CPE | bridged/upgraded routed | | DS-Lite CPE| +-------------------------+ +------------+ +---------------------+ +------------+ User End | IPv6 | | DS/IPv6 | +---------------------+ +------------+ Scenario Figure 8: The DS-Lite Solution in IPv6 Infrastructure The Scenario for IPv6-only subscriber accessing a IPv6 BRAS is very simple. But the routed CPE at the edge of customer premises network needs upgrade to support IPv6 and PPPoE with IPv6. And the PC operation system (OS) also needs to support PPPoE with IPv6 with a Yang, et al. Expires April 23, 2011 [Page 18] Internet-Draft Broadband Network Transition October 2010 bridged CPE. This scenario will exist when the IPv6 traffic is already dominant in the network. The little IPv4 traffic will be translated by a NAT64 device located at the edge of IPv6 Ocean. This situation is similar to the solution in Section 6.4 The Scenario for Dual-stack subscriber is a little bit complicated. It provides Dual-stack service over an IPv6-only infrastructure. The technologies like DS-Lite [I-D.ietf-softwire-dual-stack-lite] can be deployed in this scenario. This section will focus on this technology. DS-Lite is a tunnel technology with a point-to-multipoint IPv4-in- IPv6 tunnel between B4 element and AFTR. According to the definition in [I-D.ietf-softwire-dual-stack-lite], the B4 element is a function implemented on a dual-stack capable node, either a directly connected device or a CPE, which creates a tunnel to an DS-Lite Address Family Translation Router (AFTR) deployed somewhere in the regional broadband network. The operating system (OS) of the new subscriber is recommended to support PPPoE with IPv6. Third-party dial-up software could be provided if the OS is not support PPPoE with IPv6. Subscribers need to replace the existing CPEs for DS-Lite services. The pros and cons of the DS-Lite solution will be: Pros: o We are assuming a completely IPv6 scenario, it is a one-step solution of IPv6 transition. The network infrastructure does not need to upgrade to native IPv6 network in the future. o AFTR is performing a NAT [RFC3022] behavior, which is relatively mature compared with IPv4/IPv6 Translation. The major existing applications, such as Instant Messengers, E-mail Terminals and P2P downloaders are already supporting NAT traverse. Transitioning with providing Dual-stack service is much smoother than providing IPv6-only service, especially at the initial stage of the IPv6 transition. o The IPv4 address used in DS-lite does not need to planned. It is easy for operation and management. Cons: o DS-Lite solution seems not suitable for the transition of the existing network that contains thousands of IPv4-only BRASs. Because the first step should be upgrade the existing BRAS to at Yang, et al. Expires April 23, 2011 [Page 19] Internet-Draft Broadband Network Transition October 2010 least Dual-stack. if the BRASs is upgraded to Dual-stack, DS-Lite does not need any more. Moreover, if the CRs are Dual-stack, and it is planned to add new BRASs to provide Dual-stack service, the simplist solution is let the new BRASs to be Dual-stack. So, DS- Lite solution is only suitable for the new build IPv6 network scenario. o DS-lite CPEs are needed to provide to subscribers, and there is no mature product until now. It may change the original access method and service provisioning method. And the extra installment cost is unacceptable when the number of subscribers is huge. o DS-Lite has not been deployed and verified in any large-scale commercial trail. In the regional broadband network with a large number of dual-stack subscribers, a number of DS-Lite AFTR devices with high performance are needed. The reengineering cost for this solution may be very high. Applicable scenarios: This solution is suitable for the scenarios that providing dual-stack services over an IPv6-only network infrastructure when IPv6 traffic is already dominant in the network. It is also suitable when the broadband subscribers are increasing slowly and the CPEs are provided by operators. Some IPv6-only BRASs could be added for these new subscribers. It is also suitable for the new services which may using IPv6-only, for example, IPTV and Machine-to-machine (M2M) services. 6.3. Dual-Stack over IPv4 - 6rd In this solution, the CRs in the regional broadband network are IPv4- only or Dual-stack and the BRASs are IPv4-only. It provides a Dual- stack service or an IPv6-only service with a completely/partly IPv4 infrastructure for subscribers. The discussion will focus on scenario in Figure 9. o An IPv6 or Dual-stack terminal accessing to an IPv4-only BRAS. Yang, et al. Expires April 23, 2011 [Page 20] Internet-Draft Broadband Network Transition October 2010 +----------------------------------------+ CR/AR | Dual-Stack/IPv4 | +----------------------------------------+ 6rd border router somewhere +----------------------------------------+ BRAS | IPv4 | +----------------------------------------+ +-------------------------+ +------------+ CPE | bridged/upgraded routed | | 6rd CPE | +-------------------------+ +------------+ +------------+ User End | DS/IPv6 | +------------+ Figure 9: The 6rd Solution in an IPv4 infrastructure A possible technical solution for this scenario is IPv6 Rapid Deployment (6rd) [RFC5969]. There are two components in this solution. 6rd CPEs support IPv6 on their customer premise side and support 6rd on the provider side. 6rd gateway (a.k.a 6rd border router or 6rd relay) is operated at the border between IPv4 infrastructure and the IPv6 Internet. The 6rd mechanism operates statelessly, which ensures simplicity and scalability. The IPv4 address in the IPv4 infrastructure could be a private address, 6rd mechanism can support the private IPv4 address. The pros and cons of the 6rd solution will be: Pros: o 6rd solution does not need to upgrade the IPv4 infrastructure. It can deploy incrementally by adding some 6rd gateways in the network. Therefore the engineering complexity and cost is low compared with other solutions. o Although NAT44 technology is needed after the IPv4 address exhaustion, NAT[RFC3022] is relatively mature compared with IPv4/ IPv6 Translation. The major existing applications, such as Instant Messengers, E-mail Terminals and P2P downloaders are already supporting NAT traverse. Transitioning with providing Dual-stack service is much smoother than providing IPv6-only service, especially at the initial stage of the IPv6 transition. o There is no extra cost on the network operation and management. There is still only one physical network in each regional area and the operation and management team can use the original one, though some compulsory training is needed. Yang, et al. Expires April 23, 2011 [Page 21] Internet-Draft Broadband Network Transition October 2010 Cons: o When the network infrastructure is transitioning to IPv6 in the future, the access method may need to be changed again. 6rd is not applicable when the infrastructure is IPv6-only in the future. When the BRASs are removed by nature, the new BRASs for replacement will enable IPv6 and the 6rd may be useless. o 6rd CPE need to be provided to subscribers, which will lead to a huge amount of devices cost and installment cost. And when the IPv6 traffic is extremely high, each regional broadband network may need a number of 6RD border routers to ensure the performance. Applicable scenarios: This solution may be suitable for the initial stage of the IPv6 transition, providing IPv6 services with rapid deployment. 6.4. IPv6 and NAT64 This solution is for the IPv6-only subscribers that are accessing to the new built IPv6-only regional broadband network. Basically, only IPv6 address is allocated to the subscribers. And for the requirement ofaccessing IPv4 applications and contents, it needs to deploy a IPv6/IPv4 Translation device to solve the intercommunication problem between IPv6 and IPv4 for the IPv6-only subscribers. +------++----------+ +------+ Backbone| IPv4 ||Dual-stack| | IPv6 | +.-----++.------*--+ +--*---+ +--.-------.--+ * * * IPv6 Traffic | . NAT64 . | * * . IPv4 Traffic +--*-------*--+---*-------*--+ CR/AR | * IPv6 * | +----------------------------+ +----------------------------+ BRAS | IPv6 | +----------------------------+ +------------------------+ User End | IPv6 | +------------------------+ Figure 10: The NAT64 Solution in an IPv6 infrastructure - Scenario 1 The operating system (OS) is required to support PPPoE with IPv6. Third-party dial-up software could be provided if the OS of the new hosts is unable to support PPPoE with IPv6. Yang, et al. Expires April 23, 2011 [Page 22] Internet-Draft Broadband Network Transition October 2010 The routing mode CPE that is purchased by subscribers is also required to support PPPoE with IPv6 as well, or to turn off the auto- dialup function, and initial the PPPoE with IPv6 dial-up session from the host. Pros: o This solution is usually building a new IPv6 network which could avoid the risk from changing the existing regional broadband network. o Building a completely new network is much easier than upgrade from the existing one. That is because there is no subscriber with no traffic on the new network. o It is no need to allocate IPv4 address for subscribers. o It is benefit the development of IPv6 and 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 NAT64 mechanisms have not been deployed and verified in large scale commercial trails. And the NAT64 technologies are still immature, the users experience with this solution could be worse. o The requirement of NAT64 device performance is very high, especially when there is a large amount of subscribers. The situation could be much worse because the IPv4 traffic is still the majority at the IPv6 initial stage. o The cost is huge and the investment is duplicated with the existing one. The existing network infrastructure is usually kept up-to-date. Building a new network may lead to an early end of the lifecycle of the existing network infrastructure, which will lead to investment loss. o Building a completely new regional broadband network is usually along with building a new transmission infrastructure. And the engineering period will be very long. o After the new network is built, there are two networks in the same area, which will lead an extra operational cost. Applicable scenarios: This solution is suitable for the last-step of Yang, et al. Expires April 23, 2011 [Page 23] Internet-Draft Broadband Network Transition October 2010 the IPv6 transition. The IPv6 contents and services are already very popular and abundant. Besides, IPv6/IPv4 Translation technology is relatively mature and the IPv4 traffic is little. In this case, we can disable the IPv4 protocol stack of the Dual-stack devices, and NAT64 devices can also be deployed at several sites to meet the requirement of IPv6-only users who are visiting the historical IPv4 services. 7. Backwards Compatibility 8. Conclusions TBD... 9. Acknowledgements The authors would like to acknowledge the discussions on this topic with Dave Thaler, Denis Alexeitsev, Jari Arkko, R"|mi Despr"|s, Tina TSOU, Tom Taylor and Tony Li. 10. IANA Considerations This memo includes no request to IANA. 11. 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. 12. References 12.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. Yang, et al. Expires April 23, 2011 [Page 24] Internet-Draft Broadband Network Transition October 2010 12.2. Informative References [I-D.huang-v6ops-v4v6tran-bb-usecase] Huang, C., Li, X., and L. Hu, "Use Case For IPv6 Transition For a Large-Scale Broadband network", draft-huang-v6ops-v4v6tran-bb-usecase-00 (work in progress), September 2010. [I-D.ietf-behave-v6v4-xlate-stateful] Bagnulo, M., Matthews, P., and I. Beijnum, "Stateful NAT64: Network Address and Protocol Translation from IPv6 Clients to IPv4 Servers", draft-ietf-behave-v6v4-xlate-stateful-12 (work in progress), July 2010. [I-D.ietf-softwire-dual-stack-lite] Durand, A., Droms, R., Woodyatt, J., and Y. Lee, "Dual- Stack Lite Broadband Deployments Following IPv4 Exhaustion", draft-ietf-softwire-dual-stack-lite-06 (work in progress), August 2010. [I-D.kuarsingh-lsn-deployment] Kuarsingh, V. and J. Cianfarani, "NAT44/LSN Deployment Options and Experiences", draft-kuarsingh-lsn-deployment-00 (work in progress), July 2010. [I-D.xli-behave-ivi] Li, X., Bao, C., Chen, M., Zhang, H., and J. Wu, "The CERNET IVI Translation Design and Deployment for the IPv4/ IPv6 Coexistence and Transition", draft-xli-behave-ivi-07 (work in progress), January 2010. [I-D.zhou-softwire-ds-lite-p2p] Zhou, C., ZOU), T., Lee, Y., and G. Yang, "Deployment DS- lite in Point-to-Point Access Network", draft-zhou-softwire-ds-lite-p2p-02 (work in progress), July 2010. [RFC1661] Simpson, W., "The Point-to-Point Protocol (PPP)", STD 51, RFC 1661, July 1994. [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. [RFC2629] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629, June 1999. Yang, et al. Expires April 23, 2011 [Page 25] Internet-Draft Broadband Network Transition October 2010 [RFC2637] Hamzeh, K., Pall, G., Verthein, W., Taarud, J., Little, W., and G. Zorn, "Point-to-Point Tunneling Protocol", RFC 2637, July 1999. [RFC2661] Townsley, W., Valencia, A., Rubens, A., Pall, G., Zorn, G., and B. Palter, "Layer Two Tunneling Protocol "L2TP"", RFC 2661, August 1999. [RFC3022] Srisuresh, P. and K. Egevang, "Traditional IP Network Address Translator (Traditional NAT)", RFC 3022, January 2001. [RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol Label Switching Architecture", RFC 3031, January 2001. [RFC3107] Rekhter, Y. and E. Rosen, "Carrying Label Information in BGP-4", RFC 3107, May 2001. [RFC3376] Cain, B., Deering, S., Kouvelas, I., Fenner, B., and A. Thyagarajan, "Internet Group Management Protocol, Version 3", RFC 3376, October 2002. [RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC Text on Security Considerations", BCP 72, RFC 3552, July 2003. [RFC3697] Rajahalme, J., Conta, A., Carpenter, B., and S. Deering, "IPv6 Flow Label Specification", RFC 3697, March 2004. [RFC3810] Vida, R. and L. Costa, "Multicast Listener Discovery Version 2 (MLDv2) for IPv6", RFC 3810, June 2004. [RFC4798] De Clercq, J., Ooms, D., Prevost, S., and F. Le Faucheur, "Connecting IPv6 Islands over IPv4 MPLS Using IPv6 Provider Edge Routers (6PE)", RFC 4798, February 2007. [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008. [RFC5969] Townsley, W. and O. Troan, "IPv6 Rapid Deployment on IPv4 Infrastructures (6rd) -- Protocol Specification", RFC 5969, August 2010. Yang, et al. Expires April 23, 2011 [Page 26] Internet-Draft Broadband Network Transition October 2010 Authors' Addresses GuoLiang Yang (editor) China Telecom 109, Zhongshan Ave. West, Guangzhou, Tianhe District 510630 P.R. China Phone: Email: yanggl@gsta.com LeMing Hu China Telecom 109, Zhongshan Ave. West, Guangzhou, Tianhe District 510630 P.R. China Phone: Email: hulm@gsta.com JinYan Lin China Telecom 109, Zhongshan Ave. West, Guangzhou, Tianhe District 510630 P.R. China Phone: Email: jasonlin.gz@gmail.com Yang, et al. Expires April 23, 2011 [Page 27]