idnits 2.17.1 draft-mule-cablelabs-docsis3-ipv6-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.1 on line 19. -- Found old boilerplate from RFC 3978, Section 5.5 on line 748. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 759. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 766. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 772. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** 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.) ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 588: '...s is that a CMTS MUST forward downstre...' Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (March 20, 2006) is 6583 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'ID-SSM-ARCH' is mentioned on line 567, but not defined == Unused Reference: 'RFC2131' is defined on line 672, but no explicit reference was found in the text == Unused Reference: 'RFC3513' is defined on line 686, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2461 (Obsoleted by RFC 4861) ** Obsolete normative reference: RFC 2462 (Obsoleted by RFC 4862) ** Obsolete normative reference: RFC 3315 (Obsoleted by RFC 8415) ** Obsolete normative reference: RFC 3513 (Obsoleted by RFC 4291) ** Obsolete normative reference: RFC 3633 (Obsoleted by RFC 8415) Summary: 10 errors (**), 0 flaws (~~), 4 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group R. Droms 3 Internet-Draft Cisco Systems, Inc. 4 Intended status: Standards Track A. Durand 5 Expires: September 21, 2006 Comcast Corporation 6 D. Kharbanda 7 J-F. Mule 8 CableLabs 9 March 20, 2006 11 DOCSIS 3.0 Requirements for IPv6 support 12 draft-mule-cablelabs-docsis3-ipv6-00.txt 14 Status of this Memo 16 By submitting this Internet-Draft, each author represents that any 17 applicable patent or other IPR claims of which he or she is aware 18 have been or will be disclosed, and any of which he or she becomes 19 aware will be disclosed, in accordance with Section 6 of BCP 79. 21 Internet-Drafts are working documents of the Internet Engineering 22 Task Force (IETF), its areas, and its working groups. Note that 23 other groups may also distribute working documents as Internet- 24 Drafts. 26 Internet-Drafts are draft documents valid for a maximum of six months 27 and may be updated, replaced, or obsoleted by other documents at any 28 time. It is inappropriate to use Internet-Drafts as reference 29 material or to cite them other than as "work in progress." 31 The list of current Internet-Drafts can be accessed at 32 http://www.ietf.org/ietf/1id-abstracts.txt. 34 The list of Internet-Draft Shadow Directories can be accessed at 35 http://www.ietf.org/shadow.html. 37 This Internet-Draft will expire on September 21, 2006. 39 Copyright Notice 41 Copyright (C) The Internet Society (2006). 43 Abstract 45 This document provides an overview of the draft requirements for IPv6 46 support in the CableLabs DOCSIS 3.0 specifications. Our goal is to 47 share high-level IPv6 requirements and design architecture in draft 48 status with the IETF community. 50 We first introduce the main network elements involved in the support 51 of IPv6 in DOCSIS cable networks and expand on the deployment 52 scenarios in scope of the DOCSIS 3.0 efforts. We elaborate on the 53 roles played by some network elements in enabling IPv6 in DOCSIS: the 54 broadband access device (Cable Modem), the headend or network side 55 equipment (Cable Modem Termination System) and the various backoffice 56 servers. Some high-level requirements are then summarized with a 57 special focus on three network services: IPv6 provisioning and 58 management of cable modems, IPv6 transport via a DOCSIS network using 59 a cable modem acting as an IPv6 bridge or router, and IP multicast. 60 Finally, we conclude with a theory of operations section to provide 61 more details and sample flows on how an IPv6-capable cable modem 62 acquires its IPv6 address and configuration parameters over a DOCSIS 63 3.0 network. 65 CableLabs, its members, the vendors participating in the DOCSIS 66 specifications and the co-authors of this document are seeking 67 general feedback from the IETF community on the overall DOCSIS IPv6 68 approach. The level of requirements provided in this document may 69 vary; we also welcome feedback on where more details should be 70 provided in future versions. 72 Table of Contents 74 1. Overview of DOCSIS 3.0 Networks . . . . . . . . . . . . . . . 4 75 2. Motivations for IPv6 in DOCSIS 3.0 . . . . . . . . . . . . . . 7 76 3. Theory of operations . . . . . . . . . . . . . . . . . . . . . 7 77 3.1. CM Configuration and Provisioning . . . . . . . . . . . . 8 78 3.1.1. Steps in CM Provisioning . . . . . . . . . . . . . . . 8 79 3.1.2. Dual-stack management . . . . . . . . . . . . . . . . 10 80 3.1.3. Alternative Provisioning Mode (APM) . . . . . . . . . 10 81 3.2. CM Management . . . . . . . . . . . . . . . . . . . . . . 10 82 3.3. Motivation for Use of DHCPv6 . . . . . . . . . . . . . . . 11 83 4. High-level IPv6 Requirements for DOCSIS Devices . . . . . . . 11 84 4.1. CMTS Requirements for IPv6 . . . . . . . . . . . . . . . . 12 85 4.2. Cable Modem Requirements for IPv6 Support . . . . . . . . 12 86 4.3. Embedded IPv6 Router Requirements . . . . . . . . . . . . 13 87 4.4. IPv6 Multicast Support . . . . . . . . . . . . . . . . . . 14 88 5. DOCSIS 3.0 DHCPv6 Requirements . . . . . . . . . . . . . . . . 15 89 6. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . . 16 90 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 16 91 8. Security Considerations . . . . . . . . . . . . . . . . . . . 16 92 9. Normative References . . . . . . . . . . . . . . . . . . . . . 16 93 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 17 94 Intellectual Property and Copyright Statements . . . . . . . . . . 19 96 1. Overview of DOCSIS 3.0 Networks 98 This section provides some terminology and background information on 99 cable access networks to the readers who may not be familiar with 100 DOCSIS networks. 102 The CableLabs(r) DOCSIS(r) project (Data Over Cable Service Interface 103 Specification) defines interface requirements for cable modems 104 involved in high-speed data distribution over cable television system 105 networks. CableLabs has published the DOCSIS 2.0 specification 106 [RFI2.0], and CableLabs is currently developing the DOCSIS 3.0 107 specification. 109 In this document, we use the following terminology for a DOCSIS 110 network: 112 Cable access network or hybrid-fiber/coax (HFC) network: A broadband 113 cable access network that may take the form of either an all-coax 114 or hybrid-fiber/coax (HFC) network. The generic term "cable 115 network" is used here to cover all cases. It is the logical or 116 physical portion of network between a cable modem and a cable 117 modem termination system. 119 Core data network: The data network operated by a cable service 120 provider to run DOCSIS high-speed data services. It connects the 121 cable modem termination system to the backoffice systems and the 122 rest of the Internet network. 124 Home network: the network connecting CPEs to the cable modem. 126 The main elements that participate in a DOCSIS network and the 127 provisioning of DOCSIS services include: 129 the Cable Modem (CM): The CM connects to the operator's cable 130 network and to a home network, forwarding packets between them. 131 Many devices can be attached to the home network, including 132 standalone devices and devices embedded in the CM. 134 Customer Premises Equipment (CPE): DOCSIS 3.0 CMs will support CPE 135 devices and hosts that may use IPv4, IPv6 or dual stack IPv4 and 136 IPv6. CMs may provide layer 2 bridging of Ethernet transport, but 137 the details of this function are out of the scope of this 138 document. Examples of typical CPE devices are home routers, VoIP 139 telephony adapters, set-top devices, personal computers, etc. 141 the Cable Modem Termination System (CMTS): The CMTS connects the 142 operator's core data network with the HFC access network. At a 143 high level, the CMTS possesses two interfaces: a Network Side 144 Interface (NSI) connecting the CMTS to the core data network and 145 the RF Interface (RFI) connecting the CMTS to the cable network. 146 Its main function is to forward packets between these two domains, 147 and between upstream and downstream channels on the cable network. 149 The CMTS may operate as a layer-2 bridging or layer-3 routing 150 device. In either case, there is a "network-side routing 151 function" provided either in the CMTS or by a separate router. 152 The CMTS forwarding capabilities for IPv6 are described in more 153 detail below. 155 various backoffice configuration services: Various services provide 156 configuration and other support to the devices on the DOCSIS 157 network. These services are implemented in servers connected to 158 the core data network. In a DOCSIS 3.0 network, these servers may 159 use IPv4, IPv6 or both as appropriate to the particular operator's 160 deployment. 162 The network diagram in Figure 1 shows the various components 163 described about. The figure illustrates three configurations: 165 o CPEs connected through a bridging CM (CM1) 167 o a CPE router (RTR) with multiple downstream links connected 168 through a bridging CM (CM2) 170 o CPEs connected through a routing CM (CM3) 171 CPE-+ 172 | 173 CPE-+--(A)----CM1+ 174 | \ 175 CPE-+ | 176 | 177 CPE-+ | 178 | | 179 CPE-+-(C)+ | 180 | +-(A)-+----+ DNS SNMP 181 CPE-+ \ | | | | Other 182 +-(D)--RTR-CM2---(B)-+CMTS+----Core network-Mgmt 183 CPE-+ / | | | | Systems 184 | +-(F)-+----+ DHCP TFTP 185 CPE-+-(E)+ | 186 | | 187 CPE-+ | 188 | 189 CPE-+ | 190 | / 191 CPE-+- (G)----CM3+ 192 | 193 CPE-+ 195 <-------------> <-------> <----------------------> 196 Home Cable Access Core Data Network 197 Network Network 199 CM1 is a bridging CM 200 CM2 is a bridging CM, RTR is an external CPE router with multiple 201 downstream links 202 CM3 is a routing CM with a single downstream link 204 Links A, B and F are all bridged by the CMTS. 206 Customer 2 (CM2) is assigned 2001:DB8:2::/48 207 Customer 3 (CM3) is assigned 2001:DB8:3::/48 209 Links A, B and F are assigned 2001:DB8:0:0::/64 210 Link C is assigned 2001:DB8:2:1::/64 211 Link D is assigned 2001:DB8:2:2::/64 212 Link E is assigned 2001:DB8:2:3::/64 213 Link G is assigned 2001:DB8:3:1::/64 215 Figure 1: Example DOCSIS 3.0 network. 217 2. Motivations for IPv6 in DOCSIS 3.0 219 The primary motivations for enabling IPv6 support in cable operator 220 networks may vary from one cable operator to another and depend on 221 each cable operator's IPv6 adoption strategy. 223 Some cable operators view IPv6 support in DOCSIS as a critical 224 element for CM provisioning and management to alleviate the IPv4 225 address space management issues. 227 Some cable operators view IPv6 support as a stepping stone to provide 228 IPv6 connectivity within the home. 230 Some believe that the basic CM with IPv6 support should initially be 231 a link-layer bridge while others have expressed support for a CM 232 acting as an IPv6 layer-3 forwarding device with some router 233 functionality. 235 The main motivations for IPv6 support in DOCSIS 3.0 include: 237 o to provide CM and CPE operations through IPv6 239 o to manage IPv6-only CMs, and, dual-stack IPv4 and IPv6 CMs, 241 o to enable native IPv6 transport over cable access networks with a 242 DOCSIS 3.0 CM acting as a bridge or router for IPv6 traffic. 244 Interoperability with other DOCSIS versions is a critical requirement 245 to support various deployment scenarios and enable IPv6 migration 246 with a phased approach. For example, a 3.0 CM must operate on an 247 IPv4 DOCSIS 2.0 network and a 3.0 CMTS must be able to support all 248 variants of DOCSIS CMs (3.0 IPv6 CM, 3.0 IPv4 CM, 2.0 IPv4 CM, etc.). 250 3. Theory of operations 252 This section describes the process for initial configuration and 253 provisioning of a DOCSIS 3.0 CM using IPv6. The description focuses 254 on the layer 3 provisioning, although it includes some layer 2 255 provisioning that controls the layer 3 provisioning. This section 256 first highlights some of the important design choices that were made 257 when defining IPv6 requirements for DOCSIS 3.0 cable modems. We then 258 provide sample flows representing IPv6 message exchanges. 260 DOCSIS 3.0 also defines a process for CM configuration using IPv4. 261 The details of that provisioning process are beyond the scope of this 262 document. 264 As described in Section 1, a DOCSIS 3.0 CM can operate in either 265 bridging or routing mode. In either case, the CM has a full IP stack 266 that can support local applications and that has an IPv4 address, an 267 IPv6 address or both assigned to an interface on the cable network. 268 The primary use for the local applications is initial configuration, 269 which uses DHCP, TFTP and Network Time protocol, and operational 270 management, which uses SNMP. 272 A DOCSIS 3.0 CM management IP stack can operate in the following 273 modes: IPv4 only, IPv6 mode, and dual IPv4-IPv6 mode. The 274 operational mode of a CM is independent of the protocols forwarded by 275 the CM to CPEs on the home network; for example, a DOCSIS 3.0 CM 276 provisioned and managed in IPv4 supports bridging of traffic for IPv6 277 CPEs and vice-versa. 279 3.1. CM Configuration and Provisioning 281 During initialization, the CM receives some directives on how to 282 establish its IP connectivity (IP provisioning mode) using a DOCSIS 283 MAC Management Message at layer 2 containing the following 284 information: the CM IP provisioning mode (IPv6 or IPv4), an indicator 285 of whether the CM should enable Alternative Provisioning Mode (APM), 286 and an indicator to enable or disable dual-stack management. APM and 287 dual-stack management will be explained further below. 289 For backward compatibility reasons, if the CM does not receive a 290 DOCSIS MAC Management Message containing the above parameters from 291 the CMTS, the CM operates as though it is connected to a pre DOCSIS 292 3.0 network or legacy provisioning system. In this case, the CM 293 performs IPv4 configuration and provisioning in DOCSIS 2.0 mode. 295 3.1.1. Steps in CM Provisioning 297 The DOCSIS 3.0 provisioning process includes the following steps: 299 Layer 2: The CM begins by performing layer 2 provisioning with the 300 CMTS. The details of this provisioning process are beyond the 301 scope of this document. As part of the layer 2 provisioning, the 302 CM receives a message from the CMTS that controls: 304 * Use of IPv4 or IPv6 for CM provisioning and management 306 * Dual-stack management 308 * APM 310 The remainder of the provisioning process described here will 311 assume the use of IPv6 without dual-stack management and APM. The 312 use of dual-stack management and APM will be described later. 314 Acquire IPv6 Connectivity: In this step, the CM acquires a link- 315 local IPv6 address on the cable network and an address of larger 316 scope to be used for the CM management applications. 318 The CM creates a link-local address, assigns that address to the 319 CM management interface and uses duplicate address detection 320 [RFC2462] to confirm that the link-local address is not already in 321 use on the cable network. 323 If the CM finds that the link-local address is already in use, the 324 CM restarts its provisioning process and a report is sent to the 325 cable operators error logging system. 327 The CM then uses Neighbor Discovery (ND) [RFC2461] to locate the 328 CMTS router and other information from a Router Advertisement (RA) 329 message. 331 DOCSIS 3.0 defines that IPv6 address assignment to the CM uses 332 DHCPv6 [RFC3315], so the 'M' and 'O' flags in the RA are set to 333 cause the CM to initiate DHCPv6. 335 After receiving the RA, the CM initiates a DHCPv6 message 336 exchange. The DHCPv6 server supplies the IPv6 address for the CM 337 management interface, as well as other configuration information. 338 Section 5 lists the DHCPv6 options used in CM provisioning. 340 Obtain configuration file: Once the CM has the IPv6 address assigned 341 to its management interface, it uses TFTP (over IPv6) to download 342 a DOCSIS 3.0 configuration file. The name and address of this 343 file are provided through the DHCPv6 message exchange in the 344 previous step. 346 Set time of day: The CM contacts a Network Time protocol server 347 [RFC0868] to set its internal clock. The address of the Network 348 Time protocol server is provided through DHCPv6. 350 Complete Registration with CMTS: After the configuration and 351 provisioning steps are completed, the CM completes its 352 registration with the CMTS. The CM authenticates itself to the 353 CMTS and supplies its layer 2 and IPv6 addresses to the CMTS. The 354 CMTS records these addresses for subsequent validation of traffic 355 from the CM 357 3.1.2. Dual-stack management 359 To provide higher reliability for CM management through redundancy, a 360 CM can be configured to be managed through SNMP carried over IPv4 or 361 IPv6. In this scenario, after completing the normal configuration 362 process, the CM obtains a second IP address to assign to its 363 management interface. For example, if the CM has been provisioned 364 through IPv6 and is configured to use dual-stack management, the CM 365 uses DHCPv4 to obtain an IPv4 address, which it assigns to its 366 management interface. 368 3.1.3. Alternative Provisioning Mode (APM) 370 A CM can be configured to use APM to improve provisioning 371 reliability. When using APM, the CM first uses the primary 372 provisioning protocol (IPv6 or IPv4), as specified by the CMTS. If 373 this provisioning mode fails, the CM then tries to provision itself 374 using the other protocol. For example, if a CM is initially 375 configured to use IPv6 for provisioning and to use APM, if the CM is 376 unable to contact a TFTP server over IPv6, it will restart the 377 provisioning process using IPv4. 379 3.2. CM Management 381 Prior to registration with the CMTS, the CM is managed via both IPv4 382 and IPv6. For data forwarding requirements related to IPv6 prior to 383 CMTS registration, the CM is required to: 385 o respond to SNMP queries and ICMP Echo packets sent to its 386 diagnostic IP address from the CMCI port(s). The diagnostic CM IP 387 address is a well-known IP address used only for troubleshooting 388 purposes prior to CM registration; 390 o send all DHCPv4 DHCPDISCOVER or DHCPREQUEST, DHCPv6 Solicit or 391 Request, TFTP or Time Protocol Request, or IPv6 Router 392 Solicitation messages to its RF interface (towards the CMTS) - it 393 must not send any of these requests to any other interface, 395 o not forward any packets between its RF interface and its CMCI or 396 other any other internal interfaces (embedded eSAFE). 398 After successful CMTS registration, the CM applies standard packet 399 forwarding rules. Some frame or packet filtering and processing 400 rules may apply based on its configuration file or other requirements 401 (for example, the CM must not forward unicast frames addressed to 402 unknown destination MAC addresses, or, it must not accept any 403 DHCPOFFER, ADVERTISE, etc. from the CMCI interface). The details on 404 the packet forwarding rules are out of scope of this document. 406 3.3. Motivation for Use of DHCPv6 408 As DHCPv4 plays a key role in cable modem provisioning in today's 409 network and the cable operator's operations, DHCPv6 is also used in 410 IPv6 mode of operation for the cable modem to acquire its IP address 411 from the MSO backoffice systems. 413 A DOCSIS 3.0 Cable Modem obtains its IP address via DHCPv6, not 414 stateless address autoconfiguration. This design choice was 415 motivated by several factors: 417 o the fact that cable networks are operated with highly managed 418 requirements and the knowledge and control of IP address 419 assignments is deemed important 421 o the importance of minimizing the changes in management and 422 operational models (DHCP is the first gate for access network 423 control, the binding of IPv6 addresses to DNS hostnames is 424 critical in IPv6 and the use of stateful DHCPv6 services to 425 perform this binding is seen by some operators as easier to 426 implement than with SAAC) 428 o Due to the fact that DNS plays a more important role than in IPv4 429 (IPv6 addresses are so error prone to type), DHCP servers are 430 perceived as the simplest place to perform dynamic DNS updates in 431 both the forward and reverse DNS tree. 433 4. High-level IPv6 Requirements for DOCSIS Devices 435 Based on the deployment scenarios and cable operator motivations for 436 deploying IPv6, the DOCSIS 3.0 specifications address the 437 requirements for CM and CMTS operation described in this section. 438 Some requirements are centered around CM provisioning and management 439 using IPv6 while others are enabling native IPv6 transport for CPEs. 441 Cable operators have identified the following requirements for IPv6 442 in DOCSIS 3.0: 444 o IPv6-only operation 446 o IPv6 provisioning with dual-stack management 448 o Fallback from IPv6 to IPv4 provisioning 450 o Backward compatibility with devices qualified for previous DOCSIS 451 versions 453 o Control of CM provisioning modes by cable operator 455 o Provisioning, management and operation of embedded router 457 o Provisioning and operation of CPE router 459 4.1. CMTS Requirements for IPv6 461 The CMTS provides IP connectivity between hosts attached to the cable 462 modems (the hosts attached to the CMs can communicate only via the 463 CMTS) and between the CM and the core data network. 465 The CMTS can act as a bridge or router: it performs data forwarding 466 in transparent bridging or network-layer forwarding mode, or a 467 combination of the two. The link-layer requirements applicable to 468 CMTS are out of scope of this document. 470 For IPv6, the CMTS participates in Neighbor Discovery (ND) [RFC2461]. 471 The CMTS must either forward ND packets from one host to the other, 472 or facilitate a proxy ND service, which responds on behalf of other 473 hosts. A proxy ND service on the CMTS also reduces the possibility 474 of potential denial of service attacks because the ND messages are 475 not forwarded to hosts (untrusted entities). The implementation of 476 the proxy ND service is vendor dependent and not specified by the 477 CableLabs specifications. 479 The CMTS acts as a relay agent for DHCPv6 messages. The CMTS adds 480 specific DHCPv6 relay agent options to pass information about the 481 type and location of CMs and CPEs to the DHCPv6 server(s). The CMTS 482 also receives DHCPv6 relay agent options from the DHCPv6 server 483 regarding the assignment of prefixes and addresses to CPEs. 485 The network-side routing function generates Router Advertisement (RA) 486 messages [RFC2461]. In the case of a routing CMTS, the RAs are 487 forwarded directly to the cable network. In the case of a bridging 488 CMTS, the network-side routing function is provided b y a separate 489 router, which forwards the RAs to the RFI interface for appropriate 490 forwarding by the bridging CMTS. 492 When the routing CMTS forwards well-known IPv6 multicast packets from 493 the NSI to RFI, the CMTS terminates and applies appropriate 494 processing. 496 4.2. Cable Modem Requirements for IPv6 Support 498 The DOCSIS 3.0 CM must support operations in IPv4, IPv6, or both IPv4 499 and IPv6 including: 501 o Device provisioning for the CM through IPv6 or IPv4. The choice 502 of provisioning mode is controlled by the cable operator through 503 the CMTS. A mode is also defined when provisioning will fall back 504 from one IP version to the other in case of failure. This 505 behavior is required to support a variety of operating 506 environments and failure conditions. 508 o IPv6 address assignment through DHCPv6 [RFC3315]; Section 3gives 509 some of the reasons that led to this choice and how it compares 510 with today's IPv4 address assignment mechanism through DHCP. 512 o Element management through IPv6, IPv4, or dual-stack IPv4 and 513 IPv6. The mode of element mode management is controlled by the 514 cable operator through the CMTS. 516 o Data forwarding of IPv4 and IPv6 traffic from and to CPE through 517 the CM regardless of how the modem is provisioned for the cable 518 operator's management purposes. 520 4.3. Embedded IPv6 Router Requirements 522 A DOCSIS 3.0 CM integrated device may include an embedded IPv6 523 router. This section highlights some of the critical requirements an 524 embedded DOCSIS IPv6 router must support. 526 For IP-level requirements (IPv6 Routing, Forwarding, Multicast, 527 etc.), the embedded router must: 529 o support Neighbor Discovery and Router Solicitation queries from 530 IPv6 CPE hosts 532 o forward IPv6 packets to multiple stand-alone IPv6 CPE Routers for 533 a single global IPv6 prefix 535 o support propagation of other configuration information such as the 536 addresses of DNS servers 538 o support Multicast Listener Discovery (MLD) proxy for MLDv1 and 539 MLDv2 541 For Provisioning and Management, the embedded router must: 543 o implement a DHCPv6 client to acquire Prefix from the cable 544 operator's network and obtain its global-scope IPv6 management 545 address(es) 547 o support IPv6 Stateless Autonomous Auto-Configuration (SAAC) for 548 CPE hosts 550 o implement a DHCPv6 Server with IPv6 Prefix Delegation to CPE hosts 552 o support router configuration via TFTP and other optional protocols 553 (like HTTPS) 555 o support SNMPv3 and IPv6 MIBs including the IETF Host and Router 556 MIB modules along with the ability to enable or disable the IPv6 557 router functionality 559 The QoS requirements are being defined and are left out of scope for 560 now. They will be added in a future revision of this I-D. 562 4.4. IPv6 Multicast Support 564 DOCSIS 3.0 provides enhanced support for IP Multicast with the 565 addition of several new capabilities. The main features in-scope of 566 this document include support for Source Specific Multicast (SSM) 567 [ID-SSM-ARCH] (forwarding of SSM traffic for MLDv2) and IPv6 568 multicast transport (multicast traffic including Neighbor Discovery 569 (ND), Router Solicitation (RS), etc.). 571 DOCSIS 3.0 supports both the traditional form of IP Multicast, Any 572 Source Multicast (ASM) [RFC1112], as well as Source Specific 573 Multicast (SSM) which is particularly relevant for broadcast-type IP 574 multicast applications. MLDv2 for IPv6 [RFC3810] is required for 575 SSM. 577 The membership reports are passed transparently by the CM towards the 578 CMTS. The CMTS operates as an MLD querier, and as an IPv6 multicast 579 router for a routing CMTS or listener (snooping switch) for a 580 bridging CMTS. In IPv6 multicast, both the "Any Source Multicast" 581 (ASM) and the "Source Specific Multicast" models are supported. 583 Specific requirements exist on the CM and CMTS to properly handle 584 IPv6 multicast. For example, in order to successfully obtain its IP 585 address and register with the CMTS, the CM needs to receive certain 586 multicast packets such as those used for DHCPv6, router discovery and 587 duplicate address detection. Another example of IPv6 multicast 588 requirements is that a CMTS MUST forward downstream IPv6 multicast 589 traffic to CPE devices joined through MLDv2. Also, the CM must 590 forward IPv6 registration multicast traffic for CPEs behind the CM. 592 More details on IPv6 multicast support may be provided in future 593 versions of this document. Other multicast capabilities are included 594 in DOCSIS 3.0 but they are out of scope of this document. 596 5. DOCSIS 3.0 DHCPv6 Requirements 598 This section lists the main IETF DHCPv6 client and relay agent DHCP 599 options used for CM IPv6 provisioning. It provides more details on 600 how DHCPv6 is used to acquire configuration parameters. 602 DHCPv6 Client options include: 604 Published IETF RFCs: as defined in [RFC3315] and [RFC3633] 605 Client Identifier option (DUID) 606 IPv6 address assignment (IA_NA, IA_TA) 607 Prefix assignment (IA_PD) 608 Rapid commit 609 Reconfigure accept 610 Option request 612 Current IETF Internet-Drafts (in DHC wg): 613 RFC 868 Time Protocol servers 614 Time offset 616 CableLabs vendor specific options: 617 These sub-option parameters are defined as part of the DHCPv6 618 Vendor-specific Information option defined in section 22.17 of RFC 619 3315, under the CableLabs enterprise number: 620 DOCSIS version identifier 621 CM capabilities 622 TFTP servers 623 TFTP configuration file name 624 syslog servers 625 Device ID (MAC address) 627 The DHCP Relay agent options include: 629 Published IETF RFCs: 630 Interface-ID 632 Current IETF Internet-Drafts (in DHC wg): 633 Subscriber-ID option 634 Assignment information 636 CableLabs vendor specific options: 637 CMTS capabilities: additional CMTS capability strings are defined 638 which contains the DOCSIS version of the relay agent. 639 CM MAC address 641 6. Open Issues 643 This could be a section where we seek more guidance or provide a more 644 direct view on how we have taken some IPv6 requirements. 646 7. Acknowledgments 648 This document is based on the work of a large number of people and 649 contributors participating in the CableLabs DOCSIS project. The 650 authors would like to recognize and thank the following for their 651 assistance and contributions: 653 Jason Combs and John Brzozowski of Comcast, Ron da Silva and Chris 654 Williams of Time Warner Cable, Victor Blake of Advance New House, 655 Kirk Erichsen of Adelphia, Ben Bekele of Cox Communications, Doc R. 656 Evans and Dan Torbet of Arris, Margo Dolas and Cliff Danielson of 657 Broadcom, Amol Bhagwat of CableLabs, Diego Mazzola of TI and Madhu 658 Sudan of Cisco. 660 8. Security Considerations 662 None. 664 9. Normative References 666 [RFC0868] Postel, J. and K. Harrenstien, "Time Protocol", STD 26, 667 RFC 868, May 1983. 669 [RFC1112] Deering, S., "Host extensions for IP multicasting", STD 5, 670 RFC 1112, August 1989. 672 [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", 673 RFC 2131, March 1997. 675 [RFC2461] Narten, T., Nordmark, E., and W. Simpson, "Neighbor 676 Discovery for IP Version 6 (IPv6)", RFC 2461, 677 December 1998. 679 [RFC2462] Thomson, S. and T. Narten, "IPv6 Stateless Address 680 Autoconfiguration", RFC 2462, December 1998. 682 [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., 683 and M. Carney, "Dynamic Host Configuration Protocol for 684 IPv6 (DHCPv6)", RFC 3315, July 2003. 686 [RFC3513] Hinden, R. and S. Deering, "Internet Protocol Version 6 687 (IPv6) Addressing Architecture", RFC 3513, April 2003. 689 [RFC3633] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic 690 Host Configuration Protocol (DHCP) version 6", RFC 3633, 691 December 2003. 693 [RFC3810] Vida, R. and L. Costa, "Multicast Listener Discovery 694 Version 2 (MLDv2) for IPv6", RFC 3810, June 2004. 696 [RFI2.0] CableLabs, "CableLabs Data-Over-Cable Service Interface 697 Specifications: Radio Frequency Interface Specification 698 SP-RFI2.0-I09-050812", December 2005. 700 Authors' Addresses 702 Ralph Droms 703 Cisco Systems, Inc. 704 1414 Massachusetts Avenue 705 Boxborough, MA 01719 706 USA 708 Phone: +1 978 936 1674 709 Email: rdroms@cisco.com 711 Alain Durand 712 Comcast Corporation 713 1500 Market Street 714 Philadelphia, PA 09102 715 USA 717 Email: alain_durand@cable.comcast.com 719 Deepak Kharbanda 720 CableLabs 721 858 Coal Creek Circle 722 Louisville, CO 80027 723 USA 725 Email: d.kharbanda@cablelabs.com 726 Jean-Francois Mule 727 CableLabs 728 858 Coal Creek Circle 729 Louisville, CO 80027 730 USA 732 Email: jfm@cablelabs.com 734 Full Copyright Statement 736 Copyright (C) The Internet Society (2006). 738 This document is subject to the rights, licenses and restrictions 739 contained in BCP 78, and except as set forth therein, the authors 740 retain all their rights. 742 This document and the information contained herein are provided on an 743 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 744 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 745 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 746 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 747 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 748 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 750 Intellectual Property 752 The IETF takes no position regarding the validity or scope of any 753 Intellectual Property Rights or other rights that might be claimed to 754 pertain to the implementation or use of the technology described in 755 this document or the extent to which any license under such rights 756 might or might not be available; nor does it represent that it has 757 made any independent effort to identify any such rights. Information 758 on the procedures with respect to rights in RFC documents can be 759 found in BCP 78 and BCP 79. 761 Copies of IPR disclosures made to the IETF Secretariat and any 762 assurances of licenses to be made available, or the result of an 763 attempt made to obtain a general license or permission for the use of 764 such proprietary rights by implementers or users of this 765 specification can be obtained from the IETF on-line IPR repository at 766 http://www.ietf.org/ipr. 768 The IETF invites any interested party to bring to its attention any 769 copyrights, patents or patent applications, or other proprietary 770 rights that may cover technology that may be required to implement 771 this standard. Please address the information to the IETF at 772 ietf-ipr@ietf.org. 774 Acknowledgment 776 Funding for the RFC Editor function is provided by the IETF 777 Administrative Support Activity (IASA).