idnits 2.17.1 draft-ietf-v6ops-bb-deployment-scenarios-04.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 20. -- Found old boilerplate from RFC 3978, Section 5.5 on line 3715. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 3692. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 3699. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 3705. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- == There are 31 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (October 20, 2005) is 6762 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Looks like a reference, but probably isn't: 'MFF' on line 3468 == Unused Reference: '12' is defined on line 3549, but no explicit reference was found in the text == Unused Reference: '16' is defined on line 3563, but no explicit reference was found in the text == Unused Reference: '20' is defined on line 3576, but no explicit reference was found in the text ** Downref: Normative reference to an Informational RFC: RFC 3053 (ref. '2') ** Downref: Normative reference to an Informational RFC: RFC 3904 (ref. '6') ** Obsolete normative reference: RFC 3177 (ref. '7') (Obsoleted by RFC 6177) ** Obsolete normative reference: RFC 3513 (ref. '8') (Obsoleted by RFC 4291) ** Obsolete normative reference: RFC 3736 (ref. '9') (Obsoleted by RFC 8415) ** Obsolete normative reference: RFC 3315 (ref. '10') (Obsoleted by RFC 8415) ** Obsolete normative reference: RFC 2462 (ref. '11') (Obsoleted by RFC 4862) ** Obsolete normative reference: RFC 3633 (ref. '12') (Obsoleted by RFC 8415) ** Obsolete normative reference: RFC 3041 (ref. '13') (Obsoleted by RFC 4941) ** Downref: Normative reference to an Informational RFC: RFC 2516 (ref. '14') ** Obsolete normative reference: RFC 2472 (ref. '16') (Obsoleted by RFC 5072, RFC 5172) ** Obsolete normative reference: RFC 2461 (ref. '17') (Obsoleted by RFC 4861) ** Obsolete normative reference: RFC 2770 (ref. '18') (Obsoleted by RFC 3180) ** Obsolete normative reference: RFC 2669 (ref. '19') (Obsoleted by RFC 4639) ** Downref: Normative reference to an Experimental RFC: RFC 3618 (ref. '21') ** Obsolete normative reference: RFC 3775 (ref. '23') (Obsoleted by RFC 6275) ** Downref: Normative reference to an Informational RFC: RFC 4029 (ref. '24') == 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 -- No information found for draft-mboned-ipv6-multicast-issues - is the name correct? == Outdated reference: A later version (-12) exists of draft-ietf-pim-sm-bsr-04 Summary: 20 errors (**), 0 flaws (~~), 10 warnings (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group S. Asadullah 3 Internet-Draft A. Ahmed 4 Expires: April 23, 2006 C. Popoviciu 5 Cisco Systems 6 P. Savola 7 CSC/FUNET 8 J. Palet 9 Consulintel 10 October 20, 2005 12 ISP IPv6 Deployment Scenarios in Broadband Access Networks 13 15 Status of this Memo 17 By submitting this Internet-Draft, each author represents that any 18 applicable patent or other IPR claims of which he or she is aware 19 have been or will be disclosed, and any of which he or she becomes 20 aware will be disclosed, in accordance with Section 6 of BCP 79. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF), its areas, and its working groups. Note that 24 other groups may also distribute working documents as Internet- 25 Drafts. 27 Internet-Drafts are draft documents valid for a maximum of six months 28 and may be updated, replaced, or obsoleted by other documents at any 29 time. It is inappropriate to use Internet-Drafts as reference 30 material or to cite them other than as "work in progress." 32 The list of current Internet-Drafts can be accessed at 33 http://www.ietf.org/ietf/1id-abstracts.txt. 35 The list of Internet-Draft Shadow Directories can be accessed at 36 http://www.ietf.org/shadow.html. 38 This Internet-Draft will expire on April 23, 2006. 40 Copyright Notice 42 Copyright (C) The Internet Society (2005). 44 Abstract 46 This document provides detailed description of IPv6 deployment and 47 integration methods and scenarios in today's Service Provider (SP) 48 Broadband (BB) networks in coexistence with deployed IPv4 services. 49 Cable/HFC, BB Ethernet, xDSL and WLAN are the main BB technologies 50 that are currently deployed, and discussed in this document. The 51 emerging Broadband Power Line Communications (PLC/BPL) access 52 technology is also discussed for completeness. In this document we 53 will discuss main components of IPv6 BB networks and their 54 differences from IPv4 BB networks and how IPv6 is deployed and 55 integrated in each of these BB technologies using tunneling 56 mechanisms and native IPv6. 58 Table of Contents 60 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 61 1.1. Common Terminology . . . . . . . . . . . . . . . . . . . . 4 62 2. IPv6 Based BB Services . . . . . . . . . . . . . . . . . . . . 5 63 3. Scope of the Document . . . . . . . . . . . . . . . . . . . . 6 64 4. Core/Backbone Network . . . . . . . . . . . . . . . . . . . . 7 65 4.1. Layer 2 Access Provider Network . . . . . . . . . . . . . 7 66 4.2. Layer 3 Access Provider Network . . . . . . . . . . . . . 7 67 5. Tunneling Overview . . . . . . . . . . . . . . . . . . . . . . 9 68 5.1. Access over Tunnels - Customers with Public IPv4 69 Address . . . . . . . . . . . . . . . . . . . . . . . . . 9 70 5.2. Access over Tunnels - Customers with Private IPv4 71 Address . . . . . . . . . . . . . . . . . . . . . . . . . 9 72 5.3. Transition a Portion of the IPv4 Infrastructure . . . . . 10 73 6. Broadband Cable Networks . . . . . . . . . . . . . . . . . . . 11 74 6.1. Broadband Cable Network Elements . . . . . . . . . . . . . 11 75 6.2. Deploying IPv6 in Cable Networks . . . . . . . . . . . . . 12 76 6.2.1. Deploying IPv6 in a Bridged CMTS Network . . . . . . . 13 77 6.2.2. Deploying IPv6 in a Routed CMTS Network . . . . . . . 16 78 6.2.3. IPv6 Multicast . . . . . . . . . . . . . . . . . . . . 25 79 6.2.4. IPv6 QoS . . . . . . . . . . . . . . . . . . . . . . . 26 80 6.2.5. IPv6 Security Considerations . . . . . . . . . . . . . 27 81 6.2.6. IPv6 Network Management . . . . . . . . . . . . . . . 28 82 7. Broadband DSL Networks . . . . . . . . . . . . . . . . . . . . 29 83 7.1. DSL Network Elements . . . . . . . . . . . . . . . . . . . 29 84 7.2. Deploying IPv6 in IPv4 DSL Networks . . . . . . . . . . . 30 85 7.2.1. Point-to-Point Model . . . . . . . . . . . . . . . . . 31 86 7.2.2. PPP Terminated Aggregation (PTA) Model . . . . . . . . 33 87 7.2.3. L2TPv2 Access Aggregation (LAA) Model . . . . . . . . 36 88 7.2.4. Hybrid Model for IPv4 and IPv6 Service . . . . . . . . 39 89 7.3. IPv6 Multicast . . . . . . . . . . . . . . . . . . . . . . 41 90 7.3.1. ASM Based Deployments . . . . . . . . . . . . . . . . 41 91 7.3.2. SSM Based Deployments . . . . . . . . . . . . . . . . 42 92 7.4. IPv6 QoS . . . . . . . . . . . . . . . . . . . . . . . . . 43 93 7.5. IPv6 Security Considerations . . . . . . . . . . . . . . . 43 94 7.6. IPv6 Network management . . . . . . . . . . . . . . . . . 44 95 8. Broadband Ethernet Networks . . . . . . . . . . . . . . . . . 45 96 8.1. Ethernet Access Network Elements . . . . . . . . . . . . . 45 97 8.2. Deploying IPv6 in IPv4 Broadband Ethernet Networks . . . . 46 98 8.2.1. Point-to-Point Model . . . . . . . . . . . . . . . . . 47 99 8.2.2. PPP Terminated Aggregation (PTA) Model . . . . . . . . 48 100 8.2.3. L2TPv2 Access Aggregation (LAA) Model . . . . . . . . 50 101 8.2.4. Hybrid Model for IPv4 and IPv6 Service . . . . . . . . 52 102 8.3. IPv6 Multicast . . . . . . . . . . . . . . . . . . . . . . 55 103 8.4. IPv6 QoS . . . . . . . . . . . . . . . . . . . . . . . . . 56 104 8.5. IPv6 Security Considerations . . . . . . . . . . . . . . . 56 105 8.6. IPv6 Network Management . . . . . . . . . . . . . . . . . 57 106 9. Wireless LAN . . . . . . . . . . . . . . . . . . . . . . . . . 58 107 9.1. WLAN Deployment Scenarios . . . . . . . . . . . . . . . . 58 108 9.1.1. Layer 2 NAP with Layer 3 termination at NSP Edge 109 Router . . . . . . . . . . . . . . . . . . . . . . . . 59 110 9.1.2. Layer 3 aware NAP with Layer 3 termination at 111 Access Router . . . . . . . . . . . . . . . . . . . . 62 112 9.1.3. PPP Based Model . . . . . . . . . . . . . . . . . . . 64 113 9.2. IPv6 Multicast . . . . . . . . . . . . . . . . . . . . . . 66 114 9.3. IPv6 QoS . . . . . . . . . . . . . . . . . . . . . . . . . 67 115 9.4. IPv6 Security Considerations . . . . . . . . . . . . . . . 68 116 9.5. IPv6 Network Management . . . . . . . . . . . . . . . . . 69 117 10. Broadband Power Line Communications (PLC) . . . . . . . . . . 69 118 10.1. PLC/BPL Access Network Elements . . . . . . . . . . . . . 70 119 10.2. Deploying IPv6 in IPv4 PLC/BPL . . . . . . . . . . . . . . 71 120 10.2.1. IPv6 Related Infrastructure Changes . . . . . . . . . 71 121 10.2.2. Addressing . . . . . . . . . . . . . . . . . . . . . . 71 122 10.2.3. Routing . . . . . . . . . . . . . . . . . . . . . . . 72 123 10.3. IPv6 Multicast . . . . . . . . . . . . . . . . . . . . . . 72 124 10.4. IPv6 QoS . . . . . . . . . . . . . . . . . . . . . . . . . 73 125 10.5. IPv6 Security Considerations . . . . . . . . . . . . . . . 73 126 10.6. IPv6 Network Management . . . . . . . . . . . . . . . . . 73 127 11. Gap Analysis . . . . . . . . . . . . . . . . . . . . . . . . . 73 128 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 76 129 13. Security Considerations . . . . . . . . . . . . . . . . . . . 76 130 14. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 76 131 15. References . . . . . . . . . . . . . . . . . . . . . . . . . . 76 132 15.1. Normative References . . . . . . . . . . . . . . . . . . . 76 133 15.2. Informative References . . . . . . . . . . . . . . . . . . 78 134 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 80 135 Intellectual Property and Copyright Statements . . . . . . . . . . 82 137 1. Introduction 139 With the exponential growth of the Internet and increasing number of 140 end users, SPs are looking for new ways to evolve their current 141 network architecture to meet the needs of Internet ready appliances, 142 new applications and services. IPv6 is designed to enable SPs to 143 meet these challenges and provide new services to their customers. 145 As the number of devices per BB user increase exponentially 146 worldwide, Cable, DSL, Ethernet to the Home, Wireless, PLC/BPL and 147 other always-on access technologies can benefit from the huge address 148 range [8] of IPv6. Other benefits of IPv6 include the capability to 149 enhance end-to-end security, mobile communications, and ease system 150 management burdens. Some examples include peer-to-peer communication 151 without NAT traversal problems, being able to access securely devices 152 at home from work, enhanced IP Mobility [23] and so on. 154 Therefore SPs are aggressively evaluating the capabilities of IPv6 to 155 meet these needs. Some countries have taken a lead role in this race 156 and moved from testing and evaluation to real deployments of IPv6 in 157 the BB arena. Japan is a prime example along with other countries 158 that are looking at moving towards large scale production deployments 159 of IPv6. 161 The SPs are deploying tunneling mechanisms to transport IPv6 over 162 their existing IPv4 networks as well as deploying native IPv6 where 163 possible. Native IPv6 should be preferred over tunneling mechanisms 164 as native IPv6 deployment option might be more scalable and provide 165 required service performance. Tunneling mechanisms should only be 166 used when native IPv6 deployment is not an option. 168 1.1. Common Terminology 170 CPE: Customer Premise Equipment 172 GWR: Gateway Router 174 ISP: Internet Service Provider 176 NAP: Network Access Provider 178 NSP: Network Service Provider 180 SP: Service Provider 182 2. IPv6 Based BB Services 184 At this point IPv6 based services are seen as a differentiator that 185 enables SPs to take advantage of the large IPv6 address space to the 186 extent that subscribers get up to fixed /48 prefixes versus the 187 single, temporary IPv4 addresses. Such resources allow the SPs to 188 better position themselves against the competition. The IPv6 189 deployments can be seen as a driver for lower service support costs 190 by eliminating NAT with its negative impact on applications and its 191 complex behavior. Another reason of IPv6 being popular in some 192 countries might be the government driven financial incentives and 193 favorable legislation towards the ISPs who are deploying IPv6. 195 NTT East, Japan started a commercial dual-stack (devices capable of 196 forwarding IPv4 and IPv6 packets) IPv6 unicast service option early 197 this year for its ADSL and FTTH subscribers, under the name of 198 FLETS.Net. For these users the IPv6 addresses are dedicated (/64 per 199 user) and are used when needed. However, this IPv6 service is 200 available only to the NTT-East ADSL and FTTH subscribers who are part 201 of FLETS.NET network and at this point does not provide connectivity 202 to the IPv6 Internet. 204 Some ISPs that are currently providing IPv4 based Multicast and VoIP 205 services are evaluating IPv6 to improve and expand their service. 206 The Multicast services consist of video and audio streaming of 207 several programs (streams). The content provider delivers these 208 streams to BB subscribers. One of today's challenges is the fact 209 that when done through IPv4, there is generally a single device 210 directly attached to the CPE that receives the Multicast stream. By 211 moving to IPv6, ISP should be capable to provide multiple streams to 212 multiple devices on the customer site. 214 For instance in Japan, Cable TV and dish services are not very 215 popular, the users expect content mostly through the broadcasted, 216 free programs (traditional TV). In case of BB users however, they 217 can get additional content through their SP, which can be delivered 218 at a reasonable priced for 20 Mbps or 10/100 Mbps of bandwidth. 219 Users sign up with a content provider that is multicasting several 220 channels of video and audio. A subscriber would join the multicast 221 group of interest (after authentication) and will start receiving the 222 stream(s). An example of a video stream could be Disney movies and 223 an example of an audio stream could be Karaoke (part of same *,G 224 group). Similar to Cable TV, where customers sign up and pay for 225 single programs or packages of programs. 227 SPs are also offering IPv6 services over wireless links using 802.11 228 compliant WiFi Hot Spots. This enables users to take notebook PCs 229 and PDAs (Windows 2003 supports IPv6 capable Internet Explorer and 230 Media Player 9) along with them and connect to the Internet from 231 various locations without the restriction of staying indoors. 233 3. Scope of the Document 235 This document presents the options available in deploying IPv6 236 services in the access portion of a BB Service Provider network 237 namely Cable/HFC, BB Ethernet, xDSL, WLAN and PLC/BPL. 239 This document briefly discusses the other elements of a provider 240 network as well. It provides different viable IPv6 deployment and 241 integration techniques and models for each of the above mentioned BB 242 technologies individually. The example list is not exhaustive but it 243 tries to be representative. 245 This document analyzes, how all the important parts of current IPv4 246 based Cable/HFC, BB Ethernet, xDSL, WLAN and PLC/BPL networks will 247 behave when IPv6 is integrated and deployed. 249 The following important pieces are discussed: 251 A. Available tunneling options 253 B. Devices that would require to be upgraded to support IPv6 255 C. Available IPv6 address assignment techniques and their use 257 D. Possible IPv6 Routing options and their use 259 E. IPv6 unicast and multicast packet transmission 261 F. Required IPv6 QoS parameters 263 G. Required IPv6 Security parameters 265 H. Required IPv6 Network Management parameters 267 It is important to note that the addressing rules provided throughout 268 this document represent an example that follows the current 269 assignment policies and recommendations of the registries. They can 270 be however adapted to the network and business model needs of the 271 ISPs. 273 The scope of the document is to advise on the ways of upgrading an 274 existing infrastructure to support IPv6 services. The recommendation 275 to upgrade a device to dual-stack does not stop an SP from adding a 276 new device to its network to perform the necessary IPv6 functions 277 discussed. The costs involved could be offset by lower impact on the 278 existing IPv4 services. 280 4. Core/Backbone Network 282 This section intends to briefly discuss some important elements of a 283 provider network tied to the deployment of IPv6. A more detailed 284 description of the core network is provided in other documents [24]. 286 There are two networks identified in the Broadband deployments: 288 A. Access Provider Network: This network provides the broadband 289 access and aggregates the subscribers. The subscriber traffic is 290 handed over to the Service Provider at Layer 2 or 3. 292 B. Service Provider Network: This network provides Intranet and 293 Internet IP connectivity for the subscribers. 295 The Service Provider network structure beyond the Edge routers that 296 interface with the Access provider is beyond the scope of this 297 document. 299 4.1. Layer 2 Access Provider Network 301 The Access Provider can deploy a Layer 2 network and perform no 302 routing of the subscriber traffic to the SP. The devices that 303 support each specific access technology are aggregated into a highly 304 redundant, resilient and scalable layer two core. The network core 305 can involve various technologies such as Ethernet, ATM etc. The 306 Service Provider Edge Router connects to the Access Provider core. 308 In this type of a network the impact of deploying IPv6 is minimal. 309 The network is transparent to the Layer 3 protocol. The only 310 possible changes would come with the intent of filtering and 311 monitoring IPv6 traffic based on layer 2 information such as IPv6 312 Ether Type Protocol ID (0x86DD) or IPv6 multicast specific MAC 313 addresses (3333.xxxx.xxxx). 315 4.2. Layer 3 Access Provider Network 317 The Access Provider can choose to terminate the Layer 2 domain and 318 route the IP traffic to the Service Provider network. Access Routers 319 are used to aggregate the subscriber traffic and route it over a 320 Layer 3 core to the SP Edge Routers. In this case the impact of the 321 IPv6 deployment is significant. 323 The case studies in this document only present the significant 324 network elements of such a network: Customer Premise Equipment, 325 Access Router and Edge Router. In real networks the link between the 326 Access Router and the Edge Router involves other routers that are 327 part of the aggregation and the core layer of the Access Provider 328 network. 330 The Access Provider can forward the IPv6 traffic through its layer 3 331 core in three possible ways: 333 A. IPv6 Tunneling: As a temporary solution, the Access Providers can 334 choose to use a tunneling mechanism to forward the subscriber IPv6 335 traffic to the Service Provider Edge Router. This approach has the 336 least impact on the Access Provider network however, as the number of 337 users increase and the amount of IPv6 traffic grows, the ISP will 338 have to evolve to one of the scenarios listed below. 340 B. Native IPv6 Deployment: The Access Provider routers are upgraded 341 to support IPv6 and can become dual-stack. In a dual-stack network 342 an IPv6 IGP such as OSPFv3 or IS-IS is enabled. [24] discusses the 343 IGP selection options with their benefits and drawbacks. 345 C. MPLS 6PE Deployment [25]: If the Access Provider is running MPLS 346 in its IPv4 core it could use 6PE to forward IPv6 traffic over it. 347 In this case only a subset of routers close to the edge of the 348 network need to be IPv6 aware. With this approach BGP becomes 349 important in order to support 6PE. 351 The 6PE approach has the advantage of having minimal impact on the 352 Access Provider network. Fewer devices need to be upgraded and 353 configured while the MPLS core continues to switch the traffic un- 354 aware of the fact that it transports both IPv4 and IPv6 traffic. 6PE 355 should be leveraged only if MPLS is already deployed in the network. 356 At the time of writing this document, a major disadvantage of the 6PE 357 solution is the fact that it does not support multicast IPv6 traffic. 359 The native approach has the advantage of supporting IPv6 multicast 360 traffic but it may imply a significant impact on the IPv4 operational 361 network from software, configuration and possibly hardware upgrade 362 perspective. 364 More detailed Core Network deployment recommendations are discussed 365 in other documents [24]. The handling of IPv6 traffic in the Core of 366 the Access Provider Network will not be discussed for the remainder 367 of this document. 369 5. Tunneling Overview 371 If SPs are not able to deploy native IPv6, they might use tunneling 372 based transition mechanisms to start an IPv6 service offering and 373 move to native IPv6 deployment at a later time. 375 Several tunneling mechanisms were developed specifically to transport 376 IPv6 over existing IPv4 infrastructures. Several of them have been 377 standardized and their use depends on the existing SP IPv4 network 378 and the structure of the IPv6 service. The requirements for the most 379 appropriate mechanisms are described in [34] with more updates to 380 follow. Deploying IPv6 using tunneling techniques can imply as 381 little changes to the network as upgrading SW on tunnel end points 382 (TEP). A Service Provider could use tunneling to deploy IPv6 in the 383 following scenarios: 385 5.1. Access over Tunnels - Customers with Public IPv4 Address 387 If the customer is a residential user, it can initiate the tunnel 388 directly from the IPv6 capable host to a tunnel termination router 389 located in the NAP or ISP network. The tunnel type used should be 390 decided by the SP but it should take into consideration its 391 availability on commonly used software running on the host machine. 392 Out of the many tunneling mechanisms developed [2], [3], [4], [26], 393 [29], [5] some are more popular than the others. 395 If the end customer has a GWR installed, then it could be used to 396 originate the tunnel and thus offer native IPv6 access to multiple 397 hosts on the customer network. In this case the GWR would need to be 398 upgraded to dual-stack in order to support IPv6. The GWR can be 399 owned by the customer or by the SP 401 5.2. Access over Tunnels - Customers with Private IPv4 Address 403 If the end customer receives a private IPv4 address and needs to 404 initiate a tunnel through NAT, techniques like 6to4 may not work 405 since they rely on public IPv4 address. In this case, unless the 406 existing GWRs support protocol-41-forwarding [28], the end user might 407 have to use tunnels that can operate through NATs (such as Teredo 408 tunnel [29]). Most GWRs support protocol-41-forwarding which means 409 that hosts can initiate the tunnels in which case the GWR is not 410 affected by the IPv6 service. 412 The customer has the option to initiate the tunnel from the device 413 (GWR) that performs the NAT functionality, similar to the GWR 414 scenario discussed in section 5.1. This will imply HW replacement or 415 SW upgrade and a native IPv6 environment behind the GWR. 417 It is important to note that the customers of a Service Provider can 418 choose to establish tunnels to publicly available and free tunnel 419 services. Even though the quality of such services might not be 420 high, they provide free IPv6 access. In designing their IPv6 421 services, the SPs should take into considerations such options 422 available to their potential customers. The IPv6 deployment should 423 support services (like multicast, VoIPv6 etc) and a level of quality 424 that would make the access through the SP worthwhile to potential 425 subscribers. 427 It is also worth observing that initiating an IPv6 tunnel over IPv4 428 through already established IPv4 IPSec sessions would provide a 429 certain level of security to the IPv6 traffic. 431 5.3. Transition a Portion of the IPv4 Infrastructure 433 Tunnels can be used to transport the IPv6 traffic across a defined 434 segment of the network. As an example, the customer might connect 435 natively to the Network Access Provider and a tunnel is used to 436 transit the traffic over IPv4 to the ISP. In this case the tunnel 437 choice depends on its capabilities (for example, whether it supports 438 multicast or not), routing protocols used (there are several types 439 that can transport layer 2 messages such as GRE, L2TPv3 or 440 Pseudowire), manage-ability and scalability (dynamic versus static 441 tunnels). 443 This scenario implies that the access portion of the network has been 444 upgraded to support dual stack so the savings provided by tunneling 445 in this scenario are very small compared with the previous two 446 scenarios. Depending on the number of sites requiring the service 447 and considering the expenses required to manage the tunnels (some 448 tunnels are static while others are dynamic [27]) in this case, the 449 SPs might find the native approach worth the additional investments. 451 In all the scenarios listed above the tunnel selection process should 452 consider the IPv6 multicast forwarding capabilities if such service 453 is planned. As an example, 6to4 tunnels do not support IPv6 454 multicast traffic. 456 The operation, capabilities and deployment of various tunnel types 457 has been discussed extensively in the documents referenced earlier as 458 well as in [29], [6]. Details of a tunnel based deployment are 459 offered in the next section of this document (section 6). In the 460 case of Cable Access where the current DOCSIS specifications do not 461 provide support for native IPv6 access. Although sections 7, 8, 9 462 and 10 focus on a native IPv6 deployments over DSL, FTTH, Wireless 463 and PLC/BPL because this approach is fully supported today, tunnel 464 based solutions are also possible in these cases based on the 465 guidelines of this section and some of the recommendations provided 466 in section 6. 468 6. Broadband Cable Networks 470 This section describes the infrastructure that exists today in cable 471 networks providing BB services to the home. It also describes IPv6 472 deployment options in these cable networks. 474 DOCSIS standardizes and documents the operation of data over Cable 475 Networks. The current version of DOCSIS has limitations that do not 476 allow for a smooth implementation of native IPv6 transport. Some of 477 these limitations are discussed in this section. For this reason, 478 the IPv6 deployment scenarios discussed in this section for the 479 existent Cable Networks are tunnel based. The tunneling examples 480 presented here could also be applied to the other BB technologies 481 described in sections 7, 8, 9 and 10. 483 6.1. Broadband Cable Network Elements 485 Broadband cable networks are capable of transporting IP traffic to/ 486 from users to provide high speed Internet access and VOIP services. 487 The mechanism of transporting IP traffic over cable networks is 488 outlined in the DOCSIS specification [32]. 490 Here are some of the key elements of a Cable network: 492 Cable (HFC) Plant: Hybrid Fiber Coaxial plant, used as the underlying 493 transport 495 CMTS: Cable Modem Termination System (can be a Layer 2 bridging or 496 Layer 3 routing CMTS) 498 GWR: Residential Gateway Router (provides Layer 3 services to hosts) 500 Host: PC, notebook etc. which is connected to the CM or GWR 502 CM: Cable Modem 504 ER: Edge Router 506 MSO: Multiple Service Operator 508 Data Over Cable Service Interface Specification (DOCSIS): The 509 standards defining how data should be carried over cable networks. 511 Figure 6.1 illustrates the key elements of a Cable Network 513 |--- ACCESS ---||------ HFC ------||----- Aggregation / Core -----| 515 +-----+ +------+ 516 |Host |--| GWR | 517 +-----+ +--+---+ 518 | _ _ _ _ _ _ 519 +------+ | | 520 | CM |---| | 521 +------+ | | 522 | HFC | +------+ +--------+ 523 | | | | | Edge | 524 +-----+ +------+ | Network |---| CMTS |---| |=>ISP 525 |Host |--| CM |---| | | | | Router | Network 526 +-----+ +--+---+ | | +------+ +--------+ 527 |_ _ _ _ _ _| 528 +------+ | 529 +-----+ | GWR/ | | 530 |Host |--| CM |---------+ 531 +-----+ | | 532 +------+ Figure 6.1 534 6.2. Deploying IPv6 in Cable Networks 536 One of the motivators for an MSO to deploy IPv6 over their Cable 537 Network is to ease management burdens. IPv6 can be enabled on the 538 CM, CMTS and ER for management purposes. Currently portions of the 539 cable infrastructure use [1] IPv4 addresses; however, there are a 540 finite number of those. Thus, IPv6 could have utility in the cable 541 space implemented on the management plane initially and later on 542 focused on the data plane for end user services. For more details on 543 using IPv6 for management in Cable Networks please refer to section 544 6.6.1. 546 There are two different deployment modes in current cable networks: a 547 bridged CMTS environment and a routed CMTS environment. IPv6 can be 548 deployed in both of these environments. 550 1. Bridged CMTS Network 552 In this scenario, both the CM and CMTS bridge all data traffic. 553 Traffic to/from host devices is forwarded through the cable network 554 to the ER. The ER then routes traffic through the ISP network to the 555 Internet. The CM and CMTS support a certain degree of Layer 3 556 functionality for management purposes. 558 2. Routed CMTS Network 560 In a routed network, the CMTS forwards IP traffic to/from hosts based 561 on Layer 3 information using the IP source/destination address. The 562 CM acts as a Layer-2 bridge for forwarding data traffic and supports 563 some Layer 3 functionality for management purposes. 565 Some of the factors that hinder deployment of native IPv6 in current 566 routed and bridged cable networks include: 568 A. Problems with IPv6 Neighbor Discovery (ND) on CM and CMTS. These 569 devices rely on IGMP join messages to track membership of hosts that 570 are part of a particular IP Multicast group. In order to support ND 571 the CM and CMTS will need to support IGMPv3/MLDv2 or v1 snooping. 573 B. Classification of IPv6 traffic in the upstream and downstream 574 direction. The CM and CMTS will need to support classification of 575 IPv6 packets in order to give them the appropriate priority and QoS. 576 Without proper classification all IPv6 traffic will need to be sent 577 best effort (BE) which can cause problems when deploying services 578 like VOIP and IP Multicast video. 580 C. Changes need to be made to the DOCSIS specification to include 581 support for IPv6 on the CM and CMTS. This is imperative for 582 deploying native IPv6 over cable networks. 584 Due to the above mentioned limitations in deployed cable networks, 585 the only available option to cable operators is to use tunneling 586 techniques in order to transport IPv6 traffic over their current IPv4 587 infrastructure. The following sections will cover these deployment 588 scenarios in more detail. 590 6.2.1. Deploying IPv6 in a Bridged CMTS Network 592 In IPv4 the CM and CMTS act as Layer 2 bridges and forward all data 593 traffic to/from the hosts and the ER. The hosts use the ER as their 594 Layer 3 next hop. If there is a GWR behind the CM it can act as a 595 next hop for all hosts and forward data traffic to/from the ER. 597 When deploying IPv6 in this environment, the CM and CMTS will 598 continue to be bridging devices in order to keep the transition 599 smooth and reduce operational complexity. The CM and CMTS will need 600 to bridge IPv6 unicast and multicast packets to/from the ER and the 601 hosts. If there is a GWR connected to the CM, it will need to 602 forward IPv6 unicast and multicast traffic to/from the ER. 604 IPv6 can be deployed in a bridged CMTS network either natively or via 605 tunneling. This section discusses the native deployment model. The 606 tunneling model is similar to ones described in sections 6.2.2.1 and 607 6.2.2.2. 609 Figure 6.2.1 illustrate the IPv6 deployment scenario 611 +-----+ +-----+ 612 |Host |--| GWR | 613 +-----+ +--+--+ 614 | _ _ _ _ _ _ 615 | +------+ | | 616 +--| CM |---| | 617 +------+ | | 618 | HFC | +------+ +--------+ 619 | | | | | Edge | 620 +-----+ +------+ | Network |---| CMTS |--| |=>ISP 621 |Host |--| CM |---| | | | | Router |Network 622 +-----+ +------+ | | +------+ +--------+ 623 |_ _ _ _ _ _| 624 |-------------||---------------------------------||---------------| 625 L3 Routed L2 Bridged L3 Routed 627 Figure 6.2.1 629 6.2.1.1. IPv6 Related Infrastructure Changes 631 In this scenario the CM and the CMTS bridge all data traffic so they 632 will need to support bridging of native IPv6 unicast and multicast 633 traffic. The following devices have to be upgraded to dual stack: 634 Host, GWR and ER. 636 6.2.1.2. Addressing 638 The proposed architecture for IPv6 deployment includes two components 639 that must be provisioned: the CM and the host. Additionally if there 640 is a GWR connected to the CM, it will also need to be provisioned. 641 The host or the GWR use the ER as their Layer 3 next hop. 643 6.2.1.2.1. IP Addressing for CM 645 The CM will be provisioned in the same way as in currently deployed 646 cable networks, using an IPv4 address on the cable interface 647 connected to the MSO network for management functions. During the 648 initialization phase, it will obtain its IPv4 address using DHCPv4, 649 and download a DOCSIS configuration file identified by the DHCPv4 650 server. 652 6.2.1.2.2. IP Addressing for Hosts 654 If there is no GWR connected to the CM, the host behind the CM will 655 get a /64 prefix assigned to it via stateless auto-configuration or 656 DHCPv6. 658 If using stateless auto-configuration, the host listens for routing 659 advertisements (RA) from the ER. The RAs contain the /64 prefix 660 assigned to the segment. Upon receipt of an RA, the host constructs 661 its IPv6 address by combining the prefix in the RA (/64) and a unique 662 identifier (e.g., its modified EUI-64 format interface ID). 664 If DHCPv6 is used to obtain an IPv6 address, it will work in much the 665 same way as DHCPv4 works today. The DHCPv6 messages exchanged 666 between the host and the DHCPv6 server are bridged by the CM and the 667 CMTS. 669 6.2.1.2.3. IP Addressing for GWR 671 The GWR can use stateless auto-configuration (RA) to obtain an 672 address for its upstream interface, the link between itself and the 673 ER. This step is followed by a request via DHCP-PD (Prefix 674 Delegation) for a prefix shorter than /64, typically /48 [7], which 675 in turn is divided into /64s and assigned to its downstream 676 interfaces connecting to the hosts. 678 6.2.1.3. Data Forwarding 680 The CM and CMTS must be able to bridge native IPv6 unicast and 681 multicast traffic. The CMTS must provide IP connectivity between 682 hosts attached to CMs and must do so in a way that meets the 683 expectation of Ethernet attached customer equipment. In order to do 684 that, the CM and CMTS must forward Neighbor Discovery (ND) packets 685 between ER and the hosts attached to the CM. 687 Communication between hosts behind different CMs is always forwarded 688 through the CMTS. IPv6 communication between the different sites 689 relies on multicast IPv6 ND [17] frames being forwarded correctly by 690 the CM and the CMTS. As with the CM, a bridged CMTS that selectively 691 forwards multicast datagrams on the basis of MLD will potentially 692 break IPv6 ND. 694 In order to support IPv6 multicast applications across DOCSIS cable 695 networks, the CM and bridging CMTS need to support IGMPv3/MLDv2 or v1 696 snooping. MLD is almost identical to IGMP in IPv4, only the name and 697 numbers are changed. MLDv2 is identical to IGMPv3 and also supports 698 ASM (Any Source Multicast) and SSM (Single Source Multicast) service 699 models. Implementation work on CM/CMTS should be minimal because the 700 only significant difference between IPv4 IGMPv3 and IPv6 MLDv2 is the 701 longer addresses in the protocol. 703 6.2.1.4. Routing 705 The hosts install a default route that points to the ER or the GWR. 706 No routing protocols are needed on these devices which generally have 707 limited resources. If there is a GWR present it will also use static 708 default route to the ER. 710 The ER runs an IGP such as OSPFv3 or IS-IS. The connected prefixes 711 have to be redistributed. If DHCP-PD is used, with every delegated 712 prefix a static route is installed by the ER. For this reason the 713 static routes must also be redistributed. Prefix summarization 714 should be done at the ER. 716 6.2.2. Deploying IPv6 in a Routed CMTS Network 718 In an IPv4 routed CMTS network the CM still acts as a Layer-2 device 719 and bridges all data traffic between its Ethernet interface and cable 720 interface connected to the cable operator network. The CMTS acts as 721 a Layer 3 router and may also include the ER functionality. The 722 hosts and the GWR use the CMTS as their Layer 3 next hop. 724 When deploying IPv6 in a routed CMTS network, the CM still acts as a 725 Layer-2 device and will need to bridge IPv6 unicast as well as 726 multicast traffic. The CMTS/ER will need to either tunnel IPv6 727 traffic or natively support IPv6. The host and GWR will use the 728 CMTS/ER as their Layer 3 next hop. 730 There could be five possible deployment scenarios for IPv6 in a 731 routed CMTS network: 733 1. IPv4 Cable (HFC) Network 735 In this scenario the cable network, including the CM and CMTS remain 736 IPv4 devices. The host and ER are upgraded to dual-stack. This is 737 the easiest way for a Cable Operator to provide IPv6 service as no 738 changes are made to the cable network. 740 2. IPv4 Cable (HFC) Network, GWR at Customer Site 742 In this case the cable network, including the CM and CMTS remain IPv4 743 devices. The host, GWR and ER are upgraded to dual-stack. This 744 scenario is also easy to deploy since the cable operator just needs 745 to add GWR at the customer site. 747 3. Dual-stacked Cable (HFC) Network, CM and CMTS Support IPv6 749 In this scenario the CMTS is upgraded to dual-stack to support IPv4 750 and IPv6. Since the CMTS supports IPv6 it can acts as an ER as well. 751 The CM will act as a Layer-2 bridge but will need to bridge IPv6 752 unicast and multicast traffic. This scenario is not easy to deploy 753 since it requires changes to the DOCSIS specification. The CM and 754 CMTS may require HW and SW upgrades to support IPv6. 756 4. Dual-stacked Cable (HFC) Network, Standalone GWR and CMTS Support 757 IPv6 759 In this scenario there is a standalone GWR connected to the CM. 760 Since the IPv6 functionality exists on the GWR the CM does not need 761 to be dual-stack. The CMTS is upgraded to dual-stack and it can 762 incorporate the ER functionality. This scenario may also require HW 763 and SW changes on the GWR and CMTS. 765 5. Dual-stacked Cable (HFC) Network, Embedded GWR/CM and CMTS 766 Support IPv6 768 In this scenario the CM and GWR functionality exists on a single 769 device which needs to be upgraded to dual-stack. The CMTS will also 770 need to be upgraded to a dual-stack device. This scenario is also 771 difficult to deploy in existent cable network since it requires 772 changes on the Embedded GWR/CM and the CMTS. 774 The DOCSIS specification will also need to be modified to allow 775 native IPv6 support on the Embedded GWR/CM. 777 6.2.2.1. IPv4 Cable Network, Host and ER Upgraded to Dual-Stack 779 This is one of the most cost effective ways for a Cable Operator to 780 offer IPv6 services to its customers. Since the cable network 781 remains IPv4 there is relatively minimal cost involved in turning up 782 IPv6 service. All IPv6 traffic is exchanged between the hosts and 783 the ER. 785 Figure 6.2.2.1 illustrates this deployment scenario 787 +-----------+ +------+ +--------+ 788 +-----+ +-------+ | Cable | | | | Edge | 789 |Host |--| CM |----| (HFC) |---| CMTS |---| |=>ISP 790 +-----+ +-------+ | Network | | | | Router |Network 791 +-----------+ +------+ +--------+ 792 _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ 793 ()_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _() 794 IPv6-in-IPv4 tunnel 796 |---------||---------------------------------------||------------| 797 IPv4/v6 IPv4 only IPv4/v6 799 Figure 6.2.2.1 801 6.2.2.1.1. IPv6 Related Infrastructure Changes 803 In this scenario the CM and the CMTS will only need to support IPv4 804 so no changes need to be made to them or the cable network. The 805 following devices have to be upgraded to dual stack: Host and ER. 807 6.2.2.1.2. Addressing 809 The only device that needs to be assigned an IPv6 address at customer 810 site is the host. Host address assignment can be done in multiple 811 ways. Depending on the tunneling mechanism used it could be 812 automatic or might require manual configuration. 814 The host still receives an IPv4 address using DHCPv4, which works the 815 same way in currently deployed cable networks. In order to get IPv6 816 connectivity, host devices will also need an IPv6 address and a means 817 to communicate with the ER. 819 6.2.2.1.3. Data Forwarding 821 All IPv6 traffic will be sent to/from the ER and the host device. In 822 order to transport IPv6 packets over the cable operator IPv4 network, 823 the host and the ER will need to use one of the available IPv6 in 824 IPv4 tunneling mechanisms. 826 The host will use its IPv4 address to source the tunnel to the ER. 827 All IPv6 traffic will be forwarded to the ER, encapsulated in IPv4 828 packets. The intermediate IPv4 nodes will forward this traffic as 829 regular IPv4 packets. The ER will need to terminate the tunnel 830 and/or provide other IPv6 services. 832 6.2.2.1.4. Routing 834 Routing configuration on the host will vary depending on the 835 tunneling technique used, in some cases a default or static route 836 might be needed to forward traffic to the next hop. 838 The ER runs an IGP such as OSPFv3 or ISIS. 840 6.2.2.2. IPv4 Cable Network, Host, GWR and ER Upgraded to Dual-Stack 842 The cable operator can provide IPv6 services to its customers, in 843 this scenario, by adding a GWR behind the CM. Since the GWR will 844 facilitate all IPv6 traffic to/from the host and the ER, the cable 845 network including the CM and CMTS do not need to support IPv6 and can 846 remain as IPv4 devices. 848 Figure 6.2.2.2 illustrates this deployment scenario 850 +-----+ 851 |Host | 852 +--+--+ 853 | +-----------+ +------+ +--------+ 854 +---+---+ +-------+ | Cable | | | | Edge | 855 | GWR |--| CM |----| (HFC) |---| CMTS |---| |=>ISP 856 +-------+ +-------+ | Network | | | | Router |Network 857 +-----------+ +------+ +--------+ 858 _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ 859 ()_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _() 860 IPv6-in-IPv4 tunnel 862 |---------||--------------------------------------||-------------| 863 IPv4/v6 IPv4 only IPv4/v6 865 Figure 6.2.2.2 867 6.2.2.2.1. IPv6 Related Infrastructure Changes 869 In this scenario the CM and the CMTS will only need to support IPv4 870 so no changes need to be made to them or the cable network. The 871 following devices have to be upgraded to dual stack: Host, GWR and 872 ER. 874 6.2.2.2.2. Addressing 876 The only devices that needs to be assigned an IPv6 address at 877 customer site are the host and GWR. IPv6 address assignment can be 878 done statically at the GWR downstream interface. The GWR will send 879 out RA messages on its downstream interface which will be used by the 880 hosts to auto-configure themselves with an IPv6 address. The GWR can 881 also configure its upstream interface using RA messages from the ER 882 and use DHCP-PD for requesting a /48 [7] prefix from the ER. This 883 /48 prefix will be used to configure /64s on hosts connected to the 884 GWR downstream interfaces. Currently the DHCP-PD functionality 885 cannot be implemented if the DHCP-PD server is not the Edge Router. 886 If the DHCP-PD messages are relayed, the Edge Router does not have a 887 mechanism to learn the assigned prefixes and thus install the proper 888 routes to make that prefix reachable. Work is being done to address 889 this issue, one idea being to provide the Edge Router with a snooping 890 mechanism. The uplink to the ISP network is configured with a /64 891 prefix as well. 893 The GWR still receives a global IPv4 address on its upstream 894 interface using DHCPv4, which works the same way in currently 895 deployed cable networks. In order to get IPv6 connectivity to the 896 Internet the GWR will need to communicate with the ER. 898 6.2.2.2.3. Data Forwarding 900 All IPv6 traffic will be sent to/from the ER and the GWR, which will 901 forward IPv6 traffic to/from the host. In order to transport IPv6 902 packets over the cable operator IPv4 network, the GWR and the ER will 903 need to use one of the available IPv6 in IPv4 tunneling mechanisms. 904 All IPv6 traffic will need to go through the tunnel, once it comes 905 up. 907 The GWR will use its IPv4 address to source the tunnel to the ER. 908 The tunnel endpoint will be the IPv4 address of the ER. All IPv6 909 traffic will be forwarded to the ER, encapsulated in IPv4 packets. 910 The intermediate IPv4 nodes will forward this traffic as regular IPv4 911 packets. In case of 6to4 tunneling, the ER will need to support 6to4 912 relay functionality in order to provide IPv6 Internet connectivity to 913 the GWR and hence the hosts connected to the GWR. 915 6.2.2.2.4. Routing 917 Depending on the tunneling technique used there might some 918 configuration needed on the GWR and the ER. If the ER is also 919 providing a 6to4 relay service then a default route will need to be 920 added to the GWR pointing to the ER, for all non-6to4 traffic. 922 If using manual tunneling, the GWR and ER can use static routing or 923 they can also configure RIPng. The RIPng updates can be transported 924 over a manual tunnel, which does not work when using 6to4 tunneling. 926 Customer routes can be carried to the ER using RIPng updates. The ER 927 can advertise these routes in its IGP. Prefix summarization should 928 be done at the ER. 930 If DHCP-PD is used for address assignment a static route is 931 automatically installed on the CMTS/ER for each delegated /48 prefix. 932 The static routes need to be redistributed into the IGP at the 933 CMTS/ER, so there is no need for a routing protocol between the 934 CMTS/ER and the GWR. 936 The ER runs an IGP such as OSPFv3 or ISIS. 938 6.2.2.3. Dual-stacked Cable (HFC) Network, CM and CMTS Support IPv6 940 In this scenario the Cable Operator can offer native IPv6 services to 941 its customers since the cable network including the CMTS supports 942 IPv6. The ER functionality can be included in the CMTS or it can 943 exist on a separate router connected to the CMTS upstream interface. 944 The CM will need to bridge IPv6 unicast and multicast traffic. 946 Figure 6.2.2.3 illustrates this deployment scenario 948 +-----------+ +-------------+ 949 +-----+ +-------+ | Cable | | CMTS / Edge | 950 |Host |--| CM |----| (HFC) |---| |=>ISP 951 +-----+ +-------+ | Network | | Router | Network 952 +-----------+ +-------------+ 954 |-------||---------------------------||---------------| 955 IPv4/v6 IPv4/v6 IPv4/v6 957 Figure 6.2.2.3 959 6.2.2.3.1. IPv6 Related Infrastructure Changes 961 Since the CM still acts as a Layer-2 bridge, it does not need to be 962 dual-stack. The CM will need to support bridging of IPv6 unicast and 963 multicast traffic and IGMPv3/MLDv2 or v1 snooping which requires 964 changes in the DOCSIS specification. In this scenario the following 965 devices have to be upgraded to dual stack: Host and CMTS/ER. 967 6.2.2.3.2. Addressing 969 In today's cable networks the CM receives a private IPv4 address 970 using DHCPv4 for management purposes. In an IPv6 environment, the CM 971 will continue to use an IPv4 address for management purposes. The 972 cable operator can also choose to assign an IPv6 address to the CM 973 for management, but the CM will have to be upgraded to support this 974 functionality. 976 IPv6 address assignment for the CM and host can be done via DHCP or 977 stateless auto-configuration. If the CM uses an IPv4 address for 978 management, it will use DHCPv4 for its address assignment and the 979 CMTS will need to act as a DHCPv4 relay agent. If the CM uses an 980 IPv6 address for management, it can use DHCPv6 with the CMTS acting 981 as a DHCPv6 relay agent or the CMTS can be statically configured with 982 a /64 prefix and it can send out RA messages out the cable interface. 983 The CMs connected to the cable interface can use the RA messages to 984 auto-configure themselves with an IPv6 address. All CMs connected to 985 the cable interface will be in the same subnet. 987 The hosts can receive their IPv6 address via DHCPv6 or stateless 988 auto-configuration. With DHCPv6, the CMTS may need to act as a 989 DHCPv6 relay agent and forward DHCP messages between the hosts and 990 the DHCP server. With stateless auto-configuration, the CMTS will be 991 configured with multiple /64 prefixes and send out RA messages to the 992 hosts. If the CMTS is not also acting as an ER, the RA messages will 993 come from the ER connected to the CMTS upstream interface. The CMTS 994 will need to forward the RA messages downstream or act as an ND 995 proxy. 997 6.2.2.3.3. Data Forwarding 999 All IPv6 traffic will be sent to/from the CMTS and hosts. Data 1000 forwarding will work the same way it works in currently deployed 1001 cable networks. The CMTS will forward IPv6 traffic to/from hosts 1002 based on the IP source/destination address. 1004 6.2.2.3.4. Routing 1006 No routing protocols are needed between the CMTS and the host since 1007 the CM and host are directly connected to the CMTS cable interface. 1008 Since the CMTS supports IPv6, hosts will use the CMTS as their Layer 1009 3 next hop. 1011 If the CMTS is also acting as an ER, it runs an IGP such as OSPFv3 or 1012 ISIS. 1014 6.2.2.4. Dual-Stacked Cable (HFC) Network, Standalone GWR and CMTS 1015 Support IPv6 1017 In this case the cable operator can offer IPv6 services to its 1018 customers by adding a GWR between the CM and the host. The GWR will 1019 facilitate IPv6 communication between the host and the CMTS/ER. The 1020 CMTS will be upgraded to dual-stack to support IPv6 and can acts as 1021 an ER as well. The CM will act as a bridge for forwarding data 1022 traffic and does not need to support IPv6. 1024 This scenario is similar to the case described in section 6.2.2.2. 1025 The only difference in this case is the ER functionality exists on 1026 the CMTS instead of a separate router in the cable operator network. 1028 Figure 6.2.2.4 illustrates this deployment scenario 1030 +-----------+ +-----------+ 1031 +------+ +-------+ +-------+ | Cable | |CMTS / Edge| 1032 | Host |--| GWR |--| CM |---| (HFC) |---| |=>ISP 1033 +------+ +-------+ +-------+ | Network | | Router |Network 1034 +-----------+ +-----------+ 1035 _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ 1036 ()_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _() 1037 IPv6-in-IPv4 tunnel 1038 |-----------------||-----------------------------||--------------| 1039 IPv4/v6 IPv4 IPv4/v6 1041 Figure 6.2.2.4 1043 6.2.2.4.1. IPv6 Related Infrastructure Changes 1045 Since the CM still acts as a Layer-2 bridge, it does not need to be 1046 dual-stack nor does it need to support IPv6. In this scenario the 1047 following devices have to be upgraded to dual stack: Host, GWR and 1048 CMTS/ER. 1050 6.2.2.4.2. Addressing 1052 The CM will still receive a private IPv4 address using DHCPv4 which 1053 works the same way in existent cable networks. The CMTS will act as 1054 DHCPv4 relay agent. 1056 The address assignment for the host and GWR happens in a similar 1057 manner as described in section 6.2.2.2.2. 1059 6.2.2.4.3. Data Forwarding 1061 Data forwarding between the host and CMTS/ER is facilitated by the 1062 GWR and happens in a similar manner as described in section 1063 6.2.2.2.3. 1065 6.2.2.4.4. Routing 1067 In this case routing is very similar to the case described in section 1068 6.2.2.2.4. Since the CMTS now incorporates the ER functionality, it 1069 will need to run an IGP such as OSPFv3 or ISIS. 1071 6.2.2.5. Dual-Stacked Cable (HFC) Network, Embedded GWR/CM and CMTS 1072 Support IPv6 1074 In this scenario the Cable Operator can offer native IPv6 services to 1075 its customers since the cable network including the CM/Embedded GWR 1076 and CMTS support IPv6. The ER functionality can be included in the 1077 CMTS or it can exist on a separate router connected to the CMTS 1078 upstream interface. The CM/Embedded GWR acts as a Layer 3 device. 1080 Figure 6.2.2.5 illustrates this deployment scenario 1082 +-----------+ +-------------+ 1083 +-----+ +-----------+ | Cable | | CMTS / Edge | 1084 |Host |---| CM / GWR |---| (HFC) |---| |=>ISP 1085 +-----+ +-----------+ | Network | | Router |Network 1086 +-----------+ +-------------+ 1088 |---------------------------------------------------------| 1089 IPv4/v6 1091 Figure 6.2.2.5 1093 6.2.2.5.1. IPv6 Related Infrastructure Changes 1095 Since the CM/GWR acts as a Layer 3 device, IPv6 can be deployed end- 1096 to-end. In this scenario the following devices have to be upgraded 1097 to dual-stack: Host, CM/GWR and CMTS/ER. 1099 6.2.2.5.2. Addressing 1101 Since the CM/GWR is dual-stack, it can receive an IPv4 or IPv6 1102 address using DHCP for management purposes. As the GWR functionality 1103 is Embedded in the CM, it will need an IPv6 address for forwarding 1104 data traffic. IPv6 address assignment for the CM/GWR and host can be 1105 done via DHCPv6 or DHCP-PD. 1107 If using DHCPv6 the CMTS will need to act as DHCPv6 relay agent. The 1108 host and CM/GWR will receive IPv6 addresses from pools of /64 1109 prefixes configured on the DHCPv6 server. The CMTS will need to 1110 glean pertinent information from the DHCP Offer messages, sent from 1111 the DHCP server to the DHCP clients (host and CM/GWR), much like it 1112 does today in DHCPv4. All CM/GWR connected to the same cable 1113 interface on the CMTS belong to same management /64 prefix. The 1114 hosts connected to the same cable interface on the CMTS may belong to 1115 different /64 customer prefixes as the CMTS may have multiple /64 1116 prefixes configured under its cable interfaces. 1118 It is also possible to use DHCP-PD for IPv6 address assignment. In 1119 this case the CM/GWR will use stateless auto-configuration to assign 1120 an IPv6 address to its upstream interface using the /64 prefix sent 1121 by the CMTS/ER in RA message. Once the CM/GWR assigns an IPv6 1122 address to its upstream interface it will request a /48 [7] prefix 1123 from the CMTS/ER and chop this /48 prefix into /64s for assigning 1124 IPv6 addresses to hosts. Currently the DHCP-PD functionality cannot 1125 be implemented if the DHCP-PD server is not the Edge Router. If the 1126 DHCP-PD messages are relayed, the Edge Router does not have a 1127 mechanism to learn the assigned prefixes and thus install the proper 1128 routes to make that prefix reachable. Work is being done to address 1129 this issue, one idea being to provide the Edge Router with a snooping 1130 mechanism. The uplink to the ISP network is configured with a /64 1131 prefix as well. 1133 6.2.2.5.3. Data Forwarding 1135 The host will use the CM/GWR as the Layer 3 next hop. The CM/GWR 1136 will forward all IPv6 traffic to/from the CMTS/ER and hosts. The 1137 CMTS/ER will forward IPv6 traffic to/from hosts based on the IP 1138 source/destination address. 1140 6.2.2.5.4. Routing 1142 The CM/GWR can use a static default route pointing to the CMTS/ER or 1143 it can run a routing protocol such as RIPng or OSPFv3 between itself 1144 and the CMTS. Customer routes from behind the CM/GWR can be carried 1145 to the CMTS using routing updates. 1147 If DHCP-PD is used for address assignment a static route is 1148 automatically installed on the CMTS/ER for each delegated /48 prefix. 1149 The static routes need to be redistributed into the IGP at the 1150 CMTS/ER so there is no need for a routing protocol between the 1151 CMTS/ER and the GWR. 1153 If the CMTS is also acting as an ER, it runs an IGP such as OSPFv3 or 1154 ISIS. 1156 6.2.3. IPv6 Multicast 1158 In order to support IPv6 multicast applications across DOCSIS cable 1159 networks, the CM and bridging CMTS will need to support IGMPv3/MLDv2 1160 or v1 snooping. MLD is almost identical to IGMP in IPv4, only the 1161 name and numbers are changed. MLDv2 is almost identical to IGMPv3 1162 and also supports ASM (Any Source Multicast) and SSM (Single Source 1163 Multicast) service models. 1165 SSM is more suited for deployments where the SP intends to provide 1166 paid content to the users (Video or Audio). This type of services 1167 are expected to be of primary interest. Moreover, the simplicity of 1168 the SSM model often times override the scalability issues that would 1169 be resolved in an ASM model. ASM is however an option that is 1170 discussed in section 7.3.1. The Layer 3 CM, GWR and Layer 3 routed 1171 CMTS/ER will need to be enabled with PIM-SSM, which requires the 1172 definition and support for IGMPv3/MLDv1 or v2 snooping, in order to 1173 track join/leave messages from the hosts. Another option would be 1174 for the Layer 3 CM or GWR to support MLD proxy routing. The Layer 3 1175 next hop for the hosts needs to support MLD. 1177 Please refer to section 7.3 for more IPv6 multicast details. 1179 6.2.4. IPv6 QoS 1181 IPv6 will not change or add any queuing/scheduling functionality 1182 already existing in DOCSIS specifications. But the QoS mechanisms on 1183 the CMTS and CM would need to be IPv6 capable. This includes support 1184 for IPv6 classifiers, so that data traffic to/from host devices can 1185 be classified appropriately into different service flows and be 1186 assigned appropriate priority. Appropriate classification criteria 1187 would need to be implemented for unicast and multicast traffic. 1189 In order to classify IPv6 traffic the following classifiers would 1190 need to be modified in the DOCSIS specification to support the 128- 1191 bit IPv6 address: 1193 A. IP source address 1195 B. IP source mask 1197 C. IP destination address 1199 D. IP destination mask 1201 E. IP traffic class (DSCP) 1203 The following classifiers would be new for IPv6: 1205 A. IP version 1207 B. Flow label (optional) 1209 Traffic classification and marking should be done at the CM for 1210 upstream traffic and the CMTS/ER for downstream traffic in order to 1211 support the various types of services: data, voice, video. The same 1212 IPv4 QoS concepts and methodologies should be applied for IPv6 as 1213 well. 1215 It is important to note that when traffic is encrypted end-to-end, 1216 the traversed network devices will not have access to many of the 1217 packet fields used for classification purposes. In these cases 1218 routers will most likely place the packets in the default classes. 1219 The QoS design should take into consideration this scenario and try 1220 to use mainly IP header fields for classification purposes. 1222 6.2.5. IPv6 Security Considerations 1224 Security in a DOCSIS cable network is provided using Baseline Privacy 1225 Plus (BPI+). The only part that is dependent on IP addresses is 1226 encrypted multicast. Semantically, multicast encryption would work 1227 the same way in an IPv6 environment as in the IPv4 network. However, 1228 appropriate enhancements will be needed in the DOCSIS specification 1229 to support encrypted IPv6 multicast. 1231 The other aspect of security enhancement is mandated IPSec support in 1232 IPv6. The IPv6 specifications mandate implementation of IPSec, but 1233 they do not mandate its use. The IPv4 specifications do not mandate 1234 IPSec. IPSec is the same for both IPv4 and IPv6, but it still 1235 requires a key distribution mechanism. Cable operators may consider 1236 deploying it end-to-end on IPv6 as there is not an intermediate 1237 device(i.e. NAT). 1239 There are limited changes that have to be done for hosts in order to 1240 enhance security. The Privacy extensions [13] for auto-configuration 1241 should be used by the hosts. IPv6 firewall functions could be 1242 enabled, if available on the host or GWR. 1244 The ISP provides security against attacks that come form its own 1245 subscribers but it could also implement security services that 1246 protect its subscribers from attacks sourced from the outside of its 1247 network. Such services do not apply at the access level of the 1248 network discussed here. 1250 The CMTS/ER should protect the ISP network and the other subscribers 1251 against attacks by one of its own customers. For this reason Unicast 1252 Reverse Path Forwarding (uRPF) [22] and ACLs should be used on all 1253 interfaces facing subscribers. Filtering should be implemented with 1254 regard for the operational requirements of IPv6 [Security 1255 considerations for IPv6]. 1257 The CMTS/ER should protect its processing resources against floods of 1258 valid customer control traffic such as: Router and Neighbor 1259 Solicitations, MLD Requests. 1261 All other security features used with the IPv4 service should be 1262 similarly applied to IPv6 as well. 1264 6.2.6. IPv6 Network Management 1266 IPv6 can have many applications in Cable Networks. MSOs can 1267 initially implement IPv6 on the control plane and use it to manage 1268 the thousands of devices connected to the CMTS. This would be a good 1269 way to introduce IPv6 in a Cable Network. Later on the MSO can 1270 extend IPv6 to the data plane and use it to carry customer as well as 1271 management traffic. 1273 6.2.6.1. Using IPv6 for Management in Cable Networks 1275 IPv6 can be enabled in a Cable Network for management of devices like 1276 CM, CMTS and ER. With the roll out of advanced services like VoIP 1277 and Video-over-IP, MSOs are looking for ways to manage the large 1278 number of devices connected to the CMTS. In IPv4, an RFC1918 address 1279 is assigned to these devices like CM for management purposes. Since 1280 there is a finite number of RFC1918 addresses available, it is 1281 becoming difficult for MSOs to manage these devices. 1283 By using IPv6 for management purposes, MSOs can scale their network 1284 management systems to meet their needs. The CMTS/ER can be 1285 configured with a /64 management prefix which is shared among all CMs 1286 connected to the CMTS cable interface. Addressing for the CMs can be 1287 done via stateless auto-configuration. Once the CMs receive the /64 1288 prefix from the CMTS/ER via RA they can configure themselves with an 1289 IPv6 address. 1291 If there are devices behind the CM which need to be managed by the 1292 MSO, another /64 prefix can be defined on the CMTS/ER. These devices 1293 can also use stateless auto-configuration to assign themselves an 1294 IPv6 address. 1296 Traffic sourced from or destined to the management prefix should not 1297 cross the MSO's network boundaries. 1299 In this scenario IPv6 will only be used for managing these devices on 1300 the Cable Network, all data traffic will still be forwarded by the CM 1301 and CMTS/ER using IPv4. 1303 6.2.6.2. Updates to MIBs/Standards to support IPv6 1305 The current DOCSIS, PacketCable, and CableHome MIBs are already 1306 designed to support IPv6 objects. In this case, IPv6 will neither 1307 add, nor change any of the functionality of these MIBs. An object to 1308 identify the IP version, InetAddressType has been added to all the 1309 appropriate SNMP objects related to IP address. 1311 There are some exceptions, the following MIBs might need to add IPv6 1312 support: 1314 On the CMTS 1316 A. DOCS-QOS-MIB 1318 B. DOCS-SUBMGT-MIB (Subscriber Management Interface Specification 1319 ANNEX B) 1321 On the CM 1323 A. DOCS-QOS-MIB 1325 B. DOCS-CABLE-DEVICE-MIB (or [19]) 1327 7. Broadband DSL Networks 1329 This section describes the IPv6 deployment options in today's High 1330 Speed DSL Networks. 1332 7.1. DSL Network Elements 1334 Digital Subscriber Line (DSL) broadband services provide users with 1335 IP connectivity over the existing twisted-pair telephone lines called 1336 the local-loop. A wide range of bandwidth offerings are available 1337 depending on the quality of the line and the distance between the 1338 Customer Premise Equipment and the DSLAM. 1340 The following network elements are typical of a DSL network [ISP 1341 Transition Scenarios]: 1343 DSL Modem: It can be a stand alone device, it can be incorporated in 1344 the host, it can incorporate router functionalities and also have the 1345 capabilities to act as a CPE router. 1347 Customer Premise Router: It is used to provide Layer 3 services for 1348 customer premise networks. It is usually used to provide firewalling 1349 functions and segment broadcast domains for a Small business. 1351 DSL Access Multiplexer (DSLAM): It terminates multiple twisted pair 1352 telephone lines and provides aggregation to BRAS. 1354 Broadband Remote Access Server (BRAS): It aggregates or terminates 1355 multiple PVC corresponding to the subscriber DSL circuits. 1357 Edge Router (ER): It provides the Layer 3 interface to the ISP 1358 network. 1360 Figure 7.1 depicts all the network elements mentioned 1362 Customer Premise | Network Access Provider | Network Service Provider 1363 CP NAP NSP 1364 +-----+ +------+ +------+ +--------+ 1365 |Hosts|--|Router| +--+ BRAS +---+ Edge | ISP 1366 +-----+ +--+---+ | | | | Router +==> Network 1367 | | +------+ +--------+ 1368 +--+---+ | 1369 | DSL +-+ | 1370 |Modem | | | 1371 +------+ | +-----+ | 1372 +--+ | | 1373 +------+ |DSLAM+--+ 1374 +-----+ | DSL | +--+ | 1375 |Hosts|--+Modem +-+ +-----+ 1376 +-----+ +--+---+ 1377 Figure 7.1 1379 7.2. Deploying IPv6 in IPv4 DSL Networks 1381 There are three main design approaches to providing IPv4 connectivity 1382 over a DSL infrastructure: 1384 1. Point-to-Point Model: Each subscriber connects to the DSLAM over 1385 a twisted pair and is provided with a unique PVC that links it to the 1386 service provider. The PVCs can be terminated at the BRAS or at the 1387 Edge Router. This type of design is not very scalable if the PVCs 1388 are not terminated as close as possible to the DSLAM (at the BRAS). 1389 In this case a large number of layer two circuits has to be 1390 maintained over a significant portion of the network. The layer two 1391 domains can be terminated at the ER in three ways: 1393 A. In a common bridge group with a virtual interface that routes it 1394 out. 1396 B. Enable a Routed Bridged Encapsulation feature, all users could be 1397 part of the same subnet. This is the most common deployment type of 1398 IPv4 over DSL but it might not be the best choice in IPv6 where 1399 address availability is not an issue. 1401 C. Terminate the PVC at Layer 3, each PVC has its own prefix. This 1402 is the approach that seems more suitable for IPv6 and presented in 1403 7.2.1 In none of these cases the CPE (DSL Modem) has to be upgraded. 1405 2. PPP Terminated Aggregation (PTA) Model: PPP sessions are opened 1406 between each subscriber and the BRAS. The BRAS terminates the PPP 1407 sessions and provides Layer 3 connectivity between the subscriber and 1408 the ISP. This model is presented in section 7.2.2. 1410 3. L2TP Access Aggregation (LAA) Model: PPP sessions are opened 1411 between each subscriber and the ISP Edge Router. The BRAS tunnels 1412 the subscriber PPP sessions to the ISP by encapsulating them into 1413 L2TPv2 tunnels. This model is presented in section 7.2.3. 1415 In aggregation models the BRAS terminates the subscriber PVCs and 1416 aggregates their connections before providing access to the ISP. 1418 In order to maintain the deployment concepts and business models 1419 proven and used with existent revenue generating IPv4 services, the 1420 IPv6 deployment will match the IPv4 one. This approach is presented 1421 in sections 7.2.1-3 that describe current IPv4 over DSL broadband 1422 access deployments. Under certain circumstances where new service 1423 types or service needs justify it, IPv4 and IPv6 network logical 1424 architectures could be different as described in section 7.2.4. 1426 7.2.1. Point-to-Point Model 1428 In this scenario the Ethernet frames from the Host or the Customer 1429 Premise Router are bridged over the PVC assigned to the subscriber. 1431 Figure 7.2.1 describes the protocol architecture of this model 1433 Customer Premise NAP NSP 1434 |-------------------------| |---------------| |------------------| 1436 +-----+ +-------+ +-----+ +--------+ +----------+ 1437 |Hosts|--+Router +--+ DSL +--+ DSLAM +--------+ Edge | ISP 1438 +-----+ +-------+ |Modem| +--------+ | Router +=>Network 1439 +-----+ +----------+ 1440 |----------------------------| 1441 ATM 1442 Figure 7.2.1 1444 7.2.1.1. IPv6 Related Infrastructure Changes 1446 In this scenario the DSL modem and the entire NAP is Layer 3 unaware, 1447 so no changes are needed to support IPv6. The following devices have 1448 to be upgraded to dual stack: Host, Customer Router (if present) and 1449 Edge Router. 1451 7.2.1.2. Addressing 1453 The Hosts or the Customer Routers have the Edge Router as their Layer 1454 3 next hop. 1456 If there is no Customer Router all the hosts on the subscriber site 1457 belong to the same /64 subnet that is statically configured on the 1458 Edge Router for that subscriber PVC. The hosts can use stateless 1459 auto-configuration or stateful DHCPv6 based configuration to acquire 1460 an address via the Edge Router. 1462 However, as manual configuration for each customer is a provisioning 1463 challenge, implementations are encouraged to develop mechanism(s) 1464 which automatically map the PVC (or some other customer-specific 1465 information) to an IPv6 subnet prefix, and advertise the customer- 1466 specific prefix to all the customers with minimal configuration. 1468 If a Customer Router is present: 1470 A. It is statically configured with an address on the /64 subnet 1471 between itself and the Edge Router, and with /64 prefixes on the 1472 interfaces connecting the hosts on the customer site. This is not a 1473 desired provisioning method being expensive and difficult to manage. 1475 B. It can use its link-local address to communicate with the ER. It 1476 can also dynamically acquire through stateless auto-configuration the 1477 prefix for the link between itself and the ER. The later option 1478 allows it to contact a remote DHCPv6 server if needed. This step is 1479 followed by a request via DHCP-PD for a prefix shorter than /64 that 1480 in turn is divided in /64s and assigned to its downstream interfaces. 1482 The Edge Router has a /64 prefix configured for each subscriber VLAN. 1483 Each VLAN should be enabled to relay DHCPv6 requests from the 1484 subscribers to DHCPv6 servers in the ISP network. The VLANs 1485 providing access for subscribers that use DHCP-PD as well, have to be 1486 enabled to support the feature. Currently the DHCP-PD functionality 1487 cannot be implemented if the DHCP-PD server is not the Edge Router. 1488 If the DHCP-PD messages are relayed, the Edge Router does not have a 1489 mechanism to learn the assigned prefixes and thus install the proper 1490 routes to make that prefix reachable. Work is being done to address 1491 this issue, one idea being to provide the Edge Router with a snooping 1492 mechanism. The uplink to the ISP network is configured with a /64 1493 prefix as well. 1495 The prefixes used for subscriber links and the ones delegated via 1496 DHCP-PD should be planned in a manner that allows as much 1497 summarization as possible at the Edge Router. 1499 Other information of interest to the host, such as DNS, is provided 1500 through stateful DHCPv6 [10] and stateless DHCPv6 [9]. 1502 7.2.1.3. Routing 1504 The CPE devices are configured with a default route that points to 1505 the Edge router. No routing protocols are needed on these devices 1506 which generally have limited resources. 1508 The Edge Router runs the IPv6 IGP used in the NSP: OSPFv3 or IS-IS. 1509 The connected prefixes have to be redistributed. If DHCP-PD is used, 1510 with every delegated prefix a static route is installed by the Edge 1511 Router. For this reason the static routes must also be 1512 redistributed. Prefix summarization should be done at the Edge 1513 Router. 1515 7.2.2. PPP Terminated Aggregation (PTA) Model 1517 The PTA architecture relies on PPP-based protocols (PPPoA [15] and 1518 PPPoE [14]). The PPP sessions are initiated by Customer Premise 1519 Equipment and are terminated at the BRAS. The BRAS authorizes the 1520 session, authenticates the subscriber, and provides an IP address on 1521 behalf of the ISP. The BRAS then does Layer 3 routing of the 1522 subscriber traffic to the NSP Edge Router. This model is often used 1523 when the NSP is also the NAP. 1525 There are two types of PPP encapsulations that can be leveraged with 1526 this model: 1528 A. Connection using PPPoA 1530 Customer Premise NAP NSP 1531 |--------------------| |----------------------| |----------------| 1532 +-----------+ 1533 | AAA | 1534 +-------+ Radius | 1535 | | TACACS | 1536 | +-----------+ 1537 +-----+ +-------+ +--------+ +----+-----+ +-----------+ 1538 |Hosts|--+Router +------+ DSLAM +-+ BRAS +-+ Edge | 1539 +-----+ +-------+ +--------+ +----------+ | Router +=>Core 1540 |--------------------------| +-----------+ 1541 PPP 1542 Figure 7.2.2.1 1544 The PPP sessions are initiated by the Customer Premise Equipment. 1545 The BRAS authenticates the subscriber against a local or a remote 1546 database. Once the session is established, the BRAS provides an 1547 address and maybe a DNS server to the user, information acquired from 1548 the subscriber profile or from a DHCP server. 1550 This solution scales better then the Point-to-Point but since there 1551 is only one PPP session per ATM PVC the subscriber can choose a 1552 single ISP service at a time. 1554 B. Connection using PPPoE 1556 Customer Premise NAP NSP 1557 |--------------------------| |-------------------| |---------------| 1558 +-----------+ 1559 | AAA | 1560 +-------+ Radius | 1561 | | TACACS | 1562 | +-----------+ 1563 | 1564 +-----+ +-------+ +--------+ +-----+----+ +-----------+ 1565 |Hosts|--+Router +-----------+ DSLAM +-+ BRAS +-+ Edge | C 1566 +-----+ +-------+ +--------+ +----------+ | Router +=>O 1567 | | R 1568 |--------------------------------| +-----------+ E 1569 PPP 1570 Figure 7.2.2.2 1572 The operation of PPPoE is similar to PPPoA with the exception that 1573 with PPPoE multiple sessions can be supported over the same PVC thus 1574 allowing the subscriber to connect to multiple services at the same 1575 time. The hosts can initiate the PPPoE sessions as well. It is 1576 important to remember that the PPPoE encapsulation reduces the IP MTU 1577 available for the customer traffic due to additional headers. 1579 The network design and operation of the PTA model is the same 1580 regardless of the PPP encapsulation type used. 1582 7.2.2.1. IPv6 Related Infrastructure Changes 1584 In this scenario the BRAS is Layer 3 aware and it has to be upgraded 1585 to support IPv6. Since the BRAS terminates the PPP sessions it has 1586 to support the implementation of these PPP protocols with IPv6. The 1587 following devices have to be upgraded to dual stack: Host, Customer 1588 Router (if present), BRAS and Edge Router. 1590 7.2.2.2. Addressing 1592 The BRAS terminates the PPP sessions and provides the subscriber with 1593 an IPv6 address from the defined pool for that profile. The 1594 subscriber profile for authorization and authentication can be 1595 located on the BRAS or on a AAA server. The Hosts or the Customer 1596 Routers have the BRAS as their Layer 3 next hop. 1598 The PPP session can be initiated by a host or by a Customer Router. 1599 In the latter case, once the session is established with the BRAS and 1600 an address is negotiated for the uplink to the BRAS, DHCP-PD can be 1601 used to acquire prefixes for the Customer Router other interfaces. 1603 The BRAS has to be enabled to support DHCP-PD and to relay the DHCPv6 1604 requests of the hosts on the subscriber sites. 1606 The BRAS has a /64 prefixes configured on the link to the Edge 1607 router. The Edge router links are also configured with /64 prefixes 1608 to provide connectivity to the rest of the ISP network. 1610 The prefixes used for subscriber and the ones delegated via DHCP-PD 1611 should be planned in a manner that allows maximum summarization at 1612 the BRAS. 1614 Other information of interest to the host, such as DNS, is provided 1615 through stateful [10] and stateless [9] DHCPv6. 1617 7.2.2.3. Routing 1619 The CPE devices are configured with a default route that points to 1620 the BRAS router. No routing protocols are needed on these devices 1621 which generally have limited resources. 1623 The BRAS runs an IGP to the Edge Router: OSPFv3 or IS-IS. Since the 1624 addresses assigned to the PPP sessions are represented as connected 1625 host routes, connected prefixes have to be redistributed. If DHCP-PD 1626 is used, with every delegated prefix a static route is installed by 1627 the Edge Router. For this reason the static routes must also be 1628 redistributed. Prefix summarization should be done at the BRAS. 1630 The Edge Router is running the IGP used in the ISP network: OSPFv3 or 1631 IS-IS. 1633 A separation between the routing domains of the ISP and the Access 1634 Provider is recommended if they are managed independently. 1635 Controlled redistribution will be needed between the Access Provider 1636 IGP and the ISP IGP. 1638 7.2.3. L2TPv2 Access Aggregation (LAA) Model 1640 In the LAA model the BRAS forwards the CPE initiated session to the 1641 ISP over an L2TPv2 tunnel established between the BRAS and the Edge 1642 Router. In this case the authentication, authorization and 1643 subscriber configuration are performed by the ISP itself. There are 1644 two types of PPP encapsulations that can be leveraged with this 1645 model: 1647 A. Connection via PPPoA 1649 Customer Premise NAP NSP 1650 |--------------------| |----------------------| |----------------| 1651 +-----------+ 1652 | AAA | 1653 +-------+ Radius | 1654 | | TACACS | 1655 | +-----+-----+ 1656 | | 1657 +-----+ +-------+ +--------+ +----+-----+ +-----+-----+ 1658 |Hosts|--+Router +------+ DSLAM +-+ BRAS +-+ Edge | 1659 +-----+ +-------+ +--------+ +----------+ | Router +=>Core 1660 +-----------+ 1661 |----------------------------------------| 1662 PPP 1663 |------------| 1664 L2TPv2 1665 Figure 7.2.3.1 1667 B. Connection via PPPoE 1669 Customer Premise NAP NSP 1670 |--------------------------| |--------------------| |---------------| 1671 +-----------+ 1672 | AAA | 1673 +------+ Radius | 1674 | | TACACS | 1675 | +-----+-----+ 1676 | | 1677 +-----+ +-------+ +--------+ +----+-----+ +----+------+ 1678 |Hosts|--+Router +-----------+ DSLAM +-+ BRAS +-+ Edge | C 1679 +-----+ +-------+ +--------+ +----------+ | Router +=>O 1680 | | R 1681 +-----------+ E 1682 |-----------------------------------------------| 1683 PPP 1684 |--------------| 1685 L2TPv2 1686 Figure 7.2.3.2 1688 The network design and operation of the PTA model is the same 1689 regardless of the PPP encapsulation type used. 1691 7.2.3.1. IPv6 Related Infrastructure Changes 1693 In this scenario the BRAS is forwarding the PPP sessions initiated by 1694 the subscriber over the L2TPv2 tunnel established to the LNS, the 1695 aggregation point in the ISP network. The L2TPv2 tunnel between the 1696 LAC and LNS could run over IPv6 or IPv4. These capabilities have to 1697 be supported on the BRAS. The following devices have to be upgraded 1698 to dual stack: Host, Customer Router and Edge Router. If the tunnel 1699 is set up over IPv6 then the BRAS must be upgraded to dual stack. 1701 7.2.3.2. Addressing 1703 The Edge router terminates the PPP sessions and provides the 1704 subscriber with an IPv6 address from the defined pool for that 1705 profile. The subscriber profile for authorization and authentication 1706 can be located on the Edge Router or on a AAA server. The Hosts or 1707 the Customer Routers have the Edge Router as their Layer 3 next hop. 1709 The PPP session can be initiated by a host or by a Customer Router. 1710 In the latter case, once the session is established with the Edge 1711 Router, DHCP-PD can be used to acquire prefixes for the Customer 1712 Router interfaces. The Edge Router has to be enabled to support 1713 DHCP-PD and to relay the DHCPv6 requests generated by the hosts on 1714 the subscriber sites. 1716 The BRAS has a /64 prefix configured on the link to the Edge router. 1717 The Edge router links are also configured with /64 prefixes to 1718 provide connectivity to the rest of the ISP network. Other 1719 information of interest to the host, such as DNS, is provided through 1720 stateful [10] and stateless [9] DHCPv6. 1722 It is important to note here a significant difference between this 1723 deployment for IPv6 versus IPv4. In the case of IPv4 the customer 1724 router or CPE can end up on any Edge Router (acting as LNS) where the 1725 assumption is that there are at least two of them for redundancy 1726 purposes. Once authenticated, the customer will be given an address 1727 from the IP pool of the ER (LNS) it connected to. This allows the 1728 ERs (LNSs) to aggregate the addresses handed out to the customers. 1729 In the case of IPv6, an important constraint that likely will be 1730 enforced is that the customer should keep its own address regardless 1731 of the ER (LNS) it connects to. This could significantly reduce the 1732 prefix aggregation capabilities of the ER (LNS). This is different 1733 than the current IPv4 deployment where addressing is dynamic in 1734 nature and the same user can get different addresses depending on the 1735 LNS it ends up connecting to. 1737 One possible solution is to ensure that a given BRAS will always 1738 connect to the same ER (LNS) unless that LNS is down. This means 1739 that customers from a given prefix range will always be connected to 1740 the same ER (primary if up or secondary if not). Each ER (LNS) can 1741 carry summary statements in their routing protocol configuration for 1742 the prefixes they are the primary ER (LNS) as well as for the ones 1743 for which they are the secondary. This way the prefixes will be 1744 summarized any time they become "active" on the ER (LNS). 1746 7.2.3.3. Routing 1748 The CPE devices are configured with a default route that points to 1749 the Edge router that terminates the PPP sessions. No routing 1750 protocols are needed on these devices which have generally limited 1751 resources. 1753 The BRAS runs an IPv6 IGP to the Edge Router: OSPFv3 or IS-IS. 1754 Different processes should be used if the NAP and the NSP are managed 1755 by different organizations. In this case, controlled redistribution 1756 should be enabled between the two domains. 1758 The Edge Router is running the IPv6 IGP used in the ISP network: 1759 OSPFv3 or IS-IS. 1761 7.2.4. Hybrid Model for IPv4 and IPv6 Service 1763 It was recommended throughout this section that the IPv6 service 1764 implementation should map the existent IPv4 one. This approach 1765 simplifies manageability and minimizes training needed for personnel 1766 operating the network. In certain circumstances such mapping is not 1767 feasible. This typically becomes the case when a Service Provider 1768 plans to expand its service offering with the new IPv6 deployed 1769 infrastructure. If this new service is not well supported in a 1770 network design such as the one used for IPv4 then a different design 1771 might be used for IPv6. 1773 An example of such circumstances is that of a provider using an LAA 1774 design for its IPv4 services. In this case all the PPP sessions are 1775 bundled and tunneled across the entire NAP infrastructure which is 1776 made of multiple BRAS routers, aggregation routers etc. The end 1777 point of these tunnels is the ISP Edge Router. If the provider 1778 decides to offer multicast services over such a design, it will face 1779 the problem of NAP resources being over utilized. The multicast 1780 traffic can be replicated only at the end of the tunnels by the Edge 1781 router and the copies for all the subscribers are carried over the 1782 entire NAP. 1784 A Modified Point-to-Point (as described in 7.2.4.2) or PTA model are 1785 more suitable to support multicast services because the packet 1786 replication can be done closer to the destination at the BRAS. Such 1787 topology saves NAP resources. 1789 In this sense IPv6 deployment can be viewed as an opportunity to 1790 build an infrastructure that might better support the expansion of 1791 services. In this case, an SP using the LAA design for its IPv4 1792 services might choose a modified Point-to-Point or PTA design for 1793 IPv6. 1795 7.2.4.1. IPv4 in LAA Model and IPv6 in PTA Model 1797 The coexistence of the two PPP based models, PTA and LAA, is 1798 relatively straight forward. The PPP sessions are terminated on 1799 different network devices for the IPv4 and IPv6 services. The PPP 1800 sessions for the existent IPv4 service deployed in an LAA model are 1801 terminated on the Edge Router. The PPP sessions for the new IPv6 1802 service deployed in a PTA model are terminated on the BRAS. 1804 The logical design for IPv6 and IPv4 in this hybrid model is 1805 presented in Figure 7.2.4.1. 1807 IPv6 |--------------------------| 1808 PPP +-----------+ 1809 | AAA | 1810 +-------+ Radius | 1811 | | TACACS | 1812 | +-----+-----+ 1813 | | 1814 +-----+ +-------+ +--------+ +----+-----+ +-----+-----+ 1815 |Hosts|--+Router +------+ DSLAM +-+ BRAS +-+ Edge | 1816 +-----+ +-------+ +--------+ +----------+ | Router +=>Core 1817 +-----------+ 1818 IPv4 |----------------------------------------| 1819 PPP 1820 |------------| 1821 L2TPv2 1822 Figure 7.2.4.1 1824 7.2.4.2. IPv4 in LAA Model and IPv6 in Modified Point-to-Point Model 1826 In this particular scenario the Point-to-Point model used for the 1827 IPv6 service is a modified version of the model described in section 1828 7.2.1. 1830 For the IPv4 service in LAA model, the VLANs are terminated on the 1831 BRAS and PPP sessions are terminated on the Edge Router (LNS). For 1832 IPv6 service in Point-to-Point model, the VLANs are terminated at the 1833 Edge Router as described in section 7.2.1. In this hybrid model, the 1834 Point-to-Point link could be terminated on the BRAS, a NAP owned 1835 device. The IPv6 traffic is then routed through the NAP network to 1836 the NSP. In order to have this hybrid model, the BRAS has to be 1837 upgraded to a dual-stack router. The functionalities of the Edge 1838 Router as described in section 7.2.1 are now implemented on the BRAS. 1840 The other aspect of this deployment model is the fact that the BRAS 1841 has to be capable of distinguishing between the IPv4 PPP traffic that 1842 has to be bridged across the L2TPv2 tunnel and the IPv6 packets that 1843 have to be routed to the NSP. The IPv6 Routing and Bridging 1844 Encapsulation (RBE) has to be enabled on all interfaces with VLANs 1845 supporting both IPv4 and IPv6 services in this hybrid design. 1847 The logical design for IPv6 and IPv4 in this hybrid model is 1848 presented in Figure 7.2.4.2. 1850 IPv6 |----------------| 1851 ATM +-----------+ 1852 | AAA | 1853 +-------+ Radius | 1854 | | TACACS | 1855 | +-----+-----+ 1856 | | 1857 +-----+ +-------+ +--------+ +----+-----+ +-----+-----+ 1858 |Hosts|--+Router +------+ DSLAM +-+ BRAS +-+ Edge | 1859 +-----+ +-------+ +--------+ +----------+ | Router +=>Core 1860 +-----------+ 1861 IPv4 |----------------------------------------| 1862 PPP 1863 |------------| 1864 L2TPv2 1865 Figure 7.2.4.2 1867 7.3. IPv6 Multicast 1869 The deployment of IPv6 multicast services relies on MLD, identical to 1870 IGMP in IPv4 and on PIM for routing. ASM (Any Source Multicast) and 1871 SSM (Single Source Multicast) service models operate almost the same 1872 as in IPv4. Both have the same benefits and disadvantages as in 1873 IPv4. Nevertheless, the larger address space and the scoped address 1874 architecture provide major benefits for multicast IPv6. Through 1875 RFC3306 the large address space provides the means to assign global 1876 multicast group addresses to organizations or users that were 1877 assigned unicast prefixes. It is a significant improvement with 1878 respect to the IPv4 GLOP mechanism [18]. 1880 This facilitates the deployment of multicast services. The 1881 discussion of this section applies to all the multicast sections in 1882 the document. 1884 7.3.1. ASM Based Deployments 1886 Any Source Multicast (ASM) is useful for Service Providers that 1887 intend to support the forwarding of multicast traffic of their 1888 customers. It is based on the PIM-SM protocol and it is more complex 1889 to manage because of the use of Rendezvous Points (RPs). With IPv6, 1890 static RP and BSR [33] can be used for RP-to-group mapping similar to 1891 IPv4. Additionally, the larger IPv6 address space allows for 1892 building up of group addresses that incorporate the address of the 1893 RP. This RP-to-group mapping mechanism is called Embedded RP and is 1894 specific to IPv6. 1896 In inter-domain deployments, Multicast Source Discovery Protocol 1897 (MSDP) [21] is an important element of IPv4 PIM-SM deployments. MSDP 1898 is meant to be a solution for the exchange of source registration 1899 information between RPs in different domains. This solution was 1900 intended to be temporary. This is one of the reasons why it was 1901 decided not to implement MSDP in IPv6 [31]. 1903 For multicast reachability across domains, Embedded RP can be used. 1904 As Embedded RP provides roughly the same capabilities as MSDP, but in 1905 a slightly different way, the best management practices for ASM 1906 multicast with embedded RP still remain to be developed. 1908 7.3.2. SSM Based Deployments 1910 Based on PIM-SSM, the Source Specific Multicast deployments do not 1911 need an RP and the related protocols (such as BSR or MSDP) but rely 1912 on the listeners to know the source of the multicast traffic they 1913 plan to receive. The lack of RP makes SSM not only simpler to 1914 operate but also robust, it is not impacted by RP failures or inter 1915 domain constraints. It is also has a higher level of security (No RP 1916 to be targeted by attacks). For more discussions on the topic of 1917 IPv6 multicast see [31]. 1919 The typical multicast services offered for residential and very small 1920 businesses is video/audio streaming where the subscriber joins a 1921 multicast group and receives the content. This type of service model 1922 is well supported through PIM-SSM which is very simple and easy to 1923 manage. PIM-SSM has to be enabled throughout the SP network. MLDv2 1924 is required for PIM-SSM support. Vendors can choose to implement 1925 features that allow routers to map MLDv1 group joins to predefined 1926 sources. 1928 Subscribers might use a set-top box that is responsible for the 1929 control piece of the multicast service (does group joins/leaves). 1930 The subscriber hosts can also join desired multicast groups as long 1931 as they are enabled to support MLDv1 or MLDv2. If a customer premise 1932 router is used then it has to be enabled to support MLDv1 and MLDv2 1933 in order to process the requests of the hosts. It has to be enabled 1934 to support PIM-SSM in order to send PIM joins/leaves up to its Layer 1935 3 next hop whether it is the BRAS or the Edge router. When enabling 1936 this functionality on a customer premise router, its limited 1937 resources should be taken into consideration. Another option would 1938 be for the customer premise router to support MLD proxy routing. 1940 The router that is the Layer 3 next hop for the subscriber (BRAS in 1941 the PTA model or the Edge router in the LAA and Point-to-Point model) 1942 has to be enabled to support MLDv1 and MLDv2 in order to process the 1943 requests coming from subscribers without customer premise routers. 1944 It has to be enabled for PIM-SSM in order to receive joins/leaves 1945 from customer routers and send joins/leaves to the next hop towards 1946 the multicast source (Edge router or the NSP core). 1948 MLD authentication, authorization and accounting is usually 1949 configured on the edge router in order to enable the ISP to do 1950 control the subscriber access of the service and do billing for the 1951 content provided. Alternative mechanisms that would support these 1952 functions should be investigated further. 1954 7.4. IPv6 QoS 1956 The QoS configuration is particularly relevant on the router that 1957 represents the Layer 3 next hop for the subscriber (BRAS in the PTA 1958 model or the Edge router in the LAA and Point-to-Point model) in 1959 order to manage resources shared amongst multiple subscribers 1960 possibly with various service level agreements. 1962 In the DSL infrastructure it is expected that there is already a 1963 level of traffic policing and shaping implemented for IPv4 1964 connectivity. This is implemented throughout the NAP and it is 1965 beyond the scope of this document. 1967 On the BRAS or the Edge Router the subscriber facing interfaces have 1968 to be configure to police the inbound customer traffic and shape the 1969 traffic outbound to the customer based on the SLAs. Traffic 1970 classification and marking should also be done on the router closest 1971 (at Layer 3) to the subscriber in order to support the various types 1972 of customer traffic: data, voice, video and to optimally use the 1973 infrastructure resources. Each provider (NAP, NSP) could implement 1974 their own QoS policies and services so reclassification and marking 1975 might be performed at the boundary between the NAP and the NSP in 1976 order to make sure the traffic is properly handled by the ISP. The 1977 same IPv4 QoS concepts and methodologies should be applied with IPv6 1978 as well. 1980 It is important to note that when traffic is encrypted end-to-end, 1981 the traversed network devices will not have access to many of the 1982 packet fields used for classification purposes. In these cases 1983 routers will most likely place the packets in the default classes. 1984 The QoS design should take into consideration this scenario and try 1985 to use mainly IP header fields for classification purposes. 1987 7.5. IPv6 Security Considerations 1989 There are limited changes that have to be done for CPEs in order to 1990 enhance security. The Privacy extensions for auto-configuration [13] 1991 should be used by the hosts. ISPs can track the prefixes it assigns 1992 to subscribers relatively easily. If however the ISPs are required 1993 by regulations to track their users at /128 address level, the 1994 Privacy Extensions can be implemented only in parallel with network 1995 management tools that could provide traceability of the hosts. IPv6 1996 firewall functions should be enabled on the hosts or customer premise 1997 router if present. 1999 The ISP provides security against attacks that come form its own 2000 subscribers but it could also implement security services that 2001 protect its subscribers from attacks sourced from the outside of its 2002 network. Such services do not apply at the access level of the 2003 network discussed here. 2005 The device that is the Layer 3 next hop for the subscribers (BRAS or 2006 Edge router) should protect the network and the other subscribers 2007 against attacks by one of the provider customers. For this reason 2008 uRPF and ACLs should be used on all interfaces facing subscribers. 2009 Filtering should be implemented with regard for the operational 2010 requirements of IPv6 [35]. Authentication and authorization should 2011 be used wherever possible. 2013 The BRAS and the Edge Router should protect their processing 2014 resources against floods of valid customer control traffic such as: 2015 Router and Neighbor Solicitations, MLD Requests. Rate limiting 2016 should be implemented on all subscriber facing interfaces. The 2017 emphasis should be placed on multicast type traffic as it is most 2018 often used by the IPv6 control plane. 2020 All other security features used with the IPv4 service should be 2021 similarly applied to IPv6 as well. 2023 7.6. IPv6 Network management 2025 The necessary instrumentation (such as MIBs, NetFlow Records etc) 2026 should be available for IPv6. 2028 Usually, NSPs manage the edge routers by SNMP. The SNMP transport 2029 can be done over IPv4 if all managed devices have connectivity over 2030 both IPv4 and IPv6. This would imply the smallest changes to the 2031 existent network management practices and processes. Transport over 2032 IPv6 could also be implemented and it might become necessary if IPv6 2033 only islands are present in the network. The management stations are 2034 located on the core network. Network Management Applications should 2035 handle IPv6 in a similar fashion to IPv4, however, they should also 2036 support features specific to IPv6 (such as Neighbor monitoring). 2038 In some cases service providers manage equipment located on customers 2039 LANs. The management of equipment at customers' LANs is out of scope 2040 of this memo. 2042 8. Broadband Ethernet Networks 2044 This section describes the IPv6 deployment options in currently 2045 deployed Broadband Ethernet Access Networks. 2047 8.1. Ethernet Access Network Elements 2049 In environments that support the infrastructure deploying RJ-45 or 2050 fiber (Fiber to the Home (FTTH) service) to subscribers, 10/100 Mbps 2051 Ethernet broadband services can be provided. Such services are 2052 generally available in metropolitan areas, in multi tenant buildings 2053 where an Ethernet infrastructure can be deployed in a cost effective 2054 manner. In such environments Metro-Ethernet services can be used to 2055 provide aggregation and uplink to a Service Provider. 2057 The following network elements are typical of an Ethernet network: 2059 Access Switch: It is used as a Layer 2 access device for subscribers. 2061 Customer Premise Router: It is used to provide Layer 3 services for 2062 customer premise networks. 2064 Aggregation Ethernet Switches: Aggregates multiple subscribers. 2066 Broadband Remote Access Server (BRAS) 2068 Edge Router (ER) 2070 Figure 8.1 depicts all the network elements mentioned. 2072 Customer Premise | Network Access Provider | Network Service Provider 2073 CP NAP NSP 2075 +-----+ +------+ +------+ +--------+ 2076 |Hosts|--|Router| +-+ BRAS +--+ Edge | ISP 2077 +-----+ +--+---+ | | | | Router +===> Network 2078 | | +------+ +--------+ 2079 +--+----+ | 2080 |Access +-+ | 2081 |Switch | | | 2082 +-------+ | +------+ | 2083 +--+Agg E | | 2084 +-------+ |Switch+-+ 2085 +-----+ |Access | +--+ | 2086 |Hosts|--+Switch +-+ +------+ 2087 +-----+ +-------+ 2088 Figure 8.1 2090 The logical topology and design of Broadband Ethernet Networks is 2091 very similar to DSL Broadband Networks discussed in section 7. 2093 It is worth noting that the general operation, concepts and 2094 recommendations described in this section apply similarly to a 2095 HomePNA based network environment. In such an environment some of 2096 the network elements might be differently named. 2098 8.2. Deploying IPv6 in IPv4 Broadband Ethernet Networks 2100 There are three main design approaches to providing IPv4 connectivity 2101 over an Ethernet infrastructure: 2103 A. Point-to-Point Model: Each subscriber connects to the network 2104 Access switch over RJ-45 or fiber links. Each subscriber is assigned 2105 a unique VLAN on the access switch. The VLAN can be terminated at 2106 the BRAS or at the Edge Router. The VLANs are 802.1q trunked to the 2107 Layer 3 device (BRAS or Edge Router). 2109 This model is presented in section 8.2.1. 2111 B. PPP Terminated Aggregation (PTA) Model: PPP sessions are opened 2112 between each subscriber and the BRAS. The BRAS terminates the PPP 2113 sessions and provides Layer 3 connectivity between the subscriber and 2114 the ISP. 2116 This model is presented in section 8.2.2. 2118 C. L2TPv2 Access Aggregation (LAA) Model: PPP sessions are opened 2119 between each subscriber and the ISP termination devices. The BRAS 2120 tunnels the subscriber PPP sessions to the ISP by encapsulating them 2121 into L2TPv2 tunnels. 2123 This model is presented in section 8.2.3. 2125 In aggregation models the BRAS terminates the subscriber VLANs and 2126 aggregates their connections before providing access to the ISP. 2128 In order to maintain the deployment concepts and business models 2129 proven and used with existent revenue generating IPv4 services, the 2130 IPv6 deployment will match the IPv4 one. This approach is presented 2131 in sections 8.2.1-3 that describe currently deployed IPv4 over 2132 Ethernet broadband access deployments. Under certain circumstances 2133 where new service types or service needs justify it, IPv4 and IPv6 2134 network architectures could be different as described in section 2135 8.2.4. 2137 8.2.1. Point-to-Point Model 2139 In this scenario the Ethernet frames from the Host or the Customer 2140 Premise Router are bridged over the VLAN assigned to the subscriber. 2142 Figure 8.2.1 describes the protocol architecture of this model. 2144 | Customer Premise | | NAP | NSP | 2146 +-----+ +------+ +------+ +--------+ +----------+ 2147 |Hosts|--+Router+--+Access+--+ Switch +--------+ Edge | ISP 2148 +-----+ +------+ |Switch| +--------+ 802.1q | Router +=>Network 2149 +------+ +----------+ 2151 |----------------------------| 2152 Ethernet/VLANs 2154 Figure 8.2.1 2156 8.2.1.1. IPv6 Related Infrastructure Changes 2158 In this scenario the Access Switch on the customer site and the 2159 entire NAP is Layer 3 unaware so no changes are needed to support 2160 IPv6. The following devices have to be upgraded to dual stack: Host, 2161 Customer Router and Edge Router. 2163 The Access switches might need upgrades to support certain IPv6 2164 related features such as MLD Snooping. 2166 8.2.1.2. Addressing 2168 The Hosts or the Customer Routers have the Edge Router as their Layer 2169 3 next hop. If there is no Customer Router all the hosts on the 2170 subscriber site belong to the same /64 subnet that is statically 2171 configured on the Edge Router for that subscriber VLAN. The hosts 2172 can use stateless auto-configuration or stateful DHCPv6 based 2173 configuration to acquire an address via the Edge Router. 2175 However, as manual configuration for each customer is a provisioning 2176 challenge, implementations are encouraged to develop mechanism(s) 2177 which automatically map the VLAN (or some other customer-specific 2178 information) to an IPv6 subnet prefix, and advertise the customer- 2179 specific prefix to all the customers with minimal configuration. 2181 If a Customer Router is present: 2183 A. It is statically configured with an address on the /64 subnet 2184 between itself and the Edge Router, and with /64 prefixes on the 2185 interfaces connecting the hosts on the customer site. This is not a 2186 desired provisioning method being expensive and difficult to manage. 2188 B. It can use its link-local address to communicate with the ER. It 2189 can also dynamically acquire through stateless auto-configuration the 2190 address for the link between itself and the ER. This step is 2191 followed by a request via DHCP-PD for a prefix shorter than /64 that 2192 in turn is divided in /64s and assigned to its interfaces connecting 2193 the hosts on the customer site. 2195 The Edge Router has a /64 prefix configured for each subscriber VLAN. 2196 Each VLAN should be enabled to relay DHCPv6 requests from the 2197 subscribers to DHCPv6 servers in the ISP network. The VLANs 2198 providing access for subscribers that use DHCP-PD as well, have to be 2199 enabled to support the feature. Currently the DHCP-PD functionality 2200 cannot be implemented if the DHCP-PD server is not the Edge Router. 2201 If the DHCP-PD messages are relayed, the Edge Router does not have a 2202 mechanism to learn the assigned prefixes and thus install the proper 2203 routes to make that prefix reachable. Work is being done to address 2204 this issue, one idea being to provide the Edge Router with a snooping 2205 mechanism. The uplink to the ISP network is configured with a /64 2206 prefix as well. The uplink to the ISP network is configured with a 2207 /64 prefix as well. 2209 The prefixes used for subscriber links and the ones delegated via 2210 DHCP-PD should be planned in a manner that allows as much 2211 summarization as possible at the Edge Router. 2213 Other information of interest to the host, such as DNS, is provided 2214 through stateful [10] and stateless [9] DHCPv6. 2216 8.2.1.3. Routing 2218 The CPE devices are configured with a default route that points to 2219 the Edge router. No routing protocols are needed on these devices 2220 which generally have limited resources. 2222 The Edge Router runs the IPv6 IGP used in the NSP: OSPFv3 or IS-IS. 2223 The connected prefixes have to be redistributed. If DHCP-PD is used, 2224 with every delegated prefix a static route is installed by the Edge 2225 Router. For this reason the static routes must also be 2226 redistributed. Prefix summarization should be done at the Edge 2227 Router. 2229 8.2.2. PPP Terminated Aggregation (PTA) Model 2231 The PTA architecture relies on PPP-based protocols (PPPoE). The PPP 2232 sessions are initiated by Customer Premise Equipment and it is 2233 terminated at the BRAS. The BRAS authorizes the session, 2234 authenticates the subscriber, and provides an IP address on behalf of 2235 the ISP. The BRAS then does Layer 3 routing of the subscriber 2236 traffic to the NSP Edge Router. This model is often used when the 2237 NSP is also the NAP. The PPPoE logical diagram in an Ethernet 2238 Broadband Network is shown in Fig 8.2.2.1. 2240 | Customer Premise | | NAP | | NSP | 2242 +-----------+ 2243 | AAA | 2244 +-------+ Radius | 2245 | | TACACS | 2246 | +-----------+ 2247 +-----+ +-------+ +--------+ +--------+ +----+-----+ +-----------+ 2248 |Hosts|-+Router +-+A Switch+-+ Switch +-+ BRAS +-+ Edge | C 2249 +-----+ +-------+ +--------+ +--------+ +----------+ | Router +=>O 2250 |---------------- PPP ----------------| | | R 2251 +-----------+ E 2252 Figure 8.2.2.1 2254 The PPP sessions are initiated by the Customer Premise Equipment 2255 (Host or Router). The BRAS authenticates the subscriber against a 2256 local or a remote database. Once the session is established, the 2257 BRAS provides an address and maybe a DNS server to the user, 2258 information acquired from the subscriber profile or from a DHCP 2259 server. 2261 This model allows for multiple PPPoE sessions to be supported over 2262 the same VLAN thus allowing the subscriber to connect to multiple 2263 services at the same time. The hosts can initiate the PPPoE sessions 2264 as well. It is important to remember that the PPPoE encapsulation 2265 reduces the IP MTU available for the customer traffic. 2267 8.2.2.1. IPv6 Related Infrastructure Changes 2269 In this scenario the BRAS is Layer 3 aware and it has to be upgraded 2270 to support IPv6. Since the BRAS terminates the PPP sessions it has 2271 to support PPPoE with IPv6. The following devices have to be 2272 upgraded to dual stack: Host, Customer Router (if present), BRAS and 2273 Edge Router. 2275 8.2.2.2. Addressing 2277 The BRAS terminates the PPP sessions and provides the subscriber with 2278 an IPv6 address from the defined pool for that profile. The 2279 subscriber profile for authorization and authentication can be 2280 located on the BRAS or on a AAA server. The Hosts or the Customer 2281 Routers have the BRAS as their Layer 3 next hop. 2283 The PPP session can be initiated by a host or by a Customer Router. 2284 In the latter case, once the session is established with the BRAS, 2285 DHCP-PD can be used to acquire prefixes for the Customer Router 2286 interfaces. The BRAS has to be enabled to support DHCP-PD and to 2287 relay the DHCPv6 requests of the hosts on the subscriber sites. 2288 Currently the DHCP-PD functionality cannot be implemented if the 2289 DHCP-PD server is not the Edge Router. If the DHCP-PD messages are 2290 relayed, the Edge Router does not have a mechanism to learn the 2291 assigned prefixes and thus install the proper routes to make that 2292 prefix reachable. Work is being done to address this issue, one idea 2293 being to provide the Edge Router with a snooping mechanism. The 2294 uplink to the ISP network is configured with a /64 prefix as well. 2296 The BRAS has a /64 prefix configured on the link facing the Edge 2297 router. The Edge router links are also configured with /64 prefixes 2298 to provide connectivity to the rest of the ISP network. 2300 The prefixes used for subscriber and the ones delegated via DHCP-PD 2301 should be planned in a manner that allows maximum summarization at 2302 the BRAS. 2304 Other information of interest to the host, such as DNS, is provided 2305 through stateful [10] and stateless [9] DHCPv6. 2307 8.2.2.3. Routing 2309 The CPE devices are configured with a default route that points to 2310 the BRAS router. No routing protocols are needed on these devices 2311 which generally have limited resources. 2313 The BRAS runs an IGP to the Edge Router: OSPFv3 or IS-IS. Since the 2314 addresses assigned to the PPP sessions are represented as connected 2315 host routes, connected prefixes have to be redistributed. If DHCP-PD 2316 is used, with every delegated prefix a static route is installed by 2317 the BRAS. For this reason the static routes must also be 2318 redistributed. Prefix summarization should be done at the BRAS. 2320 The Edge Router is running the IGP used in the ISP network: OSPFv3 or 2321 IS-IS. A separation between the routing domains of the ISP and the 2322 Access Provider is recommended if they are managed independently. 2323 Controlled redistribution will be needed between the Access Provider 2324 IGP and the ISP IGP. 2326 8.2.3. L2TPv2 Access Aggregation (LAA) Model 2328 In the LAA model the BRAS forwards the CPE initiated session to the 2329 ISP over an L2TPv2 tunnel established between the BRAS and the Edge 2330 Router. In this case the authentication, authorization and 2331 subscriber configuration are performed by the ISP itself. 2333 | Customer Premise | | NAP | | NSP | 2335 +-----------+ 2336 | AAA | 2337 +------+ Radius | 2338 | | TACACS | 2339 | +-----+-----+ 2340 | | 2341 +-----+ +-------+ +--------+ +--------+ +----+-----+ +-----------+ 2342 |Hosts|-+Router +-+A Switch+-+ Switch +-+ BRAS +-+ Edge | C 2343 +-----+ +-------+ +--------+ +--------+ +----------+ | Router +=>O 2344 | | R 2345 +-----------+ E 2346 |-----------------------------------------------| 2347 PPP 2348 |--------------| 2349 L2TPv2 2350 Figure 8.2.3.1 2352 8.2.3.1. IPv6 Related Infrastructure Changes 2354 In this scenario the BRAS is Layer 3 aware and it has to be upgraded 2355 to support IPv6. The PPP sessions initiated by the subscriber are 2356 forwarded over the L2TPv2 tunnel to the aggregation point in the ISP 2357 network. The BRAS (LAC) can aggregate IPv6 PPP sessions and tunnel 2358 them to the LNS using L2TPv2. The L2TPv2 tunnel between the LAC and 2359 LNS could run over IPv6 or IPv4. These capabilities have to be 2360 supported on the BRAS. The following devices have to be upgraded to 2361 dual stack: Host, Customer Router (if present), BRAS and Edge Router. 2363 8.2.3.2. Addressing 2365 The Edge router terminates the PPP sessions and provides the 2366 subscriber with an IPv6 address from the defined pool for that 2367 profile. The subscriber profile for authorization and authentication 2368 can be located on the Edge Router or on a AAA server. The Hosts or 2369 the Customer Routers have the Edge Router as their Layer 3 next hop. 2371 The PPP session can be initiated by a host or by a Customer Router. 2372 In the latter case, once the session is established with the Edge 2373 Router and an IPv6 address is assigned to the Customer Router by the 2374 Edge router, DHCP-PD can be used to acquire prefixes for the Customer 2375 Router other interfaces. The Edge Router has to be enabled to 2376 support DHCP-PD and to relay the DHCPv6 requests of the hosts on the 2377 subscriber sites. Currently the DHCP-PD functionality cannot be 2378 implemented if the DHCP-PD server is not the Edge Router. If the 2379 DHCP-PD messages are relayed, the Edge Router does not have a 2380 mechanism to learn the assigned prefixes and thus install the proper 2381 routes to make that prefix reachable. Work is being done to address 2382 this issue, one idea being to provide the Edge Router with a snooping 2383 mechanism. The uplink to the ISP network is configured with a /64 2384 prefix as well. 2386 The BRAS has a /64 prefix configured on the link to the Edge router. 2387 The Edge router links are also configured with /64 prefixes to 2388 provide connectivity to the rest of the ISP network. 2390 Other information of interest to the host, such as DNS, is provided 2391 through stateful [10] and stateless [9] DHCPv6. 2393 The address assignment and prefix summarization issues discussed in 2394 section 7.2.3.2 are relevant in the same way for this media access 2395 type as well. 2397 8.2.3.3. Routing 2399 The CPE devices are configured with a default route that points to 2400 the Edge router that terminates the PPP sessions. No routing 2401 protocols are needed on these devices which have limited resources. 2403 The BRAS runs an IPv6 IGP to the Edge Router: OSPFv3 or IS-IS. 2404 Different processes should be used if the NAP and the NSP are managed 2405 by different organizations. In this case controlled redistribution 2406 should be enabled between the two domains. 2408 The Edge Router is running the IPv6 IGP used in the ISP network: 2409 OSPFv3 or IS-IS. 2411 8.2.4. Hybrid Model for IPv4 and IPv6 Service 2413 It was recommended throughout this section that the IPv6 service 2414 implementation should map the existent IPv4 one. This approach 2415 simplifies manageability and minimizes training needed for personnel 2416 operating the network. In certain circumstances such mapping is not 2417 feasible. This typically becomes the case when a Service Provider 2418 plans to expand its service offering with the new IPv6 deployed 2419 infrastructure. If this new service is not well supported in a 2420 network design such as the one used for IPv4 then a different design 2421 might be used for IPv6. 2423 An example of such circumstances is that of a provider using an LAA 2424 design for its IPv4 services. In this case all the PPP sessions are 2425 bundled and tunneled across the entire NAP infrastructure which is 2426 made of multiple BRAS routers, aggregation routers etc. The end 2427 point of these tunnels is the ISP Edge Router. If the SP decides to 2428 offer multicast services over such a design, it will face the problem 2429 of NAP resources being over utilized. The multicast traffic can be 2430 replicated only at the end of the tunnels by the Edge router and the 2431 copies for all the subscribers are carried over the entire NAP. 2433 A Modified Point-to-Point (see section 8.2.4.2) or a PTA model is 2434 more suitable to support multicast services because the packet 2435 replication can be done closer to the destination at the BRAS. Such 2436 topology saves NAP resources. 2438 In this sense IPv6 deployments can be viewed as an opportunity to 2439 build an infrastructure that can better support the expansion of 2440 services. In this case, an SP using the LAA design for its IPv4 2441 services might choose a modified Point-to-Point or PTA design for 2442 IPv6. 2444 8.2.4.1. IPv4 in LAA Model and IPv6 in PTA Model 2446 The coexistence of the two PPP based models, PTA and LAA, is 2447 relatively straight forward. It is a straight forward overlap of the 2448 two deployment models. The PPP sessions are terminated on different 2449 network devices for the IPv4 and IPv6 services. The PPP sessions for 2450 the existent IPv4 service deployed in an LAA model are terminated on 2451 the Edge Router. The PPP sessions for the new IPv6 service deployed 2452 in a PTA model are terminated on the BRAS. 2454 The logical design for IPv6 and IPv4 in this hybrid model is 2455 presented in Figure 8.2.4.1. 2457 IPv6 |--------------------------| 2458 PPP +-----------+ 2459 | AAA | 2460 +-------+ Radius | 2461 | | TACACS | 2462 | +-----+-----+ 2463 | | 2464 +-----+ +-------+ +--------+ +----+-----+ +-----+-----+ 2465 |Hosts|--+Router +------+ Switch +-+ BRAS +-+ Edge | 2466 +-----+ +-------+ +--------+ +----------+ | Router +=>Core 2467 +-----------+ 2469 IPv4 |----------------------------------------| 2470 PPP 2471 |------------| 2472 L2TPv2 2473 Figure 8.2.4.1 2475 8.2.4.2. IPv4 in LAA Model and IPv6 in Modified Point-to-Point Model 2477 The coexistence of the modified Point-to-Point and the LAA models 2478 implies a few specific changes. 2480 For the IPv4 service in LAA model, the VLANs are terminated on the 2481 BRAS and PPP sessions are terminated on the Edge Router (LNS). For 2482 IPv6 service in Point-to-Point model, the VLANs are terminated at the 2483 Edge Router as described in section 7.2.1. In this hybrid model, the 2484 Point-to-Point link could be terminated on the BRAS, a NAP owned 2485 device. The IPv6 traffic is then routed through the NAP network to 2486 the NSP. In order to have this hybrid model, the BRAS has to be 2487 upgraded to a dual-stack router. The functionalities of the Edge 2488 Router as described in section 7.2.1 are now implemented on the BRAS. 2490 The logical design for IPv6 and IPv4 in this hybrid model is in 2491 Figure 8.2.4.2. 2493 IPv6 |----------------| 2494 Ethernet 2495 +-----------+ 2496 | AAA | 2497 +-------+ Radius | 2498 | | TACACS | 2499 | +-----+-----+ 2500 | | 2501 +-----+ +-------+ +--------+ +----+-----+ +-----+-----+ 2502 |Hosts|--+Router +------+ Switch +-+ BRAS +-+ Edge | 2503 +-----+ +-------+ +--------+ +----------+ | Router +=>Core 2504 +-----------+ 2505 IPv4 |----------------------------------------| 2506 PPP 2507 |------------| 2508 L2TPv2 2509 Figure 8.2.4.2 2511 8.3. IPv6 Multicast 2513 The typical multicast services offered for residential and very small 2514 businesses is video/audio streaming where the subscriber joins a 2515 multicast group and receives the content. This type of service model 2516 is well supported through PIM-SSM which is very simple and easy to 2517 manage. PIM-SSM has to be enabled throughout the ISP network. MLDv2 2518 is required for PIM-SSM support. Vendors can choose to implement 2519 features that allow routers to map MLDv1 group joins to predefined 2520 sources. 2522 Subscribers might use a set-top box that is responsible for the 2523 control piece of the multicast service (does group joins/leaves). 2524 The subscriber hosts can also join desired multicast groups as long 2525 as they are enabled to support MLDv1 or MLDv2. If a customer premise 2526 router is used then it has to be enabled to support MLDv1 and MLDv2 2527 in order to process the requests of the hosts. It has to be enabled 2528 to support PIM-SSM in order to send PIM joins/leaves up to its Layer 2529 3 next hop whether it is the BRAS or the Edge router. When enabling 2530 this functionality on a customer premise router, its limited 2531 resources should be taken into consideration. Another option would 2532 be for the customer premise router to support MLD proxy routing. MLD 2533 snooping or similar layer two multicast related protocols could be 2534 enabled on the NAP switches. 2536 The router that is the Layer 3 next hop for the subscriber (BRAS in 2537 the PTA model or the Edge router in the LAA and Point-to-Point model) 2538 has to be enabled to support MLDv1 and MLDv2 in order to process the 2539 requests coming from subscribers without customer premise routers. 2540 It has to be enabled for PIM-SSM in order to receive joins/leaves 2541 from customer routers and send joins/leaves to the next hop towards 2542 the multicast source (Edge router or the NSP core). 2544 MLD authentication, authorization and accounting is usually 2545 configured on the edge router in order to enable the ISP to do 2546 control the subscriber access of the service and do billing for the 2547 content provided. Alternative mechanisms that would support these 2548 functions should be investigated further. 2550 Please refer to section 7.3 for more IPv6 multicast details. 2552 8.4. IPv6 QoS 2554 The QoS configuration is particularly relevant on the router that 2555 represents the Layer 3 next hop for the subscriber (BRAS in the PTA 2556 model or the Edge router in the LAA and Point-to-Point model) in 2557 order to manage resources shared amongst multiple subscribers 2558 possibly with various service level agreements. 2560 On the BRAS or the Edge Router the subscriber facing interfaces have 2561 to be configured to police the inbound customer traffic and shape the 2562 traffic outbound to the customer based on the SLAs. Traffic 2563 classification and marking should also be done on the router closest 2564 (at Layer 3) to the subscriber in order to support the various types 2565 of customer traffic: data, voice, video and to optimally use the 2566 network resources. This infrastructure offers a very good 2567 opportunity to leverage the QoS capabilities of Layer two devices. 2568 DiffServ based QoS used for IPv4 should be expanded to IPv6. 2570 Each provider (NAP, NSP) could implement their own QoS policies and 2571 services so reclassification and marking might be performed at the 2572 boundary between the NAP and the NSP in order to make sure the 2573 traffic is properly handled by the ISP. The same IPv4 QoS concepts 2574 and methodologies should be applied for the IPv6 as well. 2576 It is important to note that when traffic is encrypted end-to-end, 2577 the traversed network devices will not have access to many of the 2578 packet fields used for classification purposes. In these cases 2579 routers will most likely place the packets in the default classes. 2580 The QoS design should take into consideration this scenario and try 2581 to use mainly IP header fields for classification purposes. 2583 8.5. IPv6 Security Considerations 2585 There are limited changes that have to be done for CPEs in order to 2586 enhance security. The Privacy extensions [13] for auto-configuration 2587 should be used by the hosts with the same considerations for host 2588 traceability as discussed in section 7.5. IPv6 firewall functions 2589 should be enabled on the hosts or customer premise router if present. 2591 The ISP provides security against attacks that come form its own 2592 subscribers but it could also implement security services that 2593 protect its subscribers from attacks sourced from the outside of its 2594 network. Such services do not apply at the access level of the 2595 network discussed here. 2597 If any layer two filters for Ethertypes are in place, the NAP must 2598 permit the IPv6 Ethertype (0X86DD). 2600 The device that is the Layer 3 next hop for the subscribers (BRAS 2601 Edge router) should protect the network and the other subscribers 2602 against attacks by one of the provider customers. For this reason 2603 uRPF and ACLs should be used on all interfaces facing subscribers. 2604 Filtering should be implemented with regard for the operational 2605 requirements of IPv6 [35]. 2607 Authentication and authorization should be used wherever possible. 2609 The BRAS and the Edge Router should protect their processing 2610 resources against floods of valid customer control traffic such as: 2611 Router and Neighbor Solicitations, MLD Requests. Rate limiting 2612 should be implemented on all subscriber facing interfaces. The 2613 emphasis should be placed on multicast type traffic as it is most 2614 often used by the IPv6 control plane. 2616 All other security features used with the IPv4 service should be 2617 similarly applied to IPv6 as well. 2619 8.6. IPv6 Network Management 2621 The necessary instrumentation (such as MIBs, NetFlow Records etc) 2622 should be available for IPv6. 2624 Usually, NSPs manage the edge routers by SNMP. The SNMP transport 2625 can be done over IPv4 if all managed devices have connectivity over 2626 both IPv4 and IPv6. This would imply the smallest changes to the 2627 existent network management practices and processes. Transport over 2628 IPv6 could also be implemented and it might become necessary if IPv6 2629 only islands are present in the network. The management stations are 2630 located on the core network. Network Management Applications should 2631 handle IPv6 in a similar fashion to IPv4 however they should also 2632 support features specific to IPv6 such as Neighbor monitoring. 2634 In some cases service providers manage equipment located on customers 2635 LANs. 2637 9. Wireless LAN 2639 This section provides detailed description of IPv6 deployment and 2640 integration methods in currently deployed wireless LAN (WLAN) 2641 infrastructure. 2643 9.1. WLAN Deployment Scenarios 2645 WLAN enables subscribers to connect to the Internet from various 2646 locations without the restriction of staying indoors. WLAN is 2647 standardized by IEEE 802.11a/b/g. Consideration should be also given 2648 to IEEE 802.16 WiMAX for similar deployment approaches. IEEE 802.11 2649 offers maximum transmission speed from 1 or 2 Mbps, IEEE 802.11b 2650 offers 11 Mbps and IEEE 802.11a/g offer up to 54 Mbps. 2652 Figure 9.1 describes the current WLAN architecture. 2654 Customer | Access Provider | Service Provider 2655 Premise | | 2657 +------+ +--+ +--------------+ +----------+ +------+ 2658 |WLAN | ---- | | |Access Router/| |Underlying| |Edge | 2659 |Host/ |-(WLAN)--|AP|-|Layer 2 Switch|-|Technology|-|Router|=>SP 2660 |Router| ---- | | | | | | | |Network 2661 +------+ +--+ +--------------+ +----------+ +------+ 2662 | 2663 +------+ 2664 |AAA | 2665 |Server| 2666 +------+ 2667 Figure 9.1 2669 The host should have a wireless network interface card (NIC) in order 2670 to connect to a WLAN network. WLAN is a flat broadcast network and 2671 works in a similar fashion as Ethernet. When hosts initiate a 2672 connection, it is authenticated by the AAA server located at the SP 2673 network. All the authentication parameters (username, password and 2674 etc.) are forwarded by the Access Point (AP) to the AAA server. The 2675 AAA server authenticates the host, once successfully authenticated 2676 the host can send data packets. The AP is located near the host and 2677 acts as a bridge. The AP forwards all the packets coming to/from 2678 host to the Edge Router. The underlying connection between the AP 2679 and Edge Router could be based on any access layer technology such as 2680 HFC/Cable, FTTH, xDSL or etc. 2682 WLANs are based in limited areas known as WiFi Hot Spots. While 2683 users are present in the area covered by the WLAN range, they can be 2684 connected to the Internet given they have a wireless NIC and required 2685 configuration settings in their devices (notebook PCs, PDA or etc.). 2686 Once the user initiates the connection the IP address is assigned by 2687 the SP using DHCPv4. In most of the cases SP assigns limited number 2688 of public IP addresses to the its customer. When the user 2689 disconnects the connection and moves to a new WiFi hot spot, the 2690 above mentioned process of authentication, address assignment and 2691 accessing the Internet is repeated. 2693 There are IPv4 deployments where customers can use WLAN routers to 2694 connect over wireless to their service provider. These deployment 2695 types do not fit in the typical Hot Spot concept but they rather 2696 serve fixed customers. For this reason this section discusses the 2697 WLAN router options as well. In this case, the ISP provides a public 2698 IP address and the WLAN Router assigns private addresses [1] to all 2699 WLAN users. The WLAN Router provides NAT functionality while WLAN 2700 users access the Internet. 2702 While deploying IPv6 in the above mentioned WLAN architecture, there 2703 are three possible scenarios as discussed below. 2705 A. Layer 2 NAP with Layer 3 termination at NSP Edge Router 2707 B. Layer 3 aware NAP with Layer 3 termination at Access Router 2709 C. PPP Based Model 2711 9.1.1. Layer 2 NAP with Layer 3 termination at NSP Edge Router 2713 When a Layer 2 switch is present between AP and Edge Router, the AP 2714 and Layer 2 switch continues to work as a bridge, forwarding IPv4 and 2715 IPv6 packets from WLAN Host/Router to Edge Router and vice versa. 2717 When initiating the connection, the WLAN host is authenticated by the 2718 AAA server located at the SP network. All the parameters related to 2719 authentication (username, password and etc.) are forwarded by the AP 2720 to the AAA server. The AAA server authenticates the WLAN Hosts and 2721 once authenticated and associated successfully with WLAN AP, IPv6 2722 address will be acquired by the WLAN Host. Note the initiation and 2723 authentication process is same as used in IPv4. 2725 Figure 9.1.1 describes the WLAN architecture when Layer 2 Switch is 2726 located between AP and Edge Router. 2728 Customer | Access Provider | Service Provider 2729 Premise | | 2731 +------+ +--+ +--------------+ +----------+ +------+ 2732 |WLAN | ---- | | | | |Underlying| |Edge | 2733 |Host/ |-(WLAN)--|AP|-|Layer 2 Switch|-|Technology|-|Router|=>SP 2734 |Router| ---- | | | | | | | |Network 2735 +------+ +--+ +--------------+ +----------+ +------+ 2736 | 2737 +------+ 2738 |AAA | 2739 |Server| 2740 +------+ 2741 Figure 9.1.1 2743 9.1.1.1. IPv6 Related Infrastructure Changes 2745 IPv6 will be deployed in this scenario by upgrading the following 2746 devices to dual-stack: WLAN Host, WLAN Router (if present) and Edge 2747 Router. 2749 9.1.1.2. Addressing 2751 When customer WLAN Router is not present, the WLAN Host has two 2752 possible options to get an IPv6 address via the Edge Router. 2754 A. The WLAN host can get the IPv6 address from Edge router using 2755 stateless auto-configuration [11]. All hosts on the WLAN belong to 2756 the same /64 subnet that is statically configured on the Edge Router. 2757 The IPv6 WLAN Host may use stateless DHCPv6 for obtaining other 2758 information of interest such as DNS and etc. 2760 B. IPv6 WLAN host can use DHCPv6 [10] to get a IPv6 address from the 2761 DHCPv6 server. In this case the DHCPv6 server would be located in 2762 the SP core network and Edge Router would simply act as a DHCP Relay 2763 Agent. This option is similar to what we do today in case of DHCPv4. 2764 It is important to note that host implementation of stateful auto- 2765 configuration is rather limited at this time and this should be 2766 considered if choosing this address assignment option. 2768 When a customer WLAN Router is present, the WLAN Host has two 2769 possible options as well for acquiring IPv6 address. 2771 A. The WLAN Router may be assigned a prefix between /48 and /64 [7] 2772 depending on the SP policy and customer requirements. If the WLAN 2773 Router has multiple networks connected to its interfaces, the network 2774 administrator will have to configure the /64 prefixes to the WLAN 2775 Router interfaces connecting the WLAN Hosts on the customer site. 2777 The WLAN Hosts connected to these interfaces can automatically 2778 configure themselves using stateless auto-configuration with /64 2779 prefix. 2781 B. The WLAN Router can use its link-local address to communicate with 2782 the ER. It can also dynamically acquire through stateless auto- 2783 configuration the address for the link between itself and the ER. 2784 This step is followed by a request via DHCP-PD for a prefix shorter 2785 than /64 that in turn is divided in /64s and assigned to its 2786 interfaces connecting the hosts on the customer site. 2788 In this option, the WLAN Router would act as a requesting router and 2789 Edge Router would act as delegating router. Once prefix is received 2790 by the WLAN Router, it assigns /64 prefixes to each of its interfaces 2791 connecting the WLAN Hosts on the customer site. The WLAN Hosts 2792 connected to these interfaces can automatically configure themselves 2793 using stateless auto-configuration with /64 prefix. Currently the 2794 DHCP-PD functionality cannot be implemented if the DHCP-PD server is 2795 not the ER. If the DHCP-PD messages are relayed, the Edge Router 2796 does not have a mechanism to learn the assigned prefixes and thus 2797 install the proper routes to make that prefix reachable. Work is 2798 being done to address this issue, one idea being to provide the Edge 2799 Router with a snooping mechanism. The uplink to the ISP network is 2800 configured with a /64 prefix as well. 2802 Usually it is easier for the SPs to stay with the DHCP PD and 2803 stateless auto-configuration model and point the clients to a central 2804 server for DNS/domain information, proxy configurations and etc. 2805 Using this model the SP could change prefixes on the fly and the WLAN 2806 Router would simply pull the newest prefix based on the valid/ 2807 preferred lifetime. 2809 The prefixes used for subscriber links and the ones delegated via 2810 DHCP-PD should be planned in a manner that allows maximum 2811 summarization as possible at the Edge Router. 2813 Other information of interest to the host, such as DNS, is provided 2814 through stateful [10] and stateless [9] DHCPv6. 2816 9.1.1.3. Routing 2818 The WLAN Host/Router are configured with a default route that points 2819 to the Edge router. No routing protocols are needed on these devices 2820 which generally have limited resources. 2822 The Edge Router runs the IGP used in the SP network such as OSPFv3 or 2823 IS-IS for IPv6. The connected prefixes have to be redistributed. 2824 Prefix summarization should be done at the Edge Router. When DHCP-PD 2825 is used, the IGP has to redistribute the static routes installed 2826 during the process of prefix delegation. 2828 9.1.2. Layer 3 aware NAP with Layer 3 termination at Access Router 2830 When an Access Router is present between AP and Edge Router, the AP 2831 continues to work as a bridge, bridging IPv4 and IPv6 packets from 2832 WLAN Host/Router to Access Router and vice versa. The Access Router 2833 could be part of SP network or owned by a separate Access Provider. 2835 When WLAN Host initiates the connection, the AAA authentication and 2836 association process with WLAN AP will be similar as explained in 2837 section 9.1.1. 2839 Figure 9.1.2 describes the WLAN architecture when Access Router is 2840 located between AP and Edge Router. 2842 Customer | Access Provider | Service Provider 2843 Premise | | 2845 +------+ +--+ +--------------+ +----------+ +------+ 2846 |WLAN | ---- | | | | |Underlying| |Edge | 2847 |Host/ |-(WLAN)--|AP|-|Access Router |-|Technology|-|Router|=>SP 2848 |Router| ---- | | | | | | | |Network 2849 +------+ +--+ +--------------+ +----------+ +------+ 2850 | 2851 +------+ 2852 |AAA | 2853 |Server| 2854 +------+ 2855 Figure 9.1.2 2857 9.1.2.1. IPv6 Related Infrastructure Changes 2859 IPv6 is deployed in this scenario by upgrading the following devices 2860 to dual-stack: WLAN Host, WLAN Router (if present), Access Router and 2861 Edge Router. 2863 9.1.2.2. Addressing 2865 There are three possible options in this scenario for IPv6 address 2866 assignment: 2868 A. The Edge Router interface facing towards the Access Router is 2869 statically configured with /64 prefix. The Access Router receives/ 2870 configures an /64 prefix on its interface facing towards Edge Router 2871 through stateless auto-configuration. The network administrator will 2872 have to configure the /64 prefixes to the Access Router interface 2873 facing towards the customer premise. The WLAN Host/Router connected 2874 to this interface can automatically configure themselves using 2875 stateless auto-configuration with /64 prefix. 2877 B. This option uses DHCPv6 [10] for IPv6 prefix assignments to the 2878 WLAN Host/Router. There is no use of DHCP PD or stateless auto- 2879 configuration in this option. The DHCPv6 server can be located on 2880 the Access Router, on the Edge Router or somewhere in the SP network. 2881 In this case depending on where the DHCPv6 server is located, Access 2882 Router or the Edge Router would relay the DHCPv6 requests. 2884 C. It can use its link-local address to communicate with the ER. It 2885 can also dynamically acquire through stateless auto-configuration the 2886 address for the link between itself and the ER. This step is 2887 followed by a request via DHCP-PD for a prefix shorter than /64 that 2888 in turn is divided in /64s and assigned to its interfaces connecting 2889 the hosts on the customer site. 2891 In this option, the Access Router would act as a requesting router 2892 and Edge Router would act as delegating router. Once prefix is 2893 received by the Access Router, it assigns /64 prefixes to each of its 2894 interfaces connecting the WLAN Host/Router on customer site. The 2895 WLAN Host/Router connected to these interfaces can automatically 2896 configure themselves using stateless auto-configuration with /64 2897 prefix. Currently the DHCP-PD functionality cannot be implemented if 2898 the DHCP-PD server is not the Edge Router. If the DHCP-PD messages 2899 are relayed, the Edge Router does not have a mechanism to learn the 2900 assigned prefixes and thus install the proper routes to make that 2901 prefix reachable. Work is being done to address this issue, one idea 2902 being to provide the Edge Router with a snooping mechanism. The 2903 uplink to the ISP network is configured with a /64 prefix as well. 2905 It is easier for the SPs to stay with the DHCP PD and stateless auto- 2906 configuration model and point the clients to a central server for 2907 DNS/domain information, proxy configurations and others. Using this 2908 model the provider could change prefixes on the fly and the Access 2909 Router would simply pull the newest prefix based on the valid/ 2910 preferred lifetime. 2912 As mentioned before the prefixes used for subscriber links and the 2913 ones delegated via DHCP-PD should be planned in a manner that allows 2914 maximum summarization possible at the Edge Router. Other information 2915 of interest to the host, such as DNS, is provided through stateful 2916 [10] and stateless [9] DHCPv6. 2918 9.1.2.3. Routing 2920 The WLAN Host/Router are configured with a default route that points 2921 to the Access Router. No routing protocols are needed on these 2922 devices which generally have limited resources. 2924 If the Access Router is owned by an Access Provider, then the Access 2925 Router can have a default route, pointing towards the SP Edge Router. 2926 The Edge Router runs the IGP used in the SP network such as OSPFv3 or 2927 IS-IS for IPv6. The connected prefixes have to be redistributed. If 2928 DHCP-PD is used, with every delegated prefix a static route is 2929 installed by the Edge Router. For this reason the static routes must 2930 be redistributed. Prefix summarization should be done at the Edge 2931 Router. 2933 If the Access Router is owned by the SP, then Access Router will also 2934 run IPv6 IGP and will be part of SP IPv6 routing domain (OSPFv3 or 2935 IS-IS). The connected prefixes have to be redistributed. If DHCP-PD 2936 is used, with every delegated prefix a static route is installed by 2937 the Access Router. For this reason the static routes must be 2938 redistributed. Prefix summarization should be done at the Access 2939 Router. 2941 9.1.3. PPP Based Model 2943 PPP TERMINATED AGGREGATION (PTA) and L2TPv2 ACCESS AGGREGATION (LAA) 2944 models as discussed in sections 7.2.2 and 7.2.3 respectively can also 2945 be deployed in IPv6 WLAN environment. 2947 9.1.3.1. PTA Model in IPv6 WLAN Environment 2949 While deploying the PTA model in IPv6 WLAN environment the Access 2950 Router is Layer 3 aware and it has to be upgraded to support IPv6. 2951 Since the Access Router terminates the PPP sessions initiated by WLAN 2952 Host/Router, it has to support PPPoE with IPv6. 2954 Figure 9.1.3.1 describes the PTA Model in IPv6 WLAN environment. 2956 Customer | Access Provider | Service Provider 2957 Premise | | 2958 +------+ +--+ +--------------+ +----------+ +------+ 2959 |WLAN | ---- | | | | |Underlying| |Edge | 2960 |Host/ |-(WLAN)--|AP|-|Access Router |-|Technology|-|Router|=>SP 2961 |Router| ---- | | | | | | | |Network 2962 +------+ +--+ +--------------+ +----------+ +------+ 2963 | 2964 |---------------------------| +------+ 2965 PPP |AAA | 2966 |Server| 2967 +------+ 2968 Figure 9.1.3.1 2970 9.1.3.1.1. IPv6 Related Infrastructure Changes 2972 IPv6 is deployed in this scenario by upgrading the following devices 2973 to dual-stack: WLAN Host, WLAN Router (if present), Access Router and 2974 Edge Router. 2976 9.1.3.1.2. Addressing 2978 The addressing techniques described in section 7.2.2.2 applies to 2979 IPv6 WLAN PTA scenario as well. 2981 9.1.3.1.3. Routing 2983 The routing techniques described in section 7.2.2.3 applies to IPv6 2984 WLAN PTA scenario as well. 2986 9.1.3.2. LAA Model in IPv6 WLAN Environment 2988 While deploying the LAA model in IPv6 WLAN environment the Access 2989 Router is Layer 3 aware and it has to be upgraded to support IPv6. 2990 The PPP sessions initiated by WLAN Host/Router are forwarded over the 2991 L2TPv2 tunnel to the aggregation point in the SP network. The Access 2992 Router must have the capability to support L2TPv2 for IPv6. 2994 Figure 9.1.3.2 describes the LAA Model in IPv6 WLAN environment 2996 Customer | Access Provider | Service Provider 2997 Premise | | 2999 +------+ +--+ +--------------+ +----------+ +------+ 3000 |WLAN | ---- | | | | |Underlying| |Edge | 3001 |Host/ |-(WLAN)--|AP|-|Access Router |-|Technology|-|Router|=>SP 3002 |Router| ---- | | | | | | | |Network 3003 +------+ +--+ +--------------+ +----------+ +------+ 3004 | 3005 |-------------------------------------------------- | 3006 PPP | 3007 |--------------------- | 3008 L2TPv2 | 3009 +------+ 3010 |AAA | 3011 |Server| 3012 +------+ 3013 Figure 9.1.3.2 3015 9.1.3.2.1. IPv6 Related Infrastructure Changes 3017 IPv6 is deployed in this scenario by upgrading the following devices 3018 to dual-stack: WLAN Host, WLAN Router (if present), Access Router and 3019 Edge Router. 3021 9.1.3.2.2. Addressing 3023 The addressing techniques described in section 7.2.3.2 applies to 3024 IPv6 WLAN LAA scenario as well. 3026 9.1.3.2.3. Routing 3028 The routing techniques described in section 7.2.3.3 applies to IPv6 3029 WLAN LAA scenario as well. 3031 9.2. IPv6 Multicast 3033 The typical multicast services offered are video/audio streaming 3034 where the IPv6 WLAN Host joins a multicast group and receives the 3035 content. This type of service model is well supported through PIM- 3036 SSM which is enabled throughout the SP network. MLDv2 is required 3037 for PIM-SSM support. Vendors can choose to implement features that 3038 allow routers to map MLDv1 group joins to predefined sources. 3040 It is important to note that in the shared wireless environments 3041 multicast can have a significant bandwidth impact. For this reason 3042 the bandwidth allocated to multicast traffic should be limited and 3043 fixed based on the overall capacity of the wireless specification 3044 used 802.11a, 802.11b or 802.11g. 3046 The IPv6 WLAN Hosts can also join desired multicast groups as long as 3047 they are enabled to support MLDv1 or MLDv2. If a WLAN/Access Routers 3048 are used then they have to be enabled to support MLDv1 and MLDv2 in 3049 order to process the requests of the IPv6 WLAN Hosts. The WLAN/ 3050 Access Router should also needs to be enabled to support PIM-SSM in 3051 order to send PIM joins up to the Edge Router. When enabling this 3052 functionality on a WLAN/Access Router, its limited resources should 3053 be taken into consideration. Another option would be for the WLAN/ 3054 Access Router to support MLD proxy routing. 3056 The Edge Router has to be enabled to support MLDv1 and MLDv2 in order 3057 to process the requests coming from IPv6 WLAN Host or WLAN/Access 3058 Router (if present). The Edge Router has also needs to be enabled 3059 for PIM-SSM in order to receive joins from IPv6 WLAN Hosts or WLAN/ 3060 Access Router (if present) and send joins towards the SP core. 3062 MLD authentication, authorization and accounting is usually 3063 configured on the Edge Router in order to enable the SP to do billing 3064 for the content services provided. Further investigation should be 3065 made in finding alternative mechanisms that would support these 3066 functions. 3068 Concerns have been raised in the past related to running IPv6 3069 multicast over WLAN links. Potentially these are same kind of issues 3070 when running any Layer 3 protocol over a WLAN link that has a high 3071 loss-to-signal ratio, where certain frames that are multicast based 3072 are dropped when settings are not adjusted properly. For instance 3073 this behavior is similar to IGMP host membership report, when done on 3074 a WLAN link with high loss-to-signal ratio and high interference. 3076 This problem is inherited to WLAN that can impact both IPv4 and IPv6 3077 multicast packets and not specific to IPv6 multicast. 3079 While deploying WLAN (IPv4 or IPv6), one should adjust their 3080 broadcast/multicast settings if they are in danger of dropping 3081 application dependent frames. These problems are usually caused when 3082 AP are placed too far apart (not following the distance limitations), 3083 high interference and etc. These issues may impact a real multicast 3084 application such as streaming video or basic operation of IPv6 if the 3085 frames were dropped. Basic IPv6 communications uses functions such 3086 as Duplicate Address Detection (DAD), Router and Neighbor 3087 Solicitations (RS, NS), Router and Neighbor Advertisement (RA, NA) 3088 and etc. which could be impacted by the above mentioned issues as 3089 these frames are Layer 2 Ethernet multicast frames. 3091 Please refer to section 7.3 for more IPv6 multicast details. 3093 9.3. IPv6 QoS 3095 Today, QoS is done outside of the WiFi domain but it is nevertheless 3096 important to the overall deployment. 3098 The QoS configuration is particularly relevant on the Edge Router in 3099 order to manage resources shared amongst multiple subscribers 3100 possibly with various service level agreements (SLA). Although, the 3101 WLAN Host/Router and Access Router could also be configured for QoS. 3102 This includes support for appropriate classification criteria which 3103 would need to be implemented for IPv6 unicast and multicast traffic. 3105 On the Edge Router the subscriber facing interfaces have to be 3106 configured to police the inbound customer traffic and shape the 3107 traffic outbound to the customer, based on the SLA. Traffic 3108 classification and marking should also be done on the Edge router in 3109 order to support the various types of customer traffic: data, voice, 3110 video. The same IPv4 QoS concepts and methodologies should be 3111 applied for the IPv6 as well. 3113 It is important to note that when traffic is encrypted end-to-end, 3114 the traversed network devices will not have access to many of the 3115 packet fields used for classification purposes. In these cases 3116 routers will most likely place the packets in the default classes. 3117 The QoS design should take into consideration this scenario and try 3118 to use mainly IP header fields for classification purposes. 3120 9.4. IPv6 Security Considerations 3122 There are limited changes that have to be done for WLAN Host/Router 3123 in order to enhance security. The Privacy extensions [13] for auto- 3124 configuration should be used by the hosts with the same consideration 3125 for host traceability as described in section 7.5. IPv6 firewall 3126 functions should be enabled on the WLAN Host/Router if present. 3128 The ISP provides security against attacks that come form its own 3129 subscribers but it could also implement security services that 3130 protect its subscribers from attacks sourced from the outside of its 3131 network. Such services do not apply at the access level of the 3132 network discussed here. 3134 If the host authentication at hot spots is done using web based 3135 authentication system then the level of security would depend on the 3136 particular implementation. User credential should never be sent as 3137 clear text via HTTP. Secure HTTP (HTTPS) should be used between the 3138 web browser and authentication server. The authentication server 3139 could use RADIUS and LDAP services at the back end. 3141 Authentication is an important aspect of securing WLAN networks prior 3142 to implementing Layer 3 security policies. This would help for 3143 example avoid threats to the ND or stateless auto-configuration 3144 processes. 802.1x provides the means to secure the network access 3145 however, the many types of EAP (PEAP, EAP-TLS, EAP-TTLS, EAP-FAST, 3146 LEAP) and the capabilities of the hosts to support some of the 3147 features might make it difficult to implement a comprehensive and 3148 consistent policy. 3150 If any layer two filters for Ethertypes are in place, the NAP must 3151 permit the IPv6 Ethertype (0X86DD). 3153 The device that is the Layer 3 next hop for the subscribers (Access 3154 or Edge Router) should protect the network and the other subscribers 3155 against attacks by one of the provider customers. For this reason 3156 uRPF and ACLs should be used on all interfaces facing subscribers. 3157 Filtering should be implemented with regard for the operational 3158 requirements of IPv6 [Security considerations for IPv6]. 3160 Authentication and authorization should be used wherever possible. 3162 The Access and the Edge Router should protect their processing 3163 resources against floods of valid customer control traffic such as: 3164 RS, NS, MLD Requests. Rate limiting should be implemented on all 3165 subscriber facing interfaces. The emphasis should be placed on 3166 multicast type traffic as it is most often used by the IPv6 control 3167 plane. 3169 9.5. IPv6 Network Management 3171 The necessary instrumentation (such as MIBs, NetFlow Records, etc) 3172 should be available for IPv6. 3174 Usually, NSPs manage the edge routers by SNMP. The SNMP transport 3175 can be done over IPv4 if all managed devices have connectivity over 3176 both IPv4 and IPv6. This would imply the smallest changes to the 3177 existent network management practices and processes. Transport over 3178 IPv6 could also be implemented and it might become necessary if IPv6 3179 only islands are present in the network. The management stations are 3180 located on the core network. Network Management Applications should 3181 handle IPv6 in a similar fashion to IPv4 however they should also 3182 support features specific to IPv6 (such as Neighbor monitoring). 3184 In some cases service providers manage equipment located on customers 3185 LANs. 3187 10. Broadband Power Line Communications (PLC) 3189 This section describes the IPv6 deployment in Power Line 3190 Communications (PLC) Access Networks. There may be other choices, 3191 but it seems that this is the best model to follow. Lessons learnt 3192 from Cable, Ethernet and even WLAN access networks may be applicable 3193 also. 3195 Power Line Communications are also often called Broadband Power Line 3196 (BPL) and some times even Power Line Telecommunications (PLT). 3198 PLC/BPL can be used for providing, with today's technology, up to 3199 200Mbps (total, upstream+downstream) by means of the power grid. The 3200 coverage is often the last half mile (typical distance from the 3201 Medium-to-Low Voltage transformer to the customer premise meter), and 3202 of course, as an in-home network (which is out of the scope of this 3203 document). 3205 The bandwidth in a given PLC/BPL segment is shared among all the 3206 customers connected to that segment (often the customers connected to 3207 the same medium-to-low voltage transformer). The number of customers 3208 can vary depending on different factors, such as distances and even 3209 countries (from a few customers, just 5-6, up to 100-150). 3211 PLC/BPL could also be used in the Medium Voltage network (often 3212 configured as Metropolitan Area Networks), but this is also out of 3213 the scope of this document, as it will be part of the core network, 3214 not the access one. 3216 10.1. PLC/BPL Access Network Elements 3218 This section describes the different elements commonly used in PLC/ 3219 BPL access networks. 3221 Head End (HE): Router that connects the PLC/BPL access network (the 3222 power grid), located at the medium-to-low voltage transformer, to the 3223 core network. The HE PLC/BPL interface appears to each customer as a 3224 single virtual interface, all of them sharing the same physical 3225 media. 3227 Repeater (RPT): A device which may be required in some circumstances 3228 to improve the signal on the PLC/BPL. This may be the case if there 3229 are many customers in the same segment or building. It is often a 3230 bridge, but it could be also a router if for example there is a lot 3231 of peer-to-peer traffic in a building and due to the master-slave 3232 nature of the PLC/BPL technology, is required to improve the 3233 performance within that segment. For simplicity, in this document, 3234 it will be considered that the RPT is always a transparent layer 2 3235 bridge, so it may be present or not (from the layer 3 point of view). 3237 Customer Premise Equipment (CPE): Modem (internal to the host), 3238 modem/bridge (BCPE), router (RCPE) or any combination among those 3239 (i.e. modem+bridge/router), located at the customer premise. 3241 Edge Router (ER) 3243 Figure 10.1 depicts all the network elements indicated above 3245 Customer Premise | Network Access Provider | Network Service Provider 3247 +-----+ +------+ +-----+ +------+ +--------+ 3248 |Hosts|--| RCPE |--| RPT |--------+ Head +---+ Edge | ISP 3249 +-----+ +------+ +-----+ | End | | Router +=>Network 3250 +--+---+ +--------+ 3251 +-----+ +------+ +-----+ | 3252 |Hosts|--| BCPE |--| RPT |-----------+ 3253 +-----+ +------+ +-----+ 3254 Figure 10.1 3256 The logical topology and design of PLC/BPL is very similar to 3257 Ethernet Broadband Networks as discussed in Section 8. IP 3258 connectivity is typically provided in a Point-to-Point model as 3259 described in section 8.2.1 3261 10.2. Deploying IPv6 in IPv4 PLC/BPL 3263 The most simplistic and efficient model, considering the nature of 3264 the PLC/BPL networks, is to see the network as a point-to-point one 3265 to each customer. Even if several customers share the same physical 3266 media, the traffic is not visible among them because each one uses 3267 different channels, which are in addition encrypted by means of 3DES. 3269 In order to maintain the deployment concepts and business models 3270 proven and used with existing revenue generating IPv4 services, the 3271 IPv6 deployment will match the IPv4 one. Under certain circumstances 3272 where new service types or service needs justify it, IPv4 and IPv6 3273 network architectures could be different. Both approaches are very 3274 similar to those already described for the Ethernet case. 3276 10.2.1. IPv6 Related Infrastructure Changes 3278 In this scenario only the RPT is layer 3 unaware, but the other 3279 devices have to be upgraded to dual stack Hosts, RCPE, Head End, and 3280 Edge Router. 3282 10.2.2. Addressing 3284 The Hosts or the RCPEs have the HE as their Layer 3 next hop. 3286 If there is no RCPE, but instead a BCPE all the hosts on the 3287 subscriber site belong to the same /64 subnet that is statically 3288 configured on the HE. The hosts can use stateless auto-configuration 3289 or stateful DHCPv6 based configuration to acquire an address via the 3290 HE. 3292 If a RCPE is present: 3294 A. It is statically configured with an address on the /64 subnet 3295 between itself and the HE, and with /64 prefixes on the interfaces 3296 connecting the hosts on the customer site. This is not a desired 3297 provisioning method being expensive and difficult to manage. 3299 B. It can use its link-local address to communicate with the HE. It 3300 can also dynamically acquire through stateless auto-configuration the 3301 address for the link between itself and the HE. This step is 3302 followed by a request via DHCP-PD for a prefix shorter than /64 3303 (typically /48 [7]) that in turn is divided in /64s and assigned to 3304 its interfaces connecting the hosts on the customer site. This 3305 should be the preferred provisioning method, being cheaper and easier 3306 to manage. 3308 The Edge Router needs to have a prefix considering that each customer 3309 in general will receive a /48 prefix, and that each HE will 3310 accommodate customers. Consequently each HE will require n x /48 3311 prefixes. 3313 It could be possible to use a kind of Hierarchical Prefix Delegation 3314 to automatically provision the required prefixes and fully auto- 3315 configure the HEs, and consequently reduce the network setup, 3316 operation and maintenance cost. 3318 The prefixes used for subscriber links and the ones delegated via 3319 DHCP-PD should be planned in a manner that allows as much 3320 summarization as possible at the Edge Router. 3322 Other information of interest to the host, such as DNS, is provided 3323 through stateful [10] and stateless [9] DHCPv6. 3325 10.2.3. Routing 3327 If no routers are used on the customer premise, the HE can simply be 3328 configured with a default route that points to the Edge Router. If a 3329 router is used on the customer premise (RCPE) then the HE could also 3330 run an IGP to the ER such as OSPFv3, IS-IS or even RIPng. The 3331 connected prefixes should be redistributed. If DHCP-PD is used, with 3332 every delegated prefix a static route is installed by the HE. For 3333 this reason the static routes must also be redistributed. Prefix 3334 summarization should be done at the HE. 3336 The RCPE requires only a default route pointing to the HE. No 3337 routing protocols are needed on these devices which generally have 3338 limited resources. 3340 The Edge Router runs the IPv6 IGP used in the NSP: OSPFv3 or IS-IS. 3341 The connected prefixes have to be redistributed as well as any RP 3342 other than the ones used on the ER that might be used between the HE 3343 and the ER. 3345 10.3. IPv6 Multicast 3347 The considerations regarding IPv6 Multicast for Ethernet are also 3348 applicable here, in general, but assuming the nature of PLC/BPL being 3349 a shared media. If a lot of Multicast is expected, it may be worth 3350 considering using RPT which are layer 3 aware. In that case, one 3351 extra layer of Hierarchical DHCP-PD could be considered, in order to 3352 facilitate the deployment, operation and maintenance of the network. 3354 10.4. IPv6 QoS 3356 The considerations introduced for QoS in Ethernet are also applicable 3357 here. PLC/BPL networks support QoS, which basically are no different 3358 whether the transport is IPv4 or IPv6. It is necessary to understand 3359 that the specific network characteristics, such as the variability 3360 that may be introduced by electrical noise, towards which the PLC/BPL 3361 network will automatically self-adapt. 3363 10.5. IPv6 Security Considerations 3365 There are no differences in terms of security considerations if 3366 compared with the Ethernet case. 3368 10.6. IPv6 Network Management 3370 Conceptually network management in PLC Networks should be similar to 3371 Broadband Ethernet Networks as described in section 8.6. Although 3372 there could be a need to develop some PLC specific MIBs. 3374 11. Gap Analysis 3376 Several aspects of deploying IPv6 over SP Broadband networks were 3377 highlighted in this document, aspects that require additional work in 3378 order to facilitate native deployments as summarized below: 3380 A. As mentioned in section 6, changes will need to be made to the 3381 DOCSIS specification in order for SPs to deploy native IPv6 over 3382 cable networks. The CM and CMTS will both need to support IPv6 3383 natively in order to forward IPv6 unicast and multicast traffic. 3384 This is required for IPv6 Neighbor Discovery to work over DOCSIS 3385 cable networks. Additional classifiers need to be added to the 3386 DOCSIS specification in order to classify IPv6 traffic at the CM and 3387 CMTS in order to provide QoS. These issues are addressed in a recent 3388 proposal made to Cable Labs for DOCSIS 3.0 [30]. 3390 B. Currently the DHCP-PD functionality cannot be implemented if the 3391 DHCP-PD server is not the Edge Router (CPE's layer 3 next hop). If 3392 the DHCP-PD messages are relayed, the Edge Router does not have a 3393 mechanism to learn the assigned prefixes and thus install the proper 3394 routes to make that prefix reachable. Work needs to be done to 3395 address this issue, one idea being to provide the Edge Router with a 3396 snooping mechanism. The uplink to the ISP network is configured with 3397 a /64 prefix as well. 3399 C. Section 7 stated that current RBE based IPv4 deployment might not 3400 be the best approach for IPv6 where the addressing space available 3401 gives the SP the opportunity to separate the users on different 3402 subnets. The differences between IPv4 RBE and IPv6 RBE were 3403 highlighted in section 7. If however, support and reason is found 3404 for a deployment similar to IPv4 RBE, then the environment becomes 3405 NBMA and the new feature should observe RFC2491 recommendations. 3407 D. Section 7 discussed the constraints imposed on a LAA based IPv6 3408 deployment by the fact that it is expected that the subscribers keep 3409 their assigned prefix regardless of LNS. A deployment approach was 3410 proposed that would maintain the addressing schemes contiguous and 3411 offers prefix summarization opportunities. The topic could be 3412 further investigated for other solutions or improvements. 3414 E. Sections 7 and 8 pointed out the limitations (previously 3415 documented in [31]) in deploying inter-domain ASM however, SSM based 3416 services seem more likely at this time. For such SSM based services 3417 of content delivery (video or Audio), mechanisms are needed to 3418 facilitate the billing and management of listeners. The currently 3419 available feature of MLD AAA is suggested however, other methods or 3420 mechanisms might be developed and proposed. 3422 F. In relation to section 9, concerns have been raised related to 3423 running IPv6 multicast over WLAN links. Potentially these are same 3424 kind of issues when running any Layer 3 protocol over a WLAN link 3425 that has a high loss-to-signal ratio, certain frames that are 3426 multicast based are dropped when settings are not adjusted properly. 3427 For instance this behavior is similar to IGMP host membership report, 3428 when done on a WLAN link with high loss-to-signal ratio and high 3429 interference. This problem is inherited to WLAN that can impact both 3430 IPv4 and IPv6 multicast packets and not specific to IPv6 multicast. 3432 G. The Privacy Extensions were mentioned as a popular means to 3433 provide some form of host security. ISPs can track relatively easily 3434 the prefixes assigned to subscribers. If however the ISPs are 3435 required by regulations to track their users at host address level, 3436 the Privacy Extensions [13] can be implemented only in parallel with 3437 network management tools that could provide traceability of the 3438 hosts. Mechanisms should be defined to implement this aspect of user 3439 management. 3441 H. Tunnels are an effective way to avoid deployment dependencies on 3442 the IPv6 support on platforms that are out of the SP control (GWRs or 3443 CPEs) or over technologies that did not standardize the IPv6 support 3444 yet (cable). They can be used in the following ways: 3446 i. Tunnels directly to the CPE or GWR with public or private IPv4 3447 addresses. 3449 ii. Tunnels directly to hosts with public or private IPv4 addresses. 3450 Recommendations on the exact tunneling mechanisms that can/should be 3451 used for last mile access need to be investigated further and should 3452 be covered in a future IETF draft. 3454 I. Through its larger address space, IPv6 allows SPs to assign fixed, 3455 globally routable prefixes to the links connecting each subscriber. 3457 This approach changes the provisioning methodologies that were used 3458 for IPv4. Static configuration of the IPv6 addresses for all these 3459 links on the Edge Routers or Access Routers might not be a scalable 3460 option. New provisioning mechanisms or features might need to be 3461 developed in order to deal with this issue, such as automatic mapping 3462 of VLAN IDs/PVCs (or other customer-specific information) to IPv6 3463 prefixes. 3465 J. New deployment models are emerging for the Layer 2 portion of the 3466 NAP where individual VLANs are not dedicated to each subscriber. 3467 This approach allows Layer 2 switches to aggregate more then 4096 3468 users. MAC Forced Forwarding [MFF] is an example of such an 3469 implementation where a broadcast domain is turned into a NBMA like 3470 environment by forwarding the frames based on both Source and 3471 Destination MAC addresses. Since these models are being adopted by 3472 the field, the implications of deploying IPv6 in such environments 3473 need to be further investigated. 3475 K. The deployment of IPv6 in continuously evolving access service 3476 models raises some issues that may need further investigation. 3477 Examples of such topics are [36]: 3479 i. Network Service Selection & Authentication(NSSA) mechanisms 3480 working in association with stateless auto-configuration. As an 3481 example, NSSA relevant information such as ISP preference, passwords 3482 or profile ID can be sent by hosts with the RS. 3484 ii. Adding additional information in Router Advertisements to help 3485 access nodes with prefix selection in multi-ISP/multi-homed 3486 environment. 3488 The outcome of solutions to some of these topics ranges from making a 3489 media access capable of supporting native IPv6 (cable) to improving 3490 operational aspects of native IPv6 deployments. 3492 12. IANA Considerations 3494 This document requests no action by IANA. 3496 13. Security Considerations 3498 Please refer to the individual "IPv6 Security Considerations" 3499 technology sections for details. 3501 14. Acknowledgements 3503 We would like to thank Brian Carpenter, Patrick Grossetete, Toerless 3504 Eckert, Madhu Sudan, Shannon McFarland and Benoit Lourdelet, Fred 3505 Baker for their valuable comments. The authors would like to 3506 acknowledge the structure and information guidance provided by the 3507 work of Mickels et al on Transition Scenarios for ISP Networks. 3509 15. References 3511 15.1. Normative References 3513 [1] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and E. 3514 Lear, "Address Allocation for Private Internets", BCP 5, 3515 RFC 1918, February 1996. 3517 [2] Durand, A., Fasano, P., Guardini, I., and D. Lento, "IPv6 3518 Tunnel Broker", RFC 3053, January 2001. 3520 [3] Carpenter, B. and K. Moore, "Connection of IPv6 Domains via 3521 IPv4 Clouds", RFC 3056, February 2001. 3523 [4] Conta, A. and S. Deering, "Generic Packet Tunneling in IPv6 3524 Specification", RFC 2473, December 1998. 3526 [5] Carpenter, B. and C. Jung, "Transmission of IPv6 over IPv4 3527 Domains without Explicit Tunnels", RFC 2529, March 1999. 3529 [6] Huitema, C., Austein, R., Satapati, S., and R. van der Pol, 3530 "Evaluation of IPv6 Transition Mechanisms for Unmanaged 3531 Networks", RFC 3904, September 2004. 3533 [7] IAB and IESG, "IAB/IESG Recommendations on IPv6 Address 3534 Allocations to Sites", RFC 3177, September 2001. 3536 [8] Hinden, R. and S. Deering, "Internet Protocol Version 6 (IPv6) 3537 Addressing Architecture", RFC 3513, April 2003. 3539 [9] Droms, R., "Stateless Dynamic Host Configuration Protocol 3540 (DHCP) Service for IPv6", RFC 3736, April 2004. 3542 [10] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., and M. 3543 Carney, "Dynamic Host Configuration Protocol for IPv6 3544 (DHCPv6)", RFC 3315, July 2003. 3546 [11] Thomson, S. and T. Narten, "IPv6 Stateless Address 3547 Autoconfiguration", RFC 2462, December 1998. 3549 [12] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic Host 3550 Configuration Protocol (DHCP) version 6", RFC 3633, 3551 December 2003. 3553 [13] Narten, T. and R. Draves, "Privacy Extensions for Stateless 3554 Address Autoconfiguration in IPv6", RFC 3041, January 2001. 3556 [14] Mamakos, L., Lidl, K., Evarts, J., Carrel, D., Simone, D., and 3557 R. Wheeler, "A Method for Transmitting PPP Over Ethernet 3558 (PPPoE)", RFC 2516, February 1999. 3560 [15] Gross, G., Kaycee, M., Lin, A., Malis, A., and J. Stephens, 3561 "PPP Over AAL5", RFC 2364, July 1998. 3563 [16] Haskin, D. and E. Allen, "IP Version 6 over PPP", RFC 2472, 3564 December 1998. 3566 [17] Narten, T., Nordmark, E., and W. Simpson, "Neighbor Discovery 3567 for IP Version 6 (IPv6)", RFC 2461, December 1998. 3569 [18] Meyer, D. and P. Lothberg, "GLOP Addressing in 233/8", 3570 RFC 2770, February 2000. 3572 [19] St. Johns, M., "DOCSIS Cable Device MIB Cable Device Management 3573 Information Base for DOCSIS compliant Cable Modems and Cable 3574 Modem Termination Systems", RFC 2669, August 1999. 3576 [20] Droms, R., "DNS Configuration options for Dynamic Host 3577 Configuration Protocol for IPv6 (DHCPv6)", RFC 3646, 3578 December 2003. 3580 [21] Fenner, B. and D. Meyer, "Multicast Source Discovery Protocol 3581 (MSDP)", RFC 3618, October 2003. 3583 [22] Baker, F. and P. Savola, "Ingress Filtering for Multihomed 3584 Networks", BCP 84, RFC 3704, March 2004. 3586 [23] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in 3587 IPv6", RFC 3775, June 2004. 3589 [24] Lind, M., Ksinant, V., Park, S., Baudot, A., and P. Savola, 3590 "Scenarios and Analysis for Introducing IPv6 into ISP 3591 Networks", RFC 4029, March 2005. 3593 15.2. Informative References 3595 [25] De Clercq, J., Ooms, D., Prevost, S., and F. Le Faucheur, 3596 "Connecting IPv6 Islands across IPv4 Clouds with 3597 BGP(draft-ooms-v6ops-bgp-tunnel-04.txt)", October 2004. 3599 [26] Templin, F., Gleeson, T., Talwar, M., and D. Thaler, "Intra- 3600 Site Automatic Tunnel Addressing Protocol 3601 (ISATAP)(draft-ietf-ngtrans-isatap-12.txt)", January 2003. 3603 [27] Palet, J., Diaz, M., and P. Savola, "Analysis of IPv6 Tunnel 3604 End-point Discovery 3605 Mechanisms(draft-palet-v6ops-tun-auto-disc-03.txt)", 3606 January 2005. 3608 [28] Palet, J., Olvera, C., and D. Fernandez, "Forwarding Protocol 3609 41 in NAT Boxes(draft-palet-v6ops-proto41-nat-03.txt)", 3610 October 2003. 3612 [29] Nordmark, E. and R. Gilligan, "Basic Transition Mechanisms for 3613 IPv6 Hosts and Routers(draft-ietf-v6ops-mech-v2-06.txt)", 3614 September 2004. 3616 [30] Cisco, Systems., "DOCSIS 3.0 Proposal", April 2005. 3618 [31] Savola, P., "IPv6 Multicast Deployment 3619 Issues(draft-mboned-ipv6-multicast-issues.txt)", April 2004. 3621 [32] Cable, Labs., "Radio Frequency Interface Specification SP- 3622 RFIv2.0-I02-020617", June 2002. 3624 [33] Bhaskar, N., Gall, A., and S. Venaas, "Bootstrap Router (BSR) 3625 Mechanism for PIM(draft-ietf-pim-sm-bsr-04.txt)", January 2005. 3627 [34] Palet, J., Nielsent, K., Parent, F., Durand, A., 3628 Suryanarayanan, R., and P. Savola, "Goals for Tunneling 3629 Configuration(draft-palet-v6tc-goals-tunneling-00.txt)", 3630 August 2005. 3632 [35] Convery, S. and D. Miller, "IPv6 and IPv4 Threat Comparison and 3633 Best-Practice Evaluation", March 2004. 3635 [36] Wen, H., Zhu, X., Jiang, Y., and R. Yan, "The deployment of 3636 IPv6 stateless auto-configuration in access network", 3637 June 2005. 3639 Authors' Addresses 3641 Salman Asadullah 3642 Cisco Systems 3643 170 West Tasman Drive 3644 San Jose, CA 95134 3645 USA 3647 Phone: 408 526 8982 3648 Email: sasad@cisco.com 3650 Adeel Ahmed 3651 Cisco Systems 3652 2200 East President George Bush Turnpike 3653 Richardson, TX 75082 3654 USA 3656 Phone: 469 255 4122 3657 Email: adahmed@cisco.com 3659 Ciprian Popoviciu 3660 Cisco Systems 3661 7025-6 Kit Creek Road 3662 Research Triangle Park, NC 27709 3663 USA 3665 Phone: 919 392 3723 3666 Email: cpopovic@cisco.com 3668 Pekka Savola 3669 CSC - Scientific Computing Ltd. 3670 Espoo 3671 Finland 3673 Email: psavola@funet.fi 3674 Jordi Palet Martinez 3675 Consulintel 3676 San Jose Artesano, 1 3677 Alcobendas, Madrid E-28108 3678 Spain 3680 Phone: +34 91 151 81 99 3681 Email: jordi.palet@consulintel.es 3683 Intellectual Property Statement 3685 The IETF takes no position regarding the validity or scope of any 3686 Intellectual Property Rights or other rights that might be claimed to 3687 pertain to the implementation or use of the technology described in 3688 this document or the extent to which any license under such rights 3689 might or might not be available; nor does it represent that it has 3690 made any independent effort to identify any such rights. Information 3691 on the procedures with respect to rights in RFC documents can be 3692 found in BCP 78 and BCP 79. 3694 Copies of IPR disclosures made to the IETF Secretariat and any 3695 assurances of licenses to be made available, or the result of an 3696 attempt made to obtain a general license or permission for the use of 3697 such proprietary rights by implementers or users of this 3698 specification can be obtained from the IETF on-line IPR repository at 3699 http://www.ietf.org/ipr. 3701 The IETF invites any interested party to bring to its attention any 3702 copyrights, patents or patent applications, or other proprietary 3703 rights that may cover technology that may be required to implement 3704 this standard. Please address the information to the IETF at 3705 ietf-ipr@ietf.org. 3707 Disclaimer of Validity 3709 This document and the information contained herein are provided on an 3710 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 3711 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 3712 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 3713 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 3714 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 3715 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 3717 Copyright Statement 3719 Copyright (C) The Internet Society (2005). This document is subject 3720 to the rights, licenses and restrictions contained in BCP 78, and 3721 except as set forth therein, the authors retain all their rights. 3723 Acknowledgment 3725 Funding for the RFC Editor function is currently provided by the 3726 Internet Society.