idnits 2.17.1 draft-ietf-v6ops-bb-deployment-scenarios-05.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 20. -- Found old boilerplate from RFC 3978, Section 5.5 on line 3605. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 3582. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 3589. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 3595. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- == There are 31 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (June 7, 2006) is 6532 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 2461 (Obsoleted by RFC 4861) ** Obsolete normative reference: RFC 2462 (Obsoleted by RFC 4862) ** Downref: Normative reference to an Informational RFC: RFC 2516 ** Obsolete normative reference: RFC 2740 (Obsoleted by RFC 5340) ** Obsolete normative reference: RFC 2770 (Obsoleted by RFC 3180) ** Obsolete normative reference: RFC 3041 (Obsoleted by RFC 4941) ** Downref: Normative reference to an Informational RFC: RFC 3053 ** Obsolete normative reference: RFC 3177 (Obsoleted by RFC 6177) ** Obsolete normative reference: RFC 3315 (Obsoleted by RFC 8415) ** Downref: Normative reference to an Experimental RFC: RFC 3618 ** Obsolete normative reference: RFC 3736 (Obsoleted by RFC 8415) ** Downref: Normative reference to an Informational RFC: RFC 3904 ** Downref: Normative reference to an Informational RFC: RFC 4029 ** Obsolete normative reference: RFC 4214 (Obsoleted by RFC 5214) == Outdated reference: A later version (-07) exists of draft-ooms-v6ops-bgp-tunnel-04 == Outdated reference: A later version (-12) exists of draft-ietf-pim-sm-bsr-04 == Outdated reference: A later version (-07) exists of draft-ietf-isis-ipv6-06 == Outdated reference: A later version (-03) exists of draft-ietf-softwire-problem-statement-01 Summary: 17 errors (**), 0 flaws (~~), 7 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group S. Asadullah 3 Internet-Draft A. Ahmed 4 Expires: December 9, 2006 C. Popoviciu 5 Cisco Systems 6 P. Savola 7 CSC/FUNET 8 J. Palet 9 Consulintel 10 June 7, 2006 12 ISP IPv6 Deployment Scenarios in Broadband Access Networks 13 15 Status of this Memo 17 By submitting this Internet-Draft, each author represents that any 18 applicable patent or other IPR claims of which he or she is aware 19 have been or will be disclosed, and any of which he or she becomes 20 aware will be disclosed, in accordance with Section 6 of BCP 79. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF), its areas, and its working groups. Note that 24 other groups may also distribute working documents as Internet- 25 Drafts. 27 Internet-Drafts are draft documents valid for a maximum of six months 28 and may be updated, replaced, or obsoleted by other documents at any 29 time. It is inappropriate to use Internet-Drafts as reference 30 material or to cite them other than as "work in progress." 32 The list of current Internet-Drafts can be accessed at 33 http://www.ietf.org/ietf/1id-abstracts.txt. 35 The list of Internet-Draft Shadow Directories can be accessed at 36 http://www.ietf.org/shadow.html. 38 This Internet-Draft will expire on December 9, 2006. 40 Copyright Notice 42 Copyright (C) The Internet Society (2006). 44 Abstract 46 This document provides detailed description of IPv6 deployment and 47 integration methods and scenarios in today's Service Provider (SP) 48 Broadband (BB) networks in coexistence with deployed IPv4 services. 49 Cable/HFC, BB Ethernet, xDSL and WLAN are the main BB technologies 50 that are currently deployed, and discussed in this document. The 51 emerging Broadband Power Line Communications (PLC/BPL) access 52 technology is also discussed for completeness. In this document we 53 will discuss main components of IPv6 BB networks and their 54 differences from IPv4 BB networks and how IPv6 is deployed and 55 integrated in each of these networks using tunneling mechanisms and 56 native IPv6. 58 Table of Contents 60 1. Scope of the Document . . . . . . . . . . . . . . . . . . . . 4 61 2. Common Terminology . . . . . . . . . . . . . . . . . . . . . . 5 62 3. Core/Backbone Network . . . . . . . . . . . . . . . . . . . . 5 63 3.1. Layer 2 Access Provider Network . . . . . . . . . . . . . 5 64 3.2. Layer 3 Access Provider Network . . . . . . . . . . . . . 6 65 4. Tunneling Overview . . . . . . . . . . . . . . . . . . . . . . 7 66 4.1. Access over Tunnels - Customers with Public IPv4 67 Address . . . . . . . . . . . . . . . . . . . . . . . . . 7 68 4.2. Access over Tunnels - Customers with Private IPv4 69 Address . . . . . . . . . . . . . . . . . . . . . . . . . 8 70 4.3. Transition a Portion of the IPv4 Infrastructure . . . . . 8 71 5. Broadband Cable Networks . . . . . . . . . . . . . . . . . . . 9 72 5.1. Broadband Cable Network Elements . . . . . . . . . . . . . 9 73 5.2. Deploying IPv6 in Cable Networks . . . . . . . . . . . . . 10 74 5.2.1. Deploying IPv6 in a Bridged CMTS Network . . . . . . . 11 75 5.2.2. Deploying IPv6 in a Routed CMTS Network . . . . . . . 14 76 5.2.3. IPv6 Multicast . . . . . . . . . . . . . . . . . . . . 23 77 5.2.4. IPv6 QoS . . . . . . . . . . . . . . . . . . . . . . . 24 78 5.2.5. IPv6 Security Considerations . . . . . . . . . . . . . 24 79 5.2.6. IPv6 Network Management . . . . . . . . . . . . . . . 25 80 6. Broadband DSL Networks . . . . . . . . . . . . . . . . . . . . 26 81 6.1. DSL Network Elements . . . . . . . . . . . . . . . . . . . 26 82 6.2. Deploying IPv6 in IPv4 DSL Networks . . . . . . . . . . . 27 83 6.2.1. Point-to-Point Model . . . . . . . . . . . . . . . . . 28 84 6.2.2. PPP Terminated Aggregation (PTA) Model . . . . . . . . 30 85 6.2.3. L2TPv2 Access Aggregation (LAA) Model . . . . . . . . 32 86 6.2.4. Hybrid Model for IPv4 and IPv6 Service . . . . . . . . 35 87 6.3. IPv6 Multicast . . . . . . . . . . . . . . . . . . . . . . 37 88 6.3.1. ASM Based Deployments . . . . . . . . . . . . . . . . 38 89 6.3.2. SSM Based Deployments . . . . . . . . . . . . . . . . 38 90 6.4. IPv6 QoS . . . . . . . . . . . . . . . . . . . . . . . . . 39 91 6.5. IPv6 Security Considerations . . . . . . . . . . . . . . . 40 92 6.6. IPv6 Network management . . . . . . . . . . . . . . . . . 40 93 7. Broadband Ethernet Networks . . . . . . . . . . . . . . . . . 41 94 7.1. Ethernet Access Network Elements . . . . . . . . . . . . . 41 95 7.2. Deploying IPv6 in IPv4 Broadband Ethernet Networks . . . . 42 96 7.2.1. Point-to-Point Model . . . . . . . . . . . . . . . . . 43 97 7.2.2. PPP Terminated Aggregation (PTA) Model . . . . . . . . 45 98 7.2.3. L2TPv2 Access Aggregation (LAA) Model . . . . . . . . 47 99 7.2.4. Hybrid Model for IPv4 and IPv6 Service . . . . . . . . 48 100 7.3. IPv6 Multicast . . . . . . . . . . . . . . . . . . . . . . 51 101 7.4. IPv6 QoS . . . . . . . . . . . . . . . . . . . . . . . . . 52 102 7.5. IPv6 Security Considerations . . . . . . . . . . . . . . . 52 103 7.6. IPv6 Network Management . . . . . . . . . . . . . . . . . 53 104 8. Wireless LAN . . . . . . . . . . . . . . . . . . . . . . . . . 54 105 8.1. WLAN Deployment Scenarios . . . . . . . . . . . . . . . . 54 106 8.1.1. Layer 2 NAP with Layer 3 termination at NSP Edge 107 Router . . . . . . . . . . . . . . . . . . . . . . . . 55 108 8.1.2. Layer 3 aware NAP with Layer 3 termination at 109 Access Router . . . . . . . . . . . . . . . . . . . . 57 110 8.1.3. PPP Based Model . . . . . . . . . . . . . . . . . . . 60 111 8.2. IPv6 Multicast . . . . . . . . . . . . . . . . . . . . . . 62 112 8.3. IPv6 QoS . . . . . . . . . . . . . . . . . . . . . . . . . 63 113 8.4. IPv6 Security Considerations . . . . . . . . . . . . . . . 63 114 8.5. IPv6 Network Management . . . . . . . . . . . . . . . . . 65 115 9. Broadband Power Line Communications (PLC) . . . . . . . . . . 65 116 9.1. PLC/BPL Access Network Elements . . . . . . . . . . . . . 66 117 9.2. Deploying IPv6 in IPv4 PLC/BPL . . . . . . . . . . . . . . 67 118 9.2.1. IPv6 Related Infrastructure Changes . . . . . . . . . 67 119 9.2.2. Addressing . . . . . . . . . . . . . . . . . . . . . . 67 120 9.2.3. Routing . . . . . . . . . . . . . . . . . . . . . . . 68 121 9.3. IPv6 Multicast . . . . . . . . . . . . . . . . . . . . . . 69 122 9.4. IPv6 QoS . . . . . . . . . . . . . . . . . . . . . . . . . 69 123 9.5. IPv6 Security Considerations . . . . . . . . . . . . . . . 69 124 9.6. IPv6 Network Management . . . . . . . . . . . . . . . . . 69 125 10. Gap Analysis . . . . . . . . . . . . . . . . . . . . . . . . . 69 126 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 72 127 12. Security Considerations . . . . . . . . . . . . . . . . . . . 72 128 13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 72 129 14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 72 130 14.1. Normative References . . . . . . . . . . . . . . . . . . . 72 131 14.2. Informative References . . . . . . . . . . . . . . . . . . 74 132 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 77 133 Intellectual Property and Copyright Statements . . . . . . . . . . 79 135 1. Scope of the Document 137 This document presents the options available in deploying IPv6 138 services in the access portion of a BB Service Provider network 139 namely Cable/HFC, BB Ethernet, xDSL, WLAN and PLC/BPL. 141 This document briefly discusses the other elements of a provider 142 network as well. It provides different viable IPv6 deployment and 143 integration techniques and models for each of the above mentioned BB 144 technologies individually. The example list is not exhaustive but it 145 tries to be representative. 147 This document analyzes, how all the important components of current 148 IPv4 based Cable/HFC, BB Ethernet, xDSL, WLAN and PLC/BPL networks 149 will behave when IPv6 is integrated and deployed. 151 The following important pieces are discussed: 153 A. Available tunneling options 155 B. Devices that would require to be upgraded to support IPv6 157 C. Available IPv6 address assignment techniques and their use 159 D. Possible IPv6 Routing options and their use 161 E. IPv6 unicast and multicast packet transmission 163 F. Required IPv6 QoS parameters 165 G. Required IPv6 Security parameters 167 H. Required IPv6 Network Management parameters 169 It is important to note that the addressing rules provided throughout 170 this document represent an example that follows the current 171 assignment policies and recommendations of the registries. They can 172 be however adapted to the network and business model needs of the 173 ISPs. 175 The scope of the document is to advise on the ways of upgrading an 176 existing infrastructure to support IPv6 services. The recommendation 177 to upgrade a device to dual-stack does not stop an SP from adding a 178 new device to its network to perform the necessary IPv6 functions 179 discussed. The costs involved with such an approach could be offset 180 by lower impact on the existing IPv4 services. 182 2. Common Terminology 184 BB: Broadband 186 CPE: Customer Premise Equipment 188 GWR: Gateway Router 190 ISP: Internet Service Provider 192 NAP: Network Access Provider 194 NSP: Network Service Provider 196 QoS: Quality of Service 198 SP: Service Provider 200 3. Core/Backbone Network 202 This section intends to briefly discuss some important elements of a 203 provider network tied to the deployment of IPv6. A more detailed 204 description of the core network is provided in other documents 205 [RFC4029]. 207 There are two types of networks identified in the Broadband 208 deployments: 210 A. Access Provider Network: This network provides the broadband 211 access and aggregates the subscribers. The subscriber traffic is 212 handed over to the Service Provider at Layer 2 or 3. 214 B. Service Provider Network: This network provides Intranet and 215 Internet IP connectivity for the subscribers. 217 The Service Provider network structure beyond the Edge routers that 218 interface with the Access provider is beyond the scope of this 219 document. 221 3.1. Layer 2 Access Provider Network 223 The Access Provider can deploy a Layer 2 network and perform no 224 routing of the subscriber traffic to the SP. The devices that 225 support each specific access technology are aggregated into a highly 226 redundant, resilient and scalable Layer 2 core. The network core can 227 involve various technologies such as Ethernet, ATM etc. The Service 228 Provider Edge Router connects to the Access Provider core. 230 This type of network may be transparent to the Layer 3 protocol. 231 Some possible changes may come with the intent of supporting IPv6 232 provisioning mechanisms as well as filtering and monitoring IPv6 233 traffic based on layer 2 information such as IPv6 Ether Type Protocol 234 ID (0x86DD) or IPv6 multicast specific MAC addresses 235 (33:33:xx:xx:xx:xx). 237 3.2. Layer 3 Access Provider Network 239 The Access Provider can choose to terminate the Layer 2 domain and 240 route the IP traffic to the Service Provider network. Access Routers 241 are used to aggregate the subscriber traffic and route it over a 242 Layer 3 core to the SP Edge Routers. In this case the impact of the 243 IPv6 deployment is significant. 245 The case studies in this document discuss only the relevant network 246 elements of such a network: Customer Premise Equipment, Access Router 247 and Edge Router. In real networks the link between the Access Router 248 and the Edge Router involves other routers that are part of the 249 aggregation and the core layer of the Access Provider network. 251 The Access Provider can forward the IPv6 traffic through its layer 3 252 core in three possible ways: 254 A. IPv6 Tunneling: As a temporary solution, the Access Provider can 255 choose to use a tunneling mechanism to forward the subscriber IPv6 256 traffic to the Service Provider Edge Router. This approach has the 257 least impact on the Access Provider network however, as the number of 258 users increase and the amount of IPv6 traffic grows, the ISP will 259 have to evolve to one of the scenarios listed below. 261 B. Native IPv6 Deployment: The Access Provider routers are upgraded 262 to support IPv6 and can become dual-stack. In a dual-stack network 263 an IPv6 IGP such as OSPFv3 [RFC2740] or IS-IS [ISISv6] is enabled. 264 RFC4029 [RFC4029] discusses the IGP selection options with their 265 benefits and drawbacks. 267 C. MPLS 6PE Deployment [6PE]: If the Access Provider is running MPLS 268 in its IPv4 core it could use 6PE to forward IPv6 traffic over it. 269 In this case only a subset of routers close to the edge of the 270 network need to be IPv6 aware. With this approach BGP becomes 271 important in order to support 6PE. 273 The 6PE approach has the advantage of having minimal impact on the 274 Access Provider network. Fewer devices need to be upgraded and 275 configured while the MPLS core continues to switch the traffic un- 276 aware of the fact that it transports both IPv4 and IPv6. 6PE should 277 be leveraged only if MPLS is already deployed in the network. At the 278 time of writing this document, a major disadvantage of the 6PE 279 solution is the fact that it does not support multicast IPv6 traffic. 281 The native approach has the advantage of supporting IPv6 multicast 282 traffic but it may imply a significant impact on the IPv4 operational 283 network from software, configuration and possibly hardware upgrade 284 perspective. 286 More detailed Core Network deployment recommendations are discussed 287 in other documents [RFC4029]. The handling of IPv6 traffic in the 288 Core of the Access Provider Network will not be discussed for the 289 remainder of this document. 291 4. Tunneling Overview 293 If SPs are not able to deploy native IPv6, they might use tunneling 294 based transition mechanisms to start an IPv6 service offering and 295 move to native IPv6 deployment at a later time. 297 Several tunneling mechanisms were developed specifically to transport 298 IPv6 over existing IPv4 infrastructures. Several of them have been 299 standardized and their use depends on the existing SP IPv4 network 300 and the structure of the IPv6 service. The requirements for the most 301 appropriate mechanisms are described in [v6tc] with more updates to 302 follow. Deploying IPv6 using tunneling techniques can imply as 303 little changes to the network as upgrading software on tunnel end 304 points. A Service Provider could use tunneling to deploy IPv6 in the 305 following scenarios: 307 4.1. Access over Tunnels - Customers with Public IPv4 Address 309 If the customer is a residential user, it can initiate the tunnel 310 directly from the IPv6 capable host to a tunnel termination router 311 located in the NAP or ISP network. The tunnel type used should be 312 decided by the SP but it should take into consideration its 313 availability on commonly used software running on the host machine. 314 Out of the many tunneling mechanisms developed such as IPv6 Tunnel 315 Broker [RFC3053], Connection of IPv6 Domains via IPv4 Clouds 316 [RFC3056], Generic Packet Tunneling in IPv6 [RFC2473], ISATAP 317 [RFC4214], Basic Transition Mechanisms for IPv6 Hosts and Routers 318 [RFC4213] and Transmission of IPv6 over IPv4 Domains without Explicit 319 Tunnels [RFC2529] some are more popular than the others. At the time 320 of writing this document, the IETF Softwire Working Group was tasked 321 with standardizing a single tunneling protocol [Softwire] for this 322 application. 324 If the end customer has a GWR installed, then it could be used to 325 originate the tunnel and thus offer native IPv6 access to multiple 326 hosts on the customer network. In this case the GWR would need to be 327 upgraded to dual-stack in order to support IPv6. The GWR can be 328 owned by the customer or by the SP. 330 4.2. Access over Tunnels - Customers with Private IPv4 Address 332 If the end customer receives a private IPv4 address and needs to 333 initiate a tunnel through NAT, techniques like 6to4 may not work 334 since they rely on public IPv4 address. In this case, unless the 335 existing GWRs support protocol-41-forwarding [Protocol 41], the end 336 user might have to use tunnels that can operate through NATs (such as 337 Teredo [RFC4380]). Most GWRs support protocol-41-forwarding which 338 means that hosts can initiate the tunnels in which case the GWR is 339 not affected by the IPv6 service. 341 The customer has the option to initiate the tunnel from the device 342 (GWR) that performs the NAT functionality, similar to the GWR 343 scenario discussed in section 4.1. This will imply HW replacement or 344 SW upgrade and a native IPv6 environment behind the GWR. 346 It is also worth observing that initiating an IPv6 tunnel over IPv4 347 through already established IPv4 IPsec sessions would provide a 348 certain level of security to the IPv6 traffic. 350 4.3. Transition a Portion of the IPv4 Infrastructure 352 Tunnels can be used to transport the IPv6 traffic across a defined 353 segment of the network. As an example, the customer might connect 354 natively to the Network Access Provider and a tunnel is used to 355 transit the traffic over IPv4 to the ISP. In this case the tunnel 356 choice depends on its capabilities (for example, whether it supports 357 multicast or not), routing protocols used (there are several types 358 that can transport layer 2 messages such as GRE [RFC2784], L2TPv3 359 [RFC3931] or Pseudowire), manage-ability and scalability (dynamic 360 versus static tunnels). 362 This scenario implies that the access portion of the network has been 363 upgraded to support dual stack so the savings provided by tunneling 364 in this scenario are very small compared with the previous two 365 scenarios. Depending on the number of sites requiring the service 366 and considering the expenses required to manage the tunnels (some 367 tunnels are static while others are dynamic [Dynamic Tunnel]) in this 368 case, the SPs might find the native approach worth the additional 369 investments. 371 In all the scenarios listed above the tunnel selection process should 372 consider the IPv6 multicast forwarding capabilities if such service 373 is planned. As an example, 6to4 tunnels do not support IPv6 374 multicast traffic. 376 The operation, capabilities and deployment of various tunnel types 377 has been discussed extensively in the documents referenced earlier as 378 well as in [RFC4213], [RFC3904]. Details of a tunnel based 379 deployment are offered in the next section of this document which 380 discusses the case of Cable Access where the current DOCSIS 2.0 [RF 381 Interface] and prior specifications do not provide support for native 382 IPv6 access. Although sections 6, 7, 8 and 9 focus on a native IPv6 383 deployments over DSL, FTTH, Wireless and PLC/BPL because this 384 approach is fully supported today, tunnel based solutions are also 385 possible in these cases based on the guidelines of this section and 386 some of the recommendations provided in section 5. 388 5. Broadband Cable Networks 390 This section describes the infrastructure that exists today in cable 391 networks providing BB services to the home. It also describes IPv6 392 deployment options in these cable networks. 394 DOCSIS standardizes and documents the operation of data over Cable 395 Networks. DOCSIS 2.0 and prior specifications have limitations that 396 do not allow for a smooth implementation of native IPv6 transport. 397 Some of these limitations are discussed in this section. For this 398 reason, the IPv6 deployment scenarios discussed in this section for 399 the existing Cable Networks are tunnel based. The tunneling examples 400 presented here could also be applied to the other BB technologies 401 described in sections 6, 7, 8, and 9. 403 5.1. Broadband Cable Network Elements 405 Broadband cable networks are capable of transporting IP traffic to/ 406 from users to provide high speed Internet access and VOIP services. 407 The mechanism of transporting IP traffic over cable networks is 408 outlined in the DOCSIS specification [RF Interface]. 410 Here are some of the key elements of a Cable network: 412 Cable (HFC) Plant: Hybrid Fiber Coaxial plant, used as the underlying 413 transport 415 CMTS: Cable Modem Termination System (can be a Layer 2 bridging or 416 Layer 3 routing CMTS) 418 GWR: Residential Gateway Router (provides Layer 3 services to hosts) 419 Host: PC, notebook etc. which is connected to the CM or GWR 421 CM: Cable Modem 423 ER: Edge Router 425 MSO: Multiple Service Operator 427 Data Over Cable Service Interface Specification (DOCSIS): The 428 standards defining how data should be carried over cable networks. 430 Figure 5.1 illustrates the key elements of a Cable Network 432 |--- ACCESS ---||------ HFC ------||----- Aggregation / Core -----| 434 +-----+ +------+ 435 |Host |--| GWR | 436 +-----+ +--+---+ 437 | _ _ _ _ _ _ 438 +------+ | | 439 | CM |---| | 440 +------+ | | 441 | HFC | +------+ +--------+ 442 | | | | | Edge | 443 +-----+ +------+ | Network |---| CMTS |---| |=>ISP 444 |Host |--| CM |---| | | | | Router | Network 445 +-----+ +--+---+ | | +------+ +--------+ 446 |_ _ _ _ _ _| 447 +------+ | 448 +-----+ | GWR/ | | 449 |Host |--| CM |---------+ 450 +-----+ | | 451 +------+ Figure 5.1 453 5.2. Deploying IPv6 in Cable Networks 455 One of the motivators for an MSO to deploy IPv6 over its Cable 456 Network is to ease management burdens. IPv6 can be enabled on the 457 CM, CMTS and ER for management purposes. Currently portions of the 458 cable infrastructure use IPv4 address space [RFC1918]; however, there 459 are a finite number of those. Thus, IPv6 could have utility in the 460 cable space implemented on the management plane initially and later 461 on focused on the data plane for end user services. For more details 462 on using IPv6 for management in Cable Networks please refer to 463 section 5.6.1. 465 There are two different deployment modes in current cable networks: a 466 bridged CMTS environment and a routed CMTS environment. IPv6 can be 467 deployed in both of these environments. 469 1. Bridged CMTS Network 471 In this scenario, both the CM and CMTS bridge all data traffic. 472 Traffic to/from host devices is forwarded through the cable network 473 to the ER. The ER then routes traffic through the ISP network to the 474 Internet. The CM and CMTS support a certain degree of Layer 3 475 functionality for management purposes. 477 2. Routed CMTS Network 479 In a routed network, the CMTS forwards IP traffic to/from hosts based 480 on Layer 3 information using the IP source/destination address. The 481 CM acts as a Layer 2 bridge for forwarding data traffic and supports 482 some Layer 3 functionality for management purposes. 484 Some of the factors that hinder deployment of native IPv6 in current 485 routed and bridged cable networks include: 487 A. Changes need to be made to the DOCSIS specification [RF Interface] 488 to include support for IPv6 on the CM and CMTS. This is imperative 489 for deploying native IPv6 over cable networks. 491 B. Problems with IPv6 Neighbor Discovery (ND) on CM and CMTS. In 492 IPv4, these devices rely on IGMP join messages to track membership of 493 hosts that are part of a particular IP Multicast group. In order to 494 support ND, a multicast based process, the CM and CMTS will need to 495 support IGMPv3/MLDv2 or v1 snooping. 497 C. Classification of IPv6 traffic in the upstream and downstream 498 direction. The CM and CMTS will need to support classification of 499 IPv6 packets in order to give them the appropriate priority and QoS. 500 Service providers that wish to deploy QoS mechanisms also have to 501 support classification of IPv6 traffic. 503 Due to the above mentioned limitations in deployed cable networks, at 504 the time of writing this document the only option available for cable 505 operators is to use tunneling techniques in order to transport IPv6 506 traffic over their current IPv4 infrastructure. The following 507 sections will cover tunneling and native IPv6 deployment scenarios in 508 more detail. 510 5.2.1. Deploying IPv6 in a Bridged CMTS Network 512 In IPv4 the CM and CMTS act as Layer 2 bridges and forward all data 513 traffic to/from the hosts and the ER. The hosts use the ER as their 514 Layer 3 next hop. If there is a GWR behind the CM it can act as a 515 next hop for all hosts and forward data traffic to/from the ER. 517 When deploying IPv6 in this environment, the CM and CMTS will 518 continue to act as bridging devices in order to keep the transition 519 smooth and reduce operational complexity. The CM and CMTS will need 520 to bridge IPv6 unicast and multicast packets to/from the ER and the 521 hosts. If there is a GWR connected to the CM, it will need to 522 forward IPv6 unicast and multicast traffic to/from the ER. 524 IPv6 can be deployed in a bridged CMTS network either natively or via 525 tunneling. This section discusses the native deployment model. The 526 tunneling model is similar to ones described in sections 5.2.2.1 and 527 5.2.2.2. 529 Figure 5.2.1 illustrate the IPv6 deployment scenario 531 +-----+ +-----+ 532 |Host |--| GWR | 533 +-----+ +--+--+ 534 | _ _ _ _ _ _ 535 | +------+ | | 536 +--| CM |---| | 537 +------+ | | 538 | HFC | +------+ +--------+ 539 | | | | | Edge | 540 +-----+ +------+ | Network |---| CMTS |--| |=>ISP 541 |Host |--| CM |---| | | | | Router |Network 542 +-----+ +------+ | | +------+ +--------+ 543 |_ _ _ _ _ _| 544 |-------------||---------------------------------||---------------| 545 L3 Routed L2 Bridged L3 Routed 547 Figure 5.2.1 549 5.2.1.1. IPv6 Related Infrastructure Changes 551 In this scenario the CM and the CMTS bridge all data traffic so they 552 will need to support bridging of native IPv6 unicast and multicast 553 traffic. The following devices have to be upgraded to dual stack: 554 Host, GWR and ER. 556 5.2.1.2. Addressing 558 The proposed architecture for IPv6 deployment includes two components 559 that must be provisioned: the CM and the host. Additionally if there 560 is a GWR connected to the CM, it will also need to be provisioned. 561 The host or the GWR use the ER as their Layer 3 next hop. 563 5.2.1.2.1. IP Addressing for CM 565 The CM will be provisioned in the same way as in currently deployed 566 cable networks, using an IPv4 address on the cable interface 567 connected to the MSO network for management functions. During the 568 initialization phase, it will obtain its IPv4 address using DHCPv4, 569 and download a DOCSIS configuration file identified by the DHCPv4 570 server. 572 5.2.1.2.2. IP Addressing for Hosts 574 If there is no GWR connected to the CM, the host behind the CM will 575 get a /64 prefix via stateless auto-configuration or DHCPv6. 577 If using stateless auto-configuration, the host listens for routing 578 advertisements (RA) from the ER. The RAs contain the /64 prefix 579 assigned to the segment. Upon receipt of an RA, the host constructs 580 its IPv6 address by combining the prefix in the RA (/64) and a unique 581 identifier (e.g. its modified EUI-64 format interface ID). 583 If DHCPv6 is used to obtain an IPv6 address, it will work in much the 584 same way as DHCPv4 works today. The DHCPv6 messages exchanged 585 between the host and the DHCPv6 server are bridged by the CM and the 586 CMTS. 588 5.2.1.2.3. IP Addressing for GWR 590 The GWR can use stateless auto-configuration (RA) to obtain an 591 address for its upstream interface, the link between itself and the 592 ER. This step is followed by a request via DHCP-PD (Prefix 593 Delegation) for a prefix shorter than /64, typically /48 [RFC3177], 594 which in turn is divided into /64s and assigned to its downstream 595 interfaces connecting to the hosts. 597 5.2.1.3. Data Forwarding 599 The CM and CMTS must be able to bridge native IPv6 unicast and 600 multicast traffic. The CMTS must provide IP connectivity between 601 hosts attached to CMs and must do so in a way that meets the 602 expectation of Ethernet attached customer equipment. In order to do 603 that, the CM and CMTS must forward Neighbor Discovery (ND) packets 604 between ER and the hosts attached to the CM. 606 Communication between hosts behind different CMs is always forwarded 607 through the CMTS. IPv6 communication between the different sites 608 relies on multicast IPv6 ND [RFC2461] frames being forwarded 609 correctly by the CM and the CMTS. 611 In order to support IPv6 multicast applications across DOCSIS cable 612 networks, the CM and bridging CMTS need to support IGMPv3/MLDv2 or v1 613 snooping. MLD is almost identical to IGMP in IPv4, only the name and 614 numbers are changed. MLDv2 is identical to IGMPv3 and also supports 615 ASM (Any Source Multicast) and SSM (Single Source Multicast) service 616 models. Implementation work on CM/CMTS should be minimal because the 617 only significant difference between IPv4 IGMPv3 and IPv6 MLDv2 is the 618 longer addresses in the protocol. 620 5.2.1.4. Routing 622 The hosts install a default route that points to the ER or the GWR. 623 No routing protocols are needed on these devices which generally have 624 limited resources. If there is a GWR present it will also use static 625 default route to the ER. 627 The ER runs an IGP such as OSPFv3 or IS-IS. The connected prefixes 628 have to be redistributed. If DHCP-PD is used, with every delegated 629 prefix a static route is installed by the ER. For this reason the 630 static routes must also be redistributed. Prefix summarization 631 should be done at the ER. 633 5.2.2. Deploying IPv6 in a Routed CMTS Network 635 In an IPv4/IPv6 routed CMTS network the CM still acts as a Layer 2 636 device and bridges all data traffic between its Ethernet interface 637 and cable interface connected to the cable operator network. The 638 CMTS acts as a Layer 3 router and may also include the ER 639 functionality. The hosts and the GWR use the CMTS as their Layer 3 640 next hop. 642 When deploying IPv6, the CMTS/ER will need to either tunnel IPv6 643 traffic or natively support IPv6. 645 There are five possible deployment scenarios for IPv6 in a routed 646 CMTS network: 648 1. IPv4 Cable (HFC) Network 650 In this scenario the cable network, including the CM and CMTS remain 651 IPv4 devices. The host and ER are upgraded to dual-stack. This is 652 the easiest way for a Cable Operator to provide IPv6 service as no 653 changes are made to the cable network. 655 2. IPv4 Cable (HFC) Network, GWR at Customer Site 657 In this case the cable network, including the CM and CMTS remain IPv4 658 devices. The host, GWR and ER are upgraded to dual-stack. This 659 scenario is also easy to deploy since the cable operator just needs 660 to add GWR at the customer site. 662 3. Dual-stacked Cable (HFC) Network, CM and CMTS Support IPv6 664 In this scenario the CMTS is upgraded to dual-stack to support IPv4 665 and IPv6. Since the CMTS supports IPv6 it can act as an ER as well. 666 The CM will act as a Layer 2 bridge but will need to bridge IPv6 667 unicast and multicast traffic. This scenario is not easy to deploy 668 since it requires changes to the DOCSIS specification. The CM and 669 CMTS may require HW and SW upgrades to support IPv6. 671 4. Dual-stacked Cable (HFC) Network, Standalone GWR and CMTS Support 672 IPv6 674 In this scenario there is a standalone GWR connected to the CM. 675 Since the IPv6 functionality exists on the GWR the CM does not need 676 to be dual-stack. The CMTS is upgraded to dual-stack and it can 677 incorporate the ER functionality. This scenario may also require HW 678 and SW changes on the GWR and CMTS. 680 5. Dual-stacked Cable (HFC) Network, Embedded GWR/CM and CMTS 681 Support IPv6 683 In this scenario the CM and GWR functionality exists on a single 684 device which needs to be upgraded to dual-stack. The CMTS will also 685 need to be upgraded to a dual-stack device. This scenario is also 686 difficult to deploy in existing cable network since it requires 687 changes on the Embedded GWR/CM and the CMTS. 689 The DOCSIS specification will also need to be modified to allow 690 native IPv6 support on the Embedded GWR/CM. 692 5.2.2.1. IPv4 Cable Network, Host and ER Upgraded to Dual-Stack 694 This is one of the most cost effective ways for a Cable Operator to 695 offer IPv6 services to its customers. Since the cable network 696 remains IPv4 there is relatively minimal cost involved in turning up 697 IPv6 service. All IPv6 traffic is exchanged between the hosts and 698 the ER. 700 Figure 5.2.2.1 illustrates this deployment scenario 702 +-----------+ +------+ +--------+ 703 +-----+ +-------+ | Cable | | | | Edge | 704 |Host |--| CM |----| (HFC) |---| CMTS |---| |=>ISP 705 +-----+ +-------+ | Network | | | | Router |Network 706 +-----------+ +------+ +--------+ 707 _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ 708 ()_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _() 709 IPv6-in-IPv4 tunnel 711 |---------||---------------------------------------||------------| 712 IPv4/v6 IPv4 only IPv4/v6 714 Figure 5.2.2.1 716 5.2.2.1.1. IPv6 Related Infrastructure Changes 718 In this scenario the CM and the CMTS will only need to support IPv4 719 so no changes need to be made to them or the cable network. The 720 following devices have to be upgraded to dual stack: Host and ER. 722 5.2.2.1.2. Addressing 724 The only device that needs to be assigned an IPv6 address at customer 725 site is the host. Host address assignment can be done in multiple 726 ways. Depending on the tunneling mechanism used it could be 727 automatic or might require manual configuration. 729 The host still receives an IPv4 address using DHCPv4, which works the 730 same way in currently deployed cable networks. In order to get IPv6 731 connectivity, host devices will also need an IPv6 address and a means 732 to communicate with the ER. 734 5.2.2.1.3. Data Forwarding 736 All IPv6 traffic will be sent to/from the ER and the host device. In 737 order to transport IPv6 packets over the cable operator IPv4 network, 738 the host and the ER will need to use one of the available IPv6 in 739 IPv4 tunneling mechanisms. 741 The host will use its IPv4 address to source the tunnel to the ER. 742 All IPv6 traffic will be forwarded to the ER, encapsulated in IPv4 743 packets. The intermediate IPv4 nodes will forward this traffic as 744 regular IPv4 packets. The ER will need to terminate the tunnel 745 and/or provide other IPv6 services. 747 5.2.2.1.4. Routing 749 Routing configuration on the host will vary depending on the 750 tunneling technique used, in some cases a default or static route 751 might be needed to forward traffic to the next hop. 753 The ER runs an IGP such as OSPFv3 or ISIS. 755 5.2.2.2. IPv4 Cable Network, Host, GWR and ER Upgraded to Dual-Stack 757 The cable operator can provide IPv6 services to its customers, in 758 this scenario, by adding a GWR behind the CM. Since the GWR will 759 facilitate all IPv6 traffic between the host and the ER, the cable 760 network including the CM and CMTS do not need to support IPv6 and can 761 remain as IPv4 devices. 763 Figure 5.2.2.2 illustrates this deployment scenario 765 +-----+ 766 |Host | 767 +--+--+ 768 | +-----------+ +------+ +--------+ 769 +---+---+ +-------+ | Cable | | | | Edge | 770 | GWR |--| CM |----| (HFC) |---| CMTS |---| |=>ISP 771 +-------+ +-------+ | Network | | | | Router |Network 772 +-----------+ +------+ +--------+ 773 _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ 774 ()_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _() 775 IPv6-in-IPv4 tunnel 777 |---------||--------------------------------------||-------------| 778 IPv4/v6 IPv4 only IPv4/v6 780 Figure 5.2.2.2 782 5.2.2.2.1. IPv6 Related Infrastructure Changes 784 In this scenario the CM and the CMTS will only need to support IPv4 785 so no changes need to be made to them or the cable network. The 786 following devices have to be upgraded to dual stack: Host, GWR and 787 ER. 789 5.2.2.2.2. Addressing 791 The only devices that need to be assigned an IPv6 address at customer 792 site are the host and GWR. IPv6 address assignment can be done 793 statically at the GWR downstream interface. The GWR will send out RA 794 messages on its downstream interface which will be used by the hosts 795 to auto-configure themselves with an IPv6 address. The GWR can also 796 configure its upstream interface using RA messages from the ER and 797 use DHCP-PD for requesting a /48 [RFC3177] prefix from the ER. This 798 /48 prefix will be used to configure /64s on hosts connected to the 799 GWR downstream interfaces. The uplink to the ISP network is 800 configured with a /64 prefix as well. 802 The GWR still receives a global IPv4 address on its upstream 803 interface using DHCPv4, which works the same way in currently 804 deployed cable networks. In order to get IPv6 connectivity to the 805 Internet the GWR will need to communicate with the ER. 807 5.2.2.2.3. Data Forwarding 809 All IPv6 traffic will be sent to/from the ER and the GWR, which will 810 forward IPv6 traffic to/from the host. In order to transport IPv6 811 packets over the cable operator IPv4 network, the GWR and the ER will 812 need to use one of the available IPv6 in IPv4 tunneling mechanisms. 813 All IPv6 traffic will need to go through the tunnel, once it comes 814 up. 816 The GWR will use its IPv4 address to source the tunnel to the ER. 817 The tunnel endpoint will be the IPv4 address of the ER. All IPv6 818 traffic will be forwarded to the ER, encapsulated in IPv4 packets. 819 The intermediate IPv4 nodes will forward this traffic as regular IPv4 820 packets. In case of 6to4 tunneling, the ER will need to support 6to4 821 relay functionality in order to provide IPv6 Internet connectivity to 822 the GWR and hence the hosts connected to the GWR. 824 5.2.2.2.4. Routing 826 Depending on the tunneling technique used, additional configuration 827 might be needed on the GWR and the ER. If the ER is also providing a 828 6to4 relay service then a default route will need to be added to the 829 GWR pointing to the ER, for all non-6to4 traffic. 831 If using manual tunneling, the GWR and ER can use static routing or 832 an IGP such as RIPng [RFC2080]. The RIPng updates can be transported 833 over a manual tunnel, which does not work when using 6to4 tunneling 834 since it does not support multicast. 836 Customer routes can be carried to the ER using RIPng updates. The ER 837 can advertise these routes in its IGP. Prefix summarization should 838 be done at the ER. 840 If DHCP-PD is used for address assignment a static route is 841 automatically installed on the ER for each delegated /48 prefix. The 842 static routes need to be redistributed into the IGP at the ER, so 843 there is no need for a routing protocol between the ER and the GWR. 845 The ER runs an IGP such as OSPFv3 or ISIS. 847 5.2.2.3. Dual-stacked Cable (HFC) Network, CM and CMTS Support IPv6 849 In this scenario the Cable Operator can offer native IPv6 services to 850 its customers since the cable network including the CMTS supports 851 IPv6. The ER functionality can be included in the CMTS or it can 852 exist on a separate router connected to the CMTS upstream interface. 853 The CM will need to bridge IPv6 unicast and multicast traffic. 855 Figure 5.2.2.3 illustrates this deployment scenario 857 +-----------+ +-------------+ 858 +-----+ +-------+ | Cable | | CMTS / Edge | 859 |Host |--| CM |----| (HFC) |---| |=>ISP 860 +-----+ +-------+ | Network | | Router | Network 861 +-----------+ +-------------+ 863 |-------||---------------------------||---------------| 864 IPv4/v6 IPv4/v6 IPv4/v6 866 Figure 5.2.2.3 868 5.2.2.3.1. IPv6 Related Infrastructure Changes 870 Since the CM still acts as a Layer 2 bridge, it does not need to be 871 dual-stack. The CM will need to support bridging of IPv6 unicast and 872 multicast traffic and IGMPv3/MLDv2 or v1 snooping which requires 873 changes in the DOCSIS specification. In this scenario the following 874 devices have to be upgraded to dual stack: Host and CMTS/ER. 876 5.2.2.3.2. Addressing 878 In cable networks today the CM receives a private IPv4 address using 879 DHCPv4 for management purposes. In an IPv6 environment, the CM will 880 continue to use an IPv4 address for management purposes. The cable 881 operator can also choose to assign an IPv6 address to the CM for 882 management, but the CM will have to be upgraded to support this 883 functionality. 885 IPv6 address assignment for the CM and host can be done via DHCP or 886 stateless auto-configuration. If the CM uses an IPv4 address for 887 management, it will use DHCPv4 for its address assignment and the 888 CMTS will need to act as a DHCPv4 relay agent. If the CM uses an 889 IPv6 address for management, it can use DHCPv6 with the CMTS acting 890 as a DHCPv6 relay agent or the CMTS can be statically configured with 891 a /64 prefix and it can send out RA messages out the cable interface. 892 The CMs connected to the cable interface can use the RA messages to 893 auto-configure themselves with an IPv6 address. All CMs connected to 894 the cable interface will be in the same subnet. 896 The hosts can receive their IPv6 address via DHCPv6 or stateless 897 auto-configuration. With DHCPv6, the CMTS may need to act as a 898 DHCPv6 relay agent and forward DHCP messages between the hosts and 899 the DHCP server. With stateless auto-configuration, the CMTS will be 900 configured with multiple /64 prefixes and send out RA messages to the 901 hosts. If the CMTS is not also acting as an ER, the RA messages will 902 come from the ER connected to the CMTS upstream interface. The CMTS 903 will need to forward the RA messages downstream or act as an ND 904 proxy. 906 5.2.2.3.3. Data Forwarding 908 All IPv6 traffic will be sent to/from the CMTS and hosts. Data 909 forwarding will work the same way it works in currently deployed 910 cable networks. The CMTS will forward IPv6 traffic to/from hosts 911 based on the IP source/destination address. 913 5.2.2.3.4. Routing 915 No routing protocols are needed between the CMTS and the host since 916 the CM and host are directly connected to the CMTS cable interface. 917 Since the CMTS supports IPv6, hosts will use the CMTS as their Layer 918 3 next hop. 920 If the CMTS is also acting as an ER, it runs an IGP such as OSPFv3 or 921 ISIS. 923 5.2.2.4. Dual-Stacked Cable (HFC) Network, Standalone GWR and CMTS 924 Support IPv6 926 In this case the cable operator can offer IPv6 services to its 927 customers by adding a GWR between the CM and the host. The GWR will 928 facilitate IPv6 communication between the host and the CMTS/ER. The 929 CMTS will be upgraded to dual-stack to support IPv6 and can act as an 930 ER as well. The CM will act as a bridge for forwarding data traffic 931 and does not need to support IPv6. 933 This scenario is similar to the case described in section 5.2.2.2. 934 The only difference in this case is the ER functionality exists on 935 the CMTS instead of a separate router in the cable operator network. 937 Figure 5.2.2.4 illustrates this deployment scenario 939 +-----------+ +-----------+ 940 +------+ +-------+ +-------+ | Cable | |CMTS / Edge| 941 | Host |--| GWR |--| CM |---| (HFC) |---| |=>ISP 942 +------+ +-------+ +-------+ | Network | | Router |Network 943 +-----------+ +-----------+ 944 _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ 945 ()_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _() 946 IPv6-in-IPv4 tunnel 947 |-----------------||-----------------------------||--------------| 948 IPv4/v6 IPv4 IPv4/v6 950 Figure 5.2.2.4 952 5.2.2.4.1. IPv6 Related Infrastructure Changes 954 Since the CM still acts as a Layer 2 bridge, it does not need to be 955 dual-stack nor does it need to support IPv6. In this scenario the 956 following devices have to be upgraded to dual stack: Host, GWR and 957 CMTS/ER. 959 5.2.2.4.2. Addressing 961 The CM will still receive a private IPv4 address using DHCPv4 which 962 works the same way in existing cable networks. The CMTS will act as 963 DHCPv4 relay agent. 965 The address assignment for the host and GWR happens in a similar 966 manner as described in section 5.2.2.2.2. 968 5.2.2.4.3. Data Forwarding 970 Data forwarding between the host and CMTS/ER is facilitated by the 971 GWR and happens in a similar manner as described in section 972 5.2.2.2.3. 974 5.2.2.4.4. Routing 976 In this case routing is very similar to the case described in section 977 5.2.2.2.4. Since the CMTS now incorporates the ER functionality, it 978 will need to run an IGP such as OSPFv3 or ISIS. 980 5.2.2.5. Dual-Stacked Cable (HFC) Network, Embedded GWR/CM and CMTS 981 Support IPv6 983 In this scenario the Cable Operator can offer native IPv6 services to 984 its customers since the cable network including the CM/Embedded GWR 985 and CMTS support IPv6. The ER functionality can be included in the 986 CMTS or it can exist on a separate router connected to the CMTS 987 upstream interface. The CM/Embedded GWR acts as a Layer 3 device. 989 Figure 5.2.2.5 illustrates this deployment scenario 991 +-----------+ +-------------+ 992 +-----+ +-----------+ | Cable | | CMTS / Edge | 993 |Host |---| CM / GWR |---| (HFC) |---| |=>ISP 994 +-----+ +-----------+ | Network | | Router |Network 995 +-----------+ +-------------+ 997 |---------------------------------------------------------| 998 IPv4/v6 1000 Figure 5.2.2.5 1002 5.2.2.5.1. IPv6 Related Infrastructure Changes 1004 Since the CM/GWR acts as a Layer 3 device, IPv6 can be deployed end- 1005 to-end. In this scenario the following devices have to be upgraded 1006 to dual-stack: Host, CM/GWR and CMTS/ER. 1008 5.2.2.5.2. Addressing 1010 Since the CM/GWR is dual-stack, it can receive an IPv4 or IPv6 1011 address using DHCP for management purposes. As the GWR functionality 1012 is Embedded in the CM, it will need an IPv6 address for forwarding 1013 data traffic. IPv6 address assignment for the CM/GWR and host can be 1014 done via DHCPv6 or DHCP-PD. 1016 If using DHCPv6 the CMTS will need to act as DHCPv6 relay agent. The 1017 host and CM/GWR will receive IPv6 addresses from pools of /64 1018 prefixes configured on the DHCPv6 server. The CMTS will need to 1019 glean pertinent information from the DHCP Offer messages, sent from 1020 the DHCP server to the DHCP clients (host and CM/GWR), much like it 1021 does today in DHCPv4. All CM/GWR connected to the same cable 1022 interface on the CMTS belong to same management /64 prefix. The 1023 hosts connected to the same cable interface on the CMTS may belong to 1024 different /64 customer prefixes as the CMTS may have multiple /64 1025 prefixes configured under its cable interfaces. 1027 It is also possible to use DHCP-PD for IPv6 address assignment. In 1028 this case the CM/GWR will use stateless auto-configuration to assign 1029 an IPv6 address to its upstream interface using the /64 prefix sent 1030 by the CMTS/ER in RA message. Once the CM/GWR assigns an IPv6 1031 address to its upstream interface it will request a /48 [RFC3177] 1032 prefix from the CMTS/ER and chop this /48 prefix into /64s for 1033 assigning IPv6 addresses to hosts. The uplink to the ISP network is 1034 configured with a /64 prefix as well. 1036 5.2.2.5.3. Data Forwarding 1038 The host will use the CM/GWR as the Layer 3 next hop. The CM/GWR 1039 will forward all IPv6 traffic to/from the CMTS/ER and hosts. The 1040 CMTS/ER will forward IPv6 traffic to/from hosts based on the IP 1041 source/destination address. 1043 5.2.2.5.4. Routing 1045 The CM/GWR can use a static default route pointing to the CMTS/ER or 1046 it can run a routing protocol such as RIPng or OSPFv3 between itself 1047 and the CMTS. Customer routes from behind the CM/GWR can be carried 1048 to the CMTS using routing updates. 1050 If DHCP-PD is used for address assignment a static route is 1051 automatically installed on the CMTS/ER for each delegated /48 prefix. 1052 The static routes need to be redistributed into the IGP at the 1053 CMTS/ER so there is no need for a routing protocol between the 1054 CMTS/ER and the GWR. 1056 If the CMTS is also acting as an ER, it runs an IGP such as OSPFv3 or 1057 ISIS. 1059 5.2.3. IPv6 Multicast 1061 In order to support IPv6 multicast applications across DOCSIS cable 1062 networks, the CM and bridging CMTS will need to support IGMPv3/MLDv2 1063 or v1 snooping. MLD is almost identical to IGMP in IPv4, only the 1064 name and numbers are changed. MLDv2 is almost identical to IGMPv3 1065 and also supports ASM (Any Source Multicast) and SSM (Single Source 1066 Multicast) service models. 1068 SSM is more suited for deployments where the SP intends to provide 1069 paid content to the users (Video or Audio). This type of services 1070 are expected to be of primary interest. Moreover, the simplicity of 1071 the SSM model often times override the scalability issues that would 1072 be resolved in an ASM model. ASM is however an option that is 1073 discussed in section 6.3.1. The Layer 3 CM, GWR and Layer 3 routed 1074 CMTS/ER will need to be enabled with PIM-SSM, which requires the 1075 definition and support for IGMPv3/MLDv1 or v2 snooping, in order to 1076 track join/leave messages from the hosts. Another option would be 1077 for the Layer 3 CM or GWR to support MLD proxy routing. The Layer 3 1078 next hop for the hosts needs to support MLD. 1080 Refer to section 6.3 for more IPv6 multicast details. 1082 5.2.4. IPv6 QoS 1084 IPv6 will not change or add any queuing/scheduling functionality 1085 already existing in DOCSIS specifications. But the QoS mechanisms on 1086 the CMTS and CM would need to be IPv6 capable. This includes support 1087 for IPv6 classifiers, so that data traffic to/from host devices can 1088 be classified appropriately into different service flows and be 1089 assigned appropriate priority. Appropriate classification criteria 1090 would need to be implemented for unicast and multicast traffic. 1092 Traffic classification and marking should be done at the CM for 1093 upstream traffic and the CMTS/ER for downstream traffic in order to 1094 support the various types of services: data, voice and video. The 1095 same IPv4 QoS concepts and methodologies should be applied for IPv6 1096 as well. 1098 It is important to note that when traffic is encrypted end-to-end, 1099 the traversed network devices will not have access to many of the 1100 packet fields used for classification purposes. In these cases 1101 routers will most likely place the packets in the default classes. 1102 The QoS design should take into consideration this scenario and try 1103 to use mainly IP header fields for classification purposes. 1105 5.2.5. IPv6 Security Considerations 1107 Security in a DOCSIS cable network is provided using Baseline Privacy 1108 Plus (BPI+). The only part that is dependent on IP addresses is 1109 encrypted multicast. Semantically, multicast encryption would work 1110 the same way in an IPv6 environment as in the IPv4 network. However, 1111 appropriate enhancements will be needed in the DOCSIS specification 1112 to support encrypted IPv6 multicast. 1114 There are limited changes that have to be done for hosts in order to 1115 enhance security. The Privacy extensions [RFC3041] for auto- 1116 configuration should be used by the hosts. IPv6 firewall functions 1117 could be enabled, if available on the host or GWR. 1119 The ISP provides security against attacks that come from its own 1120 subscribers but it could also implement security services that 1121 protect its subscribers from attacks sourced from the outside of its 1122 network. Such services do not apply at the access level of the 1123 network discussed here. 1125 The CMTS/ER should protect the ISP network and the other subscribers 1126 against attacks by one of its own customers. For this reason Unicast 1127 Reverse Path Forwarding (uRPF) [RFC3704] and ACLs should be used on 1128 all interfaces facing subscribers. Filtering should be implemented 1129 with regard for the operational requirements of IPv6 [Security 1130 considerations for IPv6]. 1132 The CMTS/ER should protect its processing resources against floods of 1133 valid customer control traffic such as: Router and Neighbor 1134 Solicitations, MLD Requests. 1136 All other security features used with the IPv4 service should be 1137 similarly applied to IPv6 as well. 1139 5.2.6. IPv6 Network Management 1141 IPv6 can have many applications in Cable Networks. MSOs can 1142 initially implement IPv6 on the control plane and use it to manage 1143 the thousands of devices connected to the CMTS. This would be a good 1144 way to introduce IPv6 in a Cable Network. Later on the MSO can 1145 extend IPv6 to the data plane and use it to carry customer as well as 1146 management traffic. 1148 5.2.6.1. Using IPv6 for Management in Cable Networks 1150 IPv6 can be enabled in a Cable Network for management of devices like 1151 CM, CMTS and ER. With the roll out of advanced services like VoIP 1152 and Video-over-IP, MSOs are looking for ways to manage the large 1153 number of devices connected to the CMTS. In IPv4, an RFC1918 address 1154 is assigned to these devices for management purposes. Since there is 1155 a finite number of RFC1918 addresses available, it is becoming 1156 difficult for MSOs to manage these devices. 1158 By using IPv6 for management purposes, MSOs can scale their network 1159 management systems to meet their needs. The CMTS/ER can be 1160 configured with a /64 management prefix which is shared among all CMs 1161 connected to the CMTS cable interface. Addressing for the CMs can be 1162 done via stateless auto-configuration or DHCPv6. Once the CMs 1163 receive a /64 prefix they can configure themselves with an IPv6 1164 address. 1166 If there are devices behind the CM which need to be managed by the 1167 MSO, another /64 prefix can be defined on the CMTS/ER. These devices 1168 can also use stateless auto-configuration to assign themselves an 1169 IPv6 address. 1171 Traffic sourced from or destined to the management prefix should not 1172 cross the MSO's network boundaries. 1174 In this scenario IPv6 will only be used for managing devices on the 1175 Cable Network. The CM will no longer require an IPv4 address for 1176 management as described in DOCSIS 3.0 [DOCSIS 3.0 Requirements]. 1178 5.2.6.2. Updates to MIB modules/Standards to support IPv6 1180 The current DOCSIS, PacketCable, and CableHome MIB modules are 1181 already designed to support IPv6 objects. In this case, IPv6 will 1182 neither add, nor change any of the functionality of these MIB 1183 modules. The Textual Convention used to represent SMIv2 objects 1184 representing IP addresses was updated [RFC4001] and a new Textual 1185 Convention InetAddressType was added to identify the type of the IP 1186 address used for IP address objects in MIB modules. 1188 There are some exceptions, the MIB modules that might need to add 1189 IPv6 support are defined in the DOCSIS 3.0 OSSI specification [DOCSIS 1190 3.0 OSSI]. 1192 6. Broadband DSL Networks 1194 This section describes the IPv6 deployment options in today's High 1195 Speed DSL Networks. 1197 6.1. DSL Network Elements 1199 Digital Subscriber Line (DSL) broadband services provide users with 1200 IP connectivity over the existing twisted-pair telephone lines called 1201 the local-loop. A wide range of bandwidth offerings are available 1202 depending on the quality of the line and the distance between the 1203 Customer Premise Equipment and the DSLAM. 1205 The following network elements are typical of a DSL network: 1207 DSL Modem: It can be a stand alone device, it can be incorporated in 1208 the host, it can incorporate router functionalities and also have the 1209 capability to act as a CPE router. 1211 Customer Premise Router: It is used to provide Layer 3 services for 1212 customer premise networks. It is usually used to provide firewalling 1213 functions and segment broadcast domains for a Small business. 1215 DSL Access Multiplexer (DSLAM): It terminates multiple twisted pair 1216 telephone lines and provides aggregation to BRAS. 1218 Broadband Remote Access Server (BRAS): It aggregates or terminates 1219 multiple PVC corresponding to the subscriber DSL circuits. 1221 Edge Router (ER): It provides the Layer 3 interface to the ISP 1222 network. 1224 Figure 6.1 depicts all the network elements mentioned 1226 Customer Premise | Network Access Provider | Network Service Provider 1227 CP NAP NSP 1228 +-----+ +------+ +------+ +--------+ 1229 |Hosts|--|Router| +--+ BRAS +---+ Edge | ISP 1230 +-----+ +--+---+ | | | | Router +==> Network 1231 | | +------+ +--------+ 1232 +--+---+ | 1233 | DSL +-+ | 1234 |Modem | | | 1235 +------+ | +-----+ | 1236 +--+ | | 1237 +------+ |DSLAM+--+ 1238 +-----+ | DSL | +--+ | 1239 |Hosts|--+Modem +-+ +-----+ 1240 +-----+ +--+---+ 1241 Figure 6.1 1243 6.2. Deploying IPv6 in IPv4 DSL Networks 1245 There are three main design approaches to providing IPv4 connectivity 1246 over a DSL infrastructure: 1248 1. Point-to-Point Model: Each subscriber connects to the DSLAM over 1249 a twisted pair and is provided with a unique PVC that links it to the 1250 service provider. The PVCs can be terminated at the BRAS or at the 1251 Edge Router. This type of design is not very scalable if the PVCs 1252 are not terminated as close as possible to the DSLAM (at the BRAS). 1253 In this case a large number of Layer 2 circuits has to be maintained 1254 over a significant portion of the network. The Layer 2 domains can 1255 be terminated at the ER in three ways: 1257 A. In a common bridge group with a virtual interface that routes 1258 traffic out. 1260 B. Enable a Routed Bridged Encapsulation feature, all users could be 1261 part of the same subnet. This is the most common deployment approach 1262 of IPv4 over DSL but it might not be the best choice in IPv6 where 1263 address availability is not an issue. 1265 C. Terminate the PVC at Layer 3, each PVC has its own prefix. This 1266 is the approach that seems more suitable for IPv6 and is presented in 1267 6.2.1 In none of these cases the CPE (DSL Modem) has to be upgraded. 1269 2. PPP Terminated Aggregation (PTA) Model: PPP sessions are opened 1270 between each subscriber and the BRAS. The BRAS terminates the PPP 1271 sessions and provides Layer 3 connectivity between the subscriber and 1272 the ISP. This model is presented in section 6.2.2. 1274 3. L2TP Access Aggregation (LAA) Model: PPP sessions are opened 1275 between each subscriber and the ISP Edge Router. The BRAS tunnels 1276 the subscriber PPP sessions to the ISP by encapsulating them into 1277 L2TPv2 [RFC2661] tunnels. This model is presented in section 6.2.3. 1279 In aggregation models the BRAS terminates the subscriber PVCs and 1280 aggregates their connections before providing access to the ISP. 1282 In order to maintain the deployment concepts and business models 1283 proven and used with existing revenue generating IPv4 services, the 1284 IPv6 deployment will match the IPv4 one. This approach is presented 1285 in sections 6.2.1-3 that describe current IPv4 over DSL broadband 1286 access deployments. Under certain circumstances where new service 1287 types or service needs justify it, IPv4 and IPv6 network logical 1288 architectures could be different as described in section 6.2.4. 1290 6.2.1. Point-to-Point Model 1292 In this scenario the Ethernet frames from the Host or the Customer 1293 Premise Router are bridged over the PVC assigned to the subscriber. 1295 Figure 6.2.1 describes the protocol architecture of this model 1297 Customer Premise NAP NSP 1298 |-------------------------| |---------------| |------------------| 1299 +-----+ +-------+ +-----+ +--------+ +----------+ 1300 |Hosts|--+Router +--+ DSL +--+ DSLAM +--------+ Edge | ISP 1301 +-----+ +-------+ |Modem| +--------+ | Router +=>Network 1302 +-----+ +----------+ 1303 |----------------------------| 1304 ATM 1305 Figure 6.2.1 1307 6.2.1.1. IPv6 Related Infrastructure Changes 1309 In this scenario the DSL modem and the entire NAP is Layer 3 unaware, 1310 so no changes are needed to support IPv6. The following devices have 1311 to be upgraded to dual stack: Host, Customer Router (if present) and 1312 Edge Router. 1314 6.2.1.2. Addressing 1316 The Hosts or the Customer Routers have the Edge Router as their Layer 1317 3 next hop. 1319 If there is no Customer Router all the hosts on the subscriber site 1320 belong to the same /64 subnet that is statically configured on the 1321 Edge Router for that subscriber PVC. The hosts can use stateless 1322 auto-configuration or stateful DHCPv6 based configuration to acquire 1323 an address via the Edge Router. 1325 However, as manual configuration for each customer is a provisioning 1326 challenge, implementations are encouraged to develop mechanism(s) 1327 which automatically map the PVC (or some other customer-specific 1328 information) to an IPv6 subnet prefix, and advertise the customer- 1329 specific prefix to all the customers with minimal configuration. 1331 If a Customer Router is present: 1333 A. It is statically configured with an address on the /64 subnet 1334 between itself and the Edge Router, and with /64 prefixes on the 1335 interfaces connecting the hosts on the customer site. This is not a 1336 desired provisioning method being expensive and difficult to manage. 1338 B. It can use its link-local address to communicate with the ER. It 1339 can also dynamically acquire through stateless auto-configuration the 1340 prefix for the link between itself and the ER. The later option 1341 allows it to contact a remote DHCPv6 server if needed. This step is 1342 followed by a request via DHCP-PD for a prefix shorter than /64 that 1343 in turn is divided in /64s and assigned to its downstream interfaces. 1345 The Edge Router has a /64 prefix configured for each subscriber PVC. 1346 Each PVC should be enabled to relay DHCPv6 requests from the 1347 subscribers to DHCPv6 servers in the ISP network. The PVCs providing 1348 access for subscribers that use DHCP-PD as well, have to be enabled 1349 to support the feature. The uplink to the ISP network is configured 1350 with a /64 prefix as well. 1352 The prefixes used for subscriber links and the ones delegated via 1353 DHCP-PD should be planned in a manner that allows as much 1354 summarization as possible at the Edge Router. 1356 Other information of interest to the host, such as DNS, is provided 1357 through stateful DHCPv6 [RFC3315] and stateless DHCPv6 [RFC3736]. 1359 6.2.1.3. Routing 1361 The CPE devices are configured with a default route that points to 1362 the Edge router. No routing protocols are needed on these devices 1363 which generally have limited resources. 1365 The Edge Router runs the IPv6 IGP used in the NSP: OSPFv3 or IS-IS. 1366 The connected prefixes have to be redistributed. If DHCP-PD is used, 1367 with every delegated prefix a static route is installed by the Edge 1368 Router. For this reason the static routes must also be 1369 redistributed. Prefix summarization should be done at the Edge 1370 Router. 1372 6.2.2. PPP Terminated Aggregation (PTA) Model 1374 The PTA architecture relies on PPP-based protocols (PPPoA [RFC2364] 1375 and PPPoE [RFC2516]). The PPP sessions are initiated by Customer 1376 Premise Equipment and are terminated at the BRAS. The BRAS 1377 authorizes the session, authenticates the subscriber, and provides an 1378 IP address on behalf of the ISP. The BRAS then does Layer 3 routing 1379 of the subscriber traffic to the NSP Edge Router. 1381 When the NSP is also the NAP, the BRAS and NSP Edge Router could be 1382 the same piece of equipment and provide the above mentioned 1383 functionality. 1385 There are two types of PPP encapsulations that can be leveraged with 1386 this model: 1388 A. Connection using PPPoA 1390 Customer Premise NAP NSP 1391 |--------------------| |----------------------| |----------------| 1392 +-----------+ 1393 | AAA | 1394 +-------+ Radius | 1395 | | TACACS | 1396 | +-----------+ 1397 +-----+ +-------+ +--------+ +----+-----+ +-----------+ 1398 |Hosts|--+Router +------+ DSLAM +-+ BRAS +-+ Edge | 1399 +-----+ +-------+ +--------+ +----------+ | Router +=>Core 1400 |--------------------------| +-----------+ 1401 PPP 1402 Figure 6.2.2.1 1404 The PPP sessions are initiated by the Customer Premise Equipment. 1405 The BRAS authenticates the subscriber against a local or a remote 1406 database. Once the session is established, the BRAS provides an 1407 address and maybe a DNS server to the user, information acquired from 1408 the subscriber profile or from a DHCP server. 1410 This solution scales better then the Point-to-Point but since there 1411 is only one PPP session per ATM PVC, the subscriber can choose a 1412 single ISP service at a time. 1414 B. Connection using PPPoE 1416 Customer Premise NAP NSP 1417 |--------------------------| |-------------------| |---------------| 1418 +-----------+ 1419 | AAA | 1420 +-------+ Radius | 1421 | | TACACS | 1422 | +-----------+ 1423 | 1424 +-----+ +-------+ +--------+ +-----+----+ +-----------+ 1425 |Hosts|--+Router +-----------+ DSLAM +-+ BRAS +-+ Edge | C 1426 +-----+ +-------+ +--------+ +----------+ | Router +=>O 1427 | | R 1428 |--------------------------------| +-----------+ E 1429 PPP 1430 Figure 6.2.2.2 1432 The operation of PPPoE is similar to PPPoA with the exception that 1433 with PPPoE multiple sessions can be supported over the same PVC thus 1434 allowing the subscriber to connect to multiple services at the same 1435 time. The hosts can initiate the PPPoE sessions as well. It is 1436 important to remember that the PPPoE encapsulation reduces the IP MTU 1437 available for the customer traffic due to additional headers. 1439 The network design and operation of the PTA model is the same 1440 regardless of the PPP encapsulation type used. 1442 6.2.2.1. IPv6 Related Infrastructure Changes 1444 In this scenario the BRAS is Layer 3 aware and it has to be upgraded 1445 to support IPv6. Since the BRAS terminates the PPP sessions it has 1446 to support the implementation of these PPP protocols with IPv6. The 1447 following devices have to be upgraded to dual stack: Host, Customer 1448 Router (if present), BRAS and Edge Router. 1450 6.2.2.2. Addressing 1452 The BRAS terminates the PPP sessions and provides the subscriber with 1453 an IPv6 address from the defined pool for that profile. The 1454 subscriber profile for authorization and authentication can be 1455 located on the BRAS or on a AAA server. The Hosts or the Customer 1456 Routers have the BRAS as their Layer 3 next hop. 1458 The PPP session can be initiated by a host or by a Customer Router. 1459 In the latter case, once the session is established with the BRAS and 1460 an address is negotiated for the uplink to the BRAS, DHCP-PD can be 1461 used to acquire prefixes for the Customer Router other interfaces. 1463 The BRAS has to be enabled to support DHCP-PD and to relay the DHCPv6 1464 requests of the hosts on the subscriber sites. 1466 The BRAS has a /64 prefixes configured on the link to the Edge 1467 router. The Edge router links are also configured with /64 prefixes 1468 to provide connectivity to the rest of the ISP network. 1470 The prefixes used for subscriber and the ones delegated via DHCP-PD 1471 should be planned in a manner that allows maximum summarization at 1472 the BRAS. 1474 Other information of interest to the host, such as DNS, is provided 1475 through stateful [RFC3315] and stateless [RFC3736] DHCPv6. 1477 6.2.2.3. Routing 1479 The CPE devices are configured with a default route that points to 1480 the BRAS router. No routing protocols are needed on these devices 1481 which generally have limited resources. 1483 The BRAS runs an IGP to the Edge Router: OSPFv3 or IS-IS. Since the 1484 addresses assigned to the PPP sessions are represented as connected 1485 host routes, connected prefixes have to be redistributed. If DHCP-PD 1486 is used, with every delegated prefix a static route is installed by 1487 the Edge Router. For this reason the static routes must also be 1488 redistributed. Prefix summarization should be done at the BRAS. 1490 The Edge Router is running the IGP used in the ISP network: OSPFv3 or 1491 IS-IS. 1493 A separation between the routing domains of the ISP and the Access 1494 Provider is recommended if they are managed independently. 1495 Controlled redistribution will be needed between the Access Provider 1496 IGP and the ISP IGP. 1498 6.2.3. L2TPv2 Access Aggregation (LAA) Model 1500 In the LAA model the BRAS forwards the CPE initiated session to the 1501 ISP over an L2TPv2 tunnel established between the BRAS and the Edge 1502 Router. In this case the authentication, authorization and 1503 subscriber configuration are performed by the ISP itself. There are 1504 two types of PPP encapsulations that can be leveraged with this 1505 model: 1507 A. Connection via PPPoA 1509 Customer Premise NAP NSP 1510 |--------------------| |----------------------| |----------------| 1511 +-----------+ 1512 | AAA | 1513 +-------+ Radius | 1514 | | TACACS | 1515 | +-----+-----+ 1516 | | 1517 +-----+ +-------+ +--------+ +----+-----+ +-----+-----+ 1518 |Hosts|--+Router +------+ DSLAM +-+ BRAS +-+ Edge | 1519 +-----+ +-------+ +--------+ +----------+ | Router +=>Core 1520 +-----------+ 1521 |----------------------------------------| 1522 PPP 1523 |------------| 1524 L2TPv2 1525 Figure 6.2.3.1 1527 B. Connection via PPPoE 1529 Customer Premise NAP NSP 1530 |--------------------------| |--------------------| |---------------| 1531 +-----------+ 1532 | AAA | 1533 +------+ Radius | 1534 | | TACACS | 1535 | +-----+-----+ 1536 | | 1537 +-----+ +-------+ +--------+ +----+-----+ +----+------+ 1538 |Hosts|--+Router +-----------+ DSLAM +-+ BRAS +-+ Edge | C 1539 +-----+ +-------+ +--------+ +----------+ | Router +=>O 1540 | | R 1541 +-----------+ E 1542 |-----------------------------------------------| 1543 PPP 1544 |--------------| 1545 L2TPv2 1546 Figure 6.2.3.2 1548 The network design and operation of the PTA model is the same 1549 regardless of the PPP encapsulation type used. 1551 6.2.3.1. IPv6 Related Infrastructure Changes 1553 In this scenario the BRAS is forwarding the PPP sessions initiated by 1554 the subscriber over the L2TPv2 tunnel established to the LNS, the 1555 aggregation point in the ISP network. The L2TPv2 tunnel between the 1556 LAC and LNS can run over IPv6 or IPv4. These capabilities have to be 1557 supported on the BRAS. The following devices have to be upgraded to 1558 dual stack: Host, Customer Router and Edge Router. If the tunnel is 1559 set up over IPv6 then the BRAS must be upgraded to dual stack. 1561 6.2.3.2. Addressing 1563 The Edge router terminates the PPP sessions and provides the 1564 subscriber with an IPv6 address from the defined pool for that 1565 profile. The subscriber profile for authorization and authentication 1566 can be located on the Edge Router or on a AAA server. The Hosts or 1567 the Customer Routers have the Edge Router as their Layer 3 next hop. 1569 The PPP session can be initiated by a host or by a Customer Router. 1570 In the latter case, once the session is established with the Edge 1571 Router, DHCP-PD can be used to acquire prefixes for the Customer 1572 Router interfaces. The Edge Router has to be enabled to support 1573 DHCP-PD and to relay the DHCPv6 requests generated by the hosts on 1574 the subscriber sites. 1576 The BRAS has a /64 prefix configured on the link to the Edge router. 1577 The Edge router links are also configured with /64 prefixes to 1578 provide connectivity to the rest of the ISP network. Other 1579 information of interest to the host, such as DNS, is provided through 1580 stateful [RFC3315] and stateless [RFC3736] DHCPv6. 1582 It is important to note here a significant difference between this 1583 deployment for IPv6 versus IPv4. In the case of IPv4 the customer 1584 router or CPE can end up on any Edge Router (acting as LNS) where the 1585 assumption is that there are at least two of them for redundancy 1586 purposes. Once authenticated, the customer will be given an address 1587 from the IP pool of the ER (LNS) it connected to. This allows the 1588 ERs (LNSs) to aggregate the addresses handed out to the customers. 1589 In the case of IPv6, an important constraint that likely will be 1590 enforced is that the customer should keep its own address regardless 1591 of the ER (LNS) it connects to. This could significantly reduce the 1592 prefix aggregation capabilities of the ER (LNS). This is different 1593 than the current IPv4 deployment where addressing is dynamic in 1594 nature and the same user can get different addresses depending on the 1595 LNS it ends up connecting to. 1597 One possible solution is to ensure that a given BRAS will always 1598 connect to the same ER (LNS) unless that LNS is down. This means 1599 that customers from a given prefix range will always be connected to 1600 the same ER (primary if up or secondary if not). Each ER (LNS) can 1601 carry summary statements in their routing protocol configuration for 1602 the prefixes they are the primary ER (LNS) as well as for the ones 1603 for which they are the secondary. This way the prefixes will be 1604 summarized any time they become "active" on the ER (LNS). 1606 6.2.3.3. Routing 1608 The CPE devices are configured with a default route that points to 1609 the Edge router that terminates the PPP sessions. No routing 1610 protocols are needed on these devices which have generally limited 1611 resources. 1613 The BRAS runs an IPv6 IGP to the Edge Router: OSPFv3 or IS-IS. 1614 Different processes should be used if the NAP and the NSP are managed 1615 by different organizations. In this case, controlled redistribution 1616 should be enabled between the two domains. 1618 The Edge Router is running the IPv6 IGP used in the ISP network: 1619 OSPFv3 or IS-IS. 1621 6.2.4. Hybrid Model for IPv4 and IPv6 Service 1623 It was recommended throughout this section that the IPv6 service 1624 implementation should map the existing IPv4 one. This approach 1625 simplifies manageability and minimizes training needed for personnel 1626 operating the network. In certain circumstances such mapping is not 1627 feasible. This typically becomes the case when a Service Provider 1628 plans to expand its service offering with the new IPv6 deployed 1629 infrastructure. If this new service is not well supported in a 1630 network design such as the one used for IPv4 then a different design 1631 might be used for IPv6. 1633 An example of such circumstances is that of a provider using an LAA 1634 design for its IPv4 services. In this case all the PPP sessions are 1635 bundled and tunneled across the entire NAP infrastructure which is 1636 made of multiple BRAS routers, aggregation routers etc. The end 1637 point of these tunnels is the ISP Edge Router. If the provider 1638 decides to offer multicast services over such a design, it will face 1639 the problem of NAP resources being over utilized. The multicast 1640 traffic can be replicated only at the end of the tunnels by the Edge 1641 router and the copies for all the subscribers are carried over the 1642 entire NAP. 1644 A Modified Point-to-Point (as described in 6.2.4.2) or PTA model are 1645 more suitable to support multicast services because the packet 1646 replication can be done closer to the destination at the BRAS. Such 1647 topology saves NAP resources. 1649 In this sense IPv6 deployment can be viewed as an opportunity to 1650 build an infrastructure that might better support the expansion of 1651 services. In this case, an SP using the LAA design for its IPv4 1652 services might choose a modified Point-to-Point or PTA design for 1653 IPv6. 1655 6.2.4.1. IPv4 in LAA Model and IPv6 in PTA Model 1657 The coexistence of the two PPP based models, PTA and LAA, is 1658 relatively straight forward. The PPP sessions are terminated on 1659 different network devices for the IPv4 and IPv6 services. The PPP 1660 sessions for the existing IPv4 service deployed in an LAA model are 1661 terminated on the Edge Router. The PPP sessions for the new IPv6 1662 service deployed in a PTA model are terminated on the BRAS. 1664 The logical design for IPv6 and IPv4 in this hybrid model is 1665 presented in Figure 6.2.4.1. 1667 IPv6 |--------------------------| 1668 PPP +-----------+ 1669 | AAA | 1670 +-------+ Radius | 1671 | | TACACS | 1672 | +-----+-----+ 1673 | | 1674 +-----+ +-------+ +--------+ +----+-----+ +-----+-----+ 1675 |Hosts|--+Router +------+ DSLAM +-+ BRAS +-+ Edge | 1676 +-----+ +-------+ +--------+ +----------+ | Router +=>Core 1677 +-----------+ 1678 IPv4 |----------------------------------------| 1679 PPP 1680 |------------| 1681 L2TPv2 1682 Figure 6.2.4.1 1684 6.2.4.2. IPv4 in LAA Model and IPv6 in Modified Point-to-Point Model 1686 In this particular scenario the Point-to-Point model used for the 1687 IPv6 service is a modified version of the model described in section 1688 6.2.1. 1690 For the IPv4 service in LAA model, the PVCs are terminated on the 1691 BRAS and PPP sessions are terminated on the Edge Router (LNS). For 1692 IPv6 service in Point-to-Point model, the PVCs are terminated at the 1693 Edge Router as described in section 6.2.1. In this hybrid model, the 1694 Point-to-Point link could be terminated on the BRAS, a NAP owned 1695 device. The IPv6 traffic is then routed through the NAP network to 1696 the NSP. In order to have this hybrid model, the BRAS has to be 1697 upgraded to a dual-stack router. The functionalities of the Edge 1698 Router as described in section 6.2.1 are now implemented on the BRAS. 1700 The other aspect of this deployment model is the fact that the BRAS 1701 has to be capable of distinguishing between the IPv4 PPP traffic that 1702 has to be bridged across the L2TPv2 tunnel and the IPv6 packets that 1703 have to be routed to the NSP. The IPv6 Routing and Bridging 1704 Encapsulation (RBE) has to be enabled on all interfaces with PVCs 1705 supporting both IPv4 and IPv6 services in this hybrid design. 1707 The logical design for IPv6 and IPv4 in this hybrid model is 1708 presented in Figure 6.2.4.2. 1710 IPv6 |----------------| 1711 ATM +-----------+ 1712 | AAA | 1713 +-------+ Radius | 1714 | | TACACS | 1715 | +-----+-----+ 1716 | | 1717 +-----+ +-------+ +--------+ +----+-----+ +-----+-----+ 1718 |Hosts|--+Router +------+ DSLAM +-+ BRAS +-+ Edge | 1719 +-----+ +-------+ +--------+ +----------+ | Router +=>Core 1720 +-----------+ 1721 IPv4 |----------------------------------------| 1722 PPP 1723 |------------| 1724 L2TPv2 1725 Figure 6.2.4.2 1727 6.3. IPv6 Multicast 1729 The deployment of IPv6 multicast services relies on MLD, identical to 1730 IGMP in IPv4 and on PIM for routing. ASM (Any Source Multicast) and 1731 SSM (Single Source Multicast) service models operate almost the same 1732 as in IPv4. Both have the same benefits and disadvantages as in 1733 IPv4. Nevertheless, the larger address space and the scoped address 1734 architecture provide major benefits for multicast IPv6. Through 1735 RFC3306 the large address space provides the means to assign global 1736 multicast group addresses to organizations or users that were 1737 assigned unicast prefixes. It is a significant improvement with 1738 respect to the IPv4 GLOP mechanism [RFC2770]. 1740 This facilitates the deployment of multicast services. The 1741 discussion of this section applies to all the multicast sections in 1742 the document. 1744 6.3.1. ASM Based Deployments 1746 Any Source Multicast (ASM) is useful for Service Providers that 1747 intend to support the forwarding of multicast traffic of their 1748 customers. It is based on the PIM-SM protocol and it is more complex 1749 to manage because of the use of Rendezvous Points (RPs). With IPv6, 1750 static RP and BSR [BSR] can be used for RP-to-group mapping similar 1751 to IPv4. Additionally, the larger IPv6 address space allows for 1752 building up of group addresses that incorporate the address of the 1753 RP. This RP-to-group mapping mechanism is called Embedded RP and is 1754 specific to IPv6. 1756 In inter-domain deployments, Multicast Source Discovery Protocol 1757 (MSDP) [RFC3618] is an important element of IPv4 PIM-SM deployments. 1758 MSDP is meant to be a solution for the exchange of source 1759 registration information between RPs in different domains. This 1760 solution was intended to be temporary. This is one of the reasons 1761 why it was decided not to implement MSDP in IPv6 [IPv6 Multicast]. 1763 For multicast reachability across domains, Embedded RP can be used. 1764 As Embedded RP provides roughly the same capabilities as MSDP, but in 1765 a slightly different way, the best management practices for ASM 1766 multicast with embedded RP still remain to be developed. 1768 6.3.2. SSM Based Deployments 1770 Based on PIM-SSM, the Source Specific Multicast deployments do not 1771 need an RP and the related protocols (such as BSR or MSDP) but rely 1772 on the listeners to know the source of the multicast traffic they 1773 plan to receive. The lack of RP makes SSM not only simpler to 1774 operate but also robust, it is not impacted by RP failures or inter 1775 domain constraints. It is also has a higher level of security (No RP 1776 to be targeted by attacks). For more discussions on the topic of 1777 IPv6 multicast see [IPv6 Multicast]. 1779 The typical multicast services offered for residential and very small 1780 businesses is video/audio streaming where the subscriber joins a 1781 multicast group and receives the content. This type of service model 1782 is well supported through PIM-SSM which is very simple and easy to 1783 manage. PIM-SSM has to be enabled throughout the SP network. MLDv2 1784 is required for PIM-SSM support. Vendors can choose to implement 1785 features that allow routers to map MLDv1 group joins to predefined 1786 sources. 1788 Subscribers might use a set-top box that is responsible for the 1789 control piece of the multicast service (does group joins/leaves). 1791 The subscriber hosts can also join desired multicast groups as long 1792 as they are enabled to support MLDv1 or MLDv2. If a customer premise 1793 router is used then it has to be enabled to support MLDv1 and MLDv2 1794 in order to process the requests of the hosts. It has to be enabled 1795 to support PIM-SSM in order to send PIM joins/leaves up to its Layer 1796 3 next hop whether it is the BRAS or the Edge router. When enabling 1797 this functionality on a customer premise router, its limited 1798 resources should be taken into consideration. Another option would 1799 be for the customer premise router to support MLD proxy routing. 1801 The router that is the Layer 3 next hop for the subscriber (BRAS in 1802 the PTA model or the Edge router in the LAA and Point-to-Point model) 1803 has to be enabled to support MLDv1 and MLDv2 in order to process the 1804 requests coming from subscribers without customer premise routers. 1805 It has to be enabled for PIM-SSM in order to receive joins/leaves 1806 from customer routers and send joins/leaves to the next hop towards 1807 the multicast source (Edge router or the NSP core). 1809 MLD authentication, authorization and accounting is usually 1810 configured on the edge router in order to enable the ISP to control 1811 the subscriber access of the service and do billing for the content 1812 provided. Alternative mechanisms that would support these functions 1813 should be investigated further. 1815 6.4. IPv6 QoS 1817 The QoS configuration is particularly relevant on the router that 1818 represents the Layer 3 next hop for the subscriber (BRAS in the PTA 1819 model or the Edge router in the LAA and Point-to-Point model) in 1820 order to manage resources shared amongst multiple subscribers 1821 possibly with various service level agreements. 1823 In the DSL infrastructure it is expected that there is already a 1824 level of traffic policing and shaping implemented for IPv4 1825 connectivity. This is implemented throughout the NAP and it is 1826 beyond the scope of this document. 1828 On the BRAS or the Edge Router the subscriber facing interfaces have 1829 to be configure to police the inbound customer traffic and shape the 1830 traffic outbound to the customer based on the SLAs. Traffic 1831 classification and marking should also be done on the router closest 1832 (at Layer 3) to the subscriber in order to support the various types 1833 of customer traffic: data, voice, video and to optimally use the 1834 infrastructure resources. Each provider (NAP, NSP) could implement 1835 their own QoS policies and services so reclassification and marking 1836 might be performed at the boundary between the NAP and the NSP in 1837 order to make sure the traffic is properly handled by the ISP. The 1838 same IPv4 QoS concepts and methodologies should be applied with IPv6 1839 as well. 1841 It is important to note that when traffic is encrypted end-to-end, 1842 the traversed network devices will not have access to many of the 1843 packet fields used for classification purposes. In these cases 1844 routers will most likely place the packets in the default classes. 1845 The QoS design should take into consideration this scenario and try 1846 to use mainly IP header fields for classification purposes. 1848 6.5. IPv6 Security Considerations 1850 There are limited changes that have to be done for CPEs in order to 1851 enhance security. The Privacy extensions for auto-configuration 1852 [RFC3041] should be used by the hosts. ISPs can track the prefixes 1853 it assigns to subscribers relatively easily. If however the ISPs are 1854 required by regulations to track their users at /128 address level, 1855 the Privacy Extensions may be implemented in parallel with network 1856 management tools that could provide traceability of the hosts. IPv6 1857 firewall functions should be enabled on the hosts or customer premise 1858 router if present. 1860 The ISP provides security against attacks that come from its own 1861 subscribers but it could also implement security services that 1862 protect its subscribers from attacks sourced from the outside of its 1863 network. Such services do not apply at the access level of the 1864 network discussed here. 1866 The device that is the Layer 3 next hop for the subscribers (BRAS or 1867 Edge router) should protect the network and the other subscribers 1868 against attacks by one of the provider customers. For this reason 1869 uRPF and ACLs should be used on all interfaces facing subscribers. 1870 Filtering should be implemented with regard for the operational 1871 requirements of IPv6 [Security considerations for IPv6]. 1872 Authentication and authorization should be used wherever possible. 1874 The BRAS and the Edge Router should protect their processing 1875 resources against floods of valid customer control traffic such as: 1876 Router and Neighbor Solicitations, MLD Requests. Rate limiting 1877 should be implemented on all subscriber facing interfaces. The 1878 emphasis should be placed on multicast type traffic as it is most 1879 often used by the IPv6 control plane. 1881 All other security features used with the IPv4 service should be 1882 similarly applied to IPv6 as well. 1884 6.6. IPv6 Network management 1886 The necessary instrumentation (such as MIB modules, NetFlow Records 1887 etc) should be available for IPv6. 1889 Usually, NSPs manage the edge routers by SNMP. The SNMP transport 1890 can be done over IPv4 if all managed devices have connectivity over 1891 both IPv4 and IPv6. This would imply the smallest changes to the 1892 existing network management practices and processes. Transport over 1893 IPv6 could also be implemented and it might become necessary if IPv6 1894 only islands are present in the network. The management applications 1895 may be running on hosts belonging to the NSP core network domain. 1896 Network Management Applications should handle IPv6 in a similar 1897 fashion to IPv4, however, they should also support features specific 1898 to IPv6 (such as Neighbor monitoring). 1900 In some cases service providers manage equipment located on customers 1901 LANs. The management of equipment at customers' LANs is out of scope 1902 of this memo. 1904 7. Broadband Ethernet Networks 1906 This section describes the IPv6 deployment options in currently 1907 deployed Broadband Ethernet Access Networks. 1909 7.1. Ethernet Access Network Elements 1911 In environments that support the infrastructure deploying RJ-45 or 1912 fiber (Fiber to the Home (FTTH) service) to subscribers, 10/100 Mbps 1913 Ethernet broadband services can be provided. Such services are 1914 generally available in metropolitan areas, in multi tenant buildings 1915 where an Ethernet infrastructure can be deployed in a cost effective 1916 manner. In such environments Metro-Ethernet services can be used to 1917 provide aggregation and uplink to a Service Provider. 1919 The following network elements are typical of an Ethernet network: 1921 Access Switch: It is used as a Layer 2 access device for subscribers. 1923 Customer Premise Router: It is used to provide Layer 3 services for 1924 customer premise networks. 1926 Aggregation Ethernet Switches: Aggregates multiple subscribers. 1928 Broadband Remote Access Server (BRAS) 1930 Edge Router (ER) 1932 Figure 7.1 depicts all the network elements mentioned. 1934 Customer Premise | Network Access Provider | Network Service Provider 1935 CP NAP NSP 1937 +-----+ +------+ +------+ +--------+ 1938 |Hosts|--|Router| +-+ BRAS +--+ Edge | ISP 1939 +-----+ +--+---+ | | | | Router +===> Network 1940 | | +------+ +--------+ 1941 +--+----+ | 1942 |Access +-+ | 1943 |Switch | | | 1944 +-------+ | +------+ | 1945 +--+Agg E | | 1946 +-------+ |Switch+-+ 1947 +-----+ |Access | +--+ | 1948 |Hosts|--+Switch +-+ +------+ 1949 +-----+ +-------+ 1950 Figure 7.1 1952 The logical topology and design of Broadband Ethernet Networks is 1953 very similar to DSL Broadband Networks discussed in section 6. 1955 It is worth noting that the general operation, concepts and 1956 recommendations described in this section apply similarly to a 1957 HomePNA based network environment. In such an environment some of 1958 the network elements might be differently named. 1960 7.2. Deploying IPv6 in IPv4 Broadband Ethernet Networks 1962 There are three main design approaches to providing IPv4 connectivity 1963 over an Ethernet infrastructure: 1965 A. Point-to-Point Model: Each subscriber connects to the network 1966 Access switch over RJ-45 or fiber links. Each subscriber is assigned 1967 a unique VLAN on the access switch. The VLAN can be terminated at 1968 the BRAS or at the Edge Router. The VLANs are 802.1Q trunked to the 1969 Layer 3 device (BRAS or Edge Router). 1971 This model is presented in section 7.2.1. 1973 B. PPP Terminated Aggregation (PTA) Model: PPP sessions are opened 1974 between each subscriber and the BRAS. The BRAS terminates the PPP 1975 sessions and provides Layer 3 connectivity between the subscriber and 1976 the ISP. 1978 This model is presented in section 7.2.2. 1980 C. L2TPv2 Access Aggregation (LAA) Model: PPP sessions are opened 1981 between each subscriber and the ISP termination devices. The BRAS 1982 tunnels the subscriber PPP sessions to the ISP by encapsulating them 1983 into L2TPv2 tunnels. 1985 This model is presented in section 7.2.3. 1987 In aggregation models the BRAS terminates the subscriber VLANs and 1988 aggregates their connections before providing access to the ISP. 1990 In order to maintain the deployment concepts and business models 1991 proven and used with existing revenue generating IPv4 services, the 1992 IPv6 deployment will match the IPv4 one. This approach is presented 1993 in sections 7.2.1-3 that describe currently deployed IPv4 over 1994 Ethernet broadband access deployments. Under certain circumstances 1995 where new service types or service needs justify it, IPv4 and IPv6 1996 network architectures could be different as described in section 1997 7.2.4. 1999 7.2.1. Point-to-Point Model 2001 In this scenario the Ethernet frames from the Host or the Customer 2002 Premise Router are bridged over the VLAN assigned to the subscriber. 2004 Figure 7.2.1 describes the protocol architecture of this model. 2006 | Customer Premise | | NAP | NSP | 2008 +-----+ +------+ +------+ +--------+ +----------+ 2009 |Hosts|--+Router+--+Access+--+ Switch +--------+ Edge | ISP 2010 +-----+ +------+ |Switch| +--------+ 802.1Q | Router +=>Network 2011 +------+ +----------+ 2013 |----------------------------| 2014 Ethernet/VLANs 2016 Figure 7.2.1 2018 7.2.1.1. IPv6 Related Infrastructure Changes 2020 In this scenario the Access Switch on the customer site and the 2021 entire NAP is Layer 3 unaware so no changes are needed to support 2022 IPv6. The following devices have to be upgraded to dual stack: Host, 2023 Customer Router and Edge Router. 2025 The Access switches might need upgrades to support certain IPv6 2026 related features such as MLD Snooping. 2028 7.2.1.2. Addressing 2030 The Hosts or the Customer Routers have the Edge Router as their Layer 2031 3 next hop. If there is no Customer Router all the hosts on the 2032 subscriber site belong to the same /64 subnet that is statically 2033 configured on the Edge Router for that subscriber VLAN. The hosts 2034 can use stateless auto-configuration or stateful DHCPv6 based 2035 configuration to acquire an address via the Edge Router. 2037 However, as manual configuration for each customer is a provisioning 2038 challenge, implementations are encouraged to develop mechanism(s) 2039 which automatically map the VLAN (or some other customer-specific 2040 information) to an IPv6 subnet prefix, and advertise the customer- 2041 specific prefix to all the customers with minimal configuration. 2043 If a Customer Router is present: 2045 A. It is statically configured with an address on the /64 subnet 2046 between itself and the Edge Router, and with /64 prefixes on the 2047 interfaces connecting the hosts on the customer site. This is not a 2048 desired provisioning method being expensive and difficult to manage. 2050 B. It can use its link-local address to communicate with the ER. It 2051 can also dynamically acquire through stateless auto-configuration the 2052 address for the link between itself and the ER. This step is 2053 followed by a request via DHCP-PD for a prefix shorter than /64 that 2054 in turn is divided in /64s and assigned to its interfaces connecting 2055 the hosts on the customer site. 2057 The Edge Router has a /64 prefix configured for each subscriber VLAN. 2058 Each VLAN should be enabled to relay DHCPv6 requests from the 2059 subscribers to DHCPv6 servers in the ISP network. The VLANs 2060 providing access for subscribers that use DHCP-PD as well, have to be 2061 enabled to support the feature. The uplink to the ISP network is 2062 configured with a /64 prefix as well. 2064 The prefixes used for subscriber links and the ones delegated via 2065 DHCP-PD should be planned in a manner that allows as much 2066 summarization as possible at the Edge Router. 2068 Other information of interest to the host, such as DNS, is provided 2069 through stateful [RFC3315] and stateless [RFC3736] DHCPv6. 2071 7.2.1.3. Routing 2073 The CPE devices are configured with a default route that points to 2074 the Edge router. No routing protocols are needed on these devices 2075 which generally have limited resources. 2077 The Edge Router runs the IPv6 IGP used in the NSP: OSPFv3 or IS-IS. 2078 The connected prefixes have to be redistributed. If DHCP-PD is used, 2079 with every delegated prefix a static route is installed by the Edge 2080 Router. For this reason the static routes must also be 2081 redistributed. Prefix summarization should be done at the Edge 2082 Router. 2084 7.2.2. PPP Terminated Aggregation (PTA) Model 2086 The PTA architecture relies on PPP-based protocols (PPPoE). The PPP 2087 sessions are initiated by Customer Premise Equipment and it is 2088 terminated at the BRAS. The BRAS authorizes the session, 2089 authenticates the subscriber, and provides an IP address on behalf of 2090 the ISP. The BRAS then does Layer 3 routing of the subscriber 2091 traffic to the NSP Edge Router. 2093 When the NSP is also the NAP, the BRAS and NSP Edge Router could be 2094 the same piece of equipment and provide the above mentioned 2095 functionality. 2097 The PPPoE logical diagram in an Ethernet Broadband Network is shown 2098 in Fig 7.2.2.1. 2100 | Customer Premise | | NAP | | NSP | 2102 +-----------+ 2103 | AAA | 2104 +-------+ Radius | 2105 | | TACACS | 2106 | +-----------+ 2107 +-----+ +-------+ +--------+ +--------+ +----+-----+ +-----------+ 2108 |Hosts|-+Router +-+A Switch+-+ Switch +-+ BRAS +-+ Edge | C 2109 +-----+ +-------+ +--------+ +--------+ +----------+ | Router +=>O 2110 |---------------- PPP ----------------| | | R 2111 +-----------+ E 2112 Figure 7.2.2.1 2114 The PPP sessions are initiated by the Customer Premise Equipment 2115 (Host or Router). The BRAS authenticates the subscriber against a 2116 local or a remote database. Once the session is established, the 2117 BRAS provides an address and maybe a DNS server to the user, 2118 information acquired from the subscriber profile or from a DHCP 2119 server. 2121 This model allows for multiple PPPoE sessions to be supported over 2122 the same VLAN thus allowing the subscriber to connect to multiple 2123 services at the same time. The hosts can initiate the PPPoE sessions 2124 as well. It is important to remember that the PPPoE encapsulation 2125 reduces the IP MTU available for the customer traffic. 2127 7.2.2.1. IPv6 Related Infrastructure Changes 2129 In this scenario the BRAS is Layer 3 aware and it has to be upgraded 2130 to support IPv6. Since the BRAS terminates the PPP sessions it has 2131 to support PPPoE with IPv6. The following devices have to be 2132 upgraded to dual stack: Host, Customer Router (if present), BRAS and 2133 Edge Router. 2135 7.2.2.2. Addressing 2137 The BRAS terminates the PPP sessions and provides the subscriber with 2138 an IPv6 address from the defined pool for that profile. The 2139 subscriber profile for authorization and authentication can be 2140 located on the BRAS or on a AAA server. The Hosts or the Customer 2141 Routers have the BRAS as their Layer 3 next hop. 2143 The PPP session can be initiated by a host or by a Customer Router. 2144 In the latter case, once the session is established with the BRAS, 2145 DHCP-PD can be used to acquire prefixes for the Customer Router 2146 interfaces. The BRAS has to be enabled to support DHCP-PD and to 2147 relay the DHCPv6 requests of the hosts on the subscriber sites. 2149 The BRAS has a /64 prefix configured on the link facing the Edge 2150 router. The Edge router links are also configured with /64 prefixes 2151 to provide connectivity to the rest of the ISP network. 2153 The prefixes used for subscriber and the ones delegated via DHCP-PD 2154 should be planned in a manner that allows maximum summarization at 2155 the BRAS. 2157 Other information of interest to the host, such as DNS, is provided 2158 through stateful [RFC3315] and stateless [RFC3736] DHCPv6. 2160 7.2.2.3. Routing 2162 The CPE devices are configured with a default route that points to 2163 the BRAS router. No routing protocols are needed on these devices 2164 which generally have limited resources. 2166 The BRAS runs an IGP to the Edge Router: OSPFv3 or IS-IS. Since the 2167 addresses assigned to the PPP sessions are represented as connected 2168 host routes, connected prefixes have to be redistributed. If DHCP-PD 2169 is used, with every delegated prefix a static route is installed by 2170 the BRAS. For this reason the static routes must also be 2171 redistributed. Prefix summarization should be done at the BRAS. 2173 The Edge Router is running the IGP used in the ISP network: OSPFv3 or 2174 IS-IS. A separation between the routing domains of the ISP and the 2175 Access Provider is recommended if they are managed independently. 2176 Controlled redistribution will be needed between the Access Provider 2177 IGP and the ISP IGP. 2179 7.2.3. L2TPv2 Access Aggregation (LAA) Model 2181 In the LAA model the BRAS forwards the CPE initiated session to the 2182 ISP over an L2TPv2 tunnel established between the BRAS and the Edge 2183 Router. In this case the authentication, authorization and 2184 subscriber configuration are performed by the ISP itself. 2186 | Customer Premise | | NAP | | NSP | 2188 +-----------+ 2189 | AAA | 2190 +------+ Radius | 2191 | | TACACS | 2192 | +-----+-----+ 2193 | | 2194 +-----+ +-------+ +--------+ +--------+ +----+-----+ +-----------+ 2195 |Hosts|-+Router +-+A Switch+-+ Switch +-+ BRAS +-+ Edge | C 2196 +-----+ +-------+ +--------+ +--------+ +----------+ | Router +=>O 2197 | | R 2198 +-----------+ E 2199 |-----------------------------------------------| 2200 PPP 2201 |--------------| 2202 L2TPv2 2203 Figure 7.2.3.1 2205 7.2.3.1. IPv6 Related Infrastructure Changes 2207 In this scenario the BRAS is Layer 3 aware and it has to be upgraded 2208 to support IPv6. The PPP sessions initiated by the subscriber are 2209 forwarded over the L2TPv2 tunnel to the aggregation point in the ISP 2210 network. The BRAS (LAC) can aggregate IPv6 PPP sessions and tunnel 2211 them to the LNS using L2TPv2. The L2TPv2 tunnel between the LAC and 2212 LNS could run over IPv6 or IPv4. These capabilities have to be 2213 supported on the BRAS. The following devices have to be upgraded to 2214 dual stack: Host, Customer Router (if present), BRAS and Edge Router. 2216 7.2.3.2. Addressing 2218 The Edge router terminates the PPP sessions and provides the 2219 subscriber with an IPv6 address from the defined pool for that 2220 profile. The subscriber profile for authorization and authentication 2221 can be located on the Edge Router or on a AAA server. The Hosts or 2222 the Customer Routers have the Edge Router as their Layer 3 next hop. 2224 The PPP session can be initiated by a host or by a Customer Router. 2225 In the latter case, once the session is established with the Edge 2226 Router and an IPv6 address is assigned to the Customer Router by the 2227 Edge router, DHCP-PD can be used to acquire prefixes for the Customer 2228 Router other interfaces. The Edge Router has to be enabled to 2229 support DHCP-PD and to relay the DHCPv6 requests of the hosts on the 2230 subscriber sites. The uplink to the ISP network is configured with a 2231 /64 prefix as well. 2233 The BRAS has a /64 prefix configured on the link to the Edge router. 2234 The Edge router links are also configured with /64 prefixes to 2235 provide connectivity to the rest of the ISP network. 2237 Other information of interest to the host, such as DNS, is provided 2238 through stateful [RFC3315] and stateless [RFC3736] DHCPv6. 2240 The address assignment and prefix summarization issues discussed in 2241 section 6.2.3.2 are relevant in the same way for this media access 2242 type as well. 2244 7.2.3.3. Routing 2246 The CPE devices are configured with a default route that points to 2247 the Edge router that terminates the PPP sessions. No routing 2248 protocols are needed on these devices which have limited resources. 2250 The BRAS runs an IPv6 IGP to the Edge Router: OSPFv3 or IS-IS. 2251 Different processes should be used if the NAP and the NSP are managed 2252 by different organizations. In this case controlled redistribution 2253 should be enabled between the two domains. 2255 The Edge Router is running the IPv6 IGP used in the ISP network: 2256 OSPFv3 or IS-IS. 2258 7.2.4. Hybrid Model for IPv4 and IPv6 Service 2260 It was recommended throughout this section that the IPv6 service 2261 implementation should map the existing IPv4 one. This approach 2262 simplifies manageability and minimizes training needed for personnel 2263 operating the network. In certain circumstances such mapping is not 2264 feasible. This typically becomes the case when a Service Provider 2265 plans to expand its service offering with the new IPv6 deployed 2266 infrastructure. If this new service is not well supported in a 2267 network design such as the one used for IPv4 then a different design 2268 might be used for IPv6. 2270 An example of such circumstances is that of a provider using an LAA 2271 design for its IPv4 services. In this case all the PPP sessions are 2272 bundled and tunneled across the entire NAP infrastructure which is 2273 made of multiple BRAS routers, aggregation routers etc. The end 2274 point of these tunnels is the ISP Edge Router. If the SP decides to 2275 offer multicast services over such a design, it will face the problem 2276 of NAP resources being over utilized. The multicast traffic can be 2277 replicated only at the end of the tunnels by the Edge router and the 2278 copies for all the subscribers are carried over the entire NAP. 2280 A Modified Point-to-Point (see section 7.2.4.2) or a PTA model is 2281 more suitable to support multicast services because the packet 2282 replication can be done closer to the destination at the BRAS. Such 2283 a topology saves NAP resources. 2285 In this sense IPv6 deployments can be viewed as an opportunity to 2286 build an infrastructure that can better support the expansion of 2287 services. In this case, an SP using the LAA design for its IPv4 2288 services might choose a modified Point-to-Point or PTA design for 2289 IPv6. 2291 7.2.4.1. IPv4 in LAA Model and IPv6 in PTA Model 2293 The coexistence of the two PPP based models, PTA and LAA, is 2294 relatively straight forward. It is a straight forward overlap of the 2295 two deployment models. The PPP sessions are terminated on different 2296 network devices for the IPv4 and IPv6 services. The PPP sessions for 2297 the existing IPv4 service deployed in an LAA model are terminated on 2298 the Edge Router. The PPP sessions for the new IPv6 service deployed 2299 in a PTA model are terminated on the BRAS. 2301 The logical design for IPv6 and IPv4 in this hybrid model is 2302 presented in Figure 7.2.4.1. 2304 IPv6 |--------------------------| 2305 PPP +-----------+ 2306 | AAA | 2307 +-------+ Radius | 2308 | | TACACS | 2309 | +-----+-----+ 2310 | | 2311 +-----+ +-------+ +--------+ +----+-----+ +-----+-----+ 2312 |Hosts|--+Router +------+ Switch +-+ BRAS +-+ Edge | 2313 +-----+ +-------+ +--------+ +----------+ | Router +=>Core 2314 +-----------+ 2316 IPv4 |----------------------------------------| 2317 PPP 2318 |------------| 2319 L2TPv2 2320 Figure 7.2.4.1 2322 7.2.4.2. IPv4 in LAA Model and IPv6 in Modified Point-to-Point Model 2324 The coexistence of the modified Point-to-Point and the LAA models 2325 implies a few specific changes. 2327 For the IPv4 service in LAA model, the VLANs are terminated on the 2328 BRAS and PPP sessions are terminated on the Edge Router (LNS). For 2329 the IPv6 service in Point-to-Point model, the VLANs are terminated at 2330 the Edge Router as described in section 6.2.1. In this hybrid model, 2331 the Point-to-Point link could be terminated on the BRAS, a NAP owned 2332 device. The IPv6 traffic is then routed through the NAP network to 2333 the NSP. In order to have this hybrid model, the BRAS has to be 2334 upgraded to a dual-stack router. The functionalities of the Edge 2335 Router as described in section 6.2.1 are now implemented on the BRAS. 2337 The logical design for IPv6 and IPv4 in this hybrid model is in 2338 Figure 7.2.4.2. 2340 IPv6 |----------------| 2341 Ethernet 2342 +-----------+ 2343 | AAA | 2344 +-------+ Radius | 2345 | | TACACS | 2346 | +-----+-----+ 2347 | | 2348 +-----+ +-------+ +--------+ +----+-----+ +-----+-----+ 2349 |Hosts|--+Router +------+ Switch +-+ BRAS +-+ Edge | 2350 +-----+ +-------+ +--------+ +----------+ | Router +=>Core 2351 +-----------+ 2352 IPv4 |----------------------------------------| 2353 PPP 2354 |------------| 2355 L2TPv2 2356 Figure 7.2.4.2 2358 7.3. IPv6 Multicast 2360 The typical multicast services offered for residential and very small 2361 businesses is video/audio streaming where the subscriber joins a 2362 multicast group and receives the content. This type of service model 2363 is well supported through PIM-SSM which is very simple and easy to 2364 manage. PIM-SSM has to be enabled throughout the ISP network. MLDv2 2365 is required for PIM-SSM support. Vendors can choose to implement 2366 features that allow routers to map MLDv1 group joins to predefined 2367 sources. 2369 Subscribers might use a set-top box that is responsible for the 2370 control piece of the multicast service (does group joins/leaves). 2371 The subscriber hosts can also join desired multicast groups as long 2372 as they are enabled to support MLDv1 or MLDv2. If a customer premise 2373 router is used then it has to be enabled to support MLDv1 and MLDv2 2374 in order to process the requests of the hosts. It has to be enabled 2375 to support PIM-SSM in order to send PIM joins/leaves up to its Layer 2376 3 next hop whether it is the BRAS or the Edge router. When enabling 2377 this functionality on a customer premise router, its limited 2378 resources should be taken into consideration. Another option would 2379 be for the customer premise router to support MLD proxy routing. MLD 2380 snooping or similar Layer 2 multicast related protocols could be 2381 enabled on the NAP switches. 2383 The router that is the Layer 3 next hop for the subscriber (BRAS in 2384 the PTA model or the Edge router in the LAA and Point-to-Point model) 2385 has to be enabled to support MLDv1 and MLDv2 in order to process the 2386 requests coming from subscribers without customer premise routers. 2387 It has to be enabled for PIM-SSM in order to receive joins/leaves 2388 from customer routers and send joins/leaves to the next hop towards 2389 the multicast source (Edge router or the NSP core). 2391 MLD authentication, authorization and accounting is usually 2392 configured on the edge router in order to enable the ISP to do 2393 control the subscriber access of the service and do billing for the 2394 content provided. Alternative mechanisms that would support these 2395 functions should be investigated further. 2397 Please refer to section 6.3 for more IPv6 multicast details. 2399 7.4. IPv6 QoS 2401 The QoS configuration is particularly relevant on the router that 2402 represents the Layer 3 next hop for the subscriber (BRAS in the PTA 2403 model or the Edge router in the LAA and Point-to-Point model) in 2404 order to manage resources shared amongst multiple subscribers 2405 possibly with various service level agreements. 2407 On the BRAS or the Edge Router the subscriber facing interfaces have 2408 to be configured to police the inbound customer traffic and shape the 2409 traffic outbound to the customer based on the SLAs. Traffic 2410 classification and marking should also be done on the router closest 2411 (at Layer 3) to the subscriber in order to support the various types 2412 of customer traffic: data, voice, video and to optimally use the 2413 network resources. This infrastructure offers a very good 2414 opportunity to leverage the QoS capabilities of Layer 2 devices. 2415 DiffServ based QoS used for IPv4 should be expanded to IPv6. 2417 Each provider (NAP, NSP) could implement their own QoS policies and 2418 services so reclassification and marking might be performed at the 2419 boundary between the NAP and the NSP in order to make sure the 2420 traffic is properly handled by the ISP. The same IPv4 QoS concepts 2421 and methodologies should be applied for the IPv6 as well. 2423 It is important to note that when traffic is encrypted end-to-end, 2424 the traversed network devices will not have access to many of the 2425 packet fields used for classification purposes. In these cases 2426 routers will most likely place the packets in the default classes. 2427 The QoS design should take into consideration this scenario and try 2428 to use mainly IP header fields for classification purposes. 2430 7.5. IPv6 Security Considerations 2432 There are limited changes that have to be done for CPEs in order to 2433 enhance security. The Privacy extensions [RFC3041] for auto- 2434 configuration should be used by the hosts with the same 2435 considerations for host traceability as discussed in section 6.5. 2437 IPv6 firewall functions should be enabled on the hosts or customer 2438 premise router if present. 2440 The ISP provides security against attacks that come from its own 2441 subscribers but it could also implement security services that 2442 protect its subscribers from attacks sourced from the outside of its 2443 network. Such services do not apply at the access level of the 2444 network discussed here. 2446 If any Layer 2 filters for Ethertypes are in place, the NAP must 2447 permit the IPv6 Ethertype (0X86DD). 2449 The device that is the Layer 3 next hop for the subscribers (BRAS 2450 Edge router) should protect the network and the other subscribers 2451 against attacks by one of the provider customers. For this reason 2452 uRPF and ACLs should be used on all interfaces facing subscribers. 2453 Filtering should be implemented with regard for the operational 2454 requirements of IPv6 [Security considerations for IPv6]. 2456 The BRAS and the Edge Router should protect their processing 2457 resources against floods of valid customer control traffic such as: 2458 Router and Neighbor Solicitations, MLD Requests. Rate limiting 2459 should be implemented on all subscriber facing interfaces. The 2460 emphasis should be placed on multicast type traffic as it is most 2461 often used by the IPv6 control plane. 2463 All other security features used with the IPv4 service should be 2464 similarly applied to IPv6 as well. 2466 7.6. IPv6 Network Management 2468 The necessary instrumentation (such as MIB modules, NetFlow Records 2469 etc) should be available for IPv6. 2471 Usually, NSPs manage the edge routers by SNMP. The SNMP transport 2472 can be done over IPv4 if all managed devices have connectivity over 2473 both IPv4 and IPv6. This would imply the smallest changes to the 2474 existing network management practices and processes. Transport over 2475 IPv6 could also be implemented and it might become necessary if IPv6 2476 only islands are present in the network. The management applications 2477 may be running on hosts belonging to the NSP core network domain. 2478 Network Management Applications should handle IPv6 in a similar 2479 fashion to IPv4 however they should also support features specific to 2480 IPv6 such as Neighbor monitoring. 2482 In some cases service providers manage equipment located on customers 2483 LANs. 2485 8. Wireless LAN 2487 This section provides a detailed description of IPv6 deployment and 2488 integration methods in currently deployed wireless LAN (WLAN) 2489 infrastructure. 2491 8.1. WLAN Deployment Scenarios 2493 WLAN enables subscribers to connect to the Internet from various 2494 locations without the restriction of staying indoors. WLAN is 2495 standardized by IEEE 802.11a/b/g. 2497 Figure 8.1 describes the current WLAN architecture. 2499 Customer | Access Provider | Service Provider 2500 Premise | | 2502 +------+ +--+ +--------------+ +----------+ +------+ 2503 |WLAN | ---- | | |Access Router/| | Provider | |Edge | 2504 |Host/ |-(WLAN)--|AP|-|Layer 2 Switch|-| Network |-|Router|=>SP 2505 |Router| ---- | | | | | | | |Network 2506 +------+ +--+ +--------------+ +----------+ +------+ 2507 | 2508 +------+ 2509 |AAA | 2510 |Server| 2511 +------+ 2512 Figure 8.1 2514 The host should have a wireless network interface card (NIC) in order 2515 to connect to a WLAN network. WLAN is a flat broadcast network and 2516 works in a similar fashion as Ethernet. When a host initiates a 2517 connection, it is authenticated by the AAA server located at the SP 2518 network. All the authentication parameters (username, password and 2519 etc.) are forwarded by the Access Point (AP) to the AAA server. The 2520 AAA server authenticates the host, once successfully authenticated 2521 the host can send data packets. The AP is located near the host and 2522 acts as a bridge. The AP forwards all the packets coming to/from 2523 host to the Edge Router. The underlying connection between the AP 2524 and Edge Router could be based on any access layer technology such as 2525 HFC/Cable, FTTH, xDSL or etc. 2527 WLANs operate within limited areas known as WiFi Hot Spots. While 2528 users are present in the area covered by the WLAN range, they can be 2529 connected to the Internet given they have a wireless NIC and required 2530 configuration settings in their devices (notebook PCs, PDA or etc.). 2531 Once the user initiates the connection the IP address is assigned by 2532 the SP using DHCPv4. In most of the cases SP assigns limited number 2533 of public IP addresses to the its customer. When the user 2534 disconnects the connection and moves to a new WiFi hot spot, the 2535 above mentioned process of authentication, address assignment and 2536 accessing the Internet is repeated. 2538 There are IPv4 deployments where customers can use WLAN routers to 2539 connect over wireless to their service provider. These deployment 2540 types do not fit in the typical Hot Spot concept but they rather 2541 serve fixed customers. For this reason this section discusses the 2542 WLAN router options as well. In this case, the ISP provides a public 2543 IP address and the WLAN Router assigns private addresses [RFC1918] to 2544 all WLAN users. The WLAN Router provides NAT functionality while 2545 WLAN users access the Internet. 2547 While deploying IPv6 in the above mentioned WLAN architecture, there 2548 are three possible scenarios as discussed below. 2550 A. Layer 2 NAP with Layer 3 termination at NSP Edge Router 2552 B. Layer 3 aware NAP with Layer 3 termination at Access Router 2554 C. PPP Based Model 2556 8.1.1. Layer 2 NAP with Layer 3 termination at NSP Edge Router 2558 When a Layer 2 switch is present between AP and Edge Router, the AP 2559 and Layer 2 switch continues to work as a bridge, forwarding IPv4 and 2560 IPv6 packets from WLAN Host/Router to Edge Router and vice versa. 2562 When initiating the connection, the WLAN host is authenticated by the 2563 AAA server located at the SP network. All the parameters related to 2564 authentication (username, password and etc.) are forwarded by the AP 2565 to the AAA server. The AAA server authenticates the WLAN Hosts and 2566 once authenticated and associated successfully with WLAN AP, an IPv6 2567 address will be acquired by the WLAN Host. Note the initiation and 2568 authentication process is same as used in IPv4. 2570 Figure 8.1.1 describes the WLAN architecture when a Layer 2 Switch is 2571 located between AP and Edge Router. 2573 Customer | Access Provider | Service Provider 2574 Premise | | 2576 +------+ +--+ +--------------+ +----------+ +------+ 2577 |WLAN | ---- | | | | | Provider | |Edge | 2578 |Host/ |-(WLAN)--|AP|-|Layer 2 Switch|-| Network |-|Router|=>SP 2579 |Router| ---- | | | | | | | |Network 2580 +------+ +--+ +--------------+ +----------+ +------+ 2581 | 2582 +------+ 2583 |AAA | 2584 |Server| 2585 +------+ 2586 Figure 8.1.1 2588 8.1.1.1. IPv6 Related Infrastructure Changes 2590 IPv6 will be deployed in this scenario by upgrading the following 2591 devices to dual-stack: WLAN Host, WLAN Router (if present) and Edge 2592 Router. 2594 8.1.1.2. Addressing 2596 When customer WLAN Router is not present, the WLAN Host has two 2597 possible options to get an IPv6 address via the Edge Router. 2599 A. The WLAN host can get the IPv6 address from Edge router using 2600 stateless auto-configuration [RFC2462]. All hosts on the WLAN belong 2601 to the same /64 subnet that is statically configured on the Edge 2602 Router. The IPv6 WLAN Host may use stateless DHCPv6 for obtaining 2603 other information of interest such as DNS and etc. 2605 B. IPv6 WLAN host can use DHCPv6 [RFC3315] to get a IPv6 address from 2606 the DHCPv6 server. In this case the DHCPv6 server would be located 2607 in the SP core network and Edge Router would simply act as a DHCP 2608 Relay Agent. This option is similar to what is done today in case of 2609 DHCPv4. It is important to note that host implementation of stateful 2610 auto-configuration is rather limited at this time and this should be 2611 considered if choosing this address assignment option. 2613 When a customer WLAN Router is present, the WLAN Host has two 2614 possible options as well for acquiring IPv6 address. 2616 A. The WLAN Router may be assigned a prefix between /48 and /64 2617 [RFC3177] depending on the SP policy and customer requirements. If 2618 the WLAN Router has multiple networks connected to its interfaces, 2619 the network administrator will have to configure the /64 prefixes to 2620 the WLAN Router interfaces connecting the WLAN Hosts on the customer 2621 site. The WLAN Hosts connected to these interfaces can automatically 2622 configure themselves using stateless auto-configuration. 2624 B. The WLAN Router can use its link-local address to communicate with 2625 the ER. It can also dynamically acquire through stateless auto- 2626 configuration the address for the link between itself and the ER. 2627 This step is followed by a request via DHCP-PD for a prefix shorter 2628 than /64 that in turn is divided in /64s and assigned to its 2629 interfaces connecting the hosts on the customer site. 2631 In this option, the WLAN Router would act as a requesting router and 2632 Edge Router would act as delegating router. Once prefix is received 2633 by the WLAN Router, it assigns /64 prefixes to each of its interfaces 2634 connecting the WLAN Hosts on the customer site. The WLAN Hosts 2635 connected to these interfaces can automatically configure themselves 2636 using stateless auto-configuration. The uplink to the ISP network is 2637 configured with a /64 prefix as well. 2639 Usually it is easier for the SPs to stay with the DHCP-PD and 2640 stateless auto-configuration model and point the clients to a central 2641 server for DNS/domain information, proxy configurations and etc. 2642 Using this model the SP could change prefixes on the fly and the WLAN 2643 Router would simply pull the newest prefix based on the valid/ 2644 preferred lifetime. 2646 The prefixes used for subscriber links and the ones delegated via 2647 DHCP-PD should be planned in a manner that allows maximum 2648 summarization as possible at the Edge Router. 2650 Other information of interest to the host, such as DNS, is provided 2651 through stateful [RFC3315] and stateless [RFC3736] DHCPv6. 2653 8.1.1.3. Routing 2655 The WLAN Host/Router are configured with a default route that points 2656 to the Edge router. No routing protocols are needed on these devices 2657 which generally have limited resources. 2659 The Edge Router runs the IGP used in the SP network such as OSPFv3 or 2660 IS-IS for IPv6. The connected prefixes have to be redistributed. 2661 Prefix summarization should be done at the Edge Router. When DHCP-PD 2662 is used, the IGP has to redistribute the static routes installed 2663 during the process of prefix delegation. 2665 8.1.2. Layer 3 aware NAP with Layer 3 termination at Access Router 2667 When an Access Router is present between AP and Edge Router, the AP 2668 continues to work as a bridge, bridging IPv4 and IPv6 packets from 2669 WLAN Host/Router to Access Router and vice versa. The Access Router 2670 could be part of SP network or owned by a separate Access Provider. 2672 When WLAN Host initiates the connection, the AAA authentication and 2673 association process with WLAN AP will be similar as explained in 2674 section 8.1.1. 2676 Figure 8.1.2 describes the WLAN architecture when Access Router is 2677 located between AP and Edge Router. 2679 Customer | Access Provider | Service Provider 2680 Premise | | 2682 +------+ +--+ +--------------+ +----------+ +------+ 2683 |WLAN | ---- | | | | | Provider | |Edge | 2684 |Host/ |-(WLAN)--|AP|-|Access Router |-| Network |-|Router|=>SP 2685 |Router| ---- | | | | | | | |Network 2686 +------+ +--+ +--------------+ +----------+ +------+ 2687 | 2688 +------+ 2689 |AAA | 2690 |Server| 2691 +------+ 2692 Figure 8.1.2 2694 8.1.2.1. IPv6 Related Infrastructure Changes 2696 IPv6 is deployed in this scenario by upgrading the following devices 2697 to dual-stack: WLAN Host, WLAN Router (if present), Access Router and 2698 Edge Router. 2700 8.1.2.2. Addressing 2702 There are three possible options in this scenario for IPv6 address 2703 assignment: 2705 A. The Edge Router interface facing towards the Access Router is 2706 statically configured with /64 prefix. The Access Router receives/ 2707 configures an /64 prefix on its interface facing towards Edge Router 2708 through stateless auto-configuration. The network administrator will 2709 have to configure the /64 prefixes to the Access Router interface 2710 facing towards the customer premise. The WLAN Host/Router connected 2711 to this interface can automatically configure themselves using 2712 stateless auto-configuration. 2714 B. This option uses DHCPv6 [RFC3315] for IPv6 prefix assignments to 2715 the WLAN Host/Router. There is no use of DHCP PD or stateless auto- 2716 configuration in this option. The DHCPv6 server can be located on 2717 the Access Router, on the Edge Router or somewhere in the SP network. 2718 In this case depending on where the DHCPv6 server is located, Access 2719 Router or the Edge Router would relay the DHCPv6 requests. 2721 C. It can use its link-local address to communicate with the ER. It 2722 can also dynamically acquire through stateless auto-configuration the 2723 address for the link between itself and the ER. This step is 2724 followed by a request via DHCP-PD for a prefix shorter than /64 that 2725 in turn is divided in /64s and assigned to its interfaces connecting 2726 the hosts on the customer site. 2728 In this option, the Access Router would act as a requesting router 2729 and Edge Router would act as delegating router. Once prefix is 2730 received by the Access Router, it assigns /64 prefixes to each of its 2731 interfaces connecting the WLAN Host/Router on customer site. The 2732 WLAN Host/Router connected to these interfaces can automatically 2733 configure themselves using stateless auto-configuration. The uplink 2734 to the ISP network is configured with a /64 prefix as well. 2736 It is easier for the SPs to stay with the DHCP PD and stateless auto- 2737 configuration model and point the clients to a central server for 2738 DNS/domain information, proxy configurations and others. Using this 2739 model the provider could change prefixes on the fly and the Access 2740 Router would simply pull the newest prefix based on the valid/ 2741 preferred lifetime. 2743 As mentioned before the prefixes used for subscriber links and the 2744 ones delegated via DHCP-PD should be planned in a manner that allows 2745 maximum summarization possible at the Edge Router. Other information 2746 of interest to the host, such as DNS, is provided through stateful 2747 [RFC3315] and stateless [RFC3736] DHCPv6. 2749 8.1.2.3. Routing 2751 The WLAN Host/Router are configured with a default route that points 2752 to the Access Router. No routing protocols are needed on these 2753 devices which generally have limited resources. 2755 If the Access Router is owned by an Access Provider, then the Access 2756 Router can have a default route, pointing towards the SP Edge Router. 2757 The Edge Router runs the IGP used in the SP network such as OSPFv3 or 2758 IS-IS for IPv6. The connected prefixes have to be redistributed. If 2759 DHCP-PD is used, with every delegated prefix a static route is 2760 installed by the Edge Router. For this reason the static routes must 2761 be redistributed. Prefix summarization should be done at the Edge 2762 Router. 2764 If the Access Router is owned by the SP, then Access Router will also 2765 run IPv6 IGP and will be part of SP IPv6 routing domain (OSPFv3 or 2766 IS-IS). The connected prefixes have to be redistributed. If DHCP-PD 2767 is used, with every delegated prefix a static route is installed by 2768 the Access Router. For this reason the static routes must be 2769 redistributed. Prefix summarization should be done at the Access 2770 Router. 2772 8.1.3. PPP Based Model 2774 PPP Terminated Aggregation (PTA) and L2TPv2 Access Aggregation (LAA) 2775 models as discussed in sections 6.2.2 and 6.2.3 respectively can also 2776 be deployed in IPv6 WLAN environment. 2778 8.1.3.1. PTA Model in IPv6 WLAN Environment 2780 While deploying the PTA model in IPv6 WLAN environment the Access 2781 Router is Layer 3 aware and it has to be upgraded to support IPv6. 2782 Since the Access Router terminates the PPP sessions initiated by WLAN 2783 Host/Router, it has to support PPPoE with IPv6. 2785 Figure 8.1.3.1 describes the PTA Model in IPv6 WLAN environment. 2787 Customer | Access Provider | Service Provider 2788 Premise | | 2789 +------+ +--+ +--------------+ +----------+ +------+ 2790 |WLAN | ---- | | | | | Provider | |Edge | 2791 |Host/ |-(WLAN)--|AP|-|Access Router |-| Network |-|Router|=>SP 2792 |Router| ---- | | | | | | | |Network 2793 +------+ +--+ +--------------+ +----------+ +------+ 2794 | 2795 |---------------------------| +------+ 2796 PPP |AAA | 2797 |Server| 2798 +------+ 2799 Figure 8.1.3.1 2801 8.1.3.1.1. IPv6 Related Infrastructure Changes 2803 IPv6 is deployed in this scenario by upgrading the following devices 2804 to dual-stack: WLAN Host, WLAN Router (if present), Access Router and 2805 Edge Router. 2807 8.1.3.1.2. Addressing 2809 The addressing techniques described in section 6.2.2.2 apply to the 2810 IPv6 WLAN PTA scenario as well. 2812 8.1.3.1.3. Routing 2814 The routing techniques described in section 6.2.2.3 apply to the IPv6 2815 WLAN PTA scenario as well. 2817 8.1.3.2. LAA Model in IPv6 WLAN Environment 2819 While deploying the LAA model in IPv6 WLAN environment the Access 2820 Router is Layer 3 aware and it has to be upgraded to support IPv6. 2821 The PPP sessions initiated by WLAN Host/Router are forwarded over the 2822 L2TPv2 tunnel to the aggregation point in the SP network. The Access 2823 Router must have the capability to support L2TPv2 for IPv6. 2825 Figure 8.1.3.2 describes the LAA Model in IPv6 WLAN environment 2827 Customer | Access Provider | Service Provider 2828 Premise | | 2830 +------+ +--+ +--------------+ +----------+ +------+ 2831 |WLAN | ---- | | | | | Provider | |Edge | 2832 |Host/ |-(WLAN)--|AP|-|Access Router |-| Network |-|Router|=>SP 2833 |Router| ---- | | | | | | | |Network 2834 +------+ +--+ +--------------+ +----------+ +------+ 2835 | 2836 |-------------------------------------------------- | 2837 PPP | 2838 |--------------------- | 2839 L2TPv2 | 2840 +------+ 2841 |AAA | 2842 |Server| 2843 +------+ 2844 Figure 8.1.3.2 2846 8.1.3.2.1. IPv6 Related Infrastructure Changes 2848 IPv6 is deployed in this scenario by upgrading the following devices 2849 to dual-stack: WLAN Host, WLAN Router (if present), Access Router and 2850 Edge Router. 2852 8.1.3.2.2. Addressing 2854 The addressing techniques described in section 6.2.3.2 apply to the 2855 IPv6 WLAN LAA scenario as well. 2857 8.1.3.2.3. Routing 2859 The routing techniques described in section 6.2.3.3 apply to the IPv6 2860 WLAN LAA scenario as well. 2862 8.2. IPv6 Multicast 2864 The typical multicast services offered are video/audio streaming 2865 where the IPv6 WLAN Host joins a multicast group and receives the 2866 content. This type of service model is well supported through PIM- 2867 SSM which is enabled throughout the SP network. MLDv2 is required 2868 for PIM-SSM support. Vendors can choose to implement features that 2869 allow routers to map MLDv1 group joins to predefined sources. 2871 It is important to note that in the shared wireless environments 2872 multicast can have a significant bandwidth impact. For this reason 2873 the bandwidth allocated to multicast traffic should be limited and 2874 fixed based on the overall capacity of the wireless specification 2875 used 802.11a, 802.11b or 802.11g. 2877 The IPv6 WLAN Hosts can also join desired multicast groups as long as 2878 they are enabled to support MLDv1 or MLDv2. If a WLAN/Access Routers 2879 are used then they have to be enabled to support MLDv1 and MLDv2 in 2880 order to process the requests of the IPv6 WLAN Hosts. The WLAN/ 2881 Access Router should also needs to be enabled to support PIM-SSM in 2882 order to send PIM joins up to the Edge Router. When enabling this 2883 functionality on a WLAN/Access Router, its limited resources should 2884 be taken into consideration. Another option would be for the WLAN/ 2885 Access Router to support MLD proxy routing. 2887 The Edge Router has to be enabled to support MLDv1 and MLDv2 in order 2888 to process the requests coming from IPv6 WLAN Host or WLAN/Access 2889 Router (if present). The Edge Router has also needs to be enabled 2890 for PIM-SSM in order to receive joins from IPv6 WLAN Hosts or WLAN/ 2891 Access Router (if present) and send joins towards the SP core. 2893 MLD authentication, authorization and accounting is usually 2894 configured on the Edge Router in order to enable the SP to do billing 2895 for the content services provided. Further investigation should be 2896 made in finding alternative mechanisms that would support these 2897 functions. 2899 Concerns have been raised in the past related to running IPv6 2900 multicast over WLAN links. Potentially these are same kind of issues 2901 when running any Layer 3 protocol over a WLAN link that has a high 2902 loss-to-signal ratio, where certain frames that are multicast based 2903 are dropped when settings are not adjusted properly. For instance 2904 this behavior is similar to IGMP host membership report, when done on 2905 a WLAN link with high loss-to-signal ratio and high interference. 2907 This problem is inherited to WLAN that can impact both IPv4 and IPv6 2908 multicast packets and not specific to IPv6 multicast. 2910 While deploying WLAN (IPv4 or IPv6), one should adjust their 2911 broadcast/multicast settings if they are in danger of dropping 2912 application dependent frames. These problems are usually caused when 2913 AP are placed too far apart (not following the distance limitations), 2914 high interference and etc. These issues may impact a real multicast 2915 application such as streaming video or basic operation of IPv6 if the 2916 frames were dropped. Basic IPv6 communications uses functions such 2917 as Duplicate Address Detection (DAD), Router and Neighbor 2918 Solicitations (RS, NS), Router and Neighbor Advertisement (RA, NA) 2919 and etc. which could be impacted by the above mentioned issues as 2920 these frames are Layer 2 Ethernet multicast frames. 2922 Please refer to section 6.3 for more IPv6 multicast details. 2924 8.3. IPv6 QoS 2926 Today, QoS is done outside of the WiFi domain but it is nevertheless 2927 important to the overall deployment. 2929 The QoS configuration is particularly relevant on the Edge Router in 2930 order to manage resources shared amongst multiple subscribers 2931 possibly with various service level agreements (SLA). Although, the 2932 WLAN Host/Router and Access Router could also be configured for QoS. 2933 This includes support for appropriate classification criteria which 2934 would need to be implemented for IPv6 unicast and multicast traffic. 2936 On the Edge Router the subscriber facing interfaces have to be 2937 configured to police the inbound customer traffic and shape the 2938 traffic outbound to the customer, based on the SLA. Traffic 2939 classification and marking should also be done on the Edge router in 2940 order to support the various types of customer traffic: data, voice, 2941 video. The same IPv4 QoS concepts and methodologies should be 2942 applied for the IPv6 as well. 2944 It is important to note that when traffic is encrypted end-to-end, 2945 the traversed network devices will not have access to many of the 2946 packet fields used for classification purposes. In these cases 2947 routers will most likely place the packets in the default classes. 2948 The QoS design should take into consideration this scenario and try 2949 to use mainly IP header fields for classification purposes. 2951 8.4. IPv6 Security Considerations 2953 There are limited changes that have to be done for WLAN Host/Router 2954 in order to enhance security. The Privacy extensions [RFC3041] for 2955 auto-configuration should be used by the hosts with the same 2956 consideration for host traceability as described in section 6.5. 2957 IPv6 firewall functions should be enabled on the WLAN Host/Router if 2958 present. 2960 The ISP provides security against attacks that come from its own 2961 subscribers but it could also implement security services that 2962 protect its subscribers from attacks sourced from the outside of its 2963 network. Such services do not apply at the access level of the 2964 network discussed here. 2966 If the host authentication at hot spots is done using web based 2967 authentication system then the level of security would depend on the 2968 particular implementation. User credential should never be sent as 2969 clear text via HTTP. Secure HTTP (HTTPS) should be used between the 2970 web browser and authentication server. The authentication server 2971 could use RADIUS and LDAP services at the back end. 2973 Authentication is an important aspect of securing WLAN networks prior 2974 to implementing Layer 3 security policies. This would help for 2975 example avoid threats to the ND or stateless auto-configuration 2976 processes. 802.1x [IEEE8021X] provides the means to secure the 2977 network access however, the many types of EAP (PEAP, EAP-TLS, EAP- 2978 TTLS, EAP-FAST, LEAP) and the capabilities of the hosts to support 2979 some of the features might make it difficult to implement a 2980 comprehensive and consistent policy. 2982 The 802.11i [IEEE80211i] amendment has many components, the most 2983 obvious of which are the two new data-confidentiality protocols, 2984 Temporal Key Integrity Protocol (TKIP) and Counter-Mode/CBC-MAC 2985 Protocol (CCMP). 802.11i also uses 802.1X's key-distribution system 2986 to control access to the network. Because 802.11 handles unicast and 2987 broadcast traffic differently, each traffic type has different 2988 security concerns. With several data-confidentiality protocols and 2989 the key distribution, 802.11i includes a negotiation process for 2990 selecting the correct confidentiality protocol and key system for 2991 each traffic type. Other features introduced include key caching and 2992 pre-authentication. 2994 The 802.11i amendment is a step forward in wireless security. The 2995 amendment adds stronger encryption, authentication, and key 2996 management strategies that could make wireless data and systems more 2997 secure. 2999 If any Layer 2 filters for Ethertypes are in place, the NAP must 3000 permit the IPv6 Ethertype (0X86DD). 3002 The device that is the Layer 3 next hop for the subscribers (Access 3003 or Edge Router) should protect the network and the other subscribers 3004 against attacks by one of the provider customers. For this reason 3005 uRPF and ACLs should be used on all interfaces facing subscribers. 3006 Filtering should be implemented with regard for the operational 3007 requirements of IPv6 [Security considerations for IPv6]. 3009 The Access and the Edge Router should protect their processing 3010 resources against floods of valid customer control traffic such as: 3011 RS, NS, MLD Requests. Rate limiting should be implemented on all 3012 subscriber facing interfaces. The emphasis should be placed on 3013 multicast type traffic as it is most often used by the IPv6 control 3014 plane. 3016 8.5. IPv6 Network Management 3018 The necessary instrumentation (such as MIB modules, NetFlow Records, 3019 etc) should be available for IPv6. 3021 Usually, NSPs manage the edge routers by SNMP. The SNMP transport 3022 can be done over IPv4 if all managed devices have connectivity over 3023 both IPv4 and IPv6. This would imply the smallest changes to the 3024 existing network management practices and processes. Transport over 3025 IPv6 could also be implemented and it might become necessary if IPv6 3026 only islands are present in the network. The management applications 3027 may be running on hosts belonging to the NSP core network domain. 3028 Network Management Applications should handle IPv6 in a similar 3029 fashion to IPv4 however they should also support features specific to 3030 IPv6 (such as Neighbor monitoring). 3032 In some cases service providers manage equipment located on customers 3033 LANs. 3035 9. Broadband Power Line Communications (PLC) 3037 This section describes the IPv6 deployment in Power Line 3038 Communications (PLC) Access Networks. There may be other choices, 3039 but it seems that this is the best model to follow. Lessons learnt 3040 from Cable, Ethernet and even WLAN access networks may be applicable 3041 also. 3043 Power Line Communications are also often called Broadband Power Line 3044 (BPL) and some times even Power Line Telecommunications (PLT). 3046 PLC/BPL can be used for providing, with today's technology, up to 3047 200Mbps (total, upstream+downstream) by means of the power grid. The 3048 coverage is often the last half mile (typical distance from the 3049 Medium-to-Low Voltage transformer to the customer premise meter), and 3050 of course, as an in-home network (which is out of the scope of this 3051 document). 3053 The bandwidth in a given PLC/BPL segment is shared among all the 3054 customers connected to that segment (often the customers connected to 3055 the same medium-to-low voltage transformer). The number of customers 3056 can vary depending on different factors, such as distances and even 3057 countries (from a few customers, just 5-6, up to 100-150). 3059 PLC/BPL could also be used in the Medium Voltage network (often 3060 configured as Metropolitan Area Networks), but this is also out of 3061 the scope of this document, as it will be part of the core network, 3062 not the access one. 3064 9.1. PLC/BPL Access Network Elements 3066 This section describes the different elements commonly used in PLC/ 3067 BPL access networks. 3069 Head End (HE): Router that connects the PLC/BPL access network (the 3070 power grid), located at the medium-to-low voltage transformer, to the 3071 core network. The HE PLC/BPL interface appears to each customer as a 3072 single virtual interface, all of them sharing the same physical 3073 media. 3075 Repeater (RPT): A device which may be required in some circumstances 3076 to improve the signal on the PLC/BPL. This may be the case if there 3077 are many customers in the same segment or building. It is often a 3078 bridge, but it could be also a router if for example there is a lot 3079 of peer-to-peer traffic in a building and due to the master-slave 3080 nature of the PLC/BPL technology, is required to improve the 3081 performance within that segment. For simplicity, in this document, 3082 it will be considered that the RPT is always a transparent layer 2 3083 bridge, so it may be present or not (from the layer 3 point of view). 3085 Customer Premise Equipment (CPE): Modem (internal to the host), 3086 modem/bridge (BCPE), router (RCPE) or any combination among those 3087 (i.e. modem+bridge/router), located at the customer premise. 3089 Edge Router (ER) 3091 Figure 9.1 depicts all the network elements indicated above 3092 Customer Premise | Network Access Provider | Network Service Provider 3094 +-----+ +------+ +-----+ +------+ +--------+ 3095 |Hosts|--| RCPE |--| RPT |--------+ Head +---+ Edge | ISP 3096 +-----+ +------+ +-----+ | End | | Router +=>Network 3097 +--+---+ +--------+ 3098 +-----+ +------+ +-----+ | 3099 |Hosts|--| BCPE |--| RPT |-----------+ 3100 +-----+ +------+ +-----+ 3101 Figure 9.1 3103 The logical topology and design of PLC/BPL is very similar to 3104 Ethernet Broadband Networks as discussed in Section 7. IP 3105 connectivity is typically provided in a Point-to-Point model as 3106 described in section 7.2.1 3108 9.2. Deploying IPv6 in IPv4 PLC/BPL 3110 The most simplistic and efficient model, considering the nature of 3111 the PLC/BPL networks, is to see the network as a point-to-point one 3112 to each customer. Even if several customers share the same physical 3113 media, the traffic is not visible among them because each one uses 3114 different channels, which are in addition encrypted by means of 3DES. 3116 In order to maintain the deployment concepts and business models 3117 proven and used with existing revenue generating IPv4 services, the 3118 IPv6 deployment will match the IPv4 one. Under certain circumstances 3119 where new service types or service needs justify it, IPv4 and IPv6 3120 network architectures could be different. Both approaches are very 3121 similar to those already described for the Ethernet case. 3123 9.2.1. IPv6 Related Infrastructure Changes 3125 In this scenario only the RPT is layer 3 unaware, but the other 3126 devices have to be upgraded to dual stack Hosts, RCPE, Head End, and 3127 Edge Router. 3129 9.2.2. Addressing 3131 The Hosts or the RCPEs have the HE as their Layer 3 next hop. 3133 If there is no RCPE, but instead a BCPE all the hosts on the 3134 subscriber site belong to the same /64 subnet that is statically 3135 configured on the HE. The hosts can use stateless auto-configuration 3136 or stateful DHCPv6 based configuration to acquire an address via the 3137 HE. 3139 If a RCPE is present: 3141 A. It is statically configured with an address on the /64 subnet 3142 between itself and the HE, and with /64 prefixes on the interfaces 3143 connecting the hosts on the customer site. This is not a desired 3144 provisioning method being expensive and difficult to manage. 3146 B. It can use its link-local address to communicate with the HE. It 3147 can also dynamically acquire through stateless auto-configuration the 3148 address for the link between itself and the HE. This step is 3149 followed by a request via DHCP-PD for a prefix shorter than /64 3150 (typically /48 [RFC3177]) that in turn is divided in /64s and 3151 assigned to its interfaces connecting the hosts on the customer site. 3152 This should be the preferred provisioning method, being cheaper and 3153 easier to manage. 3155 The Edge Router needs to have a prefix considering that each customer 3156 in general will receive a /48 prefix, and that each HE will 3157 accommodate customers. Consequently each HE will require n x /48 3158 prefixes. 3160 It could be possible to use a kind of Hierarchical Prefix Delegation 3161 to automatically provision the required prefixes and fully auto- 3162 configure the HEs, and consequently reduce the network setup, 3163 operation and maintenance cost. 3165 The prefixes used for subscriber links and the ones delegated via 3166 DHCP-PD should be planned in a manner that allows as much 3167 summarization as possible at the Edge Router. 3169 Other information of interest to the host, such as DNS, is provided 3170 through stateful [RFC3315] and stateless [RFC3736] DHCPv6. 3172 9.2.3. Routing 3174 If no routers are used on the customer premise, the HE can simply be 3175 configured with a default route that points to the Edge Router. If a 3176 router is used on the customer premise (RCPE) then the HE could also 3177 run an IGP to the ER such as OSPFv3, IS-IS or even RIPng. The 3178 connected prefixes should be redistributed. If DHCP-PD is used, with 3179 every delegated prefix a static route is installed by the HE. For 3180 this reason the static routes must also be redistributed. Prefix 3181 summarization should be done at the HE. 3183 The RCPE requires only a default route pointing to the HE. No 3184 routing protocols are needed on these devices which generally have 3185 limited resources. 3187 The Edge Router runs the IPv6 IGP used in the NSP: OSPFv3 or IS-IS. 3188 The connected prefixes have to be redistributed as well as any RP 3189 other than the ones used on the ER that might be used between the HE 3190 and the ER. 3192 9.3. IPv6 Multicast 3194 The considerations regarding IPv6 Multicast for Ethernet are also 3195 applicable here, in general, but assuming the nature of PLC/BPL being 3196 a shared media. If a lot of Multicast is expected, it may be worth 3197 considering using RPT which are layer 3 aware. In that case, one 3198 extra layer of Hierarchical DHCP-PD could be considered, in order to 3199 facilitate the deployment, operation and maintenance of the network. 3201 9.4. IPv6 QoS 3203 The considerations introduced for QoS in Ethernet are also applicable 3204 here. PLC/BPL networks support QoS, which basically is the same 3205 whether the transport is IPv4 or IPv6. It is necessary to understand 3206 that there are specific network characteristics, such as the 3207 variability that may be introduced by electrical noise, towards which 3208 the PLC/BPL network will automatically self-adapt. 3210 9.5. IPv6 Security Considerations 3212 There are no differences in terms of security considerations if 3213 compared with the Ethernet case. 3215 9.6. IPv6 Network Management 3217 The issues related to IPv6 Network Management in PLC networks should 3218 be similar to those discussed for Broadband Ethernet Networks in 3219 section 7.6. Note that there may be a need to define MIB modules for 3220 PLC networks and interfaces, but this is not necessarily related to 3221 IPv6 management. 3223 10. Gap Analysis 3225 Several aspects of deploying IPv6 over SP Broadband networks were 3226 highlighted in this document, aspects that require additional work in 3227 order to facilitate native deployments as summarized below: 3229 A. As mentioned in section 5, changes will need to be made to the 3230 DOCSIS specification in order for SPs to deploy native IPv6 over 3231 cable networks. The CM and CMTS will both need to support IPv6 3232 natively in order to forward IPv6 unicast and multicast traffic. 3233 This is required for IPv6 Neighbor Discovery to work over DOCSIS 3234 cable networks. Additional classifiers need to be added to the 3235 DOCSIS specification in order to classify IPv6 traffic at the CM and 3236 CMTS in order to provide QoS. These issues are addressed in a recent 3237 proposal made to Cable Labs for DOCSIS 3.0 [DOCSIS 3.0 Requirements]. 3239 B. Section 6 stated that current RBE based IPv4 deployment might not 3240 be the best approach for IPv6 where the addressing space available 3241 gives the SP the opportunity to separate the users on different 3242 subnets. The differences between IPv4 RBE and IPv6 RBE were 3243 highlighted in section 6. If however, support and reason is found 3244 for a deployment similar to IPv4 RBE, then the environment becomes 3245 NBMA and the new feature should observe RFC2491 recommendations. 3247 C. Section 6 discussed the constraints imposed on a LAA based IPv6 3248 deployment by the fact that it is expected that the subscribers keep 3249 their assigned prefix regardless of LNS. A deployment approach was 3250 proposed that would maintain the addressing schemes contiguous and 3251 offers prefix summarization opportunities. The topic could be 3252 further investigated for other solutions or improvements. 3254 D. Sections 6 and 7 pointed out the limitations (previously 3255 documented in [IPv6 Multicast]) in deploying inter-domain ASM 3256 however, SSM based services seem more likely at this time. For such 3257 SSM based services of content delivery (video or Audio), mechanisms 3258 are needed to facilitate the billing and management of listeners. 3259 The currently available feature of MLD AAA is suggested however, 3260 other methods or mechanisms might be developed and proposed. 3262 E. In relation to section 8, concerns have been raised related to 3263 running IPv6 multicast over WLAN links. Potentially these are same 3264 kind of issues when running any Layer 3 protocol over a WLAN link 3265 that has a high loss-to-signal ratio, certain frames that are 3266 multicast based are dropped when settings are not adjusted properly. 3267 For instance this behavior is similar to IGMP host membership report, 3268 when done on a WLAN link with high loss-to-signal ratio and high 3269 interference. This problem is inherited to WLAN that can impact both 3270 IPv4 and IPv6 multicast packets and not specific to IPv6 multicast. 3272 F. The Privacy Extensions were mentioned as a popular means to 3273 provide some form of host security. ISPs can track relatively easily 3274 the prefixes assigned to subscribers. If however the ISPs are 3275 required by regulations to track their users at host address level, 3276 the Privacy Extensions [RFC3041] can be implemented only in parallel 3277 with network management tools that could provide traceability of the 3278 hosts. Mechanisms should be defined to implement this aspect of user 3279 management. 3281 G. Tunnels are an effective way to avoid deployment dependencies on 3282 the IPv6 support on platforms that are out of the SP control (GWRs or 3283 CPEs) or over technologies that did not standardize the IPv6 support 3284 yet (cable). They can be used in the following ways: 3286 i. Tunnels directly to the CPE or GWR with public or private IPv4 3287 addresses. 3289 ii. Tunnels directly to hosts with public or private IPv4 addresses. 3290 Recommendations on the exact tunneling mechanisms that can/should be 3291 used for last mile access need to be investigated further and should 3292 be addressed by the IETF Softwire Working Group. 3294 H. Through its larger address space, IPv6 allows SPs to assign fixed, 3295 globally routable prefixes to the links connecting each subscriber. 3297 This approach changes the provisioning methodologies that were used 3298 for IPv4. Static configuration of the IPv6 addresses for all these 3299 links on the Edge Routers or Access Routers might not be a scalable 3300 option. New provisioning mechanisms or features might need to be 3301 developed in order to deal with this issue, such as automatic mapping 3302 of VLAN IDs/PVCs (or other customer-specific information) to IPv6 3303 prefixes. 3305 I. New deployment models are emerging for the Layer 2 portion of the 3306 NAP where individual VLANs are not dedicated to each subscriber. 3307 This approach allows Layer 2 switches to aggregate more then 4096 3308 users. MAC Forced Forwarding [MFF] is an example of such an 3309 implementation where a broadcast domain is turned into a NBMA like 3310 environment by forwarding the frames based on both Source and 3311 Destination MAC addresses. Since these models are being adopted by 3312 the field, the implications of deploying IPv6 in such environments 3313 need to be further investigated. 3315 J. The deployment of IPv6 in continuously evolving access service 3316 models raises some issues that may need further investigation. 3317 Examples of such topics are [v6 auto-config]: 3319 i. Network Service Selection & Authentication (NSSA) mechanisms 3320 working in association with stateless auto-configuration. As an 3321 example, NSSA relevant information such as ISP preference, passwords 3322 or profile ID can be sent by hosts with the RS [RFC4191]. 3324 ii. Providing additional information in Router Advertisements to 3325 help access nodes with prefix selection in multi-ISP/multi-homed 3326 environment. 3328 The outcome of solutions to some of these topics ranges from making a 3329 media access capable of supporting native IPv6 (cable) to improving 3330 operational aspects of native IPv6 deployments. 3332 11. IANA Considerations 3334 This document requests no action by IANA. 3336 12. Security Considerations 3338 Please refer to the individual "IPv6 Security Considerations" 3339 technology sections for details. 3341 13. Acknowledgements 3343 We would like to thank Brian Carpenter, Patrick Grossetete, Toerless 3344 Eckert, Madhu Sudan, Shannon McFarland and Benoit Lourdelet, Fred 3345 Baker for their valuable comments. The authors would like to 3346 acknowledge the structure and information guidance provided by the 3347 work of Mickels et al on Transition Scenarios for ISP Networks. 3349 14. References 3351 14.1. Normative References 3353 [RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and 3354 E. Lear, "Address Allocation for Private Internets", 3355 BCP 5, RFC 1918, February 1996. 3357 [RFC2080] Malkin, G. and R. Minnear, "RIPng for IPv6", RFC 2080, 3358 January 1997. 3360 [RFC2364] Gross, G., Kaycee, M., Lin, A., Malis, A., and J. 3361 Stephens, "PPP Over AAL5", RFC 2364, July 1998. 3363 [RFC2461] Narten, T., Nordmark, E., and W. Simpson, "Neighbor 3364 Discovery for IP Version 6 (IPv6)", RFC 2461, 3365 December 1998. 3367 [RFC2462] Thomson, S. and T. Narten, "IPv6 Stateless Address 3368 Autoconfiguration", RFC 2462, December 1998. 3370 [RFC2473] Conta, A. and S. Deering, "Generic Packet Tunneling in 3371 IPv6 Specification", RFC 2473, December 1998. 3373 [RFC2516] Mamakos, L., Lidl, K., Evarts, J., Carrel, D., Simone, D., 3374 and R. Wheeler, "A Method for Transmitting PPP Over 3375 Ethernet (PPPoE)", RFC 2516, February 1999. 3377 [RFC2529] Carpenter, B. and C. Jung, "Transmission of IPv6 over IPv4 3378 Domains without Explicit Tunnels", RFC 2529, March 1999. 3380 [RFC2661] Townsley, W., Valencia, A., Rubens, A., Pall, G., Zorn, 3381 G., and B. Palter, "Layer Two Tunneling Protocol "L2TP"", 3382 RFC 2661, August 1999. 3384 [RFC2740] Coltun, R., Ferguson, D., and J. Moy, "OSPF for IPv6", 3385 RFC 2740, December 1999. 3387 [RFC2770] Meyer, D. and P. Lothberg, "GLOP Addressing in 233/8", 3388 RFC 2770, February 2000. 3390 [RFC2784] Farinacci, D., Li, T., Hanks, S., Meyer, D., and P. 3391 Traina, "Generic Routing Encapsulation (GRE)", RFC 2784, 3392 March 2000. 3394 [RFC3041] Narten, T. and R. Draves, "Privacy Extensions for 3395 Stateless Address Autoconfiguration in IPv6", RFC 3041, 3396 January 2001. 3398 [RFC3053] Durand, A., Fasano, P., Guardini, I., and D. Lento, "IPv6 3399 Tunnel Broker", RFC 3053, January 2001. 3401 [RFC3056] Carpenter, B. and K. Moore, "Connection of IPv6 Domains 3402 via IPv4 Clouds", RFC 3056, February 2001. 3404 [RFC3177] IAB and IESG, "IAB/IESG Recommendations on IPv6 Address 3405 Allocations to Sites", RFC 3177, September 2001. 3407 [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., 3408 and M. Carney, "Dynamic Host Configuration Protocol for 3409 IPv6 (DHCPv6)", RFC 3315, July 2003. 3411 [RFC3618] Fenner, B. and D. Meyer, "Multicast Source Discovery 3412 Protocol (MSDP)", RFC 3618, October 2003. 3414 [RFC3704] Baker, F. and P. Savola, "Ingress Filtering for Multihomed 3415 Networks", BCP 84, RFC 3704, March 2004. 3417 [RFC3736] Droms, R., "Stateless Dynamic Host Configuration Protocol 3418 (DHCP) Service for IPv6", RFC 3736, April 2004. 3420 [RFC3904] Huitema, C., Austein, R., Satapati, S., and R. van der 3421 Pol, "Evaluation of IPv6 Transition Mechanisms for 3422 Unmanaged Networks", RFC 3904, September 2004. 3424 [RFC3931] Lau, J., Townsley, M., and I. Goyret, "Layer Two Tunneling 3425 Protocol - Version 3 (L2TPv3)", RFC 3931, March 2005. 3427 [RFC4001] Daniele, M., Haberman, B., Routhier, S., and J. 3428 Schoenwaelder, "Textual Conventions for Internet Network 3429 Addresses", RFC 4001, February 2005. 3431 [RFC4029] Lind, M., Ksinant, V., Park, S., Baudot, A., and P. 3432 Savola, "Scenarios and Analysis for Introducing IPv6 into 3433 ISP Networks", RFC 4029, March 2005. 3435 [RFC4191] Draves, R. and D. Thaler, "Default Router Preferences and 3436 More-Specific Routes", RFC 4191, November 2005. 3438 [RFC4213] Nordmark, E. and R. Gilligan, "Basic Transition Mechanisms 3439 for IPv6 Hosts and Routers", RFC 4213, October 2005. 3441 [RFC4214] Templin, F., Gleeson, T., Talwar, M., and D. Thaler, 3442 "Intra-Site Automatic Tunnel Addressing Protocol 3443 (ISATAP)", RFC 4214, October 2005. 3445 [RFC4380] Huitema, C., "Teredo: Tunneling IPv6 over UDP through 3446 Network Address Translations (NATs)", RFC 4380, 3447 February 2006. 3449 14.2. Informative References 3451 [6PE] De Clercq, J., Ooms, D., Prevost, S., and F. Le Faucheur, 3452 "Connecting IPv6 Islands across IPv4 Clouds with 3453 BGP(draft-ooms-v6ops-bgp-tunnel-04.txt)", October 2004. 3455 [BSR] Bhaskar, N., Gall, A., and S. Venaas, "Bootstrap Router 3456 (BSR) Mechanism for PIM(draft-ietf-pim-sm-bsr-04.txt)", 3457 January 2005. 3459 [DOCSIS 3.0 OSSI] 3460 CableLabs, CL., "DOCSIS 3.0 OSSI Specification(CM-SP- 3461 OSSIv3.0-D02-060504)", May 2006. 3463 [DOCSIS 3.0 Requirements] 3464 Droms, R., Durand, A., Kharbanda, D., and J-F. Mule, 3465 "DOCSIS 3.0 Requirements for IPv6 3466 Support(draft-mule-cablelabs-docsis3-ipv6-00.txt)", 3467 March 2006. 3469 [Dynamic Tunnel] 3470 Palet, J., Diaz, M., and P. Savola, "Analysis of IPv6 3471 Tunnel End-point Discovery 3472 Mechanisms(draft-palet-v6ops-tun-auto-disc-03.txt)", 3473 January 2005. 3475 [IEEE80211i] 3476 IEEE, "IEEE Standards for Information Technology: Part 11: 3477 Wireless LAN Medium Access Control (MAC) and Physical 3478 Layer (PHY) specifications, Amendment 6: Medium Access 3479 Control (MAC) Security Enhancements", July 2004. 3481 [IEEE8021X] 3482 IEEE, "IEEE Standards for Local and Metropolitan Area 3483 Networks: Port based Network Access Control, IEEE Std 3484 802.1X-2001", June 2001. 3486 [IPv6 Multicast] 3487 Savola, P., "IPv6 Multicast Deployment 3488 Issues(draft-mboned-ipv6-multicast-issues.txt)", 3489 April 2004. 3491 [ISISv6] Hopps, C., "Routing IPv6 with 3492 IS-IS(draft-ietf-isis-ipv6-06.txt)", October 2005. 3494 [MFF] Melsen, T. and S. Blake, "MAC-Forced Forwarding: A Method 3495 for Traffic Separation on an Ethernet Access 3496 Network(draft-melsen-mac-forced-fwd-04.txt)", 3497 January 2006. 3499 [Protocol 41] 3500 Palet, J., Olvera, C., and D. Fernandez, "Forwarding 3501 Protocol 41 in NAT 3502 Boxes(draft-palet-v6ops-proto41-nat-03.txt)", 3503 October 2003. 3505 [RF Interface] 3506 CableLabs, CL., "DOCSIS 2.0(CM-SP-RFIv2.0-I10-051209)", 3507 December 2005. 3509 [Security considerations for IPv6] 3510 Convery, S. and D. Miller, "IPv6 and IPv4 Threat 3511 Comparison and Best-Practice Evaluation", March 2004. 3513 [Softwire] 3514 Li, X., Durand, A., Ward, D., and S. Dawkins, Ed., 3515 "Softwire Problem 3516 Statement(draft-ietf-softwire-problem-statement-01.txt)", 3517 February 2006. 3519 [v6 auto-config] 3520 Wen, H., Zhu, X., Jiang, Y., and R. Yan, "The deployment 3521 of IPv6 stateless auto-configuration in access network", 3522 June 2005. 3524 [v6tc] Palet, J., Nielsent, K., Parent, F., Durand, A., 3525 Suryanarayanan, R., and P. Savola, "Goals for Tunneling 3526 Configuration(draft-palet-v6tc-goals-tunneling-00.txt)", 3527 August 2005. 3529 Authors' Addresses 3531 Salman Asadullah 3532 Cisco Systems 3533 170 West Tasman Drive 3534 San Jose, CA 95134 3535 USA 3537 Phone: 408 526 8982 3538 Email: sasad@cisco.com 3540 Adeel Ahmed 3541 Cisco Systems 3542 2200 East President George Bush Turnpike 3543 Richardson, TX 75082 3544 USA 3546 Phone: 469 255 4122 3547 Email: adahmed@cisco.com 3549 Ciprian Popoviciu 3550 Cisco Systems 3551 7025-6 Kit Creek Road 3552 Research Triangle Park, NC 27709 3553 USA 3555 Phone: 919 392 3723 3556 Email: cpopovic@cisco.com 3558 Pekka Savola 3559 CSC - Scientific Computing Ltd. 3560 Espoo 3561 Finland 3563 Email: psavola@funet.fi 3564 Jordi Palet Martinez 3565 Consulintel 3566 San Jose Artesano, 1 3567 Alcobendas, Madrid E-28108 3568 Spain 3570 Phone: +34 91 151 81 99 3571 Email: jordi.palet@consulintel.es 3573 Intellectual Property Statement 3575 The IETF takes no position regarding the validity or scope of any 3576 Intellectual Property Rights or other rights that might be claimed to 3577 pertain to the implementation or use of the technology described in 3578 this document or the extent to which any license under such rights 3579 might or might not be available; nor does it represent that it has 3580 made any independent effort to identify any such rights. Information 3581 on the procedures with respect to rights in RFC documents can be 3582 found in BCP 78 and BCP 79. 3584 Copies of IPR disclosures made to the IETF Secretariat and any 3585 assurances of licenses to be made available, or the result of an 3586 attempt made to obtain a general license or permission for the use of 3587 such proprietary rights by implementers or users of this 3588 specification can be obtained from the IETF on-line IPR repository at 3589 http://www.ietf.org/ipr. 3591 The IETF invites any interested party to bring to its attention any 3592 copyrights, patents or patent applications, or other proprietary 3593 rights that may cover technology that may be required to implement 3594 this standard. Please address the information to the IETF at 3595 ietf-ipr@ietf.org. 3597 Disclaimer of Validity 3599 This document and the information contained herein are provided on an 3600 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 3601 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 3602 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 3603 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 3604 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 3605 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 3607 Copyright Statement 3609 Copyright (C) The Internet Society (2006). This document is subject 3610 to the rights, licenses and restrictions contained in BCP 78, and 3611 except as set forth therein, the authors retain all their rights. 3613 Acknowledgment 3615 Funding for the RFC Editor function is currently provided by the 3616 Internet Society.