RFC 4779
ISP IPv6 Deployment Scenarios in Broadband Access Networks
Network Working Group S. Asadullah Request for Comments: 4779 A. Ahmed Category: Informational C. Popoviciu Cisco Systems P. Savola CSC/FUNET J. Palet Consulintel January 2007 ISP IPv6 Deployment Scenarios in Broadband Access Networks Status of This Memo This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited. Copyright Notice Copyright (C) The IETF Trust (2007).Abstract
This document provides a detailed description of IPv6 deployment and integration methods and scenarios in today's Service Provider (SP) Broadband (BB) networks in coexistence with deployed IPv4 services. Cable/HFC, BB Ethernet, xDSL, and WLAN are the main BB technologies that are currently deployed, and discussed in this document. The emerging Broadband Power Line Communications (PLC/BPL) access technology is also discussed for completeness. In this document we will discuss main components of IPv6 BB networks, their differences from IPv4 BB networks, and how IPv6 is deployed and integrated in each of these networks using tunneling mechanisms and native IPv6.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Common Terminology . . . . . . . . . . . . . . . . . . . . . . 5 3. Core/Backbone Network . . . . . . . . . . . . . . . . . . . . 5 3.1. Layer 2 Access Provider Network . . . . . . . . . . . . . 5 3.2. Layer 3 Access Provider Network . . . . . . . . . . . . . 6 4. Tunneling Overview . . . . . . . . . . . . . . . . . . . . . . 7 4.1. Access over Tunnels - Customers with Public IPv4 Addresses . . . . . . . . . . . . . . . . . . . . . . . . 7 4.2. Access over Tunnels - Customers with Private IPv4 Addresses . . . . . . . . . . . . . . . . . . . . . . . . 8 4.3. Transition a Portion of the IPv4 Infrastructure . . . . . 8 5. Broadband Cable Networks . . . . . . . . . . . . . . . . . . . 9 5.1. Broadband Cable Network Elements . . . . . . . . . . . . . 9 5.2. Deploying IPv6 in Cable Networks . . . . . . . . . . . . . 10 5.2.1. Deploying IPv6 in a Bridged CMTS Network . . . . . . . 12 5.2.2. Deploying IPv6 in a Routed CMTS Network . . . . . . . 14 5.2.3. IPv6 Multicast . . . . . . . . . . . . . . . . . . . . 23 5.2.4. IPv6 QoS . . . . . . . . . . . . . . . . . . . . . . . 24 5.2.5. IPv6 Security Considerations . . . . . . . . . . . . . 24 5.2.6. IPv6 Network Management . . . . . . . . . . . . . . . 25 6. Broadband DSL Networks . . . . . . . . . . . . . . . . . . . . 26 6.1. DSL Network Elements . . . . . . . . . . . . . . . . . . . 26 6.2. Deploying IPv6 in IPv4 DSL Networks . . . . . . . . . . . 28 6.2.1. Point-to-Point Model . . . . . . . . . . . . . . . . . 29 6.2.2. PPP Terminated Aggregation (PTA) Model . . . . . . . . 30 6.2.3. L2TPv2 Access Aggregation (LAA) Model . . . . . . . . 33 6.2.4. Hybrid Model for IPv4 and IPv6 Service . . . . . . . . 36 6.3. IPv6 Multicast . . . . . . . . . . . . . . . . . . . . . . 38 6.3.1. ASM-Based Deployments . . . . . . . . . . . . . . . . 39 6.3.2. SSM-Based Deployments . . . . . . . . . . . . . . . . 39 6.4. IPv6 QoS . . . . . . . . . . . . . . . . . . . . . . . . . 40 6.5. IPv6 Security Considerations . . . . . . . . . . . . . . . 41 6.6. IPv6 Network Management . . . . . . . . . . . . . . . . . 42 7. Broadband Ethernet Networks . . . . . . . . . . . . . . . . . 42 7.1. Ethernet Access Network Elements . . . . . . . . . . . . . 42 7.2. Deploying IPv6 in IPv4 Broadband Ethernet Networks . . . . 43 7.2.1. Point-to-Point Model . . . . . . . . . . . . . . . . . 44 7.2.2. PPP Terminated Aggregation (PTA) Model . . . . . . . . 46 7.2.3. L2TPv2 Access Aggregation (LAA) Model . . . . . . . . 48 7.2.4. Hybrid Model for IPv4 and IPv6 Service . . . . . . . . 50 7.3. IPv6 Multicast . . . . . . . . . . . . . . . . . . . . . . 52 7.4. IPv6 QoS . . . . . . . . . . . . . . . . . . . . . . . . . 53 7.5. IPv6 Security Considerations . . . . . . . . . . . . . . . 54 7.6. IPv6 Network Management . . . . . . . . . . . . . . . . . 55
8. Wireless LAN . . . . . . . . . . . . . . . . . . . . . . . . . 55 8.1. WLAN Deployment Scenarios . . . . . . . . . . . . . . . . 55 8.1.1. Layer 2 NAP with Layer 3 termination at NSP Edge Router . . . . . . . . . . . . . . . . . . . . . . . . 56 8.1.2. Layer 3 Aware NAP with Layer 3 Termination at Access Router . . . . . . . . . . . . . . . . . . . . 59 8.1.3. PPP-Based Model . . . . . . . . . . . . . . . . . . . 61 8.2. IPv6 Multicast . . . . . . . . . . . . . . . . . . . . . . 63 8.3. IPv6 QoS . . . . . . . . . . . . . . . . . . . . . . . . . 65 8.4. IPv6 Security Considerations . . . . . . . . . . . . . . . 65 8.5. IPv6 Network Management . . . . . . . . . . . . . . . . . 67 9. Broadband Power Line Communications (PLC) . . . . . . . . . . 67 9.1. PLC/BPL Access Network Elements . . . . . . . . . . . . . 68 9.2. Deploying IPv6 in IPv4 PLC/BPL . . . . . . . . . . . . . . 69 9.2.1. IPv6 Related Infrastructure Changes . . . . . . . . . 69 9.2.2. Addressing . . . . . . . . . . . . . . . . . . . . . . 69 9.2.3. Routing . . . . . . . . . . . . . . . . . . . . . . . 70 9.3. IPv6 Multicast . . . . . . . . . . . . . . . . . . . . . . 71 9.4. IPv6 QoS . . . . . . . . . . . . . . . . . . . . . . . . . 71 9.5. IPv6 Security Considerations . . . . . . . . . . . . . . . 71 9.6. IPv6 Network Management . . . . . . . . . . . . . . . . . 71 10. Gap Analysis . . . . . . . . . . . . . . . . . . . . . . . . . 71 11. Security Considerations . . . . . . . . . . . . . . . . . . . 74 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 74 13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 74 13.1. Normative References . . . . . . . . . . . . . . . . . . . 74 13.2. Informative References . . . . . . . . . . . . . . . . . . 76
1. Introduction
This document presents the options available in deploying IPv6 services in the access portion of a BB Service Provider (SP) network - namely Cable/HFC, BB Ethernet, xDSL, WLAN, and PLC/BPL. This document briefly discusses the other elements of a provider network as well. It provides different viable IPv6 deployment and integration techniques, and models for each of the above-mentioned BB technologies individually. The example list is not exhaustive, but it tries to be representative. This document analyzes how all the important components of current IPv4-based Cable/HFC, BB Ethernet, xDSL, WLAN, and PLC/BPL networks will behave when IPv6 is integrated and deployed. The following important pieces are discussed: A. Available tunneling options B. Devices that would have to be upgraded to support IPv6 C. Available IPv6 address assignment techniques and their use D. Possible IPv6 Routing options and their use E. IPv6 unicast and multicast packet transmission F. Required IPv6 Quality of Service (QoS) parameters G. Required IPv6 Security parameters H. Required IPv6 Network Management parameters It is important to note that the addressing rules provided throughout this document represent an example that follows the current assignment policies and recommendations of the registries. However, they can be adapted to the network and business model needs of the ISPs. The scope of the document is to advise on the ways of upgrading an existing infrastructure to support IPv6 services. The recommendation to upgrade a device to dual stack does not stop an SP from adding a new device to its network to perform the necessary IPv6 functions discussed. The costs involved with such an approach could be offset by lower impact on the existing IPv4 services.
2. Common Terminology
BB: Broadband CPE: Customer Premise Equipment GWR: Gateway Router ISP: Internet Service Provider NAP: Network Access Provider NSP: Network Service Provider QoS: Quality of Service SP: Service Provider3. Core/Backbone Network
This section intends to briefly discuss some important elements of a provider network tied to the deployment of IPv6. A more detailed description of the core network is provided in other documents [RFC4029]. There are two types of networks identified in the Broadband deployments: A. Access Provider Network: This network provides the broadband access and aggregates the subscribers. The subscriber traffic is handed over to the Service Provider at Layer 2 or 3. B. Service Provider Network: This network provides Intranet and Internet IP connectivity for the subscribers. The Service Provider network structure beyond the Edge Routers that interface with the Access provider is beyond the scope of this document.3.1. Layer 2 Access Provider Network
The Access Provider can deploy a Layer 2 network and perform no routing of the subscriber traffic to the SP. The devices that support each specific access technology are aggregated into a highly redundant, resilient, and scalable Layer 2 core. The network core can involve various technologies such as Ethernet, Asynchronous Transfer Mode (ATM), etc. The Service Provider Edge Router connects to the Access Provider core.
This type of network may be transparent to the Layer 3 protocol. Some possible changes may come with the intent of supporting IPv6 provisioning mechanisms, as well as filtering and monitoring IPv6 traffic based on Layer 2 information such as IPv6 Ether Type Protocol ID (0x86DD) or IPv6 multicast specific Media Access Control (MAC) addresses (33:33:xx:xx:xx:xx).3.2. Layer 3 Access Provider Network
The Access Provider can choose to terminate the Layer 2 domain and route the IP traffic to the Service Provider network. Access Routers are used to aggregate the subscriber traffic and route it over a Layer 3 core to the SP Edge Routers. In this case, the impact of the IPv6 deployment is significant. The case studies in this document discuss only the relevant network elements of such a network: Customer Premise Equipment, Access Router, and Edge Router. In real networks, the link between the Access Router and the Edge Router involves other routers that are part of the aggregation and the core layer of the Access Provider network. The Access Provider can forward the IPv6 traffic through its Layer 3 core in three possible ways: A. IPv6 Tunneling: As a temporary solution, the Access Provider can choose to use a tunneling mechanism to forward the subscriber IPv6 traffic to the Service Provider Edge Router. This approach has the least impact on the Access Provider network; however, as the number of users increase and the amount of IPv6 traffic grows, the ISP will have to evolve to one of the scenarios listed below. B. Native IPv6 Deployment: The Access Provider routers are upgraded to support IPv6 and can become dual stack. In a dual-stack network, an IPv6 Interior Gateway Protocol (IGP), such as OSPFv3 [RFC2740] or IS-IS [ISISv6], is enabled. RFC 4029 [RFC4029] discusses the IGP selection options with their benefits and drawbacks. C. MPLS 6PE Deployment [6PE]: If the Access Provider is running MPLS in its IPv4 core, it could use 6PE to forward IPv6 traffic over it. In this case, only a subset of routers close to the edge of the network need to be IPv6 aware. With this approach, BGP becomes important in order to support 6PE. The 6PE approach has the advantage of having minimal impact on the Access Provider network. Fewer devices need to be upgraded and
configured while the MPLS core continues to switch the traffic, unaware that it transports both IPv4 and IPv6. 6PE should be leveraged only if MPLS is already deployed in the network. At the time of writing this document, a major disadvantage of the 6PE solution is that it does not support multicast IPv6 traffic. The native approach has the advantage of supporting IPv6 multicast traffic, but it may imply a significant impact on the IPv4 operational network in terms of software configuration and possibly hardware upgrade. More detailed Core Network deployment recommendations are discussed in other documents [RFC4029]. The handling of IPv6 traffic in the Core of the Access Provider Network will not be discussed for the remainder of this document.4. Tunneling Overview
If SPs are not able to deploy native IPv6, they might use tunneling- based transition mechanisms to start an IPv6 service offering, and move to native IPv6 deployment at a later time. Several tunneling mechanisms were developed specifically to transport IPv6 over existing IPv4 infrastructures. Several of them have been standardized and their use depends on the existing SP IPv4 network and the structure of the IPv6 service. The requirements for the most appropriate mechanisms are described in [v6tc] with more updates to follow. Deploying IPv6 using tunneling techniques can imply as little changes to the network as upgrading software on tunnel end points. A Service Provider could use tunneling to deploy IPv6 in the following scenarios:4.1. Access over Tunnels - Customers with Public IPv4 Addresses
If the customer is a residential user, it can initiate the tunnel directly from the IPv6 capable host to a tunnel termination router located in the NAP or ISP network. The tunnel type used should be decided by the SP, but it should take into consideration its availability on commonly used software running on the host machine. Of the many tunneling mechanisms developed, such as IPv6 Tunnel Broker [RFC3053], Connection of IPv6 Domains via IPv4 Clouds [RFC3056], Generic Packet Tunneling in IPv6 [RFC2473], ISATAP [RFC4214], Basic Transition Mechanisms for IPv6 Hosts and Routers [RFC4213], and Transmission of IPv6 over IPv4 Domains without Explicit Tunnels [RFC2529], some are more popular than the others. At the time of writing this document, the IETF Softwire Working Group was tasked with standardizing a single tunneling protocol [Softwire] for this application.
If the end customer has a GWR installed, then it could be used to originate the tunnel, thus offering native IPv6 access to multiple hosts on the customer network. In this case, the GWR would need to be upgraded to dual stack in order to support IPv6. The GWR can be owned by the customer or by the SP.4.2. Access over Tunnels - Customers with Private IPv4 Addresses
If the end customer receives a private IPv4 address and needs to initiate a tunnel through Network Address Translation (NAT), techniques like 6to4 may not work since they rely on public IPv4 address. In this case, unless the existing GWRs support protocol-41- forwarding [Protocol41], the end user might have to use tunnels that can operate through NATs (such as Teredo [RFC4380]). Most GWRs support protocol-41-forwarding, which means that hosts can initiate the tunnels - in which case the GWR is not affected by the IPv6 service. The customer has the option to initiate the tunnel from the device (GWR) that performs the NAT functionality, similar to the GWR scenario discussed in Section 4.1. This will imply hardware replacement or software upgrade and a native IPv6 environment behind the GWR. It is also worth observing that initiating an IPv6 tunnel over IPv4 through already established IPv4 IPsec sessions would provide a certain level of security to the IPv6 traffic.4.3. Transition a Portion of the IPv4 Infrastructure
Tunnels can be used to transport the IPv6 traffic across a defined segment of the network. As an example, the customer might connect natively to the Network Access Provider, where a tunnel is used to transit the traffic over IPv4 to the ISP. In this case, the tunnel choice depends on its capabilities (for example, whether or not it supports multicast), routing protocols used (there are several types that can transport Layer 2 messages, such as GRE [RFC2784], L2TPv3 [RFC3931], or pseudowire), manageability, and scalability (dynamic versus static tunnels). This scenario implies that the access portion of the network has been upgraded to support dual stack, so the savings provided by tunneling in this scenario are very small compared with the previous two scenarios. Depending on the number of sites requiring the service, and considering the expenses required to manage the tunnels (some tunnels are static while others are dynamic [DynamicTunnel]) in this case, the SPs might find the native approach worth the additional investments.
In all the scenarios listed above, the tunnel selection process should consider the IPv6 multicast forwarding capabilities if such service is planned. As an example, 6to4 tunnels do not support IPv6 multicast traffic. The operation, capabilities, and deployment of various tunnel types have been discussed extensively in the documents referenced earlier as well as in [RFC4213] and [RFC3904]. Details of a tunnel-based deployment are offered in the next section of this document, which discusses the case of Cable Access, where the current Data Over Cable Service Interface Specification (DOCSIS 2.0) [RF-Interface] and prior specifications do not provide support for native IPv6 access. Although Sections 6, 7, 8, and 9 focus on a native IPv6 deployments over DSL, Fiber to the Home (FTTH), wireless, and PLC/BPL and because this approach is fully supported today, tunnel-based solutions are also possible in these cases based on the guidelines of this section and some of the recommendations provided in Section 5.
(page 9 continued on part 2)
