diff options
Diffstat (limited to 'doc/rfc/rfc4779.txt')
| -rw-r--r-- | doc/rfc/rfc4779.txt | 4539 |
1 files changed, 4539 insertions, 0 deletions
diff --git a/doc/rfc/rfc4779.txt b/doc/rfc/rfc4779.txt new file mode 100644 index 0000000..26ca32c --- /dev/null +++ b/doc/rfc/rfc4779.txt @@ -0,0 +1,4539 @@ + + + + + + +Network Working Group S. Asadullah +Request for Comments: 4779 A. Ahmed +Category: Informational C. Popoviciu + Cisco Systems + P. Savola + CSC/FUNET + J. Palet + Consulintel + January 2007 + + + ISP IPv6 Deployment Scenarios in Broadband Access Networks + +Status of This Memo + + This memo provides information for the Internet community. It does + not specify an Internet standard of any kind. Distribution of this + memo is unlimited. + +Copyright Notice + + Copyright (C) The IETF Trust (2007). + +Abstract + + This document provides a detailed description of IPv6 deployment and + integration methods and scenarios in today's Service Provider (SP) + Broadband (BB) networks in coexistence with deployed IPv4 services. + Cable/HFC, BB Ethernet, xDSL, and WLAN are the main BB technologies + that are currently deployed, and discussed in this document. The + emerging Broadband Power Line Communications (PLC/BPL) access + technology is also discussed for completeness. In this document we + will discuss main components of IPv6 BB networks, their differences + from IPv4 BB networks, and how IPv6 is deployed and integrated in + each of these networks using tunneling mechanisms and native IPv6. + + + + + + + + + + + + + + + + +Asadullah, et al. Informational [Page 1] + +RFC 4779 ISP IPv6 Deployment Scenarios in BB January 2007 + + +Table of Contents + + 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 + 2. Common Terminology . . . . . . . . . . . . . . . . . . . . . . 5 + 3. Core/Backbone Network . . . . . . . . . . . . . . . . . . . . 5 + 3.1. Layer 2 Access Provider Network . . . . . . . . . . . . . 5 + 3.2. Layer 3 Access Provider Network . . . . . . . . . . . . . 6 + 4. Tunneling Overview . . . . . . . . . . . . . . . . . . . . . . 7 + 4.1. Access over Tunnels - Customers with Public IPv4 + Addresses . . . . . . . . . . . . . . . . . . . . . . . . 7 + 4.2. Access over Tunnels - Customers with Private IPv4 + Addresses . . . . . . . . . . . . . . . . . . . . . . . . 8 + 4.3. Transition a Portion of the IPv4 Infrastructure . . . . . 8 + 5. Broadband Cable Networks . . . . . . . . . . . . . . . . . . . 9 + 5.1. Broadband Cable Network Elements . . . . . . . . . . . . . 9 + 5.2. Deploying IPv6 in Cable Networks . . . . . . . . . . . . . 10 + 5.2.1. Deploying IPv6 in a Bridged CMTS Network . . . . . . . 12 + 5.2.2. Deploying IPv6 in a Routed CMTS Network . . . . . . . 14 + 5.2.3. IPv6 Multicast . . . . . . . . . . . . . . . . . . . . 23 + 5.2.4. IPv6 QoS . . . . . . . . . . . . . . . . . . . . . . . 24 + 5.2.5. IPv6 Security Considerations . . . . . . . . . . . . . 24 + 5.2.6. IPv6 Network Management . . . . . . . . . . . . . . . 25 + 6. Broadband DSL Networks . . . . . . . . . . . . . . . . . . . . 26 + 6.1. DSL Network Elements . . . . . . . . . . . . . . . . . . . 26 + 6.2. Deploying IPv6 in IPv4 DSL Networks . . . . . . . . . . . 28 + 6.2.1. Point-to-Point Model . . . . . . . . . . . . . . . . . 29 + 6.2.2. PPP Terminated Aggregation (PTA) Model . . . . . . . . 30 + 6.2.3. L2TPv2 Access Aggregation (LAA) Model . . . . . . . . 33 + 6.2.4. Hybrid Model for IPv4 and IPv6 Service . . . . . . . . 36 + 6.3. IPv6 Multicast . . . . . . . . . . . . . . . . . . . . . . 38 + 6.3.1. ASM-Based Deployments . . . . . . . . . . . . . . . . 39 + 6.3.2. SSM-Based Deployments . . . . . . . . . . . . . . . . 39 + 6.4. IPv6 QoS . . . . . . . . . . . . . . . . . . . . . . . . . 40 + 6.5. IPv6 Security Considerations . . . . . . . . . . . . . . . 41 + 6.6. IPv6 Network Management . . . . . . . . . . . . . . . . . 42 + 7. Broadband Ethernet Networks . . . . . . . . . . . . . . . . . 42 + 7.1. Ethernet Access Network Elements . . . . . . . . . . . . . 42 + 7.2. Deploying IPv6 in IPv4 Broadband Ethernet Networks . . . . 43 + 7.2.1. Point-to-Point Model . . . . . . . . . . . . . . . . . 44 + 7.2.2. PPP Terminated Aggregation (PTA) Model . . . . . . . . 46 + 7.2.3. L2TPv2 Access Aggregation (LAA) Model . . . . . . . . 48 + 7.2.4. Hybrid Model for IPv4 and IPv6 Service . . . . . . . . 50 + 7.3. IPv6 Multicast . . . . . . . . . . . . . . . . . . . . . . 52 + 7.4. IPv6 QoS . . . . . . . . . . . . . . . . . . . . . . . . . 53 + 7.5. IPv6 Security Considerations . . . . . . . . . . . . . . . 54 + 7.6. IPv6 Network Management . . . . . . . . . . . . . . . . . 55 + + + + + +Asadullah, et al. Informational [Page 2] + +RFC 4779 ISP IPv6 Deployment Scenarios in BB January 2007 + + + 8. Wireless LAN . . . . . . . . . . . . . . . . . . . . . . . . . 55 + 8.1. WLAN Deployment Scenarios . . . . . . . . . . . . . . . . 55 + 8.1.1. Layer 2 NAP with Layer 3 termination at NSP Edge + Router . . . . . . . . . . . . . . . . . . . . . . . . 56 + 8.1.2. Layer 3 Aware NAP with Layer 3 Termination at + Access Router . . . . . . . . . . . . . . . . . . . . 59 + 8.1.3. PPP-Based Model . . . . . . . . . . . . . . . . . . . 61 + 8.2. IPv6 Multicast . . . . . . . . . . . . . . . . . . . . . . 63 + 8.3. IPv6 QoS . . . . . . . . . . . . . . . . . . . . . . . . . 65 + 8.4. IPv6 Security Considerations . . . . . . . . . . . . . . . 65 + 8.5. IPv6 Network Management . . . . . . . . . . . . . . . . . 67 + 9. Broadband Power Line Communications (PLC) . . . . . . . . . . 67 + 9.1. PLC/BPL Access Network Elements . . . . . . . . . . . . . 68 + 9.2. Deploying IPv6 in IPv4 PLC/BPL . . . . . . . . . . . . . . 69 + 9.2.1. IPv6 Related Infrastructure Changes . . . . . . . . . 69 + 9.2.2. Addressing . . . . . . . . . . . . . . . . . . . . . . 69 + 9.2.3. Routing . . . . . . . . . . . . . . . . . . . . . . . 70 + 9.3. IPv6 Multicast . . . . . . . . . . . . . . . . . . . . . . 71 + 9.4. IPv6 QoS . . . . . . . . . . . . . . . . . . . . . . . . . 71 + 9.5. IPv6 Security Considerations . . . . . . . . . . . . . . . 71 + 9.6. IPv6 Network Management . . . . . . . . . . . . . . . . . 71 + 10. Gap Analysis . . . . . . . . . . . . . . . . . . . . . . . . . 71 + 11. Security Considerations . . . . . . . . . . . . . . . . . . . 74 + 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 74 + 13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 74 + 13.1. Normative References . . . . . . . . . . . . . . . . . . . 74 + 13.2. Informative References . . . . . . . . . . . . . . . . . . 76 + + + + + + + + + + + + + + + + + + + + + + + + +Asadullah, et al. Informational [Page 3] + +RFC 4779 ISP IPv6 Deployment Scenarios in BB January 2007 + + +1. Introduction + + This document presents the options available in deploying IPv6 + services in the access portion of a BB Service Provider (SP) network + - namely Cable/HFC, BB Ethernet, xDSL, WLAN, and PLC/BPL. + + This document briefly discusses the other elements of a provider + network as well. It provides different viable IPv6 deployment and + integration techniques, and models for each of the above-mentioned BB + technologies individually. The example list is not exhaustive, but + it tries to be representative. + + This document analyzes how all the important components of current + IPv4-based Cable/HFC, BB Ethernet, xDSL, WLAN, and PLC/BPL networks + will behave when IPv6 is integrated and deployed. + + The following important pieces are discussed: + + A. Available tunneling options + + B. Devices that would have to be upgraded to support IPv6 + + C. Available IPv6 address assignment techniques and their use + + D. Possible IPv6 Routing options and their use + + E. IPv6 unicast and multicast packet transmission + + F. Required IPv6 Quality of Service (QoS) parameters + + G. Required IPv6 Security parameters + + H. Required IPv6 Network Management parameters + + It is important to note that the addressing rules provided throughout + this document represent an example that follows the current + assignment policies and recommendations of the registries. However, + they can be adapted to the network and business model needs of the + ISPs. + + The scope of the document is to advise on the ways of upgrading an + existing infrastructure to support IPv6 services. The recommendation + to upgrade a device to dual stack does not stop an SP from adding a + new device to its network to perform the necessary IPv6 functions + discussed. The costs involved with such an approach could be offset + by lower impact on the existing IPv4 services. + + + + + +Asadullah, et al. Informational [Page 4] + +RFC 4779 ISP IPv6 Deployment Scenarios in BB January 2007 + + +2. Common Terminology + + BB: Broadband + + CPE: Customer Premise Equipment + + GWR: Gateway Router + + ISP: Internet Service Provider + + NAP: Network Access Provider + + NSP: Network Service Provider + + QoS: Quality of Service + + SP: Service Provider + +3. Core/Backbone Network + + This section intends to briefly discuss some important elements of a + provider network tied to the deployment of IPv6. A more detailed + description of the core network is provided in other documents + [RFC4029]. + + There are two types of networks identified in the Broadband + deployments: + + A. Access Provider Network: This network provides the broadband + access and aggregates the subscribers. The subscriber traffic is + handed over to the Service Provider at Layer 2 or 3. + + B. Service Provider Network: This network provides Intranet and + Internet IP connectivity for the subscribers. + + The Service Provider network structure beyond the Edge Routers that + interface with the Access provider is beyond the scope of this + document. + +3.1. Layer 2 Access Provider Network + + The Access Provider can deploy a Layer 2 network and perform no + routing of the subscriber traffic to the SP. The devices that + support each specific access technology are aggregated into a highly + redundant, resilient, and scalable Layer 2 core. The network core + can involve various technologies such as Ethernet, Asynchronous + Transfer Mode (ATM), etc. The Service Provider Edge Router connects + to the Access Provider core. + + + +Asadullah, et al. Informational [Page 5] + +RFC 4779 ISP IPv6 Deployment Scenarios in BB January 2007 + + + This type of network may be transparent to the Layer 3 protocol. + Some possible changes may come with the intent of supporting IPv6 + provisioning mechanisms, as well as filtering and monitoring IPv6 + traffic based on Layer 2 information such as IPv6 Ether Type Protocol + ID (0x86DD) or IPv6 multicast specific Media Access Control (MAC) + addresses (33:33:xx:xx:xx:xx). + +3.2. Layer 3 Access Provider Network + + The Access Provider can choose to terminate the Layer 2 domain and + route the IP traffic to the Service Provider network. Access Routers + are used to aggregate the subscriber traffic and route it over a + Layer 3 core to the SP Edge Routers. In this case, the impact of the + IPv6 deployment is significant. + + The case studies in this document discuss only the relevant network + elements of such a network: Customer Premise Equipment, Access + Router, and Edge Router. In real networks, the link between the + Access Router and the Edge Router involves other routers that are + part of the aggregation and the core layer of the Access Provider + network. + + The Access Provider can forward the IPv6 traffic through its Layer 3 + core in three possible ways: + + A. IPv6 Tunneling: As a temporary solution, the Access Provider can + choose to use a tunneling mechanism to forward the subscriber + IPv6 traffic to the Service Provider Edge Router. This approach + has the least impact on the Access Provider network; however, as + the number of users increase and the amount of IPv6 traffic + grows, the ISP will have to evolve to one of the scenarios listed + below. + + B. Native IPv6 Deployment: The Access Provider routers are upgraded + to support IPv6 and can become dual stack. In a dual-stack + network, an IPv6 Interior Gateway Protocol (IGP), such as OSPFv3 + [RFC2740] or IS-IS [ISISv6], is enabled. RFC 4029 [RFC4029] + discusses the IGP selection options with their benefits and + drawbacks. + + C. MPLS 6PE Deployment [6PE]: If the Access Provider is running MPLS + in its IPv4 core, it could use 6PE to forward IPv6 traffic over + it. In this case, only a subset of routers close to the edge of + the network need to be IPv6 aware. With this approach, BGP + becomes important in order to support 6PE. + + The 6PE approach has the advantage of having minimal impact on the + Access Provider network. Fewer devices need to be upgraded and + + + +Asadullah, et al. Informational [Page 6] + +RFC 4779 ISP IPv6 Deployment Scenarios in BB January 2007 + + + configured while the MPLS core continues to switch the traffic, + unaware that it transports both IPv4 and IPv6. 6PE should be + leveraged only if MPLS is already deployed in the network. At the + time of writing this document, a major disadvantage of the 6PE + solution is that it does not support multicast IPv6 traffic. + + The native approach has the advantage of supporting IPv6 multicast + traffic, but it may imply a significant impact on the IPv4 + operational network in terms of software configuration and possibly + hardware upgrade. + + More detailed Core Network deployment recommendations are discussed + in other documents [RFC4029]. The handling of IPv6 traffic in the + Core of the Access Provider Network will not be discussed for the + remainder of this document. + +4. Tunneling Overview + + If SPs are not able to deploy native IPv6, they might use tunneling- + based transition mechanisms to start an IPv6 service offering, and + move to native IPv6 deployment at a later time. + + Several tunneling mechanisms were developed specifically to transport + IPv6 over existing IPv4 infrastructures. Several of them have been + standardized and their use depends on the existing SP IPv4 network + and the structure of the IPv6 service. The requirements for the most + appropriate mechanisms are described in [v6tc] with more updates to + follow. Deploying IPv6 using tunneling techniques can imply as + little changes to the network as upgrading software on tunnel end + points. A Service Provider could use tunneling to deploy IPv6 in the + following scenarios: + +4.1. Access over Tunnels - Customers with Public IPv4 Addresses + + If the customer is a residential user, it can initiate the tunnel + directly from the IPv6 capable host to a tunnel termination router + located in the NAP or ISP network. The tunnel type used should be + decided by the SP, but it should take into consideration its + availability on commonly used software running on the host machine. + Of the many tunneling mechanisms developed, such as IPv6 Tunnel + Broker [RFC3053], Connection of IPv6 Domains via IPv4 Clouds + [RFC3056], Generic Packet Tunneling in IPv6 [RFC2473], ISATAP + [RFC4214], Basic Transition Mechanisms for IPv6 Hosts and Routers + [RFC4213], and Transmission of IPv6 over IPv4 Domains without + Explicit Tunnels [RFC2529], some are more popular than the others. + At the time of writing this document, the IETF Softwire Working Group + was tasked with standardizing a single tunneling protocol [Softwire] + for this application. + + + +Asadullah, et al. Informational [Page 7] + +RFC 4779 ISP IPv6 Deployment Scenarios in BB January 2007 + + + If the end customer has a GWR installed, then it could be used to + originate the tunnel, thus offering native IPv6 access to multiple + hosts on the customer network. In this case, the GWR would need to + be upgraded to dual stack in order to support IPv6. The GWR can be + owned by the customer or by the SP. + +4.2. Access over Tunnels - Customers with Private IPv4 Addresses + + If the end customer receives a private IPv4 address and needs to + initiate a tunnel through Network Address Translation (NAT), + techniques like 6to4 may not work since they rely on public IPv4 + address. In this case, unless the existing GWRs support protocol-41- + forwarding [Protocol41], the end user might have to use tunnels that + can operate through NATs (such as Teredo [RFC4380]). Most GWRs + support protocol-41-forwarding, which means that hosts can initiate + the tunnels - in which case the GWR is not affected by the IPv6 + service. + + The customer has the option to initiate the tunnel from the device + (GWR) that performs the NAT functionality, similar to the GWR + scenario discussed in Section 4.1. This will imply hardware + replacement or software upgrade and a native IPv6 environment behind + the GWR. + + It is also worth observing that initiating an IPv6 tunnel over IPv4 + through already established IPv4 IPsec sessions would provide a + certain level of security to the IPv6 traffic. + +4.3. Transition a Portion of the IPv4 Infrastructure + + Tunnels can be used to transport the IPv6 traffic across a defined + segment of the network. As an example, the customer might connect + natively to the Network Access Provider, where a tunnel is used to + transit the traffic over IPv4 to the ISP. In this case, the tunnel + choice depends on its capabilities (for example, whether or not it + supports multicast), routing protocols used (there are several types + that can transport Layer 2 messages, such as GRE [RFC2784], L2TPv3 + [RFC3931], or pseudowire), manageability, and scalability (dynamic + versus static tunnels). + + This scenario implies that the access portion of the network has been + upgraded to support dual stack, so the savings provided by tunneling + in this scenario are very small compared with the previous two + scenarios. Depending on the number of sites requiring the service, + and considering the expenses required to manage the tunnels (some + tunnels are static while others are dynamic [DynamicTunnel]) in this + case, the SPs might find the native approach worth the additional + investments. + + + +Asadullah, et al. Informational [Page 8] + +RFC 4779 ISP IPv6 Deployment Scenarios in BB January 2007 + + + In all the scenarios listed above, the tunnel selection process + should consider the IPv6 multicast forwarding capabilities if such + service is planned. As an example, 6to4 tunnels do not support IPv6 + multicast traffic. + + The operation, capabilities, and deployment of various tunnel types + have been discussed extensively in the documents referenced earlier + as well as in [RFC4213] and [RFC3904]. Details of a tunnel-based + deployment are offered in the next section of this document, which + discusses the case of Cable Access, where the current Data Over Cable + Service Interface Specification (DOCSIS 2.0) [RF-Interface] and prior + specifications do not provide support for native IPv6 access. + Although Sections 6, 7, 8, and 9 focus on a native IPv6 deployments + over DSL, Fiber to the Home (FTTH), wireless, and PLC/BPL and because + this approach is fully supported today, tunnel-based solutions are + also possible in these cases based on the guidelines of this section + and some of the recommendations provided in Section 5. + +5. Broadband Cable Networks + + This section describes the infrastructure that exists today in cable + networks providing BB services to the home. It also describes IPv6 + deployment options in these cable networks. + + DOCSIS standardizes and documents the operation of data over cable + networks. DOCSIS 2.0 and prior specifications have limitations that + do not allow for a smooth implementation of native IPv6 transport. + Some of these limitations are discussed in this section. For this + reason, the IPv6 deployment scenarios discussed in this section for + the existing cable networks are tunnel based. The tunneling examples + presented here could also be applied to the other BB technologies + described in Sections 6, 7, 8, and 9. + +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 Voice over IP + (VoIP) services. The mechanism for 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) + + + +Asadullah, et al. Informational [Page 9] + +RFC 4779 ISP IPv6 Deployment Scenarios in BB January 2007 + + + 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 + + MSO: Multiple Service Operator + + Data Over Cable Service Interface Specification (DOCSIS): 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 + +5.2. Deploying IPv6 in Cable Networks + + One of the motivators for an MSO to deploy IPv6 over its cable + network is to ease management burdens. IPv6 can be enabled on the + CM, CMTS, and ER for management purposes. Currently portions of the + cable infrastructure use IPv4 address space [RFC1918]; however, there + is a finite number of those. Thus, IPv6 could have utility in the + cable space implemented on the management plane initially and focused + + + +Asadullah, et al. Informational [Page 10] + +RFC 4779 ISP IPv6 Deployment Scenarios in BB January 2007 + + + on the data plane for end-user services later. For more details on + using IPv6 for management in cable networks, please refer to Section + 5.6.1. + + There are two different deployment modes in current 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 a certain degree of 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 current + routed and bridged cable networks include: + + A. Changes need to be made to the DOCSIS specification + [RF-Interface] to include support for IPv6 on the CM and CMTS. + This is imperative for deploying native IPv6 over cable networks. + + B. Problems with IPv6 Neighbor Discovery (ND) on CM and CMTS. In + IPv4, these devices rely on Internet Group Multicast Protocol + (IGMP) join messages to track membership of hosts that are part + of a particular IP multicast group. In order to support ND, a + multicast-based process, the CM and CMTS will need to support + IGMPv3/Multicast Listener Discovery Version 2 (MLDv2) or v1 + snooping. + + C. 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. Service providers that wish to deploy QoS mechanisms + also have to support classification of IPv6 traffic. + + Due to the above mentioned limitations in deployed cable networks, at + the time of writing this document, the only option available for + cable operators is to use tunneling techniques in order to transport + IPv6 traffic over their current IPv4 infrastructure. The following + + + +Asadullah, et al. Informational [Page 11] + +RFC 4779 ISP IPv6 Deployment Scenarios in BB January 2007 + + + sections will cover tunneling and native IPv6 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 act 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 act as 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. + + IPv6 can be deployed in a bridged CMTS network either natively or via + tunneling. This section discusses the native deployment model. The + tunneling model is similar to ones described in Sections 5.2.2.1 and + 5.2.2.2. + + Figure 5.2.1 illustrates 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 + + + + + + + + + +Asadullah, et al. Informational [Page 12] + +RFC 4779 ISP IPv6 Deployment Scenarios in BB January 2007 + + +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 currently deployed + 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 Dynamic + Host Configuration Protocol (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, the host behind the CM will + get a /64 prefix via stateless auto-configuration or DHCPv6. + + If using stateless auto-configuration, the host listens for routing + advertisements (RAs) from the ER. The RAs contain the /64 prefix + assigned to the segment. 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 (64-bit Extended Unique + Identifier) 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 (Prefix + Delegation) for a prefix shorter than /64, typically /48 [RFC3177], + which in turn is divided into /64s and assigned to its downstream + interfaces connecting to the hosts. + + + +Asadullah, et al. Informational [Page 13] + +RFC 4779 ISP IPv6 Deployment Scenarios in BB January 2007 + + +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 CM and CMTS must forward Neighbor Discovery (ND) packets + between ER and the hosts attached to the CM. + + Communication between hosts behind different CMs is always forwarded + through the CMTS. IPv6 communication between the different sites + relies on multicast IPv6 ND [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 or v1 + snooping. MLD is almost 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 (Source-Specific Multicast) + service models. Implementation work on CM/CMTS should be minimal + because the only significant difference between IPv4 IGMPv3 and IPv6 + MLDv2 is 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 generally + 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. + +5.2.2. Deploying IPv6 in a Routed CMTS Network + + In an IPv4/IPv6 routed CMTS network, the CM still acts as a Layer 2 + device and bridges all data traffic between its Ethernet interface + and cable interface connected to the cable operator 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, the CMTS/ER will need to either tunnel IPv6 + traffic or natively support IPv6. + + + + +Asadullah, et al. Informational [Page 14] + +RFC 4779 ISP IPv6 Deployment Scenarios in BB January 2007 + + + There are 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 site. + + 3. Dual-stacked Cable (HFC) Network, CM, and CMTS Support IPv6 + + In this scenario, the CMTS is upgraded to dual stack to support IPv4 + and IPv6. Since the CMTS supports IPv6, it can act 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 hardware and software upgrades to support IPv6. + + 4. Dual-stacked Cable (HFC) Network, Standalone GWR, and CMTS + Support IPv6 + + In this scenario there is a stand-alone 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 + hardware and software changes on the GWR and CMTS. + + 5. Dual-stacked Cable (HFC) Network, Embedded 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 + need to be upgraded to a dual-stack device. This scenario is also + difficult to deploy in existing cable network since it requires + changes on the Embedded GWR/CM and the CMTS. + + The DOCSIS specification will also need to be modified to allow + native IPv6 support on the Embedded GWR/CM. + + + + + +Asadullah, et al. Informational [Page 15] + +RFC 4779 ISP IPv6 Deployment Scenarios in BB January 2007 + + +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 + +-----------+ +------+ +--------+ + _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ + ()_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _() + IPv6-in-IPv4 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 the + customer site is the host. Host address assignment can be done in + multiple ways. Depending on the tunneling mechanism used, it could + be automatic or might require manual configuration. + + The host still receives an IPv4 address using DHCPv4, which works the + same way in currently deployed cable networks. In order to get IPv6 + connectivity, host devices will also need an IPv6 address and a means + to communicate with the ER. + + + + + + + + + +Asadullah, et al. Informational [Page 16] + +RFC 4779 ISP IPv6 Deployment Scenarios in BB January 2007 + + +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 IPv4 network, + the host and the ER will need to use one of the available IPv6 in + IPv4 tunneling mechanisms. + + The host will use its 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 terminate the tunnel + and/or provide other IPv6 services. + +5.2.2.1.4. Routing + + Routing configuration on the host will vary depending on the + tunneling technique used. In some cases, a default or static route + might be needed to forward traffic to the next hop. + + The ER runs an IGP such as OSPFv3 or ISIS. + +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 between the host and the ER, the cable + network, including the CM and CMTS, does not need to support IPv6, + and can remain as IPv4 devices. + + Figure 5.2.2.2 illustrates this deployment scenario. + + +-----+ + |Host | + +--+--+ + | +-----------+ +------+ +--------+ + +---+---+ +-------+ | Cable | | | | Edge | + | GWR |--| CM |----| (HFC) |---| CMTS |---| |=>ISP + +-------+ +-------+ | Network | | | | Router |Network + +-----------+ +------+ +--------+ + _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ + ()_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _() + IPv6-in-IPv4 tunnel + + |---------||--------------------------------------||-------------| + IPv4/v6 IPv4 only IPv4/v6 + + Figure 5.2.2.2 + + + + +Asadullah, et al. Informational [Page 17] + +RFC 4779 ISP IPv6 Deployment Scenarios in BB January 2007 + + +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 need to be assigned an IPv6 address at customer + site are the host and GWR. IPv6 address assignment can be done + statically at the GWR downstream interface. The GWR will send out RA + messages 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 [RFC3177] prefix from the ER. This + /48 prefix will be used to configure /64s on hosts connected to the + GWR downstream interfaces. The uplink to the ISP network is + configured with a /64 prefix as well. + + The GWR still receives a global IPv4 address on its upstream + interface using DHCPv4, which works the same way in currently + deployed 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 IPv4 network, the GWR and the ER will + need to use one of the available IPv6 in IPv4 tunneling mechanisms. + All IPv6 traffic will need to go through the tunnel, once it comes + up. + + The GWR will use its IPv4 address to source the tunnel to the ER. + The tunnel endpoint will be the IPv4 address of 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. 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 + + Depending on the tunneling technique used, additional configuration + might be needed on the GWR and the ER. If the ER is also providing a + 6to4 relay service then a default route will need to be added to the + GWR pointing to the ER, for all non-6to4 traffic. + + + +Asadullah, et al. Informational [Page 18] + +RFC 4779 ISP IPv6 Deployment Scenarios in BB January 2007 + + + If using manual tunneling, the GWR and ER can use static routing or + an IGP such as RIPng [RFC2080]. The RIPng updates can be transported + over a manual tunnel, which does not work when using 6to4 tunneling + since it does not support multicast. + + Customer routes can be carried to the ER using RIPng 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 ER for each delegated /48 prefix. The + static routes need to be redistributed into the IGP at the ER, so + there is no need for a routing protocol between the ER and the GWR. + + The ER runs an IGP such as OSPFv3 or ISIS. + +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 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 or v1 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. + + + + + + +Asadullah, et al. Informational [Page 19] + +RFC 4779 ISP IPv6 Deployment Scenarios in BB January 2007 + + +5.2.2.3.2. Addressing + + In cable networks today, 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. 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 + stateless auto-configuration. If the CM uses an IPv4 address for + management, it will use DHCPv4 for its 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 or stateless + auto-configuration. With DHCPv6, the CMTS may need to act as a + DHCPv6 relay agent and forward DHCP messages between the hosts and + the DHCP server. With stateless auto-configuration, 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 currently deployed + 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 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 + IS-IS. + + + + + +Asadullah, et al. Informational [Page 20] + +RFC 4779 ISP IPv6 Deployment Scenarios in BB January 2007 + + +5.2.2.4. Dual-Stacked Cable (HFC) Network, Stand-Alone GWR, and CMTS + Support IPv6 + + In this case, the cable operator can offer IPv6 services to its + 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 act as an + ER as well. The CM will act as a bridge for forwarding data traffic + and does not need to support IPv6. + + This scenario is similar to the case described in Section 5.2.2.2. + The only difference in this case is that the ER functionality exists + on the CMTS instead of on a separate router in the cable operator + network. + + Figure 5.2.2.4 illustrates this deployment scenario. + + + +-----------+ +-----------+ + +------+ +-------+ +-------+ | Cable | |CMTS / Edge| + | Host |--| GWR |--| CM |---| (HFC) |---| |=>ISP + +------+ +-------+ +-------+ | Network | | Router |Network + +-----------+ +-----------+ + _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ + ()_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _() + IPv6-in-IPv4 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 existing cable networks. The CMTS will act as + a 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. + + + + + +Asadullah, et al. Informational [Page 21] + +RFC 4779 ISP IPv6 Deployment Scenarios in BB January 2007 + + +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 IS-IS. + +5.2.2.5. Dual-Stacked Cable (HFC) Network, Embedded GWR/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 CM/Embedded + GWR and CMTS, supports IPv6. The ER functionality can be included in + the CMTS or it can exist on a separate router connected to the CMTS + upstream interface. The CM/Embedded 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 be 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 embedded 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. + + + +Asadullah, et al. Informational [Page 22] + +RFC 4779 ISP IPv6 Deployment Scenarios in BB January 2007 + + + If using DHCPv6, the CMTS will need to act as a DHCPv6 relay agent. + The host and CM/GWR will receive IPv6 addresses from pools of /64 + prefixes configured on the DHCPv6 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 the same management /64 prefix. The + hosts connected to the same cable interface on the CMTS may belong to + different /64 customer prefixes, as the CMTS may have multiple /64 + prefixes configured under its cable interfaces. + + It is also possible to use DHCP-PD for an IPv6 address assignment. + In this case, the CM/GWR will use stateless auto-configuration to + assign an IPv6 address to its upstream interface using the /64 prefix + sent by the CMTS/ER in an RA message. Once the CM/GWR assigns an + IPv6 address to its upstream interface, it will request a /48 + [RFC3177] prefix from the CMTS/ER and chop this /48 prefix into /64s + for assigning IPv6 addresses to hosts. The uplink to the ISP network + is configured with a /64 prefix as well. + +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 default route pointing to the CMTS/ER or + it can run a routing protocol such as RIPng 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 + IS-IS. + +5.2.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 + or v1 snooping. MLD is almost identical to IGMP in IPv4, only the + + + +Asadullah, et al. Informational [Page 23] + +RFC 4779 ISP IPv6 Deployment Scenarios in BB January 2007 + + + name and numbers are changed. MLDv2 is almost identical to IGMPv3 + and also supports ASM (Any-Source Multicast) and SSM (Source-Specific + Multicast) service models. + + SSM is more suited for deployments where the SP intends to provide + paid content to the users (video or audio). These types of services + are expected to be of primary interest. Moreover, the simplicity of + the SSM model often overrides the scalability issues that would be + resolved in an ASM model. ASM is, however, an option that is + discussed in Section 6.3.1. The Layer 3 CM, GWR, and Layer 3 routed + CMTS/ER will need to be enabled with PIM-SSM, which requires the + definition and support for IGMPv3/MLDv1 or v2 snooping, in order to + track join/leave messages from the hosts. Another option would be + for the Layer 3 CM or GWR to support MLD proxy routing. The Layer 3 + next hop for the hosts needs to support MLD. + + Refer to Section 6.3 for more IPv6 multicast details. + +5.2.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. + + 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, and video. The + same IPv4 QoS concepts and methodologies should be applied for IPv6 + as well. + + It is important to note that when traffic is encrypted end-to-end, + the traversed network devices will not have access to many of the + packet fields used for classification purposes. In these cases, + routers will most likely place the packets in the default classes. + The QoS design should take into consideration this scenario and try + to use mainly IP header fields for classification purposes. + +5.2.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, + + + + +Asadullah, et al. Informational [Page 24] + +RFC 4779 ISP IPv6 Deployment Scenarios in BB January 2007 + + + appropriate enhancements will be needed in the DOCSIS specification + to support encrypted IPv6 multicast. + + There are limited changes that have to be done for hosts in order to + enhance security. The privacy extensions [RFC3041] for auto- + configuration should be used by the hosts. IPv6 firewall functions + could be enabled, if available on the host or GWR. + + The ISP provides security against attacks that come from 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 Unicast + Reverse Path Forwarding (uRPF) [RFC3704] and Access Control Lists + (ACLs) should be used on all interfaces facing subscribers. + Filtering should be implemented with regard for the operational + requirements of IPv6 [IPv6-Security]. + + The CMTS/ER should protect its processing resources against floods of + valid customer control traffic such as: Router and Neighbor + Solicitations, and MLD Requests. + + All other security features used with the IPv4 service should be + similarly applied to IPv6 as well. + +5.2.6. IPv6 Network Management + + IPv6 can have many applications in cable networks. MSOs can + initially implement IPv6 on the control plane and use it to manage + the thousands of devices connected to the CMTS. This would be a good + way to introduce IPv6 in a cable network. Later, the MSO can extend + IPv6 to the data plane and use it to carry customer traffic as well + as management traffic. + +5.2.6.1. Using IPv6 for Management in Cable Networks + + IPv6 can be enabled in a cable network for management of devices like + CM, CMTS, and ER. With the rollout of advanced services like VoIP + and Video-over-IP, MSOs are looking for ways to manage the large + number of devices connected to the CMTS. In IPv4, an RFC1918 address + is assigned to these devices for management purposes. Since there is + a finite number of RFC1918 addresses available, it is becoming + difficult for MSOs to manage these devices. + + + + + +Asadullah, et al. Informational [Page 25] + +RFC 4779 ISP IPv6 Deployment Scenarios in BB January 2007 + + + By using IPv6 for management purposes, MSOs can scale their network + management systems to meet their needs. The CMTS/ER can be + configured with a /64 management prefix that is shared among all CMs + connected to the CMTS cable interface. Addressing for the CMs can be + done via stateless auto-configuration or DHCPv6. Once the CMs + receive a /64 prefix, they can configure themselves with an IPv6 + address. + + If there are devices behind the CM that need to be managed by the + MSO, another /64 prefix can be defined on the CMTS/ER. These devices + can also use stateless auto-configuration to assign themselves an + IPv6 address. + + Traffic sourced from or destined to the management prefix should not + cross the MSO's network boundaries. + + In this scenario, IPv6 will only be used for managing devices on the + cable network. The CM will no longer require an IPv4 address for + management as described in DOCSIS 3.0 [DOCSIS3.0-Reqs]. + +5.2.6.2. Updates to MIB Modules/Standards to Support IPv6 + + The current DOCSIS, PacketCable, and CableHome MIB modules are + already designed to support IPv6 objects. In this case, IPv6 will + neither add nor change any of the functionality of these MIB modules. + The Textual Convention used to represent Structure of Management + Information Version 2 (SMIv2) objects representing IP addresses was + updated [RFC4001] and a new Textual Convention InetAddressType was + added to identify the type of the IP address used for IP address + objects in MIB modules. + + There are some exceptions; the MIB modules that might need to add + IPv6 support are defined in the DOCSIS 3.0 OSSI specification + [DOCSIS3.0-OSSI]. + +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 Premise Equipment and the DSL Access Multiplexer (DSLAM). + + + + +Asadullah, et al. Informational [Page 26] + +RFC 4779 ISP IPv6 Deployment Scenarios in BB January 2007 + + + The following network elements are typical of a DSL network: + + DSL Modem: It can be a stand-alone device, be incorporated in the + host, incorporate router functionalities, and also have the + capability to act as a CPE router. + + Customer Premise Router (CPR): It is used to provide Layer 3 services + for customer premise networks. It is usually used to provide + firewalling functions and segment broadcast domains for a small + business. + + DSL Access Multiplexer (DSLAM): It terminates multiple twisted-pair + telephone lines and provides aggregation to BRAS. + + Broadband Remote Access Server (BRAS): It aggregates or terminates + multiple Permanent Virtual Circuits (PVCs) corresponding 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 Premise | 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 + + + + + + + + + +Asadullah, et al. Informational [Page 27] + +RFC 4779 ISP IPv6 Deployment Scenarios in BB January 2007 + + +6.2. Deploying IPv6 in IPv4 DSL Networks + + There are three 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 not terminated as close as possible to the DSLAM (at + the BRAS). In this case, a large number of Layer 2 circuits has + to be maintained over a significant portion of the network. The + Layer 2 domains can be terminated at the ER in three ways: + + A. In a common bridge group with a virtual interface that routes + traffic out. + + B. By enabling a Routed Bridged Encapsulation feature, all users + could be part of the same subnet. This is the most common + deployment approach of IPv4 over DSL but it might not be the + best choice in IPv6 where address availability is not an + issue. + + C. By terminating the PVC at Layer 3, each PVC has its own + prefix. This is the approach that seems more suitable for + IPv6 and is presented in Section 6.2.1. + + None of these ways requires that the CPE (DSL modem) be + upgraded. + + 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. Layer 2 Tunneling Protocol (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 L2TPv2 [RFC2661] 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 existing revenue generating IPv4 services, the + IPv6 deployment will match the IPv4 one. This approach is presented + + + +Asadullah, et al. Informational [Page 28] + +RFC 4779 ISP IPv6 Deployment Scenarios in BB January 2007 + + + in Sections 6.2.1 - 6.2.3 that describe current IPv4 over DSL + broadband 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 Section + 6.2.4. + +6.2.1. Point-to-Point Model + + In this scenario, the Ethernet frames from the Host or the Customer + Premise Router are bridged over the PVC assigned to the subscriber. + + Figure 6.2.1 describes the protocol architecture of this model. + + + Customer Premise NAP NSP + |-------------------------| |---------------| |------------------| + +-----+ +-------+ +-----+ +--------+ +----------+ + |Hosts|--+Router +--+ DSL +--+ DSLAM +--------+ Edge | ISP + +-----+ +-------+ |Modem| +--------+ | Router +=>Network + +-----+ +----------+ + |----------------------------| + ATM + + Figure 6.2.1 + +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 (if + present), 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 subscriber PVC. The hosts can use stateless + auto-configuration or stateful DHCPv6-based configuration to acquire + an address via the Edge Router. + + However, as manual configuration for each customer is a provisioning + challenge, implementers are encouraged to develop mechanism(s) that + automatically map the PVC (or some other customer-specific + information) to an IPv6 subnet prefix, and advertise the customer- + specific prefix to all the customers with minimal configuration. + + + +Asadullah, et al. Informational [Page 29] + +RFC 4779 ISP IPv6 Deployment Scenarios in BB January 2007 + + + If a Customer Router is present: + + A. 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. + + B. It can use its link-local address to communicate with the ER. It + can also dynamically acquire, through stateless auto- + configuration, the prefix for the link between itself and the ER. + The later option allows it to contact a remote DHCPv6 server, if + needed. This step is followed by a request via DHCP-PD for a + prefix shorter than /64 that, in turn, is divided in /64s and + assigned to its downstream interfaces. + + The Edge Router has a /64 prefix configured for each subscriber PVC. + Each PVC should be enabled to relay DHCPv6 requests from the + subscribers to DHCPv6 servers in the ISP network. The PVCs 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 manner 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 [RFC3315] and stateless DHCPv6 [RFC3736]. + +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 generally 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. + +6.2.2. PPP Terminated Aggregation (PTA) Model + + The PTA architecture relies on PPP-based protocols (PPPoA [RFC2364] + and PPPoE [RFC2516]). The PPP sessions are initiated by Customer + Premise Equipment and are terminated at the BRAS. The BRAS + + + +Asadullah, et al. Informational [Page 30] + +RFC 4779 ISP IPv6 Deployment Scenarios in BB January 2007 + + + 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. + + When the NSP is also the NAP, the BRAS and NSP Edge Router could be + the same piece of equipment and provide the above mentioned + functionality. + + There are two types of PPP encapsulations that can be leveraged with + this model: + + A. Connection using PPPoA + + Customer Premise NAP NSP + |--------------------| |----------------------| |----------------| + +-----------+ + | AAA | + +-------+ Radius | + | | TACACS | + | +-----------+ + +-----+ +-------+ +--------+ +----+-----+ +-----------+ + |Hosts|--+Router +------+ DSLAM +-+ BRAS +-+ Edge | + +-----+ +-------+ +--------+ +----------+ | Router +=>Core + |--------------------------| +-----------+ + PPP + + Figure 6.2.2.1 + + 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; this information is + acquired 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. + + + + + + + + + + + + + + +Asadullah, et al. Informational [Page 31] + +RFC 4779 ISP IPv6 Deployment Scenarios in BB January 2007 + + + B. Connection using PPPoE + + Customer Premise NAP NSP + |--------------------------| |-------------------| |---------------| + +-----------+ + | AAA | + +-------+ Radius | + | | TACACS | + | +-----------+ + | + +-----+ +-------+ +--------+ +-----+----+ +-----------+ + |Hosts|--+Router +-----------+ 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 sessions 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 due to additional headers. + + The network design and operation of the PTA model is the same, + regardless of the PPP encapsulation type used. + +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 (if present), 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 an Authentication, Authorization, and + Accounting (AAA) server. The Hosts or the Customer Routers have the + BRAS as their Layer 3 next hop. + + + + + + +Asadullah, et al. Informational [Page 32] + +RFC 4779 ISP IPv6 Deployment Scenarios in BB January 2007 + + + The PPP session can be initiated by a host or by a Customer Router. + In the latter 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 acquire prefixes for the Customer Router other 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 /64 prefixes configured on the link to the Edge router. + The Edge Router links are also configured with /64 prefixes to + provide connectivity to the rest of the ISP network. + + The prefixes used for subscribers and the ones delegated via DHCP-PD + should be planned in a manner that allows maximum summarization at + the BRAS. + + Other information of interest to the host, such as DNS, is provided + through stateful [RFC3315] and stateless [RFC3736] 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 generally 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 recommended if they are managed independently. + Controlled redistribution will be needed between the Access Provider + IGP and the ISP IGP. + +6.2.3. L2TPv2 Access Aggregation (LAA) Model + + In the LAA model, the BRAS forwards the CPE initiated session to the + ISP over an L2TPv2 tunnel established between the BRAS and the Edge + Router. In this case, the authentication, authorization, and + subscriber configuration are performed by the ISP itself. There are + two types of PPP encapsulations that can be leveraged with this + model: + + + +Asadullah, et al. Informational [Page 33] + +RFC 4779 ISP IPv6 Deployment Scenarios in BB January 2007 + + + A. Connection via PPPoA + + Customer Premise NAP NSP + |--------------------| |----------------------| |----------------| + +-----------+ + | AAA | + +-------+ Radius | + | | TACACS | + | +-----+-----+ + | | + +-----+ +-------+ +--------+ +----+-----+ +-----+-----+ + |Hosts|--+Router +------+ DSLAM +-+ BRAS +-+ Edge | + +-----+ +-------+ +--------+ +----------+ | Router +=>Core + +-----------+ + |----------------------------------------| + PPP + |------------| + L2TPv2 + + Figure 6.2.3.1 + + B. Connection via PPPoE + + Customer Premise NAP NSP + |--------------------------| |--------------------| |---------------| + +-----------+ + | AAA | + +------+ Radius | + | | TACACS | + | +-----+-----+ + | | + +-----+ +-------+ +--------+ +----+-----+ +----+------+ + |Hosts|--+Router +-----------+ DSLAM +-+ BRAS +-+ Edge | C + +-----+ +-------+ +--------+ +----------+ | Router +=>O + | | R + +-----------+ E + |-----------------------------------------------| + PPP + |--------------| + L2TPv2 + + Figure 6.2.3.2 + + The network design and operation of the PTA model is the same, + regardless of the PPP encapsulation type used. + + + + + + +Asadullah, et al. Informational [Page 34] + +RFC 4779 ISP IPv6 Deployment Scenarios in BB January 2007 + + +6.2.3.1. IPv6 Related Infrastructure Changes + + In this scenario, the BRAS is forwarding the PPP sessions initiated + by the subscriber over the L2TPv2 tunnel established to the L2TP + Network Server (LNS), the aggregation point in the ISP network. The + L2TPv2 tunnel between the L2TP Access Concentrator (LAC) and LNS can + run over IPv6 or IPv4. These capabilities have to be supported on + the BRAS. The following devices have to be upgraded to dual stack: + Host, Customer Router, and Edge Router. If the tunnel is set up over + IPv6, then the BRAS must be upgraded to dual stack. + +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 an 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 latter case, once the session is established with the Edge + Router, DHCP-PD can be used to acquire 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. + + 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 connectivity to the rest of the ISP network. Other + information of interest to the host, such as DNS, is provided through + stateful [RFC3315] and stateless [RFC3736] DHCPv6. + + It is important to note here a significant difference between this + deployment for IPv6 versus IPv4. In the case of IPv4, the customer + router or CPE can end up on any Edge Router (acting as LNS), where + the assumption is that there are at least two of them for redundancy + purposes. Once authenticated, the customer will be given an address + from the IP pool of the ER (LNS) it connected to. This allows the + ERs (LNSs) to aggregate the addresses handed out to the customers. + In the case of IPv6, an important constraint that likely will be + enforced is that the customer should keep its own address, regardless + of the ER (LNS) it connects to. This could significantly reduce the + prefix aggregation capabilities of the ER (LNS). This is different + than the current IPv4 deployment where addressing is dynamic in + nature, and the same user can get different addresses depending on + the LNS it ends up connecting to. + + + + + +Asadullah, et al. Informational [Page 35] + +RFC 4779 ISP IPv6 Deployment Scenarios in BB January 2007 + + + One possible solution is to ensure that a given BRAS will always + connect to the same ER (LNS) unless that LNS is down. This means + that customers from a given prefix range will always be connected to + the same ER (primary, if up, or secondary, if not). Each ER (LNS) + can carry summary statements in their routing protocol configuration + for the prefixes for which they are the primary ER (LNS), as well as + for the ones for which they are the secondary. This way the prefixes + will be summarized any time they become "active" on the ER (LNS). + +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 generally 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. + +6.2.4. Hybrid Model for IPv4 and IPv6 Service + + It was recommended throughout this section that the IPv6 service + implementation should map the existing IPv4 one. This approach + simplifies manageability and minimizes training 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 + bundled 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. + + + + + +Asadullah, et al. Informational [Page 36] + +RFC 4779 ISP IPv6 Deployment Scenarios in BB January 2007 + + + A Modified Point-to-Point (as described in Section 6.2.4.2) or 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. + + In this sense, IPv6 deployment can be viewed as an opportunity to + build an infrastructure that might better support the expansion of + services. In this case, an SP using the LAA design for its IPv4 + services might choose a modified 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 straightforward. The PPP sessions are terminated on + different network devices for the IPv4 and IPv6 services. The PPP + sessions for the existing 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 + |------------| + L2TPv2 + + Figure 6.2.4.1 + +6.2.4.2. IPv4 in LAA Model and IPv6 in Modified Point-to-Point Model + + In this particular scenario the Point-to-Point model used for the + IPv6 service is a modified version of the model described in section + 6.2.1. + + + + + +Asadullah, et al. Informational [Page 37] + +RFC 4779 ISP IPv6 Deployment Scenarios in BB January 2007 + + + For the IPv4 service in the LAA model, the PVCs are terminated on the + BRAS and PPP sessions are terminated on the Edge Router (LNS). For + IPv6 service in the Point-to-Point model, the PVCs are terminated at + the Edge Router as described in Section 6.2.1. In this hybrid model, + the Point-to-Point link could be terminated on the BRAS, a NAP-owned + device. The IPv6 traffic is then routed through the NAP network to + the NSP. In order to have this hybrid model, the BRAS has to be + upgraded to a dual-stack router. The functionalities of the Edge + Router, as described in Section 6.2.1, are now implemented on the + BRAS. + + The other aspect of this deployment model is the fact that the BRAS + has to be capable of distinguishing between the IPv4 PPP traffic that + has to be bridged across the L2TPv2 tunnel and the IPv6 packets that + have to be routed to the NSP. The IPv6 Routing and Bridging + Encapsulation (RBE) has to be enabled on all interfaces with PVCs + supporting both IPv4 and IPv6 services in this hybrid 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 + |------------| + L2TPv2 + + Figure 6.2.4.2 + +6.3. IPv6 Multicast + + The deployment of IPv6 multicast services relies on MLD, identical to + IGMP in IPv4 and on PIM for routing. ASM (Any Source Multicast) and + SSM (Single Source Multicast) service models operate almost the same + as in IPv4. Both have the same benefits and disadvantages as in + IPv4. Nevertheless, the larger address space and the scoped address + architecture provide major benefits for multicast IPv6. Through RFC + 3306, the large address space provides the means to assign global + + + +Asadullah, et al. Informational [Page 38] + +RFC 4779 ISP IPv6 Deployment Scenarios in BB January 2007 + + + multicast group addresses to organizations or users that were + assigned unicast prefixes. It is a significant improvement with + respect to the IPv4 GLOP mechanism [RFC3180]. + + This facilitates the deployment of multicast services. The + discussion of this section applies to all the multicast sections in + the document. + +6.3.1. ASM-Based Deployments + + Any Source Multicast (ASM) is useful for Service Providers that + intend to support the forwarding of multicast traffic of their + customers. It is based on the Protocol Independent Multicast - + Sparse Mode (PIM-SM) protocol and it is more complex to manage + because of the use of Rendezvous Points (RPs). With IPv6, static RP + and Bootstrap Router [BSR] can be used for RP-to-group mapping + similar to IPv4. Additionally, the larger IPv6 address space allows + for building up of group addresses that incorporate the address of + the RP. This RP-to-group mapping mechanism is called Embedded RP and + is specific to IPv6. + + In inter-domain deployments, Multicast Source Discovery Protocol + (MSDP) [RFC3618] is an important element of IPv4 PIM-SM deployments. + MSDP is meant to be a solution for the exchange of source + registration information between RPs in different domains. This + solution was intended to be temporary. This is one of the reasons + why it was decided not to implement MSDP in IPv6 [IPv6-Multicast]. + + For multicast reachability across domains, Embedded RP can be used. + As Embedded RP provides roughly the same capabilities as MSDP, but in + a slightly different way, the best management practices for ASM + multicast with embedded RP still remain to be developed. + +6.3.2. SSM-Based Deployments + + Based on PIM-SSM, the Source-Specific Multicast deployments do not + need an RP or related protocols (such as BSR or MSDP), but rely on + the listeners to know the source of the multicast traffic they plan + to receive. The lack of RP makes SSM not only simpler to operate, + but also robust; it is not impacted by RP failures or inter-domain + constraints. It also has a higher level of security (no RP to be + targeted by attacks). For more discussions on the topic of IPv6 + multicast, see [IPv6-Multicast]. + + The typical multicast service offered for residential and very small + businesses is video/audio streaming, where the subscriber joins a + multicast group and receives the content. This type of service model + is well supported through PIM-SSM which is very simple and easy to + + + +Asadullah, et al. Informational [Page 39] + +RFC 4779 ISP IPv6 Deployment Scenarios in BB January 2007 + + + manage. PIM-SSM has to be 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. + + 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 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 CPR, its limited resources should be taken + into consideration. Another option would be for the CPR to support + MLD proxy routing. + + 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 CPRs. 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 are usually + configured on the Edge Router in order to enable the ISP to control + the subscriber access of the service and do billing for the content + provided. Alternative mechanisms that would support these functions + should be investigated further. + +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 is beyond + the scope of this document. + + On the BRAS or the Edge Router, the subscriber-facing interfaces have + to be configured to police the inbound customer traffic and shape the + traffic outbound to the customer based on the service level + agreements (SLAs). Traffic classification and marking should also be + + + +Asadullah, et al. Informational [Page 40] + +RFC 4779 ISP IPv6 Deployment Scenarios in BB January 2007 + + + done on the router closest (at Layer 3) to the subscriber in order to + support the various types of customer traffic (data, voice, and + video) and to optimally use the infrastructure resources. Each + provider (NAP, NSP) could implement their own QoS policies and + services so that 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 with IPv6 as well. + + It is important to note that when traffic is encrypted end-to-end, + the traversed network devices will not have access to many of the + packet fields used for classification purposes. In these cases, + routers will most likely place the packets in the default classes. + The QoS design should take into consideration this scenario and try + to use mainly IP header fields for classification purposes. + +6.5. IPv6 Security Considerations + + There are limited changes that have to be done for CPEs in order to + enhance security. The privacy extensions for auto-configuration + [RFC3041] should be used by the hosts. ISPs can track the prefixes + it assigns to subscribers relatively easily. If, however, the ISPs + are required by regulations to track their users at a /128 address + level, the privacy extensions may be implemented in parallel with + network management tools that could provide traceability of the + hosts. IPv6 firewall functions should be enabled on the hosts or + CPR, if present. + + The ISP provides security against attacks that come from 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 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 [IPv6-Security]. + + The BRAS and the Edge Router should protect their processing + resources against floods of valid customer control traffic such as: + Router and Neighbor Solicitations, and 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. + + + + +Asadullah, et al. Informational [Page 41] + +RFC 4779 ISP IPv6 Deployment Scenarios in BB January 2007 + + + All other security features used with the IPv4 service should be + similarly applied to IPv6 as well. + +6.6. IPv6 Network Management + + The necessary instrumentation (such as MIB modules, NetFlow Records, + etc.) should be available for IPv6. + + Usually, NSPs manage the edge routers by SNMP. The SNMP transport + can be done over IPv4 if all managed devices have connectivity over + both IPv4 and IPv6. This would imply the smallest changes to the + existing network management practices and processes. Transport over + IPv6 could also be implemented, and it might become necessary if IPv6 + only islands are present in the network. The management applications + may be running on hosts belonging to the NSP core network domain. + Network Management Applications should handle IPv6 in a similar + fashion to IPv4; however, they should also support features specific + to IPv6 (such as neighbor monitoring). + + In some cases, service providers manage equipment located on + customers' LANs. The management of equipment at customers' LANs is + out of scope of this memo. + +7. Broadband Ethernet Networks + + This section describes the IPv6 deployment options in currently + deployed 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 provided. 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: + + Access Switch: It is used as a Layer 2 access device for subscribers. + + Customer Premise Router: It is used to provide Layer 3 services for + customer premise networks. + + Aggregation Ethernet Switches: Aggregates multiple subscribers. + + Broadband Remote Access Server (BRAS) + + + +Asadullah, et al. Informational [Page 42] + +RFC 4779 ISP IPv6 Deployment Scenarios in BB January 2007 + + + Edge Router (ER) + + Figure 7.1 depicts all the network elements mentioned. + + Customer Premise | Network Access Provider | Network Service Provider + CP NAP NSP + + + +-----+ +------+ +------+ +--------+ + |Hosts|--|Router| +-+ BRAS +--+ Edge | ISP + +-----+ +--+---+ | | | | Router +===> Network + | | +------+ +--------+ + +--+----+ | + |Access +-+ | + |Switch | | | + +-------+ | +------+ | + +--+Agg E | | + +-------+ |Switch+-+ + +-----+ |Access | +--+ | + |Hosts|--+Switch +-+ +------+ + +-----+ +-------+ + + Figure 7.1 + + The logical topology and design of Broadband Ethernet Networks are + very similar to DSL Broadband Networks discussed in Section 6. + + It is worth noting that the general operation, concepts and + recommendations described in this section apply similarly to a + HomePNA-based network environment. In such an environment, some of + the network elements might be differently named. + +7.2. Deploying IPv6 in IPv4 Broadband Ethernet Networks + + There are three main design approaches to providing IPv4 connectivity + over an Ethernet infrastructure: + + A. 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.1. + + + + + + + +Asadullah, et al. Informational [Page 43] + +RFC 4779 ISP IPv6 Deployment Scenarios in BB January 2007 + + + B. 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. + + C. L2TPv2 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 L2TPv2 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 existing revenue generating IPv4 services, the + IPv6 deployment will match the IPv4 one. This approach is presented + in Sections 7.2.1 - 7.2.3 that describe currently deployed 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 Section + 7.2.4. + +7.2.1. Point-to-Point Model + + In this scenario, the Ethernet frames from the Host or the Customer + Premise Router are bridged over the VLAN assigned to the subscriber. + + Figure 7.2.1 describes the protocol architecture of this model. + + | Customer Premise | | NAP | NSP | + + +-----+ +------+ +------+ +--------+ +----------+ + |Hosts|--+Router+--+Access+--+ Switch +--------+ Edge | ISP + +-----+ +------+ |Switch| +--------+ 802.1Q | Router +=>Network + +------+ +----------+ + + |----------------------------| + Ethernet/VLANs + + Figure 7.2.1 + + + + + + + +Asadullah, et al. Informational [Page 44] + +RFC 4779 ISP IPv6 Deployment Scenarios in BB January 2007 + + +7.2.1.1. IPv6 Related Infrastructure Changes + + In this scenario, the Access Switch is 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 Access 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 subscriber VLAN. The hosts + can use stateless auto-configuration or stateful DHCPv6-based + configuration to acquire an address via the Edge Router. + + However, as manual configuration for each customer is a provisioning + challenge, implementations are encouraged to develop mechanism(s) + that automatically map the VLAN (or some other customer-specific + information) to an IPv6 subnet prefix, and advertise the customer- + specific prefix to all the customers with minimal configuration. + + If a Customer Router is present: + + A. 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. + + B. It can use its link-local address to communicate with the ER. It + can also dynamically acquire, through stateless auto- + configuration, the address for the link between itself and the + ER. This step is followed by a request via DHCP-PD for a prefix + shorter than /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 have to be enabled + to support the feature. The uplink to the ISP network is configured + with a /64 prefix as well. + + + + + +Asadullah, et al. Informational [Page 45] + +RFC 4779 ISP IPv6 Deployment Scenarios in BB January 2007 + + + The prefixes used for subscriber links and the ones delegated via + DHCP-PD should be planned in a manner 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 [RFC3315] and stateless [RFC3736] 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 generally 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. + +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 are + 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. + + When the NSP is also the NAP, the BRAS and NSP Edge Router could be + the same piece of equipment and provide the above mentioned + functionality. + + The PPPoE logical diagram in an Ethernet Broadband Network is shown + in Fig 7.2.2.1. + + + + + + + + + + + + + + + + +Asadullah, et al. Informational [Page 46] + +RFC 4779 ISP IPv6 Deployment Scenarios in BB January 2007 + + + | Customer Premise | | NAP | | NSP | + + +-----------+ + | AAA | + +-------+ Radius | + | | TACACS | + | +-----------+ + +-----+ +-------+ +--------+ +--------+ +----+-----+ +-----------+ + |Hosts|-+Router +-+A 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 remote database. Once the session is established, the BRAS + provides an address and maybe a DNS server to the user; this + information is acquired from the subscriber profile or a DHCP server. + + This model allows for multiple PPPoE sessions 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 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 (if present), 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 an 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 latter case, once the session is established with the BRAS, + DHCP-PD can be used to acquire 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. + + + +Asadullah, et al. Informational [Page 47] + +RFC 4779 ISP IPv6 Deployment Scenarios in BB January 2007 + + + The BRAS has a /64 prefix configured on the link facing the Edge + router. The Edge Router links are also configured with /64 prefixes + to provide connectivity to the rest of the ISP network. + + The prefixes used for subscribers and the ones delegated via DHCP-PD + should be planned in a manner that allows maximum summarization at + the BRAS. + + Other information of interest to the host, such as DNS, is provided + through stateful [RFC3315] and stateless [RFC3736] 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 generally 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 BRAS. 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 recommended if they are managed independently. + Controlled redistribution will be needed between the Access Provider + IGP and the ISP IGP. + +7.2.3. L2TPv2 Access Aggregation (LAA) Model + + In the LAA model, the BRAS forwards the CPE initiated session to the + ISP over an L2TPv2 tunnel established between the BRAS and the Edge + Router. In this case, the authentication, authorization, and + subscriber configuration are performed by the ISP itself. + + + + + + + + + + + + + + + +Asadullah, et al. Informational [Page 48] + +RFC 4779 ISP IPv6 Deployment Scenarios in BB January 2007 + + + | Customer Premise | | NAP | | NSP | + + +-----------+ + | AAA | + +------+ Radius | + | | TACACS | + | +-----+-----+ + | | + +-----+ +-------+ +--------+ +--------+ +----+-----+ +-----------+ + |Hosts|-+Router +-+A Switch+-+ Switch +-+ BRAS +-+ Edge | C + +-----+ +-------+ +--------+ +--------+ +----------+ | Router +=>O + | | R + +-----------+ E + |-----------------------------------------------| + PPP + |--------------| + L2TPv2 + Figure 7.2.3.1 + +7.2.3.1. IPv6 Related Infrastructure Changes + + In this scenario, the BRAS is Layer 3 aware and has to be upgraded to + support IPv6. The PPP sessions initiated by the subscriber are + forwarded over the L2TPv2 tunnel to the aggregation point in the ISP + network. The BRAS (LAC) can aggregate IPv6 PPP sessions and tunnel + them to the LNS using L2TPv2. The L2TPv2 tunnel between the LAC and + LNS could run over IPv6 or IPv4. These capabilities have to be + supported on the BRAS. The following devices have to be upgraded to + dual stack: Host, Customer Router (if present), 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 an 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 latter case, once the session is established with the Edge + Router and an IPv6 address is assigned to the Customer Router by the + Edge Router, DHCP-PD can be used to acquire prefixes for the Customer + Router other 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. The uplink to the ISP network is configured with a + /64 prefix as well. + + + + + +Asadullah, et al. Informational [Page 49] + +RFC 4779 ISP IPv6 Deployment Scenarios in BB January 2007 + + + 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 connectivity to the rest of the ISP network. + + Other information of interest to the host, such as DNS, is provided + through stateful [RFC3315] and stateless [RFC3736] DHCPv6. + + The address assignment and prefix summarization issues discussed in + Section 6.2.3.2 are relevant in the same way for this media access + type as well. + +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 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. + +7.2.4. Hybrid Model for IPv4 and IPv6 Service + + It was recommended throughout this section that the IPv6 service + implementation should map the existing IPv4 one. This approach + simplifies manageability and minimizes training 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 + bundled 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. + + + + + +Asadullah, et al. Informational [Page 50] + +RFC 4779 ISP IPv6 Deployment Scenarios in BB January 2007 + + + A Modified Point-to-Point (see Section 7.2.4.2) 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 + a topology saves NAP resources. + + In this sense, IPv6 deployments can be viewed as an opportunity to + build an infrastructure that can better support the expansion of + services. In this case, an SP using the LAA design for its IPv4 + services might choose a modified 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 straightforward. It is a straightforward overlap of the + two deployment models. The PPP sessions are terminated on different + network devices for the IPv4 and IPv6 services. The PPP sessions for + the existing 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 + |------------| + L2TPv2 + + Figure 7.2.4.1 + + + + + + + + +Asadullah, et al. Informational [Page 51] + +RFC 4779 ISP IPv6 Deployment Scenarios in BB January 2007 + + +7.2.4.2. IPv4 in LAA Model and IPv6 in Modified Point-to-Point Model + + The coexistence of the modified Point-to-Point and the LAA models + implies a few specific changes. + + For the IPv4 service in LAA model, the VLANs are terminated on the + BRAS, and PPP sessions are terminated on the Edge Router (LNS). For + the IPv6 service in the Point-to-Point model, the VLANs are + terminated at the Edge Router as described in Section 6.2.1. In this + hybrid model, the Point-to-Point link could be terminated on the + BRAS, a NAP-owned device. The IPv6 traffic is then routed through + the NAP network to the NSP. In order to have this hybrid model, the + BRAS has to be upgraded to a dual-stack router. The functionalities + of the Edge Router, as described in Section 6.2.1, are now + implemented on the BRAS. + + 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 +------+ Switch +-+ BRAS +-+ Edge | + +-----+ +-------+ +--------+ +----------+ | Router +=>Core + +-----------+ + IPv4 |----------------------------------------| + PPP + |------------| + L2TPv2 + + Figure 7.2.4.2 + +7.3. IPv6 Multicast + + The typical multicast services offered for residential and very small + businesses are video/audio streaming where the subscriber joins a + multicast group and receives 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. + + + +Asadullah, et al. Informational [Page 52] + +RFC 4779 ISP IPv6 Deployment Scenarios in BB January 2007 + + + 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 support MLDv1 or MLDv2. If a CPR 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 CPR, its limited resources should be taken into + consideration. Another option would be for the CPR to support MLD + proxy routing. MLD snooping or similar Layer 2 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 CPRs. 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 are usually + configured on the edge router in order to enable the ISP to control + the subscriber access of the service and do billing for the content + provided. Alternative mechanisms that would support these functions + should be investigated further. + + Please refer to section 6.3 for more IPv6 multicast details. + +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 configured 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 optimally use the + network resources. This infrastructure offers a very good + opportunity to leverage the QoS capabilities of Layer 2 devices. + Diffserv-based QoS used for IPv4 should be expanded to IPv6. + + + + + +Asadullah, et al. Informational [Page 53] + +RFC 4779 ISP IPv6 Deployment Scenarios in BB January 2007 + + + Each provider (NAP, NSP) could implement their own QoS policies and + services so that 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. + + It is important to note that when traffic is encrypted end-to-end, + the traversed network devices will not have access to many of the + packet fields used for classification purposes. In these cases, + routers will most likely place the packets in the default classes. + The QoS design should take into consideration this scenario and try + to use mainly IP header fields for classification purposes. + +7.5. IPv6 Security Considerations + + There are limited changes that have to be done for CPEs in order to + enhance security. The privacy extensions [RFC3041] for auto- + configuration should be used by the hosts with the same + considerations for host traceability as discussed in Section 6.5. + IPv6 firewall functions should be enabled on the hosts or Customer + Premise Router, if present. + + The ISP provides security against attacks that come from its own + subscribers, but it could also implement security services that + protect its subscribers from attacks sourced from outside its + network. Such services do not apply at the access level of the + network discussed here. + + If any Layer 2 filters for Ethertypes are in place, the NAP must + permit 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 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 [IPv6-Security]. + + The BRAS and the Edge Router should protect their processing + resources against floods of valid customer control traffic such as: + Router and Neighbor Solicitations, and 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. + + + + +Asadullah, et al. Informational [Page 54] + +RFC 4779 ISP IPv6 Deployment Scenarios in BB January 2007 + + +7.6. IPv6 Network Management + + The necessary instrumentation (such as MIB modules, NetFlow Records, + etc.) should be available for IPv6. + + Usually, NSPs manage the edge routers by SNMP. The SNMP transport + can be done over IPv4 if all managed devices have connectivity over + both IPv4 and IPv6. This would imply the smallest changes to the + existing network management practices and processes. Transport over + IPv6 could also be implemented and it might become necessary if IPv6 + only islands are present in the network. The management applications + may be running on hosts belonging to the NSP core network domain. + Network Management Applications should handle IPv6 in a similar + fashion to IPv4; however, they should also support features specific + to IPv6 such as neighbor monitoring. + + In some cases, service providers manage equipment located on + customers' LANs. + +8. Wireless LAN + + This section provides a detailed description of IPv6 deployment and + integration methods in currently deployed wireless LAN (WLAN) + infrastructure. + +8.1. WLAN Deployment Scenarios + + WLAN enables subscribers to connect to the Internet from various + locations without the restriction of staying indoors. WLAN is + standardized by IEEE 802.11a/b/g. + + Figure 8.1 describes the current WLAN architecture. + + Customer | Access Provider | Service Provider + Premise | | + + +------+ +--+ +--------------+ +----------+ +------+ + |WLAN | ---- | | |Access Router/| | Provider | |Edge | + |Host/ |-(WLAN)--|AP|-|Layer 2 Switch|-| Network |-|Router|=>SP + |Router| ---- | | | | | | | |Network + +------+ +--+ +--------------+ +----------+ +------+ + | + +------+ + |AAA | + |Server| + +------+ + + Figure 8.1 + + + +Asadullah, et al. Informational [Page 55] + +RFC 4779 ISP IPv6 Deployment Scenarios in BB January 2007 + + + 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 a host initiates a + connection, it is authenticated by the AAA server located at the SP + network. All the authentication parameters (username, password, + etc.) are forwarded by the Access Point (AP) to the AAA server. The + AAA server authenticates the host; once successfully authenticated, + 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, etc. + + WLANs operate within 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, PDAs, etc.). + Once the user initiates the connection, the IP address is assigned by + the SP using DHCPv4. In most of the cases, SP assigns a limited + number of public IP addresses to its customers. When the user + disconnects the connection and moves to a new WiFi hot spot, the + above-mentioned process of authentication, address assignment, and + accessing the Internet is repeated. + + There are IPv4 deployments where customers can use WLAN routers to + connect over wireless to their service provider. These deployment + types do not fit in the typical Hot Spot concept, but rather they + serve fixed customers. For this reason, this section discusses the + WLAN router options as well. In this case, the ISP provides a public + IP address and the WLAN Router assigns private addresses [RFC1918] to + all WLAN users. The WLAN Router provides NAT functionality while + WLAN users access the Internet. + + While deploying IPv6 in the above-mentioned WLAN architecture, there + are three possible scenarios as discussed below. + + A. Layer 2 NAP with Layer 3 termination at NSP Edge Router + + B. Layer 3 aware NAP with Layer 3 termination at Access Router + + C. PPP-Based Model + +8.1.1. Layer 2 NAP with Layer 3 termination at NSP Edge Router + + When a Layer 2 switch is present between AP and Edge Router, the AP + and Layer 2 switch continues to work as a bridge, forwarding IPv4 and + IPv6 packets from WLAN Host/Router to Edge Router and vice versa. + + + + +Asadullah, et al. Informational [Page 56] + +RFC 4779 ISP IPv6 Deployment Scenarios in BB January 2007 + + + When initiating the connection, the WLAN Host is authenticated by the + AAA server located at the SP network. All the parameters related to + authentication (username, password, etc.) are forwarded by the AP to + the AAA server. The AAA server authenticates the WLAN Hosts, and + once the WLAN Host is authenticated and associated successfully with + the WLAN AP, it acquires an IPv6 address. Note that the initiation + and authentication process is the same as used in IPv4. + + Figure 8.1.1 describes the WLAN architecture when a Layer 2 Switch is + located between AP and Edge Router. + + Customer | Access Provider | Service Provider + Premise | | + + +------+ +--+ +--------------+ +----------+ +------+ + |WLAN | ---- | | | | | Provider | |Edge | + |Host/ |-(WLAN)--|AP|-|Layer 2 Switch|-| Network |-|Router|=>SP + |Router| ---- | | | | | | | |Network + +------+ +--+ +--------------+ +----------+ +------+ + | + +------+ + |AAA | + |Server| + +------+ + + Figure 8.1.1 + +8.1.1.1. IPv6 Related Infrastructure Changes + + IPv6 will be deployed in this scenario by upgrading the following + devices to dual stack: WLAN Host, WLAN Router (if present), and Edge + Router. + +8.1.1.2. Addressing + + When a 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 an Edge Router using + stateless auto-configuration [RFC2462]. All 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, etc. + + B. The IPv6 WLAN Host can use DHCPv6 [RFC3315] to get an IPv6 + address from the DHCPv6 server. In this case, the DHCPv6 server + would be located in the SP core network, and the Edge Router + would simply act as a DHCP Relay Agent. This option is similar + + + +Asadullah, et al. Informational [Page 57] + +RFC 4779 ISP IPv6 Deployment Scenarios in BB January 2007 + + + to what is done today in case of DHCPv4. It is important to note + that host implementation of stateful auto-configuration is rather + limited at this time, and this should be considered if choosing + this address assignment option. + + 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 be assigned a prefix between /48 and /64 + [RFC3177] depending on the SP policy and customer 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 interfaces connecting the WLAN + Hosts on the customer site. The WLAN Hosts connected to these + interfaces can automatically configure themselves using stateless + auto-configuration. + + B. The WLAN Router can use its link-local address to communicate + with the ER. It can also dynamically acquire through stateless + auto-configuration the address for the link between itself and + the ER. This step is followed by a request via DHCP-PD for a + prefix shorter than /64 that, in turn, is divided in /64s and + assigned to its interfaces connecting the hosts on the customer + site. + + In this option, the WLAN Router would act as a requesting router and + the Edge Router would act as a delegating router. Once the 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. The uplink to the ISP + network is configured with a /64 prefix as well. + + 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, etc. 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 at the Edge Router. + + Other information of interest to the host, such as DNS, is provided + through stateful [RFC3315] and stateless [RFC3736] DHCPv6. + + + + + +Asadullah, et al. Informational [Page 58] + +RFC 4779 ISP IPv6 Deployment Scenarios in BB January 2007 + + +8.1.1.3. Routing + + The WLAN Host/Router is configured with a default route that points + to the Edge Router. No routing protocols are needed on these + devices, which generally 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. When DHCP-PD + is used, the IGP has to redistribute the static routes installed + during the process of prefix delegation. + +8.1.2. Layer 3 Aware NAP with Layer 3 Termination at Access Router + + When an Access Router is present between the AP and Edge Router, the + AP continues to work as a bridge, bridging IPv4 and IPv6 packets from + WLAN Host/Router to Access Router and vice versa. The Access Router + could be part of the SP network or owned by a separate Access + Provider. + + When the WLAN Host initiates the connection, the AAA authentication + and association process with WLAN AP will be similar, as explained in + Section 8.1.1. + + Figure 8.1.2 describes the WLAN architecture when the Access Router + is located between the AP and Edge Router. + + Customer | Access Provider | Service Provider + Premise | | + + +------+ +--+ +--------------+ +----------+ +------+ + |WLAN | ---- | | | | | Provider | |Edge | + |Host/ |-(WLAN)--|AP|-|Access Router |-| Network |-|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: WLAN Host, WLAN Router (if present), Access Router, + and Edge Router. + + + +Asadullah, et al. Informational [Page 59] + +RFC 4779 ISP IPv6 Deployment Scenarios in BB January 2007 + + +8.1.2.2. Addressing + + There are three possible options in this scenario for IPv6 address + assignment: + + A. The Edge Router interface facing towards the Access Router is + statically configured with a /64 prefix. The Access Router + receives/ configures a /64 prefix on its interface facing towards + the Edge Router through stateless auto-configuration. The + network administrator will have to configure the /64 prefixes to + the Access Router interface facing toward the customer premise. + The WLAN Host/Router connected to this interface can + automatically configure itself using stateless auto- + configuration. + + 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, the Edge Router, or somewhere in + the SP network. In this case, depending on where the DHCPv6 + server is located, the Access Router or the Edge Router would + relay the DHCPv6 requests. + + C. It can use its link-local address to communicate with the ER. It + can also dynamically acquire through stateless auto-configuration + the address for the link between itself and the ER. This step is + followed by a request via DHCP-PD for a prefix shorter than /64 + that, in turn, is divided in /64s and assigned to its interfaces + connecting the hosts on the customer site. + + In this option, the Access Router would act as a requesting + router, and the Edge Router would act as a delegating router. + Once the prefix is received by the Access Router, it assigns /64 + prefixes to each of its interfaces connecting the WLAN Host/ + Router on the customer site. The WLAN Host/Router connected to + these interfaces can automatically configure itself using + stateless auto-configuration. The uplink to the ISP network is + configured with a /64 prefix as well. + + 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. + + + + + + +Asadullah, et al. Informational [Page 60] + +RFC 4779 ISP IPv6 Deployment Scenarios in BB January 2007 + + + As mentioned before, the prefixes used for subscriber links and the + ones delegated via DHCP-PD should be planned in a manner that allows + the maximum summarization possible at the Edge Router. Other + information of interest to the host, such as DNS, is provided through + stateful [RFC3315] and stateless [RFC3736] DHCPv6. + +8.1.2.3. Routing + + The WLAN Host/Router is configured with a default route that points + to the Access Router. No routing protocols are needed on these + devices, which generally 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 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 the Access Router is owned by the SP, then the Access Router will + also run IPv6 IGP, and will be part of the SP 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. + +8.1.3. PPP-Based Model + + PPP Terminated Aggregation (PTA) and L2TPv2 Access Aggregation (LAA) + models, as discussed in Sections 6.2.2 and 6.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 Layer 3 aware and it has to be upgraded to support IPv6. + Since the Access Router terminates the PPP sessions initiated by the + WLAN Host/Router, it has to support PPPoE with IPv6. + + Figure 8.1.3.1 describes the PTA Model in IPv6 WLAN environment. + + + + + + + + +Asadullah, et al. Informational [Page 61] + +RFC 4779 ISP IPv6 Deployment Scenarios in BB January 2007 + + + Customer | Access Provider | Service Provider + Premise | | + +------+ +--+ +--------------+ +----------+ +------+ + |WLAN | ---- | | | | | Provider | |Edge | + |Host/ |-(WLAN)--|AP|-|Access Router |-| Network |-|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: WLAN Host, WLAN Router (if present), Access Router, + and Edge Router. + +8.1.3.1.2. Addressing + + The addressing techniques described in Section 6.2.2.2 apply to the + IPv6 WLAN PTA scenario as well. + +8.1.3.1.3. Routing + + The routing techniques described in Section 6.2.2.3 apply to the 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 Layer 3 aware and has to be upgraded to support IPv6. The + PPP sessions initiated by the WLAN Host/Router are forwarded over the + L2TPv2 tunnel to the aggregation point in the SP network. The Access + Router must have the capability to support L2TPv2 for IPv6. + + Figure 8.1.3.2 describes the LAA Model in IPv6 WLAN environment. + + + + + + + + + + + +Asadullah, et al. Informational [Page 62] + +RFC 4779 ISP IPv6 Deployment Scenarios in BB January 2007 + + + Customer | Access Provider | Service Provider + Premise | | + + +------+ +--+ +--------------+ +----------+ +------+ + |WLAN | ---- | | | | | Provider | |Edge | + |Host/ |-(WLAN)--|AP|-|Access Router |-| Network |-|Router|=>SP + |Router| ---- | | | | | | | |Network + +------+ +--+ +--------------+ +----------+ +------+ + | + |-------------------------------------------------- | + PPP | + |--------------------- | + L2TPv2 | + +------+ + |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: WLAN Host, WLAN Router (if present), Access Router, + and Edge Router. + +8.1.3.2.2. Addressing + + The addressing techniques described in Section 6.2.3.2 apply to the + IPv6 WLAN LAA scenario as well. + +8.1.3.2.3. Routing + + The routing techniques described in Section 6.2.3.3 apply to the 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 receives the + content. This type of service model is 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. + + + + + + + +Asadullah, et al. Informational [Page 63] + +RFC 4779 ISP IPv6 Deployment Scenarios in BB January 2007 + + + It is important to note that in the shared wireless environments, + multicast can have a significant bandwidth impact. For this reason, + the bandwidth allocated to multicast traffic should be limited and + fixed, based on the overall capacity of the wireless specification + used in 802.11a, 802.11b, or 802.11g. + + The IPv6 WLAN Hosts can also join desired multicast groups as long as + they are enabled to support MLDv1 or MLDv2. If 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 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, its limited resources should + be taken into consideration. Another option would be for the WLAN/ + Access Router to support MLD proxy routing. + + The Edge Router has to be enabled to support MLDv1 and MLDv2 in order + to process the requests coming from the 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 are usually + configured on the Edge Router in order to enable the SP to do billing + for the content services provided. Further investigation should be + made in finding alternative mechanisms that would support these + functions. + + Concerns have been raised in the past related to running IPv6 + multicast over WLAN links. Potentially these are the same kind of + issues when running any Layer 3 protocol over a WLAN link that has a + high loss-to-signal ratio, where certain frames that are multicast + based are dropped when settings are not adjusted properly. For + instance, this behavior is similar to an IGMP host membership report, + when done on a WLAN link with a high loss-to-signal ratio and high + interference. + + This problem is inherited by WLAN that can impact both IPv4 and IPv6 + multicast packets; it is 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 + the AP is placed too far (not following the distance limitations), + high interference, 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 Detection (DAD), Router and Neighbor + + + +Asadullah, et al. Informational [Page 64] + +RFC 4779 ISP IPv6 Deployment Scenarios in BB January 2007 + + + Solicitations (RS, NS), Router and Neighbor Advertisement (RA, NA), + etc., which could be impacted by the above mentioned issues as these + frames are Layer 2 Ethernet multicast frames. + + Please refer to Section 6.3 for more IPv6 multicast details. + +8.3. IPv6 QoS + + Today, QoS is done outside of the WiFi domain, but it is nevertheless + important to the overall deployment. + + 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 (SLAs). However, the + WLAN Host/Router and Access Router could also be configured for QoS. + This includes support for appropriate classification criteria, which + would need to be implemented for IPv6 unicast and multicast traffic. + + On the Edge Router, the subscriber-facing interfaces have to be + configured 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, + and video. The same IPv4 QoS concepts and methodologies should be + applied for the IPv6 as well. + + It is important to note that when traffic is encrypted end-to-end, + the traversed network devices will not have access to many of the + packet fields used for classification purposes. In these cases, + routers will most likely place the packets in the default classes. + The QoS design should take into consideration this scenario and try + to use mainly IP header fields for classification purposes. + +8.4. IPv6 Security Considerations + + There are limited changes that have to be done for WLAN the Host/ + Router in order to enhance security. The privacy extensions + [RFC3041] for auto-configuration should be used by the hosts with the + same consideration for host traceability as described in Section 6.5. + IPv6 firewall functions should be enabled on the WLAN Host/Router, if + present. + + The ISP provides security against attacks that come from its own + subscribers, but it could also implement security services that + protect its subscribers from attacks sourced from outside its + network. Such services do not apply at the access level of the + network discussed here. + + + + +Asadullah, et al. Informational [Page 65] + +RFC 4779 ISP IPv6 Deployment Scenarios in BB January 2007 + + + If the host authentication at hotspots is done using a web-based + authentication system, then the level of security would depend on the + particular implementation. User credentials should never be sent as + clear text via HTTP. Secure HTTP (HTTPS) should be used between the + web browser and authentication server. The authentication server + could use RADIUS and LDAP services at the back end. + + Authentication is an important aspect of securing WLAN networks prior + to implementing Layer 3 security policies. For example, this would + help avoid threats to the ND or stateless auto-configuration + processes. 802.1x [IEEE8021X] provides the means to secure the + network access; however, the many types of EAP (PEAP, EAP-TLS, EAP- + TTLS, EAP-FAST, and LEAP) and the capabilities of the hosts to + support some of the features might make it difficult to implement a + comprehensive and consistent policy. + + The 802.11i [IEEE80211i] amendment has many components, the most + obvious of which are the two new data-confidentiality protocols, + Temporal Key Integrity Protocol (TKIP) and Counter-Mode/CBC-MAC + Protocol (CCMP). 802.11i also uses 802.1X's key-distribution system + to control access to the network. Because 802.11 handles unicast and + broadcast traffic differently, each traffic type has different + security concerns. With several data-confidentiality protocols and + the key distribution, 802.11i includes a negotiation process for + selecting the correct confidentiality protocol and key system for + each traffic type. Other features introduced include key caching and + pre-authentication. + + The 802.11i amendment is a step forward in wireless security. The + amendment adds stronger encryption, authentication, and key + management strategies that could make wireless data and systems more + secure. + + If any Layer 2 filters for Ethertypes are in place, the NAP must + permit the IPv6 Ethertype (0X86DD). + + The device that is the Layer 3 next hop for the subscribers (Access + or Edge Router) should protect the network and the other subscribers + against attacks by one of the provider 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 [IPv6-Security]. + + The Access and the Edge Router should protect their processing + resources against floods of valid customer control traffic such as: + RS, NS, and MLD Requests. Rate limiting should be implemented on all + + + + + +Asadullah, et al. Informational [Page 66] + +RFC 4779 ISP IPv6 Deployment Scenarios in BB January 2007 + + + 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 + + The necessary instrumentation (such as MIB modules, NetFlow Records, + etc) should be available for IPv6. + + Usually, NSPs manage the edge routers by SNMP. The SNMP transport + can be done over IPv4 if all managed devices have connectivity over + both IPv4 and IPv6. This would imply the smallest changes to the + existing network management practices and processes. Transport over + IPv6 could also be implemented and it might become necessary if IPv6 + only islands are present in the network. The management applications + may be running on hosts belonging to the NSP core network domain. + Network Management Applications should handle IPv6 in a similar + fashion to IPv4; however, they should also support features specific + to IPv6 (such as neighbor monitoring). + + In some cases, service providers manage equipment located on + customers' LANs. + +9. Broadband Power Line Communications (PLC) + + This section describes the IPv6 deployment in Power Line + Communications (PLC) Access Networks. There may be other choices, + but it seems that this is the best model to follow. Lessons learnt + from cable, Ethernet, and even WLAN access networks may be applicable + also. + + Power Line Communications are also often called Broadband Power Line + (BPL) and sometimes even Power Line Telecommunications (PLT). + + PLC/BPL can be used for providing, with today's technology, up to + 200Mbps (total, upstream+downstream) by means of the power grid. The + coverage is often the last half mile (typical distance from the + medium-to-low voltage transformer to the customer premise meter) and, + of course, as an in-home network (which is out of the scope of this + document). + + The bandwidth in a given PLC/BPL segment is shared among all the + customers connected to that segment (often the customers connected to + the same medium-to-low voltage transformer). The number of customers + can vary depending on different factors, such as distances and even + countries (from a few customers, just 5-6, up to 100-150). + + + + + +Asadullah, et al. Informational [Page 67] + +RFC 4779 ISP IPv6 Deployment Scenarios in BB January 2007 + + + PLC/BPL could also be used in the medium voltage network (often + configured as Metropolitan Area Networks), but this is also out of + the scope of this document, as it will be part of the core network, + not the access one. + +9.1. PLC/BPL Access Network Elements + + This section describes the different elements commonly used in PLC/ + BPL access networks. + + Head End (HE): Router that connects the PLC/BPL access network (the + power grid), located at the medium-to-low voltage transformer, to the + core network. The HE PLC/BPL interface appears to each customer as a + single virtual interface, all of them sharing the same physical + media. + + Repeater (RPT): A device that may be required in some circumstances + to improve the signal on the PLC/BPL. This may be the case if there + are many customers in the same segment or building. It is often a + bridge, but it could also be a router if, for example, there is a lot + of peer-to-peer traffic in a building and due to the master-slave + nature of the PLC/BPL technology, is required to improve the + performance within that segment. For simplicity within this + document, the RPT will always be considered a transparent Layer 2 + bridge, so it may or may not be present (from the Layer 3 point of + view). + + Customer Premise Equipment (CPE): Modem (internal to the host), + modem/bridge (BCPE), router (RCPE), or any combination among those + (i.e., modem+bridge/router), located at the customer premise. + + Edge Router (ER) + + Figure 9.1 depicts all the network elements indicated above. + + Customer Premise | Network Access Provider | Network Service Provider + + +-----+ +------+ +-----+ +------+ +--------+ + |Hosts|--| RCPE |--| RPT |--------+ Head +---+ Edge | ISP + +-----+ +------+ +-----+ | End | | Router +=>Network + +--+---+ +--------+ + +-----+ +------+ +-----+ | + |Hosts|--| BCPE |--| RPT |-----------+ + +-----+ +------+ +-----+ + + Figure 9.1 + + + + + +Asadullah, et al. Informational [Page 68] + +RFC 4779 ISP IPv6 Deployment Scenarios in BB January 2007 + + + The logical topology and design of PLC/BPL is very similar to + Ethernet Broadband Networks as discussed in Section 7. IP + connectivity is typically provided in a Point-to-Point model, as + described in Section 7.2.1 + +9.2. Deploying IPv6 in IPv4 PLC/BPL + + The most simplistic and efficient model, considering the nature of + the PLC/BPL networks, is to see the network as a point-to-point, one + to each customer. Even if several customers share the same physical + media, the traffic is not visible among them because each one uses + different channels, which are, in addition, encrypted by means of + 3DES. + + In order to maintain the deployment concepts and business models + proven and used with existing revenue-generating IPv4 services, the + IPv6 deployment will match the IPv4 one. Under certain circumstances + where new service types or service needs justify it, IPv4 and IPv6 + network architectures could be different. Both approaches are very + similar to those already described for the Ethernet case. + +9.2.1. IPv6 Related Infrastructure Changes + + In this scenario, only the RPT is Layer 3 unaware, but the other + devices have to be upgraded to dual stack Hosts, RCPE, Head End, and + Edge Router. + +9.2.2. Addressing + + The Hosts or the RCPEs have the HE as their Layer 3 next hop. + + If there is no RCPE, but instead a BCPE, all the hosts on the + subscriber site belong to the same /64 subnet that is statically + configured on the HE. The hosts can use stateless auto-configuration + or stateful DHCPv6-based configuration to acquire an address via the + HE. + + If an RCPE is present: + + A. It is statically configured with an address on the /64 subnet + between itself and the HE, 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. + + B. It can use its link-local address to communicate with the HE. It + can also dynamically acquire through stateless auto-configuration + the address for the link between itself and the HE. This step is + + + +Asadullah, et al. Informational [Page 69] + +RFC 4779 ISP IPv6 Deployment Scenarios in BB January 2007 + + + followed by a request via DHCP-PD for a prefix shorter than /64 + (typically /48 [RFC3177]) that, in turn, is divided in /64s and + assigned to its interfaces connecting the hosts on the customer + site. This should be the preferred provisioning method, being + cheaper and easier to manage. + + The Edge Router needs to have a prefix, considering that each + customer in general will receive a /48 prefix, and that each HE will + accommodate customers. Consequently, each HE will require n x /48 + prefixes. + + It could be possible to use a kind of Hierarchical Prefix Delegation + to automatically provision the required prefixes and fully auto- + configure the HEs, and consequently reduce the network setup, + operation, and maintenance cost. + + The prefixes used for subscriber links and the ones delegated via + DHCP-PD should be planned in a manner 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 [RFC3315] and stateless [RFC3736] DHCPv6. + +9.2.3. Routing + + If no routers are used on the customer premise, the HE can simply be + configured with a default route that points to the Edge Router. If a + router is used on the customer premise (RCPE), then the HE could also + run an IGP (such as OSPFv3, IS-IS or even RIPng) to the ER. The + connected prefixes should be redistributed. If DHCP-PD is used, with + every delegated prefix a static route is installed by the HE. For + this reason, the static routes must also be redistributed. Prefix + summarization should be done at the HE. + + The RCPE requires only a default route pointing to the HE. No + routing protocols are needed on these devices, which generally 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, as well as any + routing protocols (other than the ones used on the ER) that might be + used between the HE and the ER. + + + + + + + + + +Asadullah, et al. Informational [Page 70] + +RFC 4779 ISP IPv6 Deployment Scenarios in BB January 2007 + + +9.3. IPv6 Multicast + + The considerations regarding IPv6 Multicast for Ethernet are also + applicable here, in general, assuming the nature of PLC/BPL is a + shared media. If a lot of Multicast is expected, it may be worth + considering using RPT which are Layer 3 aware. In that case, one + extra layer of Hierarchical DHCP-PD could be considered, in order to + facilitate the deployment, operation, and maintenance of the network. + +9.4. IPv6 QoS + + The considerations introduced for QoS in Ethernet are also applicable + here. PLC/BPL networks support QoS, which basically is the same + whether the transport is IPv4 or IPv6. It is necessary to understand + that there are specific network characteristics, such as the + variability that may be introduced by electrical noise, towards which + the PLC/BPL network will automatically self-adapt. + +9.5. IPv6 Security Considerations + + There are no differences in terms of security considerations if + compared with the Ethernet case. + +9.6. IPv6 Network Management + + The issues related to IPv6 Network Management in PLC networks should + be similar to those discussed for Broadband Ethernet Networks in + Section 7.6. Note that there may be a need to define MIB modules for + PLC networks and interfaces, but this is not necessarily related to + IPv6 management. + +10. Gap Analysis + + Several aspects of deploying IPv6 over SP Broadband networks were + highlighted in this document, aspects that require additional work in + order to facilitate native deployments, as summarized below: + + A. As mentioned in section 5, changes will need to be made to the + DOCSIS specification in order for SPs to deploy native IPv6 over + cable networks. The CM and CMTS will both need to support IPv6 + natively in order to forward IPv6 unicast and multicast traffic. + This is required for IPv6 Neighbor Discovery to work over DOCSIS + cable networks. Additional classifiers need to be added to the + DOCSIS specification in order to classify IPv6 traffic at the CM + and CMTS in order to provide QoS. These issues are addressed in + a recent proposal made to Cable Labs for DOCSIS 3.0 + [DOCSIS3.0-Reqs]. + + + + +Asadullah, et al. Informational [Page 71] + +RFC 4779 ISP IPv6 Deployment Scenarios in BB January 2007 + + + B. Section 6 stated that current RBE-based IPv4 deployment might not + be the best approach for IPv6, where the addressing space + available gives the SP the opportunity to separate the users on + different subnets. The differences between IPv4 RBE and IPv6 RBE + were highlighted in Section 6. If, however, support and reason + are found for a deployment similar to IPv4 RBE, then the + environment becomes NBMA and the new feature should observe + RFC2491 recommendations. + + C. Section 6 discussed the constraints imposed on an LAA-based IPv6 + deployment by the fact that it is expected that the subscribers + keep their assigned prefix, regardless of LNS. A deployment + approach was proposed that would maintain the addressing schemes + contiguous and offers prefix summarization opportunities. The + topic could be further investigated for other solutions or + improvements. + + D. Sections 6 and 7 pointed out the limitations (previously + documented in [IPv6-Multicast]) in deploying inter-domain ASM; + however, SSM-based services seem more likely at this time. For + such SSM-based services of content delivery (video or audio), + mechanisms are needed to facilitate the billing and management of + listeners. The currently available feature of MLD AAA is + suggested; however, other methods or mechanisms might be + developed and proposed. + + E. In relation to Section 8, concerns have been raised related to + running IPv6 multicast over WLAN links. Potentially, these are + the same kind of issues when running any Layer 3 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 an + IGMP host membership report, when done on a WLAN link with high + loss-to-signal ratio and high interference. This problem is + inherited by WLAN that can impact both IPv4 and IPv6 multicast + packets; it is not specific to IPv6 multicast. + + F. The privacy extensions were mentioned as a popular means to + provide some form of host security. ISPs can track relatively + easily the prefixes assigned to subscribers. If, however, the + ISPs are required by regulations to track their users at host + address level, the privacy extensions [RFC3041] can be + implemented only in parallel with network management tools that + could provide traceability of the hosts. Mechanisms should be + defined to implement this aspect of user management. + + + + + + +Asadullah, et al. Informational [Page 72] + +RFC 4779 ISP IPv6 Deployment Scenarios in BB January 2007 + + + G. Tunnels are an effective way to avoid deployment dependencies on + the IPv6 support on platforms that are out of the SP control + (GWRs or CPEs) or over technologies that did not standardize the + IPv6 support yet (cable). They can be used in the following + ways: + + i. Tunnels directly to the CPE or GWR with public or private + IPv4 addresses. + + ii. Tunnels directly to hosts with public or private IPv4 + addresses. Recommendations on the exact tunneling + mechanisms that can/should be used for last-mile access need + to be investigated further and should be addressed by the + IETF Softwire Working Group. + + H. Through its larger address space, IPv6 allows SPs to assign + fixed, globally routable prefixes to the links connecting each + subscriber. + + This approach changes the provisioning methodologies that were + used for IPv4. Static configuration of the IPv6 addresses for + all these links on the Edge Routers or Access Routers might not + be a scalable option. New provisioning mechanisms or features + might need to be developed in order to deal with this issue, such + as automatic mapping of VLAN IDs/PVCs (or other customer-specific + information) to IPv6 prefixes. + + I. New deployment models are emerging for the Layer 2 portion of the + NAP where individual VLANs are not dedicated to each subscriber. + This approach allows Layer 2 switches to aggregate more then 4096 + users. MAC Forced Forwarding [RFC4562] is an example of such an + implementation, where a broadcast domain is turned into an NBMA- + like environment by forwarding the frames based on both Source + and Destination MAC addresses. Since these models are being + adopted by the field, the implications of deploying IPv6 in such + environments need to be further investigated. + + J. The deployment of IPv6 in continuously evolving access service + models raises some issues that may need further investigation. + Examples of such topics are [AUTO-CONFIG]: + + i. Network Service Selection & Authentication (NSSA) mechanisms + working in association with stateless auto-configuration. + As an example, NSSA relevant information, such as ISP + preference, passwords, or profile ID, can be sent by hosts + with the RS [RFC4191]. + + + + + +Asadullah, et al. Informational [Page 73] + +RFC 4779 ISP IPv6 Deployment Scenarios in BB January 2007 + + + ii. Providing additional information in Router Advertisements to + help access nodes with prefix selection in multi-ISP/ + multi-homed environments. + + Solutions to some of these topics range from making a media access + capable of supporting native IPv6 (cable) to improving operational + aspects of native IPv6 deployments. + +11. Security Considerations + + Please refer to the individual "IPv6 Security Considerations" + technology sections for details. + +12. Acknowledgements + + We would like to thank Brian Carpenter, Patrick Grossetete, Toerless + Eckert, Madhu Sudan, Shannon McFarland, Benoit Lourdelet, and Fred + Baker for their valuable comments. The authors would like to + acknowledge the structure and information guidance provided by the + work of Mickles, et al., on "Transition Scenarios for ISP Networks" + [ISP-CASES]. + +13. References + +13.1. Normative References + + [RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, + G., and E. Lear, "Address Allocation for Private + Internets", BCP 5, RFC 1918, February 1996. + + [RFC2080] Malkin, G. and R. Minnear, "RIPng for IPv6", + RFC 2080, January 1997. + + [RFC2364] Gross, G., Kaycee, M., Lin, A., Malis, A., and J. + Stephens, "PPP Over AAL5", RFC 2364, July 1998. + + [RFC2461] Narten, T., Nordmark, E., and W. Simpson, "Neighbor + Discovery for IP Version 6 (IPv6)", RFC 2461, + December 1998. + + [RFC2462] Thomson, S. and T. Narten, "IPv6 Stateless Address + Autoconfiguration", RFC 2462, December 1998. + + [RFC2473] Conta, A. and S. Deering, "Generic Packet Tunneling + in IPv6 Specification", RFC 2473, December 1998. + + + + + + +Asadullah, et al. Informational [Page 74] + +RFC 4779 ISP IPv6 Deployment Scenarios in BB January 2007 + + + [RFC2516] Mamakos, L., Lidl, K., Evarts, J., Carrel, D., + Simone, D., and R. Wheeler, "A Method for + Transmitting PPP Over Ethernet (PPPoE)", RFC 2516, + February 1999. + + [RFC2529] Carpenter, B. and C. Jung, "Transmission of IPv6 + over IPv4 Domains without Explicit Tunnels", + RFC 2529, March 1999. + + [RFC2661] Townsley, W., Valencia, A., Rubens, A., Pall, G., + Zorn, G., and B. Palter, "Layer Two Tunneling + Protocol "L2TP"", RFC 2661, August 1999. + + [RFC2740] Coltun, R., Ferguson, D., and J. Moy, "OSPF for + IPv6", RFC 2740, December 1999. + + [RFC2784] Farinacci, D., Li, T., Hanks, S., Meyer, D., and P. + Traina, "Generic Routing Encapsulation (GRE)", + RFC 2784, March 2000. + + [RFC3041] Narten, T. and R. Draves, "Privacy Extensions for + Stateless Address Autoconfiguration in IPv6", + RFC 3041, January 2001. + + [RFC3053] Durand, A., Fasano, P., Guardini, I., and D. Lento, + "IPv6 Tunnel Broker", RFC 3053, January 2001. + + [RFC3056] Carpenter, B. and K. Moore, "Connection of IPv6 + Domains via IPv4 Clouds", RFC 3056, February 2001. + + [RFC3177] IAB and IESG, "IAB/IESG Recommendations on IPv6 + Address Allocations to Sites", RFC 3177, + September 2001. + + [RFC3180] Meyer, D. and P. Lothberg, "GLOP Addressing in + 233/8", BCP 53, RFC 3180, September 2001. + + [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, + C., and M. Carney, "Dynamic Host Configuration + Protocol for IPv6 (DHCPv6)", RFC 3315, July 2003. + + [RFC3618] Fenner, B. and D. Meyer, "Multicast Source + Discovery Protocol (MSDP)", RFC 3618, October 2003. + + [RFC3704] Baker, F. and P. Savola, "Ingress Filtering for + Multihomed Networks", BCP 84, RFC 3704, March 2004. + + + + + +Asadullah, et al. Informational [Page 75] + +RFC 4779 ISP IPv6 Deployment Scenarios in BB January 2007 + + + [RFC3736] Droms, R., "Stateless Dynamic Host Configuration + Protocol (DHCP) Service for IPv6", RFC 3736, + April 2004. + + [RFC3904] Huitema, C., Austein, R., Satapati, S., and R. van + der Pol, "Evaluation of IPv6 Transition Mechanisms + for Unmanaged Networks", RFC 3904, September 2004. + + [RFC3931] Lau, J., Townsley, M., and I. Goyret, "Layer Two + Tunneling Protocol - Version 3 (L2TPv3)", RFC 3931, + March 2005. + + [RFC4001] Daniele, M., Haberman, B., Routhier, S., and J. + Schoenwaelder, "Textual Conventions for Internet + Network Addresses", RFC 4001, February 2005. + + [RFC4029] Lind, M., Ksinant, V., Park, S., Baudot, A., and P. + Savola, "Scenarios and Analysis for Introducing + IPv6 into ISP Networks", RFC 4029, March 2005. + + [RFC4191] Draves, R. and D. Thaler, "Default Router + Preferences and More-Specific Routes", RFC 4191, + November 2005. + + [RFC4213] Nordmark, E. and R. Gilligan, "Basic Transition + Mechanisms for IPv6 Hosts and Routers", RFC 4213, + October 2005. + + [RFC4214] Templin, F., Gleeson, T., Talwar, M., and D. + Thaler, "Intra-Site Automatic Tunnel Addressing + Protocol (ISATAP)", RFC 4214, October 2005. + + [RFC4380] Huitema, C., "Teredo: Tunneling IPv6 over UDP + through Network Address Translations (NATs)", + RFC 4380, February 2006. + +13.2. Informative References + + [6PE] De Clercq, J., Ooms, D., Prevost, S., and F. Le + Faucheur, "Connecting IPv6 Islands across IPv4 + Clouds with BGP", Work in Progress, December 2006. + + [AUTO-CONFIG] Wen, H., Zhu, X., Jiang, Y., and R. Yan, "The + deployment of IPv6 stateless auto-configuration in + access network", 8th International Conference on + Telecommunications, ConTEL 2005, June 2005. + + + + + +Asadullah, et al. Informational [Page 76] + +RFC 4779 ISP IPv6 Deployment Scenarios in BB January 2007 + + + [BSR] Bhaskar, N., Gall, A., Lingard, J., and S. Venaas, + "Bootstrap Router (BSR) Mechanism for PIM", Work + in Progress, June 2006. + + [DOCSIS3.0-OSSI] CableLabs, CL., "DOCSIS 3.0 OSSI Specification(CM- + SP-OSSIv3.0-D02-060504)", May 2006. + + [DOCSIS3.0-Reqs] Droms, R., Durand, A., Kharbanda, D., and J-F. + Mule, "DOCSIS 3.0 Requirements for IPv6 Support", + Work in Progress, March 2006. + + [DynamicTunnel] Palet, J., Diaz, M., and P. Savola, "Analysis of + IPv6 Tunnel End-point Discovery Mechanisms", Work + in Progress, January 2005. + + [IEEE80211i] IEEE, "IEEE Standards for Information Technology: + Part 11: Wireless LAN Medium Access Control (MAC) + and Physical Layer (PHY) specifications, Amendment + 6: Medium Access Control (MAC) Security + Enhancements", July 2004. + + [IEEE8021X] IEEE, "IEEE Standards for Local and Metropolitan + Area Networks: Port based Network Access Control, + IEEE Std 802.1X-2001", June 2001. + + [IPv6-Multicast] Savola, P., "IPv6 Multicast Deployment Issues", + Work in Progress, April 2004. + + [IPv6-Security] Convery, S. and D. Miller, "IPv6 and IPv4 Threat + Comparison and Best-Practice Evaluation", + March 2004. + + [ISISv6] Hopps, C., "Routing IPv6 with IS-IS", Work + in Progress, October 2005. + + [ISP-CASES] Mickles, C., "Transition Scenarios for ISP + Networks", Work in Progress, September 2002. + + [Protocol41] Palet, J., Olvera, C., and D. Fernandez, + "Forwarding Protocol 41 in NAT Boxes", Work + in Progress, October 2003. + + [RF-Interface] CableLabs, CL., "DOCSIS 2.0(CM-SP-RFIv2.0-I10- + 051209)", December 2005. + + [RFC4562] Melsen, T. and S. Blake, "MAC-Forced Forwarding: A + Method for Subscriber Separation on an Ethernet + Access Network", RFC 4562, June 2006. + + + +Asadullah, et al. Informational [Page 77] + +RFC 4779 ISP IPv6 Deployment Scenarios in BB January 2007 + + + [Softwire] Dawkins, S., Ed., "Softwire Problem Statement", + Work in Progress, May 2006. + + [v6tc] Palet, J., Nielsent, K., Parent, F., Durand, A., + Suryanarayanan, R., and P. Savola, "Goals for + Tunneling Configuration", Work in Progress, + August 2005. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Asadullah, et al. Informational [Page 78] + +RFC 4779 ISP IPv6 Deployment Scenarios in BB January 2007 + + +Authors' Addresses + + Salman Asadullah + Cisco Systems + 170 West Tasman Drive + San Jose, CA 95134 + USA + + Phone: 408 526 8982 + EMail: sasad@cisco.com + + + Adeel Ahmed + Cisco Systems + 2200 East President George Bush Turnpike + Richardson, TX 75082 + USA + + Phone: 469 255 4122 + EMail: adahmed@cisco.com + + + Ciprian Popoviciu + Cisco Systems + 7025-6 Kit Creek Road + Research Triangle Park, NC 27709 + USA + + Phone: 919 392 3723 + EMail: cpopovic@cisco.com + + + Pekka Savola + CSC - Scientific Computing Ltd. + Espoo + Finland + + EMail: psavola@funet.fi + + + + + + + + + + + + + +Asadullah, et al. Informational [Page 79] + +RFC 4779 ISP IPv6 Deployment Scenarios in BB January 2007 + + + Jordi Palet Martinez + Consulintel + San Jose Artesano, 1 + Alcobendas, Madrid E-28108 + Spain + + Phone: +34 91 151 81 99 + EMail: jordi.palet@consulintel.es + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Asadullah, et al. Informational [Page 80] + +RFC 4779 ISP IPv6 Deployment Scenarios in BB January 2007 + + +Full Copyright Statement + + Copyright (C) The IETF Trust (2007). + + 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. + + 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, THE IETF TRUST 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. + +Intellectual Property + + 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 described 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. + +Acknowledgement + + Funding for the RFC Editor function is currently provided by the + Internet Society. + + + + + + + +Asadullah, et al. Informational [Page 81] + |