idnits 2.17.1 draft-ietf-v6ops-bb-deployment-scenarios-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.5 on line 3412. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 3395. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 3401. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. ** The document seems to lack an RFC 3979 Section 5, para. 1 IPR Disclosure Acknowledgement -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document uses RFC 3667 boilerplate or RFC 3978-like boilerplate instead of verbatim RFC 3978 boilerplate. After 6 May 2005, submission of drafts without verbatim RFC 3978 boilerplate is not accepted. The following non-3978 patterns matched text found in the document. That text should be removed or replaced: This document is an Internet-Draft and is subject to all provisions of Section 3 of RFC 3667. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 36 longer pages, the longest (page 54) being 62 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 65 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** There are 8 instances of too long lines in the document, the longest one being 4 characters in excess of 72. == There are 8 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == The "Author's Address" (or "Authors' Addresses") section title is misspelled. == Line 185 has weird spacing: '... some extra...' -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- Couldn't find a document date in the document -- date freshness check skipped. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'RFC3775' is mentioned on line 125, but not defined ** Obsolete undefined reference: RFC 3775 (Obsoleted by RFC 6275) == Missing Reference: 'RFC3704' is mentioned on line 1200, but not defined == Missing Reference: 'RFC1918' is mentioned on line 2623, but not defined == Unused Reference: 'RFC3053' is defined on line 3224, but no explicit reference was found in the text == Unused Reference: 'RFC3056' is defined on line 3228, but no explicit reference was found in the text == Unused Reference: 'RFC2473' is defined on line 3232, but no explicit reference was found in the text == Unused Reference: 'RFC2893' is defined on line 3236, but no explicit reference was found in the text == Unused Reference: 'RFC2529' is defined on line 3240, but no explicit reference was found in the text == Unused Reference: 'RFC3633' is defined on line 3264, but no explicit reference was found in the text == Unused Reference: 'RFC2472' is defined on line 3279, but no explicit reference was found in the text == Unused Reference: 'RFC3646' is defined on line 3290, but no explicit reference was found in the text == Unused Reference: 'ISATAP' is defined on line 3312, but no explicit reference was found in the text ** Downref: Normative reference to an Informational RFC: RFC 3053 ** Obsolete normative reference: RFC 2893 (Obsoleted by RFC 4213) ** Downref: Normative reference to an Informational RFC: RFC 3904 ** Obsolete normative reference: RFC 3513 (Obsoleted by RFC 4291) ** Obsolete normative reference: RFC 3736 (Obsoleted by RFC 8415) ** Obsolete normative reference: RFC 3315 (Obsoleted by RFC 8415) ** Obsolete normative reference: RFC 2462 (Obsoleted by RFC 4862) ** Obsolete normative reference: RFC 3633 (Obsoleted by RFC 8415) ** Obsolete normative reference: RFC 3041 (Obsoleted by RFC 4941) ** Downref: Normative reference to an Informational RFC: RFC 2516 -- Duplicate reference: RFC2516, mentioned in 'RFC2364', was also mentioned in 'RFC2516'. ** Downref: Normative reference to an Informational RFC: RFC 2516 (ref. 'RFC2364') ** Obsolete normative reference: RFC 2472 (Obsoleted by RFC 5072, RFC 5172) ** Obsolete normative reference: RFC 2461 (Obsoleted by RFC 4861) ** Obsolete normative reference: RFC 2770 (Obsoleted by RFC 3180) ** Downref: Normative reference to an Experimental RFC: RFC 3618 == Outdated reference: A later version (-07) exists of draft-ooms-v6ops-bgp-tunnel-04 == Outdated reference: A later version (-24) exists of draft-ietf-ngtrans-isatap-12 == Outdated reference: A later version (-07) exists of draft-ietf-v6ops-mech-v2-06 == Outdated reference: A later version (-12) exists of draft-ietf-pim-sm-bsr-04 -- Unexpected draft version: The latest known version of draft-suryanarayanan-v6ops-zeroconf-reqs is -00, but you're referring to -01. Summary: 25 errors (**), 0 flaws (~~), 23 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 IPv6 Working Group Salman Asadullah 2 INTERNET DRAFT Adeel Ahmed 3 February 2005 Ciprian Popoviciu 4 Cisco Systems 6 ISP IPv6 Deployment Scenarios in Broadband Access Networks 7 9 Status of this Memo 11 This document is an Internet-Draft and is subject to all provisions 12 of section 3 of RFC3667. By submitting this Internet-Draft, each 13 author represents that any applicable patent or other IPR claims of 14 which he or she is aware have been or will be disclosed, and any of 15 which he or she become aware will be disclosed, in accordance with 16 RFC3668. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as 21 Internet-Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt. 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 This Internet-Draft will expire on March 27, 2005. 36 Abstract 38 This document provides detailed description of IPv6 deployment and 39 integration methods and scenarios in today's Service Provider (SP) 40 Broadband (BB) networks in coexistence with deployed IPv4 services. 42 Cable/HFC, BB Ethernet, xDSL and WLAN are the main BB technologies 43 that are currently deployed, and discussed in this document. In this 44 document we will discuss main components of IPv6 BB networks and 45 their differences from IPv4 BB networks and how IPv6 is deployed 46 and integrated in each of these BB technologies using tunneling 47 mechanisms and native IPv6. 49 Table of Contents: 50 1. Introduction..................................................3 51 2. IPv6 Based BB Services........................................3 52 3. Scope of the Document.........................................4 53 4. Core Backbone Network.........................................5 54 4.1 Layer 2 Access Provider....................................5 55 4.2 Layer3 Access Provider....................................6 56 5. Tunneling Options.............................................7 57 5.1 Access over Tunnels-customers with public IPv4 address....7 58 5.2 Access over Tunnels-customers with private IPv4 address...7 59 5.3 Transition a portion of the IPv4 infrastructure...........8 60 6. Broadband Cable Networks .....................................9 61 6.1 Broadband Cable Network Elements .........................9 62 6.2 Deploying IPv6 in Cable Networks.........................10 63 6.2.1 Bridged CMTS Network .............................11 64 6.2.2 Routed CMTS Network ..............................13 65 6.3 IPv6 Multicast ..........................................22 66 6.4 IPv6 QoS ................................................22 67 6.5 IPv6 Security Considerations.............................23 68 6.6 IPv6 Network Management .................................23 69 7. Broadband DSL Networks.......................................24 70 7.1 DSL Network Elements ....................................24 71 7.2 Deploying IPv6 in IPv4 DSL Networks......................25 72 7.2.1 Point-to-Point Model..............................26 73 7.2.2 PPP Terminated Aggregation (PTA) Model............27 74 7.2.3 L2TP Access Aggregation (LAA) Model...............30 75 7.2.4 Hybrid Model for IPv4 and IPv6 Service ...........33 76 7.3 IPv6 Multicast...........................................35 77 7.3.1 ASM Based Deployments..............................35 78 7.3.1 SSM Based Deployments..............................36 79 7.4 IPv6 QoS.................................................37 80 7.5 IPv6 Security Considerations.............................37 81 7.6 IPv6 Network Management..................................38 82 8. Broadband Ethernet Networks..................................38 83 8.1 Ethernet Access Network Elements .......................38 84 8.2 Deploying IPv6 in IPv4 BB Ethernet Networks.............39 85 8.2.1 Point-to-Point Model.............................40 86 8.2.2 PPP Terminated Aggregation (PTA) Model...........41 87 8.2.3 L2TP Access Aggregation (LAA) Model..............43 88 8.2.4 Hybrid Model for IPv4 and IPv6 Service...........45 89 8.3 IPv6 Multicast..........................................47 90 8.4 IPv6 QoS................................................48 91 8.5 IPv6 Security Considerations............................48 92 8.6 IPv6 Network Management.................................49 93 9. Broadband Wireless LAN Networks..............................49 94 9.1 WLAN Deployment Scenarios...............................49 95 9.1.1 Layer 2 Switch Between AP and SP Edge Router......51 96 9.1.2 Access Router Between AP and SP Edge Router......53 97 9.1.3 PPP Based Model..................................55 98 9.2 IPv6 Multicast..........................................57 99 9.3 IPv6 QoS................................................58 100 9.4 IPv6 Security Considerations............................59 101 9.5 IPv6 Network Management.................................59 103 10.Gap Analysis.................................................60 104 11.Contributors.................................................62 105 12.Acknowledgments..............................................62 106 13.References...................................................62 107 Authors Addresses...............................................64 109 1. Introduction 111 With the exponential growth of the Internet and increasing number of 112 end users, SPs are looking for new ways to evolve their current 113 network architecture to meet the needs of Internet ready appliances, 114 new applications and services. IPv6 is designed to enable SPs to meet 115 these challenges and provide new services to their customers. 117 As the number of devices per BB user increase exponentially 118 worldwide, Cable, DSL, Ethernet to the Home, Wireless and other 119 always-on access technologies can benefit from the huge address 120 range [RFC3513] of IPv6. Other benefits of IPv6 include the 121 capability to enhance end-to-end security, mobile communications, 122 and ease system management burdens. Some examples include 123 peer-to-peer communication without NAT traversal problems, being 124 able to access securely devices at home from work, enhanced IP 125 Mobility [RFC3775] and so on. 127 Therefore SPs are aggressively evaluating the capabilities of IPv6 128 to meet these needs. Some countries have taken a lead role in this 129 race and moved from testing and evaluation to real deployments of 130 IPv6 in the BB arena. Japan is a prime example along with other 131 countries that are looking at moving towards large scale production 132 deployments of IPv6. 134 The SPs are deploying tunneling mechanisms to transport IPv6 over 135 their existing IPv4 networks as a start as well as deploying native 136 IPv6 where possible. Deployment of tunneling solutions is simpler, 137 easier and more economical to start the IPv6 services, as they 138 require minimal investments and network infrastructure changes in 139 current SP model. Depending on customer needs and requirements a 140 native IPv6 deployment option might be more scalable and provide 141 required service performance. 143 2. IPv6 Based BB Services 145 At this point IPv6 based services are seen as a differentiator that 146 enables SPs to take advantage of the large IPv6 address space to 147 the extent that subscribers get fixed /64 prefixes versus the single, 148 temporary IPv4 addresses. Such resources allow the SPs to better 149 position themselves against the competition. The IPv6 deployments 150 can be seen as a driver for lower service support costs by 151 eliminating NAT with its negative impact on applications and its 152 complex behavior. Another reason of IPv6 being very popular in some 153 countries is the government driven financial incentives and favorable 154 legislation toward the ISPs who are deploying IPv6. 156 NTT East, Japan started a commercial dual-stack (devices capable of 157 forwarding IPv4 and IPv6 packets) IPv6 unicast service option early 158 this year for its ADSL and FTTH subscribers, under the name of 159 FLETS.Net [Dual Stack Access]. 161 For these users the IPv6 addresses are dedicated (/64 per user) and 162 are used when needed. However, this IPv6 service is available only 163 to the NTT-East ADSL and FTTH subscribers who are part of FLETS.NET 164 network and at this point does not provide connectivity to the 165 IPv6 Internet. 167 The list of BB SPs that have deployed IPv6 services contains names 168 such as: SpaceNet in Germany, Dolphin in Switzerland, Nerim in 169 France and XS4ALL in The Netherlands. 171 Some ISPs that are currently providing IPv4 based Multicast and 172 VoIP services are evaluating IPv6 to take advantage of the huge 173 address space and other useful features. The Multicast services 174 consist of video and audio streaming of several programs (streams). 175 The content provider will have certain content (which is of user 176 interest) and they would send these multicast streams to BB 177 subscribers. Today, when done through IPv4, there is generally a 178 single device directly attached to the CPE that receives the 179 Multicast stream. By moving to IPv6, ISP should be capable to 180 provide multiple streams to multiple devices on the customer site. 182 For instance in Japan, Cable TV and dish services are not very 183 popular, the users expect everything through the broadcasted, free 184 programs (traditional TV). In case of BB users however, they can get 185 some extra content through the SP, which is very reasonably priced 186 for 20 Mbps or 10/100 Mbps of bandwidth. Users sign up with a content 187 provider that is multicasting several channels of video and audio. A 188 subscriber would join the multicast group of interest (after 189 authentication) and will start receiving the stream(s). An example of 190 a video stream could be Disney movies and an example of an audio 191 stream could be Karaoke (part of same *,G group). Similar to Cable 192 TV, where customers sign up and pay for single programs or packages 193 of programs. 195 SPs are also offering IPv6 services over wireless links using 802.11 196 compliant WiFi Hot Spots. This enables users to take notebook PCs and 197 PDAs (Windows 2003 supports IPv6 capable Internet Explorer and Media 198 Player 9) along with them and connect to the Internet from various 199 locations without the restriction of staying indoors. 201 3. Scope of the Document 203 The focus of this document is to present the options available in 204 deploying IPv6 services in the access portion of a BB Service 205 Provider network namely Cable/HFC, BB Ethernet, xDSL and WLAN. 207 This document briefly discusses the other elements of a provider 208 network as well. It provides different viable IPv6 deployment and 209 integration techniques and models for each of the above mentioned BB 210 technologies separately. The example list is not exhaustive but it 211 tries to be representative. 213 This document analyzes, how all the important parts of current IPv4 214 based Cable/HFC, BB Ethernet, xDSL and WLAN networks will behave 215 when IPv6 is integrated and deployed. 217 The following important pieces are discussed: 219 A. Available tunneling options 220 B. Devices that would require to be upgraded to support IPv6 221 C. Available IPv6 address assignment techniques and their use 222 D. Possible IPv6 Routing options and their use 223 E. IPv6 unicast and multicast packet transmission 224 F. Required IPv6 QoS parameters 225 G. Required IPv6 Security parameters 226 H. Required IPv6 Network Management parameters 228 It is important to note that the addressing rules provided throughout 229 this document represent an example that follows the current 230 assignment policies and recommendations of the registries. They can 231 be however adapted to the network and business model needs of the 232 ISPs. 234 4. Core/Backbone Network 236 This section intends to briefly discuss the some important elements 237 of a provider network tied to the deployment of IPv6. A more detailed 238 description of the core network is provided in other documents [ISP 239 Networks IPv6 Scenarios]. 241 There are two networks identified in the Broadband deployments: 243 A. Access Provider Network: This network provides the broadband 244 access and aggregates the subscribers. The subscriber traffic is 245 handed over to the Service Provider at Layer 2 or 3. 246 B. Service Provider Network: This network provides Intranet and 247 Internet IP connectivity for the subscribers. 249 The Service Provider network structure beyond the Edge routers that 250 interface with the Access provider is beyond the scope of this 251 document. 253 4.1 Layer 2 Access Provider Network 255 The Access Provider can deploy a Layer 2 network and perform no 256 routing of the subscriber traffic to the SP. The devices 257 that support each specific access technology are aggregated into a 258 highly redundant, resilient and scalable layer two core. The network 259 core can involve various technologies such as Ethernet, ATM etc. 260 The Service Provider Edge Router connects to the Access Provider 261 core. 263 In this type of a network the impact of deploying IPv6 is minimal. 264 The network is transparent to the Layer 3 protocol. The only possible 265 changes would come with the intent of filtering and monitoring IPv6 266 traffic based on layer 2 information such as IPv6 Ether Type Protocol 267 ID (0x86DD) or IPv6 multicast specific MAC addresses 268 (3333.xxxx.xxxx). 270 4.2 Layer3 Access Provider Network 272 The Access Provider can choose to terminate the Layer 2 domain and 273 route the IP traffic to the Service Provider network. Access Routers 274 are used to aggregate the subscriber traffic and route it over a 275 Layer3 core to the SP Edge Routers. In this case the impact of the 276 IPv6 deployment is significant. 278 The case studies in this document only present the significant 279 network elements of such a network: Customer Premises Equipment, 280 Access Router and Edge Router. In real networks the link between the 281 Access Router and the Edge Router involves other routers that are 282 part of the aggregation and the core layer of the Access Provider 283 network. 285 The Access Provider can forward the IPv6 traffic through its layer3 286 core in three possible ways: 288 A. IPv6 Tunneling: As a temporary solution, the Access Providers can 289 choose to use a tunneling mechanism to forward the subscriber IPv6 290 traffic to the Service Provider Edge Router. This approach has the 291 least impact on the Access Provider network however, as the number of 292 users increase and the amount of IPv6 traffic grows, the ISP will 293 have to evolve to one of the scenarios listed below. 295 B. Native IPv6 Deployment: The Access Provider routers are upgraded 296 to support IPv6 and can become dual-stack. In a dual-stack network 297 an IPv6 IGP such as OSPFv3 or IS-IS is enabled, usually mapping the 298 IGP deployed for IPv4. The most important thing to remember in this 299 case is that the device resources are now shared between IPv4 and 300 IPv6 processes. This problem could be eliminated with the use of 301 ISIS-MT (multi-topology) where a single database and SPF is used for 302 IPv4 and IPv6. 304 C. MPLS 6PE Deployment [6PE]: If the Access Provider is running MPLS 305 in its IPv4 core it could use 6PE to forward IPv6 traffic over its. 306 In this case only a subset of routers close to the edge of the 307 network need to be IPv6 aware. With this approach BGP becomes 308 important in order to support 6PE. 310 The 6PE approach has the advantage of having minimal impact on the 311 Access Provider network. Fewer devices need to be upgraded and 312 configured while the MPLS core continues to switch the traffic 313 un-aware of the fact that it transports both IPv4 and IPv6 traffic. 314 6PE should be leveraged only if MPLS is already deployed in the 315 network. At the time of writing this document, a major disadvantage 316 of the 6PE solution is the fact that it does not support multicast 317 IPv6 traffic. 319 The native approach has the advantage of supporting IPv6 320 multicast traffic but it may imply a significant impact on the IPv4 321 operational network from software, configuration and possibly 322 hardware upgrade perspective. 324 More detailed Core Network deployment recommendations are discussed 325 in other documents [ISP Networks IPv6 Scenarios]. The handling of 326 IPv6 traffic in the Core of the Access Provider Network will not be 327 discussed for the remainder of this document. 329 5. Tunneling Overview 331 Service Providers might not be able to deploy native IPv6 today due 332 to the cost associated with HW and SW upgrades, the infrastructure 333 changes needed to their current network and the current demand for 334 the service. For these reasons, some SPs might choose tunneling 335 based transition mechanisms to start an IPv6 service offering and 336 move to native IPv6 deployment at a later time. 338 Several tunneling mechanisms were developed specifically 339 to transport IPv6 over existing IPv4 infrastructures. Several of 340 them have been standardized and their use depends on the existing SP 341 IPv4 network and the structure of the IPv6 service. The 342 requirements for the most appropriate mechanisms are described in 343 [Assisted Tunneling] and [ZeroConf] with more updates to follow. 344 Deploying IPv6 using tunneling techniques can imply as little 345 changes to the network as upgrading SW on tunnel end points. 346 A Service Provider could use tunneling to deploy IPv6 in the 347 following scenarios: 349 5.1 Access over Tunnels-customers with Public IPv4 Address 351 If the customer is a residential user, it can initiate the tunnel 352 directly from the IPv6 capable host to a tunnel termination router 353 located in the NAP or ISP network. The tunnel type used should be 354 decided by the SP but it should take into consideration its 355 availability on commonly used software running on the host machine. 356 Out of the many tunneling mechanisms developed [RFC3053, RFC3056, 357 RFC2473, ISATAP, RFC2893, RFC2529] some are more popular than the 358 others. 360 If the end customer has a GWR installed, then it could be used to 361 originate the tunnel and thus offer native IPv6 access to multiple 362 hosts on the customer network. In this case the GWR would need to be 363 upgraded to dual-stack in order to support IPv6. The GWR can be owned 364 by the customer or by the SP. 366 5.2 Access over Tunnels-Customers with Private IPv4 Address 368 If the end customer receives a private IPv4 address and its hosts 369 need to go through a NAT, tunneling techniques like 6to4 will not 370 work since they rely on Public IPv4 address. In this case the end 371 user might have to use tunnels that can operate through NATs (such 372 as Teredo tunnel [OPS]). 374 The customer has the option to initiate the tunnel from the device 375 (GWR) that performs the NAT functionality, similar to the GWR 376 scenario discussed in section 5.1. This will imply HW replacement or 377 SW upgrade and a native IPv6 environment behind the GWR. 379 It is important to note that the customers of a Service Provider can 380 choose to establish tunnels to publicly available and free tunnel 381 services. Even though the quality of such services might not be high, 382 they provide free IPv6 access. In designing their IPv6 services, the 383 SPs should take into considerations such options available to their 384 potential customers. The IPv6 deployment should support services 385 (like multicast, VoIPv6 etc) and a level of quality that would make 386 the access through the SP worthwhile to potential subscribers. 388 It is also worth observing that initiating an IPv6 tunnel over IPv4 389 through already established IPv4 IPsec sessions would provide a 390 certain level of security to the IPv6 traffic [Tunnel through IPsec]. 392 5.3 Transition a Portion of the IPv4 Infrastructure 394 Tunnels can be used to transport the IPv6 traffic across a defined 395 segment of the network. As an example, the customer might connect 396 natively to the Network Access Provider and a tunnel is used to 397 transit the traffic over IPv4 to the ISP. In this case the tunnel 398 choice depends on its capabilities (for example, whether it supports 399 multicast or not), routing protocols used (GRE is the only tunnel 400 type which can transport layer 2 messages as well), manage-ability 401 and scalability (dynamic versus static tunnels). 403 This scenario implies that the access portion of the network has been 404 upgraded to support dual stack so the savings provided by tunneling 405 in this scenario are very small compared with the previous two. 406 Depending on the number of sites requiring the service and 407 considering the expenses required to manage the tunnels (some tunnels 408 are static while others are dynamic [Dynamic Tunnel]) in this case, 409 the SPs might find the native approach worth the additional 410 investments. 412 In all the scenarios listed above the tunnel selection process should 413 consider the IPv6 multicast forwarding capabilities if such service 414 is planned. As an example, 6to4 tunnels do not support IPv6 multicast 415 traffic. 417 The operation, capabilities and deployment of various tunnel types 418 has been discussed extensively in the documents referenced earlier as 419 well as in [OPS, RFC3904]. Details of a tunnel based deployment are 420 offered in the next section of this document (section 6). In the case 421 of Cable Access where the current DOCSIS specifications do not 422 provide support for native IPv6 access. Although sections 7, 8 and 9 423 focus on a native IPv6 deployments over DSL, FTTH and Wireless 424 because this approach is fully supported today, tunnel based 425 solutions are also possible in these cases based on the guidelines 426 of this section and some of the recommendations provided in section 427 6. 429 6. Broadband Cable Networks 431 This section describes the infrastructure that exists today in 432 cable networks providing BB services to the home. It also describes 433 IPv6 deployment options in these cable networks. 435 DOCSIS standardizes and documents the operation of data over Cable 436 Networks. The current version of DOCSIS has limitations that do not 437 allow for a smooth implementation of native IPv6 transport. Some of 438 these limitations are discussed in this section. For this reason, 439 the IPv6 deployment scenarios discussed in this section for the 440 existent Cable Networks are tunnel based. The tunneling examples 441 presented here could also be applied to the other BB technologies 442 described in sections 7, 8 and 9. 444 6.1 Broadband Cable Network Elements 446 Broadband cable networks are capable of transporting IP traffic to/ 447 from users to provide high speed Internet access and VOIP services. 448 The mechanism of transporting IP traffic over cable networks is 449 outlined in the DOCSIS specification [RF Interface]. 451 Here are some of the key elements of a Cable network: 453 Cable (HFC) Plant: Hybrid Fiber Coaxial plant, used as the underlying 454 transport 456 CMTS: Cable Modem Termination System (can be a Layer 2 bridging or 457 Layer 3 routing CMTS) 459 GWR: Residential Gateway Router (provides Layer 3 services to hosts) 461 Host: PC, notebook etc. which is connected to the CM or GWR 463 CM: Cable Modem 465 ER: Edge Router 467 MSO: Multiple Service Operator 469 Data Over Cable Service Interface Specification (DOCSIS): The 470 standards defining how data should be carried over cable networks. 472 Figure 9.1 illustrates the key elements of a Cable Network 474 <--- ACCESS ---><------ HFC ------><----- Aggregation / Core -----> 475 +-----+ +------+ 476 |Host |--| GWR | 477 +-----+ +--+---+ 478 | _ _ _ _ _ _ 479 +------+ | | 480 | CM |---| | 481 +------+ | | 482 | HFC | +------+ +--------+ 483 | | | | | Edge | 484 +-----+ +------+ | Network |---| CMTS |---| |===> ISP 485 |Host |--| CM |---| | | | | Router | Network 486 +-----+ +--+---+ | | +------+ +--------+ 487 |_ _ _ _ _ _| 488 +------+ | 489 +-----+ | GWR/ | | 490 |Host |--| CM |---------+ 491 +-----+ | | 492 +------+ Figure 6.1 494 6.2 Deploying IPv6 in Cable Networks 496 One of the motivators for an MSO to deploy IPv6 over their Cable 497 Network is to ease management burdens. IPv6 can be enabled on the 498 host, CM, CMTS and ER for management purposes. Currently portions of 499 the cable infrastructure use RFC1918 IPv4 addresses; however, there 500 are a finite number of those. Thus, IPv6 could have utility in the 501 cable space implemented on the control plane initially and later on 502 focused on the data plane for end user services. 504 There are two different deployment modes in current cable networks: 505 a bridged CMTS environment and a routed CMTS environment. IPv6 can 506 be deployed in both of these environments. 508 1. Bridged CMTS Network 510 In this scenario, both the CM and CMTS bridge all data traffic. 511 Traffic to/from host devices is forwarded through the cable network 512 to the ER. The ER then routes traffic through the ISP network to the 513 Internet. The CM and CMTS support a certain degree of Layer 3 514 functionality for management purposes. 516 2. Routed CMTS Network 518 In a routed network, the CMTS forwards IP traffic to/from hosts 519 based on Layer 3 information using the IP source/destination address. 520 The CM acts as a Layer-2 bridge for forwarding data traffic and 521 supports some Layer 3 functionality for management purposes. 523 Some of the factors that hinder deployment of native IPv6 in current 524 cable networks include: 526 A. Problems with IPv6 Neighbor Discovery (ND) on CM and CMTS. These 527 devices rely on IGMP join messages to track membership of hosts that 528 are part of a particular IP Multicast group. In order to support ND 529 the CM and CMTS will need to support IGMPv3/MLDv1 or v2 snooping. 531 B. Classification of IPv6 traffic in the upstream and downstream 532 direction. The CM and CMTS will need to support classification of 533 IPv6 packets in order to give them the appropriate priority and 534 QoS. Without proper classification all IPv6 traffic will need to be 535 sent best effort (BE) which can cause problems when deploying 536 services like VOIP and IP Multicast video. 538 C. Changes need to be made to the DOCSIS specification to include 539 support for IPv6 on the CM and CMTS. This is imperative for 540 deploying native IPv6 over cable networks. 542 Due to the above mentioned limitations in deployed cable networks, 543 the only available option to cable operators is to use tunneling 544 techniques in order to transport IPv6 traffic over their current 545 IPv4 infrastructure. The following sections will cover these 546 deployment scenarios in more detail. 548 6.2.1 Deploying IPv6 in a Bridged CMTS Network 550 In IPv4 the CM and CMTS act as Layer 2 bridges and forward all data 551 traffic to/from the hosts and the ER. The hosts use the ER as their 552 Layer 3 next hop. If there is a GWR behind the CM it can act as a 553 next hop for all hosts and forward data traffic to/from the ER. 555 When deploying IPv6 in this environment, the CM and CMTS will 556 continue to be bridging devices in order to keep the transition 557 smooth and reduce operational complexity. The CM and CMTS will need 558 to bridge IPv6 unicast and multicast packets to/from the ER and the 559 hosts. If there is a GWR connected to the CM, it will need to forward 560 IPv6 unicast and multicast traffic to/from the ER. 562 Figure 6.2.1 illustrate the IPv6 deployment scenario 564 +-----+ +-----+ 565 |Host |--| GWR | 566 +-----+ +--+--+ 567 | _ _ _ _ _ _ 568 | +------+ | | 569 +--| CM |---| | 570 +------+ | | 571 | HFC | +------+ +--------+ 572 | | | | | Edge | 573 +-----+ +------+ | Network |---| CMTS |---| |===> ISP 574 |Host |--| CM |---| | | | | Router | Network 575 +-----+ +------+ | | +------+ +--------+ 576 |_ _ _ _ _ _| 578 <-------------><---------------------------------><---------------> 579 L3 Routed L2 Bridged L3 Routed 581 Figure 6.2.1 583 6.2.1.1 IPv6 Related Infrastructure Changes 585 In this scenario the CM and the CMTS bridge all data traffic so they 586 will need to support bridging of native IPv6 unicast and multicast 587 traffic. The following devices have to be upgraded to dual stack: 588 Host, GWR and ER. 590 6.2.1.2 Addressing 592 The proposed architecture for IPv6 deployment includes two components 593 that must be provisioned: the CM and the host. Additionally if there 594 is a GWR connected to the CM, it will also need to be provisioned. 595 The host or the GWR use the ER as their Layer 3 next hop. 597 6.2.1.2.1 IP Addressing for CM 599 The CM will be provisioned in the same way as in currently deployed 600 cable networks, using an IPv4 address on the cable interface 601 connected to the MSO network for management functions. During the 602 initialization phase, it will obtain its IPv4 address using DHCPv4, 603 and download a DOCSIS configuration file identified by the DHCPv4 604 server. 606 6.2.1.2.2 IP Addressing for Hosts 608 If there is no GWR connected to the CM, the host behind the CM will 609 get a /64 prefix assigned to it via stateless autoconfiguration or 610 DHCPv6. 612 If using stateless auto-configuration, the host listens for routing 613 advertisements (RA) from the ER. The RAs contain the /64 prefix 614 assigned to the segment. Upon receipt of an RA, the host constructs 615 its IPv6 address by combining the prefix in the RA (/64) and a unique 616 identifier (e.g., its modified EUI-64 format interface ID). 618 If DHCPv6 is used to obtain an IPv6 address, it will work in much 619 the same way as DHCPv4 works today. The DHCPv6 messages exchanged 620 between the host and the DHCPv6 server are bridged by the CM and 621 the CMTS. 623 6.2.1.2.3 IP Addressing for GWR 625 The GWR can use stateless auto-configuration (RA) to obtain an 626 address for its upstream interface, the link between itself and 627 the ER. This step is followed by a request via DHCP-PD for a prefix 628 shorter than /64, typically /48, which in turn is divided into /64s 629 and assigned to its downstream interfaces connecting to the hosts. 631 6.2.1.3 Data Forwarding 633 The CM and CMTS must be able to bridge native IPv6 unicast and 634 multicast traffic. The CMTS must provide IP connectivity between 635 hosts attached to CMs and must do so in a way that meets the 636 expectation of Ethernet attached customer equipment. In order to do 637 that, the CMTS must either forward Neighbor Discovery (ND) packets 638 or provide a proxy ND service. 640 Communication between hosts behind different CMs is always forwarded 641 through the CMTS. IPv6 communication between the different sites 642 relies on multicast IPv6 ND [RFC2461] frames being forwarded correctly 643 by the CM and the CMTS. As with the CM, a bridged CMTS that selectively 644 forwards multicast datagrams on the basis of IGMPv2 will potentially 645 break IPv6 ND. 647 In order to support IPv6 multicast applications across DOCSIS cable 648 networks, the CM and bridging CMTS need to support IGMPv3/MLDv2 649 snooping. MLD is almost identical to IGMP in IPv4, only the name and 650 numbers are changed. MLDv2 is identical to IGMPv3 and also supports 651 ASM (Any Source Multicast) and SSM (Single Source Multicast) service 652 models. Implementation work on CM/CMTS should be minimal because the 653 only significant difference between IPv4 IGMPv3 and IPv6 MLDv2 is the 654 longer addresses in the protocol. 656 6.2.1.4 Routing 658 The hosts install a default route that points to the ER or the GWR. 659 No routing protocols are needed on these devices which generally have 660 limited resources. If there is a GWR present it will also use static 661 default route to the ER. 663 The ER runs an IGP such as OSPFv3 or IS-IS. The connected prefixes 664 have to be redistributed. If DHCP-PD is used, with every delegated 665 prefix a static route is installed by the ER. For this reason the 666 static routes must also be redistributed. Prefix summarization 667 should be done at the ER. 669 6.2.2 Deploying IPv6 in a Routed CMTS Network 671 In an IPv4 routed CMTS network the CM still acts as a Layer-2 672 device and bridges all data traffic between its Ethernet interface 673 and cable interface connected to the cable operator network. The CMTS 674 acts as a Layer 3 router and may also include the ER functionality. 675 The hosts and the GWR use the CMTS as their Layer 3 next hop. 677 When deploying IPv6 in a routed CMTS network, the CM still acts 678 as a Layer-2 device and will need to bridge IPv6 unicast as well as 679 multicast traffic. The CMTS/ER will need to either tunnel IPv6 680 traffic or natively support IPv6. The host and GWR will use the 681 CMTS/ER as their Layer 3 next hop. 683 There could be five possible deployment scenarios for IPv6 in a 684 routed CMTS network: 686 1. IPv4 Cable (HFC) Network 688 In this scenario the cable network, including the CM and CMTS remain 689 IPv4 devices. The host and ER are upgraded to dual-stack. This is the 690 easiest way for a Cable Operator to provide IPv6 service as no 691 changes are made to the cable network. 693 2. IPv4 Cable (HFC) Network, GWR at Customer Site 695 In this case the cable network, including the CM and CMTS remain 696 IPv4 devices. The host, GWR and ER are upgraded to dual-stack. This 697 scenario is also easy to deploy since the cable operator just needs 698 to add GWR at the customer site. 700 3. Dual-stacked Cable (HFC) Network, CM and CMTS Support IPv6 702 In this scenario the CMTS is upgraded to dual-stack to support IPv4 703 and IPv6. Since the CMTS supports IPv6 it can acts as an ER as well. 704 The CM will act as a Layer-2 bridge but will need to bridge IPv6 705 unicast and multicast traffic. This scenario is not easy to deploy 706 since it requires changes to the DOCSIS specification. The CM and 707 CMTS may require HW and SW upgrades to support IPv6. 709 4. Dual-stacked Cable (HFC) Network, Standalone GWR and CMTS Support 710 IPv6 712 In this scenario there is a standalone GWR connected to the CM. 713 Since the IPv6 functionality exists on the GWR the CM does not need 714 to be dual-stack. The CMTS is upgraded to dual-stack and it can 715 incorporate the ER functionality. This scenario may also require HW 716 and SW changes on the GWR and CMTS. 718 5. Dual-stacked Cable (HFC) Network, Embedded GWR/CM and CMTS Support 719 IPv6 721 In this scenario the CM and GWR functionality exists on a single 722 device which needs to be upgraded to dual-stack. The CMTS will also 723 need to be upgraded to a dual-stack device. This scenario is also 724 difficult to deploy in existent cable network since it requires 725 changes on the Embedded GWR/CM and the CMTS. 727 The DOCSIS specification will also need to be modified to allow 728 native IPv6 support on the Embedded GWR/CM. 730 6.2.2.1 IPv4 Cable Network, Host and ER Upgraded to Dual-Stack 732 This is one of the most cost effective ways for a Cable Operator to 733 offer IPv6 services to its customers. Since the cable network remains 734 IPv4 there is relatively minimal cost involved in turning up IPv6 735 service. All IPv6 traffic is exchanged between the hosts and the ER. 737 Figure 6.2.2.1 illustrates this deployment scenario 739 +-----------+ +------+ +--------+ 740 +-----+ +-------+ | Cable | | | | Edge | 741 |Host |--| CM |----| (HFC) |----| CMTS |----| |=>ISP 742 +-----+ +-------+ | Network | | | | Router | Network 743 +-----------+ +------+ +--------+ 744 _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ 745 ()_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _() 746 IPv6-over-IPv4 tunnel 748 <---------><----------------------------------------><------------> 749 IPv4/v6 IPv4 only IPv4/v6 751 Figure 6.2.2.1 753 6.2.2.1.1 IPv6 Related Infrastructure Changes 755 In this scenario the CM and the CMTS will only need to support IPv4 756 so no changes need to be made to them or the cable network. The 757 following devices have to be upgraded to dual stack: Host and ER. 759 6.2.2.1.2 Addressing 761 The only device that needs to be assigned an IPv6 address at customer 762 site is the host. Host address assignment can be done in multiple 763 ways. Depending on the tunneling mechanism used it be automatic or 764 might require manual configuration.. 766 The host still receives an IPv4 address using DHCPv4, which works 767 the same way in currently deployed cable networks. In order to get 768 IPv6 connectivity, host devices will also need an IPv6 address and 769 a means to communicate with the ER. 771 6.2.2.1.3 Data Forwarding 773 All IPv6 traffic will be sent to/from the ER and the host device. In 774 order to transport IPv6 packets over the cable operator IPv4 775 network, the host and the ER will need to use one of the available 776 IPv6 over IPv4 tunneling mechanisms. 778 The host will use its IPv4 address to source the tunnel to the 779 ER. All IPv6 traffic will be forwarded to the ER, encapsulated in 780 IPv4 packets. The intermediate IPv4 nodes will forward this traffic 781 as regular IPv4 packets. The ER will need to terminate the tunnel 782 and/or provide other IPv6 services. 784 6.2.2.1.4 Routing 786 Routing configuration on the host will vary depending on 787 the tunneling technique used, in some cases a default or static 788 route might be needed to forward traffic to the next hop. 790 The ER runs an IGP such as OSPFv3 or ISIS. 792 6.2.2.2 IPv4 Cable Network, Host, GWR and ER Upgraded to Dual-Stack 794 The cable operator can provide IPv6 services to its customers, in 795 this scenario, by adding a GWR behind the CM. Since the GWR will 796 facilitate all IPv6 traffic to/from the host and the ER, the cable 797 network including the CM and CMTS do not need to support IPv6 and 798 can remain IPv4 devices. 800 Figure 6.2.2.2 illustrates this deployment scenario 802 +-----+ 803 |Host | 804 +--+--+ 805 | +-----------+ +------+ +--------+ 806 +---+---+ +-------+ | Cable | | | | Edge | 807 | GWR |--| CM |----| (HFC) |----| CMTS |----| |=>ISP 808 +-------+ +-------+ | Network | | | | Router | Network 809 +-----------+ +------+ +--------+ 810 _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ 811 ()_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _() 812 IPv6-over-IPv4 tunnel 814 <---------><---------------------------------------><-------------> 815 IPv4/v6 IPv4 only IPv4/v6 817 Figure 6.2.2.2 819 6.2.2.2.1 IPv6 Related Infrastructure Changes 821 In this scenario the CM and the CMTS will only need to support IPv4 822 so no changes need to be made to them or the cable network. The 823 following devices have to be upgraded to dual stack: Host, GWR and 824 ER. 826 6.2.2.2.2 Addressing 828 The only devices that needs to be assigned an IPv6 address at 829 customer site are the host and GWR. IPv6 address assignment can be 830 done statically at the GWR downstream interface. The GWR will send 831 out RA messages on its downstream interface which will be used by the 832 hosts to auto-configure themselves with an IPv6 address. The GWR can 833 also configure its upstream interface using RA messages from the ER 834 and use DHCP-PD for requesting a /48 prefix from the ER. This /48 835 prefix will be used to configure /64s on hosts connected to the GWR 836 downstream interfaces. Currently the DHCP-PD functionality cannot be 837 implemented if the DHCP-PD server is not the Edge Router. If the 838 DHCP-PD messages are relayed, the Edge Router does not have a 839 mechanism to learn the assigned prefixes and thus install the proper 840 routes to make that prefix reachable. Work is being done to address 841 this issue, one idea being to provide the Edge Router with a snooping 842 mechanism. The uplink to the ISP network is configured with a /64 843 prefix as well. 845 The GWR still receives a global IPv4 address on its upstream 846 interface using DHCPv4, which works the same way in currently 847 deployed cable networks. In order to get IPv6 connectivity to the 848 Internet the GWR will need to communicate with the ER. 850 6.2.2.2.3 Data Forwarding 852 All IPv6 traffic will be sent to/from the ER and the GWR, which will 853 forward IPv6 traffic to/from the host. In order to transport IPv6 854 packets over the cable operator IPv4 network, the GWR and the ER 855 will need to use one of the available IPv6 over IPv4 tunneling 856 mechanisms. All IPv6 traffic will need to go through the tunnel, once 857 it comes up. 859 The GWR will use its IPv4 address to source the tunnel to the ER. 860 The tunnel endpoint will be the IPv4 address of the ER. All IPv6 861 traffic will be forwarded to the ER, encapsulated in IPv4 packets. 862 The intermediate IPv4 nodes will forward this traffic as regular IPv4 863 packets. In case of 6to4 tunneling, the ER will need to support 864 6to4 relay functionality in order to provide IPv6 Internet 865 connectivity to the GWR and hence the hosts connected to the GWR. 867 6.2.2.2.4 Routing 869 Depending on the tunneling technique used there might some 870 configuration needed on the GWR and the ER. If the ER is also 871 providing a 6to4 relay service then a default route will need to be 872 added to the GWR pointing to the ER, for all non-6to4 traffic. 874 If using manual tunneling, the GWR and ER can use static routing or 875 they can also configure RIPng. The RIPng updates can be transported 876 over a manual tunnel, which does not work when using 6to4 tunneling. 878 Customer routes can be carried to the ER using RIPng updates. The ER 879 can advertise these routes in its IGP. Prefix summarization should be 880 done at the ER. 882 If DHCP-PD is used for address assignment a static route is 883 automatically installed on the CMTS/ER for each delegated /48 prefix. 884 The static routes need to be redistributed into the IGP at the 885 CMTS/ER, so there is no need for a routing protocol between the 886 CMTS/ER and the GWR. 888 The ER runs an IGP such as OSPFv3 or ISIS. 890 6.2.2.3 Dual-stacked Cable (HFC) Network, CM and CMTS Support IPv6 891 In this scenario the Cable Operator can offer native IPv6 services 892 to its customers since the cable network including the CMTS supports 893 IPv6. The ER functionality can be included in the CMTS or it can 894 exist on a separate router connected to the CMTS upstream interface. 895 The CM will need to bridge IPv6 unicast and multicast traffic. 897 Figure 6.2.2.3 illustrates this deployment scenario 899 +-----------+ +-------------+ 900 +-----+ +-------+ | Cable | | CMTS / Edge | 901 |Host |--| CM |----| (HFC) |----| |=>ISP 902 +-----+ +-------+ | Network | | Router | Network 903 +-----------+ +-------------+ 905 <-------><----------------------------><----------------> 906 IPv4/v6 IPv4/v6 IPv4/v6 908 Figure 6.2.2.3 910 6.2.2.3.1 IPv6 Related Infrastructure Changes 912 Since the CM still acts as a Layer-2 bridge, it does not need to 913 be dual-stack. The CM will need to support bridging of IPv6 unicast 914 and multicast traffic and IGMPv3/MLDv1 or v2 snooping which requires 915 changes in the DOCSIS specification. In this scenario the following 916 devices have to be upgraded to dual stack: Host and CMTS/ER. 918 6.2.2.3.2 Addressing 920 In today's cable networks the CM receives a private IPv4 address 921 using DHCPv4 for management purposes. In an IPv6 environment, the 922 CM will continue to use an IPv4 address for management purposes. 923 The cable operator can also choose to assign an IPv6 address to the 924 CM for management, but the CM will have to be upgraded to support 925 this functionality. 927 IPv6 address assignment for the CM and host can be done via DHCP or 928 stateless autoconfiguration. If the CM uses an IPv4 address for 929 management, it will use DHCPv4 for its address assignment and the 930 CMTS will need to act as a DHCPv4 relay agent. If the CM uses an IPv6 931 address for management, it can use DHCPv6 with the CMTS acting as a 932 DHCPv6 relay agent or the CMTS can be statically configured with a 933 /64 prefix and it can send out RA messages out the cable interface. 934 The CMs connected to the cable interface can use the RA messages to 935 auto-configure themselves with an IPv6 address. All CMs connected to 936 the cable interface will be in the same subnet. 938 The hosts can receive their IPv6 address via DHCPv6 or stateless 939 autoconfiguration. With DHCPv6, the CMTS may need to act as a DHCPv6 940 relay agent and forward DHCP messages between the hosts and the DHCP 941 server. With stateless autoconfiguration, the CMTS will be configured 942 with multiple /64 prefixes and send out RA messages to the hosts. 943 If the CMTS is not also acting as an ER, the RA messages will come 944 from the ER connected to the CMTS upstream interface. The CMTS will 945 need to forward the RA messages downstream or act as an ND proxy. 947 6.2.2.3.3 Data Forwarding 949 All IPv6 traffic will be sent to/from the CMTS and hosts. Data 950 forwarding will work the same way it works in currently deployed 951 cable networks. The CMTS will forward IPv6 traffic to/from hosts 952 based on the IP source/destination address. 954 6.2.2.3.4 Routing 956 No routing protocols are needed between the CMTS and the host 957 since the CM and host are directly connected to the CMTS cable 958 interface. Since the CMTS supports IPv6, hosts will use the CMTS 959 as their Layer 3 next hop. 961 If the CMTS is also acting as an ER, it runs an IGP such as OSPFv3 962 or ISIS. 964 6.2.2.4 Dual-Stacked Cable (HFC) Network, Standalone GWR and CMTS 965 Support IPv6 967 In this case the cable operator can offer IPv6 services to its 968 customers by adding a GWR between the CM and the host. The GWR will 969 facilitate IPv6 communication between the host and the CMTS/ER. The 970 CMTS will be upgraded to dual-stack to support IPv6 and can acts as 971 an ER as well. The CM will act as a bridge for forwarding data 972 traffic and does not need to support IPv6. 974 This scenario is similar to the case described in section 6.2.2.2. 975 The only difference in this case is the ER functionality exists on 976 the CMTS instead of a separate router in the cable operator network. 978 Figure 6.2.2.4 illustrates this deployment scenario 980 +-----------+ +------------+ 981 +------+ +-------+ +-------+ | Cable | |CMTS / Edge | 982 | Host |---| GWR |--| CM |---| (HFC) |----| |=>ISP 983 +------+ +-------+ +-------+ | Network | | Router |Network 984 +-----------+ +------------+ 986 _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ 987 ()_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _() 988 IPv6-over-IPv4 tunnel 989 <-----------------><--------------------------------><--------------> 990 IPv4/v6 IPv4 IPv4/v6 992 Figure 6.2.2.4 994 6.2.2.4.1 IPv6 Related Infrastructure Changes 996 Since the CM still acts as a Layer-2 bridge, it does not need to 997 be dual-stack nor does it need to support IPv6. In this scenario 998 the following devices have to be upgraded to dual stack: Host, GWR 999 and CMTS/ER. 1001 6.2.2.4.2 Addressing 1003 The CM will still receive a private IPv4 address using DHCPv4 which 1004 works the same way in existent cable networks. The CMTS will act as 1005 DHCPv4 relay agent. 1007 The address assignment for the host and GWR happens in a similar 1008 manner as described in section 6.2.2.2.2. 1010 6.2.2.4.3 Data Forwarding 1012 Data forwarding between the host and CMTS/ER is facilitated by the 1013 GWR and happens in a similar manner as described in section 1014 6.2.2.2.3. 1016 6.2.2.4.4 Routing 1018 In this case routing is very similar to the case described in 1019 section 6.2.2.2.4. Since the CMTS now incorporates the ER 1020 functionality, it will need to run an IGP such as OSPFv3 or ISIS. 1022 6.2.2.5 Dual-Stacked Cable (HFC) Network, Embedded GWR/CM and CMTS 1023 Support IPv6 1025 In this scenario the Cable Operator can offer native IPv6 services 1026 to its customers since the cable network including the CM/Embedded 1027 GWR and CMTS support IPv6. The ER functionality can be included in 1028 the CMTS or it can exist on a separate router connected to the CMTS 1029 upstream interface. The CM/Embedded GWR acts as a Layer 3 device. 1031 Figure 6.2.2.5 illustrates this deployment scenario 1033 +-----------+ +-------------+ 1034 +-----+ +-----------+ | Cable | | CMTS / Edge | 1035 |Host |---| CM / GWR |----| (HFC) |----| |=> ISP 1036 +-----+ +-----------+ | Network | | Router | Network 1037 +-----------+ +-------------+ 1039 <----------------------------------------------------------> 1040 IPv4/v6 1042 Figure 6.2.2.5 1044 6.2.2.5.1 IPv6 Related Infrastructure Changes 1046 Since the CM/GWR acts as a Layer 3 device, IPv6 can be deployed 1047 end-to-end. In this scenario the following devices have to be 1048 upgraded to dual-stack: Host, CM/GWR and CMTS/ER. 1050 6.2.2.5.2 Addressing 1052 Since the CM/GWR is dual-stack, it can receive an IPv4 or IPv6 1053 address using DHCP for management purposes. As the GWR 1054 functionality is Embedded in the CM, it will need an IPv6 address for 1055 forwarding data traffic. IPv6 address assignment for the CM/GWR and 1056 host can be done via DHCPv6 or DHCP-PD. 1058 If using DHCPv6 the CMTS will need to act as DHCPv6 relay agent. The 1059 host and CM/GWR will receive IPv6 addresses from pools of /64 1060 prefixes configured on the DHCPv6 server. The CMTS will need to glean 1061 pertinent information from the DHCP Offer messages, sent from the 1062 DHCP server to the DHCP clients (host and CM/GWR), much like it does 1063 today in DHCPv4. All CM/GWR connected to the same cable interface on 1064 the CMTS belong to same /64 prefix. The hosts connected to the same 1065 cable interface on the CMTS may belong to different /64 prefixes as 1066 the CMTS will have multiple /64 prefixes configured under its cable 1067 interfaces. 1069 It is also possible to use DHCP-PD for IPv6 address assignment. In 1070 this case the CM/GWR will use stateless auto-configuration to assign 1071 an IPv6 address to its upstream interface using the /64 prefix 1072 sent by the CMTS/ER in RA message. Once the CM/GWR assigns an IPv6 1073 address to its upstream interface it will request a /48 prefix from 1074 the CMTS/ER and chop this /48 prefix into /64s for assigning IPv6 1075 addresses to hosts. Currently the DHCP-PD functionality cannot be 1076 implemented if the DHCP-PD server is not the Edge Router. If the 1077 DHCP-PD messages are relayed, the Edge Router does not have a 1078 mechanism to learn the assigned prefixes and thus install the proper 1079 routes to make that prefix reachable. Work is being done to address 1080 this issue, one idea being to provide the Edge Router with a snooping 1081 mechanism. The uplink to the ISP network is configured with a /64 1082 prefix as well. 1084 6.2.2.5.3 Data Forwarding 1086 The host will use the CM/GWR as the Layer 3 next hop. The CM/GWR 1087 will forward all IPv6 traffic to/from the CMTS/ER and hosts. The 1088 CMTS/ER will forward IPv6 traffic to/from hosts based on the IP 1089 source/destination address. 1091 6.2.2.5.4 Routing 1093 The CM/GWR can use a static default route pointing to the CMTS/ER or 1094 it can run a routing protocol such as RIP-ng or OSPFv3 between itself 1095 and the CMTS. Customer routes from behind the CM/GWR can be carried 1096 to the CMTS using routing updates. 1098 If DHCP-PD is used for address assignment a static route is 1099 automatically installed on the CMTS/ER for each delegated /48 prefix. 1101 The static routes need to be redistributed into the IGP at the 1102 CMTS/ER so there is no need for a routing protocol between the 1103 CMTS/ER and the GWR. 1105 If the CMTS is also acting as an ER, it runs an IGP such as OSPFv3 1106 or ISIS. 1108 6.3 IPv6 Multicast 1110 In order to support IPv6 multicast applications across DOCSIS cable 1111 networks, the CM and bridging CMTS will need to support IGMPv3/MLDv1 1112 or v2 snooping. MLD is almost identical to IGMP in IPv4, only the 1113 name and numbers are changed. MLDv2 is almost identical to IGMPv3 and 1114 also supports ASM (Any Source Multicast) and SSM (Single Source 1115 Multicast) service models. 1117 SSM is more suited for deployments where the SP intends to provide 1118 paid content to the users (Video or Audio). This type of services 1119 are expected to be of primary interest. Moreover, the simplicity of 1120 the SSM model often times override the scalability issues that would 1121 be resolved in an ASM model. ASM is however an option that is 1122 discussed in section 7.3.1. The "SSM safe reporting" problem for IPv4 1123 where contention can be generated when a snooping switch sees a (S,G) 1124 INCLUDE and a (*,G) EXCLUDE does not exist in IPv6 multicast because 1125 the SSM address range in IPv6 is well defined. The CM, GWR and 1126 Layer 3 routed CMTS/ER will need to be enabled with PIM-SSM, which 1127 requires the definition and support for IGMPv3/MLDv1 or v2 snooping, 1128 in order to track join/leave messages from the hosts. The Layer 3 1129 next hop for the hosts support MLD. 1131 Please refer to section 7.3 for more IPv6 multicast details. 1133 6.4 IPv6 QoS 1135 IPv6 will not change or add any queuing/scheduling functionality 1136 already existing in DOCSIS specifications. But the QoS mechanisms on 1137 the CMTS and CM would need to be IPv6 capable. This includes support 1138 for IPv6 classifiers, so that data traffic to/from host devices can 1139 be classified appropriately into different service flows and be 1140 assigned appropriate priority. Appropriate classification criteria 1141 would need to be implemented for unicast and multicast traffic. 1143 In order to classify IPv6 traffic the following classifiers would 1144 need to be modified in the DOCSIS specification to support the 1145 128-bit IPv6 address: 1147 A. IP source address 1148 B. IP source mask 1149 C. IP destination address 1150 D. IP destination mask 1151 E. IP traffic class (DSCP) 1152 The following classifiers would be new for IPv6: 1154 A. IP version 1155 B. Flow label (optional) 1157 Traffic classification and marking should be done at the CM for 1158 upstream traffic and the CMTS/ER for downstream traffic in order to 1159 support the various types of services: data, voice, video. The same 1160 IPv4 QoS concepts and methodologies should be applied for IPv6 as 1161 well. 1163 It is important to note that when traffic is encrypted end-to-end, 1164 the traversed network devices will not have access to many of the 1165 packet fields used for classification purposes. In these cases 1166 routers will most likely place the packets in the default classes. 1167 The QoS design should take into consideration this scenario and try 1168 to use mainly IP header fields for classification purposes. 1170 6.5 IPv6 Security Considerations 1172 Security in a DOCSIS cable network is provided using Baseline Privacy 1173 Plus (BPI+). The only part that is dependent on IP addresses is 1174 encrypted multicast. Semantically, multicast encryption would work 1175 the same way in an IPv6 environment as in the IPv4 network. However, 1176 appropriate enhancements will be needed in the DOCSIS specification 1177 to support encrypted IPv6 multicast. 1179 The other aspect of security enhancement is mandated IPSec support 1180 in IPv6. The IPv6 specifications mandate implementation of IPSec, 1181 but they do not mandate its use. The IPv4 specifications do not 1182 mandate IPSec. IPSec is the same for both IPv4 and IPv6, but it 1183 still requires a key distribution mechanism. Cable operators may 1184 consider deploying it end-to-end on IPv6 as there is not an 1185 intermediate device(i.e. NAT). 1187 There are limited changes that have to be done for hosts in order to 1188 enhance security. The Privacy extensions [RFC3041] for 1189 autoconfiguration should be used by the hosts. IPv6 firewall 1190 functions could be enabled, if available on the host or GWR. 1192 The ISP provides security against attacks that come form its own 1193 subscribers but it could also implement security services that 1194 protect its subscribers from attacks sourced from the outside of its 1195 network. Such services do not apply at the access level of the 1196 network discussed here. 1198 The CMTS/ER should protect the ISP network and the other subscribers 1199 against attacks by one of its own customers. For this reason Unicast 1200 Reverse Path Forwarding (uRPF) [RFC3704] and ACLs should be used on 1201 all interfaces facing subscribers. Filtering should be implemented 1202 with regard for the operational requirements of IPv6 (ICMPv6 types). 1203 For instance, ND messages should not be filtered. 1205 The CMTS/ER should protect its processing resources against floods of 1206 valid customer control traffic such as: Router and Neighbor 1207 Solicitations, MLD Requests. 1209 All other security features used with the IPv4 service should be 1210 similarly applied to IPv6 as well. 1212 6.6 IPv6 Network Management 1214 The current DOCSIS, PacketCable, and CableHome MIBs are already 1216 designed to support IPv6 objects. In this case, IPv6 will neither 1217 add, nor change any of the functionality of these MIBs. An object to 1218 identify the IP version, InetAddressType has been added to all the 1219 appropriate SNMP objects related to IP address. 1221 There are some exceptions, the following MIBs might need to add IPv6 1222 support: 1224 On the CMTS 1226 A. DOCS-QOS-MIB 1227 B. DOCS-SUBMGT-MIB (Subscriber Management Interface Specification 1228 ANNEX B) 1230 On the CM 1232 A. DOCS-QOS-MIB 1233 B. DOCS-CABLE-DEVICE-MIB (or RFC2669) 1235 7. Broadband DSL Networks 1237 This section describes the IPv6 deployment options in today's 1238 High Speed DSL Networks. 1240 7.1 DSL Network Elements 1242 Digital Subscriber Line (DSL) broadband services provide users 1243 with IP connectivity over the existing twisted-pair telephone lines 1244 called the local-loop. A wide range of bandwidth offerings are 1245 available depending on the quality of the line and the distance 1246 between the Customer Premises Equipment and the DSLAM. 1248 The following network elements are typical of a DSL network [ISP 1249 Transition Scenarios]: 1251 DSL Modem: It can be a stand alone device, it can be incorporated 1252 in the host, it can incorporate router functionalities and also 1253 have the capabilities to act as a CPE router. 1255 Customer Premises Router: It is used to provide Layer 3 services 1256 for customer premises networks. It is usually use to provide 1257 firewalling functions and segment broadcast domains for a Small 1258 business. 1260 DSL Access Multiplexer (DSLAM): It terminates multiple twisted 1261 pair telephone lines and provides aggregation to BRAS. 1263 Broadband Remote Access Server (BRAS): It aggregates or terminates 1264 multiple PVC corresponding to the subscriber DSL circuits. 1266 Edge Router (ER): It provides the Layer 3 interface to the ISP 1267 network. 1268 Figure 7.1 depicts all the network elements mentioned. 1270 Customer Premises | Network Access Provider | Network Service Provider 1271 CP NAP NSP 1273 +-----+ +------+ +------+ +--------+ 1274 |Hosts|--|Router| +--+ BRAS +---+ Edge | ISP 1275 +-----+ +--+---+ | | | | Router +===> Network 1276 | | +------+ +--------+ 1277 +--+---+ | 1278 | DSL +--+ | 1279 |Modem | | | 1280 +------+ | +-----+ | 1281 +--+ | | 1282 +------+ |DSLAM+--+ 1283 +-----+ | DSL | +--+ | 1284 |Hosts|--+Modem +--+ +-----+ 1285 +-----+ +--+---+ 1287 Figure 7.1 1289 7.2 Deploying IPv6 in IPv4 DSL Networks 1291 There are three main design approaches to providing IPv4 connectivity 1292 over a DSL infrastructure: 1294 1. Point-to-Point Model: Each subscriber connects to the DSLAM 1295 over a twisted pair and is provided with a unique PVC that links it 1296 to the service provider. The PVCs can be terminated at the BRAS or 1297 at the Edge Router. This type of design is not very scalable if the 1298 PVCs are not terminated as close as possible to the DSLAM (at the 1299 BRAS). In this case a large number of layer two circuits has to be 1300 maintained over a significant portion of the network. The layer two 1301 domains can be terminated at the ER in three ways: 1303 A. In a common bridge group with a virtual interface that routes it 1304 out. 1306 B. Enable a Routed Bridged Encapsulation feature, all users could be 1307 part of the same subnet. This is the most common deployment type of 1308 IPv4 over DSL but it might not be the best choice in IPv6 where 1309 address availability is not an issue. 1311 C. Terminate the PVC at Layer 3, each PVC has its own prefix. This is 1312 the approach that seems more suitable for IPv6 and presented in 7.2.1 1313 In none of these cases the CPE (DSL Modem) has to be upgraded. 1315 2. PPP Terminated Aggregation (PTA) Model: PPP sessions are opened 1316 between each subscriber and the BRAS. The BRAS terminates the PPP 1317 sessions and provides Layer 3 connectivity between the subscriber 1318 and the ISP. This model is presented in section 7.2.2. 1320 3. L2TP Access Aggregation (LAA) Model: PPP sessions are opened 1321 between each subscriber and the ISP Edge Router. The BRAS tunnels the 1322 subscriber PPP sessions to the ISP by encapsulating them into L2TPv2 1323 tunnels. This model is presented in section 7.2.3. 1325 In aggregation models the BRAS terminates the subscriber PVCs and 1326 aggregates their connections before providing access to the ISP. 1328 In order to maintain the deployment concepts and business models 1329 proven and used with existent revenue generating IPv4 services, the 1330 IPv6 deployment will match the IPv4 one. This approach is presented 1331 in sections 7.2.1-3 that describe current IPv4 over DSL broadband 1332 access deployments. Under certain circumstances where new service 1333 types or service needs justify it, IPv4 and IPv6 network logical 1334 architectures could be different as described in section 7.2.4. 1336 7.2.1 Point-to-Point Model 1338 In this scenario the Ethernet frames from the Host or the Customer 1339 Premises Router are bridged over the PVC assigned to the subscriber 1340 [ISP Transition Scenarios]. 1342 Figure 7.2.1 describes the protocol architecture of this model. 1344 Customer Premises NAP NSP 1345 <-------------------------> <---------------> <--------------------> 1347 +-----+ +-------+ +-----+ +--------+ +----------+ 1348 |Hosts|--+Router +--+ DSL +--+ DSLAM +--------+ Edge | ISP 1349 +-----+ +-------+ |Modem| +--------+ | Router +==> Network 1350 +-----+ +----------+ 1351 <----------------------------> 1352 ATM 1353 Figure 7.2.1 1355 7.2.1.1 IPv6 Related Infrastructure Changes 1357 In this scenario the DSL modem and the entire NAP is Layer 3 unaware, 1358 so no changes are needed to support IPv6. The following devices have 1359 to be upgraded to dual stack: Host, Customer Router (if present) and 1360 Edge Router. 1362 7.2.1.2 Addressing 1364 The Hosts or the Customer Routers have the Edge Router as their Layer 1365 3 next hop. 1367 If there is no Customer Router all the hosts on the subscriber site 1368 belong to the same /64 subnet that is statically configured on the 1369 Edge Router for that subscriber PVC. The hosts can use stateless 1370 autoconfiguration or stateful DHCPv6 based configuration to acquire 1371 an address via the Edge Router. 1373 If a Customer Router is present: 1375 A. It is statically configured with an address on the /64 subnet 1376 between itself and the Edge Router, and with /64 prefixes on the 1377 interfaces connecting the hosts on the customer site. This is not a 1378 desired provisioning method being expensive and difficult to manage. 1380 B. It can use its link-local address to communicate with the ER. 1381 It can also dynamically acquire through stateless autoconfiguration 1382 the address for the link between itself and the ER. This step is 1383 followed by a request via DHCP-PD for a prefix shorter than /64 that 1384 in turn is divided in /64s and assigned to its interfaces connecting 1385 the hosts on the customer site. 1387 The Edge Router has a /64 prefix configured for each subscriber VLAN. 1388 Each VLAN should be enabled to relay DHCPv6 requests from the 1389 subscribers to DHCPv6 servers in the ISP network. The VLANs providing 1390 access for subscribers that use DHCP-PD as well, have to be enabled 1391 to support the feature. Currently the DHCP-PD functionality cannot be 1392 implemented if the DHCP-PD server is not the Edge Router. If the 1393 DHCP-PD messages are relayed, the Edge Router does not have a 1394 mechanism to learn the assigned prefixes and thus install the proper 1395 routes to make that prefix reachable. Work is being done to address 1396 this issue, one idea being to provide the Edge Router with a snooping 1397 mechanism. The uplink to the ISP 1398 network is configured with a /64 prefix as well. 1400 The prefixes used for subscriber links and the ones delegated via 1401 DHCP-PD should be planned in a manner that allows as much 1402 summarization as possible at the Edge Router. 1404 Other information of interest to the host, such as DNS, is provided 1405 through stateful DHCPv6 [RFC3315] and stateless DHCPv6 [RFC3736]. 1407 7.2.1.3 Routing 1409 The CPE devices are configured with a default route that points to 1410 the Edge router. No routing protocols are needed on these devices 1411 which do have limited resources. 1413 The Edge Router runs the IPv6 IGP used in the NSP: OSPFv3 or IS-IS. 1414 The connected prefixes have to be redistributed. If DHCP-PD is used, 1415 with every delegated prefix a static route is installed by the Edge 1416 Router. For this reason the static routes must also be redistributed. 1417 Prefix summarization should be done at the Edge Router. 1419 7.2.2 PPP Terminated Aggregation (PTA) Model 1421 The PTA architecture relies on PPP-based protocols (PPPoA [RFC2364] 1422 and PPPoE [RFC2516]). The PPP sessions are initiated by Customer 1423 Premise Equipment and are terminated at the BRAS. The BRAS 1424 authorizes the session, authenticates the subscriber, and provides 1426 an IP address on behalf of the ISP. The BRAS then does Layer 3 1427 routing of the subscriber traffic to the NSP Edge Router. This model 1428 is often used when the NSP is also the NAP 1429 [ISP Transition Scenarios]. 1431 There are two types of PPP encapsulations that can be leveraged with 1432 this model: 1434 A. Connection using PPPoA 1436 Customer Premises NAP NSP 1437 <--------------------> <----------------------> <-----------------> 1439 +-----------+ 1440 | AAA | 1441 +-------+ Radius | 1442 | | TACACS | 1443 | +-----------+ 1444 | 1445 +-----+ +-------+ +--------+ +----+-----+ +-----------+ 1446 |Hosts|--+Router +------+ DSLAM +-+ BRAS +-+ Edge | 1447 +-----+ +-------+ +--------+ +----------+ | Router +=>Core 1448 +-----------+ 1449 <--------------------------> 1450 PPP 1452 Figure 7.2.2.1 1454 The PPP sessions are initiated by the Customer Premise Equipment. The 1455 BRAS authenticates the subscriber against a local or a remote 1456 database. Once the session is established, the BRAS provides an 1457 address and maybe a DNS server to the user, information acquired from 1458 the subscriber profile or from a DHCP server. 1460 This solution scales better then the Point-to-Point but since there 1461 is only one PPP session per ATM PVC the subscriber can choose a 1462 single ISP service at a time. 1464 B. Connection using PPPoE 1466 Customer Premises NAP NSP 1467 <----------------------------> <-------------------> <-----------------> 1469 +-----------+ 1470 | AAA | 1471 +-------+ Radius | 1472 | | TACACS | 1473 | +-----------+ 1474 | 1475 +-----+ +-------+ +--------+ +----+-----+ +-----------+ 1476 |Hosts|--+Router +------------+ DSLAM +-+ BRAS +-+ Edge | C 1477 +-----+ +-------+ +--------+ +----------+ | Router +=>O 1478 | | R 1479 +-----------+ E 1480 <--------------------------------> 1481 PPP 1483 Figure 7.2.2.2 1485 The operation of PPPoE is similar to PPPoA with the exception that 1486 with PPPoE multiple sessions can be supported over the same PVC thus 1487 allowing the subscriber to connect to multiple services at the same 1488 time. The hosts can initiate the PPPoE sessions as well. It is 1489 important to remember that the PPPoE encapsulation reduces the IP 1490 MTU available for the customer traffic due to additional headers 1491 [ISP Transition Scenarios]. 1493 The network design and operation of the PTA model is the same 1494 regardless of the PPP encapsulation type used. 1496 7.2.2.1 IPv6 Related Infrastructure Changes 1498 In this scenario the BRAS is Layer 3 aware and it has to be upgraded 1499 to support IPv6. Since the BRAS terminates the PPP sessions it has to 1500 support the implementation of these PPP protocols with IPv6. The 1501 following devices have to be upgraded to dual stack: Host, Customer 1502 Router (if present), BRAS and Edge Router. 1504 7.2.2.2 Addressing 1506 The BRAS terminates the PPP sessions and provides the subscriber with 1507 an IPv6 address from the defined pool for that profile. The 1508 subscriber profile for authorization and authentication can be 1509 located on the BRAS or on a AAA server. The Hosts or the Customer 1510 Routers have the BRAS as their Layer 3 next hop. 1512 The PPP session can be initiated by a host or by a Customer Router. 1513 In the latter case, once the session is established with the BRAS and 1514 an address is negotiated for the uplink to the BRAS, DHCP-PD can be 1515 used to acquire prefixes for the Customer Router other interfaces. 1517 The BRAS has to be enabled to support DHCP-PD and to relay the 1518 DHCPv6 requests of the hosts on the subscriber sites. 1520 The BRAS has a /64 prefixes configured on the link to the Edge 1521 router. The Edge router links are also configured with /64 prefixes 1522 to provide connectivity to the rest of the ISP network. 1524 The prefixes used for subscriber and the ones delegated via DHCP-PD 1525 should be planned in a manner that allows maximum summarization at 1526 the BRAS. 1528 Other information of interest to the host, such as DNS, is provided 1529 through stateful [RFC3315] and stateless [RFC3736] DHCPv6. 1531 7.2.2.3 Routing 1533 The CPE devices are configured with a default route that points to 1534 the BRAS router. No routing protocols are needed on these devices 1535 which have limited resources. 1537 The BRAS runs an IGP to the Edge Router: OSPFv3 or IS-IS. Since the 1538 addresses assigned to the PPP sessions are represented as connected 1540 host routes, connected prefixes have to be redistributed. If DHCP-PD 1541 is used, with every delegated prefix a static route is installed by 1542 the Edge Router. For this reason the static routes must also be 1543 redistributed. Prefix summarization should be done at the BRAS. 1545 The Edge Router is running the IGP used in the ISP network: OSPFv3 1546 or IS-IS. 1548 A separation between the routing domains of the ISP and the Access 1549 Provider is recommended if they are managed independently. Controlled 1550 redistribution will be needed between the Access Provider IGP and the 1551 ISP IGP. 1553 7.2.3 L2TPv2 Access Aggregation (LAA) Model 1555 In the LAA model the BRAS forwards the CPE initiated session to 1556 the ISP over an L2TPv2 tunnel established between the BRAS and the 1557 Edge Router. In this case the authentication, authorization and 1558 subscriber configuration are performed by the ISP itself 1559 [ISP Transitions Scenarios]. There are two types of PPP 1560 encapsulations that can be leveraged with this model: 1562 A. Connection via PPPoA 1564 Customer Premises NAP NSP 1565 <--------------------> <----------------------> <-----------------> 1567 +-----------+ 1568 | AAA | 1569 +-------+ Radius | 1570 | | TACACS | 1571 | +-----+-----+ 1572 | | 1573 +-----+ +-------+ +--------+ +----+-----+ +-----+-----+ 1574 |Hosts|--+Router +------+ DSLAM +-+ BRAS +-+ Edge | 1575 +-----+ +-------+ +--------+ +----------+ | Router +=>Core 1576 +-----------+ 1577 <----------------------------------------> 1578 PPP 1579 <------------> 1580 L2TPv2 1581 Figure 7.2.3.1 1583 B. Connection via PPPoE 1585 Customer Premises NAP NSP 1586 <---------------------------> <--------------------> <-----------------> 1587 +-----------+ 1588 | AAA | 1589 +------+ Radius | 1590 | | TACACS | 1591 | +-----+-----+ 1592 | | 1593 +-----+ +-------+ +--------+ +----+-----+ +----+------+ 1594 |Hosts|--+Router +------------+ DSLAM +-+ BRAS +-+ Edge | C 1595 +-----+ +-------+ +--------+ +----------+ | Router +=>O 1596 | | R 1597 +-----------+ E 1598 <-----------------------------------------------> 1599 PPP 1600 <--------------> 1601 L2TPv2 1603 Figure 7.2.3.2 1605 The network design and operation of the PTA model is the same 1606 regardless of the PPP encapsulation type used. 1608 7.2.3.1 IPv6 Related Infrastructure Changes 1610 In this scenario the BRAS is forwarding the PPP sessions initiated 1611 by the subscriber over the L2TPv2 tunnel established to the LNS, the 1612 aggregation point in the ISP network. The L2TPv2 tunnel between the 1613 LAC and LNS could run over IPv6 or IPv4. These capabilities 1614 have to be supported on the BRAS. The following devices have to be 1615 upgraded to dual stack: Host, Customer Router and Edge Router. If 1616 the tunnel is set up over IPv6 then the BRAS must be upgraded to 1617 dual stack. 1619 7.2.3.2 Addressing 1621 The Edge router terminates the PPP sessions and provides the 1622 subscriber with an IPv6 address from the defined pool for that 1623 profile. The subscriber profile for authorization and authentication 1624 can be located on the Edge Router or on a AAA server. The Hosts or 1625 the Customer Routers have the Edge Router as their Layer 3 next hop. 1627 The PPP session can be initiated by a host or by a Customer Router. 1628 In the latter case, once the session is established with the Edge 1629 Router, DHCP-PD can be used to acquire prefixes for the Customer 1630 Router interfaces. The Edge Router has to be enabled to support 1631 DHCP-PD and to relay the DHCPv6 requests generated by the hosts on 1632 the subscriber sites. 1634 The BRAS has a /64 prefix configured on the link to the Edge router. 1635 The Edge router links are also configured with /64 prefixes to 1636 provide connectivity to the rest of the ISP network. 1638 Other information of interest to the host, such as DNS, is provided 1639 through stateful [RFC3315] and stateless [RFC3736] DHCPv6. 1641 It is important to note here a significant difference between this 1642 deployment for IPv6 versus IPv4. In the case of IPv4 the customer 1643 router or CPE can end up on any Edge Router (acting as LNS) where the 1644 assumption is that there are at least two of them for redundancy 1645 purposes. Once authenticated, the customer will be given an address 1646 from the IP pool of the ER (LNS) it connected to. This allows the ERs 1647 (LNSs) to aggregate the addresses handed out to the customers. In the 1648 case of IPv6, an important constraint that likely will be enforced is 1649 that the customer should keep its own address regardless of the ER 1650 (LNS) it connects to. This could significantly reduce the prefix 1651 aggregation capabilities of the ER (LNS). This is different than the 1652 current IPv4 deployment where addressing is dynamic in nature and the 1653 same user can get different addresses depending on the LNS it ends up 1654 connecting to. 1656 One possible solution is to ensure that a given BRAS will always 1657 connect to the same ER (LNS) unless that LNS is down. This means that 1658 customers from a given prefix range will always be connected to the 1659 same ER (primary if up or secondary if not). Each ER (LNS) can carry 1660 summary statements in their routing protocol configuration for the 1661 prefixes they are the primary ER (LNS) as well as for the ones for 1662 which they are the secondary. This way the prefixes will be 1663 summarized any time they become "active" on the ER (LNS). 1665 7.2.3.3 Routing 1667 The CPE devices are configured with a default route that points to 1668 the Edge router that terminates the PPP sessions. No routing 1669 protocols are needed on these devices which have limited resources. 1671 The BRAS runs an IPv6 IGP to the Edge Router: OSPFv3 or IS-IS. 1672 Different processes should be used if the NAP and the NSP are managed 1673 by different organizations. In this case, controlled redistribution 1674 should be enabled between the two domains. 1676 The Edge Router is running the IPv6 IGP used in the ISP network: 1677 OSPFv3 or IS-IS. 1679 7.2.4 Hybrid Model for IPv4 and IPv6 Service 1681 It was recommended throughout this section that the IPv6 service 1682 implementation should map the existent IPv4 one. This approach 1683 simplifies manageability and minimizes training needed for personnel 1684 operating the network. In certain circumstances such mapping is not 1685 feasible. This typically becomes the case when a Service Provider 1686 plans to expand its service offering with the new IPv6 deployed 1687 infrastructure. If this new service is not well supported in a 1688 network design such as the one used for IPv4 then a different design 1689 might be used for IPv6. 1691 An example of such circumstances is that of a provider using an LAA 1692 design for its IPv4 services. In this case all the PPP sessions are 1693 bundled and tunneled across the entire NAP infrastructure which is 1694 made of multiple BRAS routers, aggregation routers etc. The end point 1695 of these tunnels is the ISP Edge Router. If the provider decides to 1696 offer multicast services over such a design, it will face the problem 1697 of NAP resources being over utilized. The multicast traffic can be 1698 replicated only at the end of the tunnels by the Edge router and the 1699 copies for all the subscribers are carried over the entire NAP. 1701 A Modified Point-to-Point (as described in 7.2.4.2) or PTA model are 1702 more suitable to support multicast services because the packet 1703 replication can be done closer to the destination at the BRAS. Such 1704 topology saves NAP resources. 1706 In this sense IPv6 deployment can be viewed as an opportunity to 1707 build an infrastructure that might better support the expansion of 1708 services. In this case, an SP using the LAA design for its IPv4 1709 services might choose a modified Point-to-Point or PTA design for 1710 IPv6. 1712 7.2.4.1 IPv4 in LAA Model and IPv6 in PTA Model 1714 The coexistence of the two PPP based models, PTA and LAA, is 1715 relatively straight forward. The PPP sessions are terminated on 1716 different network devices for the IPv4 and IPv6 services. The PPP 1717 sessions for the existent IPv4 service deployed in an LAA model are 1718 terminated on the Edge Router. The PPP sessions for the new IPv6 1719 service deployed in a PTA model are terminated on the BRAS. 1721 The logical design for IPv6 and IPv4 in this hybrid model is 1722 presented in Figure 7.2.4.1. 1724 IPv6 <--------------------------> 1725 PPP +-----------+ 1726 | AAA | 1727 +-------+ Radius | 1728 | | TACACS | 1729 | +-----+-----+ 1730 | | 1731 +-----+ +-------+ +--------+ +----+-----+ +-----+-----+ 1732 |Hosts|--+Router +------+ DSLAM +-+ BRAS +-+ Edge | 1733 +-----+ +-------+ +--------+ +----------+ | Router +=>Core 1734 +-----------+ 1735 IPv4 <----------------------------------------> 1736 PPP 1737 <------------> 1738 L2TPv2 1739 Figure 7.2.4.1 1741 7.2.4.2 IPv4 in LAA Model and IPv6 in Modified Point-to-Point Model 1743 In this particular scenario the Point-to-Point model used for the 1744 IPv6 service is a modified version of the model described in section 1745 7.2.1. 1747 For the IPv4 service in LAA model, the VLANs are terminated on the 1748 BRAS and PPP sessions are terminated on the Edge Router (LNS). For 1749 IPv6 service in Point-to-Point model, the VLANs are terminated at 1750 the Edge Router as described in section 7.2.1. In this hybrid model, 1751 the Point-to-Point link could be terminated on the BRAS, a NAP owned 1752 device. The IPv6 traffic is then routed through the NAP network to 1753 the NSP. In order to have this hybrid model, the BRAS has to be 1754 upgraded to a dual-stack router. The functionalities of the Edge 1755 Router as described in section 7.2.1 are now implemented on the BRAS. 1757 The other aspect of this deployment model is the fact that the BRAS 1758 has to be capable of distinguishing between the IPv4 PPP traffic that 1759 has to be bridged across the L2TPv2 tunnel and the IPv6 packets that 1760 have to be routed to the NSP. The IPv6 Routing and Bridging 1761 Encapsulation (RBE) has to be enabled on all interfaces with VLANs 1762 supporting both IPv4 and IPv6 services in this hybrid design. 1764 The logical design for IPv6 and IPv4 in this hybrid model is 1765 presented in Figure 7.2.4.2. 1767 IPv6 <----------------> 1768 ATM +-----------+ 1769 | AAA | 1770 +-------+ Radius | 1771 | | TACACS | 1772 | +-----+-----+ 1773 | | 1774 +-----+ +-------+ +--------+ +----+-----+ +-----+-----+ 1775 |Hosts|--+Router +------+ DSLAM +-+ BRAS +-+ Edge | 1776 +-----+ +-------+ +--------+ +----------+ | Router +=>Core 1777 +-----------+ 1778 IPv4 <----------------------------------------> 1779 PPP 1780 <------------> 1781 L2TPv2 1782 Figure 7.2.4.2 1784 7.3 IPv6 Multicast 1786 The deployment of IPv6 multicast services relies on MLD, identical to 1787 IGMP in IPv4 and on PIM for routing. ASM (Any Source Multicast) and 1788 SSM (Single Source Multicast) service models operate almost the same 1789 as in IPv4. Both have the same benefits and disadvantages as in IPv4. 1790 Nevertheless, the larger address space and the scoped address 1791 architecture provide major benefits for multicast IPv6. Through 1792 RFC3306 the large address space provides the means to assign global 1793 multicast group addresses to organizations or users that were 1794 assigned unicast prefixes. It is a significant improvement with 1795 respect to the IPv4 GLOP mechanism [RFC2770]. 1797 This facilitates the deployment of multicast services. The 1798 discussion of this section applies to all the multicast sections 1799 in the document. 1801 7.3.1 ASM Based Deployments 1803 Any Source Multicast (ASM) is useful for Service Providers that 1804 intend to support the forwarding of multicast traffic of their 1805 customers. It is based on the PIM-SM protocol and it is more complex 1806 to manage because of the use of Rendezvous Points (RPs). With IPv6, 1807 static RP and BSR [BSR] can be used for RP-to-group mapping similar 1808 to IPv4. Additionally, the larger IPv6 address space allows for 1809 building up of group addresses that incorporate the address of the 1810 RP. This RP-to-group mapping mechanism is called Embedded RP and is 1811 specific to IPv6. 1813 In inter-domain deployments, Multicast Source Discovery Protocol 1814 (MSDP) [RFC3618] is an important element of IPv4 PIM-SM deployments. 1815 MSDP is meant to be a solution for the exchange of source 1816 registration information between RPs in different domains. This 1817 solution was intended to be temporary. This is one of the reasons 1818 why it was decided not to implement MSDP in IPv6 [IPv6 Multicast]. 1820 For multicast reachability across domains, Embedded RP could be 1821 used. Despite its shortcomings, MSDP provides additional 1822 flexibility in managing the domains that may not be matched with 1823 the protocols available in IPv6 today. The value of such 1824 flexibility is still under evaluation. 1826 7.3.2 SSM Based Deployments 1828 Based on PIM-SSM, the Source Specific Multicast deployments do not 1829 need an RP and the related protocols (such as BSR or MSDP) but rely 1830 on the listeners to know the source of the multicast traffic 1831 they plan to receive. The lack of RP makes SSM not only simpler to 1832 operate but also robust, it is not impacted by RP failures or inter 1833 domain constraints. It is also has a higher level of security (No RP 1834 to be targeted by attacks). For more discussions on the topic of 1835 IPv6 multicast see [IPv6 Multicast]. 1837 The typical multicast services offered for residential and very 1838 small businesses is video/audio streaming where the subscriber joins 1839 a multicast group and receives the content. This type of service 1840 model is well supported through PIM-SSM which is very simple and 1841 easy to manage. PIM-SSM has to be enabled throughout the SP network. 1842 MLDv2 is required for PIM-SSM support. Vendors can choose to 1843 implement features that allow routers to map MLDv1 group joins to 1844 predefined sources. 1846 Subscribers might use a set-top box that is responsible for the 1847 control piece of the multicast service (does group joins/leaves). 1848 The subscriber hosts can also join desired multicast groups as long 1849 as they are enabled to support MLDv1 or MLDv2. If a customer premise 1850 router is used then it has to be enabled to support MLDv1 and MLDv2 1852 in order to process the requests of the hosts. It has to be enabled 1853 to support PIM-SSM in order to send PIM joins/leaves up to its 1854 Layer 3 next hop whether it is the BRAS or the Edge router. When 1855 enabling this functionality on a customer premises router, its 1856 limited resources should be taken into consideration. 1858 The router that is the Layer 3 next hop for the subscriber (BRAS in 1859 the PTA model or the Edge router in the LAA and Point-to-Point 1860 model) has to be enabled to support MLDv1 and MLDv2 in order to 1861 process the requests coming from subscribers without customer 1862 premises routers. It has to be enabled for PIM-SSM in order to 1863 receive joins/leaves from customer routers and send joins/leaves 1864 to the next hop towards the multicast source (Edge router or the 1865 NSP core). 1867 MLD authentication, authorization and accounting is usually 1868 configured on the edge router in order to enable the ISP to do 1869 control the subscriber access of the service and do billing for the 1870 content provided. Alternative mechanisms that would support these 1871 functions should be investigated further. 1873 7.4 IPv6 QoS 1875 The QoS configuration is particularly relevant on the router that 1876 represents the Layer 3 next hop for the subscriber (BRAS in the PTA 1877 model or the Edge router in the LAA and Point-to-Point model) in 1878 order to manage resources shared amongst multiple subscribers 1879 possibly with various service level agreements. 1881 In the DSL infrastructure it is expected that there is already a 1882 level of traffic policing and shaping implemented for IPv4 1883 connectivity. This is implemented throughout the NAP and it is 1884 beyond the scope of this document. 1886 On the BRAS or the Edge Router the subscriber facing interfaces have 1887 to be configure to police the inbound customer traffic and shape the 1888 traffic outbound to the customer based on the SLAs. Traffic 1889 classification and marking should also be done on the router closest 1890 (at Layer 3) to the subscriber in order to support the various types 1891 of customer traffic: data, voice, video and to optimally use the 1892 infrastructure resources. Each provider (NAP, NSP) could implement 1893 their own QoS policies and services so reclassification and marking 1894 might be performed at the boundary between the NAP and the NSP in 1895 order to make sure the traffic is properly handled by the ISP. 1897 The same IPv4 QoS concepts and methodologies should be applied with 1898 the IPv6 as well. 1900 It is important to note that when traffic is encrypted end-to-end, 1901 the traversed network devices will not have access to many of the 1902 packet fields used for classification purposes. In these cases routers 1903 will most likely place the packets in the default classes. The QoS 1904 design should take into consideration this scenario and try to use mainly 1905 IP header fields for classification purposes. 1907 7.5 IPv6 Security Considerations 1909 There are limited changes that have to be done for CPEs in order to 1910 enhance security. The Privacy extensions for auto-configuration 1911 [RFC3041] should be used by the hosts. ISPs can track the prefixes 1912 it assigns to subscribers relatively easily. If however the ISPs are 1913 required by regulations to track their users at /128 address level, 1914 the Privacy Extensions can be implemented only in parallel with 1915 network management tools that could provide traceability of the 1916 hosts. IPv6 firewall functions should be enabled on the hosts or 1917 customer premises router if present. 1919 The ISP provides security against attacks that come form its own 1920 subscribers but it could also implement security services that 1921 protect its subscribers from attacks sourced from the outside of its 1922 network. Such services do not apply at the access level of the 1923 network discussed here. 1925 The device that is the Layer 3 next hop for the subscribers (BRAS or 1926 Edge router) should protect the network and the other subscribers 1927 against attacks by one of the provider customers. For this reason 1928 uRPF and ACLs should be used on all interfaces facing subscribers. 1929 Filtering should be implemented with regard for the operational 1930 requirements of IPv6 (ICMPv6 types). Authentication and authorization 1931 should be used wherever possible. 1933 The BRAS and the Edge Router should protect their processing 1934 resources against floods of valid customer control traffic such as: 1935 Router and Neighbor Solicitations, MLD Requests. Rate limiting 1936 should be implemented on all subscriber facing interfaces. The 1937 emphasis should be placed on multicast type traffic as it is most 1938 often used by the IPv6 control plane. 1940 All other security features used with the IPv4 service should be 1941 similarly applied to IPv6 as well. 1943 7.6 IPv6 Network management 1945 The necessary instrumentation (such as MIBs, NetFlow Records etc) 1946 should be available for IPv6. 1948 Usually, NSPs manage the edge routers by SNMP. The SNMP transport 1949 can be done over IPv4 if all managed devices have connectivity over 1950 both IPv4 and IPv6. This would imply the smallest changes to the 1951 existent network management practices and processes. Transport over 1952 IPv6 could also be implemented and it might become necessary if IPv6 1953 only islands are present in the network. The management stations are 1954 located on the core network. Network Management Applications should 1955 handle IPv6 in a similar fashion to IPv4, however, they should also 1956 support features specific to IPv6 (such as Neighbor monitoring). 1958 In some cases service providers manage equipment located on 1959 customers LANs. The management of equipment at customers' LANs is 1960 out of scope of this memo. 1962 8. Broadband Ethernet Networks 1964 This section describes the IPv6 deployment options in currently 1965 deployed Broadband Ethernet Access Networks. 1967 8.1 Ethernet Access Network Elements 1969 In environments that support the infrastructure deploying RJ-45 or 1970 fiber (Fiber to the Home (FTTH) service) to subscribers, 10/100 1971 Mbps Ethernet broadband services can be provided. Such services are 1972 generally available in metropolitan areas, in multi tenant buildings 1973 where an Ethernet infrastructure can be deployed in a cost effective 1974 manner. In such environments Metro-Ethernet services can be used to 1975 provide aggregation and uplink to a Service Provider. 1977 The following network elements are typical of an Ethernet network 1978 [ISP Transition Scenarios]: 1980 Access Switch: It is used as a Layer 2 access device for subscribers. 1982 Customer Premises Router: It is used to provide Layer 3 services 1983 for customer premises networks. 1985 Aggregation Ethernet Switches: Aggregates multiple subscribers. 1987 Broadband Remote Access Server (BRAS) 1989 Edge Router (ER) 1991 Figure 8.1 depicts all the network elements mentioned. 1993 Customer Premises | Network Access Provider | Network Service Provider 1994 CP NAP NSP 1996 +-----+ +------+ +------+ +--------+ 1997 |Hosts|--|Router| +-+ BRAS +---+ Edge | ISP 1998 +-----+ +--+---+ | | | | Router +===> Network 1999 | | +------+ +--------+ 2000 +--+-----+ | 2001 |Access +-+ | 2002 |Switch | | | 2003 +--------+ | +------+ | 2004 +--+Agg E | | 2005 +--------+ |Switch+-+ 2006 +-----+ |Access | +--+ | 2007 |Hosts|--+Switch +-+ +------+ 2008 +-----+ +--------+ 2009 Figure 8.1 2011 The logical topology and design of Broadband Ethernet Networks is 2012 very similar to DSL Broadband Networks discussed in section 6. 2014 It is worth noting that the general operation, concepts and 2015 recommendations described in this section apply similarly to a 2016 HomePNA based network environment. Some of the network elements 2017 might be differently named. 2019 8.2 Deploying IPv6 in IPv4 Broadband Ethernet Networks 2021 There are three main design approaches to providing IPv4 2022 connectivity over an Ethernet infrastructure: 2024 A. Point-to-Point Model: Each subscriber connects to the network 2025 Access switch over RJ-45 or fiber links. Each subscriber is assigned 2026 a unique VLAN on the access switch. The VLAN can be terminated at 2027 the BRAS or at the Edge Router. The VLANs are 802.1q trunked to the 2028 Layer 3 device (BRAS or Edge Router). 2030 This model is presented in section 8.2.1. 2032 B. PPP Terminated Aggregation (PTA) Model: PPP sessions are opened 2033 between each subscriber and the BRAS. The BRAS terminates the PPP 2034 sessions and provides Layer 3 connectivity between the subscriber 2035 and the ISP. 2037 This model is presented in section 8.2.2. 2039 C. L2TPv2 Access Aggregation (LAA) Model: PPP sessions are opened 2040 between each subscriber and the ISP termination devices. The BRAS 2041 tunnels the subscriber PPP sessions to the ISP by encapsulating them 2042 into L2TPv2 tunnels. 2044 This model is presented in section 8.2.3. 2046 In aggregation models the BRAS terminates the subscriber VLANs and 2047 aggregates their connections before providing access to the ISP. 2049 In order to maintain the deployment concepts and business models 2050 proven and used with existent revenue generating IPv4 services, the 2051 IPv6 deployment will match the IPv4 one. This approach is presented 2052 in sections 8.2.1-3 that describes currently deployed IPv4 over 2053 Ethernet broadband access deployments. Under certain circumstances 2054 where new service types or service needs justify it, IPv4 and IPv6 2055 network architectures could be different as described in section 2056 8.2.4. 2058 8.2.1 Point-to-Point Model 2060 In this scenario the Ethernet frames from the Host or the Customer 2061 Premises Router are bridged over the VLAN assigned to the subscriber. 2063 Figure 8.2.1 describes the protocol architecture of this model. 2065 Customer Premises NAP NSP 2066 <-------------------------> <---------------> <--------------------> 2068 +-----+ +------+ +------+ +--------+ +----------+ 2069 |Hosts|--+Router+--+Access+--+ Switch +--------+ Edge | ISP 2070 +-----+ +------+ |Switch| +--------+ 802.1q | Router +==> Network 2071 +------+ +----------+ 2073 <----------------------------> 2074 Ethernet/VLANs 2076 Figure 8.2.1 2078 8.2.1.1 IPv6 Related Infrastructure Changes 2080 In this scenario the Access Switch on the customer site and the 2081 entire NAP is Layer 3 unaware so no changes are needed to support 2082 IPv6. The following devices have to be upgraded to dual stack: Host, 2083 Customer Router and Edge Router. 2085 The Access switches might need upgrades to support certain IPv6 2086 related features such as MLD Snooping. 2088 8.2.1.2 Addressing 2090 The Hosts or the Customer Routers have the Edge Router as their 2091 Layer 3 next hop. If there is no Customer Router all the hosts on 2093 the subscriber site belong to the same /64 subnet that is 2094 statically configured on the Edge Router for that subscriber VLAN. 2095 The hosts can use stateless autoconfiguration or stateful DHCPv6 2096 based configuration to acquire an address via the Edge Router. 2098 If a Customer Router is present: 2100 A. It is statically configured with an address on the /64 subnet 2101 between itself and the Edge Router, and with /64 prefixes on the 2102 interfaces connecting the hosts on the customer site. This is not 2103 a desired provisioning method being expensive and difficult to 2104 manage. 2106 B. It can use its link-local address to communicate with the ER. 2107 It can also dynamically acquire through stateless autoconfiguration 2108 the address for the link between itself and the ER. This step is 2109 followed by a request via DHCP-PD for a prefix shorter than /64 that 2110 in turn is divided in /64s and assigned to its interfaces connecting 2111 the hosts on the customer site. 2113 The Edge Router has a /64 prefix configured for each subscriber VLAN. 2114 Each VLAN should be enabled to relay DHCPv6 requests from the 2115 subscribers to DHCPv6 servers in the ISP network. The VLANs 2116 providing access for subscribers that use DHCP-PD as well, have to 2117 be enabled to support the feature. Currently the DHCP-PD 2118 functionality cannot be implemented if the DHCP-PD server is not the 2119 Edge Router. If the DHCP-PD messages are relayed, the Edge Router 2120 does not have a mechanism to learn the assigned prefixes and thus 2121 install the proper routes to make that prefix reachable. Work is 2122 being done to address this issue, one idea being to provide the Edge 2123 Router with a snooping mechanism. The uplink to the ISP network is 2124 configured with a /64 prefix as well. The uplink to the ISP network 2125 is configured with a /64 prefix as well. 2127 The prefixes used for subscriber links and the ones delegated via 2128 DHCP-PD should be planned in a manner that allows as much 2129 summarization as possible at the Edge Router. 2131 Other information of interest to the host, such as DNS, is provided 2132 through stateful [RFC3315] and stateless [RFC3736] DHCPv6. 2134 8.2.1.3 Routing 2136 The CPE devices are configured with a default route that points to 2137 the Edge router. No routing protocols are needed on these devices 2138 which have limited resources. 2140 The Edge Router runs the IPv6 IGP used in the NSP: OSPFv3 or IS-IS. 2141 The connected prefixes have to be redistributed. If DHCP-PD is used, 2142 with every delegated prefix a static route is installed by the Edge 2143 Router. For this reason the static routes must also be redistributed. 2144 Prefix summarization should be done at the Edge Router. 2146 8.2.2 PPP Terminated Aggregation (PTA) Model 2148 The PTA architecture relies on PPP-based protocols (PPPoE). The PPP 2149 sessions are initiated by Customer Premise Equipment and it is 2150 terminated at the BRAS. The BRAS authorizes the session, 2151 authenticates the subscriber, and provides an IP address on behalf 2152 of the ISP. The BRAS then does Layer 3 routing of the subscriber 2153 traffic to the NSP Edge Router. This model is often used when the 2154 NSP is also the NAP. 2156 The PPPoE logical diagram in an Ethernet Broadband Network is shown 2157 in Fig 8.2.2.1. 2159 Customer Premises NAP NSP 2160 <---------------------------> <-----------------> <-----------------> 2161 +-----------+ 2162 | AAA | 2163 +-------+ Radius | 2164 | | TACACS | 2165 | +-----------+ 2166 +-----+ +-------+ +--------+ +--------+ +----+-----+ +-----------+ 2167 |Hosts|--+Router +-+A Switch+-+ Switch +-+ BRAS +-+ Edge | C 2168 +-----+ +-------+ +--------+ +--------+ +----------+ | Router +=>O 2169 <---------------- PPP ----------------> | | R 2170 +-----------+ E 2171 Figure 8.2.2.1 2173 The PPP sessions are initiated by the Customer Premise Equipment 2174 (Host or Router). The BRAS authenticates the subscriber against a 2175 local or a remote database. Once the session is established, the 2176 BRAS provides an address and maybe a DNS server to the user, 2177 information acquired from the subscriber profile or from a DHCP 2178 server. 2180 This model allows for multiple PPPoE session to be supported over 2181 the same VLAN thus allowing the subscriber to connect to multiple 2182 services at the same time. The hosts can initiate the PPPoE sessions 2183 as well. It is important to remember that the PPPoE encapsulation 2184 reduces the IP MTU available for the customer traffic. 2186 8.2.2.1 IPv6 Related Infrastructure Changes 2188 In this scenario the BRAS is Layer 3 aware and it has to be upgraded 2189 to support IPv6. Since the BRAS terminates the PPP sessions it has to 2190 support PPPoE with IPv6. The following devices have to be upgraded to 2191 dual stack: Host, Customer Router (if present), BRAS and Edge Router. 2193 8.2.2.2 Addressing 2195 The BRAS terminates the PPP sessions and provides the subscriber with 2196 an IPv6 address from the defined pool for that profile. The 2197 subscriber profile for authorization and authentication can be 2198 located on the BRAS or on a AAA server. The Hosts or the Customer 2199 Routers have the BRAS as their Layer 3 next hop. 2201 The PPP session can be initiated by a host or by a Customer Router. 2202 In the latter case, once the session is established with the BRAS, 2203 DHCP-PD can be used to acquire prefixes for the Customer Router 2204 interfaces. The BRAS has to be enabled to support DHCP-PD and to 2205 relay the DHCPv6 requests of the hosts on the subscriber sites. 2206 Currently the DHCP-PD functionality cannot be implemented if the 2207 DHCP-PD server is not the Edge Router. If the DHCP-PD messages are 2208 relayed, the Edge Router does not have a mechanism to learn the 2209 assigned prefixes and thus install the proper routes to make that 2210 prefix reachable. Work is being done to address this issue, one idea 2211 being to provide the Edge Router with a snooping mechanism. The 2212 uplink to the ISP network is configured with a /64 prefix as well. 2214 The BRAS has a /64 prefix configured on the link facing the Edge 2215 router. The Edge router links are also configured with /64 prefixes 2216 to provide connectivity to the rest of the ISP network. 2218 The prefixes used for subscriber and the ones delegated via DHCP-PD 2219 should be planned in a manner that allows maximum summarization at 2220 the BRAS. 2222 Other information of interest to the host, such as DNS, is provided 2223 through stateful [RFC3315] and stateless [RFC3736] DHCPv6. 2225 8.2.2.3 Routing 2227 The CPE devices are configured with a default route that points to 2228 the BRAS router. No routing protocols are needed on these devices 2229 which have limited resources. 2231 The BRAS runs an IGP to the Edge Router: OSPFv3 or IS-IS. Since the 2232 addresses assigned to the PPP sessions are represented as connected 2233 host routes, connected prefixes have to be redistributed. If DHCP-PD 2234 is used, with every delegated prefix a static route is installed by 2235 the BRAS. For this reason the static routes must also be 2236 redistributed. Prefix summarization should be done at the BRAS. 2238 The Edge Router is running the IGP used in the ISP network: OSPFv3 2239 or IS-IS. A separation between the routing domains of the ISP and 2240 the Access Provider is recommended if they are managed independently. 2241 Controlled redistribution will be needed between the Access Provider 2242 IGP and the ISP IGP. 2244 8.2.3 L2TPv2 Access Aggregation (LAA) Model 2246 In the LAA model the BRAS forwards the CPE initiated session to 2247 the ISP over an L2TPv2 tunnel established between the BRAS and the 2248 Edge Router. In this case the authentication, authorization and 2249 subscriber configuration are performed by the ISP itself. 2251 Customer Premises NAP NSP 2252 <--------------------> <----------------------> <-----------------> 2254 +-----------+ 2255 | AAA | 2256 +------+ Radius | 2257 | | TACACS | 2258 | +-----+-----+ 2259 | | 2260 +-----+ +-------+ +--------+ +--------+ +----+-----+ +-----------+ 2261 |Hosts|--+Router +-+A Switch+-+ Switch +-+ BRAS +-+ Edge | C 2262 +-----+ +-------+ +--------+ +--------+ +----------+ | Router +=>O 2263 | | R 2264 +-----------+ E 2265 <-----------------------------------------------> 2266 PPP 2267 <--------------> 2268 L2TPv2 2270 Figure 8.2.3.1 2272 8.2.3.1 IPv6 Related Infrastructure Changes 2274 In this scenario the BRAS is Layer 3 aware and it has to be upgraded 2275 to support IPv6. The PPP sessions initiated by the subscriber are 2276 forwarded over the L2TPv2 tunnel to the aggregation point in the ISP 2277 network. The BRAS (LAC) can aggregate IPv6 PPP sessions and tunnel 2278 them to the LNS using L2TPv2. The L2TPv2 tunnel between the LAC and 2279 LNS could run over IPv6 or IPv4. These capabilities have to be 2280 supported on the BRAS. The following devices have to be upgraded to 2281 dual stack: Host, Customer Router (if present), BRAS and Edge Router. 2283 8.2.3.2 Addressing 2285 The Edge router terminates the PPP sessions and provides the 2286 subscriber with an IPv6 address from the defined pool for that 2287 profile. The subscriber profile for authorization and authentication 2288 can be located on the Edge Router or on a AAA server. The Hosts or 2289 the Customer Routers have the Edge Router as their Layer 3 next hop. 2291 The PPP session can be initiated by a host or by a Customer Router. 2292 In the latter case, once the session is established with the Edge 2293 Router and an IPv6 address is assigned to the Customer Router by the 2294 Edge router, DHCP-PD can be used to acquire prefixes for the Customer 2295 Router other interfaces. The Edge Router has to be enabled to support 2296 DHCP-PD and to relay the DHCPv6 requests of the hosts on the 2297 subscriber sites. Currently the DHCP-PD functionality cannot be 2298 implemented if the DHCP-PD server is not the Edge Router. If the 2299 DHCP-PD messages are relayed, the Edge Router does not have a 2300 mechanism to learn the assigned prefixes and thus install the proper 2301 routes to make that prefix reachable. Work is being done to address 2302 this issue, one idea being to provide the Edge Router with a snooping 2303 mechanism. The uplink to the ISP network is configured with a /64 2304 prefix as well. 2306 The BRAS has a /64 prefix configured on the link to the Edge router. 2307 The Edge router links are also configured with /64 prefixes to 2308 provide connectivity to the rest of the ISP network. 2310 Other information of interest to the host, such as DNS, is provided 2311 through stateful [RFC3315] and stateless [RFC3736] DHCPv6. 2313 The address assignment and prefix summarization issues discussed in 2314 section 7.2.3.2 are relevant in the same way for this media access 2315 type as well. 2317 8.2.3.3 Routing 2319 The CPE devices are configured with a default route that points to 2320 the Edge router that terminates the PPP sessions. No routing 2321 protocols are needed on these devices which have limited 2322 resources. 2324 The BRAS runs an IPv6 IGP to the Edge Router: OSPFv3 or IS-IS. 2325 Different processes should be used if the NAP and the NSP are 2326 managed by different organizations. In this case controlled 2327 redistribution should be enabled between the two domains. 2329 The Edge Router is running the IPv6 IGP used in the ISP network: 2330 OSPFv3 or IS-IS. 2332 8.2.4 Hybrid Model for IPv4 and IPv6 Service 2334 It was recommended throughout this section that the IPv6 service 2335 implementation should map the existent IPv4 one. This approach 2336 simplifies manageability and minimizes training needed for personnel 2337 operating the network. In certain circumstances such mapping is not 2338 feasible. This typically becomes the case when a Service Provider 2339 plans to expand its service offering with the new IPv6 deployed 2340 infrastructure. If this new service is not well supported in a 2341 network design such as the one used for IPv4 then a different design 2342 might be used for IPv6. 2344 An example of such circumstances is that of a provider using an LAA 2345 design for its IPv4 services. In this case all the PPP sessions are 2346 bundled and tunneled across the entire NAP infrastructure which is 2347 made of multiple BRAS routers, aggregation routers etc. The end point 2348 of these tunnels is the ISP Edge Router. If the SP decides to offer 2349 multicast services over such a design, it will face the problem of 2350 NAP resources being over utilized. The multicast traffic can be 2351 replicated only at the end of the tunnels by the Edge router and the 2352 copies for all the subscribers are carried over the entire NAP. 2354 A Modified Point-to-Point (see section 8.2.4.2) or a PTA model is 2355 more suitable to support multicast services because the packet 2356 replication can be done closer to the destination at the BRAS. 2357 Such topology saves NAP resources. 2359 In this sense IPv6 deployments can be viewed as an opportunity to 2360 build an infrastructure that can better support the expansion of 2361 services. In this case, an SP using the LAA design for its IPv4 2362 services might choose a modified Point-to-Point or PTA design for 2363 IPv6. 2365 8.2.4.1 IPv4 in LAA Model and IPv6 in PTA Model 2367 The coexistence of the two PPP based models, PTA and LAA, is 2368 relatively straight forward. It is a straight forward overlap of the 2369 two deployment models. The PPP sessions are terminated on 2370 different network devices for the IPv4 and IPv6 services. The PPP 2371 sessions for the existent IPv4 service deployed in an LAA model are 2372 terminated on the Edge Router. The PPP sessions for the new IPv6 2373 service deployed in a PTA model are terminated on the BRAS. 2375 The logical design for IPv6 and IPv4 in this hybrid model is 2376 presented in Figure 8.2.4.1. 2378 IPv6 <--------------------------> 2379 PPP +-----------+ 2380 | AAA | 2381 +-------+ Radius | 2382 | | TACACS | 2383 | +-----+-----+ 2384 | | 2385 +-----+ +-------+ +--------+ +----+-----+ +-----+-----+ 2386 |Hosts|--+Router +------+ Switch +-+ BRAS +-+ Edge | 2387 +-----+ +-------+ +--------+ +----------+ | Router +=>Core 2388 +-----------+ 2390 IPv4 <----------------------------------------> 2391 PPP 2392 <------------> 2393 L2TPv2 2394 Figure 8.2.4.1 2396 8.2.4.2 IPv4 in LAA Model and IPv6 in Modified Point-to-Point Model 2398 The coexistence of the modified Point-to-Point and the LAA models 2399 implies a few specific changes. 2401 For the IPv4 service in LAA model, the VLANs are terminated on the 2402 BRAS and PPP sessions are terminated on the Edge Router (LNS). For 2403 IPv6 service in Point-to-Point model, the VLANs are terminated at 2404 the Edge Router as described in section 7.2.1. In this hybrid model, 2405 the Point-to-Point link could be terminated on the BRAS, a NAP owned 2406 device. The IPv6 traffic is then routed through the NAP network to 2407 the NSP. In order to have this hybrid model, the BRAS has to be 2408 upgraded to a dual-stack router. The functionalities of the Edge 2409 Router as described in section 7.2.1 are now implemented on the BRAS. 2411 The logical design for IPv6 and IPv4 in this hybrid model is 2412 in Figure 8.2.4.2. 2414 IPv6 <----------------> 2415 Ethernet 2416 +-----------+ 2417 | AAA | 2418 +-------+ Radius | 2419 | | TACACS | 2420 | +-----+-----+ 2421 | | 2422 +-----+ +-------+ +--------+ +----+-----+ +-----+-----+ 2423 |Hosts|--+Router +------+ Switch +-+ BRAS +-+ Edge | 2424 +-----+ +-------+ +--------+ +----------+ | Router +=>Core 2425 +-----------+ 2426 IPv4 <----------------------------------------> 2427 PPP 2428 <------------> 2429 L2TPv2 2431 Figure 8.2.4.2 2433 8.3 IPv6 Multicast 2435 The typical multicast services offered for residential and very small 2436 businesses is video/audio streaming where the subscriber joins a 2437 multicast group and receives the content. This type of service model 2438 is well supported through PIM-SSM which is very simple and easy to 2439 manage. PIM-SSM has to be enabled throughout the ISP network. MLDv2 2440 is required for PIM-SSM support. Vendors can choose to implement 2441 features that allow routers to map MLDv1 group joins to predefined 2442 sources. 2444 Subscribers might use a set-top box that is responsible for the 2445 control piece of the multicast service (does group joins/leaves). 2446 The subscriber hosts can also join desired multicast groups as 2447 long as they are enabled to support MLDv1 or MLDv2. If a customer 2448 premise router is used then it has to be enabled to support MLDv1 2449 and MLDv2 in order to process the requests of the hosts. It has to 2450 be enabled to support PIM-SSM in order to send PIM joins/leaves up 2451 to its Layer 3 next hop whether it is the BRAS or the Edge router. 2452 When enabling this functionality on a customer premises router, 2453 its limited resources should be taken into consideration. 2455 MLD snooping or similar layer two multicast related protocols could 2456 be enabled on the NAP switches. 2458 The router that is the Layer 3 next hop for the subscriber (BRAS in 2459 the PTA model or the Edge router in the LAA and Point-to-Point model) 2461 has to be enabled to support MLDv1 and MLDv2 in order to process the 2462 requests coming from subscribers without customer premises routers. 2463 It has to be enabled for PIM-SSM in order to receive joins/leaves 2464 from customer routers and send joins/leaves to the next hop towards 2465 the multicast source (Edge router or the NSP core). 2467 MLD authentication, authorization and accounting is usually 2468 configured on the edge router in order to enable the ISP to do 2469 control the subscriber access of the service and do billing for the 2470 content provided. Alternative mechanisms that would support these 2471 functions should be investigated further. 2473 Please refer to section 7.3 for more IPv6 multicast details. 2475 8.4 IPv6 QoS 2477 The QoS configuration is particularly relevant on the router that 2478 represents the Layer 3 next hop for the subscriber (BRAS in the PTA 2479 model or the Edge router in the LAA and Point-to-Point model) in 2480 order to manage resources shared amongst multiple subscribers 2481 possibly with various service level agreements. 2483 On the BRAS or the Edge Router the subscriber facing interfaces have 2484 to be configured to police the inbound customer traffic and shape the 2485 traffic outbound to the customer based on the SLAs. Traffic 2486 classification and marking should also be done on the router closest 2487 (at Layer 3) to the subscriber in order to support the various types 2488 of customer traffic: data, voice, video and to optimally use the 2489 network resources. This infrastructure offers a very good opportunity 2490 to leverage the QoS capabilities of Layer two devices. DiffServ based 2491 QoS used for IPv4 should be expanded to IPv6. 2493 Each provider (NAP, NSP) could implement their own QoS policies and 2494 services so reclassification and marking might be performed at the 2495 boundary between the NAP and the NSP in order to make sure the 2496 traffic is properly handled by the ISP. 2498 The same IPv4 QoS concepts and methodologies should be applied for 2499 the IPv6 as well. 2501 It is important to note that when traffic is encrypted end-to-end, 2502 the traversed network devices will not have access to many of the 2503 packet fields used for classification purposes. In these cases 2504 routers will most likely place the packets in the default classes. 2505 The QoS design should take into consideration this scenario and try 2506 to use mainly IP header fields for classification purposes. 2508 8.5 IPv6 Security Considerations 2510 There are limited changes that have to be done for CPEs in order to 2511 enhance security. The Privacy extensions [RFC3041] for 2512 autoconfiguration should be used by the hosts with the same 2513 considerations for host traceability as discussed in section 7.5. 2514 IPv6 firewall functions should be enabled on the hosts or customer 2515 premises router if present. 2517 The ISP provides security against attacks that come form its own 2518 subscribers but it could also implement security services that 2519 protect its subscribers from attacks sourced from the outside of its 2520 network. Such services do not apply at the access level of the 2522 network discussed here. 2524 If any layer two filters for Ethertypes are in place, the NAP must 2525 permit the IPv6 Ethertype (0X86DD). 2527 The device that is the Layer 3 next hop for the subscribers (BRAS 2528 Edge router) should protect the network and the other subscribers 2529 against attacks by one of the provider customers. For this reason 2530 uRPF and ACLs should be used on all interfaces facing subscribers. 2531 Filtering should be implemented with regard for the operational 2532 requirements of IPv6 (ICMPv6 types). Authentication and authorization 2533 should be used wherever possible. 2535 The BRAS and the Edge Router should protect their processing 2536 resources against floods of valid customer control traffic such as: 2537 Router and Neighbor Solicitations, MLD Requests. Rate limiting 2538 should be implemented on all subscriber facing interfaces. The 2539 emphasis should be placed on multicast type traffic as it is most 2540 often used by the IPv6 control plane. 2542 All other security features used with the IPv4 service should be 2543 similarly applied to IPv6 as well. 2545 8.6 IPv6 Network Management 2547 The necessary instrumentation (such as MIBs, NetFlow Records etc) 2548 should be available for IPv6. 2550 Usually, NSPs manage the edge routers by SNMP. The SNMP transport can 2551 be done over IPv4 if all managed devices have connectivity over both 2552 IPv4 and IPv6. This would imply the smallest changes to the existent 2553 network management practices and processes. Transport over IPv6 could 2554 also be implemented and it might become necessary if IPv6 only 2555 islands are present in the network. The management stations are 2556 located on the core network. Network Management Applications should 2557 handle IPv6 in a similar fashion to IPv4 however they should also 2558 support features specific to IPv6 such as Neighbor monitoring. 2560 In some cases service providers manage equipment located on customers 2561 LANs. 2563 9. Wireless LAN 2565 This section provides detailed description of IPv6 deployment and 2566 integration methods in currently deployed wireless LAN (WLAN) 2567 infrastructure. 2569 9.1 WLAN Deployment Scenarios 2571 WLAN enables subscribers to connect to the Internet from various 2572 locations without the restriction of staying indoors. WLAN is 2573 standardized by IEEE 802.11a/b/g. Consideration should be also given 2574 to IEEE 802.16 WiMAX for similar deployment approaches. IEEE 802.11 2575 offers maximum transmission speed from 1 or 2 Mbps, IEEE 802.11b 2576 offers 11 Mbps and IEEE 802.11a offers up to 54 Mbps. 2578 Figure 9.1 describes the current WLAN architecture. 2580 Customer Premises| Access Provider |Service Provider 2581 | | 2583 +------+ +--+ +--------------+ +----------+ +------+ 2584 |WLAN | ---- | | |Access Router/| |Underlying| |Edge | 2585 |Host/ |-(WLAN)-|AP|-|Layer 2 Switch |-|Technology|-|Router|=>SP 2586 |Router| ---- | | | | | | | | Network 2587 +------+ +--+ +--------------+ +----------+ +------+ 2588 | 2589 +------+ 2590 |AAA | 2591 |Server| 2592 Figure 9.1 +------+ 2594 The host should have a wireless network interface card (NIC) in order 2595 to connect to a WLAN network. WLAN is a flat broadcast network and 2596 works in a similar fashion as Ethernet. When hosts initiate a 2597 connection, it is authenticated by the AAA server located at the 2598 SP network. All the authentication parameters (username, password 2599 and etc.) are forwarded by the Access Point (AP) to the AAA server. 2600 The AAA server authenticates the host, once authenticated 2601 successfully the host can send data packets. The AP is located near 2602 the host and acts as a bridge. The AP forwards all the packets 2603 coming to/from host to the Edge Router. The underlying connection 2604 between the AP and Edge Router could be based on any access layer 2605 technology such as HFC/Cable, FTTH, xDSL or etc. 2607 WLANs are based in limited areas known as WiFi Hot Spots. While users 2608 are present in the area covered by the WLAN range, they can be 2609 connected to the Internet given they have a wireless NIC and required 2610 configuration settings in their devices (notebook PCs, PDA or etc.). 2611 Once the user initiates the connection the IP address is assigned by 2612 the SP using DHCPv4. In most of the cases SP assigns limited 2613 number of public IP addresses to the its customer. When the user 2614 disconnects the connection and move to a new WiFi hot spot, the above 2615 mentioned process of authentication, address assignment and accessing 2616 the Internet is repeated. 2618 There are IPv4 deployments where customers can use WLAN routers to 2619 connect over wireless to their service provider. These deployment 2620 types do not fit in the typical Hot Spot concept but they rather 2621 serve fixed customers. For this reason this section discusses the 2622 WLAN router options as well. In this case, the ISP provides a public 2623 IP address and the WLAN Router assigns private addresses [RFC1918] 2624 to all WLAN users. The WLAN Router provides NAT functionality while 2625 WLAN users access the Internet. 2627 A detailed description of current WLAN infrastructure using IPv4 is 2628 explained in [ISP Transition Scenarios]. 2630 While deploying IPv6 in the above mentioned WLAN architecture, there 2631 are three possible scenarios as discussed below. 2633 A. Layer 2 Switch Between AP and Edge Router 2634 B. Access Router Between AP and Edge Router 2635 C. PPP Based Model 2637 9.1.1 Layer 2 Switch Between AP and Edge Router 2639 When a Layer 2 switch is present between AP and Edge Router, the AP 2640 and Layer 2 switch continues to work as a bridge, forwarding IPv4 2641 and IPv6 packets from WLAN Host/Router to Edge Router and vice 2642 versa. 2644 When initiating the connection, the WLAN host is authenticated by the 2645 AAA server located at the SP network. All the parameters related to 2646 authentication (username, password and etc.) are forwarded by the AP 2647 to the AAA server. The AAA server authenticates the WLAN Hosts and 2648 once authenticated and associated successfully with WLAN AP, IPv6 2649 address will be acquired by the WLAN Host. Note the initiation and 2650 authentication process is same as used in IPv4. 2652 Figure 9.1.1 describes the WLAN architecture when Layer 2 Switch is 2653 located between AP and Edge Router. 2655 Customer Premises| Access Provider |Service Provider 2656 | | 2658 +------+ +--+ +--------------+ +----------+ +------+ 2659 |WLAN | ---- | | | | |Underlying| |Edge | 2660 |Host/ |-(WLAN)-|AP|-|Layer 2 Switch |-|Technology|-|Router|=>SP 2661 |Router| ---- | | | | | | | | Network 2662 +------+ +--+ +--------------+ +----------+ +------+ 2663 | 2664 +------+ 2665 |AAA | 2666 |Server| 2667 +------+ 2668 Figure 9.1.1 2670 9.1.1.1 IPv6 Related Infrastructure Changes 2672 IPv6 will be deployed in this scenario by upgrading the following 2673 devices to dual-stack: WLAN Host, WLAN Router (if present) and Edge 2674 Router. 2676 9.1.1.2 Addressing 2678 When customer WLAN Router is not present, the WLAN Host has two 2679 possible options to get an IPv6 address via the Edge Router. 2681 A. The WLAN host can get the IPv6 address from Edge router using 2682 stateless auto-configuration [RFC2462]. All the hosts on the WLAN 2683 belong to the same /64 subnet that is statically configured on the 2684 Edge Router. The IPv6 WLAN Host may use stateless DHCPv6 for 2685 obtaining other information of interest such as DNS and etc. 2687 B. IPv6 WLAN host can use DHCPv6 [RFC3315] to get a IPv6 address 2688 from the DHCPv6 server. In this case the DHCPv6 server would be 2689 located in the SP core network and Edge Router would act simply as 2690 a DHCP Relay Agent. This option is similar to what we do today in 2691 case of DHCPv4. It is important to note that host implementation of 2692 stateful auto-configuration is rather limited at this time and this 2693 should be considered if choosing this address assignment option. 2695 When a customer WLAN Router is present, the WLAN Host has two 2696 possible options as well for acquiring IPv6 address. 2698 A. The WLAN Router may be assigned a prefix between /48 and /64 2699 depending on the SP policy and customer requirements. If the WLAN 2700 Router has multiple networks connected to its interfaces, the network 2701 administrator will have to configure the /64 prefixes to the WLAN 2702 Router interfaces connecting the WLAN Hosts on the customer site. 2703 The WLAN Hosts connected to these interfaces can automatically 2704 configure themselves using stateless auto-configuration with /64 2705 prefix. 2707 B. The WLAN Router can use its link-local address to communicate with 2708 the ER. It can also dynamically acquire through stateless 2709 autoconfiguration the address for the link between itself and the ER. 2710 This step is followed by a request via DHCP-PD for a prefix shorter 2711 than /64 that in turn is divided in /64s and assigned to its 2712 interfaces connecting the hosts on the customer site. 2714 In this option, the WLAN Router would act as a requesting router and 2715 Edge Router would act as delegating router. Once prefix is received 2716 by the WLAN Router, it assigns /64 prefixes to each of its interfaces 2717 connecting the WLAN Hosts on the customer site. The WLAN Hosts 2718 connected to these interfaces can automatically configure themselves 2719 using stateless auto-configuration with /64 prefix. Currently the 2720 DHCP-PD functionality cannot be implemented if the DHCP-PD server is 2721 not the ER. If the DHCP-PD messages are relayed, the Edge Router 2722 does not have a mechanism to learn the assigned prefixes and thus 2723 install the proper routes to make that prefix reachable. Work is 2724 being done to address this issue, one idea being to provide the Edge 2725 Router with a snooping mechanism. The uplink to the ISP network is 2726 configured with a /64 prefix as well. 2728 Usually it is easier for the SPs to stay with the DHCP PD and 2729 stateless auto-configuration model and point the clients to a 2730 central server for DNS/domain information, proxy configurations and 2731 etc. Using this model the SP could change prefixes on the fly 2732 and the WLAN Router would simply pull the newest prefix based on the 2733 valid/preferred lifetime. 2735 The prefixes used for subscriber links and the ones delegated via 2736 DHCP-PD should be planned in a manner that allows maximum 2737 summarization as possible at the Edge Router. 2739 Other information of interest to the host, such as DNS, is provided 2740 through stateful [RFC3315] and stateless [RFC3736] DHCPv6. 2742 9.1.1.3 Routing 2744 The WLAN Host/Router are configured with a default route that points 2745 to the Edge router. No routing protocols are needed on these devices 2746 which have limited resources. 2748 The Edge Router runs the IGP used in the SP network such as OSPFv3 2749 or IS-IS for IPv6. The connected prefixes have to be redistributed. 2750 Prefix summarization should be done at the Edge Router. When DHCP-PD 2751 is used, the IGP has to redistribute the static routes installed 2752 during the process of prefix delegation. 2754 9.1.2 Access Router Between AP and SP Edge Router 2756 When a Access Router is present between AP and Edge Router, the AP 2757 continues to work as a bridge, bridging IPv4 and IPv6 packets from 2758 WLAN Host/Router to Access/Edge Router and vice versa. The Access 2759 Router could be part of SP network or owned by a separate Access 2760 Provider. 2762 When WLAN Host initiates the connection, the AAA authentication and 2763 association process with WLAN AP will be similar as explained in 2764 section 9.1.1. 2766 Figure 9.1.2 describes the WLAN architecture when Access Router is 2767 located between AP and Edge Router. 2769 Customer Premises| Access Provider |Service Provider 2770 | | 2772 +------+ +--+ +--------------+ +----------+ +------+ 2773 |WLAN | ---- | | | | |Underlying| |Edge | 2774 |Host/ |-(WLAN)-|AP|-|Access Router |-|Technology|-|Router|=>SP 2775 |Router| ---- | | | | | | | | Network 2776 +------+ +--+ +--------------+ +----------+ +------+ 2777 | 2778 +------+ 2779 |AAA | 2780 |Server| 2781 +------+ 2782 Figure 9.1.2 2784 9.1.2.1 IPv6 Related Infrastructure Changes 2786 IPv6 is deployed in this scenario by upgrading the following devices 2787 to dual-stack: WLAN Host, WLAN Router (if present), Access Router 2788 and Edge Router. 2790 9.1.2.2 Addressing 2792 There are three possible options in this scenario for IPv6 address 2793 assignment: 2795 A. The Edge Router interface facing towards the Access Router is 2796 statically configured with /64 prefix. The Access Router receives/ 2797 configures an /64 prefix on its interface facing towards Edge 2798 Router through stateless auto-configuration. The network 2799 administrator will have to configure the /64 prefixes to the Access 2800 Router interface facing towards the customer premises. The WLAN 2801 Host/Router connected to this interface can automatically configure 2802 themselves using stateless auto-configuration with /64 prefix. 2804 B. This option uses DHCPv6 [RFC3315] for IPv6 prefix assignments to 2805 the WLAN Host/Router. There is no use of DHCP PD or stateless 2806 auto-configuration in this option. The DHCPv6 server can be located 2807 on the Access Router, on the Edge Router or somewhere in the SP 2808 network. In this case depending on where the DHCPv6 server is 2809 located, Access Router or the Edge Router would relay the DHCPv6 2810 requests. 2812 C. It can use its link-local address to communicate with the ER. 2813 It can also dynamically acquire through stateless autoconfiguration 2814 the address for the link between itself and the ER. This step is 2815 followed by a request via DHCP-PD for a prefix shorter than /64 that 2816 in turn is divided in /64s and assigned to its interfaces connecting 2817 the hosts on the customer site. 2819 In this option, the Access Router would act as a requesting router 2820 and Edge Router would act as delegating router. Once prefix is 2821 received by the Access Router, it assigns /64 prefixes to each of its 2822 interfaces connecting the WLAN Host/Router on customer site. The WLAN 2823 Host/Router connected to these interfaces can automatically configure 2824 themselves using stateless auto-configuration with /64 prefix. 2825 Currently the DHCP-PD functionality cannot be implemented if the 2826 DHCP-PD server is not the Edge Router. If the DHCP-PD messages are 2827 relayed, the Edge Router does not have a mechanism to learn the 2828 assigned prefixes and thus install the proper routes to make that 2829 prefix reachable. Work is being done to address this issue, one idea 2830 being to provide the Edge Router with a snooping mechanism. The 2831 uplink to the ISP network is configured with a /64 prefix as well. 2833 It is easier for the SPs to stay with the DHCP PD and stateless 2834 auto-configuration model and point the clients to a central 2835 server for DNS/domain information, proxy configurations and others. 2836 Using this model the provider could change prefixes on the fly and 2837 the Access Router would simply pull the newest prefix based on the 2838 valid/preferred lifetime. 2840 As mentioned before the prefixes used for subscriber links and the 2841 ones delegated via DHCP-PD should be planned in a manner that 2842 allows maximum summarization possible at the Edge Router. Other 2843 information of interest to the host, such as DNS, is provided 2844 through stateful [RFC3315] and stateless [RFC3736] DHCPv6. 2846 9.1.2.3 Routing 2848 The WLAN Host/Router are configured with a default route that points 2849 to the Access Router. No routing protocols are needed on these 2850 devices which have limited resources. 2852 If the Access Router is owned by an Access Provider, then the Access 2853 Router can have a default route, pointing towards the SP Edge 2854 Router. The Edge Router runs the IGP used in the SP network such as 2855 OSPFv3 or IS-IS for IPv6. The connected prefixes have to be 2856 redistributed. If DHCP-PD is used, with every delegated prefix a 2857 static route is installed by the Edge Router. For this reason the 2858 static routes must be redistributed. Prefix summarization should be 2859 done at the Edge Router. 2861 If the Access Router is owned by the SP, then Access Router will also 2862 run IPv6 IGP and will be part of SP IPv6 routing domain (OSPFv3 2863 or IS-IS). The connected prefixes have to be redistributed. If 2864 DHCP-PD is used, with every delegated prefix a static route is 2865 installed by the Access Router. For this reason the static routes 2866 must be redistributed. Prefix summarization should be done at the 2867 Access Router. 2869 9.1.3 PPP Based Model 2871 PPP TERMINATED AGGREGATION (PTA) and L2TPv2 ACCESS AGGREGATION (LAA) 2872 models as discussed in sections 7.2.2 and 7.2.3 respectively can 2873 also be deployed in IPv6 WLAN environment. 2875 9.1.3.1 PTA Model in IPv6 WLAN Environment 2877 While deploying the PTA model in IPv6 WLAN environment the Access 2878 Router is Layer3 aware and it has to be upgraded to support IPv6. 2879 Since the Access Router terminates the PPP sessions initiated by 2880 WLAN Host/Router, it has to support PPPoE with IPv6. 2882 Figure 9.1.3.1 describes the PTA Model in IPv6 WLAN environment 2884 Customer Premises| Access Provider |Service Provider 2885 | | 2887 +------+ +--+ +--------------+ +----------+ +------+ 2888 |WLAN | ---- | | | | |Underlying| |Edge | 2889 |Host/ |-(WLAN)-|AP|-|Access Router |-|Technology|-|Router|=>SP 2890 |Router| ---- | | | | | | | | Network 2891 +------+ +--+ +--------------+ +----------+ +------+ 2892 | 2893 <---------------------------> +------+ 2894 PPP |AAA | 2895 |Server| 2896 +------+ 2898 Figure 9.1.3.1 2900 9.1.3.1.1 IPv6 Related Infrastructure Changes 2902 IPv6 is deployed in this scenario by upgrading the following 2903 devices to dual-stack: WLAN Host, WLAN Router (if present), 2904 Access Router and Edge Router. 2906 9.1.3.1.2 Addressing 2908 The addressing techniques described in section 7.2.2.2 applies to 2909 IPv6 WLAN PTA scenario as well. 2911 9.1.3.1.3 Routing 2913 The routing techniques described in section 7.2.2.3 applies to 2914 IPv6 WLAN PTA scenario as well. 2916 9.1.3.2 LAA Model in IPv6 WLAN Environment 2918 While deploying the LAA model in IPv6 WLAN environment the Access 2919 Router is Layer3 aware and it has to be upgraded to support IPv6. 2920 The PPP sessions initiated by WLAN Host/Router are forwarded over 2921 the L2TPv2 tunnel to the aggregation point in the SP network. The 2922 Access Router must have the capability to support L2TPv2 for IPv6. 2924 Figure 9.1.3.2 describes the LAA Model in IPv6 WLAN environment 2926 Customer Premises| Access Provider |Service Provider 2927 | | 2929 +------+ +--+ +--------------+ +----------+ +------+ 2930 |WLAN | ---- | | | | |Underlying| |Edge | 2931 |Host/ |-(WLAN)-|AP|-|Access Router |-|Technology|-|Router|=>SP 2932 |Router| ---- | | | | | | | | Network 2933 +------+ +--+ +--------------+ +----------+ +------+ 2934 | 2935 <-------------------------------------------------->| 2936 PPP | 2937 <--------------------->| 2938 L2TPv2 | 2939 +------+ 2940 |AAA | 2941 |Server| 2942 +------+ 2944 Figure 9.1.3.2 2946 9.1.3.2.1 IPv6 Related Infrastructure Changes 2948 IPv6 is deployed in this scenario by upgrading the following 2949 devices to dual-stack: WLAN Host, WLAN Router (if present), 2950 Access Router and Edge Router. 2952 9.1.3.2.2 Addressing 2954 The addressing techniques described in section 7.2.3.2 applies to 2955 IPv6 WLAN LAA scenario as well. 2957 9.1.3.2.3 Routing 2959 The routing techniques described in section 7.2.3.3 applies to 2960 IPv6 WLAN LAA scenario as well. 2962 9.2 IPv6 Multicast 2964 The typical multicast services offered are video/audio streaming 2965 where the IPv6 WLAN Host joins a multicast group and receives the 2966 content. This type of service model is well supported through 2967 PIM-SSM which is enabled throughout the SP network. MLDv2 is required 2968 for PIM-SSM support. Vendors can choose to implement features that 2969 allow routers to map MLDv1 group joins to predefined sources. 2971 It is important to note that in the shared wireless environments 2972 multicast can have a significant bandwidth impact. For this reason 2973 the bandwidth allocated to multicast traffic should be limited and 2974 fixed based on the overall capacity of the wireless specification 2975 used 802.11a, 802.11b or 802.11g. 2977 The IPv6 WLAN Hosts can also join desired multicast groups as 2978 long as they are enabled to support MLDv1 or MLDv2. If a 2979 WLAN/Access Routers are used then they have to be enabled to 2980 support MLDv1 and MLDv2 in order to process the requests of the 2981 IPv6 WLAN Hosts. The WLAN/Access Router should also needs to be 2982 enabled to support PIM-SSM in order to send PIM joins up to the 2983 Edge Router. When enabling this functionality on a WLAN/Access 2984 Router, its limited resources should be taken into consideration. 2986 The Edge Router has to be enabled to support MLDv1 and MLDv2 in 2987 order to process the requests coming from IPv6 WLAN Host or 2988 WLAN/Access Router (if present). The Edge Router has also needs 2989 to be enabled for PIM-SSM in order to receive joins from IPv6 2990 WLAN Hosts or WLAN/Access Router (if present) and send joins 2991 towards the SP core. 2993 MLD authentication, authorization and accounting is usually 2994 configured on the Edge Router in order to enable the SP to do 2995 billing for the content services provided. Further investigation 2996 should be made in investigating alternative mechanisms that would 2997 support these functions. 2999 The IETF draft [IPv6 over 802.11] mentions some of the concerns 3000 related to running IPv6 multicast over WLAN links. Potentially 3001 these are same kind of issues when running any Layer3 protocol 3002 over a WLAN link that has a high loss-to-signal ratio, where certain 3003 frames that are multicast based are dropped when settings are not 3004 adjusted properly. For instance this behavior is similar to IGMP host 3005 membership report, when done on a WLAN link with high loss-to-signal 3006 ratio and high interference. This problem is inherited to WLAN that 3007 can impact both IPv4 and IPv6 multicast packets and not specific to 3008 IPv6 multicast. 3010 While deploying WLAN (IPv4 or IPv6), one should adjust their 3011 broadcast/multicast settings if they are in danger of dropping 3012 application dependent frames. These problems are usually caused when 3013 AP are placed too far apart (not following the distance limitations), 3014 high interference and etc. These issues may impact a real multicast 3015 application such as streaming video or basic operation of IPv6 if 3016 the frames were dropped. Basic IPv6 communications uses functions 3017 such as Duplicate Address Detection (DAD), Router and Neighbor 3018 Solicitations (RS, NS), Router and Neighbor Advertisement (RA, NA) 3019 and etc. which could be impacted by the above mentioned issues as 3020 these frames are Layer 2 Ethernet multicast frames. 3022 Please refer to section 7.3 for more IPv6 multicast details. 3024 9.3 IPv6 QoS 3026 Today, QoS is done outside of the WiFi domain but it is 3027 nevertheless important to the overall deployment. 3029 The QoS configuration is particularly relevant on the Edge Router in 3030 order to manage resources shared amongst multiple subscribers 3031 possibly with various service level agreements (SLA). Although, the 3032 WLAN Host/Router and Access Router could also be configured for QoS. 3033 This includes support for IPv6 classifiers, so that data traffic 3034 to/from IPv6 WLAN Host/Router, Access Router and Edge Router can be 3035 classified appropriately into different service flows (SF) and be 3036 assigned appropriate priority. Appropriate classification criteria 3037 would need to be implemented for IPv6 unicast and multicast traffic. 3039 On the Edge Router the subscriber facing interfaces have to be 3040 configure to police the inbound customer traffic and shape the 3041 traffic outbound to the customer, based on the SLA. Traffic 3042 classification and marking should also be done on the Edge router in 3043 order to support the various types of customer traffic: data, voice, 3044 video. The same IPv4 QoS concepts and methodologies should be applied 3045 for the IPv6 as well. 3047 It is important to note that when traffic is encrypted end-to-end, 3048 the traversed network devices will not have access to many of the 3049 packet fields used for classification purposes. In these cases 3050 routers will most likely place the packets in the default classes. 3051 The QoS design should take into consideration this scenario and try 3052 to use mainly IP header fields for classification purposes. 3054 9.4 IPv6 Security Considerations 3056 There are limited changes that have to be done for WLAN Host/Router 3057 in order to enhance security. The Privacy extensions [RFC3041] for 3058 autoconfiguration should be used by the hosts with the same 3059 consideration for host traceability as described in section 7.5. 3060 IPv6 firewall functions should be enabled on the WLAN Host/Router if 3061 present. 3063 The ISP provides security against attacks that come form its own 3064 subscribers but it could also implement security services that 3065 protect its subscribers from attacks sourced from the outside of 3066 its network. Such services do not apply at the access level of the 3067 network discussed here. 3069 If the host authentication at hot spots is done using web based 3070 authentication system then the level of security would depend on 3071 the particular implementation. User credential should never be sent 3072 as clear text via HTTP. Secure HTTP (HTTPS) should be used between 3073 the web browser and authentication server. The authentication server 3074 could use RADIUS and LDAP services at the back end. 3076 If any layer two filters for Ethertypes are in place, the NAP must 3077 permit the IPv6 Ethertype (0X86DD). 3079 The device that is the Layer3 next hop for the subscribers 3080 (Access or Edge Router) should protect the network and the other 3081 subscribers against attacks by one of the provider customers. 3082 For this reason uRPF and ACLs should be used on all interfaces 3083 facing subscribers. Filtering should be implemented with regard 3084 for the operational requirements of IPv6 (ICMPv6 types). 3085 Authentication and authorization should be used wherever possible. 3087 The Access and the Edge Router should protect their processing 3088 resources against floods of valid customer control traffic such as: 3089 RS, NS, MLD Requests. Rate limiting should be implemented on all 3090 subscriber facing interfaces. The emphasis should be placed on 3091 multicast type traffic as it is most often used by the IPv6 control 3092 plane. 3094 9.5 IPv6 Network Management 3096 The necessary instrumentation (such as MIBs, NetFlow Records, etc) 3097 should be available for IPv6. 3099 Usually, NSPs manage the edge routers by SNMP. The SNMP transport can 3100 be done over IPv4 if all managed devices have connectivity over both 3101 IPv4 and IPv6. This would imply the smallest changes to the existent 3102 network management practices and processes. Transport over IPv6 could 3103 also be implemented and it might become necessary if IPv6 only 3104 islands are present in the network. The management stations are 3105 located on the core network. Network Management Applications should 3106 handle IPv6 in a similar fashion to IPv4 however they should also 3107 support features specific to IPv6 (such as Neighbor monitoring). 3109 In some cases service providers manage equipment located on customers 3110 LANs. 3112 10. Gap Analysis 3114 Several aspects of deploying IPv6 over SP Broadband networks were 3115 highlighted in this document, aspects that require additional work 3116 in order to facilitate native deployments as summarized below: 3118 A. As mentioned in section 6, changes will need to be made to the 3119 DOCSIS specification in order for SPs to deploy native IPv6 over 3120 cable networks. The CM and CMTS will both need to support IPv6 3121 natively in order to forward IPv6 unicast and multicast traffic. 3122 This is required for IPv6 Neighbor Discovery to work over DOCSIS 3123 cable networks. Additional classifiers need to be added to the 3124 DOCSIS specification in order to classify IPv6 traffic at the CM 3125 and CMTS in order to provide QoS. 3127 B. Currently the DHCP-PD functionality cannot be implemented if the 3128 DHCP-PD server is not the Edge Router. If the DHCP-PD messages are 3129 relayed, the Edge Router does not have a mechanism to learn the 3130 assigned prefixes and thus install the proper routes to make that 3131 prefix reachable. Work needs to be done to address this issue, one 3132 idea being to provide the Edge Router with a snooping mechanism. The 3133 uplink to the ISP network is configured with a /64 prefix as well. 3135 C. Section 7 stated that current RBE based IPv4 deployment might not 3136 be the best approach for IPv6 where the addressing space available 3137 gives the SP the opportunity to separate the users on different subnets. 3138 The differences between IPv4 RBE and IPv6 RBE were highlighted in 3139 section 7. If however, support and reason is found for a deployment 3140 similar to IPv4 RBE, then the environment becomes NBMA and the new 3141 feature should observe RFC2491 recommendations. 3143 D. Section 7 discussed the constraints imposed on a LAA based IPv6 3144 deployment by the fact that it is expected that the subscribers keep 3145 their assigned prefix regardless of LNS. A deployment approach was 3146 proposed that would maintain the addressing schemes contiguous and 3147 offers prefix summarization opportunities. The topic could be 3148 further investigated for other solutions or improvements. 3150 E. Sections 7 and 8 pointed out the limitations (previously 3151 documented in [IPv6 Multicast]) in deploying inter-domain ASM 3152 however, SSM based services seem more likely at this time. For such 3153 SSM based services of content delivery (video or Audio), mechanisms 3154 are needed to facilitate the billing and management of listeners. 3155 The currently available feature of MLD AAA is suggested however, 3156 other methods or mechanisms might be developed and proposed. 3158 F. In relation to section 9, the IETF draft [IPv6 over 802.11] 3159 mentions some of the concerns related to running IPv6 multicast 3160 over WLAN links. Potentially these are same kind of issue when 3161 running any Layer3 protocol over a WLAN link that has a high 3162 loss-to-signal ratio, certain frames that are multicast based are 3163 dropped when settings are not adjusted properly. For instance this 3164 behavior is similar to IGMP host membership report, when done on 3165 a WLAN link with high loss-to-signal ratio and high interference. 3166 This problem is inherited to WLAN that can impact both IPv4 and 3167 IPv6 multicast packets and not specific to IPv6 multicast. 3168 The IETF draft [IPv6 over 802.11] raises some other concerns as 3169 well related to IPv6 mechanisms and WLAN, which should be addressed 3170 and resolved by the standard bodies. 3172 G. The Privacy Extensions were mentioned as a popular means to 3173 provide some form of host security. ISPs can track relatively 3174 easily the prefixes assigned to subscribers. If however the ISPs 3175 are required by regulations to track their users at host address 3176 level, the Privacy Extensions [RFC3041] can be implemented only in 3177 parallel with network management tools that could provide 3178 traceability of the hosts. Mechanisms should be defined to 3179 implement this aspect of user management. 3181 H. Tunnels are an effective way to avoid deployment dependencies on 3182 the IPv6 support on platforms that are out of the SP control (GWRs 3183 or CPEs) or over technologies that did not standardize the IPv6 3184 support yet (cable). They can be used in the following ways: 3186 i. Tunnels directly to the CPE or GWR with public or private IPv4 3187 addresses. 3188 ii. Tunnels directly to hosts with public or private IPv4 addresses. 3190 Recommendations on the exact tunneling mechanisms that can/should be 3191 used for last mile access need to be investigated further and should 3192 be covered in a future IETF draft. 3194 I. Through its larger address space, IPv6 allows SPs to assign fixed, 3195 globally routable prefixes to the links connecting each subscriber. 3197 This approach changes the provisioning methodologies that were used 3198 for IPv4. Static configuration of the IPv6 addresses for all these 3199 links on the Edge Routers or Access Routers might not be a scalable 3200 option. New provisioning mechanisms or features might need to be 3201 developed in order to deal with this issue. 3203 The outcome of solutions to some of these topics ranges from making 3204 a media access capable of supporting native IPv6 (cable) to improving 3205 operational aspects of native IPv6 deployments. 3207 11. Contributors 3209 We would like to thank Pekka Savola for his contribution, guidance 3210 and feedback in order to improve this document. 3212 12. Acknowledgements 3214 We would like to thank Brian Carpenter, Patrick Grossetete, Toerless 3215 Eckert, Madhu Sudan, Shannon McFarland and Benoit Lourdelet for their 3216 valuable comments. The authors would like to acknowledge the 3217 structure and information guidance provided to this work by 3218 [ISP Transition Scenarios]. 3220 13. References 3222 Normative References 3224 [RFC3053] 3225 Durand A., Fasano P., Guardini I., Lento D. "IPv6 Tunnel Broker", 3226 RFC3053, January 2001. 3228 [RFC3056] 3229 Carpenter B., Moore K., "Connection of IPv6 Domains via IPv4 Clouds", 3230 RFC3056, February 2001. 3232 [RFC2473] 3233 Conta A., Deering S., "Generic Packet tunneling in IPv6 3234 Specification", December 1998. 3236 [RFC2893] 3237 Gilligan R., Nordmark E., "Transition Mechanisms for IPv6 Hosts 3238 and Routers", August 2000. 3240 [RFC2529] 3241 Carpenter B., Jung C. "Transmission of IPv6 over IPv4 Domains 3242 without Explicit Tunnels", March 1999 3244 [RFC3904] 3245 Huitema C., Austein R., Satapati S., van der Pol R., "Evaluation 3246 of IPv6 Transition Mechanisms for Unmanaged Networks", September 2000 3248 [RFC3513] 3249 R. Hinden and S. Deering, "IP Version 6 Addressing Architecture", 3250 RFC3513, April 2003. 3252 [RFC3736] 3253 Droms, R., "Stateless Dynamic Host Configuration Protocol (DHCP) 3254 Service for IPv6", RFC3736, April 2004. 3256 [RFC3315] 3257 Droms, R., "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", 3258 RFC3315, July 2003. 3260 [RFC2462] 3261 Thomson, S. and Narten, T., "IPv6 Stateless Address 3262 Autoconfiguration", RFC2462, December 1998. 3264 [RFC3633] 3265 Troan, O. and Droms, R., "IPv6 Prefix Options for Dynamic Host 3266 Configuration Protocol (DHCP) version 6", RFC3633, December 2003. 3268 [RFC3041] 3269 T. Narten and R. Draves, "Privacy Extensions for Stateless Address 3270 Autoconfiguration in IPv6," RFC3041, April 2001. 3272 [RFC2516] 3273 Mamakos, L., "A Method for Transmitting PPP Over Ethernet (PPPoE)", 3274 RFC2516, February 1999. 3276 [RFC2364] 3277 Gross, G., "PPP Over AAL5 (PPPoA)", RFC2516, July 1998. 3279 [RFC2472] 3280 Haskin, D. and Allen, E., "IP Version 6 over PPP", RFC2472, 3281 December 1998. 3283 [RFC2461] 3284 Narten, T., Nordmark, E. and Simpson, W., "Neighbor Discovery for 3285 IP Version 6 (IPv6)", RFC2461, December 1998. 3287 [RFC2770] 3288 Meyer. D., "GLOP Addressing in 233/8", RFC2770, February 2000 3290 [RFC3646] 3291 Droms, R., "DNS Configuration options for Dynamic Host 3292 Configuration Protocol for IPv6 (DHCPv6)", RFC3646, December 2003. 3294 [RFC3618] 3295 Fenner B., Meyer D., "Multicast Source Discovery Protocol (MSDP)", 3297 Informative References 3299 [Dual Stack Access] 3300 Shirasaki, et al., "A Model of IPv6/IPv4 Dual Stack Internet Access 3301 Service", draft-shirasaki-dualstack-service-04.txt (work in 3302 progress) ,April 2004. 3304 [6PE] De Clercq J., et al., "Connecting IPv6 Islands across IPv4 3305 Clouds with BGP:, draft-ooms-v6ops-bgp-tunnel-04.txt, October 2004 3307 [ISP Networks IPv6 Scenarios] 3308 Lind et, al., "Scenarios and Analysis for Introducing IPv6 into ISP 3309 Networks", draft-ietf-v6ops-isp-scenarios-analysis-03.txt (work in 3310 progress), June 2004. 3312 [ISATAP] 3313 Templin F., et al., "Intra-Site Automatic Tunnel Addressing Protocol 3314 (ISATAP)", draft-ietf-ngtrans-isatap-12.txt, January 2003. 3316 [Dynamic Tunnel] 3317 Palet J., et al., "Analysis of IPv6 Tunnel End-point Discovery 3318 Mechanisms", draft-palet-v6ops-tun-auto-disc-01.txt, June 2004. 3320 [OPS] 3321 Nordmark E., Gilligan R. E., "Basic Transition Mechanisms for 3322 IPv6 Hosts and Routers", draft-ietf-v6ops-mech-v2-06.txt, 3323 September 2004. 3325 [IPv6 over 802.11] 3326 Park, S., "Transmission of IPv6 Packets over 802.11/WLAN Networks", 3327 draft-daniel-ipv6-over-wifi-01.txt, (work in progress), July 2004 3329 [ISP Transition Scenarios] 3330 Mickels, C., "Transition Scenarios for ISP Networks", 3331 draft-mickles-v6ops-isp-cases-05.txt, March 2003 3333 [DOCSIS 2.1 Proposal] 3334 Sudan, M., "DOCSIS 2.1 Proposal", May 2004. 3336 [IPv6 Multicast] 3337 Savola, P. "IPv6 Multicast Deployment Issues", 3338 draft-mboned-ipv6-multicast-issues, February 2004 3340 [RF Interface] 3341 Cable Labs, "Radio Frequency Interface Specification 3342 SP-RFIv2.0-I02-020617", Jun 2002. 3344 [BSR] 3345 Nidhi Bhaskar et all., "Bootstrap Router (BSR) Mechanism for PIM", 3346 draft-ietf-pim-sm-bsr-04.txt, January 2005 3348 [Assisted Tunneling] 3349 A.Durand, F. Parent,"Requirements for assisted tunneling", 3350 draft-ietf-v6ops-assisted-tunneling-requirements-00.txt, June 2004 3352 [ZeroConf] 3353 Suryanarayanan, et al., "Zero-Configuration Tunneling Requirements", 3354 draft-suryanarayanan-v6ops-zeroconf-reqs-01.txt, October, 2004 3356 Authors Addresses 3358 Salman Asadullah 3359 Cisco Systems, Inc. 3360 170 West Tasman Drive, 3361 San Jose, CA 95134, USA 3362 Phone: 408 526 8982 3363 Email: sasad@cisco.com 3365 Adeel Ahmed 3366 Cisco Systems, Inc. 3367 2200 East President George Bush Turnpike, 3368 Richardson, TX 75082, USA 3369 Phone: 469 255 4122 3370 Email: adahmed@cisco.com 3372 Ciprian Popoviciu 3373 Cisco Systems, Inc. 3374 7025-6 Kit Creek Road, 3375 Research Triangle Park, NC 27709, USA 3376 Phone: 919 392 3723 3377 Email: cpopovic@cisco.com 3379 Intellectual Property Statement 3381 The IETF takes no position regarding the validity or scope of any 3382 Intellectual Property Rights or other rights that might be claimed 3383 to pertain to the implementation or use of the technology describe 3384 in this document or the extent to which any license under such 3385 rights might or might not be available; nor does it represent that 3386 it has made any independent effort to identify any such rights. 3387 Information on the procedures with respect to rights in RFC 3388 documents can be found in BCP 78 and BCP 79. 3390 Copies of IPR disclosures made to the IETF Secretariat and any 3391 assurances of licenses to be made available, or the result of an 3392 attempt made to obtain a general license or permission for the use 3393 of such proprietary rights by implementers or users of this 3394 specification can be obtained from the IETF on-line IPR repository 3395 at http://www.ietf.org/ipr. 3397 The IETF invites any interested party to bring to its attention any 3398 copyrights, patents or patent applications, or other proprietary 3399 rights that may cover technology that may be required to implement 3400 this standard. Please address the information to the IETF at ietf- 3401 ipr@ietf.org. 3403 Disclaimer of Validity 3405 This document and the information contained herein are provided on 3406 an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 3407 REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND 3408 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, 3409 EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT 3410 THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR 3411 ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A 3412 PARTICULAR PURPOSE. 3414 Copyright Statement 3416 Copyright (C) The Internet Society (2004). This document is 3417 subject to the rights, licenses and restrictions contained in BCP 3418 78, and except as set forth therein, the authors retain all their 3419 rights. 3421 Acknowledgment 3423 Funding for the RFC Editor function is currently provided by the 3424 Internet Society.