idnits 2.17.1 draft-ietf-v6ops-bb-deployment-scenarios-01.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.5 on line 3674. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 3657. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 3663. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement. ** 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. ** The document seems to lack an RFC 3979 Section 5, para. 1 IPR Disclosure Acknowledgement -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document uses RFC 3667 boilerplate or RFC 3978-like boilerplate instead of verbatim RFC 3978 boilerplate. After 6 May 2005, submission of drafts without verbatim RFC 3978 boilerplate is not accepted. The following non-3978 patterns matched text found in the document. That text should be removed or replaced: This document is an Internet-Draft and is subject to all provisions of Section 3 of RFC 3667. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 3 longer pages, the longest (page 4) being 59 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 70 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) == There are 8 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 "Author's Address" (or "Authors' Addresses") section title is misspelled. == Line 193 has weird spacing: '... some extra...' -- 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.) -- Couldn't find a document date in the document -- date freshness check skipped. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'RFC3775' is mentioned on line 137, but not defined ** Obsolete undefined reference: RFC 3775 (Obsoleted by RFC 6275) == Missing Reference: 'RFC3704' is mentioned on line 1214, but not defined == Missing Reference: 'RFC1918' is mentioned on line 2667, but not defined == Missing Reference: 'MFF' is mentioned on line 3452, but not defined == Unused Reference: 'RFC3053' is defined on line 3480, but no explicit reference was found in the text == Unused Reference: 'RFC3056' is defined on line 3484, but no explicit reference was found in the text == Unused Reference: 'RFC2473' is defined on line 3488, but no explicit reference was found in the text == Unused Reference: 'RFC2893' is defined on line 3492, but no explicit reference was found in the text == Unused Reference: 'RFC2529' is defined on line 3496, but no explicit reference was found in the text == Unused Reference: 'RFC3633' is defined on line 3520, but no explicit reference was found in the text == Unused Reference: 'RFC2472' is defined on line 3535, but no explicit reference was found in the text == Unused Reference: 'RFC3646' is defined on line 3546, but no explicit reference was found in the text == Unused Reference: 'ISATAP' is defined on line 3568, but no explicit reference was found in the text ** Downref: Normative reference to an Informational RFC: RFC 3053 ** Obsolete normative reference: RFC 2893 (Obsoleted by RFC 4213) ** Downref: Normative reference to an Informational RFC: RFC 3904 ** Obsolete normative reference: RFC 3513 (Obsoleted by RFC 4291) ** Obsolete normative reference: RFC 3736 (Obsoleted by RFC 8415) ** Obsolete normative reference: RFC 3315 (Obsoleted by RFC 8415) ** Obsolete normative reference: RFC 2462 (Obsoleted by RFC 4862) ** Obsolete normative reference: RFC 3633 (Obsoleted by RFC 8415) ** Obsolete normative reference: RFC 3041 (Obsoleted by RFC 4941) ** Downref: Normative reference to an Informational RFC: RFC 2516 -- Duplicate reference: RFC2516, mentioned in 'RFC2364', was also mentioned in 'RFC2516'. ** Downref: Normative reference to an Informational RFC: RFC 2516 (ref. 'RFC2364') ** Obsolete normative reference: RFC 2472 (Obsoleted by RFC 5072, RFC 5172) ** Obsolete normative reference: RFC 2461 (Obsoleted by RFC 4861) ** Obsolete normative reference: RFC 2770 (Obsoleted by RFC 3180) ** Downref: Normative reference to an Experimental RFC: RFC 3618 == Outdated reference: A later version (-07) exists of draft-ooms-v6ops-bgp-tunnel-04 == Outdated reference: A later version (-24) exists of draft-ietf-ngtrans-isatap-12 == Outdated reference: A later version (-07) exists of draft-ietf-v6ops-mech-v2-06 == Outdated reference: A later version (-12) exists of draft-ietf-pim-sm-bsr-04 Summary: 25 errors (**), 0 flaws (~~), 24 warnings (==), 6 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 IPv6 Working Group Salman Asadullah 2 INTERNET DRAFT Adeel Ahmed 3 April 2005 Ciprian Popoviciu 4 Cisco Systems 5 Jordi Palet 6 Consulintel 8 ISP IPv6 Deployment Scenarios in Broadband Access Networks 9 11 Status of this Memo 13 This document is an Internet-Draft and is subject to all provisions 14 of section 3 of RFC3667. By submitting this Internet-Draft, each 15 author represents that any applicable patent or other IPR claims of 16 which he or she is aware have been or will be disclosed, and any of 17 which he or she become aware will be disclosed, in accordance with 18 RFC3668. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF), its areas, and its working groups. Note that 22 other groups may also distribute working documents as 23 Internet-Drafts. 25 Internet-Drafts are draft documents valid for a maximum of six 26 months and may be updated, replaced, or obsoleted by other documents 27 at any time. It is inappropriate to use Internet-Drafts as reference 28 material or to cite them other than as "work in progress." 30 The list of current Internet-Drafts can be accessed at 31 http://www.ietf.org/ietf/1id-abstracts.txt. 33 The list of Internet-Draft Shadow Directories can be accessed at 34 http://www.ietf.org/shadow.html. 36 Abstract 38 This document provides detailed description of IPv6 deployment and 39 integration methods and scenarios in today's Service Provider (SP) 40 Broadband (BB) networks in coexistence with deployed IPv4 services. 42 Cable/HFC, BB Ethernet, xDSL and WLAN are the main BB technologies 43 that are currently deployed, and discussed in this document. The 44 emerging PLC/BPL access technology is also discussed for completion 45 purposes. In this document we will discuss main components of IPv6 46 BB networks and their differences from IPv4 BB networks and how IPv6 47 is deployed and integrated in each of these BB technologies using 48 tunneling mechanisms and native IPv6. 50 Table of Contents: 51 1. Introduction..................................................3 52 2. IPv6 Based BB Services........................................4 53 3. Scope of the Document.........................................5 54 4. Core Backbone Network.........................................5 55 4.1 Layer 2 Access Provider...................................6 56 4.2 Layer3 Access Provider....................................6 57 5. Tunneling Options.............................................7 58 5.1 Access over Tunnels-customers with public IPv4 address....7 59 5.2 Access over Tunnels-customers with private IPv4 address...8 60 5.3 Transition a portion of the IPv4 infrastructure...........8 61 6. Broadband Cable Networks .....................................9 62 6.1 Broadband Cable Network Elements .........................9 63 6.2 Deploying IPv6 in Cable Networks.........................10 64 6.2.1 Bridged CMTS Network .............................11 65 6.2.2 Routed CMTS Network ..............................14 66 6.3 IPv6 Multicast ..........................................22 67 6.4 IPv6 QoS ................................................22 68 6.5 IPv6 Security Considerations.............................23 69 6.6 IPv6 Network Management .................................24 70 6.6.1 Using IPv6 for Management in Cable Networks ......24 71 6.6.2 Updates to MIBs/Standards to support IPv6 ........25 72 7. Broadband DSL Networks.......................................25 73 7.1 DSL Network Elements ....................................25 74 7.2 Deploying IPv6 in IPv4 DSL Networks......................26 75 7.2.1 Point-to-Point Model..............................27 76 7.2.2 PPP Terminated Aggregation (PTA) Model............29 77 7.2.3 L2TP Access Aggregation (LAA) Model...............31 78 7.2.4 Hybrid Model for IPv4 and IPv6 Service ...........34 79 7.3 IPv6 Multicast...........................................36 80 7.3.1 ASM Based Deployments..............................36 81 7.3.1 SSM Based Deployments..............................37 82 7.4 IPv6 QoS.................................................38 83 7.5 IPv6 Security Considerations.............................38 84 7.6 IPv6 Network Management..................................39 85 8. Broadband Ethernet Networks..................................39 86 8.1 Ethernet Access Network Elements .......................39 87 8.2 Deploying IPv6 in IPv4 BB Ethernet Networks.............40 88 8.2.1 Point-to-Point Model.............................41 89 8.2.2 PPP Terminated Aggregation (PTA) Model...........43 90 8.2.3 L2TP Access Aggregation (LAA) Model..............45 91 8.2.4 Hybrid Model for IPv4 and IPv6 Service...........46 92 8.3 IPv6 Multicast..........................................47 93 8.4 IPv6 QoS................................................49 94 8.5 IPv6 Security Considerations............................50 95 8.6 IPv6 Network Management.................................50 96 9. Broadband Wireless LAN Networks..............................51 97 9.1 WLAN Deployment Scenarios...............................51 98 9.1.1 Layer 2 Switch Between AP and SP Edge Router.....52 99 9.1.2 Access Router Between AP and SP Edge Router......54 100 9.1.3 PPP Based Model..................................56 101 9.2 IPv6 Multicast..........................................58 102 9.3 IPv6 QoS................................................60 103 9.4 IPv6 Security Considerations............................60 104 9.5 IPv6 Network Management.................................61 105 10. Broadband Power Line Communications (PLC)...................61 106 10.1 PLC/BPL Access Network Elements.........................62 107 10.2 Deploying IPv6 in IPv4 PLC/BPL..........................63 108 10.2.1 IPv6 Related Infrastructure Changes..............63 109 10.2.2 Addressing.......................................63 110 10.2.3 Routing..........................................64 111 10.3 IPv6 Multicast..........................................65 112 10.4 IPv6 QoS................................................65 113 10.5 IPv6 Security Considerations............................65 114 10.6 IPv6 Network Management.................................65 115 11. Gap Analysis................................................65 116 12. Contributors................................................67 117 13. Acknowledgments.............................................67 118 14. References..................................................67 119 Authors Addresses...............................................70 121 1. Introduction 123 With the exponential growth of the Internet and increasing number of 124 end users, SPs are looking for new ways to evolve their current 125 network architecture to meet the needs of Internet ready appliances, 126 new applications and services. IPv6 is designed to enable SPs to 127 meet these challenges and provide new services to their customers. 129 As the number of devices per BB user increase exponentially 130 worldwide, Cable, DSL, Ethernet to the Home, Wireless, PLC/BPL and 131 other always-on access technologies can benefit from the huge 132 address range [RFC3513] of IPv6. Other benefits of IPv6 include the 133 capability to enhance end-to-end security, mobile communications, 134 and ease system management burdens. Some examples include 135 peer-to-peer communication without NAT traversal problems, being 136 able to access securely devices at home from work, enhanced IP 137 Mobility [RFC3775] and so on. 139 Therefore SPs are aggressively evaluating the capabilities of IPv6 140 to meet these needs. Some countries have taken a lead role in this 141 race and moved from testing and evaluation to real deployments of 142 IPv6 in the BB arena. Japan is a prime example along with other 143 countries that are looking at moving towards large scale production 144 deployments of IPv6. 146 The SPs are deploying tunneling mechanisms to transport IPv6 over 147 their existing IPv4 networks as a start as well as deploying native 148 IPv6 where possible. Deployment of tunneling solutions is simpler, 149 easier and more economical to start the IPv6 services, as they 150 require minimal investments and network infrastructure changes in 151 current SP model. Depending on customer needs and requirements a 152 native IPv6 deployment option might be more scalable and provide 153 required service performance. 155 2. IPv6 Based BB Services 157 At this point IPv6 based services are seen as a differentiator that 158 enables SPs to take advantage of the large IPv6 address space to 159 the extent that subscribers get up to fixed /48 prefixes versus the 160 single, temporary IPv4 addresses. Such resources allow the SPs to 161 better position themselves against the competition. The IPv6 162 deployments can be seen as a driver for lower service support costs 163 by eliminating NAT with its negative impact on applications and its 164 complex behavior. Another reason of IPv6 being popular in some 165 countries might be the government driven financial incentives and 166 favorable legislation towards the IPs who are deploying IPv6. 168 NTT East, Japan started a commercial dual-stack (devices capable of 169 forwarding IPv4 and IPv6 packets) IPv6 unicast service option early 170 this year for its ADSL and FTTH subscribers, under the name of 171 FLETS.Net [Dual Stack Access]. 173 For these users the IPv6 addresses are dedicated (/64 per user) and 174 are used when needed. However, this IPv6 service is available only 175 to the NTT-East ADSL and FTTH subscribers who are part of FLETS.NET 176 network and at this point does not provide connectivity to the 177 IPv6 Internet. 179 Some ISPs that are currently providing IPv4 based Multicast and 180 VoIP services are evaluating IPv6 to take advantage of the huge 181 address space and other useful features. The Multicast services 182 consist of video and audio streaming of several programs (streams). 183 The content provider will have certain content (which is of user 184 interest) and they would send these multicast streams to BB 185 subscribers. Today, when done through IPv4, there is generally a 186 single device directly attached to the CPE that receives the 187 Multicast stream. By moving to IPv6, ISP should be capable to 188 provide multiple streams to multiple devices on the customer site. 190 For instance in Japan, Cable TV and dish services are not very 191 popular, the users expect everything through the broadcasted, free 192 programs (traditional TV). In case of BB users however, they can get 193 some extra content through the SP, which is very reasonably priced 194 for 20 Mbps or 10/100 Mbps of bandwidth. Users sign up with a 195 content provider that is multicasting several channels of video and 196 audio. A subscriber would join the multicast group of interest 197 (after authentication) and will start receiving the stream(s). An 198 example of a video stream could be Disney movies and an example of 199 an audio stream could be Karaoke (part of same *,G group). Similar 200 to Cable TV, where customers sign up and pay for single programs or 201 packages of programs. 203 SPs are also offering IPv6 services over wireless links using 802.11 204 compliant WiFi Hot Spots. This enables users to take notebook PCs and 205 PDAs (Windows 2003 supports IPv6 capable Internet Explorer and Media 206 Player 9) along with them and connect to the Internet from various 207 locations without the restriction of staying indoors. 209 3. Scope of the Document 211 The focus of this document is to present the options available in 212 deploying IPv6 services in the access portion of a BB Service 213 Provider network namely Cable/HFC, BB Ethernet, xDSL, WLAN and 214 PLC/BPL. 216 This document briefly discusses the other elements of a provider 217 network as well. It provides different viable IPv6 deployment and 218 integration techniques and models for each of the above mentioned BB 219 technologies separately. The example list is not exhaustive but it 220 tries to be representative. 222 This document analyzes, how all the important parts of current IPv4 223 based Cable/HFC, BB Ethernet, xDSL, WLAN and PLC/BPL networks will 224 behave when IPv6 is integrated and deployed. 226 The following important pieces are discussed: 228 A. Available tunneling options 229 B. Devices that would require to be upgraded to support IPv6 230 C. Available IPv6 address assignment techniques and their use 231 D. Possible IPv6 Routing options and their use 232 E. IPv6 unicast and multicast packet transmission 233 F. Required IPv6 QoS parameters 234 G. Required IPv6 Security parameters 235 H. Required IPv6 Network Management parameters 237 It is important to note that the addressing rules provided 238 throughout this document represent an example that follows the 239 current assignment policies and recommendations of the registries. 240 They can be however adapted to the network and business model needs 241 of the ISPs. 243 The scope of the document is to advise on the ways of upgrading 244 an existing infrastructure to support IPv6 services. The 245 recommendation to upgrade a device to dual-stack does not stop an 246 SP from adding a new device to its network to perform the neccessary 247 IPv6 functions discussed. The costs involved could be offset by 248 lower impact on the existing IPv4 services. 250 4. Core/Backbone Network 252 This section intends to briefly discuss the some important elements 253 of a provider network tied to the deployment of IPv6. A more 254 detailed description of the core network is provided in other 255 documents [ISP Networks IPv6 Scenarios]. 257 There are two networks identified in the Broadband deployments: 259 A. Access Provider Network: This network provides the broadband 260 access and aggregates the subscribers. The subscriber traffic is 261 handed over to the Service Provider at Layer 2 or 3. 262 B. Service Provider Network: This network provides Intranet and 263 Internet IP connectivity for the subscribers. 265 The Service Provider network structure beyond the Edge routers that 266 interface with the Access provider is beyond the scope of this 267 document. 269 4.1 Layer 2 Access Provider Network 271 The Access Provider can deploy a Layer 2 network and perform no 272 routing of the subscriber traffic to the SP. The devices 273 that support each specific access technology are aggregated into a 274 highly redundant, resilient and scalable layer two core. The network 275 core can involve various technologies such as Ethernet, ATM etc. 276 The Service Provider Edge Router connects to the Access Provider 277 core. 279 In this type of a network the impact of deploying IPv6 is minimal. 280 The network is transparent to the Layer 3 protocol. The only possible 281 changes would come with the intent of filtering and monitoring IPv6 282 traffic based on layer 2 information such as IPv6 Ether Type Protocol 283 ID (0x86DD) or IPv6 multicast specific MAC addresses 284 (3333.xxxx.xxxx). 286 4.2 Layer3 Access Provider Network 288 The Access Provider can choose to terminate the Layer 2 domain and 289 route the IP traffic to the Service Provider network. Access Routers 290 are used to aggregate the subscriber traffic and route it over a 291 Layer3 core to the SP Edge Routers. In this case the impact of the 292 IPv6 deployment is significant. 294 The case studies in this document only present the significant 295 network elements of such a network: Customer Premises Equipment, 296 Access Router and Edge Router. In real networks the link between the 297 Access Router and the Edge Router involves other routers that are 298 part of the aggregation and the core layer of the Access Provider 299 network. 301 The Access Provider can forward the IPv6 traffic through its layer3 302 core in three possible ways: 304 A. IPv6 Tunneling: As a temporary solution, the Access Providers can 305 choose to use a tunneling mechanism to forward the subscriber IPv6 306 traffic to the Service Provider Edge Router. This approach has the 307 least impact on the Access Provider network however, as the number of 308 users increase and the amount of IPv6 traffic grows, the ISP will 309 have to evolve to one of the scenarios listed below. 311 B. Native IPv6 Deployment: The Access Provider routers are upgraded 312 to support IPv6 and can become dual-stack. In a dual-stack network 313 an IPv6 IGP such as OSPFv3 or IS-IS is enabled. RFC4029 discusses the 314 IGP selection options with their benefits and drawbacks. 316 C. MPLS 6PE Deployment [6PE]: If the Access Provider is running MPLS 317 in its IPv4 core it could use 6PE to forward IPv6 traffic over it. 318 In this case only a subset of routers close to the edge of the 319 network need to be IPv6 aware. With this approach BGP becomes 320 important in order to support 6PE. 322 The 6PE approach has the advantage of having minimal impact on the 323 Access Provider network. Fewer devices need to be upgraded and 324 configured while the MPLS core continues to switch the traffic 325 un-aware of the fact that it transports both IPv4 and IPv6 traffic. 326 6PE should be leveraged only if MPLS is already deployed in the 327 network. At the time of writing this document, a major disadvantage 328 of the 6PE solution is the fact that it does not support multicast 329 IPv6 traffic. 331 The native approach has the advantage of supporting IPv6 332 multicast traffic but it may imply a significant impact on the IPv4 333 operational network from software, configuration and possibly 334 hardware upgrade perspective. 336 More detailed Core Network deployment recommendations are discussed 337 in other documents [ISP Networks IPv6 Scenarios]. The handling of 338 IPv6 traffic in the Core of the Access Provider Network will not be 339 discussed for the remainder of this document. 341 5. Tunneling Overview 343 Service Providers might not be able to deploy native IPv6 today due 344 to the cost associated with HW and SW upgrades, the infrastructure 345 changes needed to their current network and the current demand for 346 the service. For these reasons, some SPs might choose tunneling 347 based transition mechanisms to start an IPv6 service offering and 348 move to native IPv6 deployment at a later time. 350 Several tunneling mechanisms were developed specifically 351 to transport IPv6 over existing IPv4 infrastructures. Several of 352 them have been standardized and their use depends on the existing SP 353 IPv4 network and the structure of the IPv6 service. The 354 requirements for the most appropriate mechanisms are described in 355 [Assisted Tunneling] and [v6tc] with more updates to follow. 356 Deploying IPv6 using tunneling techniques can imply as little 357 changes to the network as upgrading SW on tunnel end points (TEP). 358 A Service Provider could use tunneling to deploy IPv6 in the 359 following scenarios: 361 5.1 Access over Tunnels-customers with Public IPv4 Address 363 If the customer is a residential user, it can initiate the tunnel 364 directly from the IPv6 capable host to a tunnel termination router 365 located in the NAP or ISP network. The tunnel type used should be 366 decided by the SP but it should take into consideration its 367 availability on commonly used software running on the host machine. 368 Out of the many tunneling mechanisms developed [RFC3053, RFC3056, 369 RFC2473, ISATAP, RFC2893, RFC2529] some are more popular than the 370 others. 372 If the end customer has a GWR installed, then it could be used to 373 originate the tunnel and thus offer native IPv6 access to multiple 374 hosts on the customer network. In this case the GWR would need to be 375 upgraded to dual-stack in order to support IPv6. The GWR can be owned 376 by the customer or by the SP. 378 5.2 Access over Tunnels-Customers with Private IPv4 Address 380 If the end customer receives a private IPv4 address and needs to 381 initiate a tunnel through NAT, techniques like 6to4 will not work 382 since they rely on Public IPv4 address. In this case the end user 383 might have to use tunnels that can operate through NATs (such as 384 Teredo tunnel [OPS]). 386 The customer has the option to initiate the tunnel from the device 387 (GWR) that performs the NAT functionality, similar to the GWR 388 scenario discussed in section 5.1. This will imply HW replacement or 389 SW upgrade and a native IPv6 environment behind the GWR. 391 It is important to note that the customers of a Service Provider can 392 choose to establish tunnels to publicly available and free tunnel 393 services. Even though the quality of such services might not be high, 394 they provide free IPv6 access. In designing their IPv6 services, the 395 SPs should take into considerations such options available to their 396 potential customers. The IPv6 deployment should support services 397 (like multicast, VoIPv6 etc) and a level of quality that would make 398 the access through the SP worthwhile to potential subscribers. 400 It is also worth observing that initiating an IPv6 tunnel over IPv4 401 through already established IPv4 IPsec sessions would provide a 402 certain level of security to the IPv6 traffic [Tunnel through IPsec]. 404 5.3 Transition a Portion of the IPv4 Infrastructure 406 Tunnels can be used to transport the IPv6 traffic across a defined 407 segment of the network. As an example, the customer might connect 408 natively to the Network Access Provider and a tunnel is used to 409 transit the traffic over IPv4 to the ISP. In this case the tunnel 410 choice depends on its capabilities (for example, whether it supports 411 multicast or not), routing protocols used (there are several types 412 that can transport layer 2 messages such as GRE, L2TPv3 or 413 Pseudowire), manage-ability and scalability (dynamic versus static 414 tunnels). 416 This scenario implies that the access portion of the network has been 417 upgraded to support dual stack so the savings provided by tunneling 418 in this scenario are very small compared with the previous two. 419 Depending on the number of sites requiring the service and 420 considering the expenses required to manage the tunnels (some tunnels 421 are static while others are dynamic [Dynamic Tunnel]) in this case, 422 the SPs might find the native approach worth the additional 423 investments. 425 In all the scenarios listed above the tunnel selection process should 426 consider the IPv6 multicast forwarding capabilities if such service 427 is planned. As an example, 6to4 tunnels do not support IPv6 428 multicast traffic. 430 The operation, capabilities and deployment of various tunnel types 431 has been discussed extensively in the documents referenced earlier as 432 well as in [OPS, RFC3904]. Details of a tunnel based deployment are 433 offered in the next section of this document (section 6). In the case 434 of Cable Access where the current DOCSIS specifications do not 435 provide support for native IPv6 access. Although sections 7, 8, 9 436 and 10 focus on a native IPv6 deployments over DSL, FTTH, Wireless 437 and PLC/BPL because this approach is fully supported today, tunnel 438 based solutions are also possible in these cases based on the 439 guidelines of this section and some of the recommendations provided 440 in section 6. 442 6. Broadband Cable Networks 444 This section describes the infrastructure that exists today in 445 cable networks providing BB services to the home. It also describes 446 IPv6 deployment options in these cable networks. 448 DOCSIS standardizes and documents the operation of data over Cable 449 Networks. The current version of DOCSIS has limitations that do not 450 allow for a smooth implementation of native IPv6 transport. Some of 451 these limitations are discussed in this section. For this reason, 452 the IPv6 deployment scenarios discussed in this section for the 453 existent Cable Networks are tunnel based. The tunneling examples 454 presented here could also be applied to the other BB technologies 455 described in sections 7, 8, 9 and 10. 457 6.1 Broadband Cable Network Elements 459 Broadband cable networks are capable of transporting IP traffic to/ 460 from users to provide high speed Internet access and VOIP services. 461 The mechanism of transporting IP traffic over cable networks is 462 outlined in the DOCSIS specification [RF Interface]. 464 Here are some of the key elements of a Cable network: 466 Cable (HFC) Plant: Hybrid Fiber Coaxial plant, used as the underlying 467 transport 469 CMTS: Cable Modem Termination System (can be a Layer 2 bridging or 470 Layer 3 routing CMTS) 472 GWR: Residential Gateway Router (provides Layer 3 services to hosts) 473 Host: PC, notebook etc. which is connected to the CM or GWR 475 CM: Cable Modem 477 ER: Edge Router 479 MSO: Multiple Service Operator 481 Data Over Cable Service Interface Specification (DOCSIS): The 482 standards defining how data should be carried over cable networks. 484 Figure 6.1 illustrates the key elements of a Cable Network 486 <--- ACCESS ---><------ HFC ------><----- Aggregation / Core -----> 487 +-----+ +------+ 488 |Host |--| GWR | 489 +-----+ +--+---+ 490 | _ _ _ _ _ _ 491 +------+ | | 492 | CM |---| | 493 +------+ | | 494 | HFC | +------+ +--------+ 495 | | | | | Edge | 496 +-----+ +------+ | Network |---| CMTS |---| |===> ISP 497 |Host |--| CM |---| | | | | Router | Network 498 +-----+ +--+---+ | | +------+ +--------+ 499 |_ _ _ _ _ _| 500 +------+ | 501 +-----+ | GWR/ | | 502 |Host |--| CM |---------+ 503 +-----+ | | 504 +------+ Figure 6.1 506 6.2 Deploying IPv6 in Cable Networks 508 One of the motivators for an MSO to deploy IPv6 over their Cable 509 Network is to ease management burdens. IPv6 can be enabled on the 510 CM, CMTS and ER for management purposes. Currently portions of the 511 cable infrastructure use RFC1918 IPv4 addresses; however, there are 512 a finite number of those. Thus, IPv6 could have utility in the 513 cable space implemented on the management plane initially and later 514 on focused on the data plane for end user services. For more 515 details on using IPv6 for management in Cable Networks please refer 516 to section 6.6.1. 518 There are two different deployment modes in current cable networks: 519 a bridged CMTS environment and a routed CMTS environment. IPv6 can 520 be deployed in both of these environments. 522 1. Bridged CMTS Network 524 In this scenario, both the CM and CMTS bridge all data traffic. 526 Traffic to/from host devices is forwarded through the cable network 527 to the ER. The ER then routes traffic through the ISP network to the 528 Internet. The CM and CMTS support a certain degree of Layer 3 529 functionality for management purposes. 531 2. Routed CMTS Network 533 In a routed network, the CMTS forwards IP traffic to/from hosts 534 based on Layer 3 information using the IP source/destination address. 535 The CM acts as a Layer-2 bridge for forwarding data traffic and 536 supports some Layer 3 functionality for management purposes. 538 Some of the factors that hinder deployment of native IPv6 in current 539 cable networks include: 541 A. Problems with IPv6 Neighbor Discovery (ND) on CM and CMTS. These 542 devices rely on IGMP join messages to track membership of hosts that 543 are part of a particular IP Multicast group. In order to support ND 544 the CM and CMTS will need to support IGMPv3/MLDv2 or v1 snooping. 546 B. Classification of IPv6 traffic in the upstream and downstream 547 direction. The CM and CMTS will need to support classification of 548 IPv6 packets in order to give them the appropriate priority and 549 QoS. Without proper classification all IPv6 traffic will need to be 550 sent best effort (BE) which can cause problems when deploying 551 services like VOIP and IP Multicast video. 553 C. Changes need to be made to the DOCSIS specification to include 554 support for IPv6 on the CM and CMTS. This is imperative for 555 deploying native IPv6 over cable networks. 557 Due to the above mentioned limitations in deployed cable networks, 558 the only available option to cable operators is to use tunneling 559 techniques in order to transport IPv6 traffic over their current 560 IPv4 infrastructure. The following sections will cover these 561 deployment scenarios in more detail. 563 6.2.1 Deploying IPv6 in a Bridged CMTS Network 565 In IPv4 the CM and CMTS act as Layer 2 bridges and forward all data 566 traffic to/from the hosts and the ER. The hosts use the ER as their 567 Layer 3 next hop. If there is a GWR behind the CM it can act as a 568 next hop for all hosts and forward data traffic to/from the ER. 570 When deploying IPv6 in this environment, the CM and CMTS will 571 continue to be bridging devices in order to keep the transition 572 smooth and reduce operational complexity. The CM and CMTS will need 573 to bridge IPv6 unicast and multicast packets to/from the ER and the 574 hosts. If there is a GWR connected to the CM, it will need to forward 575 IPv6 unicast and multicast traffic to/from the ER. 577 Figure 6.2.1 illustrate the IPv6 deployment scenario 579 +-----+ +-----+ 580 |Host |--| GWR | 581 +-----+ +--+--+ 582 | _ _ _ _ _ _ 583 | +------+ | | 584 +--| CM |---| | 585 +------+ | | 586 | HFC | +------+ +--------+ 587 | | | | | Edge | 588 +-----+ +------+ | Network |---| CMTS |---| |===> ISP 589 |Host |--| CM |---| | | | | Router | Network 590 +-----+ +------+ | | +------+ +--------+ 591 |_ _ _ _ _ _| 593 <-------------><---------------------------------><---------------> 594 L3 Routed L2 Bridged L3 Routed 596 Figure 6.2.1 598 6.2.1.1 IPv6 Related Infrastructure Changes 600 In this scenario the CM and the CMTS bridge all data traffic so they 601 will need to support bridging of native IPv6 unicast and multicast 602 traffic. The following devices have to be upgraded to dual stack: 603 Host, GWR and ER. 605 6.2.1.2 Addressing 607 The proposed architecture for IPv6 deployment includes two components 608 that must be provisioned: the CM and the host. Additionally if there 609 is a GWR connected to the CM, it will also need to be provisioned. 610 The host or the GWR use the ER as their Layer 3 next hop. 612 6.2.1.2.1 IP Addressing for CM 614 The CM will be provisioned in the same way as in currently deployed 615 cable networks, using an IPv4 address on the cable interface 616 connected to the MSO network for management functions. During the 617 initialization phase, it will obtain its IPv4 address using DHCPv4, 618 and download a DOCSIS configuration file identified by the DHCPv4 619 server. 621 6.2.1.2.2 IP Addressing for Hosts 623 If there is no GWR connected to the CM, the host behind the CM will 624 get a /64 prefix assigned to it via stateless autoconfiguration or 625 DHCPv6. 627 If using stateless auto-configuration, the host listens for routing 628 advertisements (RA) from the ER. The RAs contain the /64 prefix 629 assigned to the segment. Upon receipt of an RA, the host constructs 630 the same way as DHCPv4 works today. The DHCPv6 messages exchanged 631 between the host and the DHCPv6 server are bridged by the CM and 632 the CMTS. 634 6.2.1.2.3 IP Addressing for GWR 636 The GWR can use stateless auto-configuration (RA) to obtain an 637 address for its upstream interface, the link between itself and 638 the ER. This step is followed by a request via DHCP-PD (Prefix 639 Delegation) for a prefix shorter than /64, typically /48, which 640 in turn is divided into /64s and assigned to its downstream 641 interfaces connecting to the hosts. 643 6.2.1.3 Data Forwarding 645 The CM and CMTS must be able to bridge native IPv6 unicast and 646 multicast traffic. The CMTS must provide IP connectivity between 647 hosts attached to CMs and must do so in a way that meets the 648 expectation of Ethernet attached customer equipment. In order to do 649 that, the CM and CMTS must forward Neighbor Discovery (ND) packets 650 between ER and the hosts attached to the CM. 652 Communication between hosts behind different CMs is always forwarded 653 through the CMTS. IPv6 communication between the different sites 654 relies on multicast IPv6 ND [RFC2461] frames being forwarded 655 correctly by the CM and the CMTS. As with the CM, a bridged CMTS that 656 selectively forwards multicast datagrams on the basis of IGMPv2 will 657 potentially break IPv6 ND. 659 In order to support IPv6 multicast applications across DOCSIS cable 660 networks, the CM and bridging CMTS need to support IGMPv3/MLDv2 or v1 661 snooping. MLD is almost identical to IGMP in IPv4, only the name and 662 numbers are changed. MLDv2 is identical to IGMPv3 and also supports 663 ASM (Any Source Multicast) and SSM (Single Source Multicast) 664 service models. Implementation work on CM/CMTS should be minimal 665 because the only significant difference between IPv4 IGMPv3 and IPv6 666 MLDv2 is the longer addresses in the protocol. 668 6.2.1.4 Routing 670 The hosts install a default route that points to the ER or the GWR. 671 No routing protocols are needed on these devices which generally 672 have limited resources. If there is a GWR present it will also use 673 static default route to the ER. 675 The ER runs an IGP such as OSPFv3 or IS-IS. The connected prefixes 676 have to be redistributed. If DHCP-PD is used, with every delegated 677 prefix a static route is installed by the ER. For this reason the 678 static routes must also be redistributed. Prefix summarization 679 should be done at the ER. 681 its IPv6 address by combining the prefix in the RA (/64) and a unique 682 identifier (e.g., its modified EUI-64 format interface ID). 684 If DHCPv6 is used to obtain an IPv6 address, it will work in much 685 6.2.2 Deploying IPv6 in a Routed CMTS Network 687 In an IPv4 routed CMTS network the CM still acts as a Layer-2 688 device and bridges all data traffic between its Ethernet interface 689 and cable interface connected to the cable operator network. The CMTS 690 acts as a Layer 3 router and may also include the ER functionality. 691 The hosts and the GWR use the CMTS as their Layer 3 next hop. 693 When deploying IPv6 in a routed CMTS network, the CM still acts 694 as a Layer-2 device and will need to bridge IPv6 unicast as well as 695 multicast traffic. The CMTS/ER will need to either tunnel IPv6 696 traffic or natively support IPv6. The host and GWR will use the 697 CMTS/ER as their Layer 3 next hop. 699 There could be five possible deployment scenarios for IPv6 in a 700 routed CMTS network: 702 1. IPv4 Cable (HFC) Network 704 In this scenario the cable network, including the CM and CMTS remain 705 IPv4 devices. The host and ER are upgraded to dual-stack. This is the 706 easiest way for a Cable Operator to provide IPv6 service as no 707 changes are made to the cable network. 709 2. IPv4 Cable (HFC) Network, GWR at Customer Site 711 In this case the cable network, including the CM and CMTS remain 712 IPv4 devices. The host, GWR and ER are upgraded to dual-stack. This 713 scenario is also easy to deploy since the cable operator just needs 714 to add GWR at the customer site. 716 3. Dual-stacked Cable (HFC) Network, CM and CMTS Support IPv6 718 In this scenario the CMTS is upgraded to dual-stack to support IPv4 719 and IPv6. Since the CMTS supports IPv6 it can acts as an ER as well. 720 The CM will act as a Layer-2 bridge but will need to bridge IPv6 721 unicast and multicast traffic. This scenario is not easy to deploy 722 since it requires changes to the DOCSIS specification. The CM and 723 CMTS may require HW and SW upgrades to support IPv6. 725 4. Dual-stacked Cable (HFC) Network, Standalone GWR and CMTS Support 726 IPv6 728 In this scenario there is a standalone GWR connected to the CM. 729 Since the IPv6 functionality exists on the GWR the CM does not need 730 to be dual-stack. The CMTS is upgraded to dual-stack and it can 731 incorporate the ER functionality. This scenario may also require HW 732 and SW changes on the GWR and CMTS. 734 5. Dual-stacked Cable (HFC) Network, Embedded GWR/CM and CMTS Support 735 IPv6 737 In this scenario the CM and GWR functionality exists on a single 738 device which needs to be upgraded to dual-stack. The CMTS will also 739 need to be upgraded to a dual-stack device. This scenario is also 740 difficult to deploy in existent cable network since it requires 741 changes on the Embedded GWR/CM and the CMTS. 743 The DOCSIS specification will also need to be modified to allow 744 native IPv6 support on the Embedded GWR/CM. 746 6.2.2.1 IPv4 Cable Network, Host and ER Upgraded to Dual-Stack 748 This is one of the most cost effective ways for a Cable Operator to 749 offer IPv6 services to its customers. Since the cable network remains 750 IPv4 there is relatively minimal cost involved in turning up IPv6 751 service. All IPv6 traffic is exchanged between the hosts and the ER. 753 Figure 6.2.2.1 illustrates this deployment scenario 755 +-----------+ +------+ +--------+ 756 +-----+ +-------+ | Cable | | | | Edge | 757 |Host |--| CM |----| (HFC) |----| CMTS |----| |=>ISP 758 +-----+ +-------+ | Network | | | | Router | Network 759 +-----------+ +------+ +--------+ 760 _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ 761 ()_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _() 762 IPv6-in-IPv4 tunnel 764 <---------><----------------------------------------><------------> 765 IPv4/v6 IPv4 only IPv4/v6 767 Figure 6.2.2.1 769 6.2.2.1.1 IPv6 Related Infrastructure Changes 771 In this scenario the CM and the CMTS will only need to support IPv4 772 so no changes need to be made to them or the cable network. The 773 following devices have to be upgraded to dual stack: Host and ER. 775 6.2.2.1.2 Addressing 777 The only device that needs to be assigned an IPv6 address at customer 778 site is the host. Host address assignment can be done in multiple 779 ways. Depending on the tunneling mechanism used it could be 780 automatic or might require manual configuration. 782 The host still receives an IPv4 address using DHCPv4, which works 783 the same way in currently deployed cable networks. In order to get 784 IPv6 connectivity, host devices will also need an IPv6 address and 785 a means to communicate with the ER. 787 6.2.2.1.3 Data Forwarding 789 All IPv6 traffic will be sent to/from the ER and the host device. In 790 order to transport IPv6 packets over the cable operator IPv4 791 network, the host and the ER will need to use one of the available 792 IPv6 in IPv4 tunneling mechanisms. 794 The host will use its IPv4 address to source the tunnel to the 795 ER. All IPv6 traffic will be forwarded to the ER, encapsulated in 796 IPv4 packets. The intermediate IPv4 nodes will forward this traffic 797 as regular IPv4 packets. The ER will need to terminate the tunnel 798 and/or provide other IPv6 services. 800 6.2.2.1.4 Routing 802 Routing configuration on the host will vary depending on 803 the tunneling technique used, in some cases a default or static 804 route might be needed to forward traffic to the next hop. 806 The ER runs an IGP such as OSPFv3 or ISIS. 808 6.2.2.2 IPv4 Cable Network, Host, GWR and ER Upgraded to Dual-Stack 810 The cable operator can provide IPv6 services to its customers, in 811 this scenario, by adding a GWR behind the CM. Since the GWR will 812 facilitate all IPv6 traffic to/from the host and the ER, the cable 813 network including the CM and CMTS do not need to support IPv6 and 814 can remain IPv4 devices. 816 Figure 6.2.2.2 illustrates this deployment scenario 818 +-----+ 819 |Host | 820 +--+--+ 821 | +-----------+ +------+ +--------+ 822 +---+---+ +-------+ | Cable | | | | Edge | 823 | GWR |--| CM |----| (HFC) |----| CMTS |----| |=>ISP 824 +-------+ +-------+ | Network | | | | Router | Network 825 +-----------+ +------+ +--------+ 826 _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ 827 ()_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _() 828 IPv6-in-IPv4 tunnel 830 <---------><---------------------------------------><-------------> 831 IPv4/v6 IPv4 only IPv4/v6 833 Figure 6.2.2.2 835 6.2.2.2.1 IPv6 Related Infrastructure Changes 837 In this scenario the CM and the CMTS will only need to support IPv4 838 so no changes need to be made to them or the cable network. The 839 following devices have to be upgraded to dual stack: Host, GWR and 840 ER. 842 6.2.2.2.2 Addressing 844 The only devices that needs to be assigned an IPv6 address at 845 customer site are the host and GWR. IPv6 address assignment can be 846 done statically at the GWR downstream interface. The GWR will send 847 out RA messages on its downstream interface which will be used by the 848 hosts to auto-configure themselves with an IPv6 address. The GWR can 849 also configure its upstream interface using RA messages from the ER 850 and use DHCP-PD for requesting a /48 prefix from the ER. This /48 851 prefix will be used to configure /64s on hosts connected to the GWR 852 downstream interfaces. Currently the DHCP-PD functionality cannot be 853 implemented if the DHCP-PD server is not the Edge Router. If the 854 DHCP-PD messages are relayed, the Edge Router does not have a 855 mechanism to learn the assigned prefixes and thus install the proper 856 routes to make that prefix reachable. Work is being done to address 857 this issue, one idea being to provide the Edge Router with a snooping 858 mechanism. The uplink to the ISP network is configured with a /64 859 prefix as well. 861 The GWR still receives a global IPv4 address on its upstream 862 interface using DHCPv4, which works the same way in currently 863 deployed cable networks. In order to get IPv6 connectivity to the 864 Internet the GWR will need to communicate with the ER. 866 6.2.2.2.3 Data Forwarding 868 All IPv6 traffic will be sent to/from the ER and the GWR, which will 869 forward IPv6 traffic to/from the host. In order to transport IPv6 870 packets over the cable operator IPv4 network, the GWR and the ER 871 will need to use one of the available IPv6 in IPv4 tunneling 872 mechanisms. All IPv6 traffic will need to go through the tunnel, once 873 it comes up. 875 The GWR will use its IPv4 address to source the tunnel to the ER. 876 The tunnel endpoint will be the IPv4 address of the ER. All IPv6 877 traffic will be forwarded to the ER, encapsulated in IPv4 packets. 878 The intermediate IPv4 nodes will forward this traffic as regular 879 IPv4 packets. In case of 6to4 tunneling, the ER will need to support 880 6to4 relay functionality in order to provide IPv6 Internet 881 connectivity to the GWR and hence the hosts connected to the GWR. 883 6.2.2.2.4 Routing 885 Depending on the tunneling technique used there might some 886 configuration needed on the GWR and the ER. If the ER is also 887 providing a 6to4 relay service then a default route will need to be 888 added to the GWR pointing to the ER, for all non-6to4 traffic. 890 If using manual tunneling, the GWR and ER can use static routing or 891 they can also configure RIPng. The RIPng updates can be transported 892 over a manual tunnel, which does not work when using 6to4 tunneling. 894 Customer routes can be carried to the ER using RIPng updates. The ER 895 can advertise these routes in its IGP. Prefix summarization should be 896 done at the ER. 898 If DHCP-PD is used for address assignment a static route is 899 automatically installed on the CMTS/ER for each delegated /48 prefix. 900 The static routes need to be redistributed into the IGP at the 901 CMTS/ER, so there is no need for a routing protocol between the 902 CMTS/ER and the GWR. 904 The ER runs an IGP such as OSPFv3 or ISIS. 906 6.2.2.3 Dual-stacked Cable (HFC) Network, CM and CMTS Support IPv6 908 In this scenario the Cable Operator can offer native IPv6 services 909 to its customers since the cable network including the CMTS supports 910 IPv6. The ER functionality can be included in the CMTS or it can 911 exist on a separate router connected to the CMTS upstream interface. 912 The CM will need to bridge IPv6 unicast and multicast traffic. 914 Figure 6.2.2.3 illustrates this deployment scenario 916 +-----------+ +-------------+ 917 +-----+ +-------+ | Cable | | CMTS / Edge | 918 |Host |--| CM |----| (HFC) |----| |=>ISP 919 +-----+ +-------+ | Network | | Router | Network 920 +-----------+ +-------------+ 922 <-------><----------------------------><----------------> 923 IPv4/v6 IPv4/v6 IPv4/v6 925 Figure 6.2.2.3 927 6.2.2.3.1 IPv6 Related Infrastructure Changes 929 Since the CM still acts as a Layer-2 bridge, it does not need to 930 be dual-stack. The CM will need to support bridging of IPv6 unicast 931 and multicast traffic and IGMPv3/MLDv2 or v1 snooping which requires 932 changes in the DOCSIS specification. In this scenario the following 933 devices have to be upgraded to dual stack: Host and CMTS/ER. 935 6.2.2.3.2 Addressing 937 In today's cable networks the CM receives a private IPv4 address 938 using DHCPv4 for management purposes. In an IPv6 environment, the 939 CM will continue to use an IPv4 address for management purposes. 940 The cable operator can also choose to assign an IPv6 address to the 941 CM for management, but the CM will have to be upgraded to support 942 this functionality. 944 IPv6 address assignment for the CM and host can be done via DHCP or 945 stateless autoconfiguration. If the CM uses an IPv4 address for 946 management, it will use DHCPv4 for its address assignment and the 947 CMTS will need to act as a DHCPv4 relay agent. If the CM uses an IPv6 948 address for management, it can use DHCPv6 with the CMTS acting as a 949 DHCPv6 relay agent or the CMTS can be statically configured with a 950 /64 prefix and it can send out RA messages out the cable interface. 951 The CMs connected to the cable interface can use the RA messages to 952 auto-configure themselves with an IPv6 address. All CMs connected to 953 the cable interface will be in the same subnet. 955 The hosts can receive their IPv6 address via DHCPv6 or stateless 956 autoconfiguration. With DHCPv6, the CMTS may need to act as a DHCPv6 957 relay agent and forward DHCP messages between the hosts and the DHCP 958 server. With stateless autoconfiguration, the CMTS will be configured 959 with multiple /64 prefixes and send out RA messages to the hosts. 960 If the CMTS is not also acting as an ER, the RA messages will come 961 from the ER connected to the CMTS upstream interface. The CMTS will 962 need to forward the RA messages downstream or act as an ND proxy. 964 6.2.2.3.3 Data Forwarding 966 All IPv6 traffic will be sent to/from the CMTS and hosts. Data 967 forwarding will work the same way it works in currently deployed 968 cable networks. The CMTS will forward IPv6 traffic to/from hosts 969 based on the IP source/destination address. 971 6.2.2.3.4 Routing 973 No routing protocols are needed between the CMTS and the host 974 since the CM and host are directly connected to the CMTS cable 975 interface. Since the CMTS supports IPv6, hosts will use the CMTS 976 as their Layer 3 next hop. 978 If the CMTS is also acting as an ER, it runs an IGP such as OSPFv3 979 or ISIS. 981 6.2.2.4 Dual-Stacked Cable (HFC) Network, Standalone GWR and CMTS 982 Support IPv6 984 In this case the cable operator can offer IPv6 services to its 985 customers by adding a GWR between the CM and the host. The GWR will 986 facilitate IPv6 communication between the host and the CMTS/ER. The 987 CMTS will be upgraded to dual-stack to support IPv6 and can acts as 988 an ER as well. The CM will act as a bridge for forwarding data 989 traffic and does not need to support IPv6. 991 This scenario is similar to the case described in section 6.2.2.2. 992 The only difference in this case is the ER functionality exists on 993 the CMTS instead of a separate router in the cable operator network. 995 Figure 6.2.2.4 illustrates this deployment scenario 996 +-----------+ +------------+ 997 +------+ +-------+ +-------+ | Cable | |CMTS / Edge | 998 | Host |---| GWR |--| CM |---| (HFC) |----| |=>ISP 999 +------+ +-------+ +-------+ | Network | | Router |Network 1000 +-----------+ +------------+ 1002 _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ 1003 ()_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _() 1004 IPv6-in-IPv4 tunnel 1005 <-----------------><--------------------------------><--------------> 1006 IPv4/v6 IPv4 IPv4/v6 1008 Figure 6.2.2.4 1010 6.2.2.4.1 IPv6 Related Infrastructure Changes 1012 Since the CM still acts as a Layer-2 bridge, it does not need to 1013 be dual-stack nor does it need to support IPv6. In this scenario 1014 the following devices have to be upgraded to dual stack: Host, GWR 1015 and CMTS/ER. 1017 6.2.2.4.2 Addressing 1019 The CM will still receive a private IPv4 address using DHCPv4 which 1020 works the same way in existent cable networks. The CMTS will act as 1021 DHCPv4 relay agent. 1023 The address assignment for the host and GWR happens in a similar 1024 manner as described in section 6.2.2.2.2. 1026 6.2.2.4.3 Data Forwarding 1028 Data forwarding between the host and CMTS/ER is facilitated by the 1029 GWR and happens in a similar manner as described in section 1030 6.2.2.2.3. 1032 6.2.2.4.4 Routing 1034 In this case routing is very similar to the case described in 1035 section 6.2.2.2.4. Since the CMTS now incorporates the ER 1036 functionality, it will need to run an IGP such as OSPFv3 or ISIS. 1038 6.2.2.5 Dual-Stacked Cable (HFC) Network, Embedded GWR/CM and CMTS 1039 Support IPv6 1041 In this scenario the Cable Operator can offer native IPv6 services 1042 to its customers since the cable network including the CM/Embedded 1043 GWR and CMTS support IPv6. The ER functionality can be included in 1044 the CMTS or it can exist on a separate router connected to the CMTS 1045 upstream interface. The CM/Embedded GWR acts as a Layer 3 device. 1047 Figure 6.2.2.5 illustrates this deployment scenario 1049 +-----------+ +-------------+ 1050 +-----+ +-----------+ | Cable | | CMTS / Edge | 1051 |Host |---| CM / GWR |----| (HFC) |----| |=> ISP 1052 +-----+ +-----------+ | Network | | Router | Network 1053 +-----------+ +-------------+ 1055 <----------------------------------------------------------> 1056 IPv4/v6 1058 Figure 6.2.2.5 1060 6.2.2.5.1 IPv6 Related Infrastructure Changes 1062 Since the CM/GWR acts as a Layer 3 device, IPv6 can be deployed 1063 end-to-end. In this scenario the following devices have to be 1064 upgraded to dual-stack: Host, CM/GWR and CMTS/ER. 1066 6.2.2.5.2 Addressing 1068 Since the CM/GWR is dual-stack, it can receive an IPv4 or IPv6 1069 address using DHCP for management purposes. As the GWR functionality 1070 is Embedded in the CM, it will need an IPv6 address for forwarding 1071 data traffic. IPv6 address assignment for the CM/GWR and host can be 1072 done via DHCPv6 or DHCP-PD. 1074 If using DHCPv6 the CMTS will need to act as DHCPv6 relay agent. The 1075 host and CM/GWR will receive IPv6 addresses from pools of /64 1076 prefixes configured on the DHCPv6 server. The CMTS will need to glean 1077 pertinent information from the DHCP Offer messages, sent from the 1078 DHCP server to the DHCP clients (host and CM/GWR), much like it does 1079 today in DHCPv4. All CM/GWR connected to the same cable interface on 1080 the CMTS belong to same management /64 prefix. The hosts connected 1081 to the same cable interface on the CMTS may belong to different /64 1082 customer prefixes as the CMTS may have multiple /64 prefixes 1083 configured under its cable interfaces. 1085 It is also possible to use DHCP-PD for IPv6 address assignment. In 1086 this case the CM/GWR will use stateless auto-configuration to assign 1087 an IPv6 address to its upstream interface using the /64 prefix 1088 sent by the CMTS/ER in RA message. Once the CM/GWR assigns an IPv6 1089 address to its upstream interface it will request a /48 prefix from 1090 the CMTS/ER and chop this /48 prefix into /64s for assigning IPv6 1091 addresses to hosts. Currently the DHCP-PD functionality cannot be 1092 implemented if the DHCP-PD server is not the Edge Router. If the 1093 DHCP-PD messages are relayed, the Edge Router does not have a 1094 mechanism to learn the assigned prefixes and thus install the proper 1095 routes to make that prefix reachable. Work is being done to address 1096 this issue, one idea being to provide the Edge Router with a snooping 1097 mechanism. The uplink to the ISP network is configured with a /64 1098 prefix as well. 1100 6.2.2.5.3 Data Forwarding 1102 The host will use the CM/GWR as the Layer 3 next hop. The CM/GWR 1103 will forward all IPv6 traffic to/from the CMTS/ER and hosts. The 1104 CMTS/ER will forward IPv6 traffic to/from hosts based on the IP 1105 source/destination address. 1107 6.2.2.5.4 Routing 1109 The CM/GWR can use a static default route pointing to the CMTS/ER or 1110 it can run a routing protocol such as RIP-ng or OSPFv3 between itself 1111 and the CMTS. Customer routes from behind the CM/GWR can be carried 1112 to the CMTS using routing updates. 1114 If DHCP-PD is used for address assignment a static route is 1115 automatically installed on the CMTS/ER for each delegated /48 prefix. 1116 The static routes need to be redistributed into the IGP at the 1117 CMTS/ER so there is no need for a routing protocol between the 1118 CMTS/ER and the GWR. 1120 If the CMTS is also acting as an ER, it runs an IGP such as OSPFv3 1121 or ISIS. 1123 6.3 IPv6 Multicast 1125 In order to support IPv6 multicast applications across DOCSIS cable 1126 networks, the CM and bridging CMTS will need to support IGMPv3/MLDv2 1127 or v1 snooping. MLD is almost identical to IGMP in IPv4, only the 1128 name and numbers are changed. MLDv2 is almost identical to IGMPv3 1129 and also supports ASM (Any Source Multicast) and SSM (Single Source 1130 Multicast) service models. 1132 SSM is more suited for deployments where the SP intends to provide 1133 paid content to the users (Video or Audio). This type of services 1134 are expected to be of primary interest. Moreover, the simplicity of 1135 the SSM model often times override the scalability issues that would 1136 be resolved in an ASM model. ASM is however an option that is 1137 discussed in section 7.3.1. The Layer 3 CM, GWR and 1138 Layer 3 routed CMTS/ER will need to be enabled with PIM-SSM, which 1139 requires the definition and support for IGMPv3/MLDv1 or v2 snooping, 1140 in order to track join/leave messages from the hosts. Another option 1141 would be for the Layer 3 CM or GWR to support MLD proxy routing. The 1142 Layer 3 next hop for the hosts needs to support MLD. 1144 Please refer to section 7.3 for more IPv6 multicast details. 1146 6.4 IPv6 QoS 1148 IPv6 will not change or add any queuing/scheduling functionality 1149 already existing in DOCSIS specifications. But the QoS mechanisms on 1150 the CMTS and CM would need to be IPv6 capable. This includes support 1151 for IPv6 classifiers, so that data traffic to/from host devices can 1152 be classified appropriately into different service flows and be 1153 assigned appropriate priority. Appropriate classification criteria 1154 would need to be implemented for unicast and multicast traffic. 1156 In order to classify IPv6 traffic the following classifiers would 1157 need to be modified in the DOCSIS specification to support the 1158 128-bit IPv6 address: 1160 A. IP source address 1161 B. IP source mask 1162 C. IP destination address 1163 D. IP destination mask 1164 E. IP traffic class (DSCP) 1166 The following classifiers would be new for IPv6: 1168 A. IP version 1169 B. Flow label (optional) 1171 Traffic classification and marking should be done at the CM for 1172 upstream traffic and the CMTS/ER for downstream traffic in order to 1173 support the various types of services: data, voice, video. The same 1174 IPv4 QoS concepts and methodologies should be applied for IPv6 as 1175 well. 1177 It is important to note that when traffic is encrypted end-to-end, 1178 the traversed network devices will not have access to many of the 1179 packet fields used for classification purposes. In these cases 1180 routers will most likely place the packets in the default classes. 1181 The QoS design should take into consideration this scenario and try 1182 to use mainly IP header fields for classification purposes. 1184 6.5 IPv6 Security Considerations 1186 Security in a DOCSIS cable network is provided using Baseline Privacy 1187 Plus (BPI+). The only part that is dependent on IP addresses is 1188 encrypted multicast. Semantically, multicast encryption would work 1189 the same way in an IPv6 environment as in the IPv4 network. However, 1190 appropriate enhancements will be needed in the DOCSIS specification 1191 to support encrypted IPv6 multicast. 1193 The other aspect of security enhancement is mandated IPSec support 1194 in IPv6. The IPv6 specifications mandate implementation of IPSec, 1195 but they do not mandate its use. The IPv4 specifications do not 1196 mandate IPSec. IPSec is the same for both IPv4 and IPv6, but it 1197 still requires a key distribution mechanism. Cable operators may 1198 consider deploying it end-to-end on IPv6 as there is not an 1199 intermediate device(i.e. NAT). 1201 There are limited changes that have to be done for hosts in order to 1202 enhance security. The Privacy extensions [RFC3041] for 1203 autoconfiguration should be used by the hosts. IPv6 firewall 1204 functions could be enabled, if available on the host or GWR. 1206 The ISP provides security against attacks that come form its own 1207 subscribers but it could also implement security services that 1208 protect its subscribers from attacks sourced from the outside of its 1209 network. Such services do not apply at the access level of the 1210 network discussed here. 1212 The CMTS/ER should protect the ISP network and the other subscribers 1213 against attacks by one of its own customers. For this reason Unicast 1214 Reverse Path Forwarding (uRPF) [RFC3704] and ACLs should be used on 1215 all interfaces facing subscribers. Filtering should be implemented 1216 with regard for the operational requirements of IPv6 [Security 1217 considerations for IPv6]. 1219 The CMTS/ER should protect its processing resources against floods of 1220 valid customer control traffic such as: Router and Neighbor 1221 Solicitations, MLD Requests. 1223 All other security features used with the IPv4 service should be 1224 similarly applied to IPv6 as well. 1226 6.6 IPv6 Network Management 1228 IPv6 can have many applications in Cable Networks. MSOs can initially 1229 implement IPv6 on the control plane and use it to manage the 1230 thousands of devices connected to the CMTS. This would be a good way 1231 to introduce IPv6 in a Cable Network. Later on the MSO can extend 1232 IPv6 to the data plane and use it to carry customer as well as 1233 management traffic. 1235 6.6.1 Using IPv6 for Management in Cable Networks 1237 IPv6 can be enabled in a Cable Network for management of devices like 1238 CM, CMTS and ER. With the roll out of advanced services like VoIP and 1239 Video-over-IP, MSOs are looking for ways to manage the large number 1240 of devices connected to the CMTS. In IPv4, an RFC1918 address is 1241 assigned to these devices like CM for management purposes. Since 1242 there is a finite number of RFC1918 addresses available, it is 1243 becoming difficult for MSOs to manage these devices. 1245 By using IPv6 for management purposes, MSOs can scale their network 1246 management systems to meet their needs. The CMTS/ER can be 1247 configured with a /64 management prefix which is shared among all 1248 CMs connected to the CMTS cable interface. Addressing for the CMs 1249 can be done via stateless autoconfiguration. Once the CMs receive 1250 the /64 prefix from the CMTS/ER via RA they can configure themselves 1251 with an IPv6 address. 1253 If there are devices behind the CM which need to be managed by the 1254 MSO, another /64 prefix can be defined on the CMTS/ER. These devices 1255 can also use stateless autoconfiguration to assign themselves an IPv6 1256 address. 1258 Traffic sourced from or destined to the management prefix should not 1259 cross the MSO's network boundaries. 1261 In this scenario IPv6 will only be used for managing these devices 1262 on the Cable Network, all data traffic will still be forwarded by 1263 the CM and CMTS/ER using IPv4. 1265 6.6.2 Updates to MIBs/Standards to support IPv6 1267 The current DOCSIS, PacketCable, and CableHome MIBs are already 1268 designed to support IPv6 objects. In this case, IPv6 will neither 1269 add, nor change any of the functionality of these MIBs. An object to 1270 identify the IP version, InetAddressType has been added to all the 1271 appropriate SNMP objects related to IP address. 1273 There are some exceptions, the following MIBs might need to add IPv6 1274 support: 1276 On the CMTS 1278 A. DOCS-QOS-MIB 1279 B. DOCS-SUBMGT-MIB (Subscriber Management Interface Specification 1280 ANNEX B) 1282 On the CM 1284 A. DOCS-QOS-MIB 1285 B. DOCS-CABLE-DEVICE-MIB (or RFC2669) 1287 7. Broadband DSL Networks 1289 This section describes the IPv6 deployment options in today's 1290 High Speed DSL Networks. 1292 7.1 DSL Network Elements 1294 Digital Subscriber Line (DSL) broadband services provide users 1295 with IP connectivity over the existing twisted-pair telephone lines 1296 called the local-loop. A wide range of bandwidth offerings are 1297 available depending on the quality of the line and the distance 1298 between the Customer Premises Equipment and the DSLAM. 1300 The following network elements are typical of a DSL network [ISP 1301 Transition Scenarios]: 1303 DSL Modem: It can be a stand alone device, it can be incorporated 1304 in the host, it can incorporate router functionalities and also 1305 have the capabilities to act as a CPE router. 1307 Customer Premises Router: It is used to provide Layer 3 services 1308 for customer premises networks. It is usually used to provide 1309 firewalling functions and segment broadcast domains for a Small 1310 business. 1312 DSL Access Multiplexer (DSLAM): It terminates multiple twisted 1313 pair telephone lines and provides aggregation to BRAS. 1315 Broadband Remote Access Server (BRAS): It aggregates or terminates 1316 multiple PVC corresponding to the subscriber DSL circuits. 1318 Edge Router (ER): It provides the Layer 3 interface to the ISP 1319 network. 1321 Figure 7.1 depicts all the network elements mentioned. 1323 Customer Premises | Network Access Provider | Network Service Provider 1324 CP NAP NSP 1326 +-----+ +------+ +------+ +--------+ 1327 |Hosts|--|Router| +--+ BRAS +---+ Edge | ISP 1328 +-----+ +--+---+ | | | | Router +===> Network 1329 | | +------+ +--------+ 1330 +--+---+ | 1331 | DSL +--+ | 1332 |Modem | | | 1333 +------+ | +-----+ | 1334 +--+ | | 1335 +------+ |DSLAM+--+ 1336 +-----+ | DSL | +--+ | 1337 |Hosts|--+Modem +--+ +-----+ 1338 +-----+ +--+---+ 1340 Figure 7.1 1342 7.2 Deploying IPv6 in IPv4 DSL Networks 1344 There are three main design approaches to providing IPv4 connectivity 1345 over a DSL infrastructure: 1347 1. Point-to-Point Model: Each subscriber connects to the DSLAM 1348 over a twisted pair and is provided with a unique PVC that links it 1349 to the service provider. The PVCs can be terminated at the BRAS or 1350 at the Edge Router. This type of design is not very scalable if the 1351 PVCs are not terminated as close as possible to the DSLAM (at the 1352 BRAS). In this case a large number of layer two circuits has to be 1353 maintained over a significant portion of the network. The layer two 1354 domains can be terminated at the ER in three ways: 1356 A. In a common bridge group with a virtual interface that routes it 1357 out. 1359 B. Enable a Routed Bridged Encapsulation feature, all users could be 1360 part of the same subnet. This is the most common deployment type of 1361 IPv4 over DSL but it might not be the best choice in IPv6 where 1362 address availability is not an issue. 1364 C. Terminate the PVC at Layer 3, each PVC has its own prefix. This is 1365 the approach that seems more suitable for IPv6 and presented in 7.2.1 1366 In none of these cases the CPE (DSL Modem) has to be upgraded. 1368 2. PPP Terminated Aggregation (PTA) Model: PPP sessions are opened 1369 between each subscriber and the BRAS. The BRAS terminates the PPP 1370 sessions and provides Layer 3 connectivity between the subscriber 1371 and the ISP. This model is presented in section 7.2.2. 1373 3. L2TP Access Aggregation (LAA) Model: PPP sessions are opened 1374 between each subscriber and the ISP Edge Router. The BRAS tunnels the 1375 subscriber PPP sessions to the ISP by encapsulating them into L2TPv2 1376 tunnels. This model is presented in section 7.2.3. 1378 In aggregation models the BRAS terminates the subscriber PVCs and 1379 aggregates their connections before providing access to the ISP. 1381 In order to maintain the deployment concepts and business models 1382 proven and used with existent revenue generating IPv4 services, the 1383 IPv6 deployment will match the IPv4 one. This approach is presented 1384 in sections 7.2.1-3 that describe current IPv4 over DSL broadband 1385 access deployments. Under certain circumstances where new service 1386 types or service needs justify it, IPv4 and IPv6 network logical 1387 architectures could be different as described in section 7.2.4. 1389 7.2.1 Point-to-Point Model 1391 In this scenario the Ethernet frames from the Host or the Customer 1392 Premises Router are bridged over the PVC assigned to the subscriber. 1394 Figure 7.2.1 describes the protocol architecture of this model. 1396 Customer Premises NAP NSP 1397 <-------------------------> <---------------> <--------------------> 1399 +-----+ +-------+ +-----+ +--------+ +----------+ 1400 |Hosts|--+Router +--+ DSL +--+ DSLAM +--------+ Edge | ISP 1401 +-----+ +-------+ |Modem| +--------+ | Router +==> Network 1402 +-----+ +----------+ 1403 <----------------------------> 1404 ATM 1405 Figure 7.2.1 1407 7.2.1.1 IPv6 Related Infrastructure Changes 1409 In this scenario the DSL modem and the entire NAP is Layer 3 unaware, 1410 so no changes are needed to support IPv6. The following devices have 1411 to be upgraded to dual stack: Host, Customer Router (if present) and 1412 Edge Router. 1414 7.2.1.2 Addressing 1416 The Hosts or the Customer Routers have the Edge Router as their Layer 1417 3 next hop. 1419 If there is no Customer Router all the hosts on the subscriber site 1420 belong to the same /64 subnet that is statically configured on the 1421 Edge Router for that subscriber PVC. The hosts can use stateless 1422 autoconfiguration or stateful DHCPv6 based configuration to acquire 1423 an address via the Edge Router. 1425 If a Customer Router is present: 1427 A. It is statically configured with an address on the /64 subnet 1428 between itself and the Edge Router, and with /64 prefixes on the 1429 interfaces connecting the hosts on the customer site. This is not a 1430 desired provisioning method being expensive and difficult to manage. 1432 B. It can use its link-local address to communicate with the ER. 1433 It can also dynamically acquire through stateless autoconfiguration 1434 the prefix for the link between itself and the ER. The later option 1435 allows it to contact a remote DHCPv6 server if needed. This step is 1436 followed by a request via DHCP-PD for a prefix shorter than /64 1437 that in turn is divided in /64s and assigned to its downstream 1438 interfaces. 1440 The Edge Router has a /64 prefix configured for each subscriber VLAN. 1441 Each VLAN should be enabled to relay DHCPv6 requests from the 1442 subscribers to DHCPv6 servers in the ISP network. The VLANs providing 1443 access for subscribers that use DHCP-PD as well, have to be enabled 1444 to support the feature. Currently the DHCP-PD functionality cannot be 1445 implemented if the DHCP-PD server is not the Edge Router. If the 1446 DHCP-PD messages are relayed, the Edge Router does not have a 1447 mechanism to learn the assigned prefixes and thus install the proper 1448 routes to make that prefix reachable. Work is being done to address 1449 this issue, one idea being to provide the Edge Router with a snooping 1450 mechanism. The uplink to the ISP network is configured with a /64 1451 prefix as well. 1453 The prefixes used for subscriber links and the ones delegated via 1454 DHCP-PD should be planned in a manner that allows as much 1455 summarization as possible at the Edge Router. 1457 Other information of interest to the host, such as DNS, is provided 1458 through stateful DHCPv6 [RFC3315] and stateless DHCPv6 [RFC3736]. 1460 7.2.1.3 Routing 1462 The CPE devices are configured with a default route that points to 1463 the Edge router. No routing protocols are needed on these devices 1464 which generally have limited resources. 1466 The Edge Router runs the IPv6 IGP used in the NSP: OSPFv3 or IS-IS. 1467 The connected prefixes have to be redistributed. If DHCP-PD is used, 1468 with every delegated prefix a static route is installed by the Edge 1469 Router. For this reason the static routes must also be redistributed. 1470 Prefix summarization should be done at the Edge Router. 1472 7.2.2 PPP Terminated Aggregation (PTA) Model 1474 The PTA architecture relies on PPP-based protocols (PPPoA [RFC2364] 1475 and PPPoE [RFC2516]). The PPP sessions are initiated by Customer 1476 Premise Equipment and are terminated at the BRAS. The BRAS 1477 authorizes the session, authenticates the subscriber, and provides 1478 an IP address on behalf of the ISP. The BRAS then does Layer 3 1479 routing of the subscriber traffic to the NSP Edge Router. This model 1480 is often used when the NSP is also the NAP. 1482 There are two types of PPP encapsulations that can be leveraged with 1483 this model: 1485 A. Connection using PPPoA 1487 Customer Premises NAP NSP 1488 <--------------------> <----------------------> <-----------------> 1490 +-----------+ 1491 | AAA | 1492 +-------+ Radius | 1493 | | TACACS | 1494 | +-----------+ 1495 | 1496 +-----+ +-------+ +--------+ +----+-----+ +-----------+ 1497 |Hosts|--+Router +------+ DSLAM +-+ BRAS +-+ Edge | 1498 +-----+ +-------+ +--------+ +----------+ | Router +=>Core 1499 +-----------+ 1500 <--------------------------> 1501 PPP 1503 Figure 7.2.2.1 1505 The PPP sessions are initiated by the Customer Premise Equipment. The 1506 BRAS authenticates the subscriber against a local or a remote 1507 database. Once the session is established, the BRAS provides an 1508 address and maybe a DNS server to the user, information acquired from 1509 the subscriber profile or from a DHCP server. 1511 This solution scales better then the Point-to-Point but since there 1512 is only one PPP session per ATM PVC the subscriber can choose a 1513 single ISP service at a time. 1515 B. Connection using PPPoE 1517 Customer Premises NAP NSP 1518 <----------------------------> <-------------------> <-----------------> 1520 +-----------+ 1521 | AAA | 1522 +-------+ Radius | 1523 | | TACACS | 1524 | +-----------+ 1525 | 1526 +-----+ +-------+ +--------+ +----+-----+ +-----------+ 1527 |Hosts|--+Router +------------+ DSLAM +-+ BRAS +-+ Edge | C 1528 +-----+ +-------+ +--------+ +----------+ | Router +=>O 1529 | | R 1530 +-----------+ E 1531 <--------------------------------> 1532 PPP 1534 Figure 7.2.2.2 1536 The operation of PPPoE is similar to PPPoA with the exception that 1537 with PPPoE multiple sessions can be supported over the same PVC thus 1538 allowing the subscriber to connect to multiple services at the same 1539 time. The hosts can initiate the PPPoE sessions as well. It is 1540 important to remember that the PPPoE encapsulation reduces the IP 1541 MTU available for the customer traffic due to additional headers. 1543 The network design and operation of the PTA model is the same 1544 regardless of the PPP encapsulation type used. 1546 7.2.2.1 IPv6 Related Infrastructure Changes 1548 In this scenario the BRAS is Layer 3 aware and it has to be upgraded 1549 to support IPv6. Since the BRAS terminates the PPP sessions it has to 1550 support the implementation of these PPP protocols with IPv6. The 1551 following devices have to be upgraded to dual stack: Host, Customer 1552 Router (if present), BRAS and Edge Router. 1554 7.2.2.2 Addressing 1556 The BRAS terminates the PPP sessions and provides the subscriber with 1557 an IPv6 address from the defined pool for that profile. The 1558 subscriber profile for authorization and authentication can be 1559 located on the BRAS or on a AAA server. The Hosts or the Customer 1560 Routers have the BRAS as their Layer 3 next hop. 1562 The PPP session can be initiated by a host or by a Customer Router. 1563 In the latter case, once the session is established with the BRAS and 1564 an address is negotiated for the uplink to the BRAS, DHCP-PD can be 1565 used to acquire prefixes for the Customer Router other interfaces. 1567 The BRAS has to be enabled to support DHCP-PD and to relay the 1568 DHCPv6 requests of the hosts on the subscriber sites. 1570 The BRAS has a /64 prefixes configured on the link to the Edge 1571 router. The Edge router links are also configured with /64 prefixes 1572 to provide connectivity to the rest of the ISP network. 1574 The prefixes used for subscriber and the ones delegated via DHCP-PD 1575 should be planned in a manner that allows maximum summarization at 1576 the BRAS. 1578 Other information of interest to the host, such as DNS, is provided 1579 through stateful [RFC3315] and stateless [RFC3736] DHCPv6. 1581 7.2.2.3 Routing 1583 The CPE devices are configured with a default route that points to 1584 the BRAS router. No routing protocols are needed on these devices 1585 which generally have limited resources. 1587 The BRAS runs an IGP to the Edge Router: OSPFv3 or IS-IS. Since the 1588 addresses assigned to the PPP sessions are represented as connected 1590 host routes, connected prefixes have to be redistributed. If DHCP-PD 1591 is used, with every delegated prefix a static route is installed by 1592 the Edge Router. For this reason the static routes must also be 1593 redistributed. Prefix summarization should be done at the BRAS. 1595 The Edge Router is running the IGP used in the ISP network: OSPFv3 1596 or IS-IS. 1598 A separation between the routing domains of the ISP and the Access 1599 Provider is recommended if they are managed independently. Controlled 1600 redistribution will be needed between the Access Provider IGP and the 1601 ISP IGP. 1603 7.2.3 L2TPv2 Access Aggregation (LAA) Model 1605 In the LAA model the BRAS forwards the CPE initiated session to 1606 the ISP over an L2TPv2 tunnel established between the BRAS and the 1607 Edge Router. In this case the authentication, authorization and 1608 subscriber configuration are performed by the ISP itself. There 1609 are two types of PPP encapsulations that can be leveraged with 1610 this model: 1612 A. Connection via PPPoA 1614 Customer Premises NAP NSP 1615 <--------------------> <----------------------> <-----------------> 1617 +-----------+ 1618 | AAA | 1619 +-------+ Radius | 1620 | | TACACS | 1621 | +-----+-----+ 1622 | | 1623 +-----+ +-------+ +--------+ +----+-----+ +-----+-----+ 1624 |Hosts|--+Router +------+ DSLAM +-+ BRAS +-+ Edge | 1625 +-----+ +-------+ +--------+ +----------+ | Router +=>Core 1626 +-----------+ 1627 <----------------------------------------> 1628 PPP 1629 <------------> 1630 L2TPv2 1631 Figure 7.2.3.1 1633 B. Connection via PPPoE 1635 Customer Premises NAP NSP 1636 <---------------------------> <--------------------> <-----------------> 1637 +-----------+ 1638 | AAA | 1639 +------+ Radius | 1640 | | TACACS | 1641 | +-----+-----+ 1642 | | 1643 +-----+ +-------+ +--------+ +----+-----+ +----+------+ 1644 |Hosts|--+Router +------------+ DSLAM +-+ BRAS +-+ Edge | C 1645 +-----+ +-------+ +--------+ +----------+ | Router +=>O 1646 | | R 1647 +-----------+ E 1648 <-----------------------------------------------> 1649 PPP 1650 <--------------> 1651 L2TPv2 1653 Figure 7.2.3.2 1655 The network design and operation of the PTA model is the same 1656 regardless of the PPP encapsulation type used. 1658 7.2.3.1 IPv6 Related Infrastructure Changes 1660 In this scenario the BRAS is forwarding the PPP sessions initiated 1661 by the subscriber over the L2TPv2 tunnel established to the LNS, the 1662 aggregation point in the ISP network. The L2TPv2 tunnel between the 1663 LAC and LNS could run over IPv6 or IPv4. These capabilities 1664 have to be supported on the BRAS. The following devices have to be 1665 upgraded to dual stack: Host, Customer Router and Edge Router. If 1666 the tunnel is set up over IPv6 then the BRAS must be upgraded to 1667 dual stack. 1669 7.2.3.2 Addressing 1671 The Edge router terminates the PPP sessions and provides the 1672 subscriber with an IPv6 address from the defined pool for that 1673 profile. The subscriber profile for authorization and authentication 1674 can be located on the Edge Router or on a AAA server. The Hosts or 1675 the Customer Routers have the Edge Router as their Layer 3 next hop. 1677 The PPP session can be initiated by a host or by a Customer Router. 1678 In the latter case, once the session is established with the Edge 1679 Router, DHCP-PD can be used to acquire prefixes for the Customer 1680 Router interfaces. The Edge Router has to be enabled to support 1681 DHCP-PD and to relay the DHCPv6 requests generated by the hosts on 1682 the subscriber sites. 1684 The BRAS has a /64 prefix configured on the link to the Edge router. 1685 The Edge router links are also configured with /64 prefixes to 1686 provide connectivity to the rest of the ISP network. Other 1687 information of interest to the host, such as DNS, is provided 1688 through stateful [RFC3315] and stateless [RFC3736] DHCPv6. 1690 It is important to note here a significant difference between this 1691 deployment for IPv6 versus IPv4. In the case of IPv4 the customer 1692 router or CPE can end up on any Edge Router (acting as LNS) where the 1693 assumption is that there are at least two of them for redundancy 1694 purposes. Once authenticated, the customer will be given an address 1695 from the IP pool of the ER (LNS) it connected to. This allows the ERs 1696 (LNSs) to aggregate the addresses handed out to the customers. In the 1697 case of IPv6, an important constraint that likely will be enforced is 1698 that the customer should keep its own address regardless of the ER 1699 (LNS) it connects to. This could significantly reduce the prefix 1700 aggregation capabilities of the ER (LNS). This is different than the 1701 current IPv4 deployment where addressing is dynamic in nature and the 1702 same user can get different addresses depending on the LNS it ends up 1703 connecting to. 1705 One possible solution is to ensure that a given BRAS will always 1706 connect to the same ER (LNS) unless that LNS is down. This means that 1707 customers from a given prefix range will always be connected to the 1708 same ER (primary if up or secondary if not). Each ER (LNS) can carry 1709 summary statements in their routing protocol configuration for the 1710 prefixes they are the primary ER (LNS) as well as for the ones for 1711 which they are the secondary. This way the prefixes will be 1712 summarized any time they become "active" on the ER (LNS). 1714 7.2.3.3 Routing 1716 The CPE devices are configured with a default route that points to 1717 the Edge router that terminates the PPP sessions. No routing 1718 protocols are needed on these devices which have generally limited 1719 resources. 1721 The BRAS runs an IPv6 IGP to the Edge Router: OSPFv3 or IS-IS. 1722 Different processes should be used if the NAP and the NSP are 1723 managed by different organizations. In this case, controlled 1724 redistribution should be enabled between the two domains. 1726 The Edge Router is running the IPv6 IGP used in the ISP network: 1727 OSPFv3 or IS-IS. 1729 7.2.4 Hybrid Model for IPv4 and IPv6 Service 1731 It was recommended throughout this section that the IPv6 service 1732 implementation should map the existent IPv4 one. This approach 1733 simplifies manageability and minimizes training needed for personnel 1734 operating the network. In certain circumstances such mapping is not 1735 feasible. This typically becomes the case when a Service Provider 1736 plans to expand its service offering with the new IPv6 deployed 1737 infrastructure. If this new service is not well supported in a 1738 network design such as the one used for IPv4 then a different design 1739 might be used for IPv6. 1741 An example of such circumstances is that of a provider using an LAA 1742 design for its IPv4 services. In this case all the PPP sessions are 1743 bundled and tunneled across the entire NAP infrastructure which is 1744 made of multiple BRAS routers, aggregation routers etc. The end point 1745 of these tunnels is the ISP Edge Router. If the provider decides to 1746 offer multicast services over such a design, it will face the problem 1747 of NAP resources being over utilized. The multicast traffic can be 1748 replicated only at the end of the tunnels by the Edge router and the 1749 copies for all the subscribers are carried over the entire NAP. 1751 A Modified Point-to-Point (as described in 7.2.4.2) or PTA model are 1752 more suitable to support multicast services because the packet 1753 replication can be done closer to the destination at the BRAS. Such 1754 topology saves NAP resources. 1756 In this sense IPv6 deployment can be viewed as an opportunity to 1757 build an infrastructure that might better support the expansion of 1758 services. In this case, an SP using the LAA design for its IPv4 1759 services might choose a modified Point-to-Point or PTA design for 1760 IPv6. 1762 7.2.4.1 IPv4 in LAA Model and IPv6 in PTA Model 1764 The coexistence of the two PPP based models, PTA and LAA, is 1765 relatively straight forward. The PPP sessions are terminated on 1766 different network devices for the IPv4 and IPv6 services. The PPP 1767 sessions for the existent IPv4 service deployed in an LAA model are 1768 terminated on the Edge Router. The PPP sessions for the new IPv6 1769 service deployed in a PTA model are terminated on the BRAS. 1771 The logical design for IPv6 and IPv4 in this hybrid model is 1772 presented in Figure 7.2.4.1. 1774 IPv6 <--------------------------> 1775 PPP +-----------+ 1776 | AAA | 1777 +-------+ Radius | 1778 | | TACACS | 1779 | +-----+-----+ 1780 | | 1781 +-----+ +-------+ +--------+ +----+-----+ +-----+-----+ 1782 |Hosts|--+Router +------+ DSLAM +-+ BRAS +-+ Edge | 1783 +-----+ +-------+ +--------+ +----------+ | Router +=>Core 1784 +-----------+ 1785 IPv4 <----------------------------------------> 1786 PPP 1787 <------------> 1788 L2TPv2 1789 Figure 7.2.4.1 1791 7.2.4.2 IPv4 in LAA Model and IPv6 in Modified Point-to-Point Model 1793 In this particular scenario the Point-to-Point model used for the 1794 IPv6 service is a modified version of the model described in section 1795 7.2.1. 1797 For the IPv4 service in LAA model, the VLANs are terminated on the 1798 BRAS and PPP sessions are terminated on the Edge Router (LNS). For 1799 IPv6 service in Point-to-Point model, the VLANs are terminated at 1800 the Edge Router as described in section 7.2.1. In this hybrid model, 1801 the Point-to-Point link could be terminated on the BRAS, a NAP owned 1802 device. The IPv6 traffic is then routed through the NAP network to 1803 the NSP. In order to have this hybrid model, the BRAS has to be 1804 upgraded to a dual-stack router. The functionalities of the Edge 1805 Router as described in section 7.2.1 are now implemented on the BRAS. 1807 The other aspect of this deployment model is the fact that the BRAS 1808 has to be capable of distinguishing between the IPv4 PPP traffic that 1809 has to be bridged across the L2TPv2 tunnel and the IPv6 packets that 1810 have to be routed to the NSP. The IPv6 Routing and Bridging 1811 Encapsulation (RBE) has to be enabled on all interfaces with VLANs 1812 supporting both IPv4 and IPv6 services in this hybrid design. 1814 The logical design for IPv6 and IPv4 in this hybrid model is 1815 presented in Figure 7.2.4.2. 1817 IPv6 <----------------> 1818 ATM +-----------+ 1819 | AAA | 1820 +-------+ Radius | 1821 | | TACACS | 1822 | +-----+-----+ 1823 | | 1824 +-----+ +-------+ +--------+ +----+-----+ +-----+-----+ 1825 |Hosts|--+Router +------+ DSLAM +-+ BRAS +-+ Edge | 1826 +-----+ +-------+ +--------+ +----------+ | Router +=>Core 1827 +-----------+ 1828 IPv4 <----------------------------------------> 1829 PPP 1830 <------------> 1831 L2TPv2 1832 Figure 7.2.4.2 1834 7.3 IPv6 Multicast 1836 The deployment of IPv6 multicast services relies on MLD, identical to 1837 IGMP in IPv4 and on PIM for routing. ASM (Any Source Multicast) and 1838 SSM (Single Source Multicast) service models operate almost the same 1839 as in IPv4. Both have the same benefits and disadvantages as in IPv4. 1840 Nevertheless, the larger address space and the scoped address 1841 architecture provide major benefits for multicast IPv6. Through 1842 RFC3306 the large address space provides the means to assign global 1843 multicast group addresses to organizations or users that were 1844 assigned unicast prefixes. It is a significant improvement with 1845 respect to the IPv4 GLOP mechanism [RFC2770]. 1847 This facilitates the deployment of multicast services. The 1848 discussion of this section applies to all the multicast sections 1849 in the document. 1851 7.3.1 ASM Based Deployments 1853 Any Source Multicast (ASM) is useful for Service Providers that 1854 intend to support the forwarding of multicast traffic of their 1855 customers. It is based on the PIM-SM protocol and it is more complex 1856 to manage because of the use of Rendezvous Points (RPs). With IPv6, 1857 static RP and BSR [BSR] can be used for RP-to-group mapping similar 1858 to IPv4. Additionally, the larger IPv6 address space allows for 1859 building up of group addresses that incorporate the address of the 1860 RP. This RP-to-group mapping mechanism is called Embedded RP and is 1861 specific to IPv6. 1863 In inter-domain deployments, Multicast Source Discovery Protocol 1864 (MSDP) [RFC3618] is an important element of IPv4 PIM-SM deployments. 1865 MSDP is meant to be a solution for the exchange of source 1866 registration information between RPs in different domains. This 1867 solution was intended to be temporary. This is one of the reasons 1868 why it was decided not to implement MSDP in IPv6 [IPv6 Multicast]. 1870 For multicast reachability across domains, Embedded RP could be 1871 used. Despite its shortcomings, MSDP provides additional 1872 flexibility in managing the domains that may not be matched with 1873 the protocols available in IPv6 today. The value of such 1874 flexibility is still under evaluation. 1876 7.3.2 SSM Based Deployments 1878 Based on PIM-SSM, the Source Specific Multicast deployments do not 1879 need an RP and the related protocols (such as BSR or MSDP) but rely 1880 on the listeners to know the source of the multicast traffic 1881 they plan to receive. The lack of RP makes SSM not only simpler to 1882 operate but also robust, it is not impacted by RP failures or inter 1883 domain constraints. It is also has a higher level of security (No RP 1884 to be targeted by attacks). For more discussions on the topic of 1885 IPv6 multicast see [IPv6 Multicast]. 1887 The typical multicast services offered for residential and very 1888 small businesses is video/audio streaming where the subscriber joins 1889 a multicast group and receives the content. This type of service 1890 model is well supported through PIM-SSM which is very simple and 1891 easy to manage. PIM-SSM has to be enabled throughout the SP network. 1892 MLDv2 is required for PIM-SSM support. Vendors can choose to 1893 implement features that allow routers to map MLDv1 group joins to 1894 predefined sources. 1896 Subscribers might use a set-top box that is responsible for the 1897 control piece of the multicast service (does group joins/leaves). 1898 The subscriber hosts can also join desired multicast groups as long 1899 as they are enabled to support MLDv1 or MLDv2. If a customer premise 1900 router is used then it has to be enabled to support MLDv1 and MLDv2 1901 in order to process the requests of the hosts. It has to be enabled 1902 to support PIM-SSM in order to send PIM joins/leaves up to its 1903 Layer 3 next hop whether it is the BRAS or the Edge router. When 1904 enabling this functionality on a customer premises router, its 1905 limited resources should be taken into consideration. Another option 1906 would be for the customer premises router to support MLD proxy 1907 routing. 1909 The router that is the Layer 3 next hop for the subscriber (BRAS in 1910 the PTA model or the Edge router in the LAA and Point-to-Point 1911 model) has to be enabled to support MLDv1 and MLDv2 in order to 1912 process the requests coming from subscribers without customer 1913 premises routers. It has to be enabled for PIM-SSM in order to 1914 receive joins/leaves from customer routers and send joins/leaves 1915 to the next hop towards the multicast source (Edge router or the 1916 NSP core). 1918 MLD authentication, authorization and accounting is usually 1919 configured on the edge router in order to enable the ISP to do 1920 control the subscriber access of the service and do billing for the 1921 content provided. Alternative mechanisms that would support these 1922 functions should be investigated further. 1924 7.4 IPv6 QoS 1926 The QoS configuration is particularly relevant on the router that 1927 represents the Layer 3 next hop for the subscriber (BRAS in the PTA 1928 model or the Edge router in the LAA and Point-to-Point model) in 1929 order to manage resources shared amongst multiple subscribers 1930 possibly with various service level agreements. 1932 In the DSL infrastructure it is expected that there is already a 1933 level of traffic policing and shaping implemented for IPv4 1934 connectivity. This is implemented throughout the NAP and it is 1935 beyond the scope of this document. 1937 On the BRAS or the Edge Router the subscriber facing interfaces have 1938 to be configure to police the inbound customer traffic and shape the 1939 traffic outbound to the customer based on the SLAs. Traffic 1940 classification and marking should also be done on the router closest 1941 (at Layer 3) to the subscriber in order to support the various types 1942 of customer traffic: data, voice, video and to optimally use the 1943 infrastructure resources. Each provider (NAP, NSP) could implement 1944 their own QoS policies and services so reclassification and marking 1945 might be performed at the boundary between the NAP and the NSP in 1946 order to make sure the traffic is properly handled by the ISP. The 1947 same IPv4 QoS concepts and methodologies should be applied with IPv6 1948 as well. 1950 It is important to note that when traffic is encrypted end-to-end, 1951 the traversed network devices will not have access to many of the 1952 packet fields used for classification purposes. In these cases 1953 routers will most likely place the packets in the default classes. 1954 The QoS design should take into consideration this scenario and try 1955 to use mainly IP header fields for classification purposes. 1957 7.5 IPv6 Security Considerations 1959 There are limited changes that have to be done for CPEs in order to 1960 enhance security. The Privacy extensions for auto-configuration 1961 [RFC3041] should be used by the hosts. ISPs can track the prefixes 1962 it assigns to subscribers relatively easily. If however the ISPs are 1963 required by regulations to track their users at /128 address level, 1964 the Privacy Extensions can be implemented only in parallel with 1965 network management tools that could provide traceability of the 1966 hosts. IPv6 firewall functions should be enabled on the hosts or 1967 customer premises router if present. 1969 The ISP provides security against attacks that come form its own 1970 subscribers but it could also implement security services that 1971 protect its subscribers from attacks sourced from the outside of its 1972 network. Such services do not apply at the access level of the 1973 network discussed here. 1975 The device that is the Layer 3 next hop for the subscribers (BRAS or 1976 Edge router) should protect the network and the other subscribers 1977 against attacks by one of the provider customers. For this reason 1978 uRPF and ACLs should be used on all interfaces facing subscribers. 1979 Filtering should be implemented with regard for the operational 1980 requirements of IPv6 [Security considerations for IPv6]. 1981 Authentication and authorization should be used wherever possible. 1983 The BRAS and the Edge Router should protect their processing 1984 resources against floods of valid customer control traffic such as: 1985 Router and Neighbor Solicitations, MLD Requests. Rate limiting 1986 should be implemented on all subscriber facing interfaces. The 1987 emphasis should be placed on multicast type traffic as it is most 1988 often used by the IPv6 control plane. 1990 All other security features used with the IPv4 service should be 1991 similarly applied to IPv6 as well. 1993 7.6 IPv6 Network management 1995 The necessary instrumentation (such as MIBs, NetFlow Records etc) 1996 should be available for IPv6. 1998 Usually, NSPs manage the edge routers by SNMP. The SNMP transport 1999 can be done over IPv4 if all managed devices have connectivity over 2000 both IPv4 and IPv6. This would imply the smallest changes to the 2001 existent network management practices and processes. Transport over 2002 IPv6 could also be implemented and it might become necessary if IPv6 2003 only islands are present in the network. The management stations are 2004 located on the core network. Network Management Applications should 2005 handle IPv6 in a similar fashion to IPv4, however, they should also 2006 support features specific to IPv6 (such as Neighbor monitoring). 2008 In some cases service providers manage equipment located on 2009 customers LANs. The management of equipment at customers' LANs is 2010 out of scope of this memo. 2012 8. Broadband Ethernet Networks 2014 This section describes the IPv6 deployment options in currently 2015 deployed Broadband Ethernet Access Networks. 2017 8.1 Ethernet Access Network Elements 2019 In environments that support the infrastructure deploying RJ-45 or 2020 fiber (Fiber to the Home (FTTH) service) to subscribers, 10/100 2021 Mbps Ethernet broadband services can be provided. Such services are 2022 generally available in metropolitan areas, in multi tenant buildings 2023 where an Ethernet infrastructure can be deployed in a cost effective 2024 manner. In such environments Metro-Ethernet services can be used to 2025 provide aggregation and uplink to a Service Provider. 2027 The following network elements are typical of an Ethernet network: 2029 Access Switch: It is used as a Layer 2 access device for subscribers. 2031 Customer Premises Router: It is used to provide Layer 3 services 2032 for customer premises networks. 2034 Aggregation Ethernet Switches: Aggregates multiple subscribers. 2036 Broadband Remote Access Server (BRAS) 2038 Edge Router (ER) 2040 Figure 8.1 depicts all the network elements mentioned. 2042 Customer Premises | Network Access Provider | Network Service Provider 2043 CP NAP NSP 2045 +-----+ +------+ +------+ +--------+ 2046 |Hosts|--|Router| +-+ BRAS +---+ Edge | ISP 2047 +-----+ +--+---+ | | | | Router +===> Network 2048 | | +------+ +--------+ 2049 +--+-----+ | 2050 |Access +-+ | 2051 |Switch | | | 2052 +--------+ | +------+ | 2053 +--+Agg E | | 2054 +--------+ |Switch+-+ 2055 +-----+ |Access | +--+ | 2056 |Hosts|--+Switch +-+ +------+ 2057 +-----+ +--------+ 2058 Figure 8.1 2060 The logical topology and design of Broadband Ethernet Networks is 2061 very similar to DSL Broadband Networks discussed in section 7. 2063 It is worth noting that the general operation, concepts and 2064 recommendations described in this section apply similarly to a 2065 HomePNA based network environment. In such an environment some 2066 of the network elements might be differently named. 2068 8.2 Deploying IPv6 in IPv4 Broadband Ethernet Networks 2070 There are three main design approaches to providing IPv4 2071 connectivity over an Ethernet infrastructure: 2073 A. Point-to-Point Model: Each subscriber connects to the network 2074 Access switch over RJ-45 or fiber links. Each subscriber is assigned 2075 a unique VLAN on the access switch. The VLAN can be terminated at 2076 the BRAS or at the Edge Router. The VLANs are 802.1q trunked to the 2077 Layer 3 device (BRAS or Edge Router). 2079 This model is presented in section 8.2.1. 2081 B. PPP Terminated Aggregation (PTA) Model: PPP sessions are opened 2082 between each subscriber and the BRAS. The BRAS terminates the PPP 2083 sessions and provides Layer 3 connectivity between the subscriber 2084 and the ISP. 2086 This model is presented in section 8.2.2. 2088 C. L2TPv2 Access Aggregation (LAA) Model: PPP sessions are opened 2089 between each subscriber and the ISP termination devices. The BRAS 2090 tunnels the subscriber PPP sessions to the ISP by encapsulating them 2091 into L2TPv2 tunnels. 2093 This model is presented in section 8.2.3. 2095 In aggregation models the BRAS terminates the subscriber VLANs and 2096 aggregates their connections before providing access to the ISP. 2098 In order to maintain the deployment concepts and business models 2099 proven and used with existent revenue generating IPv4 services, the 2100 IPv6 deployment will match the IPv4 one. This approach is presented 2101 in sections 8.2.1-3 that describes currently deployed IPv4 over 2102 Ethernet broadband access deployments. Under certain circumstances 2103 where new service types or service needs justify it, IPv4 and IPv6 2104 network architectures could be different as described in section 2105 8.2.4. 2107 8.2.1 Point-to-Point Model 2109 In this scenario the Ethernet frames from the Host or the Customer 2110 Premises Router are bridged over the VLAN assigned to the subscriber. 2112 Figure 8.2.1 describes the protocol architecture of this model. 2114 Customer Premises NAP NSP 2115 <-------------------------> <---------------> <--------------------> 2117 +-----+ +------+ +------+ +--------+ +----------+ 2118 |Hosts|--+Router+--+Access+--+ Switch +--------+ Edge | ISP 2119 +-----+ +------+ |Switch| +--------+ 802.1q | Router +==> Network 2120 +------+ +----------+ 2122 <----------------------------> 2123 Ethernet/VLANs 2125 Figure 8.2.1 2127 8.2.1.1 IPv6 Related Infrastructure Changes 2129 In this scenario the Access Switch on the customer site and the 2130 entire NAP is Layer 3 unaware so no changes are needed to support 2131 IPv6. The following devices have to be upgraded to dual stack: Host, 2132 Customer Router and Edge Router. 2134 The Access switches might need upgrades to support certain IPv6 2135 related features such as MLD Snooping. 2137 8.2.1.2 Addressing 2139 The Hosts or the Customer Routers have the Edge Router as their 2140 Layer 3 next hop. If there is no Customer Router all the hosts on 2142 the subscriber site belong to the same /64 subnet that is 2143 statically configured on the Edge Router for that subscriber VLAN. 2144 The hosts can use stateless autoconfiguration or stateful DHCPv6 2145 based configuration to acquire an address via the Edge Router. 2147 If a Customer Router is present: 2149 A. It is statically configured with an address on the /64 subnet 2150 between itself and the Edge Router, and with /64 prefixes on the 2151 interfaces connecting the hosts on the customer site. This is not 2152 a desired provisioning method being expensive and difficult to 2153 manage. 2155 B. It can use its link-local address to communicate with the ER. 2156 It can also dynamically acquire through stateless autoconfiguration 2157 the address for the link between itself and the ER. This step is 2158 followed by a request via DHCP-PD for a prefix shorter than /64 that 2159 in turn is divided in /64s and assigned to its interfaces connecting 2160 the hosts on the customer site. 2162 The Edge Router has a /64 prefix configured for each subscriber VLAN. 2163 Each VLAN should be enabled to relay DHCPv6 requests from the 2164 subscribers to DHCPv6 servers in the ISP network. The VLANs 2165 providing access for subscribers that use DHCP-PD as well, have to 2166 be enabled to support the feature. Currently the DHCP-PD 2167 functionality cannot be implemented if the DHCP-PD server is not the 2168 Edge Router. If the DHCP-PD messages are relayed, the Edge Router 2169 does not have a mechanism to learn the assigned prefixes and thus 2170 install the proper routes to make that prefix reachable. Work is 2171 being done to address this issue, one idea being to provide the Edge 2172 Router with a snooping mechanism. The uplink to the ISP network is 2173 configured with a /64 prefix as well. The uplink to the ISP network 2174 is configured with a /64 prefix as well. 2176 The prefixes used for subscriber links and the ones delegated via 2177 DHCP-PD should be planned in a manner that allows as much 2178 summarization as possible at the Edge Router. 2180 Other information of interest to the host, such as DNS, is provided 2181 through stateful [RFC3315] and stateless [RFC3736] DHCPv6. 2183 8.2.1.3 Routing 2185 The CPE devices are configured with a default route that points to 2186 the Edge router. No routing protocols are needed on these devices 2187 which generally have limited resources. 2189 The Edge Router runs the IPv6 IGP used in the NSP: OSPFv3 or IS-IS. 2190 The connected prefixes have to be redistributed. If DHCP-PD is used, 2191 with every delegated prefix a static route is installed by the Edge 2192 Router. For this reason the static routes must also be redistributed. 2193 Prefix summarization should be done at the Edge Router. 2195 8.2.2 PPP Terminated Aggregation (PTA) Model 2197 The PTA architecture relies on PPP-based protocols (PPPoE). The PPP 2198 sessions are initiated by Customer Premise Equipment and it is 2199 terminated at the BRAS. The BRAS authorizes the session, 2200 authenticates the subscriber, and provides an IP address on behalf 2201 of the ISP. The BRAS then does Layer 3 routing of the subscriber 2202 traffic to the NSP Edge Router. This model is often used when the 2203 NSP is also the NAP. The PPPoE logical diagram in an Ethernet 2204 Broadband Network is shown in Fig 8.2.2.1. 2206 Customer Premises NAP NSP 2207 <---------------------------> <-----------------> <-----------------> 2208 +-----------+ 2209 | AAA | 2210 +-------+ Radius | 2211 | | TACACS | 2212 | +-----------+ 2213 +-----+ +-------+ +--------+ +--------+ +----+-----+ +-----------+ 2214 |Hosts|--+Router +-+A Switch+-+ Switch +-+ BRAS +-+ Edge | C 2215 +-----+ +-------+ +--------+ +--------+ +----------+ | Router +=>O 2216 <---------------- PPP ----------------> | | R 2217 +-----------+ E 2218 Figure 8.2.2.1 2220 The PPP sessions are initiated by the Customer Premise Equipment 2221 (Host or Router). The BRAS authenticates the subscriber against a 2222 local or a remote database. Once the session is established, the 2223 BRAS provides an address and maybe a DNS server to the user, 2224 information acquired from the subscriber profile or from a DHCP 2225 server. 2227 This model allows for multiple PPPoE session to be supported over 2228 the same VLAN thus allowing the subscriber to connect to multiple 2229 services at the same time. The hosts can initiate the PPPoE sessions 2230 as well. It is important to remember that the PPPoE encapsulation 2231 reduces the IP MTU available for the customer traffic. 2233 8.2.2.1 IPv6 Related Infrastructure Changes 2235 In this scenario the BRAS is Layer 3 aware and it has to be upgraded 2236 to support IPv6. Since the BRAS terminates the PPP sessions it has to 2237 support PPPoE with IPv6. The following devices have to be upgraded to 2238 dual stack: Host, Customer Router (if present), BRAS and Edge Router. 2240 8.2.2.2 Addressing 2242 The BRAS terminates the PPP sessions and provides the subscriber with 2243 an IPv6 address from the defined pool for that profile. The 2244 subscriber profile for authorization and authentication can be 2245 located on the BRAS or on a AAA server. The Hosts or the Customer 2246 Routers have the BRAS as their Layer 3 next hop. 2248 The PPP session can be initiated by a host or by a Customer Router. 2249 In the latter case, once the session is established with the BRAS, 2250 DHCP-PD can be used to acquire prefixes for the Customer Router 2251 interfaces. The BRAS has to be enabled to support DHCP-PD and to 2252 relay the DHCPv6 requests of the hosts on the subscriber sites. 2253 Currently the DHCP-PD functionality cannot be implemented if the 2254 DHCP-PD server is not the Edge Router. If the DHCP-PD messages are 2255 relayed, the Edge Router does not have a mechanism to learn the 2256 assigned prefixes and thus install the proper routes to make that 2257 prefix reachable. Work is being done to address this issue, one idea 2258 being to provide the Edge Router with a snooping mechanism. The 2259 uplink to the ISP network is configured with a /64 prefix as well. 2261 The BRAS has a /64 prefix configured on the link facing the Edge 2262 router. The Edge router links are also configured with /64 prefixes 2263 to provide connectivity to the rest of the ISP network. 2265 The prefixes used for subscriber and the ones delegated via DHCP-PD 2266 should be planned in a manner that allows maximum summarization at 2267 the BRAS. 2269 Other information of interest to the host, such as DNS, is provided 2270 through stateful [RFC3315] and stateless [RFC3736] DHCPv6. 2272 8.2.2.3 Routing 2274 The CPE devices are configured with a default route that points to 2275 the BRAS router. No routing protocols are needed on these devices 2276 which generally have limited resources. 2278 The BRAS runs an IGP to the Edge Router: OSPFv3 or IS-IS. Since the 2279 addresses assigned to the PPP sessions are represented as connected 2280 host routes, connected prefixes have to be redistributed. If DHCP-PD 2281 is used, with every delegated prefix a static route is installed by 2282 the BRAS. For this reason the static routes must also be 2283 redistributed. Prefix summarization should be done at the BRAS. 2285 The Edge Router is running the IGP used in the ISP network: OSPFv3 2286 or IS-IS. A separation between the routing domains of the ISP and 2287 the Access Provider is recommended if they are managed independently. 2288 Controlled redistribution will be needed between the Access Provider 2289 IGP and the ISP IGP. 2291 8.2.3 L2TPv2 Access Aggregation (LAA) Model 2293 In the LAA model the BRAS forwards the CPE initiated session to the 2294 ISP over an L2TPv2 tunnel established between the BRAS and the Edge 2295 Router. In this case the authentication, authorization and subscriber 2296 configuration are performed by the ISP itself. 2298 Customer Premises NAP NSP 2299 <--------------------> <----------------------> <-----------------> 2301 +-----------+ 2302 | AAA | 2303 +------+ Radius | 2304 | | TACACS | 2305 | +-----+-----+ 2306 | | 2307 +-----+ +-------+ +--------+ +--------+ +----+-----+ +-----------+ 2308 |Hosts|--+Router +-+A Switch+-+ Switch +-+ BRAS +-+ Edge | C 2309 +-----+ +-------+ +--------+ +--------+ +----------+ | Router +=>O 2310 | | R 2311 +-----------+ E 2312 <-----------------------------------------------> 2313 PPP 2314 <--------------> 2315 L2TPv2 2317 Figure 8.2.3.1 2319 8.2.3.1 IPv6 Related Infrastructure Changes 2321 In this scenario the BRAS is Layer 3 aware and it has to be upgraded 2322 to support IPv6. The PPP sessions initiated by the subscriber are 2323 forwarded over the L2TPv2 tunnel to the aggregation point in the ISP 2324 network. The BRAS (LAC) can aggregate IPv6 PPP sessions and tunnel 2325 them to the LNS using L2TPv2. The L2TPv2 tunnel between the LAC and 2326 LNS could run over IPv6 or IPv4. These capabilities have to be 2327 supported on the BRAS. The following devices have to be upgraded to 2328 dual stack: Host, Customer Router (if present), BRAS and Edge Router. 2330 8.2.3.2 Addressing 2332 The Edge router terminates the PPP sessions and provides the 2333 subscriber with an IPv6 address from the defined pool for that 2334 profile. The subscriber profile for authorization and authentication 2335 can be located on the Edge Router or on a AAA server. The Hosts or 2336 the Customer Routers have the Edge Router as their Layer 3 next hop. 2338 The PPP session can be initiated by a host or by a Customer Router. 2339 In the latter case, once the session is established with the Edge 2340 Router and an IPv6 address is assigned to the Customer Router by the 2341 Edge router, DHCP-PD can be used to acquire prefixes for the Customer 2342 Router other interfaces. The Edge Router has to be enabled to support 2343 DHCP-PD and to relay the DHCPv6 requests of the hosts on the 2344 subscriber sites. Currently the DHCP-PD functionality cannot be 2345 implemented if the DHCP-PD server is not the Edge Router. If the 2346 DHCP-PD messages are relayed, the Edge Router does not have a 2347 mechanism to learn the assigned prefixes and thus install the proper 2348 routes to make that prefix reachable. Work is being done to address 2349 this issue, one idea being to provide the Edge Router with a snooping 2350 mechanism. The uplink to the ISP network is configured with a /64 2351 prefix as well. 2353 The BRAS has a /64 prefix configured on the link to the Edge router. 2354 The Edge router links are also configured with /64 prefixes to 2355 provide connectivity to the rest of the ISP network. 2357 Other information of interest to the host, such as DNS, is provided 2358 through stateful [RFC3315] and stateless [RFC3736] DHCPv6. 2360 The address assignment and prefix summarization issues discussed in 2361 section 7.2.3.2 are relevant in the same way for this media access 2362 type as well. 2364 8.2.3.3 Routing 2366 The CPE devices are configured with a default route that points to 2367 the Edge router that terminates the PPP sessions. No routing 2368 protocols are needed on these devices which have limited 2369 resources. 2371 The BRAS runs an IPv6 IGP to the Edge Router: OSPFv3 or IS-IS. 2372 Different processes should be used if the NAP and the NSP are 2373 managed by different organizations. In this case controlled 2374 redistribution should be enabled between the two domains. 2376 The Edge Router is running the IPv6 IGP used in the ISP network: 2377 OSPFv3 or IS-IS. 2379 8.2.4 Hybrid Model for IPv4 and IPv6 Service 2381 It was recommended throughout this section that the IPv6 service 2382 implementation should map the existent IPv4 one. This approach 2383 simplifies manageability and minimizes training needed for personnel 2384 operating the network. In certain circumstances such mapping is not 2385 feasible. This typically becomes the case when a Service Provider 2386 plans to expand its service offering with the new IPv6 deployed 2387 infrastructure. If this new service is not well supported in a 2388 network design such as the one used for IPv4 then a different design 2389 might be used for IPv6. 2391 An example of such circumstances is that of a provider using an LAA 2392 design for its IPv4 services. In this case all the PPP sessions are 2393 bundled and tunneled across the entire NAP infrastructure which is 2394 made of multiple BRAS routers, aggregation routers etc. The end point 2395 of these tunnels is the ISP Edge Router. If the SP decides to offer 2396 multicast services over such a design, it will face the problem of 2397 NAP resources being over utilized. The multicast traffic can be 2398 replicated only at the end of the tunnels by the Edge router and the 2399 copies for all the subscribers are carried over the entire NAP. 2401 A Modified Point-to-Point (see section 8.2.4.2) or a PTA model is 2402 more suitable to support multicast services because the packet 2403 replication can be done closer to the destination at the BRAS. 2404 Such topology saves NAP resources. 2406 In this sense IPv6 deployments can be viewed as an opportunity to 2407 build an infrastructure that can better support the expansion of 2408 services. In this case, an SP using the LAA design for its IPv4 2409 services might choose a modified Point-to-Point or PTA design for 2410 IPv6. 2412 8.2.4.1 IPv4 in LAA Model and IPv6 in PTA Model 2414 The coexistence of the two PPP based models, PTA and LAA, is 2415 relatively straight forward. It is a straight forward overlap of the 2416 two deployment models. The PPP sessions are terminated on 2417 different network devices for the IPv4 and IPv6 services. The PPP 2418 sessions for the existent IPv4 service deployed in an LAA model are 2419 terminated on the Edge Router. The PPP sessions for the new IPv6 2420 service deployed in a PTA model are terminated on the BRAS. 2422 The logical design for IPv6 and IPv4 in this hybrid model is 2423 presented in Figure 8.2.4.1. 2425 IPv6 <--------------------------> 2426 PPP +-----------+ 2427 | AAA | 2428 +-------+ Radius | 2429 | | TACACS | 2430 | +-----+-----+ 2431 | | 2432 +-----+ +-------+ +--------+ +----+-----+ +-----+-----+ 2433 |Hosts|--+Router +------+ Switch +-+ BRAS +-+ Edge | 2434 +-----+ +-------+ +--------+ +----------+ | Router +=>Core 2435 +-----------+ 2437 IPv4 <----------------------------------------> 2438 PPP 2439 <------------> 2440 L2TPv2 2441 Figure 8.2.4.1 2443 8.2.4.2 IPv4 in LAA Model and IPv6 in Modified Point-to-Point Model 2445 The coexistence of the modified Point-to-Point and the LAA models 2446 implies a few specific changes. 2448 For the IPv4 service in LAA model, the VLANs are terminated on the 2449 BRAS and PPP sessions are terminated on the Edge Router (LNS). For 2450 IPv6 service in Point-to-Point model, the VLANs are terminated at 2451 the Edge Router as described in section 7.2.1. In this hybrid model, 2452 the Point-to-Point link could be terminated on the BRAS, a NAP owned 2453 device. The IPv6 traffic is then routed through the NAP network to 2454 the NSP. In order to have this hybrid model, the BRAS has to be 2455 upgraded to a dual-stack router. The functionalities of the Edge 2456 Router as described in section 7.2.1 are now implemented on the BRAS. 2458 The logical design for IPv6 and IPv4 in this hybrid model is 2459 in Figure 8.2.4.2. 2461 IPv6 <----------------> 2462 Ethernet 2463 +-----------+ 2464 | AAA | 2465 +-------+ Radius | 2466 | | TACACS | 2467 | +-----+-----+ 2468 | | 2469 +-----+ +-------+ +--------+ +----+-----+ +-----+-----+ 2470 |Hosts|--+Router +------+ Switch +-+ BRAS +-+ Edge | 2471 +-----+ +-------+ +--------+ +----------+ | Router +=>Core 2472 +-----------+ 2473 IPv4 <----------------------------------------> 2474 PPP 2475 <------------> 2476 L2TPv2 2478 Figure 8.2.4.2 2480 8.3 IPv6 Multicast 2482 The typical multicast services offered for residential and very small 2483 businesses is video/audio streaming where the subscriber joins a 2484 multicast group and receives the content. This type of service model 2485 is well supported through PIM-SSM which is very simple and easy to 2486 manage. PIM-SSM has to be enabled throughout the ISP network. MLDv2 2487 is required for PIM-SSM support. Vendors can choose to implement 2488 features that allow routers to map MLDv1 group joins to predefined 2489 sources. 2491 Subscribers might use a set-top box that is responsible for the 2492 control piece of the multicast service (does group joins/leaves). 2493 The subscriber hosts can also join desired multicast groups as 2494 long as they are enabled to support MLDv1 or MLDv2. If a customer 2495 premise router is used then it has to be enabled to support MLDv1 2496 and MLDv2 in order to process the requests of the hosts. It has to 2497 be enabled to support PIM-SSM in order to send PIM joins/leaves up 2498 to its Layer 3 next hop whether it is the BRAS or the Edge router. 2499 When enabling this functionality on a customer premises router, 2500 its limited resources should be taken into consideration. Another 2501 option would be for the customer premises router to support MLD 2502 proxy routing. MLD snooping or similar layer two multicast related 2503 protocols could be enabled on the NAP switches. 2505 The router that is the Layer 3 next hop for the subscriber (BRAS in 2506 the PTA model or the Edge router in the LAA and Point-to-Point model) 2507 has to be enabled to support MLDv1 and MLDv2 in order to process the 2508 requests coming from subscribers without customer premises routers. 2509 It has to be enabled for PIM-SSM in order to receive joins/leaves 2510 from customer routers and send joins/leaves to the next hop towards 2511 the multicast source (Edge router or the NSP core). 2513 MLD authentication, authorization and accounting is usually 2514 configured on the edge router in order to enable the ISP to do 2515 control the subscriber access of the service and do billing for the 2516 content provided. Alternative mechanisms that would support these 2517 functions should be investigated further. 2519 Please refer to section 7.3 for more IPv6 multicast details. 2521 8.4 IPv6 QoS 2523 The QoS configuration is particularly relevant on the router that 2524 represents the Layer 3 next hop for the subscriber (BRAS in the PTA 2525 model or the Edge router in the LAA and Point-to-Point model) in 2526 order to manage resources shared amongst multiple subscribers 2527 possibly with various service level agreements. 2529 On the BRAS or the Edge Router the subscriber facing interfaces have 2530 to be configured to police the inbound customer traffic and shape the 2531 traffic outbound to the customer based on the SLAs. Traffic 2532 classification and marking should also be done on the router closest 2533 (at Layer 3) to the subscriber in order to support the various types 2534 of customer traffic: data, voice, video and to optimally use the 2535 network resources. This infrastructure offers a very good opportunity 2536 to leverage the QoS capabilities of Layer two devices. DiffServ based 2537 QoS used for IPv4 should be expanded to IPv6. 2539 Each provider (NAP, NSP) could implement their own QoS policies and 2540 services so reclassification and marking might be performed at the 2541 boundary between the NAP and the NSP in order to make sure the 2542 traffic is properly handled by the ISP. The same IPv4 QoS concepts 2543 and methodologies should be applied for the IPv6 as well. 2545 It is important to note that when traffic is encrypted end-to-end, 2546 the traversed network devices will not have access to many of the 2547 packet fields used for classification purposes. In these cases 2548 routers will most likely place the packets in the default classes. 2549 The QoS design should take into consideration this scenario and try 2550 to use mainly IP header fields for classification purposes. 2552 8.5 IPv6 Security Considerations 2554 There are limited changes that have to be done for CPEs in order to 2555 enhance security. The Privacy extensions [RFC3041] for 2556 autoconfiguration should be used by the hosts with the same 2557 considerations for host traceability as discussed in section 7.5. 2558 IPv6 firewall functions should be enabled on the hosts or customer 2559 premises router if present. 2561 The ISP provides security against attacks that come form its own 2562 subscribers but it could also implement security services that 2563 protect its subscribers from attacks sourced from the outside of its 2564 network. Such services do not apply at the access level of the 2566 network discussed here. 2568 If any layer two filters for Ethertypes are in place, the NAP must 2569 permit the IPv6 Ethertype (0X86DD). 2571 The device that is the Layer 3 next hop for the subscribers (BRAS 2572 Edge router) should protect the network and the other subscribers 2573 against attacks by one of the provider customers. For this reason 2574 uRPF and ACLs should be used on all interfaces facing subscribers. 2575 Filtering should be implemented with regard for the operational 2576 requirements of IPv6 [Security considerations for IPv6]. 2577 Authentication and authorization should be used wherever possible. 2579 The BRAS and the Edge Router should protect their processing 2580 resources against floods of valid customer control traffic such as: 2581 Router and Neighbor Solicitations, MLD Requests. Rate limiting 2582 should be implemented on all subscriber facing interfaces. The 2583 emphasis should be placed on multicast type traffic as it is most 2584 often used by the IPv6 control plane. 2586 All other security features used with the IPv4 service should be 2587 similarly applied to IPv6 as well. 2589 8.6 IPv6 Network Management 2591 The necessary instrumentation (such as MIBs, NetFlow Records etc) 2592 should be available for IPv6. 2594 Usually, NSPs manage the edge routers by SNMP. The SNMP transport can 2595 be done over IPv4 if all managed devices have connectivity over both 2596 IPv4 and IPv6. This would imply the smallest changes to the existent 2597 network management practices and processes. Transport over IPv6 could 2598 also be implemented and it might become necessary if IPv6 only 2599 islands are present in the network. The management stations are 2600 located on the core network. Network Management Applications should 2601 handle IPv6 in a similar fashion to IPv4 however they should also 2602 support features specific to IPv6 such as Neighbor monitoring. 2604 In some cases service providers manage equipment located on customers 2605 LANs. 2607 9. Wireless LAN 2609 This section provides detailed description of IPv6 deployment and 2610 integration methods in currently deployed wireless LAN (WLAN) 2611 infrastructure. 2613 9.1 WLAN Deployment Scenarios 2615 WLAN enables subscribers to connect to the Internet from various 2616 locations without the restriction of staying indoors. WLAN is 2617 standardized by IEEE 802.11a/b/g. Consideration should be also given 2618 to IEEE 802.16 WiMAX for similar deployment approaches. IEEE 802.11 2619 offers maximum transmission speed from 1 or 2 Mbps, IEEE 802.11b 2620 offers 11 Mbps and IEEE 802.11a offers up to 54 Mbps. 2622 Figure 9.1 describes the current WLAN architecture. 2624 Customer Premises| Access Provider |Service Provider 2625 | | 2627 +------+ +--+ +--------------+ +----------+ +------+ 2628 |WLAN | ---- | | |Access Router/| |Underlying| |Edge | 2629 |Host/ |-(WLAN)-|AP|-|Layer 2 Switch|-|Technology|-|Router|=>SP 2630 |Router| ---- | | | | | | | | Network 2631 +------+ +--+ +--------------+ +----------+ +------+ 2632 | 2633 +------+ 2634 |AAA | 2635 |Server| 2636 Figure 9.1 +------+ 2638 The host should have a wireless network interface card (NIC) in order 2639 to connect to a WLAN network. WLAN is a flat broadcast network and 2640 works in a similar fashion as Ethernet. When hosts initiate a 2641 connection, it is authenticated by the AAA server located at the 2642 SP network. All the authentication parameters (username, password 2643 and etc.) are forwarded by the Access Point (AP) to the AAA server. 2644 The AAA server authenticates the host, once authenticated 2645 successfully the host can send data packets. The AP is located near 2646 the host and acts as a bridge. The AP forwards all the packets 2647 coming to/from host to the Edge Router. The underlying connection 2648 between the AP and Edge Router could be based on any access layer 2649 technology such as HFC/Cable, FTTH, xDSL or etc. 2651 WLANs are based in limited areas known as WiFi Hot Spots. While users 2652 are present in the area covered by the WLAN range, they can be 2653 connected to the Internet given they have a wireless NIC and required 2654 configuration settings in their devices (notebook PCs, PDA or etc.). 2655 Once the user initiates the connection the IP address is assigned by 2656 the SP using DHCPv4. In most of the cases SP assigns limited 2657 number of public IP addresses to the its customer. When the user 2658 disconnects the connection and move to a new WiFi hot spot, the above 2659 mentioned process of authentication, address assignment and accessing 2660 the Internet is repeated. 2662 There are IPv4 deployments where customers can use WLAN routers to 2663 connect over wireless to their service provider. These deployment 2664 types do not fit in the typical Hot Spot concept but they rather 2665 serve fixed customers. For this reason this section discusses the 2666 WLAN router options as well. In this case, the ISP provides a public 2667 IP address and the WLAN Router assigns private addresses [RFC1918] 2668 to all WLAN users. The WLAN Router provides NAT functionality while 2669 WLAN users access the Internet. 2671 While deploying IPv6 in the above mentioned WLAN architecture, there 2672 are three possible scenarios as discussed below. 2674 A. Layer 2 Switch Between AP and Edge Router 2675 B. Access Router Between AP and Edge Router 2676 C. PPP Based Model 2678 9.1.1 Layer 2 Switch Between AP and Edge Router 2680 When a Layer 2 switch is present between AP and Edge Router, the AP 2681 and Layer 2 switch continues to work as a bridge, forwarding IPv4 2682 and IPv6 packets from WLAN Host/Router to Edge Router and vice 2683 versa. 2685 When initiating the connection, the WLAN host is authenticated by the 2686 AAA server located at the SP network. All the parameters related to 2687 authentication (username, password and etc.) are forwarded by the AP 2688 to the AAA server. The AAA server authenticates the WLAN Hosts and 2689 once authenticated and associated successfully with WLAN AP, IPv6 2690 address will be acquired by the WLAN Host. Note the initiation and 2691 authentication process is same as used in IPv4. 2693 Figure 9.1.1 describes the WLAN architecture when Layer 2 Switch is 2694 located between AP and Edge Router. 2696 Customer Premises| Access Provider |Service Provider 2697 | | 2699 +------+ +--+ +--------------+ +----------+ +------+ 2700 |WLAN | ---- | | | | |Underlying| |Edge | 2701 |Host/ |-(WLAN)-|AP|-|Layer 2 Switch|-|Technology|-|Router|=>SP 2702 |Router| ---- | | | | | | | | Network 2703 +------+ +--+ +--------------+ +----------+ +------+ 2704 | 2705 +------+ 2706 |AAA | 2707 |Server| 2708 +------+ 2709 Figure 9.1.1 2711 9.1.1.1 IPv6 Related Infrastructure Changes 2713 IPv6 will be deployed in this scenario by upgrading the following 2714 devices to dual-stack: WLAN Host, WLAN Router (if present) and Edge 2715 Router. 2717 9.1.1.2 Addressing 2719 When customer WLAN Router is not present, the WLAN Host has two 2720 possible options to get an IPv6 address via the Edge Router. 2722 A. The WLAN host can get the IPv6 address from Edge router using 2723 stateless auto-configuration [RFC2462]. All the hosts on the WLAN 2724 belong to the same /64 subnet that is statically configured on the 2725 Edge Router. The IPv6 WLAN Host may use stateless DHCPv6 for 2726 obtaining other information of interest such as DNS and etc. 2728 B. IPv6 WLAN host can use DHCPv6 [RFC3315] to get a IPv6 address 2729 from the DHCPv6 server. In this case the DHCPv6 server would be 2730 located in the SP core network and Edge Router would act simply as 2731 a DHCP Relay Agent. This option is similar to what we do today in 2732 case of DHCPv4. It is important to note that host implementation of 2733 stateful auto-configuration is rather limited at this time and this 2734 should be considered if choosing this address assignment option. 2736 When a customer WLAN Router is present, the WLAN Host has two 2737 possible options as well for acquiring IPv6 address. 2739 A. The WLAN Router may be assigned a prefix between /48 and /64 2740 depending on the SP policy and customer requirements. If the WLAN 2741 Router has multiple networks connected to its interfaces, the network 2742 administrator will have to configure the /64 prefixes to the WLAN 2743 Router interfaces connecting the WLAN Hosts on the customer site. 2744 The WLAN Hosts connected to these interfaces can automatically 2745 configure themselves using stateless auto-configuration with /64 2746 prefix. 2748 B. The WLAN Router can use its link-local address to communicate with 2749 the ER. It can also dynamically acquire through stateless 2750 autoconfiguration the address for the link between itself and the ER. 2751 This step is followed by a request via DHCP-PD for a prefix shorter 2752 than /64 that in turn is divided in /64s and assigned to its 2753 interfaces connecting the hosts on the customer site. 2755 In this option, the WLAN Router would act as a requesting router and 2756 Edge Router would act as delegating router. Once prefix is received 2757 by the WLAN Router, it assigns /64 prefixes to each of its 2758 interfaces connecting the WLAN Hosts on the customer site. The WLAN 2759 Hosts connected to these interfaces can automatically configure 2760 themselves using stateless auto-configuration with /64 prefix. 2761 Currently the DHCP-PD functionality cannot be implemented if the 2762 DHCP-PD server is not the ER. If the DHCP-PD messages are relayed, 2763 the Edge Router does not have a mechanism to learn the assigned 2764 prefixes and thus install the proper routes to make that prefix 2765 reachable. Work is being done to address this issue, one idea being 2767 to provide the Edge Router with a snooping mechanism. The uplink to 2768 the ISP network is configured with a /64 prefix as well. 2770 Usually it is easier for the SPs to stay with the DHCP PD and 2771 stateless auto-configuration model and point the clients to a 2772 central server for DNS/domain information, proxy configurations and 2773 etc. Using this model the SP could change prefixes on the fly 2774 and the WLAN Router would simply pull the newest prefix based on the 2775 valid/preferred lifetime. 2777 The prefixes used for subscriber links and the ones delegated via 2778 DHCP-PD should be planned in a manner that allows maximum 2779 summarization as possible at the Edge Router. 2781 Other information of interest to the host, such as DNS, is provided 2782 through stateful [RFC3315] and stateless [RFC3736] DHCPv6. 2784 9.1.1.3 Routing 2786 The WLAN Host/Router are configured with a default route that points 2787 to the Edge router. No routing protocols are needed on these devices 2788 which generally have limited resources. 2790 The Edge Router runs the IGP used in the SP network such as OSPFv3 2791 or IS-IS for IPv6. The connected prefixes have to be redistributed. 2792 Prefix summarization should be done at the Edge Router. When DHCP-PD 2793 is used, the IGP has to redistribute the static routes installed 2794 during the process of prefix delegation. 2796 9.1.2 Access Router Between AP and SP Edge Router 2798 When a Access Router is present between AP and Edge Router, the AP 2799 continues to work as a bridge, bridging IPv4 and IPv6 packets from 2800 WLAN Host/Router to Access/Edge Router and vice versa. The Access 2801 Router could be part of SP network or owned by a separate Access 2802 Provider. 2804 When WLAN Host initiates the connection, the AAA authentication and 2805 association process with WLAN AP will be similar as explained in 2806 section 9.1.1. 2808 Figure 9.1.2 describes the WLAN architecture when Access Router is 2809 located between AP and Edge Router. 2811 Customer Premises| Access Provider |Service Provider 2812 | | 2814 +------+ +--+ +--------------+ +----------+ +------+ 2815 |WLAN | ---- | | | | |Underlying| |Edge | 2816 |Host/ |-(WLAN)-|AP|-|Access Router |-|Technology|-|Router|=>SP 2817 |Router| ---- | | | | | | | | Network 2818 +------+ +--+ +--------------+ +----------+ +------+ 2819 | 2820 +------+ 2821 |AAA | 2822 |Server| 2823 +------+ 2824 Figure 9.1.2 2826 9.1.2.1 IPv6 Related Infrastructure Changes 2828 IPv6 is deployed in this scenario by upgrading the following devices 2829 to dual-stack: WLAN Host, WLAN Router (if present), Access Router 2830 and Edge Router. 2832 9.1.2.2 Addressing 2834 There are three possible options in this scenario for IPv6 address 2835 assignment: 2837 A. The Edge Router interface facing towards the Access Router is 2838 statically configured with /64 prefix. The Access Router receives/ 2839 configures an /64 prefix on its interface facing towards Edge 2840 Router through stateless auto-configuration. The network 2841 administrator will have to configure the /64 prefixes to the Access 2842 Router interface facing towards the customer premises. The WLAN 2843 Host/Router connected to this interface can automatically configure 2844 themselves using stateless auto-configuration with /64 prefix. 2846 B. This option uses DHCPv6 [RFC3315] for IPv6 prefix assignments to 2847 the WLAN Host/Router. There is no use of DHCP PD or stateless 2848 auto-configuration in this option. The DHCPv6 server can be located 2849 on the Access Router, on the Edge Router or somewhere in the SP 2850 network. In this case depending on where the DHCPv6 server is 2851 located, Access Router or the Edge Router would relay the DHCPv6 2852 requests. 2854 C. It can use its link-local address to communicate with the ER. 2855 It can also dynamically acquire through stateless autoconfiguration 2856 the address for the link between itself and the ER. This step is 2857 followed by a request via DHCP-PD for a prefix shorter than /64 that 2858 in turn is divided in /64s and assigned to its interfaces connecting 2859 the hosts on the customer site. 2861 In this option, the Access Router would act as a requesting router 2862 and Edge Router would act as delegating router. Once prefix is 2863 received by the Access Router, it assigns /64 prefixes to each of 2864 its interfaces connecting the WLAN Host/Router on customer site. The 2865 WLAN Host/Router connected to these interfaces can automatically 2866 configure themselves using stateless auto-configuration with /64 2867 prefix. Currently the DHCP-PD functionality cannot be implemented if 2868 the DHCP-PD server is not the Edge Router. If the DHCP-PD messages 2869 are relayed, the Edge Router does not have a mechanism to learn the 2870 assigned prefixes and thus install the proper routes to make that 2871 prefix reachable. Work is being done to address this issue, one idea 2872 being to provide the Edge Router with a snooping mechanism. The 2873 uplink to the ISP network is configured with a /64 prefix as well. 2875 It is easier for the SPs to stay with the DHCP PD and stateless 2876 auto-configuration model and point the clients to a central 2877 server for DNS/domain information, proxy configurations and others. 2878 Using this model the provider could change prefixes on the fly and 2879 the Access Router would simply pull the newest prefix based on the 2880 valid/preferred lifetime. 2882 As mentioned before the prefixes used for subscriber links and the 2883 ones delegated via DHCP-PD should be planned in a manner that 2884 allows maximum summarization possible at the Edge Router. Other 2885 information of interest to the host, such as DNS, is provided 2886 through stateful [RFC3315] and stateless [RFC3736] DHCPv6. 2888 9.1.2.3 Routing 2890 The WLAN Host/Router are configured with a default route that points 2891 to the Access Router. No routing protocols are needed on these 2892 devices which generally have limited resources. 2894 If the Access Router is owned by an Access Provider, then the Access 2895 Router can have a default route, pointing towards the SP Edge 2896 Router. The Edge Router runs the IGP used in the SP network such as 2897 OSPFv3 or IS-IS for IPv6. The connected prefixes have to be 2898 redistributed. If DHCP-PD is used, with every delegated prefix a 2899 static route is installed by the Edge Router. For this reason the 2900 static routes must be redistributed. Prefix summarization should be 2901 done at the Edge Router. 2903 If the Access Router is owned by the SP, then Access Router will also 2904 run IPv6 IGP and will be part of SP IPv6 routing domain (OSPFv3 2905 or IS-IS). The connected prefixes have to be redistributed. If 2906 DHCP-PD is used, with every delegated prefix a static route is 2907 installed by the Access Router. For this reason the static routes 2908 must be redistributed. Prefix summarization should be done at the 2909 Access Router. 2911 9.1.3 PPP Based Model 2913 PPP TERMINATED AGGREGATION (PTA) and L2TPv2 ACCESS AGGREGATION (LAA) 2914 models as discussed in sections 7.2.2 and 7.2.3 respectively can 2915 also be deployed in IPv6 WLAN environment. 2917 9.1.3.1 PTA Model in IPv6 WLAN Environment 2919 While deploying the PTA model in IPv6 WLAN environment the Access 2920 Router is Layer3 aware and it has to be upgraded to support IPv6. 2921 Since the Access Router terminates the PPP sessions initiated by 2922 WLAN Host/Router, it has to support PPPoE with IPv6. 2924 Figure 9.1.3.1 describes the PTA Model in IPv6 WLAN environment 2926 Customer Premises| Access Provider |Service Provider 2927 | | 2929 +------+ +--+ +--------------+ +----------+ +------+ 2930 |WLAN | ---- | | | | |Underlying| |Edge | 2931 |Host/ |-(WLAN)-|AP|-|Access Router |-|Technology|-|Router|=>SP 2932 |Router| ---- | | | | | | | | Network 2933 +------+ +--+ +--------------+ +----------+ +------+ 2934 | 2935 <---------------------------> +------+ 2937 PPP |AAA | 2938 |Server| 2939 +------+ 2941 Figure 9.1.3.1 2943 9.1.3.1.1 IPv6 Related Infrastructure Changes 2945 IPv6 is deployed in this scenario by upgrading the following 2946 devices to dual-stack: WLAN Host, WLAN Router (if present), 2947 Access Router and Edge Router. 2949 9.1.3.1.2 Addressing 2951 The addressing techniques described in section 7.2.2.2 applies to 2952 IPv6 WLAN PTA scenario as well. 2954 9.1.3.1.3 Routing 2956 The routing techniques described in section 7.2.2.3 applies to 2957 IPv6 WLAN PTA scenario as well. 2959 9.1.3.2 LAA Model in IPv6 WLAN Environment 2961 While deploying the LAA model in IPv6 WLAN environment the Access 2962 Router is Layer3 aware and it has to be upgraded to support IPv6. 2963 The PPP sessions initiated by WLAN Host/Router are forwarded over 2964 the L2TPv2 tunnel to the aggregation point in the SP network. The 2965 Access Router must have the capability to support L2TPv2 for IPv6. 2967 Figure 9.1.3.2 describes the LAA Model in IPv6 WLAN environment 2969 Customer Premises| Access Provider |Service Provider 2970 | | 2972 +------+ +--+ +--------------+ +----------+ +------+ 2973 |WLAN | ---- | | | | |Underlying| |Edge | 2974 |Host/ |-(WLAN)-|AP|-|Access Router |-|Technology|-|Router|=>SP 2975 |Router| ---- | | | | | | | | Network 2976 +------+ +--+ +--------------+ +----------+ +------+ 2977 | 2978 <-------------------------------------------------->| 2979 PPP | 2980 <--------------------->| 2981 L2TPv2 | 2982 +------+ 2983 |AAA | 2984 |Server| 2985 +------+ 2987 Figure 9.1.3.2 2989 9.1.3.2.1 IPv6 Related Infrastructure Changes 2991 IPv6 is deployed in this scenario by upgrading the following 2992 devices to dual-stack: WLAN Host, WLAN Router (if present), 2993 Access Router and Edge Router. 2995 9.1.3.2.2 Addressing 2997 The addressing techniques described in section 7.2.3.2 applies to 2998 IPv6 WLAN LAA scenario as well. 3000 9.1.3.2.3 Routing 3002 The routing techniques described in section 7.2.3.3 applies to 3003 IPv6 WLAN LAA scenario as well. 3005 9.2 IPv6 Multicast 3007 The typical multicast services offered are video/audio streaming 3008 where the IPv6 WLAN Host joins a multicast group and receives the 3009 content. This type of service model is well supported through 3010 PIM-SSM which is enabled throughout the SP network. MLDv2 is required 3011 for PIM-SSM support. Vendors can choose to implement features that 3012 allow routers to map MLDv1 group joins to predefined sources. 3014 It is important to note that in the shared wireless environments 3015 multicast can have a significant bandwidth impact. For this reason 3016 the bandwidth allocated to multicast traffic should be limited and 3017 fixed based on the overall capacity of the wireless specification 3018 used 802.11a, 802.11b or 802.11g. 3020 The IPv6 WLAN Hosts can also join desired multicast groups as 3021 long as they are enabled to support MLDv1 or MLDv2. If a 3022 WLAN/Access Routers are used then they have to be enabled to 3023 support MLDv1 and MLDv2 in order to process the requests of the 3024 IPv6 WLAN Hosts. The WLAN/Access Router should also needs to be 3025 enabled to support PIM-SSM in order to send PIM joins up to the 3026 Edge Router. When enabling this functionality on a WLAN/Access 3027 Router, its limited resources should be taken into consideration. 3028 Another option would be for the WLAN/Access Router to support 3029 MLD proxy routing. 3031 The Edge Router has to be enabled to support MLDv1 and MLDv2 in 3032 order to process the requests coming from IPv6 WLAN Host or 3033 WLAN/Access Router (if present). The Edge Router has also needs 3034 to be enabled for PIM-SSM in order to receive joins from IPv6 3035 WLAN Hosts or WLAN/Access Router (if present) and send joins 3036 towards the SP core. 3038 MLD authentication, authorization and accounting is usually 3039 configured on the Edge Router in order to enable the SP to do 3040 billing for the content services provided. Further investigation 3041 should be made in investigating alternative mechanisms that would 3042 support these functions. 3044 Concerns have been raised in the past related to running IPv6 3045 multicast over WLAN links. Potentially these are same kind of 3046 issues when running any Layer3 protocol over a WLAN link that has a 3047 high loss-to-signal ratio, where certain frames that are multicast 3048 based are dropped when settings are not adjusted properly. For 3049 instance this behavior is similar to IGMP host membership report, 3050 when done on a WLAN link with high loss-to-signal ratio and high 3051 interference. 3053 This problem is inherited to WLAN that can impact both IPv4 and IPv6 3054 multicast packets and not specific to IPv6 multicast. 3056 While deploying WLAN (IPv4 or IPv6), one should adjust their 3057 broadcast/multicast settings if they are in danger of dropping 3058 application dependent frames. These problems are usually caused when 3059 AP are placed too far apart (not following the distance limitations), 3060 high interference and etc. These issues may impact a real multicast 3061 application such as streaming video or basic operation of IPv6 if 3062 the frames were dropped. Basic IPv6 communications uses functions 3063 such as Duplicate Address Detection (DAD), Router and Neighbor 3064 Solicitations (RS, NS), Router and Neighbor Advertisement (RA, NA) 3065 and etc. which could be impacted by the above mentioned issues as 3066 these frames are Layer 2 Ethernet multicast frames. 3068 Please refer to section 7.3 for more IPv6 multicast details. 3070 9.3 IPv6 QoS 3072 Today, QoS is done outside of the WiFi domain but it is 3073 nevertheless important to the overall deployment. 3075 The QoS configuration is particularly relevant on the Edge Router in 3076 order to manage resources shared amongst multiple subscribers 3077 possibly with various service level agreements (SLA). Although, the 3078 WLAN Host/Router and Access Router could also be configured for QoS. 3079 This includes support for IPv6 classifiers, so that data traffic 3080 to/from IPv6 WLAN Host/Router, Access Router and Edge Router can be 3081 classified appropriately into different service flows (SF) and be 3082 assigned appropriate priority. Appropriate classification criteria 3083 would need to be implemented for IPv6 unicast and multicast traffic. 3085 On the Edge Router the subscriber facing interfaces have to be 3086 configure to police the inbound customer traffic and shape the 3087 traffic outbound to the customer, based on the SLA. Traffic 3088 classification and marking should also be done on the Edge router in 3089 order to support the various types of customer traffic: data, voice, 3090 video. The same IPv4 QoS concepts and methodologies should be applied 3091 for the IPv6 as well. 3093 It is important to note that when traffic is encrypted end-to-end, 3094 the traversed network devices will not have access to many of the 3095 packet fields used for classification purposes. In these cases 3096 routers will most likely place the packets in the default classes. 3097 The QoS design should take into consideration this scenario and try 3098 to use mainly IP header fields for classification purposes. 3100 9.4 IPv6 Security Considerations 3102 There are limited changes that have to be done for WLAN Host/Router 3103 in order to enhance security. The Privacy extensions [RFC3041] for 3104 autoconfiguration should be used by the hosts with the same 3105 consideration for host traceability as described in section 7.5. 3106 IPv6 firewall functions should be enabled on the WLAN Host/Router if 3107 present. 3109 The ISP provides security against attacks that come form its own 3110 subscribers but it could also implement security services that 3111 protect its subscribers from attacks sourced from the outside of 3112 its network. Such services do not apply at the access level of the 3113 network discussed here. 3115 If the host authentication at hot spots is done using web based 3116 authentication system then the level of security would depend on 3117 the particular implementation. User credential should never be sent 3118 as clear text via HTTP. Secure HTTP (HTTPS) should be used between 3119 the web browser and authentication server. The authentication 3120 server could use RADIUS and LDAP services at the back end. 3122 Authentication is an important aspect of securing WLAN networks 3123 prior to implementing Layer 3 security policies. This would help 3124 for example avoid threats to the ND or stateless autoconfiguration 3125 processes. 802.1x provides the means to secure the network access 3126 however, the many types of EAP (PEAP, EAP-TLS, EAP-TTLS, EAP-FAST, 3127 LEAP) and the capabilities of the hosts to support some of the 3128 features might make it difficult to implement a comprehensive and 3129 consistent policy. 3131 If any layer two filters for Ethertypes are in place, the NAP must 3132 permit the IPv6 Ethertype (0X86DD). 3134 The device that is the Layer3 next hop for the subscribers 3135 (Access or Edge Router) should protect the network and the other 3136 subscribers against attacks by one of the provider customers. 3137 For this reason uRPF and ACLs should be used on all interfaces 3138 facing subscribers. Filtering should be implemented with regard for 3139 the operational requirements of IPv6 [Security considerations for 3140 IPv6]. Authentication and authorization should be used wherever 3141 possible. 3143 The Access and the Edge Router should protect their processing 3144 resources against floods of valid customer control traffic such as: 3145 RS, NS, MLD Requests. Rate limiting should be implemented on all 3146 subscriber facing interfaces. The emphasis should be placed on 3147 multicast type traffic as it is most often used by the IPv6 control 3148 plane. 3150 9.5 IPv6 Network Management 3152 The necessary instrumentation (such as MIBs, NetFlow Records, etc) 3153 should be available for IPv6. 3155 Usually, NSPs manage the edge routers by SNMP. The SNMP transport can 3156 be done over IPv4 if all managed devices have connectivity over both 3157 IPv4 and IPv6. This would imply the smallest changes to the existent 3158 network management practices and processes. Transport over IPv6 could 3159 also be implemented and it might become necessary if IPv6 only 3160 islands are present in the network. The management stations are 3161 located on the core network. Network Management Applications should 3162 handle IPv6 in a similar fashion to IPv4 however they should also 3163 support features specific to IPv6 (such as Neighbor monitoring). 3165 In some cases service providers manage equipment located on customers 3166 LANs. 3168 10. Broadband Power Line Communications (PLC) 3170 This section describes the IPv6 deployment in Power Line 3171 Communications (PLC) Access Networks. There may be other choices, 3172 but it seems that this is the best model to follow. Lessons learnt 3173 from Cable, Ethernet and even WLAN access networks may be applicable 3174 also. 3176 Power Line Communications are also often called Broadband Power Line 3177 (BPL) and some times even Power Line Telecommunications (PLT). 3179 PLC/BPL can be used for providing, with todays technology, up to 3180 200Mbps (total, upstream+downstream) by means of the power grid. The 3181 coverage is often the last half mile (typical distance from the 3182 Medium-to-Low Voltage transformer to the customer premise meter), 3183 and of course, as an in-home network (which is out of the scope of 3184 this document). 3186 The bandwidth in a given PLC/BPL segment is shared among all the 3187 customers connected to that segment (often the customers connected 3188 to the same medium-to-low voltage transformer). The number of 3189 customers can vary depending on different factors, such as distances 3190 and even countries (from a few customers, just 5-6, up to 100-150). 3192 PLC/BPL could also be used in the Medium Voltage network (often 3193 configured as Metropolitan Area Networks), but this is also out 3194 of the scope of this document, as it will be part of the core 3195 network, not the access one. 3197 Just for information/clarification, often the PLC/BPL access 3198 networks use hybrid layer 2 combinations either with PLC/BPL in the 3199 medium voltage, point to point links, wireless links, satellite, 3200 etc., but once more, this seems to be out of the scope of this 3201 document, as those means are transparent, for the purpose of this 3202 document, to the last half mile access network deployed with PLC/BPL. 3204 10.1 PLC/BPL Access Network Elements 3206 This section describes the different elements commonly used in 3207 PLC/BPL access networks. 3209 Head End (HE): It is the router that connects the PLC/BPL access 3210 network (the power grid), located at the medium-to-low voltage 3211 transformer, to the core network. The HE PLC/BPL interface appears 3212 to each customer as a single virtual interface, all of them sharing 3213 the same physical media. 3215 Repeater (RPT): It is the device which may be required in some 3216 circumstances to improve the signal on the PLC/BPL. This may be the 3217 case if there are many customers in the same segment or building. 3218 Often is a bridge, but it could be also a router if for example 3219 there is a lot of peer-to-peer traffic in a building and due to the 3220 master-slave nature of the PLC/BPL technology, is required to improve 3221 the performance within that segment. For simplicity, in this 3222 document, it will be considered that the RPT is always a transparent 3223 layer 2 bridge, so it may be present or not (from the layer 3 point 3224 of view). 3226 Customer Premise Equipment (CPE): It is the modem (internal to the 3227 host), modem/bridge (BCPE), router (RCPE) or any combination among 3228 those (i.e. modem+bridge/router), located at the customer premise. 3230 Edge Router (ER) 3232 Figure 10.1 depicts all the network elements indicated above 3234 Customer Premises | Network Access Provider | Network Service Provider 3235 CP NAP NSP 3237 +-----+ +------+ +-----+ +------+ +--------+ 3238 |Hosts|--| RCPE |--| RPT |--------+ HE +---+ Edge | ISP 3239 +-----+ +------+ +-----+ | | | Router +===> Network 3240 +--+---+ +--------+ 3241 +-----+ +------+ +-----+ | 3242 |Hosts|--| BCPE |--| RPT |-----------+ 3243 +-----+ +------+ +-----+ 3245 Figure 10.1 3247 The logical topology and design of PLC/BPL is very similar to 3248 Ethernet Broadband Networks as discussed in section 8. 3250 10.2 Deploying IPv6 in IPv4 PLC/BPL 3252 The most simplistic and efficient model, considering the nature of 3253 the PLC/BPL networks, is to see the network as a point-to-point one 3254 to each customer. Even if several customers share the same physical 3255 media, the traffic is not visible among them because each one uses 3256 different channels, which are in addition encrypted by means of 3DES. 3258 Furthermore, if required, VLANs could also be used, as already 3259 described for the Ethernet case. 3261 In order to maintain the deployment concepts and business models 3262 proven and used with existing revenue generating IPv4 services, 3263 the IPv6 deployment will match the IPv4 one. Under certain 3264 circumstances where new service types or service needs justify it, 3265 IPv4 and IPv6 network architectures could be different. Both 3266 approaches are very similar to those already described for the 3267 Ethernet case. 3269 10.2.1 IPv6 Related Infrastructure Changes 3271 In this scenario the RPT is layer 3 unaware, but not the Head End, 3272 which should be upgraded to support IPv6. Similarly other devices 3273 which have to be upgraded to dual stack: Hosts, RCPE and Edge Router. 3275 10.2.2 Addressing 3277 The Hosts or the RCPEs have the HE as their Layer 3 next hop. 3279 If there is no RCPE, but instead a BCPE all the hosts on the 3280 subscriber site belong to the same /64 subnet that is statically 3281 configured on the HE. The hosts can use stateless 3282 autoconfiguration or stateful DHCPv6 based configuration to 3283 acquire an address via the HE. 3285 If a RCPE is present: 3287 A. It is statically configured with an address on the /64 subnet 3288 between itself and the HE, and with /64 prefixes on the 3289 interfaces connecting the hosts on the customer site. This is not 3290 a desired provisioning method being expensive and difficult to 3291 manage. 3293 B. It can use its link-local address to communicate with the HE. 3294 It can also dynamically acquire through stateless 3295 autoconfiguration the address for the link between itself and 3296 the HE. This step is followed by a request via DHCP-PD for a 3297 prefix shorter than /64 (typically /48) that in turn is divided 3298 in /64s and assigned to its interfaces connecting the hosts on 3299 the customer site. This should be the preferred provisioning 3300 method, being cheaper and easier to manage. 3302 The Edge Router needs to have a prefix considering that each 3303 customer in general will receive a /48 prefix, and that each HE 3304 will accommodate customers. Consequently each HE will require 3305 n x /48 prefixes. 3307 It could be possible to use a kind of Hierarchical Prefix 3308 Delegation to automatically provision the required prefixes and 3309 fully auto-configure the HEs, and consequently reduce the network 3310 setup, operation and maintenance cost. 3312 The prefixes used for subscriber links and the ones delegated via 3313 DHCP-PD should be planned in a manner that allows as much 3314 summarization as possible at the Edge Router. 3316 Other information of interest to the host, such as DNS, is provided 3317 through stateful [RFC3315] and stateless [RFC3736] DHCPv6. 3319 10.2.3 Routing 3321 The HE are configured with a default route that points to 3322 the Edge Router. No routing protocols are needed on these devices 3323 which generally have limited resources. 3325 The Edge Router runs the IPv6 IGP used in the NSP: OSPFv3 or IS-IS. 3326 The connected prefixes have to be redistributed. If DHCP-PD is used, 3327 with every delegated prefix a static route is installed by the HE 3328 For this reason the static routes must also be redistributed. 3329 Prefix summarization should be done at the HE. 3331 10.3 IPv6 Multicast 3333 The considerations regarding IPv6 Multicast for Ethernet are also 3334 applicable here, in general, but assuming the nature of PLC/BPL 3335 being a shared media. If a lot of Multicast is expected, it may be 3336 worth considering using RPT which are layer 3 aware. In that case, 3337 one extra layer of Hierarchical DHCP-PD could be considered, in 3338 order to facilitate the deployment, operation and maintenance of 3339 the network. 3341 10.4 IPv6 QoS 3343 The considerations introduced for QoS in Ethernet are also 3344 applicable here. PLC/BPL networks support QoS, which basically are 3345 no different whether the transport is IPv4 or IPv6. It is necessary 3346 to understand that the specific network characteristics, such as the 3347 variability that may be introduced by electrical noise, towards which 3348 the PLC/BPL network will automatically self-adapt. 3350 10.5 IPv6 Security Considerations 3352 There are no differences in terms of security considerations if 3353 compared with the Ethernet case. 3355 10.6 IPv6 Network Management 3357 There are no differences in terms of network management if compared 3358 with the already described Ethernet case. 3360 11. Gap Analysis 3362 Several aspects of deploying IPv6 over SP Broadband networks were 3363 highlighted in this document, aspects that require additional work 3364 in order to facilitate native deployments as summarized below: 3366 A. As mentioned in section 6, changes will need to be made to the 3367 DOCSIS specification in order for SPs to deploy native IPv6 over 3368 cable networks. The CM and CMTS will both need to support IPv6 3369 natively in order to forward IPv6 unicast and multicast traffic. 3370 This is required for IPv6 Neighbor Discovery to work over DOCSIS 3371 cable networks. Additional classifiers need to be added to the 3372 DOCSIS specification in order to classify IPv6 traffic at the CM 3373 and CMTS in order to provide QoS. 3375 B. Currently the DHCP-PD functionality cannot be implemented if the 3376 DHCP-PD server is not the Edge Router. If the DHCP-PD messages are 3377 relayed, the Edge Router does not have a mechanism to learn the 3378 assigned prefixes and thus install the proper routes to make that 3379 prefix reachable. Work needs to be done to address this issue, one 3380 idea being to provide the Edge Router with a snooping mechanism. The 3381 uplink to the ISP network is configured with a /64 prefix as well. 3383 C. Section 7 stated that current RBE based IPv4 deployment might not 3384 be the best approach for IPv6 where the addressing space available 3385 gives the SP the opportunity to separate the users on different 3386 subnets. The differences between IPv4 RBE and IPv6 RBE were 3387 highlighted in section 7. If however, support and reason is found 3388 for a deployment similar to IPv4 RBE, then the environment becomes 3389 NBMA and the new feature should observe RFC2491 recommendations. 3391 D. Section 7 discussed the constraints imposed on a LAA based IPv6 3392 deployment by the fact that it is expected that the subscribers keep 3393 their assigned prefix regardless of LNS. A deployment approach was 3394 proposed that would maintain the addressing schemes contiguous and 3395 offers prefix summarization opportunities. The topic could be 3396 further investigated for other solutions or improvements. 3398 E. Sections 7 and 8 pointed out the limitations (previously 3399 documented in [IPv6 Multicast]) in deploying inter-domain ASM 3400 however, SSM based services seem more likely at this time. For such 3401 SSM based services of content delivery (video or Audio), mechanisms 3402 are needed to facilitate the billing and management of listeners. 3403 The currently available feature of MLD AAA is suggested however, 3404 other methods or mechanisms might be developed and proposed. 3406 F. In relation to section 9, concerns have been raised related to 3407 running IPv6 multicast over WLAN links. Potentially these are same 3408 kind of issue when running any Layer3 protocol over a WLAN link 3409 that has a high loss-to-signal ratio, certain frames that are 3410 multicast based are dropped when settings are not adjusted 3411 properly. For instance this behavior is similar to IGMP host 3412 membership report, when done on a WLAN link with high 3413 loss-to-signal ratio and high interference. This problem is 3414 inherited to WLAN that can impact both IPv4 and IPv6 multicast 3415 packets and not specific to IPv6 multicast. 3417 G. The Privacy Extensions were mentioned as a popular means to 3418 provide some form of host security. ISPs can track relatively 3419 easily the prefixes assigned to subscribers. If however the ISPs 3420 are required by regulations to track their users at host address 3421 level, the Privacy Extensions [RFC3041] can be implemented only in 3422 parallel with network management tools that could provide 3423 traceability of the hosts. Mechanisms should be defined to 3424 implement this aspect of user management. 3426 H. Tunnels are an effective way to avoid deployment dependencies on 3427 the IPv6 support on platforms that are out of the SP control (GWRs 3428 or CPEs) or over technologies that did not standardize the IPv6 3429 support yet (cable). They can be used in the following ways: 3431 i. Tunnels directly to the CPE or GWR with public or private IPv4 3432 addresses. 3433 ii. Tunnels directly to hosts with public or private IPv4 addresses. 3435 Recommendations on the exact tunneling mechanisms that can/should be 3436 used for last mile access need to be investigated further and should 3437 be covered in a future IETF draft. 3439 I. Through its larger address space, IPv6 allows SPs to assign 3440 fixed, globally routable prefixes to the links connecting each 3441 subscriber. 3443 This approach changes the provisioning methodologies that were used 3444 for IPv4. Static configuration of the IPv6 addresses for all these 3445 links on the Edge Routers or Access Routers might not be a scalable 3446 option. New provisioning mechanisms or features might need to be 3447 developed in order to deal with this issue. 3449 J. New deployment models are emerging for the Layer 2 portion of the 3450 NAP where individual VLANs are not dedicated to each subscriber. This 3451 approach allows Layer 2 switches to aggregate more then 4096 users. 3452 MAC Forced Forwarding [MFF] is an example of such an implementation 3453 where a broadcast domain is turned into a NBMA like environment by 3454 forwarding the frames based on both Source and Destination MAC 3455 addresses. Since these models are being adopted by the field, the 3456 implications of deploying IPv6 in such environments need to be 3457 further investigated. 3459 The outcome of solutions to some of these topics ranges from making 3460 a media access capable of supporting native IPv6 (cable) to 3461 improving operational aspects of native IPv6 deployments. 3463 12. Contributors 3465 We would like to thank Pekka Savola for his contribution, guidance 3466 and feedback in order to improve this document. 3468 13. Acknowledgements 3470 We would like to thank Brian Carpenter, Patrick Grossetete, Toerless 3471 Eckert, Madhu Sudan, Shannon McFarland and Benoit Lourdelet for their 3472 valuable comments. The authors would like to acknowledge the 3473 structure and information guidance provided by the work of Mickels et 3474 al on Transition Scenarios for ISP Networks. 3476 14. References 3478 Normative References 3480 [RFC3053] 3481 Durand A., Fasano P., Guardini I., Lento D. "IPv6 Tunnel Broker", 3482 RFC3053, January 2001. 3484 [RFC3056] 3485 Carpenter B., Moore K., "Connection of IPv6 Domains via IPv4 Clouds", 3486 RFC3056, Aprilruary 2001. 3488 [RFC2473] 3489 Conta A., Deering S., "Generic Packet tunneling in IPv6 3490 Specification", December 1998. 3492 [RFC2893] 3493 Gilligan R., Nordmark E., "Transition Mechanisms for IPv6 Hosts 3494 and Routers", August 2000. 3496 [RFC2529] 3497 Carpenter B., Jung C. "Transmission of IPv6 over IPv4 Domains 3498 without Explicit Tunnels", March 1999 3500 [RFC3904] 3501 Huitema C., Austein R., Satapati S., van der Pol R., "Evaluation 3502 of IPv6 Transition Mechanisms for Unmanaged Networks", September 2000 3504 [RFC3513] 3505 R. Hinden and S. Deering, "IP Version 6 Addressing Architecture", 3506 RFC3513, April 2003. 3508 [RFC3736] 3509 Droms, R., "Stateless Dynamic Host Configuration Protocol (DHCP) 3510 Service for IPv6", RFC3736, April 2004. 3512 [RFC3315] 3513 Droms, R., "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", 3514 RFC3315, July 2003. 3516 [RFC2462] 3517 Thomson, S. and Narten, T., "IPv6 Stateless Address 3518 Autoconfiguration", RFC2462, December 1998. 3520 [RFC3633] 3521 Troan, O. and Droms, R., "IPv6 Prefix Options for Dynamic Host 3522 Configuration Protocol (DHCP) version 6", RFC3633, December 2003. 3524 [RFC3041] 3525 T. Narten and R. Draves, "Privacy Extensions for Stateless Address 3526 Autoconfiguration in IPv6," RFC3041, April 2001. 3528 [RFC2516] 3529 Mamakos, L., "A Method for Transmitting PPP Over Ethernet (PPPoE)", 3530 RFC2516, Aprilruary 1999. 3532 [RFC2364] 3533 Gross, G., "PPP Over AAL5 (PPPoA)", RFC2516, July 1998. 3535 [RFC2472] 3536 Haskin, D. and Allen, E., "IP Version 6 over PPP", RFC2472, 3537 December 1998. 3539 [RFC2461] 3540 Narten, T., Nordmark, E. and Simpson, W., "Neighbor Discovery for 3541 IP Version 6 (IPv6)", RFC2461, December 1998. 3543 [RFC2770] 3544 Meyer. D., "GLOP Addressing in 233/8", RFC2770, April 2000 3546 [RFC3646] 3547 Droms, R., "DNS Configuration options for Dynamic Host 3548 Configuration Protocol for IPv6 (DHCPv6)", RFC3646, December 2003. 3550 [RFC3618] 3551 Fenner B., Meyer D., "Multicast Source Discovery Protocol (MSDP)", 3552 RFC3618, October 2003 3554 Informative References 3556 [Dual Stack Access] 3557 Shirasaki, et al., "A Model of IPv6/IPv4 Dual Stack Internet Access 3558 Service", draft-shirasaki-dualstack-service-04.txt (work in 3559 progress) ,April 2004. 3561 [6PE] De Clercq J., et al., "Connecting IPv6 Islands across IPv4 3562 Clouds with BGP:, draft-ooms-v6ops-bgp-tunnel-04.txt, October 2004 3564 [ISP Networks IPv6 Scenarios] 3565 Lind et, al., "Scenarios and Analysis for Introducing IPv6 into ISP 3566 Networks", RFC 4029, March 2005. 3568 [ISATAP] 3569 Templin F., et al., "Intra-Site Automatic Tunnel Addressing Protocol 3570 (ISATAP)", draft-ietf-ngtrans-isatap-12.txt, January 2003. 3572 [Dynamic Tunnel] 3573 Palet J., et al., "Analysis of IPv6 Tunnel End-point Discovery 3574 Mechanisms", draft-palet-v6ops-tun-auto-disc-01.txt, June 2004. 3576 [OPS] 3577 Nordmark E., Gilligan R. E., "Basic Transition Mechanisms for 3578 IPv6 Hosts and Routers", draft-ietf-v6ops-mech-v2-06.txt, 3579 September 2004. 3581 [DOCSIS 3.0 Proposal] 3582 Cisco Systems, "DOCSIS 3.0 Proposal", April 2005. 3584 [IPv6 Multicast] 3585 Savola, P. "IPv6 Multicast Deployment Issues", 3586 draft-mboned-ipv6-multicast-issues, April 2004 3588 [RF Interface] 3589 Cable Labs, "Radio Frequency Interface Specification 3590 SP-RFIv2.0-I02-020617", Jun 2002. 3592 [BSR] 3593 Nidhi Bhaskar et all., "Bootstrap Router (BSR) Mechanism for PIM", 3594 draft-ietf-pim-sm-bsr-04.txt, January 2005 3596 [Assisted Tunneling] 3597 A.Durand, F. Parent,"Requirements for assisted tunneling", 3598 draft-ietf-v6ops-assisted-tunneling-requirements-00.txt, June 2004 3600 [v6tc] 3601 J. Pallet, et al., "Goals for Tunneling Configuration", 3602 draft-palet-v6tc-goals-tunneling-00.txt, August, 2005 3604 [Security considerations for IPv6] 3605 Sean Convery, Darrin Miller, "IPv6 and IPv4 Threat Comparison 3606 and Best-Practice Evaluation" 3608 Authors Addresses 3610 Salman Asadullah 3611 Cisco Systems, Inc. 3612 170 West Tasman Drive, 3613 San Jose, CA 95134, USA 3614 Phone: 408 526 8982 3615 Email: sasad@cisco.com 3617 Adeel Ahmed 3618 Cisco Systems, Inc. 3619 2200 East President George Bush Turnpike, 3620 Richardson, TX 75082, USA 3621 Phone: 469 255 4122 3622 Email: adahmed@cisco.com 3624 Ciprian Popoviciu 3625 Cisco Systems, Inc. 3626 7025-6 Kit Creek Road, 3627 Research Triangle Park, NC 27709, USA 3628 Phone: 919 392 3723 3629 Email: cpopovic@cisco.com 3631 Jordi Palet Martinez 3632 Consulintel 3633 San Jose Artesano, 1 3634 Alcobendas - Madrid 3635 E-28108 - Spain 3637 Phone: +34 91 151 81 99 3638 Fax: +34 91 151 81 98 3639 Email: jordi.palet@consulintel.es 3641 Intellectual Property Statement 3643 The IETF takes no position regarding the validity or scope of any 3644 Intellectual Property Rights or other rights that might be claimed 3645 to pertain to the implementation or use of the technology describe 3646 in this document or the extent to which any license under such 3647 rights might or might not be available; nor does it represent that 3648 it has made any independent effort to identify any such rights. 3649 Information on the procedures with respect to rights in RFC 3650 documents can be found in BCP 78 and BCP 79. 3652 Copies of IPR disclosures made to the IETF Secretariat and any 3653 assurances of licenses to be made available, or the result of an 3654 attempt made to obtain a general license or permission for the use 3655 of such proprietary rights by implementers or users of this 3656 specification can be obtained from the IETF on-line IPR repository 3657 at http://www.ietf.org/ipr. 3659 The IETF invites any interested party to bring to its attention any 3660 copyrights, patents or patent applications, or other proprietary 3661 rights that may cover technology that may be required to implement 3662 this standard. Please address the information to the IETF at ietf- 3663 ipr@ietf.org. 3665 Disclaimer of Validity 3667 This document and the information contained herein are provided on 3668 an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 3669 REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND 3670 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, 3671 EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT 3672 THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR 3673 ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A 3674 PARTICULAR PURPOSE. 3676 Copyright Statement 3678 Copyright (C) The Internet Society (2004). This document is 3679 subject to the rights, licenses and restrictions contained in BCP 3680 78, and except as set forth therein, the authors retain all their 3681 rights. 3683 Acknowledgment 3685 Funding for the RFC Editor function is currently provided by the 3686 Internet Society.