idnits 2.17.1 draft-ietf-v6ops-bb-deployment-scenarios-02.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 18. -- Found old boilerplate from RFC 3978, Section 5.5 on line 3670. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 3647. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 3654. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 3660. ** 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 (May 19, 2005) is 6916 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 3452 == Unused Reference: '7' is defined on line 3495, but no explicit reference was found in the text == Unused Reference: '13' is defined on line 3515, but no explicit reference was found in the text == Unused Reference: '17' is defined on line 3529, but no explicit reference was found in the text == Unused Reference: '21' is defined on line 3542, but no explicit reference was found in the text ** Downref: Normative reference to an Informational RFC: RFC 3053 (ref. '2') ** Obsolete normative reference: RFC 2893 (ref. '5') (Obsoleted by RFC 4213) ** Downref: Normative reference to an Informational RFC: RFC 3904 (ref. '7') ** Obsolete normative reference: RFC 3177 (ref. '8') (Obsoleted by RFC 6177) ** Obsolete normative reference: RFC 3513 (ref. '9') (Obsoleted by RFC 4291) ** Obsolete normative reference: RFC 3736 (ref. '10') (Obsoleted by RFC 8415) ** Obsolete normative reference: RFC 3315 (ref. '11') (Obsoleted by RFC 8415) ** Obsolete normative reference: RFC 2462 (ref. '12') (Obsoleted by RFC 4862) ** Obsolete normative reference: RFC 3633 (ref. '13') (Obsoleted by RFC 8415) ** Obsolete normative reference: RFC 3041 (ref. '14') (Obsoleted by RFC 4941) ** Downref: Normative reference to an Informational RFC: RFC 2516 (ref. '15') ** Obsolete normative reference: RFC 2472 (ref. '17') (Obsoleted by RFC 5072, RFC 5172) ** Obsolete normative reference: RFC 2461 (ref. '18') (Obsoleted by RFC 4861) ** Obsolete normative reference: RFC 2770 (ref. '19') (Obsoleted by RFC 3180) ** Obsolete normative reference: RFC 2669 (ref. '20') (Obsoleted by RFC 4639) ** Downref: Normative reference to an Experimental RFC: RFC 3618 (ref. '22') ** Obsolete normative reference: RFC 3775 (ref. '24') (Obsoleted by RFC 6275) ** Downref: Normative reference to an Informational RFC: RFC 4029 (ref. '25') == 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 (-03) exists of draft-palet-v6ops-tun-auto-disc-01 == 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: 21 errors (**), 0 flaws (~~), 12 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: November 20, 2005 C. Popoviciu 5 Cisco Systems 6 J. Palet 7 Consulintel 8 May 19, 2005 10 ISP IPv6 Deployment Scenarios in Broadband Access Networks 11 13 Status of this Memo 15 By submitting this Internet-Draft, each author represents that any 16 applicable patent or other IPR claims of which he or she is aware 17 have been or will be disclosed, and any of which he or she becomes 18 aware will be disclosed, in accordance with Section 6 of BCP 79. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF), its areas, and its working groups. Note that 22 other groups may also distribute working documents as Internet- 23 Drafts. 25 Internet-Drafts are draft documents valid for a maximum of six months 26 and may be updated, replaced, or obsoleted by other documents at any 27 time. It is inappropriate to use Internet-Drafts as reference 28 material or to cite them other than as "work in progress." 30 The list of current Internet-Drafts can be accessed at 31 http://www.ietf.org/ietf/1id-abstracts.txt. 33 The list of Internet-Draft Shadow Directories can be accessed at 34 http://www.ietf.org/shadow.html. 36 This Internet-Draft will expire on November 20, 2005. 38 Copyright Notice 40 Copyright (C) The Internet Society (2005). 42 Abstract 44 This document provides detailed description of IPv6 deployment and 45 integration methods and scenarios in today's Service Provider (SP) 46 Broadband (BB) networks in coexistence with deployed IPv4 services. 47 Cable/HFC, BB Ethernet, xDSL and WLAN are the main BB technologies 48 that are currently deployed, and discussed in this document. The 49 emerging PLC/BPL access technology is also discussed for completion 50 purposes. In this document we will discuss main components of IPv6 51 BB networks and their differences from IPv4 BB networks and how IPv6 52 is deployed and integrated in each of these BB technologies using 53 tunneling mechanisms and native IPv6. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 58 2. IPv6 Based BB Services . . . . . . . . . . . . . . . . . . . 4 59 3. Scope of the Document . . . . . . . . . . . . . . . . . . . 5 60 4. Core/Backbone Network . . . . . . . . . . . . . . . . . . . 6 61 4.1 Layer 2 Access Provider Network . . . . . . . . . . . . . 7 62 4.2 Layer3 Access Provider Network . . . . . . . . . . . . . . 7 63 5. Tunneling Overview . . . . . . . . . . . . . . . . . . . . . 8 64 5.1 Access over Tunnels-Customers with Public IPv4 Address . . 9 65 5.2 Access over Tunnels-Customers with Private IPv4 Address . 9 66 5.3 Transition a Portion of the IPv4 Infrastructure . . . . . 10 67 6. Broadband Cable Networks . . . . . . . . . . . . . . . . . . 10 68 6.1 Broadband Cable Network Elements . . . . . . . . . . . . . 11 69 6.2 Deploying IPv6 in Cable Networks . . . . . . . . . . . . . 12 70 6.2.1 Deploying IPv6 in a Bridged CMTS Network . . . . . . . 13 71 6.2.2 Deploying IPv6 in a Routed CMTS Network . . . . . . . 16 72 6.2.3 IPv6 Multicast . . . . . . . . . . . . . . . . . . . . 25 73 6.2.4 IPv6 QoS . . . . . . . . . . . . . . . . . . . . . . . 26 74 6.2.5 IPv6 Security Considerations . . . . . . . . . . . . . 27 75 6.2.6 IPv6 Network Management . . . . . . . . . . . . . . . 28 76 7. Broadband DSL Networks . . . . . . . . . . . . . . . . . . . 29 77 7.1 DSL Network Elements . . . . . . . . . . . . . . . . . . . 29 78 7.2 Deploying IPv6 in IPv4 DSL Networks . . . . . . . . . . . 30 79 7.2.1 Point-to-Point Model . . . . . . . . . . . . . . . . . 31 80 7.2.2 PPP Terminated Aggregation (PTA) Model . . . . . . . . 33 81 7.2.3 L2TPv2 Access Aggregation (LAA) Model . . . . . . . . 36 82 7.2.4 Hybrid Model for IPv4 and IPv6 Service . . . . . . . . 38 83 7.3 IPv6 Multicast . . . . . . . . . . . . . . . . . . . . . . 41 84 7.3.1 ASM Based Deployments . . . . . . . . . . . . . . . . 41 85 7.3.2 SSM Based Deployments . . . . . . . . . . . . . . . . 42 86 7.4 IPv6 QoS . . . . . . . . . . . . . . . . . . . . . . . . . 43 87 7.5 IPv6 Security Considerations . . . . . . . . . . . . . . . 43 88 7.6 IPv6 Network management . . . . . . . . . . . . . . . . . 44 89 8. Broadband Ethernet Networks . . . . . . . . . . . . . . . . 45 90 8.1 Ethernet Access Network Elements . . . . . . . . . . . . . 45 91 8.2 Deploying IPv6 in IPv4 Broadband Ethernet Networks . . . . 46 92 8.2.1 Point-to-Point Model . . . . . . . . . . . . . . . . . 47 93 8.2.2 PPP Terminated Aggregation (PTA) Model . . . . . . . . 49 94 8.2.3 L2TPv2 Access Aggregation (LAA) Model . . . . . . . . 51 95 8.2.4 Hybrid Model for IPv4 and IPv6 Service . . . . . . . . 53 96 8.3 IPv6 Multicast . . . . . . . . . . . . . . . . . . . . . . 55 97 8.4 IPv6 QoS . . . . . . . . . . . . . . . . . . . . . . . . . 56 98 8.5 IPv6 Security Considerations . . . . . . . . . . . . . . . 56 99 8.6 IPv6 Network Management . . . . . . . . . . . . . . . . . 57 100 9. Wireless LAN . . . . . . . . . . . . . . . . . . . . . . . . 58 101 9.1 WLAN Deployment Scenarios . . . . . . . . . . . . . . . . 58 102 9.1.1 Layer 2 Switch Between AP and Edge Router . . . . . . 59 103 9.1.2 Access Router Between AP and SP Edge Router . . . . . 62 104 9.1.3 PPP Based Model . . . . . . . . . . . . . . . . . . . 64 105 9.2 IPv6 Multicast . . . . . . . . . . . . . . . . . . . . . . 66 106 9.3 IPv6 QoS . . . . . . . . . . . . . . . . . . . . . . . . . 68 107 9.4 IPv6 Security Considerations . . . . . . . . . . . . . . . 68 108 9.5 IPv6 Network Management . . . . . . . . . . . . . . . . . 69 109 10. Broadband Power Line Communications (PLC) . . . . . . . . . 70 110 10.1 PLC/BPL Access Network Elements . . . . . . . . . . . . 70 111 10.2 Deploying IPv6 in IPv4 PLC/BPL . . . . . . . . . . . . . 71 112 10.2.1 IPv6 Related Infrastructure Changes . . . . . . . . 72 113 10.2.2 Addressing . . . . . . . . . . . . . . . . . . . . . 72 114 10.2.3 Routing . . . . . . . . . . . . . . . . . . . . . . 73 115 10.3 IPv6 Multicast . . . . . . . . . . . . . . . . . . . . . 73 116 10.4 IPv6 QoS . . . . . . . . . . . . . . . . . . . . . . . . 73 117 10.5 IPv6 Security Considerations . . . . . . . . . . . . . . 73 118 10.6 IPv6 Network Management . . . . . . . . . . . . . . . . 74 119 11. Gap Analysis . . . . . . . . . . . . . . . . . . . . . . . . 74 120 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . 76 121 13. Security Considerations . . . . . . . . . . . . . . . . . . 76 122 14. References . . . . . . . . . . . . . . . . . . . . . . . . . 76 123 14.1 Normative References . . . . . . . . . . . . . . . . . . 76 124 14.2 Informative References . . . . . . . . . . . . . . . . . 78 125 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 79 126 Intellectual Property and Copyright Statements . . . . . . . 80 128 1. Introduction 130 With the exponential growth of the Internet and increasing number of 131 end users, SPs are looking for new ways to evolve their current 132 network architecture to meet the needs of Internet ready appliances, 133 new applications and services. IPv6 is designed to enable SPs to 134 meet these challenges and provide new services to their customers. 136 As the number of devices per BB user increase exponentially 137 worldwide, Cable, DSL, Ethernet to the Home, Wireless, PLC/BPL and 138 other always-on access technologies can benefit from the huge address 139 range [9] of IPv6. Other benefits of IPv6 include the capability to 140 enhance end-to-end security, mobile communications, and ease system 141 management burdens. Some examples include peer-to-peer communication 142 without NAT traversal problems, being able to access securely devices 143 at home from work, enhanced IP Mobility [24] and so on. 145 Therefore SPs are aggressively evaluating the capabilities of IPv6 to 146 meet these needs. Some countries have taken a lead role in this race 147 and moved from testing and evaluation to real deployments of IPv6 in 148 the BB arena. Japan is a prime example along with other countries 149 that are looking at moving towards large scale production deployments 150 of IPv6. 152 The SPs are deploying tunneling mechanisms to transport IPv6 over 153 their existing IPv4 networks as a start as well as deploying native 154 IPv6 where possible. Deployment of tunneling solutions is simpler, 155 easier and more economical to start the IPv6 services, as they 156 require minimal investments and network infrastructure changes in 157 current SP model. Depending on customer needs and requirements a 158 native IPv6 deployment option might be more scalable and provide 159 required service performance. 161 2. IPv6 Based BB Services 163 At this point IPv6 based services are seen as a differentiator that 164 enables SPs to take advantage of the large IPv6 address space to the 165 extent that subscribers get up to fixed /48 prefixes versus the 166 single, temporary IPv4 addresses. Such resources allow the SPs to 167 better position themselves against the competition. The IPv6 168 deployments can be seen as a driver for lower service support costs 169 by eliminating NAT with its negative impact on applications and its 170 complex behavior. Another reason of IPv6 being popular in some 171 countries might be the government driven financial incentives and 172 favorable legislation towards the IPs who are deploying IPv6. 174 NTT East, Japan started a commercial dual-stack (devices capable of 175 forwarding IPv4 and IPv6 packets) IPv6 unicast service option early 176 this year for its ADSL and FTTH subscribers, under the name of 177 FLETS.Net [26]. For these users the IPv6 addresses are dedicated 178 (/64 per user) and are used when needed. However, this IPv6 service 179 is available only to the NTT-East ADSL and FTTH subscribers who are 180 part of FLETS.NET network and at this point does not provide 181 connectivity to the IPv6 Internet. 183 Some ISPs that are currently providing IPv4 based Multicast and VoIP 184 services are evaluating IPv6 to improve and expand their service. 185 The Multicast services consist of video and audio streaming of 186 several programs (streams). The content provider delivers these 187 streams to BB subscribers. One of today's challenges is the fact 188 that when done through IPv4, there is generally a single device 189 directly attached to the CPE that receives the Multicast stream. By 190 moving to IPv6, ISP should be capable to provide multiple streams to 191 multiple devices on the customer site. 193 For instance in Japan, Cable TV and dish services are not very 194 popular, the users expect content mostly through the broadcasted, 195 free programs (traditional TV). In case of BB users however, they 196 can get additional content through their SP, which can be delivered 197 at a reasonable priced for 20 Mbps or 10/100 Mbps of bandwidth. 198 Users sign up with a content provider that is multicasting several 199 channels of video and audio. A subscriber would join the multicast 200 group of interest (after authentication) and will start receiving the 201 stream(s). An example of a video stream could be Disney movies and 202 an example of an audio stream could be Karaoke (part of same *,G 203 group). Similar to Cable TV, where customers sign up and pay for 204 single programs or packages of programs. 206 SPs are also offering IPv6 services over wireless links using 802.11 207 compliant WiFi Hot Spots. This enables users to take notebook PCs 208 and PDAs (Windows 2003 supports IPv6 capable Internet Explorer and 209 Media Player 9) along with them and connect to the Internet from 210 various locations without the restriction of staying indoors. 212 3. Scope of the Document 214 This document presents the options available in deploying IPv6 215 services in the access portion of a BB Service Provider network 216 namely Cable/HFC, BB Ethernet, xDSL, WLAN and PLC/BPL. 218 This document briefly discusses the other elements of a provider 219 network as well. It provides different viable IPv6 deployment and 220 integration techniques and models for each of the above mentioned BB 221 technologies individually. The example list is not exhaustive but it 222 tries to be representative. 224 This document analyzes, how all the important parts of current IPv4 225 based Cable/HFC, BB Ethernet, xDSL, WLAN and PLC/BPL networks will 226 behave when IPv6 is integrated and deployed. 228 The following important pieces are discussed: 230 A. Available tunneling options 232 B. Devices that would require to be upgraded to support IPv6 234 C. Available IPv6 address assignment techniques and their use 236 D. Possible IPv6 Routing options and their use 238 E. IPv6 unicast and multicast packet transmission 240 F. Required IPv6 QoS parameters 242 G. Required IPv6 Security parameters 244 H. Required IPv6 Network Management parameters 246 It is important to note that the addressing rules provided throughout 247 this document represent an example that follows the current 248 assignment policies and recommendations of the registries. They can 249 be however adapted to the network and business model needs of the 250 ISPs. 252 The scope of the document is to advise on the ways of upgrading an 253 existing infrastructure to support IPv6 services. The recommendation 254 to upgrade a device to dual-stack does not stop an SP from adding a 255 new device to its network to perform the neccessary IPv6 functions 256 discussed. The costs involved could be offset by lower impact on the 257 existing IPv4 services. 259 4. Core/Backbone Network 261 This section intends to briefly discuss some important elements of a 262 provider network tied to the deployment of IPv6. A more detailed 263 description of the core network is provided in other documents [25]. 265 There are two networks identified in the Broadband deployments: 267 A. Access Provider Network: This network provides the broadband 268 access and aggregates the subscribers. The subscriber traffic is 269 handed over to the Service Provider at Layer 2 or 3. 271 B. Service Provider Network: This network provides Intranet and 272 Internet IP connectivity for the subscribers. 274 The Service Provider network structure beyond the Edge routers that 275 interface with the Access provider is beyond the scope of this 276 document. 278 4.1 Layer 2 Access Provider Network 280 The Access Provider can deploy a Layer 2 network and perform no 281 routing of the subscriber traffic to the SP. The devices that 282 support each specific access technology are aggregated into a highly 283 redundant, resilient and scalable layer two core. The network core 284 can involve various technologies such as Ethernet, ATM etc. The 285 Service Provider Edge Router connects to the Access Provider core. 287 In this type of a network the impact of deploying IPv6 is minimal. 288 The network is transparent to the Layer 3 protocol. The only 289 possible changes would come with the intent of filtering and 290 monitoring IPv6 traffic based on layer 2 information such as IPv6 291 Ether Type Protocol ID (0x86DD) or IPv6 multicast specific MAC 292 addresses (3333.xxxx.xxxx). 294 4.2 Layer3 Access Provider Network 296 The Access Provider can choose to terminate the Layer 2 domain and 297 route the IP traffic to the Service Provider network. Access Routers 298 are used to aggregate the subscriber traffic and route it over a 299 Layer3 core to the SP Edge Routers. In this case the impact of the 300 IPv6 deployment is significant. 302 The case studies in this document only present the significant 303 network elements of such a network: Customer Premises Equipment, 304 Access Router and Edge Router. In real networks the link between the 305 Access Router and the Edge Router involves other routers that are 306 part of the aggregation and the core layer of the Access Provider 307 network. 309 The Access Provider can forward the IPv6 traffic through its layer3 310 core in three possible ways: 312 A. IPv6 Tunneling: As a temporary solution, the Access Providers can 313 choose to use a tunneling mechanism to forward the subscriber IPv6 314 traffic to the Service Provider Edge Router. This approach has the 315 least impact on the Access Provider network however, as the number of 316 users increase and the amount of IPv6 traffic grows, the ISP will 317 have to evolve to one of the scenarios listed below. 319 B. Native IPv6 Deployment: The Access Provider routers are upgraded 320 to support IPv6 and can become dual-stack. In a dual-stack network 321 an IPv6 IGP such as OSPFv3 or IS-IS is enabled. RFC4029 discusses 322 the IGP selection options with their benefits and drawbacks. 324 C. MPLS 6PE Deployment [27]: If the Access Provider is running MPLS 325 in its IPv4 core it could use 6PE to forward IPv6 traffic over it. 326 In this case only a subset of routers close to the edge of the 327 network need to be IPv6 aware. With this approach BGP becomes 328 important in order to support 6PE. 330 The 6PE approach has the advantage of having minimal impact on the 331 Access Provider network. Fewer devices need to be upgraded and 332 configured while the MPLS core continues to switch the traffic un- 333 aware of the fact that it transports both IPv4 and IPv6 traffic. 6PE 334 should be leveraged only if MPLS is already deployed in the network. 335 At the time of writing this document, a major disadvantage of the 6PE 336 solution is the fact that it does not support multicast IPv6 traffic. 338 The native approach has the advantage of supporting IPv6 multicast 339 traffic but it may imply a significant impact on the IPv4 operational 340 network from software, configuration and possibly hardware upgrade 341 perspective. 343 More detailed Core Network deployment recommendations are discussed 344 in other documents RFC4029. The handling of IPv6 traffic in the Core 345 of the Access Provider Network will not be discussed for the 346 remainder of this document. 348 5. Tunneling Overview 350 Service Providers might not be able to deploy native IPv6 today due 351 to the cost associated with HW and SW upgrades, the infrastructure 352 changes needed to their current network and the current demand for 353 the service. For these reasons, some SPs might choose tunneling 354 based transition mechanisms to start an IPv6 service offering and 355 move to native IPv6 deployment at a later time. 357 Several tunneling mechanisms were developed specifically to transport 358 IPv6 over existing IPv4 infrastructures. Several of them have been 359 standardized and their use depends on the existing SP IPv4 network 360 and the structure of the IPv6 service. The requirements for the most 361 appropriate mechanisms are described in [35] with more updates to 362 follow. Deploying IPv6 using tunneling techniques can imply as 363 little changes to the network as upgrading SW on tunnel end points 364 (TEP). A Service Provider could use tunneling to deploy IPv6 in the 365 following scenarios: 367 5.1 Access over Tunnels-Customers with Public IPv4 Address 369 If the customer is a residential user, it can initiate the tunnel 370 directly from the IPv6 capable host to a tunnel termination router 371 located in the NAP or ISP network. The tunnel type used should be 372 decided by the SP but it should take into consideration its 373 availability on commonly used software running on the host machine. 374 Out of the many tunneling mechanisms developed [[2], [3], [4], [28], 375 [5], [6]] some are more popular than the others. 377 If the end customer has a GWR installed, then it could be used to 378 originate the tunnel and thus offer native IPv6 access to multiple 379 hosts on the customer network. In this case the GWR would need to be 380 upgraded to dual-stack in order to support IPv6. The GWR can be 381 owned by the customer or by the SP 383 5.2 Access over Tunnels-Customers with Private IPv4 Address 385 If the end customer receives a private IPv4 address and needs to 386 initiate a tunnel through NAT, techniques like 6to4 may not work 387 since they rely on Public IPv4 address. In this case, unless the 388 existing CPE supports protocol-41-forwarding, the end user might have 389 to use tunnels that can operate through NATs (such as Teredo tunnel 390 [30]). 392 The customer has the option to initiate the tunnel from the device 393 (GWR) that performs the NAT functionality, similar to the GWR 394 scenario discussed in section 5.1. This will imply HW replacement or 395 SW upgrade and a native IPv6 environment behind the GWR. Most GWRs 396 support protocol-41-forwarding which means that hosts can initiate 397 the tunnels in which case the GWR is not affected by the IPv6 398 service. 400 It is important to note that the customers of a Service Provider can 401 choose to establish tunnels to publicly available and free tunnel 402 services. Even though the quality of such services might not be 403 high, they provide free IPv6 access. In designing their IPv6 404 services, the SPs should take into considerations such options 405 available to their potential customers. The IPv6 deployment should 406 support services (like multicast, VoIPv6 etc) and a level of quality 407 that would make the access through the SP worthwhile to potential 408 subscribers. 410 It is also worth observing that initiating an IPv6 tunnel over IPv4 411 through already established IPv4 IPsec sessions would provide a 412 certain level of security to the IPv6 traffic [Tunnel through IPsec]. 414 5.3 Transition a Portion of the IPv4 Infrastructure 416 Tunnels can be used to transport the IPv6 traffic across a defined 417 segment of the network. As an example, the customer might connect 418 natively to the Network Access Provider and a tunnel is used to 419 transit the traffic over IPv4 to the ISP. In this case the tunnel 420 choice depends on its capabilities (for example, whether it supports 421 multicast or not), routing protocols used (there are several types 422 that can transport layer 2 messages such as GRE, L2TPv3 or 423 Pseudowire), manage-ability and scalability (dynamic versus static 424 tunnels). 426 This scenario implies that the access portion of the network has been 427 upgraded to support dual stack so the savings provided by tunneling 428 in this scenario are very small compared with the previous two 429 scenarios. Depending on the number of sites requiring the service 430 and considering the expenses required to manage the tunnels (some 431 tunnels are static while others are dynamic [29]) in this case, the 432 SPs might find the native approach worth the additional investments. 434 In all the scenarios listed above the tunnel selection process should 435 consider the IPv6 multicast forwarding capabilities if such service 436 is planned. As an example, 6to4 tunnels do not support IPv6 437 multicast traffic. 439 The operation, capabilities and deployment of various tunnel types 440 has been discussed extensively in the documents referenced earlier as 441 well as in [[30], [7]]. Details of a tunnel based deployment are 442 offered in the next section of this document (section 6). In the 443 case of Cable Access where the current DOCSIS specifications do not 444 provide support for native IPv6 access. Although sections 7, 8, 9 445 and 10 focus on a native IPv6 deployments over DSL, FTTH, Wireless 446 and PLC/BPL because this approach is fully supported today, tunnel 447 based solutions are also possible in these cases based on the 448 guidelines of this section and some of the recommendations provided 449 in section 6. 451 6. Broadband Cable Networks 453 This section describes the infrastructure that exists today in cable 454 networks providing BB services to the home. It also describes IPv6 455 deployment options in these cable networks. 457 DOCSIS standardizes and documents the operation of data over Cable 458 Networks. The current version of DOCSIS has limitations that do not 459 allow for a smooth implementation of native IPv6 transport. Some of 460 these limitations are discussed in this section. For this reason, 461 the IPv6 deployment scenarios discussed in this section for the 462 existent Cable Networks are tunnel based. The tunneling examples 463 presented here could also be applied to the other BB technologies 464 described in sections 7, 8, 9 and 10. 466 6.1 Broadband Cable Network Elements 468 Broadband cable networks are capable of transporting IP traffic to/ 469 from users to provide high speed Internet access and VOIP services. 470 The mechanism of transporting IP traffic over cable networks is 471 outlined in the DOCSIS specification [33]. 473 Here are some of the key elements of a Cable network: 475 Cable (HFC) Plant: Hybrid Fiber Coaxial plant, used as the underlying 476 transport 478 CMTS: Cable Modem Termination System (can be a Layer 2 bridging or 479 Layer 3 routing CMTS) 481 GWR: Residential Gateway Router (provides Layer 3 services to hosts) 483 Host: PC, notebook etc. which is connected to the CM or GWR 485 CM: Cable Modem 487 ER: Edge Router 489 MSO: Multiple Service Operator 491 Data Over Cable Service Interface Specification (DOCSIS): The 492 standards defining how data should be carried over cable networks. 494 Figure 6.1 illustrates the key elements of a Cable Network 496 |--- ACCESS ---||------ HFC ------||----- Aggregation / Core -----| 498 +-----+ +------+ 499 |Host |--| GWR | 500 +-----+ +--+---+ 501 | _ _ _ _ _ _ 502 +------+ | | 503 | CM |---| | 504 +------+ | | 505 | HFC | +------+ +--------+ 506 | | | | | Edge | 507 +-----+ +------+ | Network |---| CMTS |---| |===> ISP 508 |Host |--| CM |---| | | | | Router | Network 509 +-----+ +--+---+ | | +------+ +--------+ 510 |_ _ _ _ _ _| 511 +------+ | 512 +-----+ | GWR/ | | 513 |Host |--| CM |---------+ 514 +-----+ | | 515 +------+ Figure 6.1 517 6.2 Deploying IPv6 in Cable Networks 519 One of the motivators for an MSO to deploy IPv6 over their Cable 520 Network is to ease management burdens. IPv6 can be enabled on the 521 CM, CMTS and ER for management purposes. Currently portions of the 522 cable infrastructure use [1] IPv4 addresses; however, there are a 523 finite number of those. Thus, IPv6 could have utility in the cable 524 space implemented on the management plane initially and later on 525 focused on the data plane for end user services. For more details on 526 using IPv6 for management in Cable Networks please refer to section 527 6.6.1. 529 There are two different deployment modes in current cable networks: a 530 bridged CMTS environment and a routed CMTS environment. IPv6 can be 531 deployed in both of these environments. 533 1. Bridged CMTS Network 535 In this scenario, both the CM and CMTS bridge all data traffic. 536 Traffic to/from host devices is forwarded through the cable network 537 to the ER. The ER then routes traffic through the ISP network to the 538 Internet. The CM and CMTS support a certain degree of Layer 3 539 functionality for management purposes. 541 2. Routed CMTS Network 543 In a routed network, the CMTS forwards IP traffic to/from hosts based 544 on Layer 3 information using the IP source/destination address. The 545 CM acts as a Layer-2 bridge for forwarding data traffic and supports 546 some Layer 3 functionality for management purposes. 548 Some of the factors that hinder deployment of native IPv6 in current 549 routed and bridged cable networks include: 551 A. Problems with IPv6 Neighbor Discovery (ND) on CM and CMTS. These 552 devices rely on IGMP join messages to track membership of hosts that 553 are part of a particular IP Multicast group. In order to support ND 554 the CM and CMTS will need to support IGMPv3/MLDv2 or v1 snooping. 556 B. Classification of IPv6 traffic in the upstream and downstream 557 direction. The CM and CMTS will need to support classification of 558 IPv6 packets in order to give them the appropriate priority and QoS. 559 Without proper classification all IPv6 traffic will need to be sent 560 best effort (BE) which can cause problems when deploying services 561 like VOIP and IP Multicast video. 563 C. Changes need to be made to the DOCSIS specification to include 564 support for IPv6 on the CM and CMTS. This is imperative for 565 deploying native IPv6 over cable networks. 567 Due to the above mentioned limitations in deployed cable networks, 568 the only available option to cable operators is to use tunneling 569 techniques in order to transport IPv6 traffic over their current IPv4 570 infrastructure. The following sections will cover these deployment 571 scenarios in more detail. 573 6.2.1 Deploying IPv6 in a Bridged CMTS Network 575 In IPv4 the CM and CMTS act as Layer 2 bridges and forward all data 576 traffic to/from the hosts and the ER. The hosts use the ER as their 577 Layer 3 next hop. If there is a GWR behind the CM it can act as a 578 next hop for all hosts and forward data traffic to/from the ER. 580 When deploying IPv6 in this environment, the CM and CMTS will 581 continue to be bridging devices in order to keep the transition 582 smooth and reduce operational complexity. The CM and CMTS will need 583 to bridge IPv6 unicast and multicast packets to/from the ER and the 584 hosts. If there is a GWR connected to the CM, it will need to 585 forward IPv6 unicast and multicast traffic to/from the ER. 587 IPv6 can be deployed in a bridged CMTS network either natively or via 588 tunneling. This section discusses the native deployment model. The 589 tunneling model is similar to ones described in sections 6.2.2.1 and 590 6.2.2.2. 592 Figure 6.2.1 illustrate the IPv6 deployment scenario 594 +-----+ +-----+ 595 |Host |--| GWR | 596 +-----+ +--+--+ 597 | _ _ _ _ _ _ 598 | +------+ | | 599 +--| CM |---| | 600 +------+ | | 601 | HFC | +------+ +--------+ 602 | | | | | Edge | 603 +-----+ +------+ | Network |--| CMTS |--| |===> ISP 604 |Host |--| CM |---| | | | | Router | Network 605 +-----+ +------+ | | +------+ +--------+ 606 |_ _ _ _ _ _| 607 |-------------||---------------------------------||---------------| 608 L3 Routed L2 Bridged L3 Routed 610 Figure 6.2.1 612 6.2.1.1 IPv6 Related Infrastructure Changes 614 In this scenario the CM and the CMTS bridge all data traffic so they 615 will need to support bridging of native IPv6 unicast and multicast 616 traffic. The following devices have to be upgraded to dual stack: 617 Host, GWR and ER. 619 6.2.1.2 Addressing 621 The proposed architecture for IPv6 deployment includes two components 622 that must be provisioned: the CM and the host. Additionally if there 623 is a GWR connected to the CM, it will also need to be provisioned. 624 The host or the GWR use the ER as their Layer 3 next hop. 626 6.2.1.2.1 IP Addressing for CM 628 The CM will be provisioned in the same way as in currently deployed 629 cable networks, using an IPv4 address on the cable interface 630 connected to the MSO network for management functions. During the 631 initialization phase, it will obtain its IPv4 address using DHCPv4, 632 and download a DOCSIS configuration file identified by the DHCPv4 633 server. 635 6.2.1.2.2 IP Addressing for Hosts 637 If there is no GWR connected to the CM, the host behind the CM will 638 get a /64 prefix assigned to it via stateless autoconfiguration or 639 DHCPv6. 641 If using stateless auto-configuration, the host listens for routing 642 advertisements (RA) from the ER. The RAs contain the /64 prefix 643 assigned to the segment. Upon receipt of an RA, the host constructs 644 its IPv6 address by combining the prefix in the RA (/64) and a unique 645 identifier (e.g., its modified EUI-64 format interface ID). 647 If DHCPv6 is used to obtain an IPv6 address, it will work in much the 648 same way as DHCPv4 works today. The DHCPv6 messages exchanged 649 between the host and the DHCPv6 server are bridged by the CM and the 650 CMTS. 652 6.2.1.2.3 IP Addressing for GWR 654 The GWR can use stateless auto-configuration (RA) to obtain an 655 address for its upstream interface, the link between itself and the 656 ER. This step is followed by a request via DHCP-PD (Prefix 657 Delegation) for a prefix shorter than /64, typically /48 [8], which 658 in turn is divided into /64s and assigned to its downstream 659 interfaces connecting to the hosts. 661 6.2.1.3 Data Forwarding 663 The CM and CMTS must be able to bridge native IPv6 unicast and 664 multicast traffic. The CMTS must provide IP connectivity between 665 hosts attached to CMs and must do so in a way that meets the 666 expectation of Ethernet attached customer equipment. In order to do 667 that, the CM and CMTS must forward Neighbor Discovery (ND) packets 668 between ER and the hosts attached to the CM. 670 Communication between hosts behind different CMs is always forwarded 671 through the CMTS. IPv6 communication between the different sites 672 relies on multicast IPv6 ND [18] frames being forwarded correctly by 673 the CM and the CMTS. As with the CM, a bridged CMTS that selectively 674 forwards multicast datagrams on the basis of MLD will potentially 675 break IPv6 ND. 677 In order to support IPv6 multicast applications across DOCSIS cable 678 networks, the CM and bridging CMTS need to support IGMPv3/MLDv2 or v1 679 snooping. MLD is almost identical to IGMP in IPv4, only the name and 680 numbers are changed. MLDv2 is identical to IGMPv3 and also supports 681 ASM (Any Source Multicast) and SSM (Single Source Multicast) service 682 models. Implementation work on CM/CMTS should be minimal because the 683 only significant difference between IPv4 IGMPv3 and IPv6 MLDv2 is the 684 longer addresses in the protocol. 686 6.2.1.4 Routing 688 The hosts install a default route that points to the ER or the GWR. 689 No routing protocols are needed on these devices which generally have 690 limited resources. If there is a GWR present it will also use static 691 default route to the ER. 693 The ER runs an IGP such as OSPFv3 or IS-IS. The connected prefixes 694 have to be redistributed. If DHCP-PD is used, with every delegated 695 prefix a static route is installed by the ER. For this reason the 696 static routes must also be redistributed. Prefix summarization 697 should be done at the ER. 699 6.2.2 Deploying IPv6 in a Routed CMTS Network 701 In an IPv4 routed CMTS network the CM still acts as a Layer-2 device 702 and bridges all data traffic between its Ethernet interface and cable 703 interface connected to the cable operator network. The CMTS acts as 704 a Layer 3 router and may also include the ER functionality. The 705 hosts and the GWR use the CMTS as their Layer 3 next hop. 707 When deploying IPv6 in a routed CMTS network, the CM still acts as a 708 Layer-2 device and will need to bridge IPv6 unicast as well as 709 multicast traffic. The CMTS/ER will need to either tunnel IPv6 710 traffic or natively support IPv6. The host and GWR will use the 711 CMTS/ER as their Layer 3 next hop. 713 There could be five possible deployment scenarios for IPv6 in a 714 routed CMTS network: 716 1. IPv4 Cable (HFC) Network 718 In this scenario the cable network, including the CM and CMTS remain 719 IPv4 devices. The host and ER are upgraded to dual-stack. This is 720 the easiest way for a Cable Operator to provide IPv6 service as no 721 changes are made to the cable network. 723 2. IPv4 Cable (HFC) Network, GWR at Customer Site 725 In this case the cable network, including the CM and CMTS remain IPv4 726 devices. The host, GWR and ER are upgraded to dual-stack. This 727 scenario is also easy to deploy since the cable operator just needs 728 to add GWR at the customer site. 730 3. Dual-stacked Cable (HFC) Network, CM and CMTS Support IPv6 732 In this scenario the CMTS is upgraded to dual-stack to support IPv4 733 and IPv6. Since the CMTS supports IPv6 it can acts as an ER as well. 734 The CM will act as a Layer-2 bridge but will need to bridge IPv6 735 unicast and multicast traffic. This scenario is not easy to deploy 736 since it requires changes to the DOCSIS specification. The CM and 737 CMTS may require HW and SW upgrades to support IPv6. 739 4. Dual-stacked Cable (HFC) Network, Standalone GWR and CMTS Support 740 IPv6 742 In this scenario there is a standalone GWR connected to the CM. 743 Since the IPv6 functionality exists on the GWR the CM does not need 744 to be dual-stack. The CMTS is upgraded to dual-stack and it can 745 incorporate the ER functionality. This scenario may also require HW 746 and SW changes on the GWR and CMTS. 748 5. Dual-stacked Cable (HFC) Network, Embedded GWR/CM and CMTS 749 Support IPv6 751 In this scenario the CM and GWR functionality exists on a single 752 device which needs to be upgraded to dual-stack. The CMTS will also 753 need to be upgraded to a dual-stack device. This scenario is also 754 difficult to deploy in existent cable network since it requires 755 changes on the Embedded GWR/CM and the CMTS. 757 The DOCSIS specification will also need to be modified to allow 758 native IPv6 support on the Embedded GWR/CM. 760 6.2.2.1 IPv4 Cable Network, Host and ER Upgraded to Dual-Stack 762 This is one of the most cost effective ways for a Cable Operator to 763 offer IPv6 services to its customers. Since the cable network 764 remains IPv4 there is relatively minimal cost involved in turning up 765 IPv6 service. All IPv6 traffic is exchanged between the hosts and 766 the ER. 768 Figure 6.2.2.1 illustrates this deployment scenario 770 +-----------+ +------+ +--------+ 771 +-----+ +-------+ | Cable | | | | Edge | 772 |Host |--| CM |----| (HFC) |---| CMTS |---| |=>ISP 773 +-----+ +-------+ | Network | | | | Router | Network 774 +-----------+ +------+ +--------+ 775 _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ 776 ()_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _() 777 IPv6-in-IPv4 tunnel 779 |---------||----------------------------------------||------------| 780 IPv4/v6 IPv4 only IPv4/v6 782 Figure 6.2.2.1 784 6.2.2.1.1 IPv6 Related Infrastructure Changes 786 In this scenario the CM and the CMTS will only need to support IPv4 787 so no changes need to be made to them or the cable network. The 788 following devices have to be upgraded to dual stack: Host and ER. 790 6.2.2.1.2 Addressing 792 The only device that needs to be assigned an IPv6 address at customer 793 site is the host. Host address assignment can be done in multiple 794 ways. Depending on the tunneling mechanism used it could be 795 automatic or might require manual configuration. 797 The host still receives an IPv4 address using DHCPv4, which works the 798 same way in currently deployed cable networks. In order to get IPv6 799 connectivity, host devices will also need an IPv6 address and a means 800 to communicate with the ER. 802 6.2.2.1.3 Data Forwarding 804 All IPv6 traffic will be sent to/from the ER and the host device. In 805 order to transport IPv6 packets over the cable operator IPv4 network, 806 the host and the ER will need to use one of the available IPv6 in 807 IPv4 tunneling mechanisms. 809 The host will use its IPv4 address to source the tunnel to the ER. 810 All IPv6 traffic will be forwarded to the ER, encapsulated in IPv4 811 packets. The intermediate IPv4 nodes will forward this traffic as 812 regular IPv4 packets. The ER will need to terminate the tunnel 813 and/or provide other IPv6 services. 815 6.2.2.1.4 Routing 817 Routing configuration on the host will vary depending on the 818 tunneling technique used, in some cases a default or static route 819 might be needed to forward traffic to the next hop. 821 The ER runs an IGP such as OSPFv3 or ISIS. 823 6.2.2.2 IPv4 Cable Network, Host, GWR and ER Upgraded to Dual-Stack 825 The cable operator can provide IPv6 services to its customers, in 826 this scenario, by adding a GWR behind the CM. Since the GWR will 827 facilitate all IPv6 traffic to/from the host and the ER, the cable 828 network including the CM and CMTS do not need to support IPv6 and can 829 remain as IPv4 devices. 831 Figure 6.2.2.2 illustrates this deployment scenario 833 +-----+ 834 |Host | 835 +--+--+ 836 | +-----------+ +------+ +--------+ 837 +---+---+ +-------+ | Cable | | | | Edge | 838 | GWR |--| CM |----| (HFC) |---| CMTS |---| |=>ISP 839 +-------+ +-------+ | Network | | | | Router | Network 840 +-----------+ +------+ +--------+ 841 _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ 842 ()_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _() 843 IPv6-in-IPv4 tunnel 845 |---------||---------------------------------------||-------------| 846 IPv4/v6 IPv4 only IPv4/v6 848 Figure 6.2.2.2 850 6.2.2.2.1 IPv6 Related Infrastructure Changes 852 In this scenario the CM and the CMTS will only need to support IPv4 853 so no changes need to be made to them or the cable network. The 854 following devices have to be upgraded to dual stack: Host, GWR and 855 ER. 857 6.2.2.2.2 Addressing 859 The only devices that needs to be assigned an IPv6 address at 860 customer site are the host and GWR. IPv6 address assignment can be 861 done statically at the GWR downstream interface. The GWR will send 862 out RA messages on its downstream interface which will be used by the 863 hosts to auto-configure themselves with an IPv6 address. The GWR can 864 also configure its upstream interface using RA messages from the ER 865 and use DHCP-PD for requesting a /48 [8] prefix from the ER. This 866 /48 prefix will be used to configure /64s on hosts connected to the 867 GWR downstream interfaces. Currently the DHCP-PD functionality 868 cannot be implemented if the DHCP-PD server is not the Edge Router. 869 If the DHCP-PD messages are relayed, the Edge Router does not have a 870 mechanism to learn the assigned prefixes and thus install the proper 871 routes to make that prefix reachable. Work is being done to address 872 this issue, one idea being to provide the Edge Router with a snooping 873 mechanism. The uplink to the ISP network is configured with a /64 874 prefix as well. 876 The GWR still receives a global IPv4 address on its upstream 877 interface using DHCPv4, which works the same way in currently 878 deployed cable networks. In order to get IPv6 connectivity to the 879 Internet the GWR will need to communicate with the ER. 881 6.2.2.2.3 Data Forwarding 883 All IPv6 traffic will be sent to/from the ER and the GWR, which will 884 forward IPv6 traffic to/from the host. In order to transport IPv6 885 packets over the cable operator IPv4 network, the GWR and the ER will 886 need to use one of the available IPv6 in IPv4 tunneling mechanisms. 887 All IPv6 traffic will need to go through the tunnel, once it comes 888 up. 890 The GWR will use its IPv4 address to source the tunnel to the ER. 891 The tunnel endpoint will be the IPv4 address of the ER. All IPv6 892 traffic will be forwarded to the ER, encapsulated in IPv4 packets. 893 The intermediate IPv4 nodes will forward this traffic as regular IPv4 894 packets. In case of 6to4 tunneling, the ER will need to support 6to4 895 relay functionality in order to provide IPv6 Internet connectivity to 896 the GWR and hence the hosts connected to the GWR. 898 6.2.2.2.4 Routing 900 Depending on the tunneling technique used there might some 901 configuration needed on the GWR and the ER. If the ER is also 902 providing a 6to4 relay service then a default route will need to be 903 added to the GWR pointing to the ER, for all non-6to4 traffic. 905 If using manual tunneling, the GWR and ER can use static routing or 906 they can also configure RIPng. The RIPng updates can be transported 907 over a manual tunnel, which does not work when using 6to4 tunneling. 909 Customer routes can be carried to the ER using RIPng updates. The ER 910 can advertise these routes in its IGP. Prefix summarization should 911 be done at the ER. 913 If DHCP-PD is used for address assignment a static route is 914 automatically installed on the CMTS/ER for each delegated /48 prefix. 915 The static routes need to be redistributed into the IGP at the 916 CMTS/ER, so there is no need for a routing protocol between the 917 CMTS/ER and the GWR. 919 The ER runs an IGP such as OSPFv3 or ISIS. 921 6.2.2.3 Dual-stacked Cable (HFC) Network, CM and CMTS Support IPv6 923 In this scenario the Cable Operator can offer native IPv6 services to 924 its customers since the cable network including the CMTS supports 925 IPv6. The ER functionality can be included in the CMTS or it can 926 exist on a separate router connected to the CMTS upstream interface. 927 The CM will need to bridge IPv6 unicast and multicast traffic. 929 Figure 6.2.2.3 illustrates this deployment scenario 931 +-----------+ +-------------+ 932 +-----+ +-------+ | Cable | | CMTS / Edge | 933 |Host |--| CM |----| (HFC) |----| |=>ISP 934 +-----+ +-------+ | Network | | Router | Network 935 +-----------+ +-------------+ 937 |-------||----------------------------||----------------| 938 IPv4/v6 IPv4/v6 IPv4/v6 940 Figure 6.2.2.3 942 6.2.2.3.1 IPv6 Related Infrastructure Changes 944 Since the CM still acts as a Layer-2 bridge, it does not need to be 945 dual-stack. The CM will need to support bridging of IPv6 unicast and 946 multicast traffic and IGMPv3/MLDv2 or v1 snooping which requires 947 changes in the DOCSIS specification. In this scenario the following 948 devices have to be upgraded to dual stack: Host and CMTS/ER. 950 6.2.2.3.2 Addressing 952 In today's cable networks the CM receives a private IPv4 address 953 using DHCPv4 for management purposes. In an IPv6 environment, the CM 954 will continue to use an IPv4 address for management purposes. The 955 cable operator can also choose to assign an IPv6 address to the CM 956 for management, but the CM will have to be upgraded to support this 957 functionality. 959 IPv6 address assignment for the CM and host can be done via DHCP or 960 stateless autoconfiguration. If the CM uses an IPv4 address for 961 management, it will use DHCPv4 for its address assignment and the 962 CMTS will need to act as a DHCPv4 relay agent. If the CM uses an 963 IPv6 address for management, it can use DHCPv6 with the CMTS acting 964 as a DHCPv6 relay agent or the CMTS can be statically configured with 965 a /64 prefix and it can send out RA messages out the cable interface. 966 The CMs connected to the cable interface can use the RA messages to 967 auto-configure themselves with an IPv6 address. All CMs connected to 968 the cable interface will be in the same subnet. 970 The hosts can receive their IPv6 address via DHCPv6 or stateless 971 autoconfiguration. With DHCPv6, the CMTS may need to act as a DHCPv6 972 relay agent and forward DHCP messages between the hosts and the DHCP 973 server. With stateless autoconfiguration, the CMTS will be 974 configured with multiple /64 prefixes and send out RA messages to the 975 hosts. If the CMTS is not also acting as an ER, the RA messages will 976 come from the ER connected to the CMTS upstream interface. The CMTS 977 will need to forward the RA messages downstream or act as an ND 978 proxy. 980 6.2.2.3.3 Data Forwarding 982 All IPv6 traffic will be sent to/from the CMTS and hosts. Data 983 forwarding will work the same way it works in currently deployed 984 cable networks. The CMTS will forward IPv6 traffic to/from hosts 985 based on the IP source/destination address. 987 6.2.2.3.4 Routing 989 No routing protocols are needed between the CMTS and the host since 990 the CM and host are directly connected to the CMTS cable interface. 991 Since the CMTS supports IPv6, hosts will use the CMTS as their Layer 992 3 next hop. 994 If the CMTS is also acting as an ER, it runs an IGP such as OSPFv3 or 995 ISIS. 997 6.2.2.4 Dual-Stacked Cable (HFC) Network, Standalone GWR and CMTS 998 Support IPv6 1000 In this case the cable operator can offer IPv6 services to its 1001 customers by adding a GWR between the CM and the host. The GWR will 1002 facilitate IPv6 communication between the host and the CMTS/ER. The 1003 CMTS will be upgraded to dual-stack to support IPv6 and can acts as 1004 an ER as well. The CM will act as a bridge for forwarding data 1005 traffic and does not need to support IPv6. 1007 This scenario is similar to the case described in section 6.2.2.2. 1008 The only difference in this case is the ER functionality exists on 1009 the CMTS instead of a separate router in the cable operator network. 1011 Figure 6.2.2.4 illustrates this deployment scenario 1013 +-----------+ +------------+ 1014 +------+ +-------+ +-------+ | Cable | |CMTS / Edge | 1015 | Host |---| GWR |--| CM |--| (HFC) |--| |=>ISP 1016 +------+ +-------+ +-------+ | Network | | Router |Network 1017 +-----------+ +------------+ 1018 _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ 1019 ()_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _() 1020 IPv6-in-IPv4 tunnel 1021 |-----------------||--------------------------------||--------------| 1022 IPv4/v6 IPv4 IPv4/v6 1024 Figure 6.2.2.4 1026 6.2.2.4.1 IPv6 Related Infrastructure Changes 1028 Since the CM still acts as a Layer-2 bridge, it does not need to be 1029 dual-stack nor does it need to support IPv6. In this scenario the 1030 following devices have to be upgraded to dual stack: Host, GWR and 1031 CMTS/ER. 1033 6.2.2.4.2 Addressing 1035 The CM will still receive a private IPv4 address using DHCPv4 which 1036 works the same way in existent cable networks. The CMTS will act as 1037 DHCPv4 relay agent. 1039 The address assignment for the host and GWR happens in a similar 1040 manner as described in section 6.2.2.2.2. 1042 6.2.2.4.3 Data Forwarding 1044 Data forwarding between the host and CMTS/ER is facilitated by the 1045 GWR and happens in a similar manner as described in section 1046 6.2.2.2.3. 1048 6.2.2.4.4 Routing 1050 In this case routing is very similar to the case described in section 1051 6.2.2.2.4. Since the CMTS now incorporates the ER functionality, it 1052 will need to run an IGP such as OSPFv3 or ISIS. 1054 6.2.2.5 Dual-Stacked Cable (HFC) Network, Embedded GWR/CM and CMTS 1055 Support IPv6 1057 In this scenario the Cable Operator can offer native IPv6 services to 1058 its customers since the cable network including the CM/Embedded GWR 1059 and CMTS support IPv6. The ER functionality can be included in the 1060 CMTS or it can exist on a separate router connected to the CMTS 1061 upstream interface. The CM/Embedded GWR acts as a Layer 3 device. 1063 Figure 6.2.2.5 illustrates this deployment scenario 1065 +-----------+ +-------------+ 1066 +-----+ +-----------+ | Cable | | CMTS / Edge | 1067 |Host |---| CM / GWR |----| (HFC) |----| |=> ISP 1068 +-----+ +-----------+ | Network | | Router | Network 1069 +-----------+ +-------------+ 1071 |----------------------------------------------------------| 1072 IPv4/v6 1074 Figure 6.2.2.5 1076 6.2.2.5.1 IPv6 Related Infrastructure Changes 1078 Since the CM/GWR acts as a Layer 3 device, IPv6 can be deployed end- 1079 to-end. In this scenario the following devices have to be upgraded 1080 to dual-stack: Host, CM/GWR and CMTS/ER. 1082 6.2.2.5.2 Addressing 1084 Since the CM/GWR is dual-stack, it can receive an IPv4 or IPv6 1085 address using DHCP for management purposes. As the GWR functionality 1086 is Embedded in the CM, it will need an IPv6 address for forwarding 1087 data traffic. IPv6 address assignment for the CM/GWR and host can be 1088 done via DHCPv6 or DHCP-PD. 1090 If using DHCPv6 the CMTS will need to act as DHCPv6 relay agent. The 1091 host and CM/GWR will receive IPv6 addresses from pools of /64 1092 prefixes configured on the DHCPv6 server. The CMTS will need to 1093 glean pertinent information from the DHCP Offer messages, sent from 1094 the DHCP server to the DHCP clients (host and CM/GWR), much like it 1095 does today in DHCPv4. All CM/GWR connected to the same cable 1096 interface on the CMTS belong to same management /64 prefix. The 1097 hosts connected to the same cable interface on the CMTS may belong to 1098 different /64 customer prefixes as the CMTS may have multiple /64 1099 prefixes configured under its cable interfaces. 1101 It is also possible to use DHCP-PD for IPv6 address assignment. In 1102 this case the CM/GWR will use stateless auto-configuration to assign 1103 an IPv6 address to its upstream interface using the /64 prefix sent 1104 by the CMTS/ER in RA message. Once the CM/GWR assigns an IPv6 1105 address to its upstream interface it will request a /48 [8] prefix 1106 from the CMTS/ER and chop this /48 prefix into /64s for assigning 1107 IPv6 addresses to hosts. Currently the DHCP-PD functionality cannot 1108 be implemented if the DHCP-PD server is not the Edge Router. If the 1109 DHCP-PD messages are relayed, the Edge Router does not have a 1110 mechanism to learn the assigned prefixes and thus install the proper 1111 routes to make that prefix reachable. Work is being done to address 1112 this issue, one idea being to provide the Edge Router with a snooping 1113 mechanism. The uplink to the ISP network is configured with a /64 1114 prefix as well. 1116 6.2.2.5.3 Data Forwarding 1118 The host will use the CM/GWR as the Layer 3 next hop. The CM/GWR 1119 will forward all IPv6 traffic to/from the CMTS/ER and hosts. The 1120 CMTS/ER will forward IPv6 traffic to/from hosts based on the IP 1121 source/destination address. 1123 6.2.2.5.4 Routing 1125 The CM/GWR can use a static default route pointing to the CMTS/ER or 1126 it can run a routing protocol such as RIP-ng or OSPFv3 between itself 1127 and the CMTS. Customer routes from behind the CM/GWR can be carried 1128 to the CMTS using routing updates. 1130 If DHCP-PD is used for address assignment a static route is 1131 automatically installed on the CMTS/ER for each delegated /48 prefix. 1132 The static routes need to be redistributed into the IGP at the 1133 CMTS/ER so there is no need for a routing protocol between the 1134 CMTS/ER and the GWR. 1136 If the CMTS is also acting as an ER, it runs an IGP such as OSPFv3 or 1137 ISIS. 1139 6.2.3 IPv6 Multicast 1141 In order to support IPv6 multicast applications across DOCSIS cable 1142 networks, the CM and bridging CMTS will need to support IGMPv3/MLDv2 1143 or v1 snooping. MLD is almost identical to IGMP in IPv4, only the 1144 name and numbers are changed. MLDv2 is almost identical to IGMPv3 1145 and also supports ASM (Any Source Multicast) and SSM (Single Source 1146 Multicast) service models. 1148 SSM is more suited for deployments where the SP intends to provide 1149 paid content to the users (Video or Audio). This type of services 1150 are expected to be of primary interest. Moreover, the simplicity of 1151 the SSM model often times override the scalability issues that would 1152 be resolved in an ASM model. ASM is however an option that is 1153 discussed in section 7.3.1. The Layer 3 CM, GWR and Layer 3 routed 1154 CMTS/ER will need to be enabled with PIM-SSM, which requires the 1155 definition and support for IGMPv3/MLDv1 or v2 snooping, in order to 1156 track join/leave messages from the hosts. Another option would be 1157 for the Layer 3 CM or GWR to support MLD proxy routing. The Layer 3 1158 next hop for the hosts needs to support MLD. 1160 Please refer to section 7.3 for more IPv6 multicast details. 1162 6.2.4 IPv6 QoS 1164 IPv6 will not change or add any queuing/scheduling functionality 1165 already existing in DOCSIS specifications. But the QoS mechanisms on 1166 the CMTS and CM would need to be IPv6 capable. This includes support 1167 for IPv6 classifiers, so that data traffic to/from host devices can 1168 be classified appropriately into different service flows and be 1169 assigned appropriate priority. Appropriate classification criteria 1170 would need to be implemented for unicast and multicast traffic. 1172 In order to classify IPv6 traffic the following classifiers would 1173 need to be modified in the DOCSIS specification to support the 128- 1174 bit IPv6 address: 1176 A. IP source address 1178 B. IP source mask 1180 C. IP destination address 1182 D. IP destination mask 1184 E. IP traffic class (DSCP) 1186 The following classifiers would be new for IPv6: 1188 A. IP version 1189 B. Flow label (optional) 1191 Traffic classification and marking should be done at the CM for 1192 upstream traffic and the CMTS/ER for downstream traffic in order to 1193 support the various types of services: data, voice, video. The same 1194 IPv4 QoS concepts and methodologies should be applied for IPv6 as 1195 well. 1197 It is important to note that when traffic is encrypted end-to-end, 1198 the traversed network devices will not have access to many of the 1199 packet fields used for classification purposes. In these cases 1200 routers will most likely place the packets in the default classes. 1201 The QoS design should take into consideration this scenario and try 1202 to use mainly IP header fields for classification purposes. 1204 6.2.5 IPv6 Security Considerations 1206 Security in a DOCSIS cable network is provided using Baseline Privacy 1207 Plus (BPI+). The only part that is dependent on IP addresses is 1208 encrypted multicast. Semantically, multicast encryption would work 1209 the same way in an IPv6 environment as in the IPv4 network. However, 1210 appropriate enhancements will be needed in the DOCSIS specification 1211 to support encrypted IPv6 multicast. 1213 The other aspect of security enhancement is mandated IPSec support in 1214 IPv6. The IPv6 specifications mandate implementation of IPSec, but 1215 they do not mandate its use. The IPv4 specifications do not mandate 1216 IPSec. IPSec is the same for both IPv4 and IPv6, but it still 1217 requires a key distribution mechanism. Cable operators may consider 1218 deploying it end-to-end on IPv6 as there is not an intermediate 1219 device(i.e. NAT). 1221 There are limited changes that have to be done for hosts in order to 1222 enhance security. The Privacy extensions [14] for autoconfiguration 1223 should be used by the hosts. IPv6 firewall functions could be 1224 enabled, if available on the host or GWR. 1226 The ISP provides security against attacks that come form its own 1227 subscribers but it could also implement security services that 1228 protect its subscribers from attacks sourced from the outside of its 1229 network. Such services do not apply at the access level of the 1230 network discussed here. 1232 The CMTS/ER should protect the ISP network and the other subscribers 1233 against attacks by one of its own customers. For this reason Unicast 1234 Reverse Path Forwarding (uRPF) [23] and ACLs should be used on all 1235 interfaces facing subscribers. Filtering should be implemented with 1236 regard for the operational requirements of IPv6 [Security 1237 considerations for IPv6]. 1239 The CMTS/ER should protect its processing resources against floods of 1240 valid customer control traffic such as: Router and Neighbor 1241 Solicitations, MLD Requests. 1243 All other security features used with the IPv4 service should be 1244 similarly applied to IPv6 as well. 1246 6.2.6 IPv6 Network Management 1248 IPv6 can have many applications in Cable Networks. MSOs can 1249 initially implement IPv6 on the control plane and use it to manage 1250 the thousands of devices connected to the CMTS. This would be a good 1251 way to introduce IPv6 in a Cable Network. Later on the MSO can 1252 extend IPv6 to the data plane and use it to carry customer as well as 1253 management traffic. 1255 6.2.6.1 Using IPv6 for Management in Cable Networks 1257 IPv6 can be enabled in a Cable Network for management of devices like 1258 CM, CMTS and ER. With the roll out of advanced services like VoIP 1259 and Video-over-IP, MSOs are looking for ways to manage the large 1260 number of devices connected to the CMTS. In IPv4, an RFC1918 address 1261 is assigned to these devices like CM for management purposes. Since 1262 there is a finite number of RFC1918 addresses available, it is 1263 becoming difficult for MSOs to manage these devices. 1265 By using IPv6 for management purposes, MSOs can scale their network 1266 management systems to meet their needs. The CMTS/ER can be 1267 configured with a /64 management prefix which is shared among all CMs 1268 connected to the CMTS cable interface. Addressing for the CMs can be 1269 done via stateless autoconfiguration. Once the CMs receive the /64 1270 prefix from the CMTS/ER via RA they can configure themselves with an 1271 IPv6 address. 1273 If there are devices behind the CM which need to be managed by the 1274 MSO, another /64 prefix can be defined on the CMTS/ER. These devices 1275 can also use stateless autoconfiguration to assign themselves an IPv6 1276 address. 1278 Traffic sourced from or destined to the management prefix should not 1279 cross the MSO's network boundaries. 1281 In this scenario IPv6 will only be used for managing these devices on 1282 the Cable Network, all data traffic will still be forwarded by the CM 1283 and CMTS/ER using IPv4. 1285 6.2.6.2 Updates to MIBs/Standards to support IPv6 1287 The current DOCSIS, PacketCable, and CableHome MIBs are already 1288 designed to support IPv6 objects. In this case, IPv6 will neither 1289 add, nor change any of the functionality of these MIBs. An object to 1290 identify the IP version, InetAddressType has been added to all the 1291 appropriate SNMP objects related to IP address. 1293 There are some exceptions, the following MIBs might need to add IPv6 1294 support: 1296 On the CMTS 1298 A. DOCS-QOS-MIB 1300 B. DOCS-SUBMGT-MIB (Subscriber Management Interface Specification 1301 ANNEX B) 1303 On the CM 1305 A. DOCS-QOS-MIB 1307 B. DOCS-CABLE-DEVICE-MIB (or [20]) 1309 7. Broadband DSL Networks 1311 This section describes the IPv6 deployment options in today's High 1312 Speed DSL Networks. 1314 7.1 DSL Network Elements 1316 Digital Subscriber Line (DSL) broadband services provide users with 1317 IP connectivity over the existing twisted-pair telephone lines called 1318 the local-loop. A wide range of bandwidth offerings are available 1319 depending on the quality of the line and the distance between the 1320 Customer Premises Equipment and the DSLAM. 1322 The following network elements are typical of a DSL network [ISP 1323 Transition Scenarios]: 1325 DSL Modem: It can be a stand alone device, it can be incorporated in 1326 the host, it can incorporate router functionalities and also have the 1327 capabilities to act as a CPE router. 1329 Customer Premises Router: It is used to provide Layer 3 services for 1330 customer premises networks. It is usually used to provide 1331 firewalling functions and segment broadcast domains for a Small 1332 business. 1334 DSL Access Multiplexer (DSLAM): It terminates multiple twisted pair 1335 telephone lines and provides aggregation to BRAS. 1337 Broadband Remote Access Server (BRAS): It aggregates or terminates 1338 multiple PVC corresponding to the subscriber DSL circuits. 1340 Edge Router (ER): It provides the Layer 3 interface to the ISP 1341 network. 1343 Figure 7.1 depicts all the network elements mentioned 1345 Customer Premises | Network Access Provider |Network Service Provider 1346 CP NAP NSP 1347 +-----+ +------+ +------+ +--------+ 1348 |Hosts|--|Router| +--+ BRAS +---+ Edge | ISP 1349 +-----+ +--+---+ | | | | Router +===> Network 1350 | | +------+ +--------+ 1351 +--+---+ | 1352 | DSL +--+ | 1353 |Modem | | | 1354 +------+ | +-----+ | 1355 +--+ | | 1356 +------+ |DSLAM+--+ 1357 +-----+ | DSL | +--+ | 1358 |Hosts|--+Modem +--+ +-----+ 1359 +-----+ +--+---+ 1360 Figure 7.1 1362 7.2 Deploying IPv6 in IPv4 DSL Networks 1364 There are three main design approaches to providing IPv4 connectivity 1365 over a DSL infrastructure: 1367 1. Point-to-Point Model: Each subscriber connects to the DSLAM over 1368 a twisted pair and is provided with a unique PVC that links it to the 1369 service provider. The PVCs can be terminated at the BRAS or at the 1370 Edge Router. This type of design is not very scalable if the PVCs 1371 are not terminated as close as possible to the DSLAM (at the BRAS). 1372 In this case a large number of layer two circuits has to be 1373 maintained over a significant portion of the network. The layer two 1374 domains can be terminated at the ER in three ways: 1376 A. In a common bridge group with a virtual interface that routes it 1377 out. 1379 B. Enable a Routed Bridged Encapsulation feature, all users could be 1380 part of the same subnet. This is the most common deployment type of 1381 IPv4 over DSL but it might not be the best choice in IPv6 where 1382 address availability is not an issue. 1384 C. Terminate the PVC at Layer 3, each PVC has its own prefix. This 1385 is the approach that seems more suitable for IPv6 and presented in 1386 7.2.1 In none of these cases the CPE (DSL Modem) has to be upgraded. 1388 2. PPP Terminated Aggregation (PTA) Model: PPP sessions are opened 1389 between each subscriber and the BRAS. The BRAS terminates the PPP 1390 sessions and provides Layer 3 connectivity between the subscriber and 1391 the ISP. This model is presented in section 7.2.2. 1393 3. L2TP Access Aggregation (LAA) Model: PPP sessions are opened 1394 between each subscriber and the ISP Edge Router. The BRAS tunnels 1395 the subscriber PPP sessions to the ISP by encapsulating them into 1396 L2TPv2 tunnels. This model is presented in section 7.2.3. 1398 In aggregation models the BRAS terminates the subscriber PVCs and 1399 aggregates their connections before providing access to the ISP. 1401 In order to maintain the deployment concepts and business models 1402 proven and used with existent revenue generating IPv4 services, the 1403 IPv6 deployment will match the IPv4 one. This approach is presented 1404 in sections 7.2.1-3 that describe current IPv4 over DSL broadband 1405 access deployments. Under certain circumstances where new service 1406 types or service needs justify it, IPv4 and IPv6 network logical 1407 architectures could be different as described in section 7.2.4. 1409 7.2.1 Point-to-Point Model 1411 In this scenario the Ethernet frames from the Host or the Customer 1412 Premises Router are bridged over the PVC assigned to the subscriber. 1414 Figure 7.2.1 describes the protocol architecture of this model 1416 Customer Premises NAP NSP 1417 |-------------------------| |---------------| |--------------------| 1419 +-----+ +-------+ +-----+ +--------+ +----------+ 1420 |Hosts|--+Router +--+ DSL +--+ DSLAM +--------+ Edge | ISP 1421 +-----+ +-------+ |Modem| +--------+ | Router +==>Network 1422 +-----+ +----------+ 1423 |----------------------------| 1424 ATM 1425 Figure 7.2.1 1427 7.2.1.1 IPv6 Related Infrastructure Changes 1429 In this scenario the DSL modem and the entire NAP is Layer 3 unaware, 1430 so no changes are needed to support IPv6. The following devices have 1431 to be upgraded to dual stack: Host, Customer Router (if present) and 1432 Edge Router. 1434 7.2.1.2 Addressing 1436 The Hosts or the Customer Routers have the Edge Router as their Layer 1437 3 next hop. 1439 If there is no Customer Router all the hosts on the subscriber site 1440 belong to the same /64 subnet that is statically configured on the 1441 Edge Router for that subscriber PVC. The hosts can use stateless 1442 autoconfiguration or stateful DHCPv6 based configuration to acquire 1443 an address via the Edge Router. 1445 If a Customer Router is present: 1447 A. It is statically configured with an address on the /64 subnet 1448 between itself and the Edge Router, and with /64 prefixes on the 1449 interfaces connecting the hosts on the customer site. This is not a 1450 desired provisioning method being expensive and difficult to manage. 1452 B. It can use its link-local address to communicate with the ER. It 1453 can also dynamically acquire through stateless autoconfiguration the 1454 prefix for the link between itself and the ER. The later option 1455 allows it to contact a remote DHCPv6 server if needed. This step is 1456 followed by a request via DHCP-PD for a prefix shorter than /64 that 1457 in turn is divided in /64s and assigned to its downstream interfaces. 1459 The Edge Router has a /64 prefix configured for each subscriber VLAN. 1460 Each VLAN should be enabled to relay DHCPv6 requests from the 1461 subscribers to DHCPv6 servers in the ISP network. The VLANs 1462 providing access for subscribers that use DHCP-PD as well, have to be 1463 enabled to support the feature. Currently the DHCP-PD functionality 1464 cannot be implemented if the DHCP-PD server is not the Edge Router. 1465 If the DHCP-PD messages are relayed, the Edge Router does not have a 1466 mechanism to learn the assigned prefixes and thus install the proper 1467 routes to make that prefix reachable. Work is being done to address 1468 this issue, one idea being to provide the Edge Router with a snooping 1469 mechanism. The uplink to the ISP network is configured with a /64 1470 prefix as well. 1472 The prefixes used for subscriber links and the ones delegated via 1473 DHCP-PD should be planned in a manner that allows as much 1474 summarization as possible at the Edge Router. 1476 Other information of interest to the host, such as DNS, is provided 1477 through stateful DHCPv6 [11] and stateless DHCPv6 [10]. 1479 7.2.1.3 Routing 1481 The CPE devices are configured with a default route that points to 1482 the Edge router. No routing protocols are needed on these devices 1483 which generally have limited resources. 1485 The Edge Router runs the IPv6 IGP used in the NSP: OSPFv3 or IS-IS. 1486 The connected prefixes have to be redistributed. If DHCP-PD is used, 1487 with every delegated prefix a static route is installed by the Edge 1488 Router. For this reason the static routes must also be 1489 redistributed. Prefix summarization should be done at the Edge 1490 Router. 1492 7.2.2 PPP Terminated Aggregation (PTA) Model 1494 The PTA architecture relies on PPP-based protocols (PPPoA [16] and 1495 PPPoE [15]). The PPP sessions are initiated by Customer Premise 1496 Equipment and are terminated at the BRAS. The BRAS authorizes the 1497 session, authenticates the subscriber, and provides an IP address on 1498 behalf of the ISP. The BRAS then does Layer 3 routing of the 1499 subscriber traffic to the NSP Edge Router. This model is often used 1500 when the NSP is also the NAP. 1502 There are two types of PPP encapsulations that can be leveraged with 1503 this model: 1505 A. Connection using PPPoA 1507 Customer Premises NAP NSP 1508 |--------------------| |----------------------| |-----------------| 1509 +-----------+ 1510 | AAA | 1511 +-------+ Radius | 1512 | | TACACS | 1513 | +-----------+ 1514 | 1515 +-----+ +-------+ +--------+ +----+-----+ +-----------+ 1516 |Hosts|--+Router +------+ DSLAM +-+ BRAS +-+ Edge | 1517 +-----+ +-------+ +--------+ +----------+ | Router +=>Core 1518 +-----------+ 1519 |--------------------------| 1520 PPP 1521 Figure 7.2.2.1 1523 The PPP sessions are initiated by the Customer Premise Equipment. 1524 The BRAS authenticates the subscriber against a local or a remote 1525 database. Once the session is established, the BRAS provides an 1526 address and maybe a DNS server to the user, information acquired from 1527 the subscriber profile or from a DHCP server. 1529 This solution scales better then the Point-to-Point but since there 1530 is only one PPP session per ATM PVC the subscriber can choose a 1531 single ISP service at a time. 1533 B. Connection using PPPoE 1535 Customer Premises NAP NSP 1536 |--------------------------| |-------------------| |--------------| 1537 +-----------+ 1538 | AAA | 1539 +-------+ Radius | 1540 | | TACACS | 1541 | +-----------+ 1542 | 1543 +-----+ +-------+ +--------+ +----+-----+ +-----------+ 1544 |Hosts|--+Router +----------+ DSLAM +-+ BRAS +-+ Edge | C 1545 +-----+ +-------+ +--------+ +----------+ | Router +=>O 1546 | | R 1547 +-----------+ E 1548 |-------------------------------| 1549 PPP 1550 Figure 7.2.2.2 1552 The operation of PPPoE is similar to PPPoA with the exception that 1553 with PPPoE multiple sessions can be supported over the same PVC thus 1554 allowing the subscriber to connect to multiple services at the same 1555 time. The hosts can initiate the PPPoE sessions as well. It is 1556 important to remember that the PPPoE encapsulation reduces the IP MTU 1557 available for the customer traffic due to additional headers. 1559 The network design and operation of the PTA model is the same 1560 regardless of the PPP encapsulation type used. 1562 7.2.2.1 IPv6 Related Infrastructure Changes 1564 In this scenario the BRAS is Layer 3 aware and it has to be upgraded 1565 to support IPv6. Since the BRAS terminates the PPP sessions it has 1566 to support the implementation of these PPP protocols with IPv6. The 1567 following devices have to be upgraded to dual stack: Host, Customer 1568 Router (if present), BRAS and Edge Router. 1570 7.2.2.2 Addressing 1572 The BRAS terminates the PPP sessions and provides the subscriber with 1573 an IPv6 address from the defined pool for that profile. The 1574 subscriber profile for authorization and authentication can be 1575 located on the BRAS or on a AAA server. The Hosts or the Customer 1576 Routers have the BRAS as their Layer 3 next hop. 1578 The PPP session can be initiated by a host or by a Customer Router. 1579 In the latter case, once the session is established with the BRAS and 1580 an address is negotiated for the uplink to the BRAS, DHCP-PD can be 1581 used to acquire prefixes for the Customer Router other interfaces. 1583 The BRAS has to be enabled to support DHCP-PD and to relay the DHCPv6 1584 requests of the hosts on the subscriber sites. 1586 The BRAS has a /64 prefixes configured on the link to the Edge 1587 router. The Edge router links are also configured with /64 prefixes 1588 to provide connectivity to the rest of the ISP network. 1590 The prefixes used for subscriber and the ones delegated via DHCP-PD 1591 should be planned in a manner that allows maximum summarization at 1592 the BRAS. 1594 Other information of interest to the host, such as DNS, is provided 1595 through stateful [11] and stateless [10] DHCPv6. 1597 7.2.2.3 Routing 1599 The CPE devices are configured with a default route that points to 1600 the BRAS router. No routing protocols are needed on these devices 1601 which generally have limited resources. 1603 The BRAS runs an IGP to the Edge Router: OSPFv3 or IS-IS. Since the 1604 addresses assigned to the PPP sessions are represented as connected 1605 host routes, connected prefixes have to be redistributed. If DHCP-PD 1606 is used, with every delegated prefix a static route is installed by 1607 the Edge Router. For this reason the static routes must also be 1608 redistributed. Prefix summarization should be done at the BRAS. 1610 The Edge Router is running the IGP used in the ISP network: OSPFv3 or 1611 IS-IS. 1613 A separation between the routing domains of the ISP and the Access 1614 Provider is recommended if they are managed independently. 1615 Controlled redistribution will be needed between the Access Provider 1616 IGP and the ISP IGP. 1618 7.2.3 L2TPv2 Access Aggregation (LAA) Model 1620 In the LAA model the BRAS forwards the CPE initiated session to the 1621 ISP over an L2TPv2 tunnel established between the BRAS and the Edge 1622 Router. In this case the authentication, authorization and 1623 subscriber configuration are performed by the ISP itself. There are 1624 two types of PPP encapsulations that can be leveraged with this 1625 model: 1627 A. Connection via PPPoA 1629 Customer Premises NAP NSP 1630 |--------------------| |----------------------| |-----------------| 1631 +-----------+ 1632 | AAA | 1633 +-------+ Radius | 1634 | | TACACS | 1635 | +-----+-----+ 1636 | | 1637 +-----+ +-------+ +--------+ +----+-----+ +-----+-----+ 1638 |Hosts|--+Router +------+ DSLAM +-+ BRAS +-+ Edge | 1639 +-----+ +-------+ +--------+ +----------+ | Router +=>Core 1640 +-----------+ 1641 |----------------------------------------| 1642 PPP 1643 |------------| 1644 L2TPv2 1645 Figure 7.2.3.1 1647 B. Connection via PPPoE 1649 Customer Premises NAP NSP 1650 |-------------------------| |--------------------| |--------------| 1651 +-----------+ 1652 | AAA | 1653 +------+ Radius | 1654 | | TACACS | 1655 | +-----+-----+ 1656 | | 1657 +-----+ +-------+ +--------+ +----+-----+ +----+------+ 1658 |Hosts|--+Router +----------+ DSLAM +-+ BRAS +-+ Edge | C 1659 +-----+ +-------+ +--------+ +----------+ | Router +=>O 1660 | | R 1661 +-----------+ E 1662 |---------------------------------------------| 1663 PPP 1664 |------------| 1665 L2TPv2 1666 Figure 7.2.3.2 1668 The network design and operation of the PTA model is the same 1669 regardless of the PPP encapsulation type used. 1671 7.2.3.1 IPv6 Related Infrastructure Changes 1673 In this scenario the BRAS is forwarding the PPP sessions initiated by 1674 the subscriber over the L2TPv2 tunnel established to the LNS, the 1675 aggregation point in the ISP network. The L2TPv2 tunnel between the 1676 LAC and LNS could run over IPv6 or IPv4. These capabilities have to 1677 be supported on the BRAS. The following devices have to be upgraded 1678 to dual stack: Host, Customer Router and Edge Router. If the tunnel 1679 is set up over IPv6 then the BRAS must be upgraded to dual stack. 1681 7.2.3.2 Addressing 1683 The Edge router terminates the PPP sessions and provides the 1684 subscriber with an IPv6 address from the defined pool for that 1685 profile. The subscriber profile for authorization and authentication 1686 can be located on the Edge Router or on a AAA server. The Hosts or 1687 the Customer Routers have the Edge Router as their Layer 3 next hop. 1689 The PPP session can be initiated by a host or by a Customer Router. 1690 In the latter case, once the session is established with the Edge 1691 Router, DHCP-PD can be used to acquire prefixes for the Customer 1692 Router interfaces. The Edge Router has to be enabled to support 1693 DHCP-PD and to relay the DHCPv6 requests generated by the hosts on 1694 the subscriber sites. 1696 The BRAS has a /64 prefix configured on the link to the Edge router. 1697 The Edge router links are also configured with /64 prefixes to 1698 provide connectivity to the rest of the ISP network. Other 1699 information of interest to the host, such as DNS, is provided through 1700 stateful [11] and stateless [10] DHCPv6. 1702 It is important to note here a significant difference between this 1703 deployment for IPv6 versus IPv4. In the case of IPv4 the customer 1704 router or CPE can end up on any Edge Router (acting as LNS) where the 1705 assumption is that there are at least two of them for redundancy 1706 purposes. Once authenticated, the customer will be given an address 1707 from the IP pool of the ER (LNS) it connected to. This allows the 1708 ERs (LNSs) to aggregate the addresses handed out to the customers. 1709 In the case of IPv6, an important constraint that likely will be 1710 enforced is that the customer should keep its own address regardless 1711 of the ER (LNS) it connects to. This could significantly reduce the 1712 prefix aggregation capabilities of the ER (LNS). This is different 1713 than the current IPv4 deployment where addressing is dynamic in 1714 nature and the same user can get different addresses depending on the 1715 LNS it ends up connecting to. 1717 One possible solution is to ensure that a given BRAS will always 1718 connect to the same ER (LNS) unless that LNS is down. This means 1719 that customers from a given prefix range will always be connected to 1720 the same ER (primary if up or secondary if not). Each ER (LNS) can 1721 carry summary statements in their routing protocol configuration for 1722 the prefixes they are the primary ER (LNS) as well as for the ones 1723 for which they are the secondary. This way the prefixes will be 1724 summarized any time they become "active" on the ER (LNS). 1726 7.2.3.3 Routing 1728 The CPE devices are configured with a default route that points to 1729 the Edge router that terminates the PPP sessions. No routing 1730 protocols are needed on these devices which have generally limited 1731 resources. 1733 The BRAS runs an IPv6 IGP to the Edge Router: OSPFv3 or IS-IS. 1734 Different processes should be used if the NAP and the NSP are managed 1735 by different organizations. In this case, controlled redistribution 1736 should be enabled between the two domains. 1738 The Edge Router is running the IPv6 IGP used in the ISP network: 1739 OSPFv3 or IS-IS. 1741 7.2.4 Hybrid Model for IPv4 and IPv6 Service 1743 It was recommended throughout this section that the IPv6 service 1744 implementation should map the existent IPv4 one. This approach 1745 simplifies manageability and minimizes training needed for personnel 1746 operating the network. In certain circumstances such mapping is not 1747 feasible. This typically becomes the case when a Service Provider 1748 plans to expand its service offering with the new IPv6 deployed 1749 infrastructure. If this new service is not well supported in a 1750 network design such as the one used for IPv4 then a different design 1751 might be used for IPv6. 1753 An example of such circumstances is that of a provider using an LAA 1754 design for its IPv4 services. In this case all the PPP sessions are 1755 bundled and tunneled across the entire NAP infrastructure which is 1756 made of multiple BRAS routers, aggregation routers etc. The end 1757 point of these tunnels is the ISP Edge Router. If the provider 1758 decides to offer multicast services over such a design, it will face 1759 the problem of NAP resources being over utilized. The multicast 1760 traffic can be replicated only at the end of the tunnels by the Edge 1761 router and the copies for all the subscribers are carried over the 1762 entire NAP. 1764 A Modified Point-to-Point (as described in 7.2.4.2) or PTA model are 1765 more suitable to support multicast services because the packet 1766 replication can be done closer to the destination at the BRAS. Such 1767 topology saves NAP resources. 1769 In this sense IPv6 deployment can be viewed as an opportunity to 1770 build an infrastructure that might better support the expansion of 1771 services. In this case, an SP using the LAA design for its IPv4 1772 services might choose a modified Point-to-Point or PTA design for 1773 IPv6. 1775 7.2.4.1 IPv4 in LAA Model and IPv6 in PTA Model 1777 The coexistence of the two PPP based models, PTA and LAA, is 1778 relatively straight forward. The PPP sessions are terminated on 1779 different network devices for the IPv4 and IPv6 services. The PPP 1780 sessions for the existent IPv4 service deployed in an LAA model are 1781 terminated on the Edge Router. The PPP sessions for the new IPv6 1782 service deployed in a PTA model are terminated on the BRAS. 1784 The logical design for IPv6 and IPv4 in this hybrid model is 1785 presented in Figure 7.2.4.1. 1787 IPv6 |--------------------------| 1788 PPP +-----------+ 1789 | AAA | 1790 +-------+ Radius | 1791 | | TACACS | 1792 | +-----+-----+ 1793 | | 1794 +-----+ +-------+ +--------+ +----+-----+ +-----+-----+ 1795 |Hosts|--+Router +------+ DSLAM +-+ BRAS +-+ Edge | 1796 +-----+ +-------+ +--------+ +----------+ | Router +=>Core 1797 +-----------+ 1798 IPv4 |----------------------------------------| 1799 PPP 1800 |------------| 1801 L2TPv2 1802 Figure 7.2.4.1 1804 7.2.4.2 IPv4 in LAA Model and IPv6 in Modified Point-to-Point Model 1806 In this particular scenario the Point-to-Point model used for the 1807 IPv6 service is a modified version of the model described in section 1808 7.2.1. 1810 For the IPv4 service in LAA model, the VLANs are terminated on the 1811 BRAS and PPP sessions are terminated on the Edge Router (LNS). For 1812 IPv6 service in Point-to-Point model, the VLANs are terminated at the 1813 Edge Router as described in section 7.2.1. In this hybrid model, the 1814 Point-to-Point link could be terminated on the BRAS, a NAP owned 1815 device. The IPv6 traffic is then routed through the NAP network to 1816 the NSP. In order to have this hybrid model, the BRAS has to be 1817 upgraded to a dual-stack router. The functionalities of the Edge 1818 Router as described in section 7.2.1 are now implemented on the BRAS. 1820 The other aspect of this deployment model is the fact that the BRAS 1821 has to be capable of distinguishing between the IPv4 PPP traffic that 1822 has to be bridged across the L2TPv2 tunnel and the IPv6 packets that 1823 have to be routed to the NSP. The IPv6 Routing and Bridging 1824 Encapsulation (RBE) has to be enabled on all interfaces with VLANs 1825 supporting both IPv4 and IPv6 services in this hybrid design. 1827 The logical design for IPv6 and IPv4 in this hybrid model is 1828 presented in Figure 7.2.4.2. 1830 IPv6 |----------------| 1831 ATM +-----------+ 1832 | AAA | 1833 +-------+ Radius | 1834 | | TACACS | 1835 | +-----+-----+ 1836 | | 1837 +-----+ +-------+ +--------+ +----+-----+ +-----+-----+ 1838 |Hosts|--+Router +------+ DSLAM +-+ BRAS +-+ Edge | 1839 +-----+ +-------+ +--------+ +----------+ | Router +=>Core 1840 +-----------+ 1841 IPv4 |----------------------------------------| 1842 PPP 1843 |------------| 1844 L2TPv2 1845 Figure 7.2.4.2 1847 7.3 IPv6 Multicast 1849 The deployment of IPv6 multicast services relies on MLD, identical to 1850 IGMP in IPv4 and on PIM for routing. ASM (Any Source Multicast) and 1851 SSM (Single Source Multicast) service models operate almost the same 1852 as in IPv4. Both have the same benefits and disadvantages as in 1853 IPv4. Nevertheless, the larger address space and the scoped address 1854 architecture provide major benefits for multicast IPv6. Through 1855 RFC3306 the large address space provides the means to assign global 1856 multicast group addresses to organizations or users that were 1857 assigned unicast prefixes. It is a significant improvement with 1858 respect to the IPv4 GLOP mechanism [19]. 1860 This facilitates the deployment of multicast services. The 1861 discussion of this section applies to all the multicast sections in 1862 the document. 1864 7.3.1 ASM Based Deployments 1866 Any Source Multicast (ASM) is useful for Service Providers that 1867 intend to support the forwarding of multicast traffic of their 1868 customers. It is based on the PIM-SM protocol and it is more complex 1869 to manage because of the use of Rendezvous Points (RPs). With IPv6, 1870 static RP and BSR [34] can be used for RP-to-group mapping similar to 1871 IPv4. Additionally, the larger IPv6 address space allows for 1872 building up of group addresses that incorporate the address of the 1873 RP. This RP-to-group mapping mechanism is called Embedded RP and is 1874 specific to IPv6. 1876 In inter-domain deployments, Multicast Source Discovery Protocol 1877 (MSDP) [22] is an important element of IPv4 PIM-SM deployments. MSDP 1878 is meant to be a solution for the exchange of source registration 1879 information between RPs in different domains. This solution was 1880 intended to be temporary. This is one of the reasons why it was 1881 decided not to implement MSDP in IPv6 [32]. 1883 For multicast reachability across domains, Embedded RP could be used. 1884 Despite its shortcomings, MSDP provides additional flexibility in 1885 managing the domains that may not be matched with the protocols 1886 available in IPv6 today. The value of such flexibility is still 1887 under evaluation. 1889 7.3.2 SSM Based Deployments 1891 Based on PIM-SSM, the Source Specific Multicast deployments do not 1892 need an RP and the related protocols (such as BSR or MSDP) but rely 1893 on the listeners to know the source of the multicast traffic they 1894 plan to receive. The lack of RP makes SSM not only simpler to 1895 operate but also robust, it is not impacted by RP failures or inter 1896 domain constraints. It is also has a higher level of security (No RP 1897 to be targeted by attacks). For more discussions on the topic of 1898 IPv6 multicast see [32]. 1900 The typical multicast services offered for residential and very small 1901 businesses is video/audio streaming where the subscriber joins a 1902 multicast group and receives the content. This type of service model 1903 is well supported through PIM-SSM which is very simple and easy to 1904 manage. PIM-SSM has to be enabled throughout the SP network. MLDv2 1905 is required for PIM-SSM support. Vendors can choose to implement 1906 features that allow routers to map MLDv1 group joins to predefined 1907 sources. 1909 Subscribers might use a set-top box that is responsible for the 1910 control piece of the multicast service (does group joins/leaves). 1911 The subscriber hosts can also join desired multicast groups as long 1912 as they are enabled to support MLDv1 or MLDv2. If a customer premise 1913 router is used then it has to be enabled to support MLDv1 and MLDv2 1914 in order to process the requests of the hosts. It has to be enabled 1915 to support PIM-SSM in order to send PIM joins/leaves up to its Layer 1916 3 next hop whether it is the BRAS or the Edge router. When enabling 1917 this functionality on a customer premises router, its limited 1918 resources should be taken into consideration. Another option would 1919 be for the customer premises router to support MLD proxy routing. 1921 The router that is the Layer 3 next hop for the subscriber (BRAS in 1922 the PTA model or the Edge router in the LAA and Point-to-Point model) 1923 has to be enabled to support MLDv1 and MLDv2 in order to process the 1924 requests coming from subscribers without customer premises routers. 1926 It has to be enabled for PIM-SSM in order to receive joins/leaves 1927 from customer routers and send joins/leaves to the next hop towards 1928 the multicast source (Edge router or the NSP core). 1930 MLD authentication, authorization and accounting is usually 1931 configured on the edge router in order to enable the ISP to do 1932 control the subscriber access of the service and do billing for the 1933 content provided. Alternative mechanisms that would support these 1934 functions should be investigated further. 1936 7.4 IPv6 QoS 1938 The QoS configuration is particularly relevant on the router that 1939 represents the Layer 3 next hop for the subscriber (BRAS in the PTA 1940 model or the Edge router in the LAA and Point-to-Point model) in 1941 order to manage resources shared amongst multiple subscribers 1942 possibly with various service level agreements. 1944 In the DSL infrastructure it is expected that there is already a 1945 level of traffic policing and shaping implemented for IPv4 1946 connectivity. This is implemented throughout the NAP and it is 1947 beyond the scope of this document. 1949 On the BRAS or the Edge Router the subscriber facing interfaces have 1950 to be configure to police the inbound customer traffic and shape the 1951 traffic outbound to the customer based on the SLAs. Traffic 1952 classification and marking should also be done on the router closest 1953 (at Layer 3) to the subscriber in order to support the various types 1954 of customer traffic: data, voice, video and to optimally use the 1955 infrastructure resources. Each provider (NAP, NSP) could implement 1956 their own QoS policies and services so reclassification and marking 1957 might be performed at the boundary between the NAP and the NSP in 1958 order to make sure the traffic is properly handled by the ISP. The 1959 same IPv4 QoS concepts and methodologies should be applied with IPv6 1960 as well. 1962 It is important to note that when traffic is encrypted end-to-end, 1963 the traversed network devices will not have access to many of the 1964 packet fields used for classification purposes. In these cases 1965 routers will most likely place the packets in the default classes. 1966 The QoS design should take into consideration this scenario and try 1967 to use mainly IP header fields for classification purposes. 1969 7.5 IPv6 Security Considerations 1971 There are limited changes that have to be done for CPEs in order to 1972 enhance security. The Privacy extensions for auto-configuration [14] 1973 should be used by the hosts. ISPs can track the prefixes it assigns 1974 to subscribers relatively easily. If however the ISPs are required 1975 by regulations to track their users at /128 address level, the 1976 Privacy Extensions can be implemented only in parallel with network 1977 management tools that could provide traceability of the hosts. IPv6 1978 firewall functions should be enabled on the hosts or customer 1979 premises router if present. 1981 The ISP provides security against attacks that come form its own 1982 subscribers but it could also implement security services that 1983 protect its subscribers from attacks sourced from the outside of its 1984 network. Such services do not apply at the access level of the 1985 network discussed here. 1987 The device that is the Layer 3 next hop for the subscribers (BRAS or 1988 Edge router) should protect the network and the other subscribers 1989 against attacks by one of the provider customers. For this reason 1990 uRPF and ACLs should be used on all interfaces facing subscribers. 1991 Filtering should be implemented with regard for the operational 1992 requirements of IPv6 [36]. Authentication and authorization should 1993 be used wherever possible. 1995 The BRAS and the Edge Router should protect their processing 1996 resources against floods of valid customer control traffic such as: 1997 Router and Neighbor Solicitations, MLD Requests. Rate limiting 1998 should be implemented on all subscriber facing interfaces. The 1999 emphasis should be placed on multicast type traffic as it is most 2000 often used by the IPv6 control plane. 2002 All other security features used with the IPv4 service should be 2003 similarly applied to IPv6 as well. 2005 7.6 IPv6 Network management 2007 The necessary instrumentation (such as MIBs, NetFlow Records etc) 2008 should be available for IPv6. 2010 Usually, NSPs manage the edge routers by SNMP. The SNMP transport 2011 can be done over IPv4 if all managed devices have connectivity over 2012 both IPv4 and IPv6. This would imply the smallest changes to the 2013 existent network management practices and processes. Transport over 2014 IPv6 could also be implemented and it might become necessary if IPv6 2015 only islands are present in the network. The management stations are 2016 located on the core network. Network Management Applications should 2017 handle IPv6 in a similar fashion to IPv4, however, they should also 2018 support features specific to IPv6 (such as Neighbor monitoring). 2020 In some cases service providers manage equipment located on customers 2021 LANs. The management of equipment at customers' LANs is out of scope 2022 of this memo. 2024 8. Broadband Ethernet Networks 2026 This section describes the IPv6 deployment options in currently 2027 deployed Broadband Ethernet Access Networks. 2029 8.1 Ethernet Access Network Elements 2031 In environments that support the infrastructure deploying RJ-45 or 2032 fiber (Fiber to the Home (FTTH) service) to subscribers, 10/100 Mbps 2033 Ethernet broadband services can be provided. Such services are 2034 generally available in metropolitan areas, in multi tenant buildings 2035 where an Ethernet infrastructure can be deployed in a cost effective 2036 manner. In such environments Metro-Ethernet services can be used to 2037 provide aggregation and uplink to a Service Provider. 2039 The following network elements are typical of an Ethernet network: 2041 Access Switch: It is used as a Layer 2 access device for subscribers. 2043 Customer Premises Router: It is used to provide Layer 3 services for 2044 customer premises networks. 2046 Aggregation Ethernet Switches: Aggregates multiple subscribers. 2048 Broadband Remote Access Server (BRAS) 2050 Edge Router (ER) 2052 Figure 8.1 depicts all the network elements mentioned. 2054 Customer Premises | Network Access Provider |Network Service Provider 2055 CP NAP NSP 2057 +-----+ +------+ +------+ +--------+ 2058 |Hosts|--|Router| +-+ BRAS +---+ Edge | ISP 2059 +-----+ +--+---+ | | | | Router +===> Network 2060 | | +------+ +--------+ 2061 +--+-----+ | 2062 |Access +-+ | 2063 |Switch | | | 2064 +--------+ | +------+ | 2065 +--+Agg E | | 2066 +--------+ |Switch+-+ 2067 +-----+ |Access | +--+ | 2068 |Hosts|--+Switch +-+ +------+ 2069 +-----+ +--------+ 2070 Figure 8.1 2072 The logical topology and design of Broadband Ethernet Networks is 2073 very similar to DSL Broadband Networks discussed in section 7. 2075 It is worth noting that the general operation, concepts and 2076 recommendations described in this section apply similarly to a 2077 HomePNA based network environment. In such an environment some of 2078 the network elements might be differently named. 2080 8.2 Deploying IPv6 in IPv4 Broadband Ethernet Networks 2082 There are three main design approaches to providing IPv4 connectivity 2083 over an Ethernet infrastructure: 2085 A. Point-to-Point Model: Each subscriber connects to the network 2086 Access switch over RJ-45 or fiber links. Each subscriber is assigned 2087 a unique VLAN on the access switch. The VLAN can be terminated at 2088 the BRAS or at the Edge Router. The VLANs are 802.1q trunked to the 2089 Layer 3 device (BRAS or Edge Router). 2091 This model is presented in section 8.2.1. 2093 B. PPP Terminated Aggregation (PTA) Model: PPP sessions are opened 2094 between each subscriber and the BRAS. The BRAS terminates the PPP 2095 sessions and provides Layer 3 connectivity between the subscriber and 2096 the ISP. 2098 This model is presented in section 8.2.2. 2100 C. L2TPv2 Access Aggregation (LAA) Model: PPP sessions are opened 2101 between each subscriber and the ISP termination devices. The BRAS 2102 tunnels the subscriber PPP sessions to the ISP by encapsulating them 2103 into L2TPv2 tunnels. 2105 This model is presented in section 8.2.3. 2107 In aggregation models the BRAS terminates the subscriber VLANs and 2108 aggregates their connections before providing access to the ISP. 2110 In order to maintain the deployment concepts and business models 2111 proven and used with existent revenue generating IPv4 services, the 2112 IPv6 deployment will match the IPv4 one. This approach is presented 2113 in sections 8.2.1-3 that describe currently deployed IPv4 over 2114 Ethernet broadband access deployments. Under certain circumstances 2115 where new service types or service needs justify it, IPv4 and IPv6 2116 network architectures could be different as described in section 2117 8.2.4. 2119 8.2.1 Point-to-Point Model 2121 In this scenario the Ethernet frames from the Host or the Customer 2122 Premises Router are bridged over the VLAN assigned to the subscriber. 2124 Figure 8.2.1 describes the protocol architecture of this model. 2126 | Customer Premises | | NAP | NSP | 2128 +-----+ +------+ +------+ +--------+ +----------+ 2129 |Hosts|--+Router+--+Access+--+ Switch +--------+ Edge | ISP 2130 +-----+ +------+ |Switch| +--------+ 802.1q | Router +==>Network 2131 +------+ +----------+ 2133 |----------------------------| 2134 Ethernet/VLANs 2136 Figure 8.2.1 2138 8.2.1.1 IPv6 Related Infrastructure Changes 2140 In this scenario the Access Switch on the customer site and the 2141 entire NAP is Layer 3 unaware so no changes are needed to support 2142 IPv6. The following devices have to be upgraded to dual stack: Host, 2143 Customer Router and Edge Router. 2145 The Access switches might need upgrades to support certain IPv6 2146 related features such as MLD Snooping. 2148 8.2.1.2 Addressing 2150 The Hosts or the Customer Routers have the Edge Router as their Layer 2151 3 next hop. If there is no Customer Router all the hosts on the 2152 subscriber site belong to the same /64 subnet that is statically 2153 configured on the Edge Router for that subscriber VLAN. The hosts 2154 can use stateless autoconfiguration or stateful DHCPv6 based 2155 configuration to acquire an address via the Edge Router. 2157 If a Customer Router is present: 2159 A. It is statically configured with an address on the /64 subnet 2160 between itself and the Edge Router, and with /64 prefixes on the 2161 interfaces connecting the hosts on the customer site. This is not a 2162 desired provisioning method being expensive and difficult to manage. 2164 B. It can use its link-local address to communicate with the ER. It 2165 can also dynamically acquire through stateless autoconfiguration the 2166 address for the link between itself and the ER. This step is 2167 followed by a request via DHCP-PD for a prefix shorter than /64 that 2168 in turn is divided in /64s and assigned to its interfaces connecting 2169 the hosts on the customer site. 2171 The Edge Router has a /64 prefix configured for each subscriber VLAN. 2172 Each VLAN should be enabled to relay DHCPv6 requests from the 2173 subscribers to DHCPv6 servers in the ISP network. The VLANs 2174 providing access for subscribers that use DHCP-PD as well, have to be 2175 enabled to support the feature. Currently the DHCP-PD functionality 2176 cannot be implemented if the DHCP-PD server is not the Edge Router. 2177 If the DHCP-PD messages are relayed, the Edge Router does not have a 2178 mechanism to learn the assigned prefixes and thus install the proper 2179 routes to make that prefix reachable. Work is being done to address 2180 this issue, one idea being to provide the Edge Router with a snooping 2181 mechanism. The uplink to the ISP network is configured with a /64 2182 prefix as well. The uplink to the ISP network is configured with a 2183 /64 prefix as well. 2185 The prefixes used for subscriber links and the ones delegated via 2186 DHCP-PD should be planned in a manner that allows as much 2187 summarization as possible at the Edge Router. 2189 Other information of interest to the host, such as DNS, is provided 2190 through stateful [11] and stateless [10] DHCPv6. 2192 8.2.1.3 Routing 2194 The CPE devices are configured with a default route that points to 2195 the Edge router. No routing protocols are needed on these devices 2196 which generally have limited resources. 2198 The Edge Router runs the IPv6 IGP used in the NSP: OSPFv3 or IS-IS. 2199 The connected prefixes have to be redistributed. If DHCP-PD is used, 2200 with every delegated prefix a static route is installed by the Edge 2201 Router. For this reason the static routes must also be 2202 redistributed. Prefix summarization should be done at the Edge 2203 Router. 2205 8.2.2 PPP Terminated Aggregation (PTA) Model 2207 The PTA architecture relies on PPP-based protocols (PPPoE). The PPP 2208 sessions are initiated by Customer Premise Equipment and it is 2209 terminated at the BRAS. The BRAS authorizes the session, 2210 authenticates the subscriber, and provides an IP address on behalf of 2211 the ISP. The BRAS then does Layer 3 routing of the subscriber 2212 traffic to the NSP Edge Router. This model is often used when the 2213 NSP is also the NAP. The PPPoE logical diagram in an Ethernet 2214 Broadband Network is shown in Fig 8.2.2.1. 2216 | Customer Premises | | NAP | | NSP | 2218 +-----------+ 2219 | AAA | 2220 +-----+ Radius | 2221 | | TACACS | 2222 | +-----------+ 2223 +-----+ +-------+ +--------+ +--------+ +----+---+ +-----------+ 2224 |Hosts|--+Router +-+A Switch+-+ Switch +-+ BRAS +-+ Edge | C 2225 +-----+ +-------+ +--------+ +--------+ +--------+ | Router +=>O 2226 |---------------- PPP ----------------| | | R 2227 +-----------+ E 2228 Figure 8.2.2.1 2230 The PPP sessions are initiated by the Customer Premise Equipment 2231 (Host or Router). The BRAS authenticates the subscriber against a 2232 local or a remote database. Once the session is established, the 2233 BRAS provides an address and maybe a DNS server to the user, 2234 information acquired from the subscriber profile or from a DHCP 2235 server. 2237 This model allows for multiple PPPoE sessions to be supported over 2238 the same VLAN thus allowing the subscriber to connect to multiple 2239 services at the same time. The hosts can initiate the PPPoE sessions 2240 as well. It is important to remember that the PPPoE encapsulation 2241 reduces the IP MTU available for the customer traffic. 2243 8.2.2.1 IPv6 Related Infrastructure Changes 2245 In this scenario the BRAS is Layer 3 aware and it has to be upgraded 2246 to support IPv6. Since the BRAS terminates the PPP sessions it has 2247 to support PPPoE with IPv6. The following devices have to be 2248 upgraded to dual stack: Host, Customer Router (if present), BRAS and 2249 Edge Router. 2251 8.2.2.2 Addressing 2253 The BRAS terminates the PPP sessions and provides the subscriber with 2254 an IPv6 address from the defined pool for that profile. The 2255 subscriber profile for authorization and authentication can be 2256 located on the BRAS or on a AAA server. The Hosts or the Customer 2257 Routers have the BRAS as their Layer 3 next hop. 2259 The PPP session can be initiated by a host or by a Customer Router. 2260 In the latter case, once the session is established with the BRAS, 2261 DHCP-PD can be used to acquire prefixes for the Customer Router 2262 interfaces. The BRAS has to be enabled to support DHCP-PD and to 2263 relay the DHCPv6 requests of the hosts on the subscriber sites. 2264 Currently the DHCP-PD functionality cannot be implemented if the 2265 DHCP-PD server is not the Edge Router. If the DHCP-PD messages are 2266 relayed, the Edge Router does not have a mechanism to learn the 2267 assigned prefixes and thus install the proper routes to make that 2268 prefix reachable. Work is being done to address this issue, one idea 2269 being to provide the Edge Router with a snooping mechanism. The 2270 uplink to the ISP network is configured with a /64 prefix as well. 2272 The BRAS has a /64 prefix configured on the link facing the Edge 2273 router. The Edge router links are also configured with /64 prefixes 2274 to provide connectivity to the rest of the ISP network. 2276 The prefixes used for subscriber and the ones delegated via DHCP-PD 2277 should be planned in a manner that allows maximum summarization at 2278 the BRAS. 2280 Other information of interest to the host, such as DNS, is provided 2281 through stateful [11] and stateless [10] DHCPv6. 2283 8.2.2.3 Routing 2285 The CPE devices are configured with a default route that points to 2286 the BRAS router. No routing protocols are needed on these devices 2287 which generally have limited resources. 2289 The BRAS runs an IGP to the Edge Router: OSPFv3 or IS-IS. Since the 2290 addresses assigned to the PPP sessions are represented as connected 2291 host routes, connected prefixes have to be redistributed. If DHCP-PD 2292 is used, with every delegated prefix a static route is installed by 2293 the BRAS. For this reason the static routes must also be 2294 redistributed. Prefix summarization should be done at the BRAS. 2296 The Edge Router is running the IGP used in the ISP network: OSPFv3 or 2297 IS-IS. A separation between the routing domains of the ISP and the 2298 Access Provider is recommended if they are managed independently. 2299 Controlled redistribution will be needed between the Access Provider 2300 IGP and the ISP IGP. 2302 8.2.3 L2TPv2 Access Aggregation (LAA) Model 2304 In the LAA model the BRAS forwards the CPE initiated session to the 2305 ISP over an L2TPv2 tunnel established between the BRAS and the Edge 2306 Router. In this case the authentication, authorization and 2307 subscriber configuration are performed by the ISP itself. 2309 | Customer Premises | | NAP | | NSP | 2311 +----------+ 2312 | AAA | 2313 +-----+ Radius | 2314 | | TACACS | 2315 | +----+-----+ 2316 | | 2317 +-----+ +-------+ +--------+ +--------+ +----+----+ +----------+ 2318 |Hosts|--+Router +-+A Switch+-+ Switch +-+ BRAS +-+ Edge | C 2319 +-----+ +-------+ +--------+ +--------+ +---------+ | Router +=>O 2320 | | R 2321 +----------+ E 2322 |---------------------------------------------| 2323 PPP 2324 |------------| 2325 L2TPv2 2326 Figure 8.2.3.1 2328 8.2.3.1 IPv6 Related Infrastructure Changes 2330 In this scenario the BRAS is Layer 3 aware and it has to be upgraded 2331 to support IPv6. The PPP sessions initiated by the subscriber are 2332 forwarded over the L2TPv2 tunnel to the aggregation point in the ISP 2333 network. The BRAS (LAC) can aggregate IPv6 PPP sessions and tunnel 2334 them to the LNS using L2TPv2. The L2TPv2 tunnel between the LAC and 2335 LNS could run over IPv6 or IPv4. These capabilities have to be 2336 supported on the BRAS. The following devices have to be upgraded to 2337 dual stack: Host, Customer Router (if present), BRAS and Edge Router. 2339 8.2.3.2 Addressing 2341 The Edge router terminates the PPP sessions and provides the 2342 subscriber with an IPv6 address from the defined pool for that 2343 profile. The subscriber profile for authorization and authentication 2344 can be located on the Edge Router or on a AAA server. The Hosts or 2345 the Customer Routers have the Edge Router as their Layer 3 next hop. 2347 The PPP session can be initiated by a host or by a Customer Router. 2348 In the latter case, once the session is established with the Edge 2349 Router and an IPv6 address is assigned to the Customer Router by the 2350 Edge router, DHCP-PD can be used to acquire prefixes for the Customer 2351 Router other interfaces. The Edge Router has to be enabled to 2352 support DHCP-PD and to relay the DHCPv6 requests of the hosts on the 2353 subscriber sites. Currently the DHCP-PD functionality cannot be 2354 implemented if the DHCP-PD server is not the Edge Router. If the 2355 DHCP-PD messages are relayed, the Edge Router does not have a 2356 mechanism to learn the assigned prefixes and thus install the proper 2357 routes to make that prefix reachable. Work is being done to address 2358 this issue, one idea being to provide the Edge Router with a snooping 2359 mechanism. The uplink to the ISP network is configured with a /64 2360 prefix as well. 2362 The BRAS has a /64 prefix configured on the link to the Edge router. 2363 The Edge router links are also configured with /64 prefixes to 2364 provide connectivity to the rest of the ISP network. 2366 Other information of interest to the host, such as DNS, is provided 2367 through stateful [11] and stateless [10] DHCPv6. 2369 The address assignment and prefix summarization issues discussed in 2370 section 7.2.3.2 are relevant in the same way for this media access 2371 type as well. 2373 8.2.3.3 Routing 2375 The CPE devices are configured with a default route that points to 2376 the Edge router that terminates the PPP sessions. No routing 2377 protocols are needed on these devices which have limited resources. 2379 The BRAS runs an IPv6 IGP to the Edge Router: OSPFv3 or IS-IS. 2380 Different processes should be used if the NAP and the NSP are managed 2381 by different organizations. In this case controlled redistribution 2382 should be enabled between the two domains. 2384 The Edge Router is running the IPv6 IGP used in the ISP network: 2385 OSPFv3 or IS-IS. 2387 8.2.4 Hybrid Model for IPv4 and IPv6 Service 2389 It was recommended throughout this section that the IPv6 service 2390 implementation should map the existent IPv4 one. This approach 2391 simplifies manageability and minimizes training needed for personnel 2392 operating the network. In certain circumstances such mapping is not 2393 feasible. This typically becomes the case when a Service Provider 2394 plans to expand its service offering with the new IPv6 deployed 2395 infrastructure. If this new service is not well supported in a 2396 network design such as the one used for IPv4 then a different design 2397 might be used for IPv6. 2399 An example of such circumstances is that of a provider using an LAA 2400 design for its IPv4 services. In this case all the PPP sessions are 2401 bundled and tunneled across the entire NAP infrastructure which is 2402 made of multiple BRAS routers, aggregation routers etc. The end 2403 point of these tunnels is the ISP Edge Router. If the SP decides to 2404 offer multicast services over such a design, it will face the problem 2405 of NAP resources being over utilized. The multicast traffic can be 2406 replicated only at the end of the tunnels by the Edge router and the 2407 copies for all the subscribers are carried over the entire NAP. 2409 A Modified Point-to-Point (see section 8.2.4.2) or a PTA model is 2410 more suitable to support multicast services because the packet 2411 replication can be done closer to the destination at the BRAS. Such 2412 topology saves NAP resources. 2414 In this sense IPv6 deployments can be viewed as an opportunity to 2415 build an infrastructure that can better support the expansion of 2416 services. In this case, an SP using the LAA design for its IPv4 2417 services might choose a modified Point-to-Point or PTA design for 2418 IPv6. 2420 8.2.4.1 IPv4 in LAA Model and IPv6 in PTA Model 2422 The coexistence of the two PPP based models, PTA and LAA, is 2423 relatively straight forward. It is a straight forward overlap of the 2424 two deployment models. The PPP sessions are terminated on different 2425 network devices for the IPv4 and IPv6 services. The PPP sessions 2426 for the existent IPv4 service deployed in an LAA model are terminated 2427 on the Edge Router. The PPP sessions for the new IPv6 service 2428 deployed in a PTA model are terminated on the BRAS. 2430 The logical design for IPv6 and IPv4 in this hybrid model is 2431 presented in Figure 8.2.4.1. 2433 IPv6 |--------------------------| 2434 PPP +-----------+ 2435 | AAA | 2436 +-------+ Radius | 2437 | | TACACS | 2438 | +-----+-----+ 2439 | | 2440 +-----+ +-------+ +--------+ +----+-----+ +-----+-----+ 2441 |Hosts|--+Router +------+ Switch +-+ BRAS +-+ Edge | 2442 +-----+ +-------+ +--------+ +----------+ | Router +=>Core 2443 +-----------+ 2445 IPv4 |----------------------------------------| 2446 PPP 2447 |------------| 2448 L2TPv2 2449 Figure 8.2.4.1 2451 8.2.4.2 IPv4 in LAA Model and IPv6 in Modified Point-to-Point Model 2453 The coexistence of the modified Point-to-Point and the LAA models 2454 implies a few specific changes. 2456 For the IPv4 service in LAA model, the VLANs are terminated on the 2457 BRAS and PPP sessions are terminated on the Edge Router (LNS). For 2458 IPv6 service in Point-to-Point model, the VLANs are terminated at the 2459 Edge Router as described in section 7.2.1. In this hybrid model, the 2460 Point-to-Point link could be terminated on the BRAS, a NAP owned 2461 device. The IPv6 traffic is then routed through the NAP network to 2462 the NSP. In order to have this hybrid model, the BRAS has to be 2463 upgraded to a dual-stack router. The functionalities of the Edge 2464 Router as described in section 7.2.1 are now implemented on the BRAS. 2466 The logical design for IPv6 and IPv4 in this hybrid model is in 2467 Figure 8.2.4.2. 2469 IPv6 |----------------| 2470 Ethernet 2471 +-----------+ 2472 | AAA | 2473 +-------+ Radius | 2474 | | TACACS | 2475 | +-----+-----+ 2476 | | 2477 +-----+ +-------+ +--------+ +----+-----+ +-----+-----+ 2478 |Hosts|--+Router +------+ Switch +-+ BRAS +-+ Edge | 2479 +-----+ +-------+ +--------+ +----------+ | Router +=>Core 2480 +-----------+ 2481 IPv4 |----------------------------------------| 2482 PPP 2483 |------------| 2484 L2TPv2 2485 Figure 8.2.4.2 2487 8.3 IPv6 Multicast 2489 The typical multicast services offered for residential and very small 2490 businesses is video/audio streaming where the subscriber joins a 2491 multicast group and receives the content. This type of service model 2492 is well supported through PIM-SSM which is very simple and easy to 2493 manage. PIM-SSM has to be enabled throughout the ISP network. MLDv2 2494 is required for PIM-SSM support. Vendors can choose to implement 2495 features that allow routers to map MLDv1 group joins to predefined 2496 sources. 2498 Subscribers might use a set-top box that is responsible for the 2499 control piece of the multicast service (does group joins/leaves). 2500 The subscriber hosts can also join desired multicast groups as long 2501 as they are enabled to support MLDv1 or MLDv2. If a customer premise 2502 router is used then it has to be enabled to support MLDv1 and MLDv2 2503 in order to process the requests of the hosts. It has to be enabled 2504 to support PIM-SSM in order to send PIM joins/leaves up to its Layer 2505 3 next hop whether it is the BRAS or the Edge router. When enabling 2506 this functionality on a customer premises router, its limited 2507 resources should be taken into consideration. Another option would 2508 be for the customer premises router to support MLD proxy routing. 2509 MLD snooping or similar layer two multicast related protocols could 2510 be enabled on the NAP switches. 2512 The router that is the Layer 3 next hop for the subscriber (BRAS in 2513 the PTA model or the Edge router in the LAA and Point-to-Point model) 2514 has to be enabled to support MLDv1 and MLDv2 in order to process the 2515 requests coming from subscribers without customer premises routers. 2517 It has to be enabled for PIM-SSM in order to receive joins/leaves 2518 from customer routers and send joins/leaves to the next hop towards 2519 the multicast source (Edge router or the NSP core). 2521 MLD authentication, authorization and accounting is usually 2522 configured on the edge router in order to enable the ISP to do 2523 control the subscriber access of the service and do billing for the 2524 content provided. Alternative mechanisms that would support these 2525 functions should be investigated further. 2527 Please refer to section 7.3 for more IPv6 multicast details. 2529 8.4 IPv6 QoS 2531 The QoS configuration is particularly relevant on the router that 2532 represents the Layer 3 next hop for the subscriber (BRAS in the PTA 2533 model or the Edge router in the LAA and Point-to-Point model) in 2534 order to manage resources shared amongst multiple subscribers 2535 possibly with various service level agreements. 2537 On the BRAS or the Edge Router the subscriber facing interfaces have 2538 to be configured to police the inbound customer traffic and shape the 2539 traffic outbound to the customer based on the SLAs. Traffic 2540 classification and marking should also be done on the router closest 2541 (at Layer 3) to the subscriber in order to support the various types 2542 of customer traffic: data, voice, video and to optimally use the 2543 network resources. This infrastructure offers a very good 2544 opportunity to leverage the QoS capabilities of Layer two devices. 2545 DiffServ based QoS used for IPv4 should be expanded to IPv6. 2547 Each provider (NAP, NSP) could implement their own QoS policies and 2548 services so reclassification and marking might be performed at the 2549 boundary between the NAP and the NSP in order to make sure the 2550 traffic is properly handled by the ISP. The same IPv4 QoS concepts 2551 and methodologies should be applied for the IPv6 as well. 2553 It is important to note that when traffic is encrypted end-to-end, 2554 the traversed network devices will not have access to many of the 2555 packet fields used for classification purposes. In these cases 2556 routers will most likely place the packets in the default classes. 2557 The QoS design should take into consideration this scenario and try 2558 to use mainly IP header fields for classification purposes. 2560 8.5 IPv6 Security Considerations 2562 There are limited changes that have to be done for CPEs in order to 2563 enhance security. The Privacy extensions [14] for autoconfiguration 2564 should be used by the hosts with the same considerations for host 2565 traceability as discussed in section 7.5. IPv6 firewall functions 2566 should be enabled on the hosts or customer premises router if 2567 present. 2569 The ISP provides security against attacks that come form its own 2570 subscribers but it could also implement security services that 2571 protect its subscribers from attacks sourced from the outside of its 2572 network. Such services do not apply at the access level of the 2573 network discussed here. 2575 If any layer two filters for Ethertypes are in place, the NAP must 2576 permit the IPv6 Ethertype (0X86DD). 2578 The device that is the Layer 3 next hop for the subscribers (BRAS 2579 Edge router) should protect the network and the other subscribers 2580 against attacks by one of the provider customers. For this reason 2581 uRPF and ACLs should be used on all interfaces facing subscribers. 2582 Filtering should be implemented with regard for the operational 2583 requirements of IPv6 [36]. 2585 Authentication and authorization should be used wherever possible. 2587 The BRAS and the Edge Router should protect their processing 2588 resources against floods of valid customer control traffic such as: 2589 Router and Neighbor Solicitations, MLD Requests. Rate limiting 2590 should be implemented on all subscriber facing interfaces. The 2591 emphasis should be placed on multicast type traffic as it is most 2592 often used by the IPv6 control plane. 2594 All other security features used with the IPv4 service should be 2595 similarly applied to IPv6 as well. 2597 8.6 IPv6 Network Management 2599 The necessary instrumentation (such as MIBs, NetFlow Records etc) 2600 should be available for IPv6. 2602 Usually, NSPs manage the edge routers by SNMP. The SNMP transport 2603 can be done over IPv4 if all managed devices have connectivity over 2604 both IPv4 and IPv6. This would imply the smallest changes to the 2605 existent network management practices and processes. Transport over 2606 IPv6 could also be implemented and it might become necessary if IPv6 2607 only islands are present in the network. The management stations are 2608 located on the core network. Network Management Applications should 2609 handle IPv6 in a similar fashion to IPv4 however they should also 2610 support features specific to IPv6 such as Neighbor monitoring. 2612 In some cases service providers manage equipment located on customers 2613 LANs. 2615 9. Wireless LAN 2617 This section provides detailed description of IPv6 deployment and 2618 integration methods in currently deployed wireless LAN (WLAN) 2619 infrastructure. 2621 9.1 WLAN Deployment Scenarios 2623 WLAN enables subscribers to connect to the Internet from various 2624 locations without the restriction of staying indoors. WLAN is 2625 standardized by IEEE 802.11a/b/g. Consideration should be also given 2626 to IEEE 802.16 WiMAX for similar deployment approaches. IEEE 802.11 2627 offers maximum transmission speed from 1 or 2 Mbps, IEEE 802.11b 2628 offers 11 Mbps and IEEE 802.11a offers up to 54 Mbps. 2630 Figure 9.1 describes the current WLAN architecture. 2632 Customer | Access Provider | Service Provider 2633 Premise | | 2635 +------+ +--+ +--------------+ +----------+ +------+ 2636 |WLAN | ---- | | |Access Router/| |Underlying| |Edge | 2637 |Host/ |-(WLAN)-|AP|-|Layer 2 Switch|-|Technology|-|Router|=>SP 2638 |Router| ---- | | | | | | | |Network 2639 +------+ +--+ +--------------+ +----------+ +------+ 2640 | 2641 +------+ 2642 |AAA | 2643 |Server| 2644 +------+ 2645 Figure 9.1 2647 The host should have a wireless network interface card (NIC) in order 2648 to connect to a WLAN network. WLAN is a flat broadcast network and 2649 works in a similar fashion as Ethernet. When hosts initiate a 2650 connection, it is authenticated by the AAA server located at the SP 2651 network. All the authentication parameters (username, password and 2652 etc.) are forwarded by the Access Point (AP) to the AAA server. The 2653 AAA server authenticates the host, once successfully authenticated 2654 the host can send data packets. The AP is located near the host and 2655 acts as a bridge. The AP forwards all the packets coming to/from 2656 host to the Edge Router. The underlying connection between the AP 2657 and Edge Router could be based on any access layer technology such as 2658 HFC/Cable, FTTH, xDSL or etc. 2660 WLANs are based in limited areas known as WiFi Hot Spots. While 2661 users are present in the area covered by the WLAN range, they can be 2662 connected to the Internet given they have a wireless NIC and required 2663 configuration settings in their devices (notebook PCs, PDA or etc.). 2664 Once the user initiates the connection the IP address is assigned by 2665 the SP using DHCPv4. In most of the cases SP assigns limited number 2666 of public IP addresses to the its customer. When the user 2667 disconnects the connection and moves to a new WiFi hot spot, the 2668 above mentioned process of authentication, address assignment and 2669 accessing the Internet is repeated. 2671 There are IPv4 deployments where customers can use WLAN routers to 2672 connect over wireless to their service provider. These deployment 2673 types do not fit in the typical Hot Spot concept but they rather 2674 serve fixed customers. For this reason this section discusses the 2675 WLAN router options as well. In this case, the ISP provides a public 2676 IP address and the WLAN Router assigns private addresses [1] to all 2677 WLAN users. The WLAN Router provides NAT functionality while WLAN 2678 users access the Internet. 2680 While deploying IPv6 in the above mentioned WLAN architecture, there 2681 are three possible scenarios as discussed below. 2683 A. Layer 2 Switch Between AP and Edge Router 2685 B. Access Router Between AP and Edge Router 2687 C. PPP Based Model 2689 9.1.1 Layer 2 Switch Between AP and Edge Router 2691 When a Layer 2 switch is present between AP and Edge Router, the AP 2692 and Layer 2 switch continues to work as a bridge, forwarding IPv4 and 2693 IPv6 packets from WLAN Host/Router to Edge Router and vice versa. 2695 When initiating the connection, the WLAN host is authenticated by the 2696 AAA server located at the SP network. All the parameters related to 2697 authentication (username, password and etc.) are forwarded by the AP 2698 to the AAA server. The AAA server authenticates the WLAN Hosts and 2699 once authenticated and associated successfully with WLAN AP, IPv6 2700 address will be acquired by the WLAN Host. Note the initiation and 2701 authentication process is same as used in IPv4. 2703 Figure 9.1.1 describes the WLAN architecture when Layer 2 Switch is 2704 located between AP and Edge Router. 2706 Customer | Access Provider | Service Provider 2707 Premise | | 2709 +------+ +--+ +--------------+ +----------+ +------+ 2710 |WLAN | ---- | | | | |Underlying| |Edge | 2711 |Host/ |-(WLAN)-|AP|-|Layer 2 Switch|-|Technology|-|Router|=>SP 2712 |Router| ---- | | | | | | | |Network 2713 +------+ +--+ +--------------+ +----------+ +------+ 2714 | 2715 +------+ 2716 |AAA | 2717 |Server| 2718 +------+ 2719 Figure 9.1.1 2721 9.1.1.1 IPv6 Related Infrastructure Changes 2723 IPv6 will be deployed in this scenario by upgrading the following 2724 devices to dual-stack: WLAN Host, WLAN Router (if present) and Edge 2725 Router. 2727 9.1.1.2 Addressing 2729 When customer WLAN Router is not present, the WLAN Host has two 2730 possible options to get an IPv6 address via the Edge Router. 2732 A. The WLAN host can get the IPv6 address from Edge router using 2733 stateless auto-configuration [12]. All hosts on the WLAN belong to 2734 the same /64 subnet that is statically configured on the Edge Router. 2735 The IPv6 WLAN Host may use stateless DHCPv6 for obtaining other 2736 information of interest such as DNS and etc. 2738 B. IPv6 WLAN host can use DHCPv6 [11] to get a IPv6 address from the 2739 DHCPv6 server. In this case the DHCPv6 server would be located in 2740 the SP core network and Edge Router would simply act as a DHCP Relay 2741 Agent. This option is similar to what we do today in case of DHCPv4. 2742 It is important to note that host implementation of stateful auto- 2743 configuration is rather limited at this time and this should be 2744 considered if choosing this address assignment option. 2746 When a customer WLAN Router is present, the WLAN Host has two 2747 possible options as well for acquiring IPv6 address. 2749 A. The WLAN Router may be assigned a prefix between /48 and /64 [8] 2750 depending on the SP policy and customer requirements. If the WLAN 2751 Router has multiple networks connected to its interfaces, the network 2752 administrator will have to configure the /64 prefixes to the WLAN 2753 Router interfaces connecting the WLAN Hosts on the customer site. 2754 The WLAN Hosts connected to these interfaces can automatically 2755 configure themselves using stateless auto-configuration with /64 2756 prefix. 2758 B. The WLAN Router can use its link-local address to communicate with 2759 the ER. It can also dynamically acquire through stateless 2760 autoconfiguration the address for the link between itself and the ER. 2761 This step is followed by a request via DHCP-PD for a prefix shorter 2762 than /64 that in turn is divided in /64s and assigned to its 2763 interfaces connecting the hosts on the customer site. 2765 In this option, the WLAN Router would act as a requesting router and 2766 Edge Router would act as delegating router. Once prefix is received 2767 by the WLAN Router, it assigns /64 prefixes to each of its interfaces 2768 connecting the WLAN Hosts on the customer site. The WLAN Hosts 2769 connected to these interfaces can automatically configure themselves 2770 using stateless auto-configuration with /64 prefix. Currently the 2771 DHCP-PD functionality cannot be implemented if the DHCP-PD server is 2772 not the ER. If the DHCP-PD messages are relayed, the Edge Router 2773 does not have a mechanism to learn the assigned prefixes and thus 2774 install the proper routes to make that prefix reachable. Work is 2775 being done to address this issue, one idea being to provide the Edge 2776 Router with a snooping mechanism. The uplink to the ISP network is 2777 configured with a /64 prefix as well. 2779 Usually it is easier for the SPs to stay with the DHCP PD and 2780 stateless auto-configuration model and point the clients to a central 2781 server for DNS/domain information, proxy configurations and etc. 2782 Using this model the SP could change prefixes on the fly and the WLAN 2783 Router would simply pull the newest prefix based on the valid/ 2784 preferred lifetime. 2786 The prefixes used for subscriber links and the ones delegated via 2787 DHCP-PD should be planned in a manner that allows maximum 2788 summarization as possible at the Edge Router. 2790 Other information of interest to the host, such as DNS, is provided 2791 through stateful [11] and stateless [10] DHCPv6. 2793 9.1.1.3 Routing 2795 The WLAN Host/Router are configured with a default route that points 2796 to the Edge router. No routing protocols are needed on these devices 2797 which generally have limited resources. 2799 The Edge Router runs the IGP used in the SP network such as OSPFv3 or 2800 IS-IS for IPv6. The connected prefixes have to be redistributed. 2802 Prefix summarization should be done at the Edge Router. When DHCP-PD 2803 is used, the IGP has to redistribute the static routes installed 2804 during the process of prefix delegation. 2806 9.1.2 Access Router Between AP and SP Edge Router 2808 When a Access Router is present between AP and Edge Router, the AP 2809 continues to work as a bridge, bridging IPv4 and IPv6 packets from 2810 WLAN Host/Router to Access/Edge Router and vice versa. The Access 2811 Router could be part of SP network or owned by a separate Access 2812 Provider. 2814 When WLAN Host initiates the connection, the AAA authentication and 2815 association process with WLAN AP will be similar as explained in 2816 section 9.1.1. 2818 Figure 9.1.2 describes the WLAN architecture when Access Router is 2819 located between AP and Edge Router. 2821 Customer | Access Provider | Service Provider 2822 Premise | | 2824 +------+ +--+ +--------------+ +----------+ +------+ 2825 |WLAN | ---- | | | | |Underlying| |Edge | 2826 |Host/ |-(WLAN)-|AP|-|Access Router |-|Technology|-|Router|=>SP 2827 |Router| ---- | | | | | | | |Network 2828 +------+ +--+ +--------------+ +----------+ +------+ 2829 | 2830 +------+ 2831 |AAA | 2832 |Server| 2833 +------+ 2834 Figure 9.1.2 2836 9.1.2.1 IPv6 Related Infrastructure Changes 2838 IPv6 is deployed in this scenario by upgrading the following devices 2839 to dual-stack: WLAN Host, WLAN Router (if present), Access Router and 2840 Edge Router. 2842 9.1.2.2 Addressing 2844 There are three possible options in this scenario for IPv6 address 2845 assignment: 2847 A. The Edge Router interface facing towards the Access Router is 2848 statically configured with /64 prefix. The Access Router receives/ 2849 configures an /64 prefix on its interface facing towards Edge Router 2850 through stateless auto-configuration. The network administrator will 2851 have to configure the /64 prefixes to the Access Router interface 2852 facing towards the customer premises. The WLAN Host/Router connected 2853 to this interface can automatically configure themselves using 2854 stateless auto-configuration with /64 prefix. 2856 B. This option uses DHCPv6 [11] for IPv6 prefix assignments to the 2857 WLAN Host/Router. There is no use of DHCP PD or stateless auto- 2858 configuration in this option. The DHCPv6 server can be located on 2859 the Access Router, on the Edge Router or somewhere in the SP network. 2860 In this case depending on where the DHCPv6 server is located, Access 2861 Router or the Edge Router would relay the DHCPv6 requests. 2863 C. It can use its link-local address to communicate with the ER. It 2864 can also dynamically acquire through stateless autoconfiguration the 2865 address for the link between itself and the ER. This step is 2866 followed by a request via DHCP-PD for a prefix shorter than /64 that 2867 in turn is divided in /64s and assigned to its interfaces connecting 2868 the hosts on the customer site. 2870 In this option, the Access Router would act as a requesting router 2871 and Edge Router would act as delegating router. Once prefix is 2872 received by the Access Router, it assigns /64 prefixes to each of its 2873 interfaces connecting the WLAN Host/Router on customer site. The 2874 WLAN Host/Router connected to these interfaces can automatically 2875 configure themselves using stateless auto-configuration with /64 2876 prefix. Currently the DHCP-PD functionality cannot be implemented if 2877 the DHCP-PD server is not the Edge Router. If the DHCP-PD messages 2878 are relayed, the Edge Router does not have a mechanism to learn the 2879 assigned prefixes and thus install the proper routes to make that 2880 prefix reachable. Work is being done to address this issue, one idea 2881 being to provide the Edge Router with a snooping mechanism. The 2882 uplink to the ISP network is configured with a /64 prefix as well. 2884 It is easier for the SPs to stay with the DHCP PD and stateless auto- 2885 configuration model and point the clients to a central server for 2886 DNS/domain information, proxy configurations and others. Using this 2887 model the provider could change prefixes on the fly and the Access 2888 Router would simply pull the newest prefix based on the valid/ 2889 preferred lifetime. 2891 As mentioned before the prefixes used for subscriber links and the 2892 ones delegated via DHCP-PD should be planned in a manner that allows 2893 maximum summarization possible at the Edge Router. Other information 2894 of interest to the host, such as DNS, is provided through stateful 2895 [11] and stateless [10] DHCPv6. 2897 9.1.2.3 Routing 2899 The WLAN Host/Router are configured with a default route that points 2900 to the Access Router. No routing protocols are needed on these 2901 devices which generally have limited resources. 2903 If the Access Router is owned by an Access Provider, then the Access 2904 Router can have a default route, pointing towards the SP Edge Router. 2905 The Edge Router runs the IGP used in the SP network such as OSPFv3 or 2906 IS-IS for IPv6. The connected prefixes have to be redistributed. If 2907 DHCP-PD is used, with every delegated prefix a static route is 2908 installed by the Edge Router. For this reason the static routes must 2909 be redistributed. Prefix summarization should be done at the Edge 2910 Router. 2912 If the Access Router is owned by the SP, then Access Router will also 2913 run IPv6 IGP and will be part of SP IPv6 routing domain (OSPFv3 or 2914 IS-IS). The connected prefixes have to be redistributed. If DHCP-PD 2915 is used, with every delegated prefix a static route is installed by 2916 the Access Router. For this reason the static routes must be 2917 redistributed. Prefix summarization should be done at the Access 2918 Router. 2920 9.1.3 PPP Based Model 2922 PPP TERMINATED AGGREGATION (PTA) and L2TPv2 ACCESS AGGREGATION (LAA) 2923 models as discussed in sections 7.2.2 and 7.2.3 respectively can also 2924 be deployed in IPv6 WLAN environment. 2926 9.1.3.1 PTA Model in IPv6 WLAN Environment 2928 While deploying the PTA model in IPv6 WLAN environment the Access 2929 Router is Layer3 aware and it has to be upgraded to support IPv6. 2930 Since the Access Router terminates the PPP sessions initiated by WLAN 2931 Host/Router, it has to support PPPoE with IPv6. 2933 Figure 9.1.3.1 describes the PTA Model in IPv6 WLAN environment. 2935 Customer | Access Provider | Service Provider 2936 Premise | | 2938 +------+ +--+ +--------------+ +----------+ +------+ 2939 |WLAN | ---- | | | | |Underlying| |Edge | 2940 |Host/ |-(WLAN)-|AP|-|Access Router |-|Technology|-|Router|=>SP 2941 |Router| ---- | | | | | | | |Network 2942 +------+ +--+ +--------------+ +----------+ +------+ 2943 | 2944 |---------------------------| +------+ 2945 PPP |AAA | 2946 |Server| 2947 +------+ 2948 Figure 9.1.3.1 2950 9.1.3.1.1 IPv6 Related Infrastructure Changes 2952 IPv6 is deployed in this scenario by upgrading the following devices 2953 to dual-stack: WLAN Host, WLAN Router (if present), Access Router and 2954 Edge Router. 2956 9.1.3.1.2 Addressing 2958 The addressing techniques described in section 7.2.2.2 applies to 2959 IPv6 WLAN PTA scenario as well. 2961 9.1.3.1.3 Routing 2963 The routing techniques described in section 7.2.2.3 applies to IPv6 2964 WLAN PTA scenario as well. 2966 9.1.3.2 LAA Model in IPv6 WLAN Environment 2968 While deploying the LAA model in IPv6 WLAN environment the Access 2969 Router is Layer3 aware and it has to be upgraded to support IPv6. 2970 The PPP sessions initiated by WLAN Host/Router are forwarded over the 2971 L2TPv2 tunnel to the aggregation point in the SP network. The Access 2972 Router must have the capability to support L2TPv2 for IPv6. 2974 Figure 9.1.3.2 describes the LAA Model in IPv6 WLAN environment 2975 Customer | Access Provider | Service Provider 2976 Premise | | 2978 +------+ +--+ +--------------+ +----------+ +------+ 2979 |WLAN | ---- | | | | |Underlying| |Edge | 2980 |Host/ |-(WLAN)-|AP|-|Access Router |-|Technology|-|Router|=>SP 2981 |Router| ---- | | | | | | | |Network 2982 +------+ +--+ +--------------+ +----------+ +------+ 2983 | 2984 |-------------------------------------------------- | 2985 PPP | 2986 |--------------------- | 2987 L2TPv2 | 2988 +------+ 2989 |AAA | 2990 |Server| 2991 +------+ 2992 Figure 9.1.3.2 2994 9.1.3.2.1 IPv6 Related Infrastructure Changes 2996 IPv6 is deployed in this scenario by upgrading the following devices 2997 to dual-stack: WLAN Host, WLAN Router (if present), Access Router and 2998 Edge Router. 3000 9.1.3.2.2 Addressing 3002 The addressing techniques described in section 7.2.3.2 applies to 3003 IPv6 WLAN LAA scenario as well. 3005 9.1.3.2.3 Routing 3007 The routing techniques described in section 7.2.3.3 applies to IPv6 3008 WLAN LAA scenario as well. 3010 9.2 IPv6 Multicast 3012 The typical multicast services offered are video/audio streaming 3013 where the IPv6 WLAN Host joins a multicast group and receives the 3014 content. This type of service model is well supported through PIM- 3015 SSM which is enabled throughout the SP network. MLDv2 is required 3016 for PIM-SSM support. Vendors can choose to implement features that 3017 allow routers to map MLDv1 group joins to predefined sources. 3019 It is important to note that in the shared wireless environments 3020 multicast can have a significant bandwidth impact. For this reason 3021 the bandwidth allocated to multicast traffic should be limited and 3022 fixed based on the overall capacity of the wireless specification 3023 used 802.11a, 802.11b or 802.11g. 3025 The IPv6 WLAN Hosts can also join desired multicast groups as long as 3026 they are enabled to support MLDv1 or MLDv2. If a WLAN/Access Routers 3027 are used then they have to be enabled to support MLDv1 and MLDv2 in 3028 order to process the requests of the IPv6 WLAN Hosts. The WLAN/ 3029 Access Router should also needs to be enabled to support PIM-SSM in 3030 order to send PIM joins up to the Edge Router. When enabling this 3031 functionality on a WLAN/Access Router, its limited resources should 3032 be taken into consideration. Another option would be for the WLAN/ 3033 Access Router to support MLD proxy routing. 3035 The Edge Router has to be enabled to support MLDv1 and MLDv2 in order 3036 to process the requests coming from IPv6 WLAN Host or WLAN/Access 3037 Router (if present). The Edge Router has also needs to be enabled 3038 for PIM-SSM in order to receive joins from IPv6 WLAN Hosts or WLAN/ 3039 Access Router (if present) and send joins towards the SP core. 3041 MLD authentication, authorization and accounting is usually 3042 configured on the Edge Router in order to enable the SP to do billing 3043 for the content services provided. Further investigation should be 3044 made in finding alternative mechanisms that would support these 3045 functions. 3047 Concerns have been raised in the past related to running IPv6 3048 multicast over WLAN links. Potentially these are same kind of issues 3049 when running any Layer3 protocol over a WLAN link that has a high 3050 loss-to-signal ratio, where certain frames that are multicast based 3051 are dropped when settings are not adjusted properly. For instance 3052 this behavior is similar to IGMP host membership report, when done on 3053 a WLAN link with high loss-to-signal ratio and high interference. 3055 This problem is inherited to WLAN that can impact both IPv4 and IPv6 3056 multicast packets and not specific to IPv6 multicast. 3058 While deploying WLAN (IPv4 or IPv6), one should adjust their 3059 broadcast/multicast settings if they are in danger of dropping 3060 application dependent frames. These problems are usually caused when 3061 AP are placed too far apart (not following the distance limitations), 3062 high interference and etc. These issues may impact a real multicast 3063 application such as streaming video or basic operation of IPv6 if the 3064 frames were dropped. Basic IPv6 communications uses functions such 3065 as Duplicate Address Detection (DAD), Router and Neighbor 3066 Solicitations (RS, NS), Router and Neighbor Advertisement (RA, NA) 3067 and etc. which could be impacted by the above mentioned issues as 3068 these frames are Layer 2 Ethernet multicast frames. 3070 Please refer to section 7.3 for more IPv6 multicast details. 3072 9.3 IPv6 QoS 3074 Today, QoS is done outside of the WiFi domain but it is nevertheless 3075 important to the overall deployment. 3077 The QoS configuration is particularly relevant on the Edge Router in 3078 order to manage resources shared amongst multiple subscribers 3079 possibly with various service level agreements (SLA). Although, the 3080 WLAN Host/Router and Access Router could also be configured for QoS. 3081 This includes support for appropriate classification criteria which 3082 would need to be implemented for IPv6 unicast and multicast traffic. 3084 On the Edge Router the subscriber facing interfaces have to be 3085 configured to police the inbound customer traffic and shape the 3086 traffic outbound to the customer, based on the SLA. Traffic 3087 classification and marking should also be done on the Edge router in 3088 order to support the various types of customer traffic: data, voice, 3089 video. The same IPv4 QoS concepts and methodologies should be 3090 applied for the IPv6 as well. 3092 It is important to note that when traffic is encrypted end-to-end, 3093 the traversed network devices will not have access to many of the 3094 packet fields used for classification purposes. In these cases 3095 routers will most likely place the packets in the default classes. 3096 The QoS design should take into consideration this scenario and try 3097 to use mainly IP header fields for classification purposes. 3099 9.4 IPv6 Security Considerations 3101 There are limited changes that have to be done for WLAN Host/Router 3102 in order to enhance security. The Privacy extensions [14] for 3103 autoconfiguration should be used by the hosts with the same 3104 consideration for host traceability as described in section 7.5. 3105 IPv6 firewall functions should be enabled on the WLAN Host/Router if 3106 present. 3108 The ISP provides security against attacks that come form its own 3109 subscribers but it could also implement security services that 3110 protect its subscribers from attacks sourced from the outside of its 3111 network. Such services do not apply at the access level of the 3112 network discussed here. 3114 If the host authentication at hot spots is done using web based 3115 authentication system then the level of security would depend on the 3116 particular implementation. User credential should never be sent as 3117 clear text via HTTP. Secure HTTP (HTTPS) should be used between the 3118 web browser and authentication server. The authentication server 3119 could use RADIUS and LDAP services at the back end. 3121 Authentication is an important aspect of securing WLAN networks prior 3122 to implementing Layer 3 security policies. This would help for 3123 example avoid threats to the ND or stateless autoconfiguration 3124 processes. 802.1x provides the means to secure the network access 3125 however, the many types of EAP (PEAP, EAP-TLS, EAP-TTLS, EAP-FAST, 3126 LEAP) and the capabilities of the hosts to support some of the 3127 features might make it difficult to implement a comprehensive and 3128 consistent policy. 3130 If any layer two filters for Ethertypes are in place, the NAP must 3131 permit the IPv6 Ethertype (0X86DD). 3133 The device that is the Layer3 next hop for the subscribers (Access or 3134 Edge Router) should protect the network and the other subscribers 3135 against attacks by one of the provider customers. For this reason 3136 uRPF and ACLs should be used on all interfaces facing subscribers. 3137 Filtering should be implemented with regard for the operational 3138 requirements of IPv6 [Security considerations for IPv6]. 3139 Authentication and authorization should be used wherever possible. 3141 The Access and the Edge Router should protect their processing 3142 resources against floods of valid customer control traffic such as: 3143 RS, NS, MLD Requests. Rate limiting should be implemented on all 3144 subscriber facing interfaces. The emphasis should be placed on 3145 multicast type traffic as it is most often used by the IPv6 control 3146 plane. 3148 9.5 IPv6 Network Management 3150 The necessary instrumentation (such as MIBs, NetFlow Records, etc) 3151 should be available for IPv6. 3153 Usually, NSPs manage the edge routers by SNMP. The SNMP transport 3154 can be done over IPv4 if all managed devices have connectivity over 3155 both IPv4 and IPv6. This would imply the smallest changes to the 3156 existent network management practices and processes. Transport over 3157 IPv6 could also be implemented and it might become necessary if IPv6 3158 only islands are present in the network. The management stations are 3159 located on the core network. Network Management Applications should 3160 handle IPv6 in a similar fashion to IPv4 however they should also 3161 support features specific to IPv6 (such as Neighbor monitoring). 3163 In some cases service providers manage equipment located on customers 3164 LANs. 3166 10. Broadband Power Line Communications (PLC) 3168 This section describes the IPv6 deployment in Power Line 3169 Communications (PLC) Access Networks. There may be other choices, 3170 but it seems that this is the best model to follow. Lessons learnt 3171 from Cable, Ethernet and even WLAN access networks may be applicable 3172 also. 3174 Power Line Communications are also often called Broadband Power Line 3175 (BPL) and some times even Power Line Telecommunications (PLT). 3177 PLC/BPL can be used for providing, with todays technology, up to 3178 200Mbps (total, upstream+downstream) by means of the power grid. The 3179 coverage is often the last half mile (typical distance from the 3180 Medium-to-Low Voltage transformer to the customer premise meter), and 3181 of course, as an in-home network (which is out of the scope of this 3182 document). 3184 The bandwidth in a given PLC/BPL segment is shared among all the 3185 customers connected to that segment (often the customers connected to 3186 the same medium-to-low voltage transformer). The number of customers 3187 can vary depending on different factors, such as distances and even 3188 countries (from a few customers, just 5-6, up to 100-150). 3190 PLC/BPL could also be used in the Medium Voltage network (often 3191 configured as Metropolitan Area Networks), but this is also out of 3192 the scope of this document, as it will be part of the core network, 3193 not the access one. 3195 Just for information/clarification, often the PLC/BPL access networks 3196 use hybrid layer 2 combinations either with PLC/BPL in the medium 3197 voltage, point to point links, wireless links, satellite, etc., but 3198 once more, this seems to be out of the scope of this document, as 3199 those means are transparent, for the purpose of this document, to the 3200 last half mile access network deployed with PLC/BPL. 3202 10.1 PLC/BPL Access Network Elements 3204 This section describes the different elements commonly used in PLC/ 3205 BPL access networks. 3207 Head End (HE): It is the router that connects the PLC/BPL access 3208 network (the power grid), located at the medium-to-low voltage 3209 transformer, to the core network. The HE PLC/BPL interface appears 3210 to each customer as a single virtual interface, all of them sharing 3211 the same physical media. 3213 Repeater (RPT): It is the device which may be required in some 3214 circumstances to improve the signal on the PLC/BPL. This may be the 3215 case if there are many customers in the same segment or building. 3216 Often is a bridge, but it could be also a router if for example there 3217 is a lot of peer-to-peer traffic in a building and due to the master- 3218 slave nature of the PLC/BPL technology, is required to improve the 3219 performance within that segment. For simplicity, in this document, 3220 it will be considered that the RPT is always a transparent layer 2 3221 bridge, so it may be present or not (from the layer 3 point of view). 3223 Customer Premise Equipment (CPE): It is the modem (internal to the 3224 host), modem/bridge (BCPE), router (RCPE) or any combination among 3225 those (i.e. modem+bridge/router), located at the customer premise. 3227 Edge Router (ER) 3229 Figure 10.1 depicts all the network elements indicated above 3231 Customer Premises|Network Access Provider|Network Service Provider 3232 CP NAP NSP 3234 +-----+ +------+ +-----+ +------+ +--------+ 3235 |Hosts|--| RCPE |--| RPT |--------+ HE +---+ Edge | ISP 3236 +-----+ +------+ +-----+ | | | Router +===>Network 3237 +--+---+ +--------+ 3238 +-----+ +------+ +-----+ | 3239 |Hosts|--| BCPE |--| RPT |-----------+ 3240 +-----+ +------+ +-----+ 3241 Figure 10.1 3243 The logical topology and design of PLC/BPL is very similar to 3244 Ethernet Broadband Networks as discussed in Section 8. 3246 10.2 Deploying IPv6 in IPv4 PLC/BPL 3248 The most simplistic and efficient model, considering the nature of 3249 the PLC/BPL networks, is to see the network as a point-to-point one 3250 to each customer. Even if several customers share the same physical 3251 media, the traffic is not visible among them because each one uses 3252 different channels, which are in addition encrypted by means of 3DES. 3254 Furthermore, if required, VLANs could also be used, as already 3255 described for the Ethernet case. 3257 In order to maintain the deployment concepts and business models 3258 proven and used with existing revenue generating IPv4 services, the 3259 IPv6 deployment will match the IPv4 one. Under certain circumstances 3260 where new service types or service needs justify it, IPv4 and IPv6 3261 network architectures could be different. Both approaches are very 3262 similar to those already described for the Ethernet case. 3264 10.2.1 IPv6 Related Infrastructure Changes 3266 In this scenario the RPT is layer 3 unaware, but not the Head End, 3267 which should be upgraded to support IPv6. Similarly other devices 3268 which have to be upgraded to dual stack: Hosts, RCPE and Edge Router. 3270 10.2.2 Addressing 3272 The Hosts or the RCPEs have the HE as their Layer 3 next hop. 3274 If there is no RCPE, but instead a BCPE all the hosts on the 3275 subscriber site belong to the same /64 subnet that is statically 3276 configured on the HE. The hosts can use stateless autoconfiguration 3277 or stateful DHCPv6 based configuration to acquire an address via the 3278 HE. 3280 If a RCPE is present: 3282 A. It is statically configured with an address on the /64 subnet 3283 between itself and the HE, and with /64 prefixes on the interfaces 3284 connecting the hosts on the customer site. This is not a desired 3285 provisioning method being expensive and difficult to manage. 3287 B. It can use its link-local address to communicate with the HE. It 3288 can also dynamically acquire through stateless autoconfiguration the 3289 address for the link between itself and the HE. This step is 3290 followed by a request via DHCP-PD for a prefix shorter than /64 3291 (typically /48 [8]) that in turn is divided in /64s and assigned to 3292 its interfaces connecting the hosts on the customer site. This 3293 should be the preferred provisioning method, being cheaper and easier 3294 to manage. 3296 The Edge Router needs to have a prefix considering that each customer 3297 in general will receive a /48 prefix, and that each HE will 3298 accommodate customers. Consequently each HE will require n x /48 3299 prefixes. 3301 It could be possible to use a kind of Hierarchical Prefix Delegation 3302 to automatically provision the required prefixes and fully auto- 3303 configure the HEs, and consequently reduce the network setup, 3304 operation and maintenance cost. 3306 The prefixes used for subscriber links and the ones delegated via 3307 DHCP-PD should be planned in a manner that allows as much 3308 summarization as possible at the Edge Router. 3310 Other information of interest to the host, such as DNS, is provided 3311 through stateful [11] and stateless [10] DHCPv6. 3313 10.2.3 Routing 3315 If no routers are used on the custmer premises, the HE can simply be 3316 configured with a default route that points to the Edge Router. If a 3317 router is used on the customer premises (RCPE) then the HE will run 3318 an IGP to the ER such as OSPFv3, IS-IS or even RIPng. The connected 3319 prefixes should be redistributed. If DHCP-PD is used, with every 3320 delegated prefix a static route is installed by the HE. For this 3321 reason the static routes must also be redistributed. Prefix 3322 summarization should be done at the HE. 3324 The RCPE requires only a default route pointing to the HE. No 3325 routing protocols are needed on these devices which generally have 3326 limited resources. 3328 The Edge Router runs the IPv6 IGP used in the NSP: OSPFv3 or IS-IS. 3329 The connected prefixes have to be redistributed as well as any RP 3330 other than the ones used on the ER that might be used between the HE 3331 and the ER. 3333 10.3 IPv6 Multicast 3335 The considerations regarding IPv6 Multicast for Ethernet are also 3336 applicable here, in general, but assuming the nature of PLC/BPL being 3337 a shared media. If a lot of Multicast is expected, it may be worth 3338 considering using RPT which are layer 3 aware. In that case, one 3339 extra layer of Hierarchical DHCP-PD could be considered, in order to 3340 facilitate the deployment, operation and maintenance of the network. 3342 10.4 IPv6 QoS 3344 The considerations introduced for QoS in Ethernet are also applicable 3345 here. PLC/BPL networks support QoS, which basically are no different 3346 whether the transport is IPv4 or IPv6. It is necessary to understand 3347 that the specific network characteristics, such as the variability 3348 that may be introduced by electrical noise, towards which the PLC/BPL 3349 network will automatically self-adapt. 3351 10.5 IPv6 Security Considerations 3353 There are no differences in terms of security considerations if 3354 compared with the Ethernet case. 3356 10.6 IPv6 Network Management 3358 There are no differences in terms of network management if compared 3359 with the already described Ethernet case. 3361 11. Gap Analysis 3363 Several aspects of deploying IPv6 over SP Broadband networks were 3364 highlighted in this document, aspects that require additional work in 3365 order to facilitate native deployments as summarized below: 3367 A. As mentioned in section 6, changes will need to be made to the 3368 DOCSIS specification in order for SPs to deploy native IPv6 over 3369 cable networks. The CM and CMTS will both need to support IPv6 3370 natively in order to forward IPv6 unicast and multicast traffic. 3371 This is required for IPv6 Neighbor Discovery to work over DOCSIS 3372 cable networks. Additional classifiers need to be added to the 3373 DOCSIS specification in order to classify IPv6 traffic at the CM and 3374 CMTS in order to provide QoS. These issues are addressed in a recent 3375 proposal made to Cable Labs for DOCSIS 3.0 [31] 3377 B. Currently the DHCP-PD functionality cannot be implemented if the 3378 DHCP-PD server is not the Edge Router. If the DHCP-PD messages are 3379 relayed, the Edge Router does not have a mechanism to learn the 3380 assigned prefixes and thus install the proper routes to make that 3381 prefix reachable. Work needs to be done to address this issue, one 3382 idea being to provide the Edge Router with a snooping mechanism. The 3383 uplink to the ISP network is configured with a /64 prefix as well. 3385 C. Section 7 stated that current RBE based IPv4 deployment might not 3386 be the best approach for IPv6 where the addressing space available 3387 gives the SP the opportunity to separate the users on different 3388 subnets. The differences between IPv4 RBE and IPv6 RBE were 3389 highlighted in section 7. If however, support and reason is found 3390 for a deployment similar to IPv4 RBE, then the environment becomes 3391 NBMA and the new feature should observe RFC2491 recommendations. 3393 D. Section 7 discussed the constraints imposed on a LAA based IPv6 3394 deployment by the fact that it is expected that the subscribers keep 3395 their assigned prefix regardless of LNS. A deployment approach was 3396 proposed that would maintain the addressing schemes contiguous and 3397 offers prefix summarization opportunities. The topic could be 3398 further investigated for other solutions or improvements. 3400 E. Sections 7 and 8 pointed out the limitations (previously 3401 documented in [32]) in deploying inter-domain ASM however, SSM based 3402 services seem more likely at this time. For such SSM based services 3403 of content delivery (video or Audio), mechanisms are needed to 3404 facilitate the billing and management of listeners. The currently 3405 available feature of MLD AAA is suggested however, other methods or 3406 mechanisms might be developed and proposed. 3408 F. In relation to section 9, concerns have been raised related to 3409 running IPv6 multicast over WLAN links. Potentially these are same 3410 kind of issues when running any Layer3 protocol over a WLAN link that 3411 has a high loss-to-signal ratio, certain frames that are multicast 3412 based are dropped when settings are not adjusted properly. For 3413 instance this behavior is similar to IGMP host membership report, 3414 when done on a WLAN link with high loss-to-signal ratio and high 3415 interference. This problem is inherited to WLAN that can impact both 3416 IPv4 and IPv6 multicast packets and not specific to IPv6 multicast. 3418 G. The Privacy Extensions were mentioned as a popular means to 3419 provide some form of host security. ISPs can track relatively easily 3420 the prefixes assigned to subscribers. If however the ISPs are 3421 required by regulations to track their users at host address level, 3422 the Privacy Extensions [14] can be implemented only in parallel with 3423 network management tools that could provide traceability of the 3424 hosts. Mechanisms should be defined to implement this aspect of user 3425 management. 3427 H. Tunnels are an effective way to avoid deployment dependencies on 3428 the IPv6 support on platforms that are out of the SP control (GWRs or 3429 CPEs) or over technologies that did not standardize the IPv6 support 3430 yet (cable). They can be used in the following ways: 3432 i. Tunnels directly to the CPE or GWR with public or private IPv4 3433 addresses. 3435 ii. Tunnels directly to hosts with public or private IPv4 addresses. 3436 Recommendations on the exact tunneling mechanisms that can/should be 3437 used for last mile access need to be investigated further and should 3438 be covered in a future IETF draft. 3440 I. Through its larger address space, IPv6 allows SPs to assign fixed, 3441 globally routable prefixes to the links connecting each subscriber. 3443 This approach changes the provisioning methodologies that were used 3444 for IPv4. Static configuration of the IPv6 addresses for all these 3445 links on the Edge Routers or Access Routers might not be a scalable 3446 option. New provisioning mechanisms or features might need to be 3447 developed in order to deal with this issue. 3449 J. New deployment models are emerging for the Layer 2 portion of the 3450 NAP where individual VLANs are not dedicated to each subscriber. 3451 This approach allows Layer 2 switches to aggregate more then 4096 3452 users. MAC Forced Forwarding [MFF] is an example of such an 3453 implementation where a broadcast domain is turned into a NBMA like 3454 environment by forwarding the frames based on both Source and 3455 Destination MAC addresses. Since these models are being adopted by 3456 the field, the implications of deploying IPv6 in such environments 3457 need to be further investigated. 3459 The outcome of solutions to some of these topics ranges from making a 3460 media access capable of supporting native IPv6 (cable) to improving 3461 operational aspects of native IPv6 deployments. 3463 12. IANA Considerations 3465 This document requests no action by IANA. 3467 13. Security Considerations 3469 Please refer to the individual "IPv6 Security Considerations" 3470 technology sections for details. 3472 14. References 3474 14.1 Normative References 3476 [1] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and E. 3477 Lear, "Address Allocation for Private Internets", BCP 5, 3478 RFC 1918, February 1996. 3480 [2] Durand, A., Fasano, P., Guardini, I., and D. Lento, "IPv6 3481 Tunnel Broker", RFC 3053, January 2001. 3483 [3] Carpenter, B. and K. Moore, "Connection of IPv6 Domains via 3484 IPv4 Clouds", RFC 3056, February 2001. 3486 [4] Conta, A. and S. Deering, "Generic Packet Tunneling in IPv6 3487 Specification", RFC 2473, December 1998. 3489 [5] Gilligan, R. and E. Nordmark, "Transition Mechanisms for IPv6 3490 Hosts and Routers", RFC 2893, August 2000. 3492 [6] Carpenter, B. and C. Jung, "Transmission of IPv6 over IPv4 3493 Domains without Explicit Tunnels", RFC 2529, March 1999. 3495 [7] Huitema, C., Austein, R., Satapati, S., and R. van der Pol, 3496 "Evaluation of IPv6 Transition Mechanisms for Unmanaged 3497 Networks", RFC 3904, September 2004. 3499 [8] IAB and IESG, "IAB/IESG Recommendations on IPv6 Address 3500 Allocations to Sites", RFC 3177, September 2001. 3502 [9] Hinden, R. and S. Deering, "Internet Protocol Version 6 (IPv6) 3503 Addressing Architecture", RFC 3513, April 2003. 3505 [10] Droms, R., "Stateless Dynamic Host Configuration Protocol 3506 (DHCP) Service for IPv6", RFC 3736, April 2004. 3508 [11] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., and M. 3509 Carney, "Dynamic Host Configuration Protocol for IPv6 3510 (DHCPv6)", RFC 3315, July 2003. 3512 [12] Thomson, S. and T. Narten, "IPv6 Stateless Address 3513 Autoconfiguration", RFC 2462, December 1998. 3515 [13] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic Host 3516 Configuration Protocol (DHCP) version 6", RFC 3633, 3517 December 2003. 3519 [14] Narten, T. and R. Draves, "Privacy Extensions for Stateless 3520 Address Autoconfiguration in IPv6", RFC 3041, January 2001. 3522 [15] Mamakos, L., Lidl, K., Evarts, J., Carrel, D., Simone, D., and 3523 R. Wheeler, "A Method for Transmitting PPP Over Ethernet 3524 (PPPoE)", RFC 2516, February 1999. 3526 [16] Gross, G., Kaycee, M., Lin, A., Malis, A., and J. Stephens, 3527 "PPP Over AAL5", RFC 2364, July 1998. 3529 [17] Haskin, D. and E. Allen, "IP Version 6 over PPP", RFC 2472, 3530 December 1998. 3532 [18] Narten, T., Nordmark, E., and W. Simpson, "Neighbor Discovery 3533 for IP Version 6 (IPv6)", RFC 2461, December 1998. 3535 [19] Meyer, D. and P. Lothberg, "GLOP Addressing in 233/8", 3536 RFC 2770, February 2000. 3538 [20] St. Johns, M., "DOCSIS Cable Device MIB Cable Device Management 3539 Information Base for DOCSIS compliant Cable Modems and Cable 3540 Modem Termination Systems", RFC 2669, August 1999. 3542 [21] Droms, R., "DNS Configuration options for Dynamic Host 3543 Configuration Protocol for IPv6 (DHCPv6)", RFC 3646, 3544 December 2003. 3546 [22] Fenner, B. and D. Meyer, "Multicast Source Discovery Protocol 3547 (MSDP)", RFC 3618, October 2003. 3549 [23] Baker, F. and P. Savola, "Ingress Filtering for Multihomed 3550 Networks", BCP 84, RFC 3704, March 2004. 3552 [24] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in 3553 IPv6", RFC 3775, June 2004. 3555 [25] Lind, M., Ksinant, V., Park, S., Baudot, A., and P. Savola, 3556 "Scenarios and Analysis for Introducing IPv6 into ISP 3557 Networks", RFC 4029, March 2005. 3559 14.2 Informative References 3561 [26] Shirasaki, Y., Miyakawa, S., and A. Takenouchi, "A Model of 3562 IPv6/IPv4 Dual Stack Internet Access 3563 Service(draft-shirasaki-dualstack-service-04.txt)", April 2004. 3565 [27] De Clercq, J., Ooms, D., Prevost, S., and F. Le Faucheur, 3566 "Connecting IPv6 Islands across IPv4 Clouds with 3567 BGP(draft-ooms-v6ops-bgp-tunnel-04.txt)", October 2004. 3569 [28] Templin, F., Gleeson, T., Talwar, M., and D. Thaler, "Intra- 3570 Site Automatic Tunnel Addressing Protocol 3571 (ISATAP)(draft-ietf-ngtrans-isatap-12.txt)", January 2003. 3573 [29] Palet, J., Diaz, M., and P. Savola, "Analysis of IPv6 Tunnel 3574 End-point Discovery 3575 Mechanisms(draft-palet-v6ops-tun-auto-disc-01.txt)", June 2004. 3577 [30] Nordmark, E. and R. Gilligan, "Basic Transition Mechanisms for 3578 IPv6 Hosts and Routers(draft-ietf-v6ops-mech-v2-06.txt)", 3579 September 2004. 3581 [31] Cisco, Systems., "DOCSIS 3.0 Proposal", April 2005. 3583 [32] Savola, P., "IPv6 Multicast Deployment 3584 Issues(draft-mboned-ipv6-multicast-issues.txt)", April 2004. 3586 [33] Cable, Labs., "Radio Frequency Interface Specification SP- 3587 RFIv2.0-I02-020617", June 2002. 3589 [34] Bhaskar, N., Gall, A., and S. Venaas, "Bootstrap Router (BSR) 3590 Mechanism for PIM(draft-ietf-pim-sm-bsr-04.txt)", January 2005. 3592 [35] Palet, J., Nielsent, K., Parent, F., Durand, A., 3593 Suryanarayanan, R., and P. Savola, "Goals for Tunneling 3594 Configuration(draft-palet-v6tc-goals-tunneling-00.txt)", 3595 August 2005. 3597 [36] Convery, S. and D. Miller, "IPv6 and IPv4 Threat Comparison and 3598 Best-Practice Evaluation", March 2004. 3600 Authors' Addresses 3602 Salman Asadullah 3603 Cisco Systems 3604 170 West Tasman Drive 3605 San Jose, CA 95134 3606 USA 3608 Phone: 408 526 8982 3609 Email: sasad@cisco.com 3611 Adeel Ahmed 3612 Cisco Systems 3613 2200 East President George Bush Turnpike 3614 Richardson, TX 75082 3615 USA 3617 Phone: 469 255 4122 3618 Email: adahmed@cisco.com 3620 Ciprian Popoviciu 3621 Cisco Systems 3622 7025-6 Kit Creek Road 3623 Research Triangle Park, NC 27709 3624 USA 3626 Phone: 919 392 3723 3627 Email: cpopovic@cisco.com 3629 Jordi Palet Martinez 3630 Consulintel 3631 San Jose Artesano, 1 3632 Alcobendas, Madrid E-28108 3633 Spain 3635 Phone: +34 91 151 81 99 3636 Email: jordi.palet@consulintel.es 3638 Intellectual Property Statement 3640 The IETF takes no position regarding the validity or scope of any 3641 Intellectual Property Rights or other rights that might be claimed to 3642 pertain to the implementation or use of the technology described in 3643 this document or the extent to which any license under such rights 3644 might or might not be available; nor does it represent that it has 3645 made any independent effort to identify any such rights. Information 3646 on the procedures with respect to rights in RFC documents can be 3647 found in BCP 78 and BCP 79. 3649 Copies of IPR disclosures made to the IETF Secretariat and any 3650 assurances of licenses to be made available, or the result of an 3651 attempt made to obtain a general license or permission for the use of 3652 such proprietary rights by implementers or users of this 3653 specification can be obtained from the IETF on-line IPR repository at 3654 http://www.ietf.org/ipr. 3656 The IETF invites any interested party to bring to its attention any 3657 copyrights, patents or patent applications, or other proprietary 3658 rights that may cover technology that may be required to implement 3659 this standard. Please address the information to the IETF at 3660 ietf-ipr@ietf.org. 3662 Disclaimer of Validity 3664 This document and the information contained herein are provided on an 3665 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 3666 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 3667 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 3668 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 3669 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 3670 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 3672 Copyright Statement 3674 Copyright (C) The Internet Society (2005). This document is subject 3675 to the rights, licenses and restrictions contained in BCP 78, and 3676 except as set forth therein, the authors retain all their rights. 3678 Acknowledgment 3680 Funding for the RFC Editor function is currently provided by the 3681 Internet Society.