IPv6 Working Group Salman Asadullah INTERNET DRAFT Adeel Ahmed August 2004 Ciprian Popoviciu Cisco Systems ISP IPv6 Deployment Scenarios in Broadband Access Networks Status of this Memo By submitting this Internet-Draft, I certify that any applicable patent or other IPR claims of which I am aware have been disclosed, and any of which I become aware will be disclosed, in accordance with [RFC 3668]. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. 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." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on March 2005. Abstract This document provides detailed description of IPv6 deployment and integration methods and scenarios in today's Service Provider (SP) Broadband (BB) networks in coexistance with deployed IPv4 services. Cable/HFC, BB Ethernet, xDSL and WLAN are the main BB technologies that are currently deployed, and discussed in this draft. In this document we will discuss main components of IPv6 BB networks and their differences from IPv4 BB networks and how IPv6 is deployed and integrated in each of these BB technologies. draft-asadullah-v6ops-bb-deployment-scenarios-00.txt [Page 1] INTERNET-DRAFT ISP IPv6 Deployment Scenarios in BB Networks July 2004 Table of Contents: 1. Introduction................................................2 2. IPv6 Based BB Services......................................2 3. Scope of the Document.......................................4 4. Core Backbone Network.......................................4 4.1 Layer2 Access Provider..................................5 4.2 Layer3 Access Provider..................................5 5. Broadband Cable Networks ...................................6 5.1 Broadband Cable Network Elements .......................7 5.2 Deploying IPv6 in today's Cable Networks................8 5.2.1 Bridged CMTS Network ............................9 5.2.2 Routed CMTS Network ............................11 5.3 IPv6 Multicast ........................................20 5.4 IPv6 QoS ..............................................21 5.5 IPv6 Security Considerations...........................21 5.6 IPv6 Network Management ...............................22 6. Broadband DSL Networks.....................................22 6.1 DSL Network Elements ..................................22 6.2 Deploying IPv6 in today's IPv4 DSL Networks............23 6.2.1 Point-to-Point Model............................24 6.2.2 PPP Terminated Aggregation (PTA) Model..........26 6.2.3 L2TP Access Aggregation (LAA) Model.............29 6.2.4 Hybrid Model for IPv4 and IPv6 Service .........31 6.3 IPv6 Multicast.........................................34 6.4 IPv6 QoS...............................................34 6.5 IPv6 Security Considerations...........................35 6.6 IPv6 Network Management................................35 7. Broadband Ethernet Networks................................36 7.1 Ethernet Access Network Elements .....................36 7.2 Deploying IPv6 in today's IPv4 BB Ethernet Networks...37 7.2.1 Point-to-Point Model...........................37 7.2.2 PPP Terminated Aggregation (PTA) Model.........39 7.2.3 L2TP Access Aggregation (LAA) Model............41 7.2.4 Hybrid Model for IPv4 and IPv6 Service ........43 7.3 IPv6 Multicast........................................45 7.4 IPv6 QoS..............................................46 7.5 IPv6 Security Considerations..........................47 7.6 IPv6 Network Management...............................47 8. Broadband Wireless LAN Networks............................47 8.1 WLAN Deployment Scenarios.............................47 8.1.1 Layer2 Switch Between AP and SP Edge Router....49 8.1.2 Access Router Between AP and SP Edge Router....51 8.1.3 PPP Based Model................................54 8.2 IPv6 Multicast........................................56 8.3 IPv6 QoS..............................................57 8.4 IPv6 Security Considerations..........................58 draft-asadullah-v6ops-bb-deployment-scenarios-00.txt [Page 2] INTERNET-DRAFT ISP IPv6 Deployment Scenarios in BB Networks July 2004 8.5 IPv6 Network Management...............................58 9. Acknowledgments............................................58 10.References.................................................59 Authors' Addresses............................................60 1. Introduction With the exponential growth of the Internet and increasing number of end users, SPs are looking for new ways to evolve their current network architecture to meet the needs of Internet ready appliances, new applications and services. IPv6 is designed to enable SPs to meet these challenges and provide new services to their customers. As the number of BB users increase exponentially worldwide, Cable, DSL, Ethernet to the Home, Wireless and other always-on access technologies can benefit from IPv6Æs huge address range [RFC 3513]. Therefore SPs are aggressively evaluating the capabilities of IPv6 to meet these needs. Some countries have taken a lead role in this race and moved from testing and evaluation to real deployments of IPv6 in the BB arena. Japan is a prime example along with Korea, China and other countries that are looking at moving towards large scale production deployments of IPv6. 2. IPv6 Based BB Services At this point IPv6 based services are seen as a differentiator that enables SPs to take advantage of the large IPv6 address space and allows them to better position themselves against the competition. Another reason of IPv6 being very popular in some countries is the government driven financial incentives and favorable legislation to the ISPs who are deploying IPv6. NTT East, Japan started a commercial dual-stack (devices capable of forwarding IPv4 and IPv6 packets) unicast service option early this year for its ADSL and FTTH subscribers, under the name of ôFLETÆS.Netö [Dual Stack Access]. draft-asadullah-v6ops-bb-deployment-scenarios-00.txt [Page 3] INTERNET-DRAFT ISP IPv6 Deployment Scenarios in BB Networks July 2004 For these users the IPv6 addresses are dedicated (/64 per user) and are used when needed. However, this IPv6 service is available to the NTT-EastÆs ADSL and FTTH subscribers who are part of ôFLETÆS.NETö network only and at this point does not provide connectivity to the IPv6 Internet. It should be noticed that where a home user generally gets a single IPv4 address (dynamic or static), the IPv6 service provides a full subnet (/64). Some ISPs that are currently providing IPv4 based Multicast and VoIP services are evaluating IPv6 to take advantage of the huge address space and other useful features. The Multicast services consist of video and audio streaming of several programs (streams). The content provider will have certain content (which is of user interest) and they would send these multicast streams to BB subscribers. Today, when done through IPv4, there is generally a single device directly attached to the CPE that receives the Multicast stream. By moving to IPv6, ISP should be capable to provide multiple streams to multiple devices on the customer site. For instance in Japan, Cable TV and dish services are not very popular, the users expect everything through the broadcasted, free programs (traditional TV). In case of BB users however, they can get some extra content through the SP, which is very reasonably priced for 20 Mbps or 10/100 Mbps of bandwidth. Users sign up with a content provider that is multicasting several channels of video and audio. A subscriber would join the multicast group of interest (after authentication) and will start receiving the stream(s). An example of a video stream could be Disney movies and an example of an audio stream could be Karaoke (part of same *,G group). Similar to Cable TV, where customers sign up and pay for single program or packages of programs. SPs are also offering IPv6 services over wireless links using 802.11 compliant WiFi Hot Spots. This enables users to take notebook PCs and PDAs (Windows 2003 supports IPv6 capable Internet Explorer and Media Player 9) along with them and connect to the Internet from various locations without the restriction of staying indoors. draft-asadullah-v6ops-bb-deployment-scenarios-00.txt [Page 4] INTERNET-DRAFT ISP IPv6 Deployment Scenarios in BB Networks July 2004 3. Scope of the Document The focus of this draft is to present the options available in deploying IPv6 services in the access portion of a BB Service Provider's network namely Cable/HFC, BB Ethernet, xDSL and WLAN. This drafts briefly discusses the other elements of a provider's network as well. This draft provides different viable IPv6 deployment and integration techniques and models for each of the above mentioned BB technologies seperately in detail. This draft analyzes, how all the important parts of current IPv4 based Cable/HFC, BB Ethernet, xDSL and WLAN networks will behave when IPv6 is integrated and deployed. Following important pieces such as: - Devices that would require to be upgraded to support IPv6 - Available IPv6 address assignment techniques and their use - Possible IPv6 Routing options and their use - IPv6 unicast and multicast packet transmition - Required IPv6 QoS parameters - Required IPv6 Security parameters - Required IPv6 Network Management parameters 4. Core/Backbone Network This section intends to briefly discuss the some important elements of a provider's network tied to deployment of IPv6. A more detailed description of the core network is provided in other drafts [ISP Networks IPv6 Scenarios]. There are two networks identified in the Broadband deployments: draft-asadullah-v6ops-bb-deployment-scenarios-00.txt [Page 5] INTERNET-DRAFT ISP IPv6 Deployment Scenarios in BB Networks July 2004 - 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. - 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 draft. 4.1 Layer2 Access Provider Network The Access Provider can deploy a Layer2 network, where it will not be involved in routing the subscriber traffic to the SP. The devices that support each specific access technology are aggregated into a highly redundant, resilient and scalable layer two core. The network core can involve various technologies such as Ethernet, ATM and etc. The Service Provider Edge Router connects to the Access Provider core. In this type of a network the impact of deploying IPv6 is minimal. The network is transparent to the Layer 3 protocol. The only possible changes would come with the intent of filtering IPv6 traffic based on layer 2 information such as IPv6 Ether Type Protocol ID (0x86DD) or IPv6 multicast specific MAC addresses (3333.xxxx.xxxx). 4.2 Layer3 Access Provider Network The Access Provider can choose to terminate the Layer2 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 Layer3 core to the SP Edge Routers. In this case the impact of the IPv6 deployment is signficant. The case studies in this draft only present the significant network elements of such a network: Customer Premises 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 layer3 core in three possible ways: draft-asadullah-v6ops-bb-deployment-scenarios-00.txt [Page 6] INTERNET-DRAFT ISP IPv6 Deployment Scenarios in BB Networks July 2004 A. IPv6 Tunneling: As a temporrary 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 it is not suitable for a large scale production deployment. B. Native IPv6 Deployment: The Access Provider routers are upgraded to support IPv6 and become dual-stack. An IPv6 IGP such as OSPFv3 or IS-IS is enabled usually mapping the IGP deployed for IPv4. The most important thing to remember is that a software upgrade of the network elements in the core might not be sufficient to deploy IPv6. Hardware upgrades might be needed in order to achieve high performance IPv6 forwarding. C. MPLS 6PE Deployment: If the Access Provider is running MPLS in its IPv4 core it could use 6PE to forward IPv6 traffic over its MPLS core. In this case only a subset of routers close to the edge of the network needs to be IPv6 aware. With this approach BGP becomes important in order to support 6PE. Its deployment will most likely leverage the Route Reflector structure used with the IPv4 deployment. The 6PE approach has the advantage of having minimal impact on the Access Provider's network. Fewer devices need to be upgraded and configured while the MPLS core continues to switch the traffic un-aware of the fact that it transports both IPv4 and IPv6 traffic. 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 the fact that it doesn't support multicast IPv6 traffic. The native/dual-stack approach has the advantage of supporting IPv6 multicast traffic but it implies a significant impact on the IPv4 operational network from software, configuration and possibly hardware upgrade perspective. More detailed Core Network deployment recomendations are discussed in other documents [1, ISP-scenarios]. The handling of IPv6 traffic in the Core of the Access Provider Network will not be dicussed for the remainder of this document. 5. Broadband Cable Networks This section describes the infrastructure that exists today in cable networks that support cable modem services to the home. It also describes IPv6 deployment options in today's cable networks. draft-asadullah-v6ops-bb-deployment-scenarios-00.txt [Page 7] INTERNET-DRAFT ISP IPv6 Deployment Scenarios in BB Networks July 2004 5.1 Broadband Cable Network Elements Broadband cable networks are capable of transporting IP traffic to/ from users to provide high speed Internet access and VOIP services. The mechanism of transporting IP traffic over cable networks is outlined in the DOCSIS specification [RF Interface]. Here are some of the key elements of a Cable network: Cable (HFC) Plant: Hybrid Fiber Coaxial plant, used as the underlying transport CMTS: Cable Modem Termination System (can be a Layer-2 bridging or Layer-3 routing CMTS) GWR: Residential Gateway Router (provides Layer-3 services to hosts) Host: PC, notebook etc. which is connected to the CM or GWR CM: Cable Modem ER: Edge Router Data Over Cable Service Interface Specification (DOCSIS): The standards defining how data should be carried over cable networks. Figure 5.1 illustrates the key elements of a Cable Network <--- ACCESS ---><------ HFC ------><----- Aggregation / Core -----> +-----+ +------+ |Host |--| GWR | +-----+ +--+---+ | _ _ _ _ _ _ +------+ | | | CM |---| | +------+ | | | HFC | +------+ +--------+ | | | | | Edge | +-----+ +------+ | Network |---| CMTS |---| |===> ISP |Host |--| CM |---| | | | | Router | Network +-----+ +--+---+ | | +------+ +--------+ |_ _ _ _ _ _| +------+ | +-----+ | GWR | | |Host |--| / |---------+ +-----+ | CM | +------+ Figure 5.1 draft-asadullah-v6ops-bb-deployment-scenarios-00.txt [Page 8] INTERNET-DRAFT ISP IPv6 Deployment Scenarios in BB Networks July 2004 5.2 Deploying IPv6 in today's Cable networks There are two different deployment modes in today's cable networks: a bridged CMTS environment and a routed CMTS environment. IPv6 can be deployed in both of these environments. 1. Bridged CMTS Network In this scenario, both the CM and CMTS bridge all data traffic. Traffic to/from host devices is forwarded through the cable network to the ER. The ER then routes traffic through the ISP network to the Internet. The CM and CMTS support some Layer-3 functionality for management purposes. 2. Routed CMTS Network In a routed network, the CMTS forwards IP traffic to/from hosts based on Layer-3 information using the IP source/destination address. The CM acts as a Layer-2 bridge for forwarding data traffic and supports some Layer-3 functionality for management purposes. Some of the factors that hinder deployment of native IPv6 in today's cable networks include: - Problems with IPv6 Neighbor Discovery (ND) on CM and Bridged CMTS. These devices rely on IGMP join messages to track membership of hosts that are part of a particular IP Multicast group. In order to support ND the CM and bridges CMTS will need to support IGMPv3/MLDv2 snooping. - Classification of IPv6 traffic in the upstream and downstream direction. The CM and CMTS will need to support classification of IPv6 packets in order to give them the appropriate priority and QoS. Without proper classification all IPv6 traffic will need to be sent best effort (BE) which can cause problems when deploying services like VOIP and IP Multicast video. - Changes need to be made to the DOCSIS specification to include support for IPv6 on the CM and CMTS. This is imperative for deployment native IPv6 over cable networks. draft-asadullah-v6ops-bb-deployment-scenarios-00.txt [Page 9] INTERNET-DRAFT ISP IPv6 Deployment Scenarios in BB Networks July 2004 Due to the above mentioned limitations in today's cable networks, most cable operators are forced to use tunneling techniques in order to transport IPv6 traffic over their current IPv4 infrastructure. The following sections will cover these deployment scenarios in more detail. 5.2.1 Deploying IPv6 in a Bridged CMTS Network In IPv4 the CM and CMTS act as Layer-2 bridges and forward all data traffic to/from the hosts and the ER. The hosts use the ER as their Layer-3 next hop. If there is a GWR behind the CM it can acts as a next hop for all hosts and forward data traffic to/from the ER. When deploying IPv6 in this environment, the CM and CMTS will continue to be bridging devices in order to keep the transition smooth and reduce operational complexity. The CM and CMTS will need to bridge IPv6 unicast and multicast packets to/from the ER and the hosts. If there is a GWR connected to the CM, it will need to forward IPv6 unicast and multicast traffic to/from the ER. Figure 5.2.1 illustrate the IPv6 deployment scenario +-----+ +-----+ |Host |--| GWR | +-----+ +--+--+ | _ _ _ _ _ _ | +------+ | | +--| CM |---| | +------+ | | | HFC | +------+ +--------+ | | | | | Edge | +-----+ +------+ | Network |---| CMTS |---| |===> ISP |Host |--| CM |---| | | | | Router | Network +-----+ +------+ | | +------+ +--------+ |_ _ _ _ _ _| <-------------><---------------------------------><---------------> L3 Routed L2 Bridged L3 Routed Figure 5.2.1 draft-asadullah-v6ops-bb-deployment-scenarios-00.txt [Page 10] INTERNET-DRAFT ISP IPv6 Deployment Scenarios in BB Networks July 2004 5.2.1.1 IPv6 Related Infrastructure Changes In this scenario the CM and the CMTS bridge all data traffic so they will need to support bridging of native IPv6 unicast and multicast traffic. The following devices have to be upgraded to dual stack: Host, GWR and ER. 5.2.1.2 Addressing The proposed architecture for IPv6 deployment includes two components that must be provisioned: the CM and the host. Additionally if there is a GWR connected to the CM, it will also need to be provisioned. The host or the GWR use the ER as their Layer-3 next hop. 5.2.1.2.1 IP Addressing for CM The CM will be provisioned in the same way as in today's cable networks, using an IPv4 address on the cable interface connected to the MSO network for management functions. During the initialization phase, it will obtain its IPv4 address using DHCPv4, and download a DOCSIS configuration file identified by the DHCPv4 server. 5.2.1.2.2 IP Addressing for Hosts If there is no GWR connected to the CM, all the hosts behind the CM will belong to the same /64 subnet that is assigned using stateless auto-configuration or DHCPv6. If using stateless auto-configuration, the host listens for routing advertisements (RA) from the ER. The RAs contain the /64 prefix assigned to the host. Upon receipt of an RA, the host constructs its IPv6 address by combining the prefix in the RA (/64) and a unique identifier (e.g., its modified EUI-64 format interface ID). If DHCPv6 is used to obtain an IPv6 address, it will work in much the same way as DHCPv4 works today. The DHCPv6 messages exchanged between the host and the DHCPv6 server are bridged by the CM and the CMTS. 5.2.1.2.3 IP Addressing for GWR The GWR can use stateless auto-configuration (RA) to obtain an address for its upstream interface, the link between itself and the ER. This step is followed by a request via DHCP-PD for a prefix shorter than /64, typically /48, which in turn is divided into /64s and assigned to its downstream interfaces connecting to the hosts. draft-asadullah-v6ops-bb-deployment-scenarios-00.txt [Page 11] INTERNET-DRAFT ISP IPv6 Deployment Scenarios in BB Networks July 2004 5.2.1.3 Data Forwarding The CM and CMTS must be able to bridge native IPv6 unicast and multicast traffic. The CMTS must provide IP connectivity between hosts attached to CMs and must do so in a way that meets the expectation of Ethernet attached customer equipment. In order to do that, the CMTS must either forward Neighbor Discovery (ND) packets or provide a proxy ND service. As with the CM, a bridged CMTS that selectively forwards multicast datagrams on the basis of IGMPv2 will potentially break IPv6 ND. Communication between hosts behind different CMs is always forwarded by the CMTS. IPv6 communication between the different sites relies on multicast IPv6 Neighbor Discovery [RFC2461] frames being forwarded correctly by the CM and the CMTS. In order to support IPv6 multicast applications across DOCSIS cable networks, the CM and bridging CMTS need to support IGMPv3/MLDv2 snooping. MLD is identical to IGMP in IPv4, only the name and numbers are changed. MLDv2 is identical to IGMPv3 and also supports ASM (Any Source Multicast) and SSM (Single Source Multicast) service models. Implementation work on CM/CMTS should be minimal because the only significant difference between IPv4 IGMPv3 and IPv6 MLDv2 are the longer addresses in the protocol. 5.2.1.4 Routing The hosts install a default route that points to the ER or the GWR. No routing protocols are needed on these devices which do have limited resources. If there is a GWR present it will also use static default route to the ER. The ER runs an IGP such as OSPFv3 or IS-IS. The connected prefixes have to be redistributed. If DHCP-PD is used, with every delegated prefix a static route is installed by the ER. For this reason the static routes must also be redistributed. Prefix summarization should be done at the ER. Depending on the design of the edge portion of the ISP network, some Edge Routers might have to run iBGP for IPv6. In this case it is expected that two peer sessions are established between the ER and a pair of redundant Route Reflectors. 5.2.2 Deploying IPv6 in a Routed CMTS Network In an IPv4 routed CMTS network the CM still acts as a Layer-2 device and bridges all data traffic between its Ethernet interface and cable interface draft-asadullah-v6ops-bb-deployment-scenarios-00.txt [Page 12] INTERNET-DRAFT ISP IPv6 Deployment Scenarios in BB Networks July 2004 connected to the cable operator's network. The CMTS acts as a Layer-3 router and may also include the ER functionality. The hosts and the GWR use the CMTS as their Layer-3 next hop. When deploying IPv6 in a routed CMTS network, the CM will still acts as a Layer-2 device and will need to bridge IPv6 unicast as well as multicast traffic. The CMTS/ER will need to either tunnel IPv6 traffic or natively support IPv6. The host and GWR will use the CMTS/ER as their Layer-3 next hop. There could be five possible deployment scenarios for IPv6 in a routed CMTS network: 1. IPv4 Cable (HFC) Network In this scenario the cable network, including the CM and CMTS remain IPv4 devices. The host and ER are upgraded to dual-stack. This is the easiest way for a Cable Operator to provide IPv6 service as no changes are made to the cable network. 2. IPv4 Cable (HFC) Network, GWR at customer site In this case the cable network, including the CM and CMTS remain IPv4 devices. The host, GWR and ER are upgraded to dual-stack. This scenario is also easy to deploy since the cable operator just needs to add GWR at the customer's site. 3. Dual-stacked Cable (HFC) Network, CM and CMTS support IPv6 In this scenario the CMTS isupgraded to dual-stack to support IPv4 and IPv6. Since the CMTS supports IPv6 it can acts as an ER as well. The CM will act as a Layer-2 bridge but will need to bridge IPv6 unicast and multicast traffic. This scenario is not easy to deploy since it requires changes to the DOCSIS specification. The CM and CMTS may require HW and SW upgrades to support IPv6. 4. Dual-stacked Cable (HFC) Network, Standalone GWR and CMTS support IPv6 In this scenario there is a standalone GWR connected to the CM. Since the IPv6 functionality exists on the GWR the CM does not need to be dual-stack. The CMTS is upgraded to dual-stack and it can incorporate the ER functionality. This scenario may also require HW and SW changes on the GWR and CMTS. 5. Dual-stacked Cable (HFC) Network, Embeded GWR/CM and CMTS support IPv6 In this scenario the CM and GWR functionality exists on a single device which needs to be upgraded to dual-stack. The CMTS will also to be upgraded to a dual-stack device. This scenario is also difficult to deploy in today's cable network since it requires changes on the Embeded GWR/CM and the CMTS. draft-asadullah-v6ops-bb-deployment-scenarios-00.txt [Page 13] INTERNET-DRAFT ISP IPv6 Deployment Scenarios in BB Networks July 2004 The DOCSIS specification will also need to be modified to allow native IPv6 support on the Embeded GWR/CM. 5.2.2.1 IPv4 Cable Network, Host and ER upgraded to Dual-Stack This is one of the most cost effective ways for a Cable Operator to offer IPv6 services to its customers. Since the cable network remains IPv4 there is relatively minimal cost involved in turning up IPv6 service. All IPv6 traffic is exchanged between the hosts and the ER. Figure 5.2.2.1 illustrates this deployment scenario +-----------+ +------+ +--------+ +-----+ +-------+ | Cable | | | | Edge | |Host |--| CM |----| (HFC) |----| CMTS |----| |=>ISP +-----+ +-------+ | Network | | | | Router | Network +-----------+ +------+ +--------+ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ ()_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _() 6to4 tunnel <---------><----------------------------------------><------------> IPv4/v6 IPv4 only IPv4/v6 Figure 5.2.2.1 5.2.2.1.1 IPv6 Related Infrastructure Changes In this scenario the CM and the CMTS will only need to support IPv4 so no changes need to be made to them or the cable network. The following devices have to be upgraded to dual stack: Host and ER. 5.2.2.1.2 Addressing The only device that needs to be assigned an IPv6 address at customer site is the host. Address assignment can be done statically as there is no mechanism to transport ND messages or DHCPv6 messages over the IPv4 cable network. The host still receives a global IPv4 address using DHCPv4, which works the same way in today's cable networks. In order to get IPv6 connectivity, host devices will also need an IPv6 address and a means to communicate with the ER. draft-asadullah-v6ops-bb-deployment-scenarios-00.txt [Page 14] INTERNET-DRAFT ISP IPv6 Deployment Scenarios in BB Networks July 2004 5.2.2.1.3 Data Forwarding All IPv6 traffic will be sent to/from the ER and the host device. In order to transport IPv6 packets over the cable operator's IPv4 network, the host and the ER will need to use tunneling mechanisms such as 6to4 tunneling [RFC 3056]. The host will use its global IPv4 address to source the tunnel to the ER. All IPv6 traffic will be forwarded to the ER, encapsulated in IPv4 packets. The intermediate IPv4 nodes will forward this traffic as regular IPv4 packets. The ER will need to support 6to4 relay functionality in order to provide IPV6 Internet connectivity to the host. 5.2.2.1.4 Routing A static 2002::/16 route and a default IPv6 route can be manually configured on the host with the IPv6 address of the ER as the next hop. The ER runs an IGP such as OSPFv3 or ISIS. Additionally some ERs may also run iBGP for IPv6 depending on the design of the edge portion of the ISP network. 5.2.2.2 IPv4 Cable Network, Host, GWR and ER upgraded to Dual-Stack The cable operator can provide IPv6 services to its customers, in this scenario, by adding a GWR behind the CM. Since the GWR will facilitate all IPv6 traffic to/from the host and the ER, the cable network including the CM and CMTS do not need to support IPv6 and can remain IPv4 devices. Figure 5.2.2.2 illustrates this deployment scenario +-----+ |Host | +--+--+ | +-----------+ +------+ +--------+ +---+---+ +-------+ | Cable | | | | Edge | | GWR |--| CM |----| (HFC) |----| CMTS |----| |=>ISP +-------+ +-------+ | Network | | | | Router | Network +-----------+ +------+ +--------+ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ ()_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _() Manual or 6to4 tunnel <---------><---------------------------------------><-------------> IPv4/v6 IPv4 only IPv4/v6 Figure 5.2.2.2 draft-asadullah-v6ops-bb-deployment-scenarios-00.txt [Page 15] INTERNET-DRAFT ISP IPv6 Deployment Scenarios in BB Networks July 2004 5.2.2.2.1 IPv6 related Infrastructure changes In this scenario the CM and the CMTS will only need to support IPv4 so no changes need to be made to them or the cable network. The following devices have to be upgraded to dual stack: Host, GWR and ER. 5.2.2.2.2 Addressing The only devices that needs to be assigned an IPv6 address at customer site are the host and GWR. IPv6 address assignment can be done statically at the GWR's downstream interface. The GWR will send out RA messges on its downstream interface which will be used by the hosts to auto-configure themselves with an IPv6 address. The GWR can also configure its upstream interface using RA messages from the ER and use DHCP-PD for requesting a /48 prefix from the ER. This /48 prefix will be used to configure /64s on hosts connected to the GWR's downstream interfaces. The GWR still receives a global IPv4 address on its upstream interface using DHCPv4, which works the same way in today's cable networks. In order to get IPv6 connectivity to the Internet the GWR will need to communicate with the ER. 5.2.2.2.3 Data Forwarding All IPv6 traffic will be sent to/from the ER and the GWR, which will forward IPv6 traffic to/from the host. In order to transport IPv6 packets over the cable operator's IPv4 network, the GWR and the ER will need to use tunneling mechanisms such as 6to4 tunneling [RFC 3056] or manual tunneling [RFC 2893]. All IPv6 traffic will need to go through the tunnel, once it comes up. The GWR will use its global IPv4 address to source the tunnel to the ER. The tunnel endpoint will be the ER's IPv4 global address. All IPv6 traffic will be forwarded to the ER, encapsulated in IPv4 packets. The intermediate IPv4 nodes will forward this traffic as regular IPv4 packets. In case of 6to4 tunneling, the ER will need to support 6to4 relay functionality in order to provide IPV6 Internet connectivity to the GWR and hence the hosts connected to the GWR. 5.2.2.2.4 Routing For 6to4 tunneling,a static 2002::/16 route and a default IPv6 route can be manually configured on the GWR with the IPv6 address of the ER as the next hop. A similar IPv6 route will need to be configured on the ER pointing back to the GWR at customer site. If using maunual tunneling, the GWR and ER can use static routing or they can also configure RIP-ng. The RIP-ng updates can be transported over a manual tunnel, which does not work when using 6to4 tunneling. draft-asadullah-v6ops-bb-deployment-scenarios-00.txt [Page 16] INTERNET-DRAFT ISP IPv6 Deployment Scenarios in BB Networks July 2004 Customer routes can be carried to the ER using RIP-ng updates. The ER can advertise these routes in its IGP. Prefix summarization should be done at the ER. If DHCP-PD is used for address assignment a static route is automatically installed on the CMTS/ER for each delegated /48 prefix. The static routes need to be redistributed into the IGP at the CMTS/ER so there is no need for a routing protocol between the CMTS/ER and the GWR. The ER runs an IGP such as OSPFv3 or ISIS. Additionally some ERs may also run iBGP for IPv6 depending on the design of the edge portion of the ISP network. 5.2.2.3 Dual-stacked Cable (HFC) Network, CM and CMTS support IPv6 In this scenario the Cable Operator can offer native IPv6 services to its customers since the cable network including the CMTS supports IPv6. The ER functionality can be included in the CMTS or it can exist on a separate router connected to the CMTS's upstream interface. The CM will need to bridge IPv6 unicast and multicast traffic. Figure 5.2.2.3 illustrates this deployment scenario +-----------+ +-------------+ +-----+ +-------+ | Cable | | CMTS / Edge | |Host |--| CM |----| (HFC) |----| |=>ISP +-----+ +-------+ | Network | | Router | Network +-----------+ +-------------+ <-------><----------------------------><----------------> IPv4/v6 IPv4/v6 IPv4/v6 Figure 5.2.2.3 5.2.2.3.1 IPv6 Related Infrastructure Changes Since the CM still acts as a Layer-2 bridge, it does not need to be dual-stack. The CM will need to support bridging of IPv6 unicast and multicast traffic and IGMPv3/MLDv2 snooping which requires changes in the DOCSIS specification. In this scenario the following devices have to be upgraded to dual stack: Host and CMTS/ER. 5.2.2.3.2 Addressing In today's cable networks the CM receives a private IPv4 address using DHCPv4 for management purposes. In an IPv6 environment, the CM will continue to use an IPv4 address for management purposes. draft-asadullah-v6ops-bb-deployment-scenarios-00.txt [Page 17] INTERNET-DRAFT ISP IPv6 Deployment Scenarios in BB Networks July 2004 The cable operator can also choose to assign an IPv6 address to the CM for management, but the CM will have to be upgraded to support this functionality. IPv6 address assignment for the CM and host can be done via DHCP or IPv6 ND messages. If the CM uses an IPv4 address for management, it will use DHCPv4 for it's address assignment and the CMTS will need to act as a DHCPv4 relay agent. If the CM uses an IPv6 address for management, it can use DHCPv6 with the CMTS acting as a DHCPv6 relay agent or the CMTS can be statically configured with a /64 prefix and it can send out RA messages out the cable interface. The CMs connected to the cable interface can use the RA messages to auto- configure themselves with an IPv6 address. All CMs connected to the cable interface will be in the same subnet. The hosts can receive their IPv6 address via DHCPv6 with the CMTS acting as a DHCPv6 relay agent. If address assignment on hosts is done via IPv6 ND, the CMTS will be configured with multiple /64 prefixes and send out RA messages to the hosts. If the CMTS is not also acting as an ER, the RA messages will come from the ER connected to the CMTS upstream interface. The CMTS will need to forward the RA messages downstream or act as an ND proxy. 5.2.2.3.3 Data Forwarding All IPv6 traffic will be sent to/from the CMTS and hosts. Data forwarding will work the same way it works in today's cable networks. The CMTS will forward IPv6 traffic to/from hosts based on the IP source/destination address. 5.2.2.3.4 Routing No routing protocols are needed between the CMTS and the host since the CM and host are directly connected to the CMTS's cable interface. Since the CMTS supports IPv6, hosts will use the CMTS as their Layer-3 next hop. If the CMTS is also acting as an ER, it runs an IGP such as OSPFv3 or ISIS. Additionally, it may also run iBGP for IPv6 depending on the design of the edge portion of the ISP network. 5.2.2.4 Dual-stacked Cable (HFC) Network, Standalone GWR and support IPv6 In this case the cable operator can offer IPv6 services to it's customers by adding a GWR between the CM and the host. The GWR will facilitate IPv6 communication between the host and the CMTS/ER. The CMTS will be upgraded to dual-stack to support IPv6 and can acts as an ER as well. The CM will act as a bridge for forwarding data traffic and and does not need to support IPv6. draft-asadullah-v6ops-bb-deployment-scenarios-00.txt [Page 18] INTERNET-DRAFT ISP IPv6 Deployment Scenarios in BB Networks July 2004 This scenario is very similar to the case described in section 5.2.2.2. The only difference in this case is the ER functionality exists on the CMTS instead of a separate router in the cable operator's network. Figure 5.2.2.2 illustrates this deployment scenario +-----------+ +------------+ +------+ +-------+ +-------+ | Cable | |CMTS / Edge | | Host |---| GWR |--| CM |----| (HFC) |----| |=>ISP +------+ +-------+ +-------+ | Network | | Router | Network +-----------+ +------------+ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ ()_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _() Manual or 6to4 tunnel <-----------------><--------------------------------><--------------> IPv4/v6 IPv4 IPv4/v6 Figure 5.2.2.4 5.2.2.4.1 IPv6 Related Infrastructure Changes Since the CM still acts as a Layer-2 bridge, it does not need to be dual-stack nor does it need to support IPv6. In this scenario the following devices have to be upgraded to dual stack: Host, GWR and CMTS/ER. 5.2.2.4.2 Addressing The CM will still receive a private IPv4 address using DHCPv4 which works the same way in today's cable networks. The CMTS will act as DHCPv4 relay agent. The address assignment for the host and GWR happens in a similar manner as described in section 5.2.2.2.2. 5.2.2.4.3 Data Forwarding Data forwarding between the host and CMTS/ER is facilitated by the GWR and happens in a similar manner as described in section 5.2.2.2.3. 5.2.2.4.4 Routing In this case routing is very similar to the case described in section 5.2.2.2.4. Since the CMTS now incorporates the ER functionality, it will need to run an IGP such as OSPFv3 or ISIS. draft-asadullah-v6ops-bb-deployment-scenarios-00.txt [Page 19] INTERNET-DRAFT ISP IPv6 Deployment Scenarios in BB Networks July 2004 5.2.2.5 Dual-stacked Cable (HFC) Network, Embeded GWR/CM and CMTS support IPv6 In this scenario the Cable Operator can can offer native IPv6 services to its customers since the cable network including the CM/Embeded GWR and CMTS support IPv6. The ER functionality can be included in the CMTS or it can exist on a separate router connected to the CMTS's upstream interface. The CM/Embeded GWR acts as a Layer-3 device. Figure 5.2.2.5 illustrates this deployment scenario +-----------+ +-------------+ +-----+ +-----------+ | Cable | | CMTS / Edge | |Host |---| CM / GWR |----| (HFC) |----| |=> ISP +-----+ +-----------+ | Network | | Router | Network +-----------+ +-------------+ <----------------------------------------------------------> IPv4/v6 Figure 5.2.2.5 5.2.2.5.1 IPv6 Related Infrastructure Changes Since the CM/GWR acts as a Layer-3 device IPv6 can be deployed end-to-end. In this scenario the following devices have to upgraded to dual-stack: Host, CM/GWR and CMTS/ER. 5.2.2.5.2 Addressing Since the CM/GWR is dual-stack, it can receive an IPv4 or IPv6 address using DHCP for management purposes. As the GWR functionality is embeded in the CM, it will need an IPv6 address for forwarding data traffic. IPv6 address assignment for the CM/GWR and host can be done via DHCPv6 or DHCP-PD. If using DHCPv6 the CMTS will need to act as DHCPv6 relay agent. The host and CM/GWR will receive IPv6 addresses from different /64 prefixes configured on the DHCP server. The CMTS will need to glean pertinent information from the DHCP Offer messages, sent from the DHCP server to the DHCP clients (host and CM/GWR), much like it does today in DHCPv4. All CM/GWR connected to the same cable interface on the CMTS belong to same /64 prefix. The hosts connected to the same cable interface on the CMTS maybelong to different /64 prefixes as the CMTS will have multiple /64 prefixes configured under it's cable interfaces. It is also possible to use DHCP-PD for IPv6 address assignment. In this case the CM/GWR will use stateless auto-configuration to assign an IPv6 address to it's upstream interface using the /64 prefix draft-asadullah-v6ops-bb-deployment-scenarios-00.txt [Page 20] INTERNET-DRAFT ISP IPv6 Deployment Scenarios in BB Networks July 2004 sent by the CMTS/ER in RA message. Once the CM/GWR assigns an IPv6 address to it's upstream interface it will request a /48 prefix from the CMTS/ER and chop this /48 prefix into /64s for assigning IPv6 addresses to hosts. The CMTS will need to keep track of the /48 prefixes assigned to different CM/GWRs. 5.2.2.5.3 Data Forwarding The host will use the CM/GWR as the Layer-3 next hop. The CM/GWR will forward all IPv6 traffic to/from the CMTS/ER and hosts. The CMTS/ER will forward IPv6 traffic to/from hosts based on the IP source/destination address. 5.2.2.5.4 Routing The CM/GWR can use a static defaul route pointing to the CMTS/ER or it can run a routing procotol such as RIP-ng or OSPFv3 between itself and the CMTS. Customer routes from behind the CM/GWR can be carried to the CMTS using routing updates. If DHCP-PD is used for address assignment a static route is automatically installed on the CMTS/ER for each delegated /48 prefix. The static routes need to be redistributed into the IGP at the CMTS/ER so there is no need for a routing protocol between the CMTS/ER and the GWR. If the CMTS is also acting as an ER, it runs an IGP such as OSPFv3 or ISIS. Additionally, it may also run iBGP for IPv6 depending on the design of the edge portion of the ISP network. 5.3 IPv6 Multicast In order to support IPv6 multicast applications across DOCSIS cable networks, the CM and bridging CMTS will need to support IGMPv3/MLDv2 snooping. MLD is identical to IGMP in IPv4, only the name and numbers are changed. MLDv2 is identical to IGMPv3 and also supports ASM (Any Source Multicast) and SSM (Single Source Multicast) service models. ASM and SSM in IPv6 operate almost the same as in IPv4. SSM has almost the same benefits as in IPv4. In IPv6, with [RFC3306] there is a better mechanism available for ASM IPv6 address allocation than in IPv4. This reduces the problems of using ASM in IPv6 to some degree. On the other hand, the protocol MSDP standard with PIM-SM is not currently defined for IPv6. In general, SSM for IPv6 is also considered to be the protocol to promote for the majority of future interdomain IP multicast applications and it is less complex solution to operate. The "SSM safe reporting" problem for IPv4 does not exist in IPv6 multicast because the use of SSM in IPv6 draft-asadullah-v6ops-bb-deployment-scenarios-00.txt [Page 21] INTERNET-DRAFT ISP IPv6 Deployment Scenarios in BB Networks July 2004 is well defined and uncontentious address ranges. The CM, GWR and CMTS/ER will need to be enabled with PIM-SSM, which requires the definition and support for IGMPv3/MLDv2 snooping, in order to track join/leave messages from the hosts. 5.4 IPv6 QoS IPv6 will not change or add any queuing/scheduling functionality already existing in DOCSIS specifications. But the QoS mechanisms on the CMTS and CM would need to be IPv6 capable. This includes support for IPv6 classifiers, so that data traffic to/from host devices can be classified appropriately into different service flows and be assigned appropriate priority. Appropriate classification criteria would need to be implemented for unicast and multicast traffic. In order to classify IPv6 traffic the following classifiers would need to be modified in the DOCSIS specification to support the 128-bit IPv6 address: - IP source address - IP source mask - IP destination address - IP destination mask - IP traffic class (DSCP) The following classifiers would be new for IPv6: - IP version - Flow label (optional) Traffic classification and marking should be done at the CM for upstream traffic and the CMTS/ER for downstream traffic in order to support the various types of services: data, voice, video. The same IPv4 QoS concepts and methodologies should be applied for IPv6 as well. 5.5 IPv6 Security Considerations Security in a DOCSIS cable network is provided using Baseline Privacy Plus (BPI+). The only part that is dependent on IP addresses is encrypted multicast. Semantically, multicast encryption would work the same way in an IPv6 environment as in the IPv4 network. However, appropriate enhancements will be needed in the DOCSIS specification to support encrypted IPv6 multicast. The other aspect of security enhancement is mandated IPSec support in IPv6. The IPv6 specifications mandate implementation of IPSec, but they don't mandate its use. The IPv4 specifications do not mandate IPSec. IPSec is the same for both IPv4 and IPv6, but it still requires a key distribution mechanism. draft-asadullah-v6ops-bb-deployment-scenarios-00.txt [Page 22] INTERNET-DRAFT ISP IPv6 Deployment Scenarios in BB Networks July 2004 Cable operators may consider deploying it end-to-end on IPv6 as there isn't an intermediate device(i.e. NAT). There are limited changes that have to be done for hosts in order to enhance security. The Privacy extenssions for autoconfiguration should be used by the hosts. IPv6 firwall functions could be enabled, if available on the host or GWR. The ISP provides security against attacks that come form its own subscribers but it could also implement security services that protect its subscribers from attacks sourced from the outside of its network. Such services do not apply at the access level of the network discussed here. The CMTS/ER should protect the ISP network and the other subscribers against attacks by one of its own customers. For this reason uRPF and ACLs should be used on all interfaces facing subscribers. Filtering should be implemented with regard for the operational requirements of IPv6 (ICMPv6 types). The CMTS/ER should protect its processing resources against floods of valid customer controll traffic such as: Router and Neighbor Solicitations, MLD Requests. All other security features used with the IPv4 service should be similarly applied to IPv6 as well. 5.6 IPv6 Network Management All current DOCSIS, PacketCable, and CableHome MIBs are already designed to support IPv6 objects. In this case, IPv6 will neither add, nor change any of the functionality of these MIBs. An object to identify the IP version, InetAddressType has been added to all the appropriate SNMP objects related to IP address. 6. Broadband DSL Networks This section describes the IPv6 deployment options in today's High Speed DSL Networks. 6.1 DSL Network Elements Digital Subscriber Line (DSL) broadband services provide users with IP connectivity over the existing twisted-pair telephone lines called the local-loop. A wide range of bandwidth offerings are available depending on the quality of the line and the distance between the Customer Premises Equipment and the DSLAM. draft-asadullah-v6ops-bb-deployment-scenarios-00.txt [Page 23] INTERNET-DRAFT ISP IPv6 Deployment Scenarios in BB Networks July 2004 The following network elements are typical of a DSL network [ISP Transition Scenarios]: - DSL Modem, it can be a stand alone device, it can be incorporated in the host, and it can incoporate router functionalities. - Customer Premises Router, it is used to provide layer 3 services for customer premises networks. It is usually use to provide firewalling functions and segment broadcast domains for a Small business. - DSL Access Multiplexer (DSLAM), it terminates multipel twisted pair telephone lines and provides aggregation to BRAS. - Broadband Remote Access Server (BRAS), it aggregates or terminates multiple PVC coresponding to the subscriber DSL circuits. - Edge Router (ER), it provides the Layer 3 interface to the ISP network. Figure 6.1 depicts all the network elements mentioned. Customer Premises | Network Access Provider | Network Service Provider CP NAP NSP +-----+ +------+ +------+ +--------+ |Hosts|--|Router| +--+ BRAS +---+ Edge | ISP +-----+ +--+---+ | | | | Router +===> Network | | +------+ +--------+ +--+---+ | | DSL +--+ | |Modem | | | +------+ | +-----+ | +--+ | | +------+ |DSLAM+--+ +-----+ | DSL | +--+ | |Hosts|--+Modem +--+ +-----+ +-----+ +--+---+ Figure 6.1 6.2 Deploying IPv6 in today's IPv4 DSL networks There are two main design approaches to providing IPv4 connectivity over a DSL infrastructure: 1. Point-to-point model: Each subscriber connects to the DSLAM over a twisted pair and is provided with a unique PVC that links it to the service provider. The PVCs can be terminated at the BRAS or at the Edge Router. This type of design is not very scalable if the PVCs are draft-asadullah-v6ops-bb-deployment-scenarios-00.txt [Page 24] INTERNET-DRAFT ISP IPv6 Deployment Scenarios in BB Networks July 2004 not terminated as close as possible to the DSLAM (at the BRAS). In this case a large number of layer two circuits has to be mantained over a significant portion of the network. This model is presented in section 6.2.6. 2. PPP Terminated Aggregation (PTA) model: PPP sessions are opened between each subscriber and the BRAS. The BRAS terminates the PPP sessions and provides Layer 3 connectivity between the subscriber and the ISP. This model is presented in section 6.2.2. 3. L2TP Access Aggregation (LAA) model: PPP sessions are opened between each subscriber and the ISP Edge Router. The BRAS tunnels the subscriber PPP sessions to the ISP by encapsulating them into L2TP tunnels. This model is presented in section 6.2.3. In aggregation models the BRAS terminates the subscriber PVCs and aggregates their connections before providing access to the ISP. In order to maintain the deployment concepts and business models proven and used with existent revenue generating IPv4 services, the IPv6 deployment will match the IPv4 one. This approach is presented in sections 6.2.1-3 that describe today's IPv4 over DSL broadbacnd access deployments. Under certain circumstances where new service types or service needs justify it, IPv4 and IPv6 network logical architectures could be different as described in secton 6.2.4. 6.2.1 POINT-TO-POINT MODEL In this scenario the Ethernet frames from the Host or the Customer Premises Router are bridged over the PVC assigned to the subscriber [ISP Transition Scenarios]. Figure 6.2.1 describes the protocol architecture of this model. Customer Premises NAP NSP <-------------------------> <---------------> <--------------------> +-----+ +-------+ +-----+ +--------+ +----------+ |Hosts|--+Router +--+ DSL +--+ DSLAM +--------+ Edge | ISP +-----+ +-------+ |Modem| +--------+ | Router +==> Network +-----+ +----------+ <----------------------------> ATM Figure 6.2.1 draft-asadullah-v6ops-bb-deployment-scenarios-00.txt [Page 25] INTERNET-DRAFT ISP IPv6 Deployment Scenarios in BB Networks July 2004 6.2.1.1 IPv6 Related Infrastructure Changes In this scenario the DSL modem and the entire NAP is layer-3 unaware so no changes are needed to support IPv6. The following devices have to be upgraded to dual stack: Host, Customer Router and Edge Router. 6.2.1.2 Addressing The Hosts or the Customer Routers have the Edge Router as their Layer 3 next hop. If there is no Customer Router all the hosts on the subscriber site belong to the same /64 subnet that is statically configured on the Edge Router for that subsrciber's PVC. The hosts can use stateless or statefull autoconfiguration to aquire an address via the Edge Router. If a Customer Router is present: - it is statically configured with an address on the /64 subnet between itself and the Edge Router, and with /64 prefixes on the interfaces connecting the hosts on the customer site. This is not a desired provisioning method being expensive and difficult to manage. - it dynamically acquires through autoconfiguration the address for the link between itself and the Edge Router. This step is followed by a DHCP-PD [RFC 3633] request for a prefix shorter then /64 that in turn is divided in /64s and assigned to its interfaces connecting the hosts on the customer site. The Edge Router has a /64 prefix configured for each subscriber VLAN. Each VLAN should be enabled to relay DHCPv6 requests from the subscribers to DHCPv6 servers in the ISP network. The VLANs providing access for subscribers that use DHCP-PD as well, have to be enabled to support the feature. The uplink to the ISP network is configured with a /64 prefix as well. The prefixes used for subscriber links and the ones delegated via DHCP-PD should be planned in a maner that allows as much summarization as possible at the Edge Router. Other information of interest to the host, such as DNS, is provided through stateful DHCPv6 [RFC 3315] and stateless DHCPv6 [RFC 3736]. 6.2.1.3 Routing The CPE devices are configured with a default route that points to the Edge router. No routing protocols are needed on these devices which do have limited resources. draft-asadullah-v6ops-bb-deployment-scenarios-00.txt [Page 26] INTERNET-DRAFT ISP IPv6 Deployment Scenarios in BB Networks July 2004 The Edge Router runs the IPv6 IGP used in the NSP: OSPFv3 or IS-IS. The connected prefixes have to be redistributed. If DHCP-PD is used, with every delegated prefix a static route is installed by the Edge Router. For this reason the static routes must also be redistributed. Prefix summarization should be done at the Edge Router. Depending on the design of the edge portion of the ISP network, some Edge Routers might have to run iBGP for IPv6. In this case it is expected that two peer sessions are established between the Edge Router and a pair of redundant Route Reflectors. 6.2.2 PPP TERMINATED AGGREGATION (PTA) MODEL The PTA architecture relies on PPP-based protocols (PPPoA [RFC 2364] and PPPoE [RFC 2516]). The PPP sessions are initiated by Customer Premise Equipment and it is terminated at the BRAS. The BRAS authorizes the session, authenticates the subscriber, and provides an IP address on behalf of the ISP. The BRAS then does Layer-3 routing of the subscriber traffic to the NSP Edge Router. This model is often used when the NSP is also the NAP [ISP Transition Scenarios]. There are two types of PPP encapsulations that can be leveraged with this model: A. Connection using PPPoA Customer Premises NAP NSP <--------------------> <----------------------> <-----------------> +-----------+ | AAA | +-------+ Radius | | | TACACS | | +-----------+ | +-----+ +-------+ +--------+ +----+-----+ +-----------+ |Hosts|--+Router +------+ DSLAM +-+ BRAS +-+ Edge | +-----+ +-------+ +--------+ +----------+ | Router +=>Core +-----------+ <--------------------------> PPP Figure 6.2.2.1 draft-asadullah-v6ops-bb-deployment-scenarios-00.txt [Page 27] INTERNET-DRAFT ISP IPv6 Deployment Scenarios in BB Networks July 2004 The PPP sessions are initiated by the Customer Premise Equipment. The BRAS authenticates the subscriber against a local or a remote database. Once the session is established, the BRAS provides an address and maybe a DNS server to the user, information aquired from the subscriber profile or from a DHCP server. This solution scales better then the Point-to-Point but since there is only one PPP session per ATM PVC the subscriber can choose a single ISP service at a time. B. Connection using PPPoE Customer Premises NAP NSP <----------------------------> <-------------------> <-----------------> +-----------+ | AAA | +-------+ Radius | | | TACACS | | +-----------+ | +-----+ +-------+ +--------+ +--------+ +----+-----+ +-----------+ |Hosts|--+Router +-+ Modem +-+ DSLAM +-+ BRAS +-+ Edge | C +-----+ +-------+ +--------+ +--------+ +----------+ | Router +=>O | | R +-----------+ E <--------------------------------> PPP Figure 6.2.2.2 The operation of PPPoE is similar to PPPoA with the exception that with PPPoE multiple session can be supported over the same PVC thus allowing the subscriber to connect to multiple services at the same time. The hosts can initiate the PPPoE sessions as well. It is important to remember that the PPPoE encapsulation reduces the IP MTU available for the customer traffic. The network design and operation of the PTA model is the same regardless of the PPP encapsulation type used. draft-asadullah-v6ops-bb-deployment-scenarios-00.txt [Page 28] INTERNET-DRAFT ISP IPv6 Deployment Scenarios in BB Networks July 2004 6.2.2.1 IPv6 Related Infrastructure Changes In this scenario the BRAS is layer-3 aware and it has to be upgraded to support IPv6. Since the BRAS terminates the PPP sessions it has to support the implementation of these PPP protocols with IPv6. The following devices have to be upgraded to dual stack: Host, Customer Router, BRAS and Edge Router. 6.2.2.2 Addressing The BRAS terminates the PPP sessions and provides the subscriber with an IPv6 address from the defined pool for that profile. The subscriber profile for authorization and authentication can be located on the BRAS or on a AAA server. The Hosts or the Customer Routers have the BRAS as their Layer 3 next hop. The PPP session can be initiated by a host or by a Customer Router. In the later case, once the session is established with the BRAS and an address is negotiated for the uplink to the BRAS, DHCP-PD can be used to aquire prefixes for the Customer Router interfaces. The BRAS has to be enabled to support DHCP-PD and to relay the DHCPv6 requests of the hosts on the subscriber sites. The BRAS has a /64 prefixes configured on the link to the Edge router. The Edge router links are also configured with /64 prefixes to provide conectivity to the rest of the ISP network. The prefixes used for subscriber and the ones delegated via DHCP-PD should be planned in a maner that allows maximu summarization BRAS. Other information of interest to the host, such as DNS, is provided through stateful and stateless DHCPv6. 6.2.2.3 Routing The CPE devices are configured with a default route that points to the BRAS router. No routing protocols are needed on these devices which do have limited resources. The BRAS runs an IGP to the Edge Router: OSPFv3 or IS-IS. Since the addresses assigned to the PPP sessions are represented as connected host routes, connected prefixes have to be redistributed. If DHCP-PD is used, with every delegated prefix a static route is installed by the Edge Router. For this reason the static routes must also be redistributed. Prefix summarization should be done at the BRAS. The Edge Router is running the IGP used in the ISP network: OSPFv3 or IS-IS. draft-asadullah-v6ops-bb-deployment-scenarios-00.txt [Page 29] INTERNET-DRAFT ISP IPv6 Deployment Scenarios in BB Networks July 2004 A separation between the routing domains of the ISP and the Access Provider is recomended if they are managed independently. Controlled redistribution will be needed between the Access Provider IGP and the ISP IGP. Depending on the design of the edge portion of the ISP network, some Edge Routers might have to run iBGP for IPv6. In this case it is expected that two peer sessions are established between the Edge Router and a pair of redundant Route Reflectors. 6.2.3 L2TP ACCESS AGGREGATION (LAA) MODEL In the LAA model the BRAS forwards the CPE initiated session to the ISP over an L2TP tunnel established between the BRAS and the Edge Router. In this case the authentication, authorization and subscriber configuration are performed by the ISP itself [1]. A. Connection via PPPoA Customer Premises NAP NSP <--------------------> <----------------------> <-----------------> +-----------+ | AAA | +-------+ Radius | | | TACACS | | +-----+-----+ | | +-----+ +-------+ +--------+ +----+-----+ +-----+-----+ |Hosts|--+Router +------+ DSLAM +-+ BRAS +-+ Edge | +-----+ +-------+ +--------+ +----------+ | Router +=>Core +-----------+ <----------------------------------------> PPP <------------> L2TP Figure 6.2.3.1 draft-asadullah-v6ops-bb-deployment-scenarios-00.txt [Page 30] INTERNET-DRAFT ISP IPv6 Deployment Scenarios in BB Networks July 2004 B. Connection via PPPoE Customer Premises NAP NSP <---------------------------> <--------------------> <-----------------> +-----------+ | AAA | +------+ Radius | | | TACACS | | +-----+-----+ | | +-----+ +-------+ +--------+ +--------+ +----+-----+ +----+------+ |Hosts|--+Router +-+ Modem +-+ DSLAM +-+ BRAS +-+ Edge | C +-----+ +-------+ +--------+ +--------+ +----------+ | Router +=>O | | R +-----------+ E <-----------------------------------------------> PPP <--------------> L2TP Figure 6.2.3.2 The network design and operation of the PTA model is the same regardless of the PPP encapsulation type used. 6.2.3.1 IPv6 Related Infrastructure Changes In this scenario the BRAS is layer-3 aware and it has to be upgraded to support IPv6. The PPP sessions initiated by the subscriber are forwarded over the L2TP tunnel to the aggregation point in the ISP network. The BRAS must have the capability to support L2TP for IPv6. The following devices have to be upgraded to dual stack: Host, Customer Router, BRAS and Edge Router. 6.2.3.2 Addressing The Edge router terminates the PPP sessions and provides the subscriber with an IPv6 address from the defined pool for that profile. The subscriber profile for authorization and authentication can be located on the Edge Router or on a AAA server. The Hosts or the Customer Routers have the Edge Router as their Layer 3 next hop. The PPP session can be initiated by a host or by a Customer Router. In the later case, once the session is established with the Edge Router, DHCP-PD can be used to aquire prefixes for the Customer Router interfaces. The Edge Router has to be enabled to support DHCP-PD and to relay the DHCPv6 requests generated by the hosts on the subscriber sites. draft-asadullah-v6ops-bb-deployment-scenarios-00.txt [Page 31] INTERNET-DRAFT ISP IPv6 Deployment Scenarios in BB Networks July 2004 The BRAS has a /64 prefix configured on the link to the Edge router. The Edge router links are also configured with /64 prefixes to provide conectivity to the rest of the ISP network. Other information of interest to the host, such as DNS, is provided through stateful and stateless DHCPv6. 6.2.3.3 Routing The CPE devices are configured with a default route that points to the Edge router that terminates the PPP sessions. No routing protocols are needed on these devices which do have limited resources. The BRAS runs an IPv6 IGP to the Edge Router: OSPFv3 or IS-IS. Different processes should be used if the NAP and the NSP are managed by different organizations. In this case controlled redistribution should be enabled between the two domains. The Edge Router is running the IPv6 IGP used in the ISP network: OSPFv3 or IS-IS. Depending on the design of the edge portion of the ISP network, some Edge Routers might have to run iBGP for IPv6. In this case it is expected that two peer sessions are established between the Edge Router and a pair of redundant Route Reflectors. 6.2.4 Hybrid MODEL for IPv4 and IPv6 service It was recommended throughut this section that the IPv6 service implementation should map the existent IPv4 one. This approach simplifies manageability and minimizes trainning needed for personnel operating the network. In certain circumstances such mapping is not feasible. This typically becomes the case when a Service Provider plans to expend its service offering with the new IPv6 deployed infrastructure. If this new service is not well supported in a network design such as the one used for IPv4 then a different design might be used for IPv6. An example of such circumstances is that of a provider using an LAA design for its IPv4 services. In this case all the PPP sessions are bundeled and tunneled across the entire NAP infrastructure which is made of multiple BRAS routers, aggregation routers etc. The end point of these tunnels is the ISP Edge Router. If the provider decides to offer multicast services over such a design, it will face the problem of NAP resources being over utilized. The multicast traffic can be replicated only at the end of the tunnels by the Edge router and the copies for all the subscribers are carried over the entire NAP. A Point-to-Point or a PTA model is more suitable to support multicast services because the packet replication can be done closer to the draft-asadullah-v6ops-bb-deployment-scenarios-00.txt [Page 32] INTERNET-DRAFT ISP IPv6 Deployment Scenarios in BB Networks July 2004 destination at the BRAS. Such topology saves NAP resources. IPv6 deployment can be viewed as an opportunity to build an infrastructure that might support better the expanssion of services. In this case, an SP using the LAA design for its IPv4 services might choose a Point-to-Point or PTA design for IPv6. 6.2.4.1 IPv4 in LAA model and IPv6 in PTA model The coexistence of the two PPP based models, PTA and LAA, is relatively straight forward. It is a straight forward overlap of the two deployment models. The the PPP sessions are terminated on different network devices for the IPv4 and IPv6 services. The PPP sessions for the existent IPv4 service deployed in an LAA model are terminated on the Edge Router. The PPP sessions for the new IPv6 service deployed in a PTA model are terminated on the BRAS. The logical design for IPv6 and IPv4 in this hybrid model is presented in Figure 6.2.4.1. IPv6 <--------------------------> PPP +-----------+ | AAA | +-------+ Radius | | | TACACS | | +-----+-----+ | | +-----+ +-------+ +--------+ +----+-----+ +-----+-----+ |Hosts|--+Router +------+ DSLAM +-+ BRAS +-+ Edge | +-----+ +-------+ +--------+ +----------+ | Router +=>Core +-----------+ IPv4 <----------------------------------------> PPP <------------> L2TP Figure 6.2.4.1 draft-asadullah-v6ops-bb-deployment-scenarios-00.txt [Page 33] INTERNET-DRAFT ISP IPv6 Deployment Scenarios in BB Networks July 2004 6.2.4.2 IPv4 in LAA Model and IPv6 in Point-to-Point Model The coexistence of the Point-to-Point and the LAA models implies a few specific changes. For the IPv4 service the VLANs are terminated on the BRAS and traffic is routed to the Edge router. The same should be done for IPv6 unlike the case study 6.2.1 where the VLANs are terminated on the Edge Router. For this reason the BRAS will have to be upgraded to IPv6 and implement all the functionalities defined for the Edge Router in section 6.2.1. The other aspect to such a deployment is the fact that the BRAS has to be capable of distingushing between the IPv4 PPP traffic that has to be bridged across the L2TP tunnel and the IPv6 packets that have to be routed to the Edge Router. The IPv6 Routing and Bridging Encapsulation (RBE) has to be enabled on all interfaces with VLANs supporting both IPv4 and IPv6 services in this hibrid design. The logical design for IPv6 and IPv4 in this hybrid model is presented in Figure 6.2.4.2. IPv6 <----------------> ATM +-----------+ | AAA | +-------+ Radius | | | TACACS | | +-----+-----+ | | +-----+ +-------+ +--------+ +----+-----+ +-----+-----+ |Hosts|--+Router +------+ DSLAM +-+ BRAS +-+ Edge | +-----+ +-------+ +--------+ +----------+ | Router +=>Core +-----------+ IPv4 <----------------------------------------> PPP <------------> L2TP Figure 6.2.4.2 draft-asadullah-v6ops-bb-deployment-scenarios-00.txt [Page 34] INTERNET-DRAFT ISP IPv6 Deployment Scenarios in BB Networks July 2004 6.3 IPv6 Multicast The typical multicast services offered for residential and very small businesses is video/audio streaming where the subscriber joins a multicast group and recieves the content. This type of service model is well supported through PIM-SSM which is very simple and easy to manage. PIM-SSM has to be enabled throughout the ISP network. MLDv2 is required for PIM-SSM support. Vendors can choose to implement features that allow routers to map MLDv1 group joins to predefined sources. Subscribers might use a set-top box that is responsible for the controll piece of the multicast service (does group joins/leaves). The subscriber hosts can also join desired multicast groups as long as they are enabled to support MLDv1 or MLDv2. If a customer premise router is used then it has to be enabled to support MLDv1 and MLDv2 in order to process the requests of the hosts. It has to be enabled to support PIM-SSM in order to send PIM joins/leaves up to its Layer-3 next hop whether it is the BRAS or the Edge router. When enabling this functionality on a customer premises router, it's limited resources should be taken into consideration. The router that is the Layer-3 next hop for the subscriber (BRAS in the PTA model or the Edge router in the LAA and Point-to-Point model) has to be enabled to support MLDv1 and MLDv2 in order to process the requests coming from subscribers without customer premises routers. It has to be enabled for PIM-SSM in order to receive joins/leaves from customer routers and send joins/leaves to the next hop towards the multicast source (Edge router or the NSP core). MLD authentication, authorization and accounting is usually configured on the edge router in order to enable the ISP to do controll the subbscriber access of the service and do billing for the content provided. 6.4 IPv6 QoS The QoS configuration is particularly relevant on the router that represents the Layer-3 next hop for the subscriber (BRAS in the PTA model or the Edge router in the LAA and Point-to-Point model) in order to manage resources shared amongst multiple subscribers possibly with various service level agreements. In the DSL infrastructure it is expected that there is already a level of traffic policing and shaping implemented for IPv4 connectivity. This is implemented throughout the NAP and it is beyond the scope of this document. draft-asadullah-v6ops-bb-deployment-scenarios-00.txt [Page 35] INTERNET-DRAFT ISP IPv6 Deployment Scenarios in BB Networks July 2004 On the BRAS or the Edge Router the subscriber facing interfaces have to be configure to police the inbound customer traffic and shape the traffic outbound to the customer based on the SLAs. Traffic classification and marking should also be done on the router closest(at layer 3) to the subscriber in order to support the various types of customer traffic: data, voice, video and to optimaly use the infrastructure resources. Each provider (NAP, NSP) could implement their own QoS policies and services so reclassification and marking might be performed at the boundary between the NAP and the NSP in order to make sure the traffic is properly handled by the ISP. The same IPv4 QoS concepts and methodologies should be applied the IPv6 as well. 6.5 IPv6 Security Considerations There are limited changes that have to be done for CPEs in order to enhance security. The Privacy extenssions for auto-configuration [RFC 3041] should be used by the hosts. IPv6 firwall functions should be enabled on the hosts or customer premisses router if present. The ISP provides security against attacks that come form its own subscribers but it could also implement security services that protect its subscribers from attacks sourced from the outside of its network. Such services do not apply at the access level of the network discussed here. The device that is the Layer-3 next hop for the subscribers (BRAS or Edge router) should protect the network and the other subscribers against attacks by one of the provider's customers. For this reason uRPF and ACLs should be used on all interfaces facing subscribers. Filtering should be implemented with regard for the operational requirements of IPv6 (ICMPv6 types). Authentication and authorization should be used wherever possible. The BRAS and the Edge Router should protect their processing resources against floods of valid customer controll traffic such as: Router and Neighbor Solicitations, MLD Requests. Rate limiting should be implemented on all subscriber facing interfaces. The emphasis should be placed on multicast type traffic as it is most often used by the IPv6 controll plane. All other security features used with the IPv4 service should be similarly applied to IPv6 as well. 6.6 IPv6 Network management Usually, NSPs manage the edge routers by SNMP. The management stations are located on the core network. Very few service providers manage equipment located on customers LANs. draft-asadullah-v6ops-bb-deployment-scenarios-00.txt [Page 36] INTERNET-DRAFT ISP IPv6 Deployment Scenarios in BB Networks July 2004 7. Broadband Ethernet Networks This section describes the IPv6 deployment options in today's Broadband Ethernet Access Networks. 7.1 Ethernet Access Network Elements In environments that support the infrastructure deploying RJ-45 or fiber (Fiber to the Home (FTTH) service) to subscribers, 10/100 Mbps Ethernet broadband services can be provded. Such services are generally available in metropolitan areas, in multi tenant buildings where an Ethernet infrastructure can be deployed in a cost effective manner. In such environments Metro-Ethernet services can be used to provide aggregation and uplink to a Service Provider. The following network elements are typical of an Ethernet network [ISP Transition Scenarios]: - Ethernet Switch, it is used as a Layer 2 aggregator of subscriber's hosts. - Customer Premises Router, it is used to provide layer 3 services for customer premises networks. - Aggregation Ethernet Switches, aggregates multiple subscribers. - Broadband Remote Access Server (BRAS) - Edge Router (ER) Figure 7.1 depicts all the network elements mentioned. Customer Premises | Network Access Provider | Network Service Provider CP NAP NSP +-----+ +------+ +------+ +--------+ |Hosts|--|Router| +-+ BRAS +---+ Edge | ISP +-----+ +--+---+ | | | | Router +===> Network | | +------+ +--------+ +--+-----+ | |Ethernet+-+ | |Switch | | | +--------+ | +------+ | +--+ | | +--------+ |Switch+-+ +-----+ |Ethernet| +--+ | |Hosts|--+Switch +-+ +------+ +-----+ +--------+ Figure 7.1 The logical topology and design of Broadband Ethernet Networks is very similar to DSL Broadband Networks discussed in section 6. draft-asadullah-v6ops-bb-deployment-scenarios-00.txt [Page 37] INTERNET-DRAFT ISP IPv6 Deployment Scenarios in BB Networks July 2004 7.2 Deploying IPv6 in today's IPv4 Broadband Ethernet Networks There are two main design approaches to providing IPv4 connectivity over an Ethernet infrastructure: 1. Point-to-point model: Each subscriber connects to the network access switch over RJ-45 or fiber links. Each subscriber is assigned a unique VLAN on the access switch. The VLAN can be terminated at the BRAS or at the Edge Router. The VLANs are 802.1q trunked to the Layer 3 device (BRAS or Edge ROuter). This model is presented in section 7.2.7. 2. PPP Terminated Aggregation (PTA) model: PPP sessions are opened between each subscriber and the BRAS. The BRAS terminates the PPP sessions and provides Layer 3 connectivity between the subscriber and the ISP. This model is presented in section 7.2.2. 3. L2TP Access Aggregation (LAA) model: PPP sessions are opened between each subscriber and the ISP termination devices. The BRAS tunnels the subscriber PPP sessions to the ISP by encapsulating them into L2TP tunnels. This model is presented in section 7.2.3. In aggregation models the BRAS terminates the subscriber VLANs and aggregates their connections before providing access to the ISP. In order to maintain the deployment concepts and business models proven and used with existent revenue generating IPv4 services, the IPv6 deployment will match the IPv4 one. This approach is presented in sections 7.2.1-3 that describes today's IPv4 over Ethernet broadband access deployments. Under certain circumstances where new service types or service needs justify it, IPv4 and IPv6 network architectures could be different as described in secton 7.2.4. 7.2.1 POINT-TO-POINT MODEL In this scenario the Ethernet frames from the Host or the Customer Premises Router are bridged over the VLAN assigned to the subscriber. draft-asadullah-v6ops-bb-deployment-scenarios-00.txt [Page 38] INTERNET-DRAFT ISP IPv6 Deployment Scenarios in BB Networks July 2004 Figure 7.2.1 describes the protocol architecture of this model. Customer Premises NAP NSP <-------------------------> <---------------> <--------------------> +-----+ +------+ +------+ +--------+ +----------+ |Hosts|--+Router+--+Ether +--+ Switch +--------+ Edge | ISP +-----+ +------+ |Switch| +--------+ 802.1q | Router +==> Network +------+ +----------+ <----------------------------> Ethernet/VLANs Figure 7.2.1 7.2.1.1 IPv6 related Infrastructure changes In this scenario the Ethernet Switch on the customer site and the entire NAP is layer-3 unaware so no changes are needed to support IPv6. The following devices have to be upgraded to dual stack: Host, Customer Router and Edge Router. The Ethernet switches might need upgrades to support certain IPv6 related features such as MLD Snooping. 7.2.1.2 Addressing The Hosts or the Customer Routers have the Edge Router as their Layer 3 next hop. If there is no Customer Router all the hosts on the subscriber site belong to the same /64 subnet that is statically configured on the Edge Router for that subsrciber's VLAN. The hosts can use stateless or statefull autoconfiguration to aquire an address via the Edge Router. If a Customer Router is present: - it is statically configured with an address on the /64 subnet between itself and the Edge Router, and with /64 prefixes on the interfaces connecting the hosts on the customer site. This is not a desired provisioning method being expensive and difficult to manage. - it dynamically acquires through autoconfiguration the address for the link between itself and the Edge Router. This step is followed by a request via DHCP-PD for a prefix shorter then /64 that in turn is divided in /64s and assigned to its interfaces connecting the hosts on the customer site. The Edge Router has a /64 prefix configured for each subscriber VLAN. draft-asadullah-v6ops-bb-deployment-scenarios-00.txt [Page 39] INTERNET-DRAFT ISP IPv6 Deployment Scenarios in BB Networks July 2004 Each VLAN should be enabled to relay DHCPv6 requests from the subscribers to DHCPv6 servers in the ISP network. The VLANs providing access for subscribers that use DHCP-PD as well, have to be enabled to support the feature. The uplink to the ISP network is configured with a /64 prefix as well. The prefixes used for subscriber links and the ones delegated via DHCP-PD should be planned in a maner that allows as much summarization as possible at the Edge Router. Other information of interest to the host, such as DNS, is provided through stateful and stateless DHCPv6. 7.2.1.3 Routing The CPE devices are configured with a default route that points to the Edge router. No routing protocols are needed on these devices which do have limited resources. The Edge Router runs the IPv6 IGP used in the NSP: OSPFv3 or IS-IS. The connected prefixes have to be redistributed. If DHCP-PD is used, with every delegated prefix a static route is installed by the Edge Router. For this reason the static routes must also be redistributed. Prefix summarization should be done at the Edge Router. Depending on the design of the edge portion of the ISP network, some Edge Routers might have to run iBGP for IPv6. In this case it is expected that two peer sessions are established between the Edge Router and a pair of redundant Route Reflectors. 7.2.2 PPP TERMINATED AGGREGATION (PTA) MODEL The PTA architecture relies on PPP-based protocols (PPPoE). The PPP sessions are initiated by Customer Premise Equipment and it is terminated at the BRAS. The BRAS authorizes the session, authenticates the subscriber, and provides an IP address on behalf of the ISP. The BRAS then does Layer-3 routing of the subscriber traffic to the NSP Edge Router. This model is often used when the NSP is also the NAP. draft-asadullah-v6ops-bb-deployment-scenarios-00.txt [Page 40] INTERNET-DRAFT ISP IPv6 Deployment Scenarios in BB Networks July 2004 The PPPoE logical diagram in an Ethernet Broadband Network is shown in Fig 7.2.2.1. Customer Premises NAP NSP <---------------------------> <-----------------> <-----------------> +-----------+ | AAA | +-------+ Radius | | | TACACS | | +-----------+ +-----+ +-------+ +--------+ +--------+ +----+-----+ +-----------+ |Hosts|--+Router +-+E Switch+-+ Switch +-+ BRAS +-+ Edge | C +-----+ +-------+ +--------+ +--------+ +----------+ | Router +=>O <---------------- PPP ----------------> | | R +-----------+ E Figure 7.2.2.1 The PPP sessions are initiated by the Customer Premise Equipment (Host or Router). The BRAS authenticates the subscriber against a local or a remote database. Once the session is established, the BRAS provides an address and maybe a DNS server to the user, information aquired from the subscriber profile or from a DHCP server. This model allows for multiple PPPoE session to be supported over the same VLAN thus allowing the subscriber to connect to multiple services at the same time. The hosts can initiate the PPPoE sessions as well. It is important to remember that the PPPoE encapsulation reduces the IP MTU available for the customer traffic. 7.2.2.1 IPv6 Related Infrastructure Changes In this scenario the BRAS is layer-3 aware and it has to be upgraded to support IPv6. Since the BRAS terminates the PPP sessions it has to support PPPoE with IPv6. The following devices have to be upgraded to dual stack: Host, Customer Router, BRAS and Edge Router. 7.2.2.2 Addressing The BRAS terminates the PPP sessions and provides the subscriber with an IPv6 address from the defined pool for that profile. The subscriber profile for authorization and authentication can be located on the BRAS or on a AAA server. The Hosts or the Customer Routers have the BRAS as their Layer 3 next hop. The PPP session can be initiated by a host or by a Customer Router. draft-asadullah-v6ops-bb-deployment-scenarios-00.txt [Page 41] INTERNET-DRAFT ISP IPv6 Deployment Scenarios in BB Networks July 2004 In the later case, once the session is established with the BRAS, DHCP-PD can be used to aquire prefixes for the Customer Router interfaces. The BRAS has to be enabled to support DHCP-PD and to relay the DHCPv6 requests of the hosts on the subscriber sites. The BRAS has a /64 prefix configured on the link to the Edge router. The Edge router links are also configured with /64 prefixes to provide conectivity to the rest of the ISP network. The prefixes used for subscriber and the ones delegated via DHCP-PD should be planned in a maner that allows maximum summarization at the BRAS. Other information of interest to the host, such as DNS, is provided through stateful and stateless DHCPv6. 7.2.2.3 Routing The CPE devices are configured with a default route that points to the BRAS router. No routing protocols are needed on these devices which do have limited resources. The BRAS runs an IGP to the Edge Router: OSPFv3 or IS-IS. Since the addresses assigned to the PPP sessions are represented as connected host routes, connected prefixes have to be redistributed. If DHCP-PD is used, with every delegated prefix a static route is installed by the Edge Router. For this reason the static routes must also be redistributed. Prefix summarization should be done at the BRAS. The Edge Router is running the IGP used in the ISP network: OSPFv3 or IS-IS. A separation between the routing domains of the ISP and the Access Provider is recomended if they are managed independently. Controlled redistribution will be needed between the Access Provider IGP and the ISP IGP. Depending on the design of the edge portion of the ISP network, some Edge Routers might have to run iBGP for IPv6. In this case it is expected that two peer sessions are established between the Edge Router and a pair of redundant Route Reflectors. 7.2.3 L2TP ACCESS AGGREGATION (LAA) MODEL In the LAA model the BRAS forwards the CPE initiated session to the ISP over an L2TP tunnel established between the BRAS and the Edge Router. In this case the authentication, authorization and subscriber configuration are performed by the ISP itself. draft-asadullah-v6ops-bb-deployment-scenarios-00.txt [Page 42] INTERNET-DRAFT ISP IPv6 Deployment Scenarios in BB Networks July 2004 Customer Premises NAP NSP <--------------------> <----------------------> <-----------------> +-----------+ | AAA | +------+ Radius | | | TACACS | | +-----+-----+ | | +-----+ +-------+ +--------+ +--------+ +----+-----+ +----+------+ |Hosts|--+Router +-+ Modem +-+ DSLAM +-+ BRAS +-+ Edge | C +-----+ +-------+ +--------+ +--------+ +----------+ | Router +=>O | | R +-----------+ E <-----------------------------------------------> PPP <--------------> L2TP Figure 7.2.3.1 7.2.3.1 IPv6 Related Infrastructure Changes In this scenario the BRAS is layer-3 aware and it has to be upgraded to support IPv6. The PPP sessions initiated by the subscriber are forwarded over the L2TP tunnel to the aggregation point in the ISP network. The BRAS must have the capability to support L2TP for IPv6. The following devices have to be upgraded to dual stack: Host, Customer Router, BRAS and Edge Router. 7.2.3.2 Addressing The Edge router terminates the PPP sessions and provides the subscriber with an IPv6 address from the defined pool for that profile. The subscriber profile for authorization and authentication can be located on the Edge Router or on a AAA server. The Hosts or the Customer Routers have the Edge Router as their Layer 3 next hop. The PPP session can be initiated by a host or by a Customer Router. In the later case, once the session is established with the Edge Router, DHCP-PD can be used to aquire prefixes for the Customer Router interfaces. The Edge Router has to be enabled to support DHCP-PD and to relay the DHCPv6 requests of the hosts on the subscriber sites. draft-asadullah-v6ops-bb-deployment-scenarios-00.txt [Page 43] INTERNET-DRAFT ISP IPv6 Deployment Scenarios in BB Networks July 2004 The BRAS has a /64 prefix configured on the link to the Edge router. The Edge router links are also configured with /64 prefixes to provide conectivity to the rest of the ISP network. Other information of interest to the host, such as DNS, is provided through stateful and stateless DHCPv6. 7.2.3.3 Routing The CPE devices are configured with a default route that points to the Edge router that terminates the PPP sessions. No routing protocols are needed on these devices which do have limited resources. The BRAS runs an IPv6 IGP to the Edge Router: OSPFv3 or IS-IS. Different processes should be used if the NAP and the NSP are managed by different organizations. In this case controlled redistribution should be enabled between the two domains. The Edge Router is running the IPv6 IGP used in the ISP network: OSPFv3 or IS-IS.Depending on the design of the edge portion of the ISP network, some Edge Routers might have to run iBGP for IPv6. In this case it is expected that two peer sessions are established between the Edge Router and a pair of redundant Route Reflectors. 7.2.4 Hybrid MODEL for IPv4 and IPv6 service It was recommended throughut this section that the IPv6 service implementation should map the existent IPv4 one. This approach simplifies manageability and minimizes trainning needed for personnel operating the network. In certain circumstances such mapping is not feasible. This typically becomes the case when a Service Provider plans to expand its service offering with the new IPv6 deployed infrastructure. If this new service is not well supported in a network design such as the one used for IPv4 then a different design might be used for IPv6. An example of such circumstances is that of a provider using an LAA design for its IPv4 services. In this case all the PPP sessions are bundeled and tunneled across the entire NAP infrastructure which is made of multiple BRAS routers, aggregation routers etc. The end point of these tunnels is the ISP Edge Router. If the SP decides to offer multicast services over such a design, it will face the problem of NAP resources being over utilized. The multicast traffic can be replicated only at the end of the tunnels by the Edge router and the copies for all the subscribers are carried over the entire NAP. draft-asadullah-v6ops-bb-deployment-scenarios-00.txt [Page 44] INTERNET-DRAFT ISP IPv6 Deployment Scenarios in BB Networks July 2004 A Point-to-Point or a PTA model is more suitable to support multicast services because the packet replication can be done closer to the destination at the BRAS. Such topology saves NAP resources. IPv6 deployment can be viewed as an opportunity to build an infrastructure that can better support the expanssion of services. In this case, an SP using the LAA design for its IPv4 services might choose a Point-to-Point or PTA design for IPv6. 7.2.4.1 IPv4 in LAA model and IPv6 in PTA model The coexistence of the two PPP based models, PTA and LAA, is relatively straight forward. It is a straight forward overlap of the two deployment models. The the PPP sessions are terminated on different network devices for the IPv4 and IPv6 services. The PPP sessions for the existent IPv4 service deployed in an LAA model are terminated on the Edge Router. The PPP sessions for the new IPv6 service deployed in a PTA model are terminated on the BRAS. The logical design for IPv6 and IPv4 in this hybrid model is presented in Figure 7.2.4.1. IPv6 <--------------------------> PPP +-----------+ | AAA | +-------+ Radius | | | TACACS | | +-----+-----+ | | +-----+ +-------+ +--------+ +----+-----+ +-----+-----+ |Hosts|--+Router +------+ Switch +-+ BRAS +-+ Edge | +-----+ +-------+ +--------+ +----------+ | Router +=>Core +-----------+ IPv4 <----------------------------------------> PPP <------------> L2TP Figure 7.2.4.1 7.2.4.2 IPv4 in LAA model and IPv6 in Point-to-Point model The coexistence of the Point-to-Point and the LAA models implies a few specific changes. For the IPv4 service the VLANs are terminated on the BRAS and traffic draft-asadullah-v6ops-bb-deployment-scenarios-00.txt [Page 45] INTERNET-DRAFT ISP IPv6 Deployment Scenarios in BB Networks July 2004 is routed to the Edge router. The same should be done for IPv6 unlike the case study 7.2.1 where the VLANs are terminated on the Edge Router. For this reason the BRAS will have to be upgraded to IPv6 and implement all the functionalities defined for the Edge Router in section 7.2.1. The other aspect to such a deployment is the fact that the BRAS has to be capable of distingushing between the IPv4 PPP traffic that has to be bridged across the L2TP tunnel and the IPv6 packets that have to be routed to the Edge Router. The IPv6 Routing and Bridging Encapsulation (RBE) has to be enabled on all interfaces with VLANs supporting both IPv4 and IPv6 services in this hibrid design. The logical design for IPv6 and IPv4 in this hybrid model is in Figure 7.2.4.2. IPv6 <----------------> Ethernet +-----------+ | AAA | +-------+ Radius | | | TACACS | | +-----+-----+ | | +-----+ +-------+ +--------+ +----+-----+ +-----+-----+ |Hosts|--+Router +------+ DSLAM +-+ BRAS +-+ Edge | +-----+ +-------+ +--------+ +----------+ | Router +=>Core +-----------+ IPv4 <----------------------------------------> PPP <------------> L2TP Figure 7.2.4.2 7.3 IPv6 Multicast The typical multicast services offered for residential and very small businesses is video/audio streaming where the subscriber joins a multicast group and recieves the content. This type of service model is well supported through PIM-SSM which is very simple and easy to manage. PIM-SSM has to be enabled throughout the ISP network. MLDv2 is required for PIM-SSM support. Vendors can choose to implement features that allow routers to map MLDv1 group joins to predefined sources. Subscribers might use a set-top box that is responsible for the control piece of the multicast service (does group joins/leaves). The subscriber hosts can also join desired multicast groups as long as they are enabled to draft-asadullah-v6ops-bb-deployment-scenarios-00.txt [Page 46] INTERNET-DRAFT ISP IPv6 Deployment Scenarios in BB Networks July 2004 support MLDv1 or MLDv2. If a customer premise router is used then it has to be enabled to support MLDv1 and MLDv2 in order to process the requests of the hosts. It has to be enabled to support PIM-SSM in order to send PIM joins/leaves up to its Layer-3 next hop whether it is the BRAS or the Edge router. When enabling this functionality on a customer premises router, it's limited resources should be taken into consideration. MLD snooping or similar layer two multicast related protocols could be enabled on the NAP switches. The router that is the Layer-3 next hop for the subscriber (BRAS in the PTA model or the Edge router in the LAA and Point-to-Point model) has to be enabled to support MLDv1 and MLDv2 in order to process the requests coming from subscribers without customer premises routers. It has to be enabled for PIM-SSM in order to receive joins/leaves from customer routers and send joins/leaves to the next hop towards the multicast source (Edge router orthe NSP core). MLD authentication, authorization and accounting is usually configured on the edge router in order to enable the ISP to do control the subbscriber access of the service and do billing for the content provided. 7.4 IPv6 QoS The QoS configuration is particularly relevant on the router that represents the Layer-3 next hop for the subscriber (BRAS in the PTA model or the Edge router in the LAA and Point-to-Point model) in order to manage resources shared amongst multiple subscribers possibly with various service level agreements. On the BRAS or the Edge Router the subscriber facing interfaces have to be configure to police the inbound customer traffic and shape the traffic outbound to the customer based on the SLAs. Traffic classification and marking should also be done on the router closest (at layer 3) to the subscriber in order to support the various types of customer traffic: data, voice, video and to optimaly use the infrastructure resources. Each provider (NAP, NSP) could implement their own QoS policies and services so reclassification and marking might be performed at the boundary between the NAP and the NSP in order to make sure the traffic is properly handled by the ISP. The same IPv4 QoS concepts and methodologies should be applied for the IPv6 as well. draft-asadullah-v6ops-bb-deployment-scenarios-00.txt [Page 47] INTERNET-DRAFT ISP IPv6 Deployment Scenarios in BB Networks July 2004 7.5 IPv6 Security Considerations There are limited changes that have to be done for CPEs in order to enhance security. The Privacy extenssions for autoconfiguration should be used by the hosts. IPv6 firwall functions should be enabled on the hosts or customer premisses router if present. The ISP provides security against attacks that come form its own subscribers but it could also implement security services that protect its subscribers from attacks sourced from the outside of its network. Such services do not apply at the access level of the network discussed here. The NAP can stop IPv6 traffic from customer that did not subscribe to the service by using layer two filters based on the IPv6 Ethertype (0X86DD). The device that is the Layer-3 next hop for the subscribers (BRAS Edge router) should protect the network and the other subscribers against attacks by one of the provider's customers. For this reason uRPF and ACLs should be used on all interfaces facing subscribers. Filtering should be implemented with regard for the operational requirements of IPv6 (ICMPv6 types). Authentication and authorization should be used wherever possible. The BRAS and the Edge Router should protect their processing resources against floods of valid customer controll traffic such as: Router and Neighbor Solicitations, MLD Requests. Rate limiting should be implemented on all subscriber facing interfaces. The emphasis should be placed on multicast type traffic as it is most often used by the IPv6 control plane. All other security features used with the IPv4 service should be similarly applied to IPv6 as well. 7.6 IPv6 Network Management Usually, NSPs manage the edge routers by SNMP. The management stations are located on the core network. Very few service providers manage equipment located on customers LANs. 8. Wireless LAN This section provides detailed description of IPv6 deployment and integration methods in today's wireless LAN (WLAN) infrastructure. 8.1 WLAN Deployment Scenarions WLAN enables subscribers to connect to the Internet from various locations without the restriction of staying indoors. WLAN is draft-asadullah-v6ops-bb-deployment-scenarios-00.txt [Page 48] INTERNET-DRAFT ISP IPv6 Deployment Scenarios in BB Networks July 2004 standardized by IEEE 802.11x. IEEE 802.11 offers maximum transmission speed from 1 or 2 Mbps, IEEE 802.11b offers 11 Mbps and IEEE 802.11a offers upto 54 Mbps. Figure 8.1 describes the current WLAN architecture. Customer Premises| Access Provider |Service Provider | | +------+ +--+ +--------------+ +----------+ +------+ |WLAN | ---- | | |Access Router/| |Underlying| |Edge | |Host/ |-(WLAN)-|AP|-|Layer2 Switch |-|Technology|-|Router|=>SP |Router| ---- | | | | | | | | Network +------+ +--+ +--------------+ +----------+ +------+ | +------+ |AAA | |Server| Figure 8.1 +------+ The host should have a wireless network interface card (NIC) in order to connect to a WLAN network. WLAN is a flat broadcast network and works in a similar fashion as Ethernet. When hosts initiate a connection, it is authenticated by the AAA server located at the SP network. All the authentication parameters (username, password and etc.) are forwarded by the Access Point (AP) to the AAA server. The AAA server authenticates the host, once authenticated successfully the host can send data packets. The AP is located near the host and acts as a bridge. The AP forwards all the packets coming to/from host to the Edge Router. The underlying connection between the AP and Edge Router could be based on any access layer technology such as HFC/Cable, FTTH, xDSL or etc. WLANs are based in limited areas known as WiFi Hot Spots. While users are present in the area covered by the WLAN range, they can be connected to the Internet given they have a wireless NIC and required configuration settings in their devices (notebook PCs, PDA or etc.). Once the user initiates the conenction the IP address is assigned by the the SP using DHCPv4. In most of the cases SP assigns limited number of public IP addresses to the it's customer. Once the public IP address is received, the WLAN Router assigns private addresses [RFC 1918] to all WLAN users. The WLAN Router provides NAT functionality while WLAN users access the Internet. When the user disconnects the connection and move to a new WiFi hot spot, the above draft-asadullah-v6ops-bb-deployment-scenarios-00.txt [Page 49] INTERNET-DRAFT ISP IPv6 Deployment Scenarios in BB Networks July 2004 mentioned process of authentication, address assignment, NAT and accessing the Internet is repeated. A detailed description of current WLAN infrastructure using IPv4 is explained in [ISP Transition Scenarios]. While deploying IPv6 in the above mentioned WLAN architecture, there are three possible scenarios as discussed below. - Layer2 Switch Between AP and Edge Router - Access Router Between AP and Edge Router - PPP Based Model 8.1.1 Layer2 Switch Between AP and Edge Router When a Layer2 switch is present between AP and Edge Router, the AP and Layer2 switch continues to work as a bridge, forwarding IPv4 and IPv6 packets from WLAN Host/Router to Edge Router and vice versa. When initiating the connection, the WLAN host is authenticated by the AAA server located at the SP network. All the parameters related to autehentication (username, password and etc.) are forwarded by the AP to the AAA server. The AAA server authenticates the WLAN Hosts and once authenticated and associated successfully with WLAN AP, IPv6 address will be acquired by the WLAN Host. Note the initiation and authentication process is same as used in IPv4. Figure 8.1.1 describes the WLAN architecture when Layer2 Switch is located between AP and Edge Router. Customer Premises| Access Provider |Service Provider | | +------+ +--+ +--------------+ +----------+ +------+ |WLAN | ---- | | | | |Underlying| |Edge | |Host/ |-(WLAN)-|AP|-|Layer2 Switch |-|Technology|-|Router|=>SP |Router| ---- | | | | | | | | Network +------+ +--+ +--------------+ +----------+ +------+ | +------+ |AAA | |Server| +------+ Figure 8.1.1 draft-asadullah-v6ops-bb-deployment-scenarios-00.txt [Page 50] INTERNET-DRAFT ISP IPv6 Deployment Scenarios in BB Networks July 2004 8.1.1.1 IPv6 Related Infrastructure Changes IPv6 will be deployed in this scenario by upgrading the following devices to dual-stack, supporting both IPv4 and IPv6 protocols: - WLAN Host - WLAN Router (if present) - Edge Router 8.1.1.2 Addressing When customer WLAN Router is not present, the WLAN Host has two possible options to get an IPv6 address via the Edge Router. A. The WLAN host can get the IPv6 address from Edge router using stateless auto-configuration [RFC 2462]. All the hosts on the WLAN belong to the same /64 subnet that is statically configured on the Edge Router. The IPv6 WLAN Host may use stateless DHCPv6 for obtaining other information of interest such as DNS and etc. B. IPv6 WLAN host can use DHCPv6 [RFC 3315] to get a IPv6 address from the DHCPv6 server. In this case the DHCPv6 server would be located in the SP core network and Edge Router would act simply as a DHCP Relay Agent. This option is similar to what we do today in case of DHCPv4. When a customer WLAN Router is present, the WLAN Host has two possible options as well for acquiring IPv6 address. A. The WLAN Router may receive a /48 or /64 prefix statically from the Edge Router depending on the SPÆs policy and the customerÆs requirements. If the WLAN Router has multiple networks connected to its interfaces, the network administrator will have to configure the /64 prefixes to the WLAN Router subinterfaces. The WLAN Hosts connected to these interfaces can automatically configure themselves using stateless auto-configuration with /64 prefix. B. The WLAN Router dynamically acquires an address through auto-configuration for the link between itself and the Edge Router. This step is followed by a request using DHCP Prefix Delegation (PD) [RFC 3633] for a prefix. In this option, the WLAN Router would act as a requesting router and Edge Router would act as delegating router. Once prefix is received by the WLAN Router, it assigns /64 prefixes to each of its interfaces connecting the WLAN Hosts on the customer site. The WLAN Hosts connected to these interfaces can automatically configure themselves using stateless auto-configuration with /64 prefix. draft-asadullah-v6ops-bb-deployment-scenarios-00.txt [Page 51] INTERNET-DRAFT ISP IPv6 Deployment Scenarios in BB Networks July 2004 Usually it is easier for the SPs to stay with the DHCP PD and stateless auto-configuration model and point the clients to a central server for DNS/domain information, proxy configurations and others. Using this model the SP could change prefixes on the fly and the WLAN Router would simply pull the newest prefix based on the valid/preferred lifetime. The prefixes used for subscriber links and the ones delegated via DHCP-PD should be planned in a manner that allows maximum summarization as possible at the Edge Router. Other information of interest to the host, such as DNS, is provided through stateful and stateless DHCPv6. 8.1.1.3 Routing The WLAN Host/Router are configured with a default route that points to the Edge router. No routing protocols are needed on these devices which do have limited resources. The Edge Router runs the IGP used in the SP network such as OSPFv3 or IS-IS for IPv6. The connected prefixes have to be redistributed. Prefix summarization should be done at the Edge Router. Depending on the design of the edge portion of the ISP network, some Edge Routers might have to run iBGP for IPv6. In this case it is expected that two peer sessions are established between the SP Edge Router and a pair of redundant Route Reflectors. 8.1.2 Access Router Between AP and SP Edge Router When a Access Router is present between AP and Edge Router, the AP continues to work as a bridge, forwarding IPv4 and IPv6 packets from WLAN Host/Router to Access/Edge Router and vice versa. The Access Router could be part of SP network or owned by a seperate Access Provider. When WLAN Host initiates the connection, the AAA authentication and assosiation process with WLAN AP will be similar as explained in section 8.1.1. Figure 8.1.2 describes the WLAN architecture when Access Router is located between AP and Edge Router. draft-asadullah-v6ops-bb-deployment-scenarios-00.txt [Page 52] INTERNET-DRAFT ISP IPv6 Deployment Scenarios in BB Networks July 2004 Customer Premises| Access Provider |Service Provider | | +------+ +--+ +--------------+ +----------+ +------+ |WLAN | ---- | | | | |Underlying| |Edge | |Host/ |-(WLAN)-|AP|-|Access Router |-|Technology|-|Router|=>SP |Router| ---- | | | | | | | | Network +------+ +--+ +--------------+ +----------+ +------+ | +------+ |AAA | |Server| +------+ Figure 8.1.2 8.1.2.1 IPv6 Related Infrastructure Changes IPv6 is deployed in this scenario by upgrading the following devices to dual-stack, supporting both IPv4 and IPv6 protocols: - WLAN Host - WLAN Router (if present) - Access Router - Edge Router 8.1.2.2 Addressing There are three possible options in this scenario for IPv6 address assignment: A. The Edge Router's interface facing towards the Access Router is statically configured with /64 prefix. The Access Router receives/ configures an /64 prefix on it's interface facing towards Edge Router through stateless auto-configuration. The network administrator will have to configure the /64 prefixes to the Access Router interface facing towards the customer premises. The WLAN Host/Router connected to this interface can automatically configure themselves using stateless auto-configuration with /64 prefix. B. This option uses DHCPv6 [RFC3315] for IPv6 prefix assignments to the WLAN Host/Router. There is no use of DHCP PD or stateless auto-configuration in this option. The DHCPv6 server can be located on the Access Router, on the Edge Router or somehwere in the SP's network. In this case depending on where the DHCPv6 server is located, Access Router or the Edge Router would relay the DHCPv6 requests. draft-asadullah-v6ops-bb-deployment-scenarios-00.txt [Page 53] INTERNET-DRAFT ISP IPv6 Deployment Scenarios in BB Networks July 2004 C. The Access Router dynamically acquires an address through auto-configuration for the link between itself and the Edge Router. This step is followed by a request using DHCP Prefix Delegation (PD) [RFC3633] for a prefix. In this option, the Access Router would act as a requesting router and Edge Router would act as delegating router. Once prefix is received by the Access Router, it assigns /64 prefixes to each of its interfaces connecting the WLAN Host/Router on customer site. The WLAN Host/Router connected to these interfaces can automatically configure themselves using stateless auto-configuration with /64 prefix. It is easier for the SPs to stay with the DHCP PD and stateless auto-configuration model and point the clients to a central server for DNS/domain information, proxy configurations and others. Using this model the provider could change prefixes on the fly and the Access Router would simply pull the newest prefix based on the valid/preferred lifetime. As mentioned before the prefixes used for subscriber links and the ones delegated via DHCP-PD should be planned in a manner that allows maximum summarization possible at the Edge Router. Other information of interest to the host, such as DNS, is provided through stateful and stateless DHCPv6. 8.1.2.3 Routing The WLAN Host/Router are configured with a default route that points to the Access Router. No routing protocols are needed on these devices which do have limited resources. If the Access Router is owned by an Access Provider, then the Access Router can have a default route, pointing towards the SP's Edge Router. The Edge Router runs the IGP used in the SP network such as OSPFv3 or IS-IS for IPv6. The connected prefixes have to be redistributed. If DHCP-PD is used, with every delegated prefix a static route is installed by the Edge Router. For this reason the static routes must be redistributed. Prefix summarization should be done at the Edge Router. If Access Router is owned by the SP, then Access Router will also run IPv6 IGP and will be part of SP's IPv6 routing domain (OSPFv3 or IS-IS). The connected prefixes have to be redistributed. If DHCP-PD is used, with every delegated prefix a static route is installed by the Access Router. For this reason the static routes must be redistributed. Prefix summarization should be done at the Access Router. draft-asadullah-v6ops-bb-deployment-scenarios-00.txt [Page 54] INTERNET-DRAFT ISP IPv6 Deployment Scenarios in BB Networks July 2004 Depending on the design of the edge portion of the ISP network, some Edge Routers might have to run iBGP for IPv6. In this case it is expected that two peer sessions are established between the Edge Router and a pair of redundant Route Reflectors. 8.1.3 PPP Based Model PPP TERMINATED AGGREGATION (PTA) and L2TP ACCESS AGGREGATION (LAA) models as discussed in sections 7.2.2 and 7.2.3 respectively can also be deployed in IPv6 WLAN environment. 8.1.3.1 PTA Model in IPv6 WLAN Environment While deploying the PTA model in IPv6 WLAN environment the Access Router is Layer3 aware and it has to be upgraded to support IPv6. Since the Access Router terminates the PPP sessions initiated by WLAN Host/Router, it has to support PPPoE with IPv6. Figure 8.1.3.1 describes the PTA Model in IPv6 WLAN environment Customer Premises| Access Provider |Service Provider | | +------+ +--+ +--------------+ +----------+ +------+ |WLAN | ---- | | | | |Underlying| |Edge | |Host/ |-(WLAN)-|AP|-|Access Router |-|Technology|-|Router|=>SP |Router| ---- | | | | | | | | Network +------+ +--+ +--------------+ +----------+ +------+ | <---------------------------> +------+ PPP |AAA | |Server| +------+ Figure 8.1.3.1 8.1.3.1.1 IPv6 Related Infrastructure Changes IPv6 is deployed in this scenario by upgrading the following devices to dual-stack, supporting both IPv4 and IPv6 protocols: - WLAN Host - WLAN Router (if present) - Access Router - Edge Router. draft-asadullah-v6ops-bb-deployment-scenarios-00.txt [Page 55] INTERNET-DRAFT ISP IPv6 Deployment Scenarios in BB Networks July 2004 8.1.3.1.2 Addressing The addressing techniques described in section 7.2.2.2 applys to IPv6 WLAN PTA scenario as well. 8.1.3.1.3 Routing The routing techniques described in section 7.2.2.3 applys to IPv6 WLAN PTA scenario as well. 8.1.3.2 LAA Model in IPv6 WLAN Environment While deploying the LAA model in IPv6 WLAN environment the Access Router is Layer3 aware and it has to be upgraded to support IPv6. The PPP sessions initiated by WLAN Host/Router are forwarded over the L2TP tunnel to the aggregation point in the SP network. The Access must have the capability to support L2TP for IPv6. Figure 8.1.3.2 describes the LAA Model in IPv6 WLAN environment Customer Premises| Access Provider |Service Provider | | +------+ +--+ +--------------+ +----------+ +------+ |WLAN | ---- | | | | |Underlying| |Edge | |Host/ |-(WLAN)-|AP|-|Access Router |-|Technology|-|Router|=>SP |Router| ---- | | | | | | | | Network +------+ +--+ +--------------+ +----------+ +------+ | <-------------------------------------------------->| PPP | <--------------------->| L2TP | +------+ |AAA | |Server| +------+ Figure 8.1.3.2 8.1.3.2.1 IPv6 Related Infrastructure Changes IPv6 is deployed in this scenario by upgrading the following devices to dual-stack, supporting both IPv4 and IPv6 protocols: draft-asadullah-v6ops-bb-deployment-scenarios-00.txt [Page 56] INTERNET-DRAFT ISP IPv6 Deployment Scenarios in BB Networks July 2004 - WLAN Host - WLAN Router (if present) - Access Router - Edge Router. 8.1.3.2.2 Addressing The addressing techniques described in section 7.2.3.2 applys to IPv6 WLAN LAA scenario as well. 8.1.3.2.3 Routing The routing techniques described in section 7.2.3.3 applys to IPv6 WLAN LAA scenario as well. 8.2 IPv6 Multicast The typical multicast services offered are video/audio streaming where the IPv6 WLAN Host joins a multicast group and recieves the content. This type of service model well supported through PIM-SSM which is enabled throughout the SP network. MLDv2 is required for PIM-SSM support. Vendors can choose to implement features that allow routers to map MLDv1 group joins to predefined sources. The IPv6 WLAN Hosts can also join desired multicast groups as long as they are enabled to support MLDv1 or MLDv2. If a WLAN/Access Routers are used then they have to be enabled to support MLDv1 and MLDv2 in order to process the requests of the IPv6 WLAN Hosts. The WLAN/Access Router should also needs to be enabled to support PIM-SSM in order to send PIM joins up to the Edge Router. When enabling this functionality on a WLAN/Access Router, it's limited resources should be taken into consideration. The Edge Router has to be enabled to support MLDv1 and MLDv2 in order to process the requests coming from IPv6 WLAN Host or WLAN/Access Router (if present). The Edge Router has also needs to be enabled for PIM-SSM in order to receive joins from IPv6 WLAN Hosts or WLAN/Access Router (if present) and send joins towards the SP core. MLD authentication, authorization and accounting is usually configured on the Edge Router in order to enable the SP to do billing for the content services provided. draft-asadullah-v6ops-bb-deployment-scenarios-00.txt [Page 57] INTERNET-DRAFT ISP IPv6 Deployment Scenarios in BB Networks July 2004 The IETF draft [IPv6 over 802.11] mentions some of the concerns related to running IPv6 multicast over WLAN links. Potentially these are same kind of issue when running any Layer3 protocol over a WLAN link that has a high loss-to-signal ratio, certain frames that are multicast based are dropped when settings are not adjusted properly. For instance this behavior is similar to IGMP host membership report, when done on a WLAN link with high loss-to-signal ratio and high interference. This problem is inherited to WLAN that can impact both IPv4 and IPv6 multicast packets and not specific to IPv6 multicast. While deploying WLAN (IPv4 or IPv6), one should adjust their broadcast/multicast settings if they are in danger of dropping application dependent frames. These problems are usually caused when AP are placed too far apart (not following the distance limitations), high interference and etc. These issues may impact a real multicast application such as streaming video or basic operation of IPv6 if the frames were dropped. Basic IPv6 communications uses functions such as Duplicate Address Detaction (DAD), Router and Neighbor Solicitations (RS, NS), Router and Neighbor Advertisment (RA, NA) and etc. which could be impacted by the above mentoined issues as these frames are Layer2 Ethernet multicast frames. 8.3 IPv6 QoS The QoS configuration is particularly relevant on the Edge Router in order to manage resources shared amongst multiple subscribers possibly with various service level agreements (SLA). Although, the WLAN Host/Router and Access Router could also be configured for QoS. This includes support for IPv6 classifiers, so that data traffic to/from IPv6 WLAN Host/ Router, Access Router and Edge Router can be classified appropriately into different service flows (SF) and be assigned appropriate priority. Appropriate classification criteria would need to be implemented for IPv6 unicast and multicast traffic. On the Edge Router the subscriber facing interfaces have to be configure to police the inbound customer traffic and shape the traffic outbound to the customer, based on the SLA. Traffic classification and marking should also be done on the Edge router in order to support the various types of customer traffic: data, voice, video. The same IPv4 QoS concepts and methodologies should be applied for the IPv6 as well. draft-asadullah-v6ops-bb-deployment-scenarios-00.txt [Page 58] INTERNET-DRAFT ISP IPv6 Deployment Scenarios in BB Networks July 2004 8.4 IPv6 Security Considerations There are limited changes that have to be done for WLAN Host/ Router in order to enhance security. The Privacy extenssions for autoconfiguration should be used by the hosts. IPv6 firwall functions should be enabled on the WLAN Host/Router if present. The ISP provides security against attacks that come form its own subscribers but it could also implement security services that protect its subscribers from attacks sourced from the outside of its network. Such services do not apply at the access level of the network discussed here. The NAP can stop IPv6 traffic from customer that did not subscribe to the service by using Layer2 filters based on the IPv6 Ethertype (0X86DD). The device that is the Layer3 next hop for the subscribers (Access or Edge Router) should protect the network and the other subscribers against attacks by one of the provider's customers. For this reason uRPF and ACLs should be used on all interfaces facing subscribers. Filtering should be implemented with regard for the operational requirements of IPv6 (ICMPv6 types). Authentication and authorization should be used wherever possible. The Access and the Edge Router should protect their processing resources against floods of valid customer control traffic such as: RS, NS, MLD Requests. Rate limiting should be implemented on all subscriber facing interfaces. The emphasis should be placed on multicast type traffic as it is most often used by the IPv6 control plane. 8.5 IPv6 Network Management Usually ISPs manages the SP Edge Routers and Access Routers using SNMP and AP by means of its configuration tools. The management stations are located in the core SP network. Currently SNMP over IPv6 transport is not supported widely. While supporting for IPv6, IPv4 transport is used to get IPv6 MIBs. 9. Acknowledgements We would like to thank Patrick Grossetete, Toerless Eckert, Madhu Sudan and Shannon McFarland for their valuable comments. draft-asadullah-v6ops-bb-deployment-scenarios-00.txt [Page 59] INTERNET-DRAFT ISP IPv6 Deployment Scenarios in BB Networks July 2004 10. References Normative References [RFC 3513] R. Hinden and S. Deering, "IP Version 6 Addressing Architecture", RFC 3513, April 2003. [RFC3736] Droms, R., "Stateless Dynamic Host Configuration Protocol (DHCP) Service for IPv6", RFC 3736, April 2004. [RFC3315] Droms, R., "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", RFC 3315, July 2003. [RFC2462] Thomson, S. and Narten, T., "IPv6 Stateless Address Autoconfiguration", RFC 2462, December 1998. [RFC3633] Troan, O. and Droms, R., "IPv6 Prefix Options for Dynamic Host Configuration Protocol (DHCP) version 6", RFC 3633, December 2003. [RFC 3041] T. Narten and R. Draves, "Privacy Extensions for Stateless Address Autoconfiguration in IPv6," RFC 3041, April 2001. [RFC2516] Mamakos, L., "A Method for Transmitting PPP Over Ethernet (PPPoE)", RFC 2516, February 1999. [RFC2364] Gross, G., "PPP Over AAL5 (PPPoA)", RFC 2516, July 1998. [RFC2472] Haskin, D. and Allen, E., "IP Version 6 over PPP", RFC 2472, December 1998. [RFC2461] Narten, T., Nordmark, E. and Simpson, W., "Neighbor Discovery for IP Version 6 (IPv6)", RFC 2461, December 1998. [RFC3646] Droms, R., "DNS Configuration options for Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", RFC 3646, December 2003. draft-asadullah-v6ops-bb-deployment-scenarios-00.txt [Page 60] INTERNET-DRAFT ISP IPv6 Deployment Scenarios in BB Networks July 2004 Informative References [Dual Stack Access] Shirasaki, et al., "A Model of IPv6/IPv4 Dual Stack Internet Access Service", draft-shirasaki-dualstack-service-04.txt (work in progress), April 2004. [ISP Networks IPv6 Scenarios] Lind et, al., "Scenarios and Analysis for Introducing IPv6 into ISP Networks", draft-ietf-v6ops-isp-scenarios-analysis-03.txt (work in progress), June 2004. [IPv6 over 802.11] Park, S., "Transmission of IPv6 Packets over 802.11/WLAN Networks", draft-daniel-ipv6-over-wifi-01.txt, (work in progress), July 2004 [ISP Transition Scenarios] Mickels, C., "Transition Scenarios for ISP Networks", draft-mickles-v6ops-isp-cases-05.txt, March 2003 [DOCSIS 2.1 Proposal] Sudan, M., "DOCSIS 2.1 Proposal", May 2004. [RF Interface] Cable Labs, "Radio Frequency Interface Specification SP-RFIv2.0-I02-020617", Jun 2002. Authors Addresses Salman Asadullah Cisco Systems, Inc. 170 West Tasman Drive, San Jose, CA 95134, USA Phone: 408 526 8982 Email: sasad@cisco.com Adeel Ahmed Cisco Systems, Inc. 2200 East President George Bush Turnpike, Richardson, TX 75082, USA Phone: 469 255 4122 Email: adahmed@cisco.com Ciprian Popoviciu Cisco Systems, Inc. 7025-6 Kit Creek Road, Research Triangle Park, NC 27709, USA Phone: 919 392 3723 Email: cpopovic@cisco.com draft-asadullah-v6ops-bb-deployment-scenarios-00.txt [Page 61] INTERNET-DRAFT ISP IPv6 Deployment Scenarios in BB Networks July 2004 Intellectual Property Statement The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology describe in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf- ipr@ietf.org. Disclaimer of Validity This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Copyright Statement Copyright (C) The Internet Society (2004). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society.