idnits 2.17.1 draft-ietf-v6ops-bb-deployment-scenarios-03.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 3726. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 3703. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 3710. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 3716. ** 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 9 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (June 2005) is 6890 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 3475 == Unused Reference: '12' is defined on line 3556, but no explicit reference was found in the text == Unused Reference: '16' is defined on line 3570, but no explicit reference was found in the text == Unused Reference: '20' is defined on line 3583, 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: December 3, 2005 C. Popoviciu 5 Cisco Systems 6 P. Savola 7 CSC/FUNET 8 J. Palet 9 Consulintel 10 June 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 December 3, 2005. 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 . . . . . . . . . . . . . . . . . . . . . 8 68 5.1 Access over Tunnels - Customers with Public IPv4 Address . 9 69 5.2 Access over Tunnels - Customers with Private IPv4 70 Address . . . . . . . . . . . . . . . . . . . . . . . . . 9 71 5.3 Transition a Portion of the IPv4 Infrastructure . . . . . 10 72 6. Broadband Cable Networks . . . . . . . . . . . . . . . . . . 11 73 6.1 Broadband Cable Network Elements . . . . . . . . . . . . . 11 74 6.2 Deploying IPv6 in Cable Networks . . . . . . . . . . . . . 12 75 6.2.1 Deploying IPv6 in a Bridged CMTS Network . . . . . . . 13 76 6.2.2 Deploying IPv6 in a Routed CMTS Network . . . . . . . 16 77 6.2.3 IPv6 Multicast . . . . . . . . . . . . . . . . . . . . 25 78 6.2.4 IPv6 QoS . . . . . . . . . . . . . . . . . . . . . . . 26 79 6.2.5 IPv6 Security Considerations . . . . . . . . . . . . . 27 80 6.2.6 IPv6 Network Management . . . . . . . . . . . . . . . 28 81 7. Broadband DSL Networks . . . . . . . . . . . . . . . . . . . 29 82 7.1 DSL Network Elements . . . . . . . . . . . . . . . . . . . 29 83 7.2 Deploying IPv6 in IPv4 DSL Networks . . . . . . . . . . . 30 84 7.2.1 Point-to-Point Model . . . . . . . . . . . . . . . . . 31 85 7.2.2 PPP Terminated Aggregation (PTA) Model . . . . . . . . 33 86 7.2.3 L2TPv2 Access Aggregation (LAA) Model . . . . . . . . 36 87 7.2.4 Hybrid Model for IPv4 and IPv6 Service . . . . . . . . 39 88 7.3 IPv6 Multicast . . . . . . . . . . . . . . . . . . . . . . 41 89 7.3.1 ASM Based Deployments . . . . . . . . . . . . . . . . 41 90 7.3.2 SSM Based Deployments . . . . . . . . . . . . . . . . 42 91 7.4 IPv6 QoS . . . . . . . . . . . . . . . . . . . . . . . . . 43 92 7.5 IPv6 Security Considerations . . . . . . . . . . . . . . . 43 93 7.6 IPv6 Network management . . . . . . . . . . . . . . . . . 44 94 8. Broadband Ethernet Networks . . . . . . . . . . . . . . . . 45 95 8.1 Ethernet Access Network Elements . . . . . . . . . . . . . 45 96 8.2 Deploying IPv6 in IPv4 Broadband Ethernet Networks . . . . 46 97 8.2.1 Point-to-Point Model . . . . . . . . . . . . . . . . . 47 98 8.2.2 PPP Terminated Aggregation (PTA) Model . . . . . . . . 48 99 8.2.3 L2TPv2 Access Aggregation (LAA) Model . . . . . . . . 51 100 8.2.4 Hybrid Model for IPv4 and IPv6 Service . . . . . . . . 52 101 8.3 IPv6 Multicast . . . . . . . . . . . . . . . . . . . . . . 55 102 8.4 IPv6 QoS . . . . . . . . . . . . . . . . . . . . . . . . . 56 103 8.5 IPv6 Security Considerations . . . . . . . . . . . . . . . 56 104 8.6 IPv6 Network Management . . . . . . . . . . . . . . . . . 57 105 9. Wireless LAN . . . . . . . . . . . . . . . . . . . . . . . . 58 106 9.1 WLAN Deployment Scenarios . . . . . . . . . . . . . . . . 58 107 9.1.1 Layer 2 NAP with Layer 3 termination at NSP Edge 108 Router . . . . . . . . . . . . . . . . . . . . . . . . 59 109 9.1.2 Layer 3 aware NAP with Layer 3 termination at 110 Access Router . . . . . . . . . . . . . . . . . . . . 62 111 9.1.3 PPP Based Model . . . . . . . . . . . . . . . . . . . 64 112 9.2 IPv6 Multicast . . . . . . . . . . . . . . . . . . . . . . 66 113 9.3 IPv6 QoS . . . . . . . . . . . . . . . . . . . . . . . . . 68 114 9.4 IPv6 Security Considerations . . . . . . . . . . . . . . . 68 115 9.5 IPv6 Network Management . . . . . . . . . . . . . . . . . 69 116 10. Broadband Power Line Communications (PLC) . . . . . . . . . 70 117 10.1 PLC/BPL Access Network Elements . . . . . . . . . . . . 70 118 10.2 Deploying IPv6 in IPv4 PLC/BPL . . . . . . . . . . . . . 71 119 10.2.1 IPv6 Related Infrastructure Changes . . . . . . . . 71 120 10.2.2 Addressing . . . . . . . . . . . . . . . . . . . . . 72 121 10.2.3 Routing . . . . . . . . . . . . . . . . . . . . . . 72 122 10.3 IPv6 Multicast . . . . . . . . . . . . . . . . . . . . . 73 123 10.4 IPv6 QoS . . . . . . . . . . . . . . . . . . . . . . . . 73 124 10.5 IPv6 Security Considerations . . . . . . . . . . . . . . 73 125 10.6 IPv6 Network Management . . . . . . . . . . . . . . . . 73 126 11. Gap Analysis . . . . . . . . . . . . . . . . . . . . . . . . 74 127 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . 76 128 13. Security Considerations . . . . . . . . . . . . . . . . . . 76 129 14. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 76 130 15. References . . . . . . . . . . . . . . . . . . . . . . . . . 76 131 15.1 Normative References . . . . . . . . . . . . . . . . . . 76 132 15.2 Informative References . . . . . . . . . . . . . . . . . 78 133 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 79 134 Intellectual Property and Copyright Statements . . . . . . . 81 136 1. Introduction 138 With the exponential growth of the Internet and increasing number of 139 end users, SPs are looking for new ways to evolve their current 140 network architecture to meet the needs of Internet ready appliances, 141 new applications and services. IPv6 is designed to enable SPs to 142 meet these challenges and provide new services to their customers. 144 As the number of devices per BB user increase exponentially 145 worldwide, Cable, DSL, Ethernet to the Home, Wireless, PLC/BPL and 146 other always-on access technologies can benefit from the huge address 147 range [8] of IPv6. Other benefits of IPv6 include the capability to 148 enhance end-to-end security, mobile communications, and ease system 149 management burdens. Some examples include peer-to-peer communication 150 without NAT traversal problems, being able to access securely devices 151 at home from work, enhanced IP Mobility [23] and so on. 153 Therefore SPs are aggressively evaluating the capabilities of IPv6 to 154 meet these needs. Some countries have taken a lead role in this race 155 and moved from testing and evaluation to real deployments of IPv6 in 156 the BB arena. Japan is a prime example along with other countries 157 that are looking at moving towards large scale production deployments 158 of IPv6. 160 The SPs are deploying tunneling mechanisms to transport IPv6 over 161 their existing IPv4 networks as a start as well as deploying native 162 IPv6 where possible. Deployment of tunneling solutions is simpler, 163 easier and more economical to start the IPv6 services, as they 164 require minimal investments and network infrastructure changes in 165 current SP model. Depending on customer needs and requirements a 166 native IPv6 deployment option might be more scalable and provide 167 required service performance. 169 1.1 Common Terminology 171 CPE: Customer Premise Equipment 173 GWR: Gateway Router 175 ISP: Internet Service Provider 177 NAP: Network Access Provider 179 NSP: Network Service Provider 181 SP: Service Provider 183 2. IPv6 Based BB Services 185 At this point IPv6 based services are seen as a differentiator that 186 enables SPs to take advantage of the large IPv6 address space to the 187 extent that subscribers get up to fixed /48 prefixes versus the 188 single, temporary IPv4 addresses. Such resources allow the SPs to 189 better position themselves against the competition. The IPv6 190 deployments can be seen as a driver for lower service support costs 191 by eliminating NAT with its negative impact on applications and its 192 complex behavior. Another reason of IPv6 being popular in some 193 countries might be the government driven financial incentives and 194 favorable legislation towards the ISPs who are deploying IPv6. 196 NTT East, Japan started a commercial dual-stack (devices capable of 197 forwarding IPv4 and IPv6 packets) IPv6 unicast service option early 198 this year for its ADSL and FTTH subscribers, under the name of 199 FLETS.Net [25]. For these users the IPv6 addresses are dedicated 200 (/64 per user) and are used when needed. However, this IPv6 service 201 is available only to the NTT-East ADSL and FTTH subscribers who are 202 part of FLETS.NET network and at this point does not provide 203 connectivity to the IPv6 Internet. 205 Some ISPs that are currently providing IPv4 based Multicast and VoIP 206 services are evaluating IPv6 to improve and expand their service. 207 The Multicast services consist of video and audio streaming of 208 several programs (streams). The content provider delivers these 209 streams to BB subscribers. One of today's challenges is the fact 210 that when done through IPv4, there is generally a single device 211 directly attached to the CPE that receives the Multicast stream. By 212 moving to IPv6, ISP should be capable to provide multiple streams to 213 multiple devices on the customer site. 215 For instance in Japan, Cable TV and dish services are not very 216 popular, the users expect content mostly through the broadcasted, 217 free programs (traditional TV). In case of BB users however, they 218 can get additional content through their SP, which can be delivered 219 at a reasonable priced for 20 Mbps or 10/100 Mbps of bandwidth. 220 Users sign up with a content provider that is multicasting several 221 channels of video and audio. A subscriber would join the multicast 222 group of interest (after authentication) and will start receiving the 223 stream(s). An example of a video stream could be Disney movies and 224 an example of an audio stream could be Karaoke (part of same *,G 225 group). Similar to Cable TV, where customers sign up and pay for 226 single programs or packages of programs. 228 SPs are also offering IPv6 services over wireless links using 802.11 229 compliant WiFi Hot Spots. This enables users to take notebook PCs 230 and PDAs (Windows 2003 supports IPv6 capable Internet Explorer and 231 Media Player 9) along with them and connect to the Internet from 232 various locations without the restriction of staying indoors. 234 3. Scope of the Document 236 This document presents the options available in deploying IPv6 237 services in the access portion of a BB Service Provider network 238 namely Cable/HFC, BB Ethernet, xDSL, WLAN and PLC/BPL. 240 This document briefly discusses the other elements of a provider 241 network as well. It provides different viable IPv6 deployment and 242 integration techniques and models for each of the above mentioned BB 243 technologies individually. The example list is not exhaustive but it 244 tries to be representative. 246 This document analyzes, how all the important parts of current IPv4 247 based Cable/HFC, BB Ethernet, xDSL, WLAN and PLC/BPL networks will 248 behave when IPv6 is integrated and deployed. 250 The following important pieces are discussed: 252 A. Available tunneling options 254 B. Devices that would require to be upgraded to support IPv6 256 C. Available IPv6 address assignment techniques and their use 258 D. Possible IPv6 Routing options and their use 260 E. IPv6 unicast and multicast packet transmission 262 F. Required IPv6 QoS parameters 264 G. Required IPv6 Security parameters 266 H. Required IPv6 Network Management parameters 268 It is important to note that the addressing rules provided throughout 269 this document represent an example that follows the current 270 assignment policies and recommendations of the registries. They can 271 be however adapted to the network and business model needs of the 272 ISPs. 274 The scope of the document is to advise on the ways of upgrading an 275 existing infrastructure to support IPv6 services. The recommendation 276 to upgrade a device to dual-stack does not stop an SP from adding a 277 new device to its network to perform the necessary IPv6 functions 278 discussed. The costs involved could be offset by lower impact on the 279 existing IPv4 services. 281 4. Core/Backbone Network 283 This section intends to briefly discuss some important elements of a 284 provider network tied to the deployment of IPv6. A more detailed 285 description of the core network is provided in other documents [24]. 287 There are two networks identified in the Broadband deployments: 289 A. Access Provider Network: This network provides the broadband 290 access and aggregates the subscribers. The subscriber traffic is 291 handed over to the Service Provider at Layer 2 or 3. 293 B. Service Provider Network: This network provides Intranet and 294 Internet IP connectivity for the subscribers. 296 The Service Provider network structure beyond the Edge routers that 297 interface with the Access provider is beyond the scope of this 298 document. 300 4.1 Layer 2 Access Provider Network 302 The Access Provider can deploy a Layer 2 network and perform no 303 routing of the subscriber traffic to the SP. The devices that 304 support each specific access technology are aggregated into a highly 305 redundant, resilient and scalable layer two core. The network core 306 can involve various technologies such as Ethernet, ATM etc. The 307 Service Provider Edge Router connects to the Access Provider core. 309 In this type of a network the impact of deploying IPv6 is minimal. 310 The network is transparent to the Layer 3 protocol. The only 311 possible changes would come with the intent of filtering and 312 monitoring IPv6 traffic based on layer 2 information such as IPv6 313 Ether Type Protocol ID (0x86DD) or IPv6 multicast specific MAC 314 addresses (3333.xxxx.xxxx). 316 4.2 Layer 3 Access Provider Network 318 The Access Provider can choose to terminate the Layer 2 domain and 319 route the IP traffic to the Service Provider network. Access Routers 320 are used to aggregate the subscriber traffic and route it over a 321 Layer 3 core to the SP Edge Routers. In this case the impact of the 322 IPv6 deployment is significant. 324 The case studies in this document only present the significant 325 network elements of such a network: Customer Premise Equipment, 326 Access Router and Edge Router. In real networks the link between the 327 Access Router and the Edge Router involves other routers that are 328 part of the aggregation and the core layer of the Access Provider 329 network. 331 The Access Provider can forward the IPv6 traffic through its layer 3 332 core in three possible ways: 334 A. IPv6 Tunneling: As a temporary solution, the Access Providers can 335 choose to use a tunneling mechanism to forward the subscriber IPv6 336 traffic to the Service Provider Edge Router. This approach has the 337 least impact on the Access Provider network however, as the number of 338 users increase and the amount of IPv6 traffic grows, the ISP will 339 have to evolve to one of the scenarios listed below. 341 B. Native IPv6 Deployment: The Access Provider routers are upgraded 342 to support IPv6 and can become dual-stack. In a dual-stack network 343 an IPv6 IGP such as OSPFv3 or IS-IS is enabled. [24] discusses the 344 IGP selection options with their benefits and drawbacks. 346 C. MPLS 6PE Deployment [26]: If the Access Provider is running MPLS 347 in its IPv4 core it could use 6PE to forward IPv6 traffic over it. 348 In this case only a subset of routers close to the edge of the 349 network need to be IPv6 aware. With this approach BGP becomes 350 important in order to support 6PE. 352 The 6PE approach has the advantage of having minimal impact on the 353 Access Provider network. Fewer devices need to be upgraded and 354 configured while the MPLS core continues to switch the traffic un- 355 aware of the fact that it transports both IPv4 and IPv6 traffic. 6PE 356 should be leveraged only if MPLS is already deployed in the network. 357 At the time of writing this document, a major disadvantage of the 6PE 358 solution is the fact that it does not support multicast IPv6 traffic. 360 The native approach has the advantage of supporting IPv6 multicast 361 traffic but it may imply a significant impact on the IPv4 operational 362 network from software, configuration and possibly hardware upgrade 363 perspective. 365 More detailed Core Network deployment recommendations are discussed 366 in other documents [24]. The handling of IPv6 traffic in the Core of 367 the Access Provider Network will not be discussed for the remainder 368 of this document. 370 5. Tunneling Overview 372 Service Providers might not be able to deploy native IPv6 today due 373 to the cost associated with HW and SW upgrades, the infrastructure 374 changes needed to their current network and the current demand for 375 the service. For these reasons, some SPs might choose tunneling 376 based transition mechanisms to start an IPv6 service offering and 377 move to native IPv6 deployment at a later time. 379 Several tunneling mechanisms were developed specifically to transport 380 IPv6 over existing IPv4 infrastructures. Several of them have been 381 standardized and their use depends on the existing SP IPv4 network 382 and the structure of the IPv6 service. The requirements for the most 383 appropriate mechanisms are described in [35] with more updates to 384 follow. Deploying IPv6 using tunneling techniques can imply as 385 little changes to the network as upgrading SW on tunnel end points 386 (TEP). A Service Provider could use tunneling to deploy IPv6 in the 387 following scenarios: 389 5.1 Access over Tunnels - Customers with Public IPv4 Address 391 If the customer is a residential user, it can initiate the tunnel 392 directly from the IPv6 capable host to a tunnel termination router 393 located in the NAP or ISP network. The tunnel type used should be 394 decided by the SP but it should take into consideration its 395 availability on commonly used software running on the host machine. 396 Out of the many tunneling mechanisms developed [2], [3], [4], [27], 397 [30], [5] some are more popular than the others. 399 If the end customer has a GWR installed, then it could be used to 400 originate the tunnel and thus offer native IPv6 access to multiple 401 hosts on the customer network. In this case the GWR would need to be 402 upgraded to dual-stack in order to support IPv6. The GWR can be 403 owned by the customer or by the SP 405 5.2 Access over Tunnels - Customers with Private IPv4 Address 407 If the end customer receives a private IPv4 address and needs to 408 initiate a tunnel through NAT, techniques like 6to4 may not work 409 since they rely on public IPv4 address. In this case, unless the 410 existing GWRs support protocol-41-forwarding [29], the end user might 411 have to use tunnels that can operate through NATs (such as Teredo 412 tunnel [30]). Most GWRs support protocol-41-forwarding which means 413 that hosts can initiate the tunnels in which case the GWR is not 414 affected by the IPv6 service. 416 The customer has the option to initiate the tunnel from the device 417 (GWR) that performs the NAT functionality, similar to the GWR 418 scenario discussed in section 5.1. This will imply HW replacement or 419 SW upgrade and a native IPv6 environment behind the GWR. 421 It is important to note that the customers of a Service Provider can 422 choose to establish tunnels to publicly available and free tunnel 423 services. Even though the quality of such services might not be 424 high, they provide free IPv6 access. In designing their IPv6 425 services, the SPs should take into considerations such options 426 available to their potential customers. The IPv6 deployment should 427 support services (like multicast, VoIPv6 etc) and a level of quality 428 that would make the access through the SP worthwhile to potential 429 subscribers. 431 It is also worth observing that initiating an IPv6 tunnel over IPv4 432 through already established IPv4 IPSec sessions would provide a 433 certain level of security to the IPv6 traffic. 435 5.3 Transition a Portion of the IPv4 Infrastructure 437 Tunnels can be used to transport the IPv6 traffic across a defined 438 segment of the network. As an example, the customer might connect 439 natively to the Network Access Provider and a tunnel is used to 440 transit the traffic over IPv4 to the ISP. In this case the tunnel 441 choice depends on its capabilities (for example, whether it supports 442 multicast or not), routing protocols used (there are several types 443 that can transport layer 2 messages such as GRE, L2TPv3 or 444 Pseudowire), manage-ability and scalability (dynamic versus static 445 tunnels). 447 This scenario implies that the access portion of the network has been 448 upgraded to support dual stack so the savings provided by tunneling 449 in this scenario are very small compared with the previous two 450 scenarios. Depending on the number of sites requiring the service 451 and considering the expenses required to manage the tunnels (some 452 tunnels are static while others are dynamic [28]) in this case, the 453 SPs might find the native approach worth the additional investments. 455 In all the scenarios listed above the tunnel selection process should 456 consider the IPv6 multicast forwarding capabilities if such service 457 is planned. As an example, 6to4 tunnels do not support IPv6 458 multicast traffic. 460 The operation, capabilities and deployment of various tunnel types 461 has been discussed extensively in the documents referenced earlier as 462 well as in [30], [6]. Details of a tunnel based deployment are 463 offered in the next section of this document (section 6). In the 464 case of Cable Access where the current DOCSIS specifications do not 465 provide support for native IPv6 access. Although sections 7, 8, 9 466 and 10 focus on a native IPv6 deployments over DSL, FTTH, Wireless 467 and PLC/BPL because this approach is fully supported today, tunnel 468 based solutions are also possible in these cases based on the 469 guidelines of this section and some of the recommendations provided 470 in section 6. 472 6. Broadband Cable Networks 474 This section describes the infrastructure that exists today in cable 475 networks providing BB services to the home. It also describes IPv6 476 deployment options in these cable networks. 478 DOCSIS standardizes and documents the operation of data over Cable 479 Networks. The current version of DOCSIS has limitations that do not 480 allow for a smooth implementation of native IPv6 transport. Some of 481 these limitations are discussed in this section. For this reason, 482 the IPv6 deployment scenarios discussed in this section for the 483 existent Cable Networks are tunnel based. The tunneling examples 484 presented here could also be applied to the other BB technologies 485 described in sections 7, 8, 9 and 10. 487 6.1 Broadband Cable Network Elements 489 Broadband cable networks are capable of transporting IP traffic to/ 490 from users to provide high speed Internet access and VOIP services. 491 The mechanism of transporting IP traffic over cable networks is 492 outlined in the DOCSIS specification [33]. 494 Here are some of the key elements of a Cable network: 496 Cable (HFC) Plant: Hybrid Fiber Coaxial plant, used as the underlying 497 transport 499 CMTS: Cable Modem Termination System (can be a Layer 2 bridging or 500 Layer 3 routing CMTS) 502 GWR: Residential Gateway Router (provides Layer 3 services to hosts) 504 Host: PC, notebook etc. which is connected to the CM or GWR 506 CM: Cable Modem 508 ER: Edge Router 510 MSO: Multiple Service Operator 512 Data Over Cable Service Interface Specification (DOCSIS): The 513 standards defining how data should be carried over cable networks. 515 Figure 6.1 illustrates the key elements of a Cable Network 517 |--- ACCESS ---||------ HFC ------||----- Aggregation / Core -----| 519 +-----+ +------+ 520 |Host |--| GWR | 521 +-----+ +--+---+ 522 | _ _ _ _ _ _ 523 +------+ | | 524 | CM |---| | 525 +------+ | | 526 | HFC | +------+ +--------+ 527 | | | | | Edge | 528 +-----+ +------+ | Network |---| CMTS |---| |=>ISP 529 |Host |--| CM |---| | | | | Router | Network 530 +-----+ +--+---+ | | +------+ +--------+ 531 |_ _ _ _ _ _| 532 +------+ | 533 +-----+ | GWR/ | | 534 |Host |--| CM |---------+ 535 +-----+ | | 536 +------+ Figure 6.1 538 6.2 Deploying IPv6 in Cable Networks 540 One of the motivators for an MSO to deploy IPv6 over their Cable 541 Network is to ease management burdens. IPv6 can be enabled on the 542 CM, CMTS and ER for management purposes. Currently portions of the 543 cable infrastructure use [1] IPv4 addresses; however, there are a 544 finite number of those. Thus, IPv6 could have utility in the cable 545 space implemented on the management plane initially and later on 546 focused on the data plane for end user services. For more details on 547 using IPv6 for management in Cable Networks please refer to section 548 6.6.1. 550 There are two different deployment modes in current cable networks: a 551 bridged CMTS environment and a routed CMTS environment. IPv6 can be 552 deployed in both of these environments. 554 1. Bridged CMTS Network 556 In this scenario, both the CM and CMTS bridge all data traffic. 557 Traffic to/from host devices is forwarded through the cable network 558 to the ER. The ER then routes traffic through the ISP network to the 559 Internet. The CM and CMTS support a certain degree of Layer 3 560 functionality for management purposes. 562 2. Routed CMTS Network 564 In a routed network, the CMTS forwards IP traffic to/from hosts based 565 on Layer 3 information using the IP source/destination address. The 566 CM acts as a Layer-2 bridge for forwarding data traffic and supports 567 some Layer 3 functionality for management purposes. 569 Some of the factors that hinder deployment of native IPv6 in current 570 routed and bridged cable networks include: 572 A. Problems with IPv6 Neighbor Discovery (ND) on CM and CMTS. These 573 devices rely on IGMP join messages to track membership of hosts that 574 are part of a particular IP Multicast group. In order to support ND 575 the CM and CMTS will need to support IGMPv3/MLDv2 or v1 snooping. 577 B. Classification of IPv6 traffic in the upstream and downstream 578 direction. The CM and CMTS will need to support classification of 579 IPv6 packets in order to give them the appropriate priority and QoS. 580 Without proper classification all IPv6 traffic will need to be sent 581 best effort (BE) which can cause problems when deploying services 582 like VOIP and IP Multicast video. 584 C. Changes need to be made to the DOCSIS specification to include 585 support for IPv6 on the CM and CMTS. This is imperative for 586 deploying native IPv6 over cable networks. 588 Due to the above mentioned limitations in deployed cable networks, 589 the only available option to cable operators is to use tunneling 590 techniques in order to transport IPv6 traffic over their current IPv4 591 infrastructure. The following sections will cover these deployment 592 scenarios in more detail. 594 6.2.1 Deploying IPv6 in a Bridged CMTS Network 596 In IPv4 the CM and CMTS act as Layer 2 bridges and forward all data 597 traffic to/from the hosts and the ER. The hosts use the ER as their 598 Layer 3 next hop. If there is a GWR behind the CM it can act as a 599 next hop for all hosts and forward data traffic to/from the ER. 601 When deploying IPv6 in this environment, the CM and CMTS will 602 continue to be bridging devices in order to keep the transition 603 smooth and reduce operational complexity. The CM and CMTS will need 604 to bridge IPv6 unicast and multicast packets to/from the ER and the 605 hosts. If there is a GWR connected to the CM, it will need to 606 forward IPv6 unicast and multicast traffic to/from the ER. 608 IPv6 can be deployed in a bridged CMTS network either natively or via 609 tunneling. This section discusses the native deployment model. The 610 tunneling model is similar to ones described in sections 6.2.2.1 and 611 6.2.2.2. 613 Figure 6.2.1 illustrate the IPv6 deployment scenario 615 +-----+ +-----+ 616 |Host |--| GWR | 617 +-----+ +--+--+ 618 | _ _ _ _ _ _ 619 | +------+ | | 620 +--| CM |---| | 621 +------+ | | 622 | HFC | +------+ +--------+ 623 | | | | | Edge | 624 +-----+ +------+ | Network |---| CMTS |--| |=>ISP 625 |Host |--| CM |---| | | | | Router |Network 626 +-----+ +------+ | | +------+ +--------+ 627 |_ _ _ _ _ _| 628 |-------------||---------------------------------||---------------| 629 L3 Routed L2 Bridged L3 Routed 631 Figure 6.2.1 633 6.2.1.1 IPv6 Related Infrastructure Changes 635 In this scenario the CM and the CMTS bridge all data traffic so they 636 will need to support bridging of native IPv6 unicast and multicast 637 traffic. The following devices have to be upgraded to dual stack: 638 Host, GWR and ER. 640 6.2.1.2 Addressing 642 The proposed architecture for IPv6 deployment includes two components 643 that must be provisioned: the CM and the host. Additionally if there 644 is a GWR connected to the CM, it will also need to be provisioned. 645 The host or the GWR use the ER as their Layer 3 next hop. 647 6.2.1.2.1 IP Addressing for CM 649 The CM will be provisioned in the same way as in currently deployed 650 cable networks, using an IPv4 address on the cable interface 651 connected to the MSO network for management functions. During the 652 initialization phase, it will obtain its IPv4 address using DHCPv4, 653 and download a DOCSIS configuration file identified by the DHCPv4 654 server. 656 6.2.1.2.2 IP Addressing for Hosts 658 If there is no GWR connected to the CM, the host behind the CM will 659 get a /64 prefix assigned to it via stateless auto-configuration or 660 DHCPv6. 662 If using stateless auto-configuration, the host listens for routing 663 advertisements (RA) from the ER. The RAs contain the /64 prefix 664 assigned to the segment. Upon receipt of an RA, the host constructs 665 its IPv6 address by combining the prefix in the RA (/64) and a unique 666 identifier (e.g., its modified EUI-64 format interface ID). 668 If DHCPv6 is used to obtain an IPv6 address, it will work in much the 669 same way as DHCPv4 works today. The DHCPv6 messages exchanged 670 between the host and the DHCPv6 server are bridged by the CM and the 671 CMTS. 673 6.2.1.2.3 IP Addressing for GWR 675 The GWR can use stateless auto-configuration (RA) to obtain an 676 address for its upstream interface, the link between itself and the 677 ER. This step is followed by a request via DHCP-PD (Prefix 678 Delegation) for a prefix shorter than /64, typically /48 [7], which 679 in turn is divided into /64s and assigned to its downstream 680 interfaces connecting to the hosts. 682 6.2.1.3 Data Forwarding 684 The CM and CMTS must be able to bridge native IPv6 unicast and 685 multicast traffic. The CMTS must provide IP connectivity between 686 hosts attached to CMs and must do so in a way that meets the 687 expectation of Ethernet attached customer equipment. In order to do 688 that, the CM and CMTS must forward Neighbor Discovery (ND) packets 689 between ER and the hosts attached to the CM. 691 Communication between hosts behind different CMs is always forwarded 692 through the CMTS. IPv6 communication between the different sites 693 relies on multicast IPv6 ND [17] frames being forwarded correctly by 694 the CM and the CMTS. As with the CM, a bridged CMTS that selectively 695 forwards multicast datagrams on the basis of MLD will potentially 696 break IPv6 ND. 698 In order to support IPv6 multicast applications across DOCSIS cable 699 networks, the CM and bridging CMTS need to support IGMPv3/MLDv2 or v1 700 snooping. MLD is almost identical to IGMP in IPv4, only the name and 701 numbers are changed. MLDv2 is identical to IGMPv3 and also supports 702 ASM (Any Source Multicast) and SSM (Single Source Multicast) service 703 models. Implementation work on CM/CMTS should be minimal because the 704 only significant difference between IPv4 IGMPv3 and IPv6 MLDv2 is the 705 longer addresses in the protocol. 707 6.2.1.4 Routing 709 The hosts install a default route that points to the ER or the GWR. 710 No routing protocols are needed on these devices which generally have 711 limited resources. If there is a GWR present it will also use static 712 default route to the ER. 714 The ER runs an IGP such as OSPFv3 or IS-IS. The connected prefixes 715 have to be redistributed. If DHCP-PD is used, with every delegated 716 prefix a static route is installed by the ER. For this reason the 717 static routes must also be redistributed. Prefix summarization 718 should be done at the ER. 720 6.2.2 Deploying IPv6 in a Routed CMTS Network 722 In an IPv4 routed CMTS network the CM still acts as a Layer-2 device 723 and bridges all data traffic between its Ethernet interface and cable 724 interface connected to the cable operator network. The CMTS acts as 725 a Layer 3 router and may also include the ER functionality. The 726 hosts and the GWR use the CMTS as their Layer 3 next hop. 728 When deploying IPv6 in a routed CMTS network, the CM still acts as a 729 Layer-2 device and will need to bridge IPv6 unicast as well as 730 multicast traffic. The CMTS/ER will need to either tunnel IPv6 731 traffic or natively support IPv6. The host and GWR will use the 732 CMTS/ER as their Layer 3 next hop. 734 There could be five possible deployment scenarios for IPv6 in a 735 routed CMTS network: 737 1. IPv4 Cable (HFC) Network 739 In this scenario the cable network, including the CM and CMTS remain 740 IPv4 devices. The host and ER are upgraded to dual-stack. This is 741 the easiest way for a Cable Operator to provide IPv6 service as no 742 changes are made to the cable network. 744 2. IPv4 Cable (HFC) Network, GWR at Customer Site 746 In this case the cable network, including the CM and CMTS remain IPv4 747 devices. The host, GWR and ER are upgraded to dual-stack. This 748 scenario is also easy to deploy since the cable operator just needs 749 to add GWR at the customer site. 751 3. Dual-stacked Cable (HFC) Network, CM and CMTS Support IPv6 753 In this scenario the CMTS is upgraded to dual-stack to support IPv4 754 and IPv6. Since the CMTS supports IPv6 it can acts as an ER as well. 755 The CM will act as a Layer-2 bridge but will need to bridge IPv6 756 unicast and multicast traffic. This scenario is not easy to deploy 757 since it requires changes to the DOCSIS specification. The CM and 758 CMTS may require HW and SW upgrades to support IPv6. 760 4. Dual-stacked Cable (HFC) Network, Standalone GWR and CMTS Support 761 IPv6 763 In this scenario there is a standalone GWR connected to the CM. 764 Since the IPv6 functionality exists on the GWR the CM does not need 765 to be dual-stack. The CMTS is upgraded to dual-stack and it can 766 incorporate the ER functionality. This scenario may also require HW 767 and SW changes on the GWR and CMTS. 769 5. Dual-stacked Cable (HFC) Network, Embedded GWR/CM and CMTS 770 Support IPv6 772 In this scenario the CM and GWR functionality exists on a single 773 device which needs to be upgraded to dual-stack. The CMTS will also 774 need to be upgraded to a dual-stack device. This scenario is also 775 difficult to deploy in existent cable network since it requires 776 changes on the Embedded GWR/CM and the CMTS. 778 The DOCSIS specification will also need to be modified to allow 779 native IPv6 support on the Embedded GWR/CM. 781 6.2.2.1 IPv4 Cable Network, Host and ER Upgraded to Dual-Stack 783 This is one of the most cost effective ways for a Cable Operator to 784 offer IPv6 services to its customers. Since the cable network 785 remains IPv4 there is relatively minimal cost involved in turning up 786 IPv6 service. All IPv6 traffic is exchanged between the hosts and 787 the ER. 789 Figure 6.2.2.1 illustrates this deployment scenario 791 +-----------+ +------+ +--------+ 792 +-----+ +-------+ | Cable | | | | Edge | 793 |Host |--| CM |----| (HFC) |---| CMTS |---| |=>ISP 794 +-----+ +-------+ | Network | | | | Router |Network 795 +-----------+ +------+ +--------+ 796 _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ 797 ()_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _() 798 IPv6-in-IPv4 tunnel 800 |---------||---------------------------------------||------------| 801 IPv4/v6 IPv4 only IPv4/v6 803 Figure 6.2.2.1 805 6.2.2.1.1 IPv6 Related Infrastructure Changes 807 In this scenario the CM and the CMTS will only need to support IPv4 808 so no changes need to be made to them or the cable network. The 809 following devices have to be upgraded to dual stack: Host and ER. 811 6.2.2.1.2 Addressing 813 The only device that needs to be assigned an IPv6 address at customer 814 site is the host. Host address assignment can be done in multiple 815 ways. Depending on the tunneling mechanism used it could be 816 automatic or might require manual configuration. 818 The host still receives an IPv4 address using DHCPv4, which works the 819 same way in currently deployed cable networks. In order to get IPv6 820 connectivity, host devices will also need an IPv6 address and a means 821 to communicate with the ER. 823 6.2.2.1.3 Data Forwarding 825 All IPv6 traffic will be sent to/from the ER and the host device. In 826 order to transport IPv6 packets over the cable operator IPv4 network, 827 the host and the ER will need to use one of the available IPv6 in 828 IPv4 tunneling mechanisms. 830 The host will use its IPv4 address to source the tunnel to the ER. 831 All IPv6 traffic will be forwarded to the ER, encapsulated in IPv4 832 packets. The intermediate IPv4 nodes will forward this traffic as 833 regular IPv4 packets. The ER will need to terminate the tunnel 834 and/or provide other IPv6 services. 836 6.2.2.1.4 Routing 838 Routing configuration on the host will vary depending on the 839 tunneling technique used, in some cases a default or static route 840 might be needed to forward traffic to the next hop. 842 The ER runs an IGP such as OSPFv3 or ISIS. 844 6.2.2.2 IPv4 Cable Network, Host, GWR and ER Upgraded to Dual-Stack 846 The cable operator can provide IPv6 services to its customers, in 847 this scenario, by adding a GWR behind the CM. Since the GWR will 848 facilitate all IPv6 traffic to/from the host and the ER, the cable 849 network including the CM and CMTS do not need to support IPv6 and can 850 remain as IPv4 devices. 852 Figure 6.2.2.2 illustrates this deployment scenario 854 +-----+ 855 |Host | 856 +--+--+ 857 | +-----------+ +------+ +--------+ 858 +---+---+ +-------+ | Cable | | | | Edge | 859 | GWR |--| CM |----| (HFC) |---| CMTS |---| |=>ISP 860 +-------+ +-------+ | Network | | | | Router |Network 861 +-----------+ +------+ +--------+ 862 _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ 863 ()_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _() 864 IPv6-in-IPv4 tunnel 866 |---------||--------------------------------------||-------------| 867 IPv4/v6 IPv4 only IPv4/v6 869 Figure 6.2.2.2 871 6.2.2.2.1 IPv6 Related Infrastructure Changes 873 In this scenario the CM and the CMTS will only need to support IPv4 874 so no changes need to be made to them or the cable network. The 875 following devices have to be upgraded to dual stack: Host, GWR and 876 ER. 878 6.2.2.2.2 Addressing 880 The only devices that needs to be assigned an IPv6 address at 881 customer site are the host and GWR. IPv6 address assignment can be 882 done statically at the GWR downstream interface. The GWR will send 883 out RA messages on its downstream interface which will be used by the 884 hosts to auto-configure themselves with an IPv6 address. The GWR can 885 also configure its upstream interface using RA messages from the ER 886 and use DHCP-PD for requesting a /48 [7] prefix from the ER. This 887 /48 prefix will be used to configure /64s on hosts connected to the 888 GWR downstream interfaces. Currently the DHCP-PD functionality 889 cannot be implemented if the DHCP-PD server is not the Edge Router. 890 If the DHCP-PD messages are relayed, the Edge Router does not have a 891 mechanism to learn the assigned prefixes and thus install the proper 892 routes to make that prefix reachable. Work is being done to address 893 this issue, one idea being to provide the Edge Router with a snooping 894 mechanism. The uplink to the ISP network is configured with a /64 895 prefix as well. 897 The GWR still receives a global IPv4 address on its upstream 898 interface using DHCPv4, which works the same way in currently 899 deployed cable networks. In order to get IPv6 connectivity to the 900 Internet the GWR will need to communicate with the ER. 902 6.2.2.2.3 Data Forwarding 904 All IPv6 traffic will be sent to/from the ER and the GWR, which will 905 forward IPv6 traffic to/from the host. In order to transport IPv6 906 packets over the cable operator IPv4 network, the GWR and the ER will 907 need to use one of the available IPv6 in IPv4 tunneling mechanisms. 908 All IPv6 traffic will need to go through the tunnel, once it comes 909 up. 911 The GWR will use its IPv4 address to source the tunnel to the ER. 912 The tunnel endpoint will be the IPv4 address of the ER. All IPv6 913 traffic will be forwarded to the ER, encapsulated in IPv4 packets. 914 The intermediate IPv4 nodes will forward this traffic as regular IPv4 915 packets. In case of 6to4 tunneling, the ER will need to support 6to4 916 relay functionality in order to provide IPv6 Internet connectivity to 917 the GWR and hence the hosts connected to the GWR. 919 6.2.2.2.4 Routing 921 Depending on the tunneling technique used there might some 922 configuration needed on the GWR and the ER. If the ER is also 923 providing a 6to4 relay service then a default route will need to be 924 added to the GWR pointing to the ER, for all non-6to4 traffic. 926 If using manual tunneling, the GWR and ER can use static routing or 927 they can also configure RIPng. The RIPng updates can be transported 928 over a manual tunnel, which does not work when using 6to4 tunneling. 930 Customer routes can be carried to the ER using RIPng updates. The ER 931 can advertise these routes in its IGP. Prefix summarization should 932 be done at the ER. 934 If DHCP-PD is used for address assignment a static route is 935 automatically installed on the CMTS/ER for each delegated /48 prefix. 936 The static routes need to be redistributed into the IGP at the 937 CMTS/ER, so there is no need for a routing protocol between the 938 CMTS/ER and the GWR. 940 The ER runs an IGP such as OSPFv3 or ISIS. 942 6.2.2.3 Dual-stacked Cable (HFC) Network, CM and CMTS Support IPv6 944 In this scenario the Cable Operator can offer native IPv6 services to 945 its customers since the cable network including the CMTS supports 946 IPv6. The ER functionality can be included in the CMTS or it can 947 exist on a separate router connected to the CMTS upstream interface. 948 The CM will need to bridge IPv6 unicast and multicast traffic. 950 Figure 6.2.2.3 illustrates this deployment scenario 952 +-----------+ +-------------+ 953 +-----+ +-------+ | Cable | | CMTS / Edge | 954 |Host |--| CM |----| (HFC) |---| |=>ISP 955 +-----+ +-------+ | Network | | Router | Network 956 +-----------+ +-------------+ 958 |-------||---------------------------||---------------| 959 IPv4/v6 IPv4/v6 IPv4/v6 961 Figure 6.2.2.3 963 6.2.2.3.1 IPv6 Related Infrastructure Changes 965 Since the CM still acts as a Layer-2 bridge, it does not need to be 966 dual-stack. The CM will need to support bridging of IPv6 unicast and 967 multicast traffic and IGMPv3/MLDv2 or v1 snooping which requires 968 changes in the DOCSIS specification. In this scenario the following 969 devices have to be upgraded to dual stack: Host and CMTS/ER. 971 6.2.2.3.2 Addressing 973 In today's cable networks the CM receives a private IPv4 address 974 using DHCPv4 for management purposes. In an IPv6 environment, the CM 975 will continue to use an IPv4 address for management purposes. The 976 cable operator can also choose to assign an IPv6 address to the CM 977 for management, but the CM will have to be upgraded to support this 978 functionality. 980 IPv6 address assignment for the CM and host can be done via DHCP or 981 stateless auto-configuration. If the CM uses an IPv4 address for 982 management, it will use DHCPv4 for its address assignment and the 983 CMTS will need to act as a DHCPv4 relay agent. If the CM uses an 984 IPv6 address for management, it can use DHCPv6 with the CMTS acting 985 as a DHCPv6 relay agent or the CMTS can be statically configured with 986 a /64 prefix and it can send out RA messages out the cable interface. 987 The CMs connected to the cable interface can use the RA messages to 988 auto-configure themselves with an IPv6 address. All CMs connected to 989 the cable interface will be in the same subnet. 991 The hosts can receive their IPv6 address via DHCPv6 or stateless 992 auto-configuration. With DHCPv6, the CMTS may need to act as a 993 DHCPv6 relay agent and forward DHCP messages between the hosts and 994 the DHCP server. With stateless auto-configuration, the CMTS will be 995 configured with multiple /64 prefixes and send out RA messages to the 996 hosts. If the CMTS is not also acting as an ER, the RA messages will 997 come from the ER connected to the CMTS upstream interface. The CMTS 998 will need to forward the RA messages downstream or act as an ND 999 proxy. 1001 6.2.2.3.3 Data Forwarding 1003 All IPv6 traffic will be sent to/from the CMTS and hosts. Data 1004 forwarding will work the same way it works in currently deployed 1005 cable networks. The CMTS will forward IPv6 traffic to/from hosts 1006 based on the IP source/destination address. 1008 6.2.2.3.4 Routing 1010 No routing protocols are needed between the CMTS and the host since 1011 the CM and host are directly connected to the CMTS cable interface. 1012 Since the CMTS supports IPv6, hosts will use the CMTS as their Layer 1013 3 next hop. 1015 If the CMTS is also acting as an ER, it runs an IGP such as OSPFv3 or 1016 ISIS. 1018 6.2.2.4 Dual-Stacked Cable (HFC) Network, Standalone GWR and CMTS 1019 Support IPv6 1021 In this case the cable operator can offer IPv6 services to its 1022 customers by adding a GWR between the CM and the host. The GWR will 1023 facilitate IPv6 communication between the host and the CMTS/ER. The 1024 CMTS will be upgraded to dual-stack to support IPv6 and can acts as 1025 an ER as well. The CM will act as a bridge for forwarding data 1026 traffic and does not need to support IPv6. 1028 This scenario is similar to the case described in section 6.2.2.2. 1029 The only difference in this case is the ER functionality exists on 1030 the CMTS instead of a separate router in the cable operator network. 1032 Figure 6.2.2.4 illustrates this deployment scenario 1034 +-----------+ +-----------+ 1035 +------+ +-------+ +-------+ | Cable | |CMTS / Edge| 1036 | Host |--| GWR |--| CM |---| (HFC) |---| |=>ISP 1037 +------+ +-------+ +-------+ | Network | | Router |Network 1038 +-----------+ +-----------+ 1039 _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ 1040 ()_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _() 1041 IPv6-in-IPv4 tunnel 1042 |-----------------||-----------------------------||--------------| 1043 IPv4/v6 IPv4 IPv4/v6 1045 Figure 6.2.2.4 1047 6.2.2.4.1 IPv6 Related Infrastructure Changes 1049 Since the CM still acts as a Layer-2 bridge, it does not need to be 1050 dual-stack nor does it need to support IPv6. In this scenario the 1051 following devices have to be upgraded to dual stack: Host, GWR and 1052 CMTS/ER. 1054 6.2.2.4.2 Addressing 1056 The CM will still receive a private IPv4 address using DHCPv4 which 1057 works the same way in existent cable networks. The CMTS will act as 1058 DHCPv4 relay agent. 1060 The address assignment for the host and GWR happens in a similar 1061 manner as described in section 6.2.2.2.2. 1063 6.2.2.4.3 Data Forwarding 1065 Data forwarding between the host and CMTS/ER is facilitated by the 1066 GWR and happens in a similar manner as described in section 1067 6.2.2.2.3. 1069 6.2.2.4.4 Routing 1071 In this case routing is very similar to the case described in section 1072 6.2.2.2.4. Since the CMTS now incorporates the ER functionality, it 1073 will need to run an IGP such as OSPFv3 or ISIS. 1075 6.2.2.5 Dual-Stacked Cable (HFC) Network, Embedded GWR/CM and CMTS 1076 Support IPv6 1078 In this scenario the Cable Operator can offer native IPv6 services to 1079 its customers since the cable network including the CM/Embedded GWR 1080 and CMTS support IPv6. The ER functionality can be included in the 1081 CMTS or it can exist on a separate router connected to the CMTS 1082 upstream interface. The CM/Embedded GWR acts as a Layer 3 device. 1084 Figure 6.2.2.5 illustrates this deployment scenario 1086 +-----------+ +-------------+ 1087 +-----+ +-----------+ | Cable | | CMTS / Edge | 1088 |Host |---| CM / GWR |---| (HFC) |---| |=>ISP 1089 +-----+ +-----------+ | Network | | Router |Network 1090 +-----------+ +-------------+ 1092 |---------------------------------------------------------| 1093 IPv4/v6 1095 Figure 6.2.2.5 1097 6.2.2.5.1 IPv6 Related Infrastructure Changes 1099 Since the CM/GWR acts as a Layer 3 device, IPv6 can be deployed end- 1100 to-end. In this scenario the following devices have to be upgraded 1101 to dual-stack: Host, CM/GWR and CMTS/ER. 1103 6.2.2.5.2 Addressing 1105 Since the CM/GWR is dual-stack, it can receive an IPv4 or IPv6 1106 address using DHCP for management purposes. As the GWR functionality 1107 is Embedded in the CM, it will need an IPv6 address for forwarding 1108 data traffic. IPv6 address assignment for the CM/GWR and host can be 1109 done via DHCPv6 or DHCP-PD. 1111 If using DHCPv6 the CMTS will need to act as DHCPv6 relay agent. The 1112 host and CM/GWR will receive IPv6 addresses from pools of /64 1113 prefixes configured on the DHCPv6 server. The CMTS will need to 1114 glean pertinent information from the DHCP Offer messages, sent from 1115 the DHCP server to the DHCP clients (host and CM/GWR), much like it 1116 does today in DHCPv4. All CM/GWR connected to the same cable 1117 interface on the CMTS belong to same management /64 prefix. The 1118 hosts connected to the same cable interface on the CMTS may belong to 1119 different /64 customer prefixes as the CMTS may have multiple /64 1120 prefixes configured under its cable interfaces. 1122 It is also possible to use DHCP-PD for IPv6 address assignment. In 1123 this case the CM/GWR will use stateless auto-configuration to assign 1124 an IPv6 address to its upstream interface using the /64 prefix sent 1125 by the CMTS/ER in RA message. Once the CM/GWR assigns an IPv6 1126 address to its upstream interface it will request a /48 [7] prefix 1127 from the CMTS/ER and chop this /48 prefix into /64s for assigning 1128 IPv6 addresses to hosts. Currently the DHCP-PD functionality cannot 1129 be implemented if the DHCP-PD server is not the Edge Router. If the 1130 DHCP-PD messages are relayed, the Edge Router does not have a 1131 mechanism to learn the assigned prefixes and thus install the proper 1132 routes to make that prefix reachable. Work is being done to address 1133 this issue, one idea being to provide the Edge Router with a snooping 1134 mechanism. The uplink to the ISP network is configured with a /64 1135 prefix as well. 1137 6.2.2.5.3 Data Forwarding 1139 The host will use the CM/GWR as the Layer 3 next hop. The CM/GWR 1140 will forward all IPv6 traffic to/from the CMTS/ER and hosts. The 1141 CMTS/ER will forward IPv6 traffic to/from hosts based on the IP 1142 source/destination address. 1144 6.2.2.5.4 Routing 1146 The CM/GWR can use a static default route pointing to the CMTS/ER or 1147 it can run a routing protocol such as RIPng or OSPFv3 between itself 1148 and the CMTS. Customer routes from behind the CM/GWR can be carried 1149 to the CMTS using routing updates. 1151 If DHCP-PD is used for address assignment a static route is 1152 automatically installed on the CMTS/ER for each delegated /48 prefix. 1153 The static routes need to be redistributed into the IGP at the 1154 CMTS/ER so there is no need for a routing protocol between the 1155 CMTS/ER and the GWR. 1157 If the CMTS is also acting as an ER, it runs an IGP such as OSPFv3 or 1158 ISIS. 1160 6.2.3 IPv6 Multicast 1162 In order to support IPv6 multicast applications across DOCSIS cable 1163 networks, the CM and bridging CMTS will need to support IGMPv3/MLDv2 1164 or v1 snooping. MLD is almost identical to IGMP in IPv4, only the 1165 name and numbers are changed. MLDv2 is almost identical to IGMPv3 1166 and also supports ASM (Any Source Multicast) and SSM (Single Source 1167 Multicast) service models. 1169 SSM is more suited for deployments where the SP intends to provide 1170 paid content to the users (Video or Audio). This type of services 1171 are expected to be of primary interest. Moreover, the simplicity of 1172 the SSM model often times override the scalability issues that would 1173 be resolved in an ASM model. ASM is however an option that is 1174 discussed in section 7.3.1. The Layer 3 CM, GWR and Layer 3 routed 1175 CMTS/ER will need to be enabled with PIM-SSM, which requires the 1176 definition and support for IGMPv3/MLDv1 or v2 snooping, in order to 1177 track join/leave messages from the hosts. Another option would be 1178 for the Layer 3 CM or GWR to support MLD proxy routing. The Layer 3 1179 next hop for the hosts needs to support MLD. 1181 Please refer to section 7.3 for more IPv6 multicast details. 1183 6.2.4 IPv6 QoS 1185 IPv6 will not change or add any queuing/scheduling functionality 1186 already existing in DOCSIS specifications. But the QoS mechanisms on 1187 the CMTS and CM would need to be IPv6 capable. This includes support 1188 for IPv6 classifiers, so that data traffic to/from host devices can 1189 be classified appropriately into different service flows and be 1190 assigned appropriate priority. Appropriate classification criteria 1191 would need to be implemented for unicast and multicast traffic. 1193 In order to classify IPv6 traffic the following classifiers would 1194 need to be modified in the DOCSIS specification to support the 128- 1195 bit IPv6 address: 1197 A. IP source address 1199 B. IP source mask 1201 C. IP destination address 1203 D. IP destination mask 1205 E. IP traffic class (DSCP) 1207 The following classifiers would be new for IPv6: 1209 A. IP version 1210 B. Flow label (optional) 1212 Traffic classification and marking should be done at the CM for 1213 upstream traffic and the CMTS/ER for downstream traffic in order to 1214 support the various types of services: data, voice, video. The same 1215 IPv4 QoS concepts and methodologies should be applied for IPv6 as 1216 well. 1218 It is important to note that when traffic is encrypted end-to-end, 1219 the traversed network devices will not have access to many of the 1220 packet fields used for classification purposes. In these cases 1221 routers will most likely place the packets in the default classes. 1222 The QoS design should take into consideration this scenario and try 1223 to use mainly IP header fields for classification purposes. 1225 6.2.5 IPv6 Security Considerations 1227 Security in a DOCSIS cable network is provided using Baseline Privacy 1228 Plus (BPI+). The only part that is dependent on IP addresses is 1229 encrypted multicast. Semantically, multicast encryption would work 1230 the same way in an IPv6 environment as in the IPv4 network. However, 1231 appropriate enhancements will be needed in the DOCSIS specification 1232 to support encrypted IPv6 multicast. 1234 The other aspect of security enhancement is mandated IPSec support in 1235 IPv6. The IPv6 specifications mandate implementation of IPSec, but 1236 they do not mandate its use. The IPv4 specifications do not mandate 1237 IPSec. IPSec is the same for both IPv4 and IPv6, but it still 1238 requires a key distribution mechanism. Cable operators may consider 1239 deploying it end-to-end on IPv6 as there is not an intermediate 1240 device(i.e. NAT). 1242 There are limited changes that have to be done for hosts in order to 1243 enhance security. The Privacy extensions [13] for auto-configuration 1244 should be used by the hosts. IPv6 firewall functions could be 1245 enabled, if available on the host or GWR. 1247 The ISP provides security against attacks that come form its own 1248 subscribers but it could also implement security services that 1249 protect its subscribers from attacks sourced from the outside of its 1250 network. Such services do not apply at the access level of the 1251 network discussed here. 1253 The CMTS/ER should protect the ISP network and the other subscribers 1254 against attacks by one of its own customers. For this reason Unicast 1255 Reverse Path Forwarding (uRPF) [22] and ACLs should be used on all 1256 interfaces facing subscribers. Filtering should be implemented with 1257 regard for the operational requirements of IPv6 [Security 1258 considerations for IPv6]. 1260 The CMTS/ER should protect its processing resources against floods of 1261 valid customer control traffic such as: Router and Neighbor 1262 Solicitations, MLD Requests. 1264 All other security features used with the IPv4 service should be 1265 similarly applied to IPv6 as well. 1267 6.2.6 IPv6 Network Management 1269 IPv6 can have many applications in Cable Networks. MSOs can 1270 initially implement IPv6 on the control plane and use it to manage 1271 the thousands of devices connected to the CMTS. This would be a good 1272 way to introduce IPv6 in a Cable Network. Later on the MSO can 1273 extend IPv6 to the data plane and use it to carry customer as well as 1274 management traffic. 1276 6.2.6.1 Using IPv6 for Management in Cable Networks 1278 IPv6 can be enabled in a Cable Network for management of devices like 1279 CM, CMTS and ER. With the roll out of advanced services like VoIP 1280 and Video-over-IP, MSOs are looking for ways to manage the large 1281 number of devices connected to the CMTS. In IPv4, an RFC1918 address 1282 is assigned to these devices like CM for management purposes. Since 1283 there is a finite number of RFC1918 addresses available, it is 1284 becoming difficult for MSOs to manage these devices. 1286 By using IPv6 for management purposes, MSOs can scale their network 1287 management systems to meet their needs. The CMTS/ER can be 1288 configured with a /64 management prefix which is shared among all CMs 1289 connected to the CMTS cable interface. Addressing for the CMs can be 1290 done via stateless auto-configuration. Once the CMs receive the /64 1291 prefix from the CMTS/ER via RA they can configure themselves with an 1292 IPv6 address. 1294 If there are devices behind the CM which need to be managed by the 1295 MSO, another /64 prefix can be defined on the CMTS/ER. These devices 1296 can also use stateless auto-configuration to assign themselves an 1297 IPv6 address. 1299 Traffic sourced from or destined to the management prefix should not 1300 cross the MSO's network boundaries. 1302 In this scenario IPv6 will only be used for managing these devices on 1303 the Cable Network, all data traffic will still be forwarded by the CM 1304 and CMTS/ER using IPv4. 1306 6.2.6.2 Updates to MIBs/Standards to support IPv6 1308 The current DOCSIS, PacketCable, and CableHome MIBs are already 1309 designed to support IPv6 objects. In this case, IPv6 will neither 1310 add, nor change any of the functionality of these MIBs. An object to 1311 identify the IP version, InetAddressType has been added to all the 1312 appropriate SNMP objects related to IP address. 1314 There are some exceptions, the following MIBs might need to add IPv6 1315 support: 1317 On the CMTS 1319 A. DOCS-QOS-MIB 1321 B. DOCS-SUBMGT-MIB (Subscriber Management Interface Specification 1322 ANNEX B) 1324 On the CM 1326 A. DOCS-QOS-MIB 1328 B. DOCS-CABLE-DEVICE-MIB (or [19]) 1330 7. Broadband DSL Networks 1332 This section describes the IPv6 deployment options in today's High 1333 Speed DSL Networks. 1335 7.1 DSL Network Elements 1337 Digital Subscriber Line (DSL) broadband services provide users with 1338 IP connectivity over the existing twisted-pair telephone lines called 1339 the local-loop. A wide range of bandwidth offerings are available 1340 depending on the quality of the line and the distance between the 1341 Customer Premise Equipment and the DSLAM. 1343 The following network elements are typical of a DSL network [ISP 1344 Transition Scenarios]: 1346 DSL Modem: It can be a stand alone device, it can be incorporated in 1347 the host, it can incorporate router functionalities and also have the 1348 capabilities to act as a CPE router. 1350 Customer Premise Router: It is used to provide Layer 3 services for 1351 customer premise networks. It is usually used to provide firewalling 1352 functions and segment broadcast domains for a Small business. 1354 DSL Access Multiplexer (DSLAM): It terminates multiple twisted pair 1355 telephone lines and provides aggregation to BRAS. 1357 Broadband Remote Access Server (BRAS): It aggregates or terminates 1358 multiple PVC corresponding to the subscriber DSL circuits. 1360 Edge Router (ER): It provides the Layer 3 interface to the ISP 1361 network. 1363 Figure 7.1 depicts all the network elements mentioned 1365 Customer Premise | Network Access Provider | Network Service Provider 1366 CP NAP NSP 1367 +-----+ +------+ +------+ +--------+ 1368 |Hosts|--|Router| +--+ BRAS +---+ Edge | ISP 1369 +-----+ +--+---+ | | | | Router +==> Network 1370 | | +------+ +--------+ 1371 +--+---+ | 1372 | DSL +-+ | 1373 |Modem | | | 1374 +------+ | +-----+ | 1375 +--+ | | 1376 +------+ |DSLAM+--+ 1377 +-----+ | DSL | +--+ | 1378 |Hosts|--+Modem +-+ +-----+ 1379 +-----+ +--+---+ 1380 Figure 7.1 1382 7.2 Deploying IPv6 in IPv4 DSL Networks 1384 There are three main design approaches to providing IPv4 connectivity 1385 over a DSL infrastructure: 1387 1. Point-to-Point Model: Each subscriber connects to the DSLAM over 1388 a twisted pair and is provided with a unique PVC that links it to the 1389 service provider. The PVCs can be terminated at the BRAS or at the 1390 Edge Router. This type of design is not very scalable if the PVCs 1391 are not terminated as close as possible to the DSLAM (at the BRAS). 1392 In this case a large number of layer two circuits has to be 1393 maintained over a significant portion of the network. The layer two 1394 domains can be terminated at the ER in three ways: 1396 A. In a common bridge group with a virtual interface that routes it 1397 out. 1399 B. Enable a Routed Bridged Encapsulation feature, all users could be 1400 part of the same subnet. This is the most common deployment type of 1401 IPv4 over DSL but it might not be the best choice in IPv6 where 1402 address availability is not an issue. 1404 C. Terminate the PVC at Layer 3, each PVC has its own prefix. This 1405 is the approach that seems more suitable for IPv6 and presented in 1406 7.2.1 In none of these cases the CPE (DSL Modem) has to be upgraded. 1408 2. PPP Terminated Aggregation (PTA) Model: PPP sessions are opened 1409 between each subscriber and the BRAS. The BRAS terminates the PPP 1410 sessions and provides Layer 3 connectivity between the subscriber and 1411 the ISP. This model is presented in section 7.2.2. 1413 3. L2TP Access Aggregation (LAA) Model: PPP sessions are opened 1414 between each subscriber and the ISP Edge Router. The BRAS tunnels 1415 the subscriber PPP sessions to the ISP by encapsulating them into 1416 L2TPv2 tunnels. This model is presented in section 7.2.3. 1418 In aggregation models the BRAS terminates the subscriber PVCs and 1419 aggregates their connections before providing access to the ISP. 1421 In order to maintain the deployment concepts and business models 1422 proven and used with existent revenue generating IPv4 services, the 1423 IPv6 deployment will match the IPv4 one. This approach is presented 1424 in sections 7.2.1-3 that describe current IPv4 over DSL broadband 1425 access deployments. Under certain circumstances where new service 1426 types or service needs justify it, IPv4 and IPv6 network logical 1427 architectures could be different as described in section 7.2.4. 1429 7.2.1 Point-to-Point Model 1431 In this scenario the Ethernet frames from the Host or the Customer 1432 Premise Router are bridged over the PVC assigned to the subscriber. 1434 Figure 7.2.1 describes the protocol architecture of this model 1436 Customer Premise NAP NSP 1437 |-------------------------| |---------------| |------------------| 1439 +-----+ +-------+ +-----+ +--------+ +----------+ 1440 |Hosts|--+Router +--+ DSL +--+ DSLAM +--------+ Edge | ISP 1441 +-----+ +-------+ |Modem| +--------+ | Router +=>Network 1442 +-----+ +----------+ 1443 |----------------------------| 1444 ATM 1445 Figure 7.2.1 1447 7.2.1.1 IPv6 Related Infrastructure Changes 1449 In this scenario the DSL modem and the entire NAP is Layer 3 unaware, 1450 so no changes are needed to support IPv6. The following devices have 1451 to be upgraded to dual stack: Host, Customer Router (if present) and 1452 Edge Router. 1454 7.2.1.2 Addressing 1456 The Hosts or the Customer Routers have the Edge Router as their Layer 1457 3 next hop. 1459 If there is no Customer Router all the hosts on the subscriber site 1460 belong to the same /64 subnet that is statically configured on the 1461 Edge Router for that subscriber PVC. The hosts can use stateless 1462 auto-configuration or stateful DHCPv6 based configuration to acquire 1463 an address via the Edge Router. 1465 However, as manual configuration for each customer is a provisioning 1466 challenge, implementations are encouraged to develop mechanism(s) 1467 which automatically map the PVC (or some other customer-specific 1468 information) to an IPv6 subnet prefix, and advertise the customer- 1469 specific prefix to all the customers with minimal configuration. 1471 If a Customer Router is present: 1473 A. It is statically configured with an address on the /64 subnet 1474 between itself and the Edge Router, and with /64 prefixes on the 1475 interfaces connecting the hosts on the customer site. This is not a 1476 desired provisioning method being expensive and difficult to manage. 1478 B. It can use its link-local address to communicate with the ER. It 1479 can also dynamically acquire through stateless auto-configuration the 1480 prefix for the link between itself and the ER. The later option 1481 allows it to contact a remote DHCPv6 server if needed. This step is 1482 followed by a request via DHCP-PD for a prefix shorter than /64 that 1483 in turn is divided in /64s and assigned to its downstream interfaces. 1485 The Edge Router has a /64 prefix configured for each subscriber VLAN. 1486 Each VLAN should be enabled to relay DHCPv6 requests from the 1487 subscribers to DHCPv6 servers in the ISP network. The VLANs 1488 providing access for subscribers that use DHCP-PD as well, have to be 1489 enabled to support the feature. Currently the DHCP-PD functionality 1490 cannot be implemented if the DHCP-PD server is not the Edge Router. 1491 If the DHCP-PD messages are relayed, the Edge Router does not have a 1492 mechanism to learn the assigned prefixes and thus install the proper 1493 routes to make that prefix reachable. Work is being done to address 1494 this issue, one idea being to provide the Edge Router with a snooping 1495 mechanism. The uplink to the ISP network is configured with a /64 1496 prefix as well. 1498 The prefixes used for subscriber links and the ones delegated via 1499 DHCP-PD should be planned in a manner that allows as much 1500 summarization as possible at the Edge Router. 1502 Other information of interest to the host, such as DNS, is provided 1503 through stateful DHCPv6 [10] and stateless DHCPv6 [9]. 1505 7.2.1.3 Routing 1507 The CPE devices are configured with a default route that points to 1508 the Edge router. No routing protocols are needed on these devices 1509 which generally have limited resources. 1511 The Edge Router runs the IPv6 IGP used in the NSP: OSPFv3 or IS-IS. 1512 The connected prefixes have to be redistributed. If DHCP-PD is used, 1513 with every delegated prefix a static route is installed by the Edge 1514 Router. For this reason the static routes must also be 1515 redistributed. Prefix summarization should be done at the Edge 1516 Router. 1518 7.2.2 PPP Terminated Aggregation (PTA) Model 1520 The PTA architecture relies on PPP-based protocols (PPPoA [15] and 1521 PPPoE [14]). The PPP sessions are initiated by Customer Premise 1522 Equipment and are terminated at the BRAS. The BRAS authorizes the 1523 session, authenticates the subscriber, and provides an IP address on 1524 behalf of the ISP. The BRAS then does Layer 3 routing of the 1525 subscriber traffic to the NSP Edge Router. This model is often used 1526 when the NSP is also the NAP. 1528 There are two types of PPP encapsulations that can be leveraged with 1529 this model: 1531 A. Connection using PPPoA 1533 Customer Premise NAP NSP 1534 |--------------------| |----------------------| |----------------| 1535 +-----------+ 1536 | AAA | 1537 +-------+ Radius | 1538 | | TACACS | 1539 | +-----------+ 1540 | 1541 +-----+ +-------+ +--------+ +----+-----+ +-----------+ 1542 |Hosts|--+Router +------+ DSLAM +-+ BRAS +-+ Edge | 1543 +-----+ +-------+ +--------+ +----------+ | Router +=>Core 1544 +-----------+ 1545 |--------------------------| 1546 PPP 1547 Figure 7.2.2.1 1549 The PPP sessions are initiated by the Customer Premise Equipment. 1550 The BRAS authenticates the subscriber against a local or a remote 1551 database. Once the session is established, the BRAS provides an 1552 address and maybe a DNS server to the user, information acquired from 1553 the subscriber profile or from a DHCP server. 1555 This solution scales better then the Point-to-Point but since there 1556 is only one PPP session per ATM PVC the subscriber can choose a 1557 single ISP service at a time. 1559 B. Connection using PPPoE 1561 Customer Premise NAP NSP 1562 |--------------------------| |-------------------| |---------------| 1563 +-----------+ 1564 | AAA | 1565 +-------+ Radius | 1566 | | TACACS | 1567 | +-----------+ 1568 | 1569 +-----+ +-------+ +--------+ +----+-----+ +-----------+ 1570 |Hosts|--+Router +-----------+ DSLAM +-+ BRAS +-+ Edge | C 1571 +-----+ +-------+ +--------+ +----------+ | Router +=>O 1572 | | R 1573 +-----------+ E 1574 |--------------------------------| 1575 PPP 1576 Figure 7.2.2.2 1578 The operation of PPPoE is similar to PPPoA with the exception that 1579 with PPPoE multiple sessions can be supported over the same PVC thus 1580 allowing the subscriber to connect to multiple services at the same 1581 time. The hosts can initiate the PPPoE sessions as well. It is 1582 important to remember that the PPPoE encapsulation reduces the IP MTU 1583 available for the customer traffic due to additional headers. 1585 The network design and operation of the PTA model is the same 1586 regardless of the PPP encapsulation type used. 1588 7.2.2.1 IPv6 Related Infrastructure Changes 1590 In this scenario the BRAS is Layer 3 aware and it has to be upgraded 1591 to support IPv6. Since the BRAS terminates the PPP sessions it has 1592 to support the implementation of these PPP protocols with IPv6. The 1593 following devices have to be upgraded to dual stack: Host, Customer 1594 Router (if present), BRAS and Edge Router. 1596 7.2.2.2 Addressing 1598 The BRAS terminates the PPP sessions and provides the subscriber with 1599 an IPv6 address from the defined pool for that profile. The 1600 subscriber profile for authorization and authentication can be 1601 located on the BRAS or on a AAA server. The Hosts or the Customer 1602 Routers have the BRAS as their Layer 3 next hop. 1604 The PPP session can be initiated by a host or by a Customer Router. 1605 In the latter case, once the session is established with the BRAS and 1606 an address is negotiated for the uplink to the BRAS, DHCP-PD can be 1607 used to acquire prefixes for the Customer Router other interfaces. 1609 The BRAS has to be enabled to support DHCP-PD and to relay the DHCPv6 1610 requests of the hosts on the subscriber sites. 1612 The BRAS has a /64 prefixes configured on the link to the Edge 1613 router. The Edge router links are also configured with /64 prefixes 1614 to provide connectivity to the rest of the ISP network. 1616 The prefixes used for subscriber and the ones delegated via DHCP-PD 1617 should be planned in a manner that allows maximum summarization at 1618 the BRAS. 1620 Other information of interest to the host, such as DNS, is provided 1621 through stateful [10] and stateless [9] DHCPv6. 1623 7.2.2.3 Routing 1625 The CPE devices are configured with a default route that points to 1626 the BRAS router. No routing protocols are needed on these devices 1627 which generally have limited resources. 1629 The BRAS runs an IGP to the Edge Router: OSPFv3 or IS-IS. Since the 1630 addresses assigned to the PPP sessions are represented as connected 1631 host routes, connected prefixes have to be redistributed. If DHCP-PD 1632 is used, with every delegated prefix a static route is installed by 1633 the Edge Router. For this reason the static routes must also be 1634 redistributed. Prefix summarization should be done at the BRAS. 1636 The Edge Router is running the IGP used in the ISP network: OSPFv3 or 1637 IS-IS. 1639 A separation between the routing domains of the ISP and the Access 1640 Provider is recommended if they are managed independently. 1641 Controlled redistribution will be needed between the Access Provider 1642 IGP and the ISP IGP. 1644 7.2.3 L2TPv2 Access Aggregation (LAA) Model 1646 In the LAA model the BRAS forwards the CPE initiated session to the 1647 ISP over an L2TPv2 tunnel established between the BRAS and the Edge 1648 Router. In this case the authentication, authorization and 1649 subscriber configuration are performed by the ISP itself. There are 1650 two types of PPP encapsulations that can be leveraged with this 1651 model: 1653 A. Connection via PPPoA 1655 Customer Premise NAP NSP 1656 |--------------------| |----------------------| |----------------| 1657 +-----------+ 1658 | AAA | 1659 +-------+ Radius | 1660 | | TACACS | 1661 | +-----+-----+ 1662 | | 1663 +-----+ +-------+ +--------+ +----+-----+ +-----+-----+ 1664 |Hosts|--+Router +------+ DSLAM +-+ BRAS +-+ Edge | 1665 +-----+ +-------+ +--------+ +----------+ | Router +=>Core 1666 +-----------+ 1667 |----------------------------------------| 1668 PPP 1669 |------------| 1670 L2TPv2 1671 Figure 7.2.3.1 1673 B. Connection via PPPoE 1675 Customer Premise NAP NSP 1676 |--------------------------| |--------------------| |---------------| 1677 +-----------+ 1678 | AAA | 1679 +------+ Radius | 1680 | | TACACS | 1681 | +-----+-----+ 1682 | | 1683 +-----+ +-------+ +--------+ +----+-----+ +----+------+ 1684 |Hosts|--+Router +-----------+ DSLAM +-+ BRAS +-+ Edge | C 1685 +-----+ +-------+ +--------+ +----------+ | Router +=>O 1686 | | R 1687 +-----------+ E 1688 |-----------------------------------------------| 1689 PPP 1690 |--------------| 1691 L2TPv2 1692 Figure 7.2.3.2 1694 The network design and operation of the PTA model is the same 1695 regardless of the PPP encapsulation type used. 1697 7.2.3.1 IPv6 Related Infrastructure Changes 1699 In this scenario the BRAS is forwarding the PPP sessions initiated by 1700 the subscriber over the L2TPv2 tunnel established to the LNS, the 1701 aggregation point in the ISP network. The L2TPv2 tunnel between the 1702 LAC and LNS could run over IPv6 or IPv4. These capabilities have to 1703 be supported on the BRAS. The following devices have to be upgraded 1704 to dual stack: Host, Customer Router and Edge Router. If the tunnel 1705 is set up over IPv6 then the BRAS must be upgraded to dual stack. 1707 7.2.3.2 Addressing 1709 The Edge router terminates the PPP sessions and provides the 1710 subscriber with an IPv6 address from the defined pool for that 1711 profile. The subscriber profile for authorization and authentication 1712 can be located on the Edge Router or on a AAA server. The Hosts or 1713 the Customer Routers have the Edge Router as their Layer 3 next hop. 1715 The PPP session can be initiated by a host or by a Customer Router. 1716 In the latter case, once the session is established with the Edge 1717 Router, DHCP-PD can be used to acquire prefixes for the Customer 1718 Router interfaces. The Edge Router has to be enabled to support 1719 DHCP-PD and to relay the DHCPv6 requests generated by the hosts on 1720 the subscriber sites. 1722 The BRAS has a /64 prefix configured on the link to the Edge router. 1723 The Edge router links are also configured with /64 prefixes to 1724 provide connectivity to the rest of the ISP network. Other 1725 information of interest to the host, such as DNS, is provided through 1726 stateful [10] and stateless [9] DHCPv6. 1728 It is important to note here a significant difference between this 1729 deployment for IPv6 versus IPv4. In the case of IPv4 the customer 1730 router or CPE can end up on any Edge Router (acting as LNS) where the 1731 assumption is that there are at least two of them for redundancy 1732 purposes. Once authenticated, the customer will be given an address 1733 from the IP pool of the ER (LNS) it connected to. This allows the 1734 ERs (LNSs) to aggregate the addresses handed out to the customers. 1735 In the case of IPv6, an important constraint that likely will be 1736 enforced is that the customer should keep its own address regardless 1737 of the ER (LNS) it connects to. This could significantly reduce the 1738 prefix aggregation capabilities of the ER (LNS). This is different 1739 than the current IPv4 deployment where addressing is dynamic in 1740 nature and the same user can get different addresses depending on the 1741 LNS it ends up connecting to. 1743 One possible solution is to ensure that a given BRAS will always 1744 connect to the same ER (LNS) unless that LNS is down. This means 1745 that customers from a given prefix range will always be connected to 1746 the same ER (primary if up or secondary if not). Each ER (LNS) can 1747 carry summary statements in their routing protocol configuration for 1748 the prefixes they are the primary ER (LNS) as well as for the ones 1749 for which they are the secondary. This way the prefixes will be 1750 summarized any time they become "active" on the ER (LNS). 1752 7.2.3.3 Routing 1754 The CPE devices are configured with a default route that points to 1755 the Edge router that terminates the PPP sessions. No routing 1756 protocols are needed on these devices which have generally limited 1757 resources. 1759 The BRAS runs an IPv6 IGP to the Edge Router: OSPFv3 or IS-IS. 1760 Different processes should be used if the NAP and the NSP are managed 1761 by different organizations. In this case, controlled redistribution 1762 should be enabled between the two domains. 1764 The Edge Router is running the IPv6 IGP used in the ISP network: 1765 OSPFv3 or IS-IS. 1767 7.2.4 Hybrid Model for IPv4 and IPv6 Service 1769 It was recommended throughout this section that the IPv6 service 1770 implementation should map the existent IPv4 one. This approach 1771 simplifies manageability and minimizes training needed for personnel 1772 operating the network. In certain circumstances such mapping is not 1773 feasible. This typically becomes the case when a Service Provider 1774 plans to expand its service offering with the new IPv6 deployed 1775 infrastructure. If this new service is not well supported in a 1776 network design such as the one used for IPv4 then a different design 1777 might be used for IPv6. 1779 An example of such circumstances is that of a provider using an LAA 1780 design for its IPv4 services. In this case all the PPP sessions are 1781 bundled and tunneled across the entire NAP infrastructure which is 1782 made of multiple BRAS routers, aggregation routers etc. The end 1783 point of these tunnels is the ISP Edge Router. If the provider 1784 decides to offer multicast services over such a design, it will face 1785 the problem of NAP resources being over utilized. The multicast 1786 traffic can be replicated only at the end of the tunnels by the Edge 1787 router and the copies for all the subscribers are carried over the 1788 entire NAP. 1790 A Modified Point-to-Point (as described in 7.2.4.2) or PTA model are 1791 more suitable to support multicast services because the packet 1792 replication can be done closer to the destination at the BRAS. Such 1793 topology saves NAP resources. 1795 In this sense IPv6 deployment can be viewed as an opportunity to 1796 build an infrastructure that might better support the expansion of 1797 services. In this case, an SP using the LAA design for its IPv4 1798 services might choose a modified Point-to-Point or PTA design for 1799 IPv6. 1801 7.2.4.1 IPv4 in LAA Model and IPv6 in PTA Model 1803 The coexistence of the two PPP based models, PTA and LAA, is 1804 relatively straight forward. The PPP sessions are terminated on 1805 different network devices for the IPv4 and IPv6 services. The PPP 1806 sessions for the existent IPv4 service deployed in an LAA model are 1807 terminated on the Edge Router. The PPP sessions for the new IPv6 1808 service deployed in a PTA model are terminated on the BRAS. 1810 The logical design for IPv6 and IPv4 in this hybrid model is 1811 presented in Figure 7.2.4.1. 1813 IPv6 |--------------------------| 1814 PPP +-----------+ 1815 | AAA | 1816 +-------+ Radius | 1817 | | TACACS | 1818 | +-----+-----+ 1819 | | 1820 +-----+ +-------+ +--------+ +----+-----+ +-----+-----+ 1821 |Hosts|--+Router +------+ DSLAM +-+ BRAS +-+ Edge | 1822 +-----+ +-------+ +--------+ +----------+ | Router +=>Core 1823 +-----------+ 1824 IPv4 |----------------------------------------| 1825 PPP 1826 |------------| 1827 L2TPv2 1828 Figure 7.2.4.1 1830 7.2.4.2 IPv4 in LAA Model and IPv6 in Modified Point-to-Point Model 1832 In this particular scenario the Point-to-Point model used for the 1833 IPv6 service is a modified version of the model described in section 1834 7.2.1. 1836 For the IPv4 service in LAA model, the VLANs are terminated on the 1837 BRAS and PPP sessions are terminated on the Edge Router (LNS). For 1838 IPv6 service in Point-to-Point model, the VLANs are terminated at the 1839 Edge Router as described in section 7.2.1. In this hybrid model, the 1840 Point-to-Point link could be terminated on the BRAS, a NAP owned 1841 device. The IPv6 traffic is then routed through the NAP network to 1842 the NSP. In order to have this hybrid model, the BRAS has to be 1843 upgraded to a dual-stack router. The functionalities of the Edge 1844 Router as described in section 7.2.1 are now implemented on the BRAS. 1846 The other aspect of this deployment model is the fact that the BRAS 1847 has to be capable of distinguishing between the IPv4 PPP traffic that 1848 has to be bridged across the L2TPv2 tunnel and the IPv6 packets that 1849 have to be routed to the NSP. The IPv6 Routing and Bridging 1850 Encapsulation (RBE) has to be enabled on all interfaces with VLANs 1851 supporting both IPv4 and IPv6 services in this hybrid design. 1853 The logical design for IPv6 and IPv4 in this hybrid model is 1854 presented in Figure 7.2.4.2. 1856 IPv6 |----------------| 1857 ATM +-----------+ 1858 | AAA | 1859 +-------+ Radius | 1860 | | TACACS | 1861 | +-----+-----+ 1862 | | 1863 +-----+ +-------+ +--------+ +----+-----+ +-----+-----+ 1864 |Hosts|--+Router +------+ DSLAM +-+ BRAS +-+ Edge | 1865 +-----+ +-------+ +--------+ +----------+ | Router +=>Core 1866 +-----------+ 1867 IPv4 |----------------------------------------| 1868 PPP 1869 |------------| 1870 L2TPv2 1871 Figure 7.2.4.2 1873 7.3 IPv6 Multicast 1875 The deployment of IPv6 multicast services relies on MLD, identical to 1876 IGMP in IPv4 and on PIM for routing. ASM (Any Source Multicast) and 1877 SSM (Single Source Multicast) service models operate almost the same 1878 as in IPv4. Both have the same benefits and disadvantages as in 1879 IPv4. Nevertheless, the larger address space and the scoped address 1880 architecture provide major benefits for multicast IPv6. Through 1881 RFC3306 the large address space provides the means to assign global 1882 multicast group addresses to organizations or users that were 1883 assigned unicast prefixes. It is a significant improvement with 1884 respect to the IPv4 GLOP mechanism [18]. 1886 This facilitates the deployment of multicast services. The 1887 discussion of this section applies to all the multicast sections in 1888 the document. 1890 7.3.1 ASM Based Deployments 1892 Any Source Multicast (ASM) is useful for Service Providers that 1893 intend to support the forwarding of multicast traffic of their 1894 customers. It is based on the PIM-SM protocol and it is more complex 1895 to manage because of the use of Rendezvous Points (RPs). With IPv6, 1896 static RP and BSR [34] can be used for RP-to-group mapping similar to 1897 IPv4. Additionally, the larger IPv6 address space allows for 1898 building up of group addresses that incorporate the address of the 1899 RP. This RP-to-group mapping mechanism is called Embedded RP and is 1900 specific to IPv6. 1902 In inter-domain deployments, Multicast Source Discovery Protocol 1903 (MSDP) [21] is an important element of IPv4 PIM-SM deployments. MSDP 1904 is meant to be a solution for the exchange of source registration 1905 information between RPs in different domains. This solution was 1906 intended to be temporary. This is one of the reasons why it was 1907 decided not to implement MSDP in IPv6 [32]. 1909 For multicast reachability across domains, Embedded RP can be used. 1910 As Embedded RP provides roughly the same capabilities as MSDP, but in 1911 a slightly different way, the best management practices for ASM 1912 multicast with embedded RP still remain to be developed. 1914 7.3.2 SSM Based Deployments 1916 Based on PIM-SSM, the Source Specific Multicast deployments do not 1917 need an RP and the related protocols (such as BSR or MSDP) but rely 1918 on the listeners to know the source of the multicast traffic they 1919 plan to receive. The lack of RP makes SSM not only simpler to 1920 operate but also robust, it is not impacted by RP failures or inter 1921 domain constraints. It is also has a higher level of security (No RP 1922 to be targeted by attacks). For more discussions on the topic of 1923 IPv6 multicast see [32]. 1925 The typical multicast services offered for residential and very small 1926 businesses is video/audio streaming where the subscriber joins a 1927 multicast group and receives the content. This type of service model 1928 is well supported through PIM-SSM which is very simple and easy to 1929 manage. PIM-SSM has to be enabled throughout the SP network. MLDv2 1930 is required for PIM-SSM support. Vendors can choose to implement 1931 features that allow routers to map MLDv1 group joins to predefined 1932 sources. 1934 Subscribers might use a set-top box that is responsible for the 1935 control piece of the multicast service (does group joins/leaves). 1936 The subscriber hosts can also join desired multicast groups as long 1937 as they are enabled to support MLDv1 or MLDv2. If a customer premise 1938 router is used then it has to be enabled to support MLDv1 and MLDv2 1939 in order to process the requests of the hosts. It has to be enabled 1940 to support PIM-SSM in order to send PIM joins/leaves up to its Layer 1941 3 next hop whether it is the BRAS or the Edge router. When enabling 1942 this functionality on a customer premise router, its limited 1943 resources should be taken into consideration. Another option would 1944 be for the customer premise router to support MLD proxy routing. 1946 The router that is the Layer 3 next hop for the subscriber (BRAS in 1947 the PTA model or the Edge router in the LAA and Point-to-Point model) 1948 has to be enabled to support MLDv1 and MLDv2 in order to process the 1949 requests coming from subscribers without customer premise routers. 1950 It has to be enabled for PIM-SSM in order to receive joins/leaves 1951 from customer routers and send joins/leaves to the next hop towards 1952 the multicast source (Edge router or the NSP core). 1954 MLD authentication, authorization and accounting is usually 1955 configured on the edge router in order to enable the ISP to do 1956 control the subscriber access of the service and do billing for the 1957 content provided. Alternative mechanisms that would support these 1958 functions should be investigated further. 1960 7.4 IPv6 QoS 1962 The QoS configuration is particularly relevant on the router that 1963 represents the Layer 3 next hop for the subscriber (BRAS in the PTA 1964 model or the Edge router in the LAA and Point-to-Point model) in 1965 order to manage resources shared amongst multiple subscribers 1966 possibly with various service level agreements. 1968 In the DSL infrastructure it is expected that there is already a 1969 level of traffic policing and shaping implemented for IPv4 1970 connectivity. This is implemented throughout the NAP and it is 1971 beyond the scope of this document. 1973 On the BRAS or the Edge Router the subscriber facing interfaces have 1974 to be configure to police the inbound customer traffic and shape the 1975 traffic outbound to the customer based on the SLAs. Traffic 1976 classification and marking should also be done on the router closest 1977 (at Layer 3) to the subscriber in order to support the various types 1978 of customer traffic: data, voice, video and to optimally use the 1979 infrastructure resources. Each provider (NAP, NSP) could implement 1980 their own QoS policies and services so reclassification and marking 1981 might be performed at the boundary between the NAP and the NSP in 1982 order to make sure the traffic is properly handled by the ISP. The 1983 same IPv4 QoS concepts and methodologies should be applied with IPv6 1984 as well. 1986 It is important to note that when traffic is encrypted end-to-end, 1987 the traversed network devices will not have access to many of the 1988 packet fields used for classification purposes. In these cases 1989 routers will most likely place the packets in the default classes. 1990 The QoS design should take into consideration this scenario and try 1991 to use mainly IP header fields for classification purposes. 1993 7.5 IPv6 Security Considerations 1995 There are limited changes that have to be done for CPEs in order to 1996 enhance security. The Privacy extensions for auto-configuration [13] 1997 should be used by the hosts. ISPs can track the prefixes it assigns 1998 to subscribers relatively easily. If however the ISPs are required 1999 by regulations to track their users at /128 address level, the 2000 Privacy Extensions can be implemented only in parallel with network 2001 management tools that could provide traceability of the hosts. IPv6 2002 firewall functions should be enabled on the hosts or customer premise 2003 router if present. 2005 The ISP provides security against attacks that come form its own 2006 subscribers but it could also implement security services that 2007 protect its subscribers from attacks sourced from the outside of its 2008 network. Such services do not apply at the access level of the 2009 network discussed here. 2011 The device that is the Layer 3 next hop for the subscribers (BRAS or 2012 Edge router) should protect the network and the other subscribers 2013 against attacks by one of the provider customers. For this reason 2014 uRPF and ACLs should be used on all interfaces facing subscribers. 2015 Filtering should be implemented with regard for the operational 2016 requirements of IPv6 [36]. Authentication and authorization should 2017 be used wherever possible. 2019 The BRAS and the Edge Router should protect their processing 2020 resources against floods of valid customer control traffic such as: 2021 Router and Neighbor Solicitations, MLD Requests. Rate limiting 2022 should be implemented on all subscriber facing interfaces. The 2023 emphasis should be placed on multicast type traffic as it is most 2024 often used by the IPv6 control plane. 2026 All other security features used with the IPv4 service should be 2027 similarly applied to IPv6 as well. 2029 7.6 IPv6 Network management 2031 The necessary instrumentation (such as MIBs, NetFlow Records etc) 2032 should be available for IPv6. 2034 Usually, NSPs manage the edge routers by SNMP. The SNMP transport 2035 can be done over IPv4 if all managed devices have connectivity over 2036 both IPv4 and IPv6. This would imply the smallest changes to the 2037 existent network management practices and processes. Transport over 2038 IPv6 could also be implemented and it might become necessary if IPv6 2039 only islands are present in the network. The management stations are 2040 located on the core network. Network Management Applications should 2041 handle IPv6 in a similar fashion to IPv4, however, they should also 2042 support features specific to IPv6 (such as Neighbor monitoring). 2044 In some cases service providers manage equipment located on customers 2045 LANs. The management of equipment at customers' LANs is out of scope 2046 of this memo. 2048 8. Broadband Ethernet Networks 2050 This section describes the IPv6 deployment options in currently 2051 deployed Broadband Ethernet Access Networks. 2053 8.1 Ethernet Access Network Elements 2055 In environments that support the infrastructure deploying RJ-45 or 2056 fiber (Fiber to the Home (FTTH) service) to subscribers, 10/100 Mbps 2057 Ethernet broadband services can be provided. Such services are 2058 generally available in metropolitan areas, in multi tenant buildings 2059 where an Ethernet infrastructure can be deployed in a cost effective 2060 manner. In such environments Metro-Ethernet services can be used to 2061 provide aggregation and uplink to a Service Provider. 2063 The following network elements are typical of an Ethernet network: 2065 Access Switch: It is used as a Layer 2 access device for subscribers. 2067 Customer Premise Router: It is used to provide Layer 3 services for 2068 customer premise networks. 2070 Aggregation Ethernet Switches: Aggregates multiple subscribers. 2072 Broadband Remote Access Server (BRAS) 2074 Edge Router (ER) 2076 Figure 8.1 depicts all the network elements mentioned. 2078 Customer Premise | Network Access Provider | Network Service Provider 2079 CP NAP NSP 2081 +-----+ +------+ +------+ +--------+ 2082 |Hosts|--|Router| +-+ BRAS +--+ Edge | ISP 2083 +-----+ +--+---+ | | | | Router +===> Network 2084 | | +------+ +--------+ 2085 +--+----+ | 2086 |Access +-+ | 2087 |Switch | | | 2088 +-------+ | +------+ | 2089 +--+Agg E | | 2090 +-------+ |Switch+-+ 2091 +-----+ |Access | +--+ | 2092 |Hosts|--+Switch +-+ +------+ 2093 +-----+ +-------+ 2094 Figure 8.1 2096 The logical topology and design of Broadband Ethernet Networks is 2097 very similar to DSL Broadband Networks discussed in section 7. 2099 It is worth noting that the general operation, concepts and 2100 recommendations described in this section apply similarly to a 2101 HomePNA based network environment. In such an environment some of 2102 the network elements might be differently named. 2104 8.2 Deploying IPv6 in IPv4 Broadband Ethernet Networks 2106 There are three main design approaches to providing IPv4 connectivity 2107 over an Ethernet infrastructure: 2109 A. Point-to-Point Model: Each subscriber connects to the network 2110 Access switch over RJ-45 or fiber links. Each subscriber is assigned 2111 a unique VLAN on the access switch. The VLAN can be terminated at 2112 the BRAS or at the Edge Router. The VLANs are 802.1q trunked to the 2113 Layer 3 device (BRAS or Edge Router). 2115 This model is presented in section 8.2.1. 2117 B. PPP Terminated Aggregation (PTA) Model: PPP sessions are opened 2118 between each subscriber and the BRAS. The BRAS terminates the PPP 2119 sessions and provides Layer 3 connectivity between the subscriber and 2120 the ISP. 2122 This model is presented in section 8.2.2. 2124 C. L2TPv2 Access Aggregation (LAA) Model: PPP sessions are opened 2125 between each subscriber and the ISP termination devices. The BRAS 2126 tunnels the subscriber PPP sessions to the ISP by encapsulating them 2127 into L2TPv2 tunnels. 2129 This model is presented in section 8.2.3. 2131 In aggregation models the BRAS terminates the subscriber VLANs and 2132 aggregates their connections before providing access to the ISP. 2134 In order to maintain the deployment concepts and business models 2135 proven and used with existent revenue generating IPv4 services, the 2136 IPv6 deployment will match the IPv4 one. This approach is presented 2137 in sections 8.2.1-3 that describe currently deployed IPv4 over 2138 Ethernet broadband access deployments. Under certain circumstances 2139 where new service types or service needs justify it, IPv4 and IPv6 2140 network architectures could be different as described in section 2141 8.2.4. 2143 8.2.1 Point-to-Point Model 2145 In this scenario the Ethernet frames from the Host or the Customer 2146 Premise Router are bridged over the VLAN assigned to the subscriber. 2148 Figure 8.2.1 describes the protocol architecture of this model. 2150 | Customer Premise | | NAP | NSP | 2152 +-----+ +------+ +------+ +--------+ +----------+ 2153 |Hosts|--+Router+--+Access+--+ Switch +--------+ Edge | ISP 2154 +-----+ +------+ |Switch| +--------+ 802.1q | Router +=>Network 2155 +------+ +----------+ 2157 |----------------------------| 2158 Ethernet/VLANs 2160 Figure 8.2.1 2162 8.2.1.1 IPv6 Related Infrastructure Changes 2164 In this scenario the Access Switch on the customer site and the 2165 entire NAP is Layer 3 unaware so no changes are needed to support 2166 IPv6. The following devices have to be upgraded to dual stack: Host, 2167 Customer Router and Edge Router. 2169 The Access switches might need upgrades to support certain IPv6 2170 related features such as MLD Snooping. 2172 8.2.1.2 Addressing 2174 The Hosts or the Customer Routers have the Edge Router as their Layer 2175 3 next hop. If there is no Customer Router all the hosts on the 2176 subscriber site belong to the same /64 subnet that is statically 2177 configured on the Edge Router for that subscriber VLAN. The hosts 2178 can use stateless auto-configuration or stateful DHCPv6 based 2179 configuration to acquire an address via the Edge Router. 2181 However, as manual configuration for each customer is a provisioning 2182 challenge, implementations are encouraged to develop mechanism(s) 2183 which automatically map the VLAN (or some other customer-specific 2184 information) to an IPv6 subnet prefix, and advertise the customer- 2185 specific prefix to all the customers with minimal configuration. 2187 If a Customer Router is present: 2189 A. It is statically configured with an address on the /64 subnet 2190 between itself and the Edge Router, and with /64 prefixes on the 2191 interfaces connecting the hosts on the customer site. This is not a 2192 desired provisioning method being expensive and difficult to manage. 2194 B. It can use its link-local address to communicate with the ER. It 2195 can also dynamically acquire through stateless auto-configuration the 2196 address for the link between itself and the ER. This step is 2197 followed by a request via DHCP-PD for a prefix shorter than /64 that 2198 in turn is divided in /64s and assigned to its interfaces connecting 2199 the hosts on the customer site. 2201 The Edge Router has a /64 prefix configured for each subscriber VLAN. 2202 Each VLAN should be enabled to relay DHCPv6 requests from the 2203 subscribers to DHCPv6 servers in the ISP network. The VLANs 2204 providing access for subscribers that use DHCP-PD as well, have to be 2205 enabled to support the feature. Currently the DHCP-PD functionality 2206 cannot be implemented if the DHCP-PD server is not the Edge Router. 2207 If the DHCP-PD messages are relayed, the Edge Router does not have a 2208 mechanism to learn the assigned prefixes and thus install the proper 2209 routes to make that prefix reachable. Work is being done to address 2210 this issue, one idea being to provide the Edge Router with a snooping 2211 mechanism. The uplink to the ISP network is configured with a /64 2212 prefix as well. The uplink to the ISP network is configured with a 2213 /64 prefix as well. 2215 The prefixes used for subscriber links and the ones delegated via 2216 DHCP-PD should be planned in a manner that allows as much 2217 summarization as possible at the Edge Router. 2219 Other information of interest to the host, such as DNS, is provided 2220 through stateful [10] and stateless [9] DHCPv6. 2222 8.2.1.3 Routing 2224 The CPE devices are configured with a default route that points to 2225 the Edge router. No routing protocols are needed on these devices 2226 which generally have limited resources. 2228 The Edge Router runs the IPv6 IGP used in the NSP: OSPFv3 or IS-IS. 2229 The connected prefixes have to be redistributed. If DHCP-PD is used, 2230 with every delegated prefix a static route is installed by the Edge 2231 Router. For this reason the static routes must also be 2232 redistributed. Prefix summarization should be done at the Edge 2233 Router. 2235 8.2.2 PPP Terminated Aggregation (PTA) Model 2237 The PTA architecture relies on PPP-based protocols (PPPoE). The PPP 2238 sessions are initiated by Customer Premise Equipment and it is 2239 terminated at the BRAS. The BRAS authorizes the session, 2240 authenticates the subscriber, and provides an IP address on behalf of 2241 the ISP. The BRAS then does Layer 3 routing of the subscriber 2242 traffic to the NSP Edge Router. This model is often used when the 2243 NSP is also the NAP. The PPPoE logical diagram in an Ethernet 2244 Broadband Network is shown in Fig 8.2.2.1. 2246 | Customer Premise | | NAP | | NSP | 2248 +-----------+ 2249 | AAA | 2250 +-------+ Radius | 2251 | | TACACS | 2252 | +-----------+ 2253 +-----+ +-------+ +--------+ +--------+ +----+-----+ +-----------+ 2254 |Hosts|-+Router +-+A Switch+-+ Switch +-+ BRAS +-+ Edge | C 2255 +-----+ +-------+ +--------+ +--------+ +----------+ | Router +=>O 2256 |---------------- PPP ----------------| | | R 2257 +-----------+ E 2258 Figure 8.2.2.1 2260 The PPP sessions are initiated by the Customer Premise Equipment 2261 (Host or Router). The BRAS authenticates the subscriber against a 2262 local or a remote database. Once the session is established, the 2263 BRAS provides an address and maybe a DNS server to the user, 2264 information acquired from the subscriber profile or from a DHCP 2265 server. 2267 This model allows for multiple PPPoE sessions to be supported over 2268 the same VLAN thus allowing the subscriber to connect to multiple 2269 services at the same time. The hosts can initiate the PPPoE sessions 2270 as well. It is important to remember that the PPPoE encapsulation 2271 reduces the IP MTU available for the customer traffic. 2273 8.2.2.1 IPv6 Related Infrastructure Changes 2275 In this scenario the BRAS is Layer 3 aware and it has to be upgraded 2276 to support IPv6. Since the BRAS terminates the PPP sessions it has 2277 to support PPPoE with IPv6. The following devices have to be 2278 upgraded to dual stack: Host, Customer Router (if present), BRAS and 2279 Edge Router. 2281 8.2.2.2 Addressing 2283 The BRAS terminates the PPP sessions and provides the subscriber with 2284 an IPv6 address from the defined pool for that profile. The 2285 subscriber profile for authorization and authentication can be 2286 located on the BRAS or on a AAA server. The Hosts or the Customer 2287 Routers have the BRAS as their Layer 3 next hop. 2289 The PPP session can be initiated by a host or by a Customer Router. 2290 In the latter case, once the session is established with the BRAS, 2291 DHCP-PD can be used to acquire prefixes for the Customer Router 2292 interfaces. The BRAS has to be enabled to support DHCP-PD and to 2293 relay the DHCPv6 requests of the hosts on the subscriber sites. 2294 Currently the DHCP-PD functionality cannot be implemented if the 2295 DHCP-PD server is not the Edge Router. If the DHCP-PD messages are 2296 relayed, the Edge Router does not have a mechanism to learn the 2297 assigned prefixes and thus install the proper routes to make that 2298 prefix reachable. Work is being done to address this issue, one idea 2299 being to provide the Edge Router with a snooping mechanism. The 2300 uplink to the ISP network is configured with a /64 prefix as well. 2302 The BRAS has a /64 prefix configured on the link facing the Edge 2303 router. The Edge router links are also configured with /64 prefixes 2304 to provide connectivity to the rest of the ISP network. 2306 The prefixes used for subscriber and the ones delegated via DHCP-PD 2307 should be planned in a manner that allows maximum summarization at 2308 the BRAS. 2310 Other information of interest to the host, such as DNS, is provided 2311 through stateful [10] and stateless [9] DHCPv6. 2313 8.2.2.3 Routing 2315 The CPE devices are configured with a default route that points to 2316 the BRAS router. No routing protocols are needed on these devices 2317 which generally have limited resources. 2319 The BRAS runs an IGP to the Edge Router: OSPFv3 or IS-IS. Since the 2320 addresses assigned to the PPP sessions are represented as connected 2321 host routes, connected prefixes have to be redistributed. If DHCP-PD 2322 is used, with every delegated prefix a static route is installed by 2323 the BRAS. For this reason the static routes must also be 2324 redistributed. Prefix summarization should be done at the BRAS. 2326 The Edge Router is running the IGP used in the ISP network: OSPFv3 or 2327 IS-IS. A separation between the routing domains of the ISP and the 2328 Access Provider is recommended if they are managed independently. 2329 Controlled redistribution will be needed between the Access Provider 2330 IGP and the ISP IGP. 2332 8.2.3 L2TPv2 Access Aggregation (LAA) Model 2334 In the LAA model the BRAS forwards the CPE initiated session to the 2335 ISP over an L2TPv2 tunnel established between the BRAS and the Edge 2336 Router. In this case the authentication, authorization and 2337 subscriber configuration are performed by the ISP itself. 2339 | Customer Premise | | NAP | | NSP | 2341 +-----------+ 2342 | AAA | 2343 +------+ Radius | 2344 | | TACACS | 2345 | +-----+-----+ 2346 | | 2347 +-----+ +-------+ +--------+ +--------+ +----+-----+ +-----------+ 2348 |Hosts|-+Router +-+A Switch+-+ Switch +-+ BRAS +-+ Edge | C 2349 +-----+ +-------+ +--------+ +--------+ +----------+ | Router +=>O 2350 | | R 2351 +-----------+ E 2352 |-----------------------------------------------| 2353 PPP 2354 |--------------| 2355 L2TPv2 2356 Figure 8.2.3.1 2358 8.2.3.1 IPv6 Related Infrastructure Changes 2360 In this scenario the BRAS is Layer 3 aware and it has to be upgraded 2361 to support IPv6. The PPP sessions initiated by the subscriber are 2362 forwarded over the L2TPv2 tunnel to the aggregation point in the ISP 2363 network. The BRAS (LAC) can aggregate IPv6 PPP sessions and tunnel 2364 them to the LNS using L2TPv2. The L2TPv2 tunnel between the LAC and 2365 LNS could run over IPv6 or IPv4. These capabilities have to be 2366 supported on the BRAS. The following devices have to be upgraded to 2367 dual stack: Host, Customer Router (if present), BRAS and Edge Router. 2369 8.2.3.2 Addressing 2371 The Edge router terminates the PPP sessions and provides the 2372 subscriber with an IPv6 address from the defined pool for that 2373 profile. The subscriber profile for authorization and authentication 2374 can be located on the Edge Router or on a AAA server. The Hosts or 2375 the Customer Routers have the Edge Router as their Layer 3 next hop. 2377 The PPP session can be initiated by a host or by a Customer Router. 2378 In the latter case, once the session is established with the Edge 2379 Router and an IPv6 address is assigned to the Customer Router by the 2380 Edge router, DHCP-PD can be used to acquire prefixes for the Customer 2381 Router other interfaces. The Edge Router has to be enabled to 2382 support DHCP-PD and to relay the DHCPv6 requests of the hosts on the 2383 subscriber sites. Currently the DHCP-PD functionality cannot be 2384 implemented if the DHCP-PD server is not the Edge Router. If the 2385 DHCP-PD messages are relayed, the Edge Router does not have a 2386 mechanism to learn the assigned prefixes and thus install the proper 2387 routes to make that prefix reachable. Work is being done to address 2388 this issue, one idea being to provide the Edge Router with a snooping 2389 mechanism. The uplink to the ISP network is configured with a /64 2390 prefix as well. 2392 The BRAS has a /64 prefix configured on the link to the Edge router. 2393 The Edge router links are also configured with /64 prefixes to 2394 provide connectivity to the rest of the ISP network. 2396 Other information of interest to the host, such as DNS, is provided 2397 through stateful [10] and stateless [9] DHCPv6. 2399 The address assignment and prefix summarization issues discussed in 2400 section 7.2.3.2 are relevant in the same way for this media access 2401 type as well. 2403 8.2.3.3 Routing 2405 The CPE devices are configured with a default route that points to 2406 the Edge router that terminates the PPP sessions. No routing 2407 protocols are needed on these devices which have limited resources. 2409 The BRAS runs an IPv6 IGP to the Edge Router: OSPFv3 or IS-IS. 2410 Different processes should be used if the NAP and the NSP are managed 2411 by different organizations. In this case controlled redistribution 2412 should be enabled between the two domains. 2414 The Edge Router is running the IPv6 IGP used in the ISP network: 2415 OSPFv3 or IS-IS. 2417 8.2.4 Hybrid Model for IPv4 and IPv6 Service 2419 It was recommended throughout this section that the IPv6 service 2420 implementation should map the existent IPv4 one. This approach 2421 simplifies manageability and minimizes training needed for personnel 2422 operating the network. In certain circumstances such mapping is not 2423 feasible. This typically becomes the case when a Service Provider 2424 plans to expand its service offering with the new IPv6 deployed 2425 infrastructure. If this new service is not well supported in a 2426 network design such as the one used for IPv4 then a different design 2427 might be used for IPv6. 2429 An example of such circumstances is that of a provider using an LAA 2430 design for its IPv4 services. In this case all the PPP sessions are 2431 bundled and tunneled across the entire NAP infrastructure which is 2432 made of multiple BRAS routers, aggregation routers etc. The end 2433 point of these tunnels is the ISP Edge Router. If the SP decides to 2434 offer multicast services over such a design, it will face the problem 2435 of NAP resources being over utilized. The multicast traffic can be 2436 replicated only at the end of the tunnels by the Edge router and the 2437 copies for all the subscribers are carried over the entire NAP. 2439 A Modified Point-to-Point (see section 8.2.4.2) or a PTA model is 2440 more suitable to support multicast services because the packet 2441 replication can be done closer to the destination at the BRAS. Such 2442 topology saves NAP resources. 2444 In this sense IPv6 deployments can be viewed as an opportunity to 2445 build an infrastructure that can better support the expansion of 2446 services. In this case, an SP using the LAA design for its IPv4 2447 services might choose a modified Point-to-Point or PTA design for 2448 IPv6. 2450 8.2.4.1 IPv4 in LAA Model and IPv6 in PTA Model 2452 The coexistence of the two PPP based models, PTA and LAA, is 2453 relatively straight forward. It is a straight forward overlap of the 2454 two deployment models. The PPP sessions are terminated on different 2455 network devices for the IPv4 and IPv6 services. The PPP sessions 2456 for the existent IPv4 service deployed in an LAA model are terminated 2457 on the Edge Router. The PPP sessions for the new IPv6 service 2458 deployed in a PTA model are terminated on the BRAS. 2460 The logical design for IPv6 and IPv4 in this hybrid model is 2461 presented in Figure 8.2.4.1. 2463 IPv6 |--------------------------| 2464 PPP +-----------+ 2465 | AAA | 2466 +-------+ Radius | 2467 | | TACACS | 2468 | +-----+-----+ 2469 | | 2470 +-----+ +-------+ +--------+ +----+-----+ +-----+-----+ 2471 |Hosts|--+Router +------+ Switch +-+ BRAS +-+ Edge | 2472 +-----+ +-------+ +--------+ +----------+ | Router +=>Core 2473 +-----------+ 2475 IPv4 |----------------------------------------| 2476 PPP 2477 |------------| 2478 L2TPv2 2479 Figure 8.2.4.1 2481 8.2.4.2 IPv4 in LAA Model and IPv6 in Modified Point-to-Point Model 2483 The coexistence of the modified Point-to-Point and the LAA models 2484 implies a few specific changes. 2486 For the IPv4 service in LAA model, the VLANs are terminated on the 2487 BRAS and PPP sessions are terminated on the Edge Router (LNS). For 2488 IPv6 service in Point-to-Point model, the VLANs are terminated at the 2489 Edge Router as described in section 7.2.1. In this hybrid model, the 2490 Point-to-Point link could be terminated on the BRAS, a NAP owned 2491 device. The IPv6 traffic is then routed through the NAP network to 2492 the NSP. In order to have this hybrid model, the BRAS has to be 2493 upgraded to a dual-stack router. The functionalities of the Edge 2494 Router as described in section 7.2.1 are now implemented on the BRAS. 2496 The logical design for IPv6 and IPv4 in this hybrid model is in 2497 Figure 8.2.4.2. 2499 IPv6 |----------------| 2500 Ethernet 2501 +-----------+ 2502 | AAA | 2503 +-------+ Radius | 2504 | | TACACS | 2505 | +-----+-----+ 2506 | | 2507 +-----+ +-------+ +--------+ +----+-----+ +-----+-----+ 2508 |Hosts|--+Router +------+ Switch +-+ BRAS +-+ Edge | 2509 +-----+ +-------+ +--------+ +----------+ | Router +=>Core 2510 +-----------+ 2511 IPv4 |----------------------------------------| 2512 PPP 2513 |------------| 2514 L2TPv2 2515 Figure 8.2.4.2 2517 8.3 IPv6 Multicast 2519 The typical multicast services offered for residential and very small 2520 businesses is video/audio streaming where the subscriber joins a 2521 multicast group and receives the content. This type of service model 2522 is well supported through PIM-SSM which is very simple and easy to 2523 manage. PIM-SSM has to be enabled throughout the ISP network. MLDv2 2524 is required for PIM-SSM support. Vendors can choose to implement 2525 features that allow routers to map MLDv1 group joins to predefined 2526 sources. 2528 Subscribers might use a set-top box that is responsible for the 2529 control piece of the multicast service (does group joins/leaves). 2530 The subscriber hosts can also join desired multicast groups as long 2531 as they are enabled to support MLDv1 or MLDv2. If a customer premise 2532 router is used then it has to be enabled to support MLDv1 and MLDv2 2533 in order to process the requests of the hosts. It has to be enabled 2534 to support PIM-SSM in order to send PIM joins/leaves up to its Layer 2535 3 next hop whether it is the BRAS or the Edge router. When enabling 2536 this functionality on a customer premise router, its limited 2537 resources should be taken into consideration. Another option would 2538 be for the customer premise router to support MLD proxy routing. MLD 2539 snooping or similar layer two multicast related protocols could be 2540 enabled on the NAP switches. 2542 The router that is the Layer 3 next hop for the subscriber (BRAS in 2543 the PTA model or the Edge router in the LAA and Point-to-Point model) 2544 has to be enabled to support MLDv1 and MLDv2 in order to process the 2545 requests coming from subscribers without customer premise routers. 2547 It has to be enabled for PIM-SSM in order to receive joins/leaves 2548 from customer routers and send joins/leaves to the next hop towards 2549 the multicast source (Edge router or the NSP core). 2551 MLD authentication, authorization and accounting is usually 2552 configured on the edge router in order to enable the ISP to do 2553 control the subscriber access of the service and do billing for the 2554 content provided. Alternative mechanisms that would support these 2555 functions should be investigated further. 2557 Please refer to section 7.3 for more IPv6 multicast details. 2559 8.4 IPv6 QoS 2561 The QoS configuration is particularly relevant on the router that 2562 represents the Layer 3 next hop for the subscriber (BRAS in the PTA 2563 model or the Edge router in the LAA and Point-to-Point model) in 2564 order to manage resources shared amongst multiple subscribers 2565 possibly with various service level agreements. 2567 On the BRAS or the Edge Router the subscriber facing interfaces have 2568 to be configured to police the inbound customer traffic and shape the 2569 traffic outbound to the customer based on the SLAs. Traffic 2570 classification and marking should also be done on the router closest 2571 (at Layer 3) to the subscriber in order to support the various types 2572 of customer traffic: data, voice, video and to optimally use the 2573 network resources. This infrastructure offers a very good 2574 opportunity to leverage the QoS capabilities of Layer two devices. 2575 DiffServ based QoS used for IPv4 should be expanded to IPv6. 2577 Each provider (NAP, NSP) could implement their own QoS policies and 2578 services so reclassification and marking might be performed at the 2579 boundary between the NAP and the NSP in order to make sure the 2580 traffic is properly handled by the ISP. The same IPv4 QoS concepts 2581 and methodologies should be applied for the IPv6 as well. 2583 It is important to note that when traffic is encrypted end-to-end, 2584 the traversed network devices will not have access to many of the 2585 packet fields used for classification purposes. In these cases 2586 routers will most likely place the packets in the default classes. 2587 The QoS design should take into consideration this scenario and try 2588 to use mainly IP header fields for classification purposes. 2590 8.5 IPv6 Security Considerations 2592 There are limited changes that have to be done for CPEs in order to 2593 enhance security. The Privacy extensions [13] for auto-configuration 2594 should be used by the hosts with the same considerations for host 2595 traceability as discussed in section 7.5. IPv6 firewall functions 2596 should be enabled on the hosts or customer premise router if present. 2598 The ISP provides security against attacks that come form its own 2599 subscribers but it could also implement security services that 2600 protect its subscribers from attacks sourced from the outside of its 2601 network. Such services do not apply at the access level of the 2602 network discussed here. 2604 If any layer two filters for Ethertypes are in place, the NAP must 2605 permit the IPv6 Ethertype (0X86DD). 2607 The device that is the Layer 3 next hop for the subscribers (BRAS 2608 Edge router) should protect the network and the other subscribers 2609 against attacks by one of the provider customers. For this reason 2610 uRPF and ACLs should be used on all interfaces facing subscribers. 2611 Filtering should be implemented with regard for the operational 2612 requirements of IPv6 [36]. 2614 Authentication and authorization should be used wherever possible. 2616 The BRAS and the Edge Router should protect their processing 2617 resources against floods of valid customer control traffic such as: 2618 Router and Neighbor Solicitations, MLD Requests. Rate limiting 2619 should be implemented on all subscriber facing interfaces. The 2620 emphasis should be placed on multicast type traffic as it is most 2621 often used by the IPv6 control plane. 2623 All other security features used with the IPv4 service should be 2624 similarly applied to IPv6 as well. 2626 8.6 IPv6 Network Management 2628 The necessary instrumentation (such as MIBs, NetFlow Records etc) 2629 should be available for IPv6. 2631 Usually, NSPs manage the edge routers by SNMP. The SNMP transport 2632 can be done over IPv4 if all managed devices have connectivity over 2633 both IPv4 and IPv6. This would imply the smallest changes to the 2634 existent network management practices and processes. Transport over 2635 IPv6 could also be implemented and it might become necessary if IPv6 2636 only islands are present in the network. The management stations are 2637 located on the core network. Network Management Applications should 2638 handle IPv6 in a similar fashion to IPv4 however they should also 2639 support features specific to IPv6 such as Neighbor monitoring. 2641 In some cases service providers manage equipment located on customers 2642 LANs. 2644 9. Wireless LAN 2646 This section provides detailed description of IPv6 deployment and 2647 integration methods in currently deployed wireless LAN (WLAN) 2648 infrastructure. 2650 9.1 WLAN Deployment Scenarios 2652 WLAN enables subscribers to connect to the Internet from various 2653 locations without the restriction of staying indoors. WLAN is 2654 standardized by IEEE 802.11a/b/g. Consideration should be also given 2655 to IEEE 802.16 WiMAX for similar deployment approaches. IEEE 802.11 2656 offers maximum transmission speed from 1 or 2 Mbps, IEEE 802.11b 2657 offers 11 Mbps and IEEE 802.11a/g offer up to 54 Mbps. 2659 Figure 9.1 describes the current WLAN architecture. 2661 Customer | Access Provider | Service Provider 2662 Premise | | 2664 +------+ +--+ +--------------+ +----------+ +------+ 2665 |WLAN | ---- | | |Access Router/| |Underlying| |Edge | 2666 |Host/ |-(WLAN)--|AP|-|Layer 2 Switch|-|Technology|-|Router|=>SP 2667 |Router| ---- | | | | | | | |Network 2668 +------+ +--+ +--------------+ +----------+ +------+ 2669 | 2670 +------+ 2671 |AAA | 2672 |Server| 2673 +------+ 2674 Figure 9.1 2676 The host should have a wireless network interface card (NIC) in order 2677 to connect to a WLAN network. WLAN is a flat broadcast network and 2678 works in a similar fashion as Ethernet. When hosts initiate a 2679 connection, it is authenticated by the AAA server located at the SP 2680 network. All the authentication parameters (username, password and 2681 etc.) are forwarded by the Access Point (AP) to the AAA server. The 2682 AAA server authenticates the host, once successfully authenticated 2683 the host can send data packets. The AP is located near the host and 2684 acts as a bridge. The AP forwards all the packets coming to/from 2685 host to the Edge Router. The underlying connection between the AP 2686 and Edge Router could be based on any access layer technology such as 2687 HFC/Cable, FTTH, xDSL or etc. 2689 WLANs are based in limited areas known as WiFi Hot Spots. While 2690 users are present in the area covered by the WLAN range, they can be 2691 connected to the Internet given they have a wireless NIC and required 2692 configuration settings in their devices (notebook PCs, PDA or etc.). 2693 Once the user initiates the connection the IP address is assigned by 2694 the SP using DHCPv4. In most of the cases SP assigns limited number 2695 of public IP addresses to the its customer. When the user 2696 disconnects the connection and moves to a new WiFi hot spot, the 2697 above mentioned process of authentication, address assignment and 2698 accessing the Internet is repeated. 2700 There are IPv4 deployments where customers can use WLAN routers to 2701 connect over wireless to their service provider. These deployment 2702 types do not fit in the typical Hot Spot concept but they rather 2703 serve fixed customers. For this reason this section discusses the 2704 WLAN router options as well. In this case, the ISP provides a public 2705 IP address and the WLAN Router assigns private addresses [1] to all 2706 WLAN users. The WLAN Router provides NAT functionality while WLAN 2707 users access the Internet. 2709 While deploying IPv6 in the above mentioned WLAN architecture, there 2710 are three possible scenarios as discussed below. 2712 A. Layer 2 NAP with Layer 3 termination at NSP Edge Router 2714 B. Layer 3 aware NAP with Layer 3 termination at Access Router 2716 C. PPP Based Model 2718 9.1.1 Layer 2 NAP with Layer 3 termination at NSP Edge Router 2720 When a Layer 2 switch is present between AP and Edge Router, the AP 2721 and Layer 2 switch continues to work as a bridge, forwarding IPv4 and 2722 IPv6 packets from WLAN Host/Router to Edge Router and vice versa. 2724 When initiating the connection, the WLAN host is authenticated by the 2725 AAA server located at the SP network. All the parameters related to 2726 authentication (username, password and etc.) are forwarded by the AP 2727 to the AAA server. The AAA server authenticates the WLAN Hosts and 2728 once authenticated and associated successfully with WLAN AP, IPv6 2729 address will be acquired by the WLAN Host. Note the initiation and 2730 authentication process is same as used in IPv4. 2732 Figure 9.1.1 describes the WLAN architecture when Layer 2 Switch is 2733 located between AP and Edge Router. 2735 Customer | Access Provider | Service Provider 2736 Premise | | 2738 +------+ +--+ +--------------+ +----------+ +------+ 2739 |WLAN | ---- | | | | |Underlying| |Edge | 2740 |Host/ |-(WLAN)--|AP|-|Layer 2 Switch|-|Technology|-|Router|=>SP 2741 |Router| ---- | | | | | | | |Network 2742 +------+ +--+ +--------------+ +----------+ +------+ 2743 | 2744 +------+ 2745 |AAA | 2746 |Server| 2747 +------+ 2748 Figure 9.1.1 2750 9.1.1.1 IPv6 Related Infrastructure Changes 2752 IPv6 will be deployed in this scenario by upgrading the following 2753 devices to dual-stack: WLAN Host, WLAN Router (if present) and Edge 2754 Router. 2756 9.1.1.2 Addressing 2758 When customer WLAN Router is not present, the WLAN Host has two 2759 possible options to get an IPv6 address via the Edge Router. 2761 A. The WLAN host can get the IPv6 address from Edge router using 2762 stateless auto-configuration [11]. All hosts on the WLAN belong to 2763 the same /64 subnet that is statically configured on the Edge Router. 2764 The IPv6 WLAN Host may use stateless DHCPv6 for obtaining other 2765 information of interest such as DNS and etc. 2767 B. IPv6 WLAN host can use DHCPv6 [10] to get a IPv6 address from the 2768 DHCPv6 server. In this case the DHCPv6 server would be located in 2769 the SP core network and Edge Router would simply act as a DHCP Relay 2770 Agent. This option is similar to what we do today in case of DHCPv4. 2771 It is important to note that host implementation of stateful auto- 2772 configuration is rather limited at this time and this should be 2773 considered if choosing this address assignment option. 2775 When a customer WLAN Router is present, the WLAN Host has two 2776 possible options as well for acquiring IPv6 address. 2778 A. The WLAN Router may be assigned a prefix between /48 and /64 [7] 2779 depending on the SP policy and customer requirements. If the WLAN 2780 Router has multiple networks connected to its interfaces, the network 2781 administrator will have to configure the /64 prefixes to the WLAN 2782 Router interfaces connecting the WLAN Hosts on the customer site. 2783 The WLAN Hosts connected to these interfaces can automatically 2784 configure themselves using stateless auto-configuration with /64 2785 prefix. 2787 B. The WLAN Router can use its link-local address to communicate with 2788 the ER. It can also dynamically acquire through stateless auto- 2789 configuration the address for the link between itself and the ER. 2790 This step is followed by a request via DHCP-PD for a prefix shorter 2791 than /64 that in turn is divided in /64s and assigned to its 2792 interfaces connecting the hosts on the customer site. 2794 In this option, the WLAN Router would act as a requesting router and 2795 Edge Router would act as delegating router. Once prefix is received 2796 by the WLAN Router, it assigns /64 prefixes to each of its interfaces 2797 connecting the WLAN Hosts on the customer site. The WLAN Hosts 2798 connected to these interfaces can automatically configure themselves 2799 using stateless auto-configuration with /64 prefix. Currently the 2800 DHCP-PD functionality cannot be implemented if the DHCP-PD server is 2801 not the ER. If the DHCP-PD messages are relayed, the Edge Router 2802 does not have a mechanism to learn the assigned prefixes and thus 2803 install the proper routes to make that prefix reachable. Work is 2804 being done to address this issue, one idea being to provide the Edge 2805 Router with a snooping mechanism. The uplink to the ISP network is 2806 configured with a /64 prefix as well. 2808 Usually it is easier for the SPs to stay with the DHCP PD and 2809 stateless auto-configuration model and point the clients to a central 2810 server for DNS/domain information, proxy configurations and etc. 2811 Using this model the SP could change prefixes on the fly and the WLAN 2812 Router would simply pull the newest prefix based on the valid/ 2813 preferred lifetime. 2815 The prefixes used for subscriber links and the ones delegated via 2816 DHCP-PD should be planned in a manner that allows maximum 2817 summarization as possible at the Edge Router. 2819 Other information of interest to the host, such as DNS, is provided 2820 through stateful [10] and stateless [9] DHCPv6. 2822 9.1.1.3 Routing 2824 The WLAN Host/Router are configured with a default route that points 2825 to the Edge router. No routing protocols are needed on these devices 2826 which generally have limited resources. 2828 The Edge Router runs the IGP used in the SP network such as OSPFv3 or 2829 IS-IS for IPv6. The connected prefixes have to be redistributed. 2831 Prefix summarization should be done at the Edge Router. When DHCP-PD 2832 is used, the IGP has to redistribute the static routes installed 2833 during the process of prefix delegation. 2835 9.1.2 Layer 3 aware NAP with Layer 3 termination at Access Router 2837 When an Access Router is present between AP and Edge Router, the AP 2838 continues to work as a bridge, bridging IPv4 and IPv6 packets from 2839 WLAN Host/Router to Access Router and vice versa. The Access Router 2840 could be part of SP network or owned by a separate Access Provider. 2842 When WLAN Host initiates the connection, the AAA authentication and 2843 association process with WLAN AP will be similar as explained in 2844 section 9.1.1. 2846 Figure 9.1.2 describes the WLAN architecture when Access Router is 2847 located between AP and Edge Router. 2849 Customer | Access Provider | Service Provider 2850 Premise | | 2852 +------+ +--+ +--------------+ +----------+ +------+ 2853 |WLAN | ---- | | | | |Underlying| |Edge | 2854 |Host/ |-(WLAN)--|AP|-|Access Router |-|Technology|-|Router|=>SP 2855 |Router| ---- | | | | | | | |Network 2856 +------+ +--+ +--------------+ +----------+ +------+ 2857 | 2858 +------+ 2859 |AAA | 2860 |Server| 2861 +------+ 2862 Figure 9.1.2 2864 9.1.2.1 IPv6 Related Infrastructure Changes 2866 IPv6 is deployed in this scenario by upgrading the following devices 2867 to dual-stack: WLAN Host, WLAN Router (if present), Access Router and 2868 Edge Router. 2870 9.1.2.2 Addressing 2872 There are three possible options in this scenario for IPv6 address 2873 assignment: 2875 A. The Edge Router interface facing towards the Access Router is 2876 statically configured with /64 prefix. The Access Router receives/ 2877 configures an /64 prefix on its interface facing towards Edge Router 2878 through stateless auto-configuration. The network administrator will 2879 have to configure the /64 prefixes to the Access Router interface 2880 facing towards the customer premise. The WLAN Host/Router connected 2881 to this interface can automatically configure themselves using 2882 stateless auto-configuration with /64 prefix. 2884 B. This option uses DHCPv6 [10] for IPv6 prefix assignments to the 2885 WLAN Host/Router. There is no use of DHCP PD or stateless auto- 2886 configuration in this option. The DHCPv6 server can be located on 2887 the Access Router, on the Edge Router or somewhere in the SP network. 2888 In this case depending on where the DHCPv6 server is located, Access 2889 Router or the Edge Router would relay the DHCPv6 requests. 2891 C. It can use its link-local address to communicate with the ER. It 2892 can also dynamically acquire through stateless auto-configuration the 2893 address for the link between itself and the ER. This step is 2894 followed by a request via DHCP-PD for a prefix shorter than /64 that 2895 in turn is divided in /64s and assigned to its interfaces connecting 2896 the hosts on the customer site. 2898 In this option, the Access Router would act as a requesting router 2899 and Edge Router would act as delegating router. Once prefix is 2900 received by the Access Router, it assigns /64 prefixes to each of its 2901 interfaces connecting the WLAN Host/Router on customer site. The 2902 WLAN Host/Router connected to these interfaces can automatically 2903 configure themselves using stateless auto-configuration with /64 2904 prefix. Currently the DHCP-PD functionality cannot be implemented if 2905 the DHCP-PD server is not the Edge Router. If the DHCP-PD messages 2906 are relayed, the Edge Router does not have a mechanism to learn the 2907 assigned prefixes and thus install the proper routes to make that 2908 prefix reachable. Work is being done to address this issue, one idea 2909 being to provide the Edge Router with a snooping mechanism. The 2910 uplink to the ISP network is configured with a /64 prefix as well. 2912 It is easier for the SPs to stay with the DHCP PD and stateless auto- 2913 configuration model and point the clients to a central server for 2914 DNS/domain information, proxy configurations and others. Using this 2915 model the provider could change prefixes on the fly and the Access 2916 Router would simply pull the newest prefix based on the valid/ 2917 preferred lifetime. 2919 As mentioned before the prefixes used for subscriber links and the 2920 ones delegated via DHCP-PD should be planned in a manner that allows 2921 maximum summarization possible at the Edge Router. Other information 2922 of interest to the host, such as DNS, is provided through stateful 2923 [10] and stateless [9] DHCPv6. 2925 9.1.2.3 Routing 2927 The WLAN Host/Router are configured with a default route that points 2928 to the Access Router. No routing protocols are needed on these 2929 devices which generally have limited resources. 2931 If the Access Router is owned by an Access Provider, then the Access 2932 Router can have a default route, pointing towards the SP Edge Router. 2933 The Edge Router runs the IGP used in the SP network such as OSPFv3 or 2934 IS-IS for IPv6. The connected prefixes have to be redistributed. If 2935 DHCP-PD is used, with every delegated prefix a static route is 2936 installed by the Edge Router. For this reason the static routes must 2937 be redistributed. Prefix summarization should be done at the Edge 2938 Router. 2940 If the Access Router is owned by the SP, then Access Router will also 2941 run IPv6 IGP and will be part of SP IPv6 routing domain (OSPFv3 or 2942 IS-IS). The connected prefixes have to be redistributed. If DHCP-PD 2943 is used, with every delegated prefix a static route is installed by 2944 the Access Router. For this reason the static routes must be 2945 redistributed. Prefix summarization should be done at the Access 2946 Router. 2948 9.1.3 PPP Based Model 2950 PPP TERMINATED AGGREGATION (PTA) and L2TPv2 ACCESS AGGREGATION (LAA) 2951 models as discussed in sections 7.2.2 and 7.2.3 respectively can also 2952 be deployed in IPv6 WLAN environment. 2954 9.1.3.1 PTA Model in IPv6 WLAN Environment 2956 While deploying the PTA model in IPv6 WLAN environment the Access 2957 Router is Layer 3 aware and it has to be upgraded to support IPv6. 2958 Since the Access Router terminates the PPP sessions initiated by WLAN 2959 Host/Router, it has to support PPPoE with IPv6. 2961 Figure 9.1.3.1 describes the PTA Model in IPv6 WLAN environment. 2963 Customer | Access Provider | Service Provider 2964 Premise | | 2966 +------+ +--+ +--------------+ +----------+ +------+ 2967 |WLAN | ---- | | | | |Underlying| |Edge | 2968 |Host/ |-(WLAN)--|AP|-|Access Router |-|Technology|-|Router|=>SP 2969 |Router| ---- | | | | | | | |Network 2970 +------+ +--+ +--------------+ +----------+ +------+ 2971 | 2972 |---------------------------| +------+ 2973 PPP |AAA | 2974 |Server| 2975 +------+ 2976 Figure 9.1.3.1 2978 9.1.3.1.1 IPv6 Related Infrastructure Changes 2980 IPv6 is deployed in this scenario by upgrading the following devices 2981 to dual-stack: WLAN Host, WLAN Router (if present), Access Router and 2982 Edge Router. 2984 9.1.3.1.2 Addressing 2986 The addressing techniques described in section 7.2.2.2 applies to 2987 IPv6 WLAN PTA scenario as well. 2989 9.1.3.1.3 Routing 2991 The routing techniques described in section 7.2.2.3 applies to IPv6 2992 WLAN PTA scenario as well. 2994 9.1.3.2 LAA Model in IPv6 WLAN Environment 2996 While deploying the LAA model in IPv6 WLAN environment the Access 2997 Router is Layer 3 aware and it has to be upgraded to support IPv6. 2998 The PPP sessions initiated by WLAN Host/Router are forwarded over the 2999 L2TPv2 tunnel to the aggregation point in the SP network. The Access 3000 Router must have the capability to support L2TPv2 for IPv6. 3002 Figure 9.1.3.2 describes the LAA Model in IPv6 WLAN environment 3003 Customer | Access Provider | Service Provider 3004 Premise | | 3006 +------+ +--+ +--------------+ +----------+ +------+ 3007 |WLAN | ---- | | | | |Underlying| |Edge | 3008 |Host/ |-(WLAN)--|AP|-|Access Router |-|Technology|-|Router|=>SP 3009 |Router| ---- | | | | | | | |Network 3010 +------+ +--+ +--------------+ +----------+ +------+ 3011 | 3012 |-------------------------------------------------- | 3013 PPP | 3014 |--------------------- | 3015 L2TPv2 | 3016 +------+ 3017 |AAA | 3018 |Server| 3019 +------+ 3020 Figure 9.1.3.2 3022 9.1.3.2.1 IPv6 Related Infrastructure Changes 3024 IPv6 is deployed in this scenario by upgrading the following devices 3025 to dual-stack: WLAN Host, WLAN Router (if present), Access Router and 3026 Edge Router. 3028 9.1.3.2.2 Addressing 3030 The addressing techniques described in section 7.2.3.2 applies to 3031 IPv6 WLAN LAA scenario as well. 3033 9.1.3.2.3 Routing 3035 The routing techniques described in section 7.2.3.3 applies to IPv6 3036 WLAN LAA scenario as well. 3038 9.2 IPv6 Multicast 3040 The typical multicast services offered are video/audio streaming 3041 where the IPv6 WLAN Host joins a multicast group and receives the 3042 content. This type of service model is well supported through PIM- 3043 SSM which is enabled throughout the SP network. MLDv2 is required 3044 for PIM-SSM support. Vendors can choose to implement features that 3045 allow routers to map MLDv1 group joins to predefined sources. 3047 It is important to note that in the shared wireless environments 3048 multicast can have a significant bandwidth impact. For this reason 3049 the bandwidth allocated to multicast traffic should be limited and 3050 fixed based on the overall capacity of the wireless specification 3051 used 802.11a, 802.11b or 802.11g. 3053 The IPv6 WLAN Hosts can also join desired multicast groups as long as 3054 they are enabled to support MLDv1 or MLDv2. If a WLAN/Access Routers 3055 are used then they have to be enabled to support MLDv1 and MLDv2 in 3056 order to process the requests of the IPv6 WLAN Hosts. The WLAN/ 3057 Access Router should also needs to be enabled to support PIM-SSM in 3058 order to send PIM joins up to the Edge Router. When enabling this 3059 functionality on a WLAN/Access Router, its limited resources should 3060 be taken into consideration. Another option would be for the WLAN/ 3061 Access Router to support MLD proxy routing. 3063 The Edge Router has to be enabled to support MLDv1 and MLDv2 in order 3064 to process the requests coming from IPv6 WLAN Host or WLAN/Access 3065 Router (if present). The Edge Router has also needs to be enabled 3066 for PIM-SSM in order to receive joins from IPv6 WLAN Hosts or WLAN/ 3067 Access Router (if present) and send joins towards the SP core. 3069 MLD authentication, authorization and accounting is usually 3070 configured on the Edge Router in order to enable the SP to do billing 3071 for the content services provided. Further investigation should be 3072 made in finding alternative mechanisms that would support these 3073 functions. 3075 Concerns have been raised in the past related to running IPv6 3076 multicast over WLAN links. Potentially these are same kind of issues 3077 when running any Layer 3 protocol over a WLAN link that has a high 3078 loss-to-signal ratio, where certain frames that are multicast based 3079 are dropped when settings are not adjusted properly. For instance 3080 this behavior is similar to IGMP host membership report, when done on 3081 a WLAN link with high loss-to-signal ratio and high interference. 3083 This problem is inherited to WLAN that can impact both IPv4 and IPv6 3084 multicast packets and not specific to IPv6 multicast. 3086 While deploying WLAN (IPv4 or IPv6), one should adjust their 3087 broadcast/multicast settings if they are in danger of dropping 3088 application dependent frames. These problems are usually caused when 3089 AP are placed too far apart (not following the distance limitations), 3090 high interference and etc. These issues may impact a real multicast 3091 application such as streaming video or basic operation of IPv6 if the 3092 frames were dropped. Basic IPv6 communications uses functions such 3093 as Duplicate Address Detection (DAD), Router and Neighbor 3094 Solicitations (RS, NS), Router and Neighbor Advertisement (RA, NA) 3095 and etc. which could be impacted by the above mentioned issues as 3096 these frames are Layer 2 Ethernet multicast frames. 3098 Please refer to section 7.3 for more IPv6 multicast details. 3100 9.3 IPv6 QoS 3102 Today, QoS is done outside of the WiFi domain but it is nevertheless 3103 important to the overall deployment. 3105 The QoS configuration is particularly relevant on the Edge Router in 3106 order to manage resources shared amongst multiple subscribers 3107 possibly with various service level agreements (SLA). Although, the 3108 WLAN Host/Router and Access Router could also be configured for QoS. 3109 This includes support for appropriate classification criteria which 3110 would need to be implemented for IPv6 unicast and multicast traffic. 3112 On the Edge Router the subscriber facing interfaces have to be 3113 configured to police the inbound customer traffic and shape the 3114 traffic outbound to the customer, based on the SLA. Traffic 3115 classification and marking should also be done on the Edge router in 3116 order to support the various types of customer traffic: data, voice, 3117 video. The same IPv4 QoS concepts and methodologies should be 3118 applied for the IPv6 as well. 3120 It is important to note that when traffic is encrypted end-to-end, 3121 the traversed network devices will not have access to many of the 3122 packet fields used for classification purposes. In these cases 3123 routers will most likely place the packets in the default classes. 3124 The QoS design should take into consideration this scenario and try 3125 to use mainly IP header fields for classification purposes. 3127 9.4 IPv6 Security Considerations 3129 There are limited changes that have to be done for WLAN Host/Router 3130 in order to enhance security. The Privacy extensions [13] for auto- 3131 configuration should be used by the hosts with the same consideration 3132 for host traceability as described in section 7.5. IPv6 firewall 3133 functions should be enabled on the WLAN Host/Router if present. 3135 The ISP provides security against attacks that come form its own 3136 subscribers but it could also implement security services that 3137 protect its subscribers from attacks sourced from the outside of its 3138 network. Such services do not apply at the access level of the 3139 network discussed here. 3141 If the host authentication at hot spots is done using web based 3142 authentication system then the level of security would depend on the 3143 particular implementation. User credential should never be sent as 3144 clear text via HTTP. Secure HTTP (HTTPS) should be used between the 3145 web browser and authentication server. The authentication server 3146 could use RADIUS and LDAP services at the back end. 3148 Authentication is an important aspect of securing WLAN networks prior 3149 to implementing Layer 3 security policies. This would help for 3150 example avoid threats to the ND or stateless auto-configuration 3151 processes. 802.1x provides the means to secure the network access 3152 however, the many types of EAP (PEAP, EAP-TLS, EAP-TTLS, EAP-FAST, 3153 LEAP) and the capabilities of the hosts to support some of the 3154 features might make it difficult to implement a comprehensive and 3155 consistent policy. 3157 If any layer two filters for Ethertypes are in place, the NAP must 3158 permit the IPv6 Ethertype (0X86DD). 3160 The device that is the Layer 3 next hop for the subscribers (Access 3161 or Edge Router) should protect the network and the other subscribers 3162 against attacks by one of the provider customers. For this reason 3163 uRPF and ACLs should be used on all interfaces facing subscribers. 3164 Filtering should be implemented with regard for the operational 3165 requirements of IPv6 [Security considerations for IPv6]. 3166 Authentication and authorization should be used wherever possible. 3168 The Access and the Edge Router should protect their processing 3169 resources against floods of valid customer control traffic such as: 3170 RS, NS, MLD Requests. Rate limiting should be implemented on all 3171 subscriber facing interfaces. The emphasis should be placed on 3172 multicast type traffic as it is most often used by the IPv6 control 3173 plane. 3175 9.5 IPv6 Network Management 3177 The necessary instrumentation (such as MIBs, NetFlow Records, etc) 3178 should be available for IPv6. 3180 Usually, NSPs manage the edge routers by SNMP. The SNMP transport 3181 can be done over IPv4 if all managed devices have connectivity over 3182 both IPv4 and IPv6. This would imply the smallest changes to the 3183 existent network management practices and processes. Transport over 3184 IPv6 could also be implemented and it might become necessary if IPv6 3185 only islands are present in the network. The management stations are 3186 located on the core network. Network Management Applications should 3187 handle IPv6 in a similar fashion to IPv4 however they should also 3188 support features specific to IPv6 (such as Neighbor monitoring). 3190 In some cases service providers manage equipment located on customers 3191 LANs. 3193 10. Broadband Power Line Communications (PLC) 3195 This section describes the IPv6 deployment in Power Line 3196 Communications (PLC) Access Networks. There may be other choices, 3197 but it seems that this is the best model to follow. Lessons learnt 3198 from Cable, Ethernet and even WLAN access networks may be applicable 3199 also. 3201 Power Line Communications are also often called Broadband Power Line 3202 (BPL) and some times even Power Line Telecommunications (PLT). 3204 PLC/BPL can be used for providing, with today's technology, up to 3205 200Mbps (total, upstream+downstream) by means of the power grid. The 3206 coverage is often the last half mile (typical distance from the 3207 Medium-to-Low Voltage transformer to the customer premise meter), and 3208 of course, as an in-home network (which is out of the scope of this 3209 document). 3211 The bandwidth in a given PLC/BPL segment is shared among all the 3212 customers connected to that segment (often the customers connected to 3213 the same medium-to-low voltage transformer). The number of customers 3214 can vary depending on different factors, such as distances and even 3215 countries (from a few customers, just 5-6, up to 100-150). 3217 PLC/BPL could also be used in the Medium Voltage network (often 3218 configured as Metropolitan Area Networks), but this is also out of 3219 the scope of this document, as it will be part of the core network, 3220 not the access one. 3222 10.1 PLC/BPL Access Network Elements 3224 This section describes the different elements commonly used in PLC/ 3225 BPL access networks. 3227 Head End (HE): Router that connects the PLC/BPL access network (the 3228 power grid), located at the medium-to-low voltage transformer, to the 3229 core network. The HE PLC/BPL interface appears to each customer as a 3230 single virtual interface, all of them sharing the same physical 3231 media. 3233 Repeater (RPT): A device which may be required in some circumstances 3234 to improve the signal on the PLC/BPL. This may be the case if there 3235 are many customers in the same segment or building. It is often a 3236 bridge, but it could be also a router if for example there is a lot 3237 of peer-to-peer traffic in a building and due to the master-slave 3238 nature of the PLC/BPL technology, is required to improve the 3239 performance within that segment. For simplicity, in this document, 3240 it will be considered that the RPT is always a transparent layer 2 3241 bridge, so it may be present or not (from the layer 3 point of view). 3243 Customer Premise Equipment (CPE): Modem (internal to the host), 3244 modem/bridge (BCPE), router (RCPE) or any combination among those 3245 (i.e. modem+bridge/router), located at the customer premise. 3247 Edge Router (ER) 3249 Figure 10.1 depicts all the network elements indicated above 3251 Customer Premise | Network Access Provider | Network Service Provider 3252 CP NAP NSP 3254 +-----+ +------+ +-----+ +------+ +--------+ 3255 |Hosts|--| RCPE |--| RPT |--------+ Head +---+ Edge | ISP 3256 +-----+ +------+ +-----+ | End | | Router +=>Network 3257 +--+---+ +--------+ 3258 +-----+ +------+ +-----+ | 3259 |Hosts|--| BCPE |--| RPT |-----------+ 3260 +-----+ +------+ +-----+ 3261 Figure 10.1 3263 The logical topology and design of PLC/BPL is very similar to 3264 Ethernet Broadband Networks as discussed in Section 8. IP 3265 connectivity is typically provided in a Point-to-Point model as 3266 described in section 8.2.1 3268 10.2 Deploying IPv6 in IPv4 PLC/BPL 3270 The most simplistic and efficient model, considering the nature of 3271 the PLC/BPL networks, is to see the network as a point-to-point one 3272 to each customer. Even if several customers share the same physical 3273 media, the traffic is not visible among them because each one uses 3274 different channels, which are in addition encrypted by means of 3DES. 3276 In order to maintain the deployment concepts and business models 3277 proven and used with existing revenue generating IPv4 services, the 3278 IPv6 deployment will match the IPv4 one. Under certain circumstances 3279 where new service types or service needs justify it, IPv4 and IPv6 3280 network architectures could be different. Both approaches are very 3281 similar to those already described for the Ethernet case. 3283 10.2.1 IPv6 Related Infrastructure Changes 3285 In this scenario only the RPT is layer 3 unaware, but the other 3286 devices have to be upgraded to dual stack Hosts, RCPE, Head End, and 3287 Edge Router. 3289 10.2.2 Addressing 3291 The Hosts or the RCPEs have the HE as their Layer 3 next hop. 3293 If there is no RCPE, but instead a BCPE all the hosts on the 3294 subscriber site belong to the same /64 subnet that is statically 3295 configured on the HE. The hosts can use stateless auto-configuration 3296 or stateful DHCPv6 based configuration to acquire an address via the 3297 HE. 3299 If a RCPE is present: 3301 A. It is statically configured with an address on the /64 subnet 3302 between itself and the HE, and with /64 prefixes on the interfaces 3303 connecting the hosts on the customer site. This is not a desired 3304 provisioning method being expensive and difficult to manage. 3306 B. It can use its link-local address to communicate with the HE. It 3307 can also dynamically acquire through stateless auto-configuration the 3308 address for the link between itself and the HE. This step is 3309 followed by a request via DHCP-PD for a prefix shorter than /64 3310 (typically /48 [7]) that in turn is divided in /64s and assigned to 3311 its interfaces connecting the hosts on the customer site. This 3312 should be the preferred provisioning method, being cheaper and easier 3313 to manage. 3315 The Edge Router needs to have a prefix considering that each customer 3316 in general will receive a /48 prefix, and that each HE will 3317 accommodate customers. Consequently each HE will require n x /48 3318 prefixes. 3320 It could be possible to use a kind of Hierarchical Prefix Delegation 3321 to automatically provision the required prefixes and fully auto- 3322 configure the HEs, and consequently reduce the network setup, 3323 operation and maintenance cost. 3325 The prefixes used for subscriber links and the ones delegated via 3326 DHCP-PD should be planned in a manner that allows as much 3327 summarization as possible at the Edge Router. 3329 Other information of interest to the host, such as DNS, is provided 3330 through stateful [10] and stateless [9] DHCPv6. 3332 10.2.3 Routing 3334 If no routers are used on the customer premise, the HE can simply be 3335 configured with a default route that points to the Edge Router. If a 3336 router is used on the customer premise (RCPE) then the HE could also 3337 run an IGP to the ER such as OSPFv3, IS-IS or even RIPng. The 3338 connected prefixes should be redistributed. If DHCP-PD is used, with 3339 every delegated prefix a static route is installed by the HE. For 3340 this reason the static routes must also be redistributed. Prefix 3341 summarization should be done at the HE. 3343 The RCPE requires only a default route pointing to the HE. No 3344 routing protocols are needed on these devices which generally have 3345 limited resources. 3347 The Edge Router runs the IPv6 IGP used in the NSP: OSPFv3 or IS-IS. 3348 The connected prefixes have to be redistributed as well as any RP 3349 other than the ones used on the ER that might be used between the HE 3350 and the ER. 3352 10.3 IPv6 Multicast 3354 The considerations regarding IPv6 Multicast for Ethernet are also 3355 applicable here, in general, but assuming the nature of PLC/BPL being 3356 a shared media. If a lot of Multicast is expected, it may be worth 3357 considering using RPT which are layer 3 aware. In that case, one 3358 extra layer of Hierarchical DHCP-PD could be considered, in order to 3359 facilitate the deployment, operation and maintenance of the network. 3361 10.4 IPv6 QoS 3363 The considerations introduced for QoS in Ethernet are also applicable 3364 here. PLC/BPL networks support QoS, which basically are no different 3365 whether the transport is IPv4 or IPv6. It is necessary to understand 3366 that the specific network characteristics, such as the variability 3367 that may be introduced by electrical noise, towards which the PLC/BPL 3368 network will automatically self-adapt. 3370 10.5 IPv6 Security Considerations 3372 There are no differences in terms of security considerations if 3373 compared with the Ethernet case. 3375 10.6 IPv6 Network Management 3377 Conceptually network management in PLC Networks should be similar to 3378 Broadband Ethernet Networks as described in section 8.6. Although 3379 there could be a need to develop some PLC specific MIBs. 3381 11. Gap Analysis 3383 Several aspects of deploying IPv6 over SP Broadband networks were 3384 highlighted in this document, aspects that require additional work in 3385 order to facilitate native deployments as summarized below: 3387 A. As mentioned in section 6, changes will need to be made to the 3388 DOCSIS specification in order for SPs to deploy native IPv6 over 3389 cable networks. The CM and CMTS will both need to support IPv6 3390 natively in order to forward IPv6 unicast and multicast traffic. 3391 This is required for IPv6 Neighbor Discovery to work over DOCSIS 3392 cable networks. Additional classifiers need to be added to the 3393 DOCSIS specification in order to classify IPv6 traffic at the CM and 3394 CMTS in order to provide QoS. These issues are addressed in a recent 3395 proposal made to Cable Labs for DOCSIS 3.0 [31]. 3397 B. Currently the DHCP-PD functionality cannot be implemented if the 3398 DHCP-PD server is not the Edge Router (CPE's layer 3 next hop). If 3399 the DHCP-PD messages are relayed, the Edge Router does not have a 3400 mechanism to learn the assigned prefixes and thus install the proper 3401 routes to make that prefix reachable. Work needs to be done to 3402 address this issue, one idea being to provide the Edge Router with a 3403 snooping mechanism. The uplink to the ISP network is configured with 3404 a /64 prefix as well. 3406 C. Section 7 stated that current RBE based IPv4 deployment might not 3407 be the best approach for IPv6 where the addressing space available 3408 gives the SP the opportunity to separate the users on different 3409 subnets. The differences between IPv4 RBE and IPv6 RBE were 3410 highlighted in section 7. If however, support and reason is found 3411 for a deployment similar to IPv4 RBE, then the environment becomes 3412 NBMA and the new feature should observe RFC2491 recommendations. 3414 D. Section 7 discussed the constraints imposed on a LAA based IPv6 3415 deployment by the fact that it is expected that the subscribers keep 3416 their assigned prefix regardless of LNS. A deployment approach was 3417 proposed that would maintain the addressing schemes contiguous and 3418 offers prefix summarization opportunities. The topic could be 3419 further investigated for other solutions or improvements. 3421 E. Sections 7 and 8 pointed out the limitations (previously 3422 documented in [32]) in deploying inter-domain ASM however, SSM based 3423 services seem more likely at this time. For such SSM based services 3424 of content delivery (video or Audio), mechanisms are needed to 3425 facilitate the billing and management of listeners. The currently 3426 available feature of MLD AAA is suggested however, other methods or 3427 mechanisms might be developed and proposed. 3429 F. In relation to section 9, concerns have been raised related to 3430 running IPv6 multicast over WLAN links. Potentially these are same 3431 kind of issues when running any Layer 3 protocol over a WLAN link 3432 that has a high loss-to-signal ratio, certain frames that are 3433 multicast based are dropped when settings are not adjusted properly. 3434 For instance this behavior is similar to IGMP host membership report, 3435 when done on a WLAN link with high loss-to-signal ratio and high 3436 interference. This problem is inherited to WLAN that can impact both 3437 IPv4 and IPv6 multicast packets and not specific to IPv6 multicast. 3439 G. The Privacy Extensions were mentioned as a popular means to 3440 provide some form of host security. ISPs can track relatively easily 3441 the prefixes assigned to subscribers. If however the ISPs are 3442 required by regulations to track their users at host address level, 3443 the Privacy Extensions [13] can be implemented only in parallel with 3444 network management tools that could provide traceability of the 3445 hosts. Mechanisms should be defined to implement this aspect of user 3446 management. 3448 H. Tunnels are an effective way to avoid deployment dependencies on 3449 the IPv6 support on platforms that are out of the SP control (GWRs or 3450 CPEs) or over technologies that did not standardize the IPv6 support 3451 yet (cable). They can be used in the following ways: 3453 i. Tunnels directly to the CPE or GWR with public or private IPv4 3454 addresses. 3456 ii. Tunnels directly to hosts with public or private IPv4 addresses. 3457 Recommendations on the exact tunneling mechanisms that can/should be 3458 used for last mile access need to be investigated further and should 3459 be covered in a future IETF draft. 3461 I. Through its larger address space, IPv6 allows SPs to assign fixed, 3462 globally routable prefixes to the links connecting each subscriber. 3464 This approach changes the provisioning methodologies that were used 3465 for IPv4. Static configuration of the IPv6 addresses for all these 3466 links on the Edge Routers or Access Routers might not be a scalable 3467 option. New provisioning mechanisms or features might need to be 3468 developed in order to deal with this issue, such as automatic mapping 3469 of VLAN IDs/PVCs (or other customer-specific information) to IPv6 3470 prefixes. 3472 J. New deployment models are emerging for the Layer 2 portion of the 3473 NAP where individual VLANs are not dedicated to each subscriber. 3474 This approach allows Layer 2 switches to aggregate more then 4096 3475 users. MAC Forced Forwarding [MFF] is an example of such an 3476 implementation where a broadcast domain is turned into a NBMA like 3477 environment by forwarding the frames based on both Source and 3478 Destination MAC addresses. Since these models are being adopted by 3479 the field, the implications of deploying IPv6 in such environments 3480 need to be further investigated. 3482 K. The deployment of IPv6 in continuously evolving access service 3483 models raises some issues that may need further investigation. 3484 Examples of such topics are [37]: 3486 i. Network Service Selection & Authentication(NSSA) mechanisms 3487 working in association with stateless auto-configuration. As an 3488 example, NSSA relevant information such as ISP preference, passwords 3489 or profile ID can be sent by hosts with the RS. 3491 ii. Adding additional information in Router Advertisements to help 3492 access nodes with prefix selection in multi-ISP/multi-homed 3493 environment. 3495 The outcome of solutions to some of these topics ranges from making a 3496 media access capable of supporting native IPv6 (cable) to improving 3497 operational aspects of native IPv6 deployments. 3499 12. IANA Considerations 3501 This document requests no action by IANA. 3503 13. Security Considerations 3505 Please refer to the individual "IPv6 Security Considerations" 3506 technology sections for details. 3508 14. Acknowledgements 3510 We would like to thank Brian Carpenter, Patrick Grossetete, Toerless 3511 Eckert, Madhu Sudan, Shannon McFarland and Benoit Lourdelet, Fred 3512 Baker for their valuable comments. The authors would like to 3513 acknowledge the structure and information guidance provided by the 3514 work of Mickels et al on Transition Scenarios for ISP Networks. 3516 15. References 3518 15.1 Normative References 3520 [1] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and E. 3521 Lear, "Address Allocation for Private Internets", BCP 5, 3522 RFC 1918, February 1996. 3524 [2] Durand, A., Fasano, P., Guardini, I., and D. Lento, "IPv6 3525 Tunnel Broker", RFC 3053, January 2001. 3527 [3] Carpenter, B. and K. Moore, "Connection of IPv6 Domains via 3528 IPv4 Clouds", RFC 3056, February 2001. 3530 [4] Conta, A. and S. Deering, "Generic Packet Tunneling in IPv6 3531 Specification", RFC 2473, December 1998. 3533 [5] Carpenter, B. and C. Jung, "Transmission of IPv6 over IPv4 3534 Domains without Explicit Tunnels", RFC 2529, March 1999. 3536 [6] Huitema, C., Austein, R., Satapati, S., and R. van der Pol, 3537 "Evaluation of IPv6 Transition Mechanisms for Unmanaged 3538 Networks", RFC 3904, September 2004. 3540 [7] IAB and IESG, "IAB/IESG Recommendations on IPv6 Address 3541 Allocations to Sites", RFC 3177, September 2001. 3543 [8] Hinden, R. and S. Deering, "Internet Protocol Version 6 (IPv6) 3544 Addressing Architecture", RFC 3513, April 2003. 3546 [9] Droms, R., "Stateless Dynamic Host Configuration Protocol 3547 (DHCP) Service for IPv6", RFC 3736, April 2004. 3549 [10] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., and M. 3550 Carney, "Dynamic Host Configuration Protocol for IPv6 3551 (DHCPv6)", RFC 3315, July 2003. 3553 [11] Thomson, S. and T. Narten, "IPv6 Stateless Address 3554 Autoconfiguration", RFC 2462, December 1998. 3556 [12] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic Host 3557 Configuration Protocol (DHCP) version 6", RFC 3633, 3558 December 2003. 3560 [13] Narten, T. and R. Draves, "Privacy Extensions for Stateless 3561 Address Autoconfiguration in IPv6", RFC 3041, January 2001. 3563 [14] Mamakos, L., Lidl, K., Evarts, J., Carrel, D., Simone, D., and 3564 R. Wheeler, "A Method for Transmitting PPP Over Ethernet 3565 (PPPoE)", RFC 2516, February 1999. 3567 [15] Gross, G., Kaycee, M., Lin, A., Malis, A., and J. Stephens, 3568 "PPP Over AAL5", RFC 2364, July 1998. 3570 [16] Haskin, D. and E. Allen, "IP Version 6 over PPP", RFC 2472, 3571 December 1998. 3573 [17] Narten, T., Nordmark, E., and W. Simpson, "Neighbor Discovery 3574 for IP Version 6 (IPv6)", RFC 2461, December 1998. 3576 [18] Meyer, D. and P. Lothberg, "GLOP Addressing in 233/8", 3577 RFC 2770, February 2000. 3579 [19] St. Johns, M., "DOCSIS Cable Device MIB Cable Device Management 3580 Information Base for DOCSIS compliant Cable Modems and Cable 3581 Modem Termination Systems", RFC 2669, August 1999. 3583 [20] Droms, R., "DNS Configuration options for Dynamic Host 3584 Configuration Protocol for IPv6 (DHCPv6)", RFC 3646, 3585 December 2003. 3587 [21] Fenner, B. and D. Meyer, "Multicast Source Discovery Protocol 3588 (MSDP)", RFC 3618, October 2003. 3590 [22] Baker, F. and P. Savola, "Ingress Filtering for Multihomed 3591 Networks", BCP 84, RFC 3704, March 2004. 3593 [23] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in 3594 IPv6", RFC 3775, June 2004. 3596 [24] Lind, M., Ksinant, V., Park, S., Baudot, A., and P. Savola, 3597 "Scenarios and Analysis for Introducing IPv6 into ISP 3598 Networks", RFC 4029, March 2005. 3600 15.2 Informative References 3602 [25] Shirasaki, Y., Miyakawa, S., and A. Takenouchi, "A Model of 3603 IPv6/IPv4 Dual Stack Internet Access 3604 Service(draft-shirasaki-dualstack-service-04.txt)", April 2004. 3606 [26] De Clercq, J., Ooms, D., Prevost, S., and F. Le Faucheur, 3607 "Connecting IPv6 Islands across IPv4 Clouds with 3608 BGP(draft-ooms-v6ops-bgp-tunnel-04.txt)", October 2004. 3610 [27] Templin, F., Gleeson, T., Talwar, M., and D. Thaler, "Intra- 3611 Site Automatic Tunnel Addressing Protocol 3612 (ISATAP)(draft-ietf-ngtrans-isatap-12.txt)", January 2003. 3614 [28] Palet, J., Diaz, M., and P. Savola, "Analysis of IPv6 Tunnel 3615 End-point Discovery 3616 Mechanisms(draft-palet-v6ops-tun-auto-disc-03.txt)", 3617 January 2005. 3619 [29] Palet, J., Olvera, C., and D. Fernandez, "Forwarding Protocol 3620 41 in NAT Boxes(draft-palet-v6ops-proto41-nat-03.txt)", 3621 October 2003. 3623 [30] Nordmark, E. and R. Gilligan, "Basic Transition Mechanisms for 3624 IPv6 Hosts and Routers(draft-ietf-v6ops-mech-v2-06.txt)", 3625 September 2004. 3627 [31] Cisco, Systems., "DOCSIS 3.0 Proposal", April 2005. 3629 [32] Savola, P., "IPv6 Multicast Deployment 3630 Issues(draft-mboned-ipv6-multicast-issues.txt)", April 2004. 3632 [33] Cable, Labs., "Radio Frequency Interface Specification SP- 3633 RFIv2.0-I02-020617", June 2002. 3635 [34] Bhaskar, N., Gall, A., and S. Venaas, "Bootstrap Router (BSR) 3636 Mechanism for PIM(draft-ietf-pim-sm-bsr-04.txt)", January 2005. 3638 [35] Palet, J., Nielsent, K., Parent, F., Durand, A., 3639 Suryanarayanan, R., and P. Savola, "Goals for Tunneling 3640 Configuration(draft-palet-v6tc-goals-tunneling-00.txt)", 3641 August 2005. 3643 [36] Convery, S. and D. Miller, "IPv6 and IPv4 Threat Comparison and 3644 Best-Practice Evaluation", March 2004. 3646 [37] Wen, H., Zhu, X., Jiang, Y., and R. Yan, "The deployment of 3647 IPv6 stateless auto-configuration in access network", 3648 June 2005. 3650 Authors' Addresses 3652 Salman Asadullah 3653 Cisco Systems 3654 170 West Tasman Drive 3655 San Jose, CA 95134 3656 USA 3658 Phone: 408 526 8982 3659 Email: sasad@cisco.com 3660 Adeel Ahmed 3661 Cisco Systems 3662 2200 East President George Bush Turnpike 3663 Richardson, TX 75082 3664 USA 3666 Phone: 469 255 4122 3667 Email: adahmed@cisco.com 3669 Ciprian Popoviciu 3670 Cisco Systems 3671 7025-6 Kit Creek Road 3672 Research Triangle Park, NC 27709 3673 USA 3675 Phone: 919 392 3723 3676 Email: cpopovic@cisco.com 3678 Pekka Savola 3679 CSC - Scientific Computing Ltd. 3680 Espoo 3681 Finland 3683 Email: psavola@funet.fi 3685 Jordi Palet Martinez 3686 Consulintel 3687 San Jose Artesano, 1 3688 Alcobendas, Madrid E-28108 3689 Spain 3691 Phone: +34 91 151 81 99 3692 Email: jordi.palet@consulintel.es 3694 Intellectual Property Statement 3696 The IETF takes no position regarding the validity or scope of any 3697 Intellectual Property Rights or other rights that might be claimed to 3698 pertain to the implementation or use of the technology described in 3699 this document or the extent to which any license under such rights 3700 might or might not be available; nor does it represent that it has 3701 made any independent effort to identify any such rights. Information 3702 on the procedures with respect to rights in RFC documents can be 3703 found in BCP 78 and BCP 79. 3705 Copies of IPR disclosures made to the IETF Secretariat and any 3706 assurances of licenses to be made available, or the result of an 3707 attempt made to obtain a general license or permission for the use of 3708 such proprietary rights by implementers or users of this 3709 specification can be obtained from the IETF on-line IPR repository at 3710 http://www.ietf.org/ipr. 3712 The IETF invites any interested party to bring to its attention any 3713 copyrights, patents or patent applications, or other proprietary 3714 rights that may cover technology that may be required to implement 3715 this standard. Please address the information to the IETF at 3716 ietf-ipr@ietf.org. 3718 Disclaimer of Validity 3720 This document and the information contained herein are provided on an 3721 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 3722 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 3723 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 3724 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 3725 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 3726 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 3728 Copyright Statement 3730 Copyright (C) The Internet Society (2005). This document is subject 3731 to the rights, licenses and restrictions contained in BCP 78, and 3732 except as set forth therein, the authors retain all their rights. 3734 Acknowledgment 3736 Funding for the RFC Editor function is currently provided by the 3737 Internet Society.