[Docs] [txt|pdf] [Tracker] [Email] [Nits]

Versions: 00

Network Working Group                                           R. Droms
Internet-Draft                                       Cisco Systems, Inc.
Intended status: Standards Track                               A. Durand
Expires: September 21, 2006                          Comcast Corporation
                                                            D. Kharbanda
                                                               J-F. Mule
                                                               CableLabs
                                                          March 20, 2006


                DOCSIS 3.0 Requirements for IPv6 support
                draft-mule-cablelabs-docsis3-ipv6-00.txt

Status of this Memo

   By submitting this Internet-Draft, each author represents that any
   applicable patent or other IPR claims of which he or she is aware
   have been or will be disclosed, and any of which he or she becomes
   aware will be disclosed, in accordance with Section 6 of BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt.

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

   This Internet-Draft will expire on September 21, 2006.

Copyright Notice

   Copyright (C) The Internet Society (2006).

Abstract

   This document provides an overview of the draft requirements for IPv6
   support in the CableLabs DOCSIS 3.0 specifications.  Our goal is to
   share high-level IPv6 requirements and design architecture in draft
   status with the IETF community.



Droms, et al.          Expires September 21, 2006               [Page 1]


Internet-Draft  DOCSIS 3.0 Requirements for IPv6 support      March 2006


   We first introduce the main network elements involved in the support
   of IPv6 in DOCSIS cable networks and expand on the deployment
   scenarios in scope of the DOCSIS 3.0 efforts.  We elaborate on the
   roles played by some network elements in enabling IPv6 in DOCSIS: the
   broadband access device (Cable Modem), the headend or network side
   equipment (Cable Modem Termination System) and the various backoffice
   servers.  Some high-level requirements are then summarized with a
   special focus on three network services: IPv6 provisioning and
   management of cable modems, IPv6 transport via a DOCSIS network using
   a cable modem acting as an IPv6 bridge or router, and IP multicast.
   Finally, we conclude with a theory of operations section to provide
   more details and sample flows on how an IPv6-capable cable modem
   acquires its IPv6 address and configuration parameters over a DOCSIS
   3.0 network.

   CableLabs, its members, the vendors participating in the DOCSIS
   specifications and the co-authors of this document are seeking
   general feedback from the IETF community on the overall DOCSIS IPv6
   approach.  The level of requirements provided in this document may
   vary; we also welcome feedback on where more details should be
   provided in future versions.






























Droms, et al.          Expires September 21, 2006               [Page 2]


Internet-Draft  DOCSIS 3.0 Requirements for IPv6 support      March 2006


Table of Contents

   1.  Overview of DOCSIS 3.0 Networks  . . . . . . . . . . . . . . .  4
   2.  Motivations for IPv6 in DOCSIS 3.0 . . . . . . . . . . . . . .  7
   3.  Theory of operations . . . . . . . . . . . . . . . . . . . . .  7
     3.1.  CM Configuration and Provisioning  . . . . . . . . . . . .  8
       3.1.1.  Steps in CM Provisioning . . . . . . . . . . . . . . .  8
       3.1.2.  Dual-stack management  . . . . . . . . . . . . . . . . 10
       3.1.3.  Alternative Provisioning Mode (APM)  . . . . . . . . . 10
     3.2.  CM Management  . . . . . . . . . . . . . . . . . . . . . . 10
     3.3.  Motivation for Use of DHCPv6 . . . . . . . . . . . . . . . 11
   4.  High-level IPv6 Requirements for DOCSIS Devices  . . . . . . . 11
     4.1.  CMTS Requirements for IPv6 . . . . . . . . . . . . . . . . 12
     4.2.  Cable Modem Requirements for IPv6 Support  . . . . . . . . 12
     4.3.  Embedded IPv6 Router Requirements  . . . . . . . . . . . . 13
     4.4.  IPv6 Multicast Support . . . . . . . . . . . . . . . . . . 14
   5.  DOCSIS 3.0 DHCPv6 Requirements . . . . . . . . . . . . . . . . 15
   6.  Open Issues  . . . . . . . . . . . . . . . . . . . . . . . . . 16
   7.  Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . 16
   8.  Security Considerations  . . . . . . . . . . . . . . . . . . . 16
   9.  Normative References . . . . . . . . . . . . . . . . . . . . . 16
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 17
   Intellectual Property and Copyright Statements . . . . . . . . . . 19




























Droms, et al.          Expires September 21, 2006               [Page 3]


Internet-Draft  DOCSIS 3.0 Requirements for IPv6 support      March 2006


1.  Overview of DOCSIS 3.0 Networks

   This section provides some terminology and background information on
   cable access networks to the readers who may not be familiar with
   DOCSIS networks.

   The CableLabs(r) DOCSIS(r) project (Data Over Cable Service Interface
   Specification) defines interface requirements for cable modems
   involved in high-speed data distribution over cable television system
   networks.  CableLabs has published the DOCSIS 2.0 specification
   [RFI2.0], and CableLabs is currently developing the DOCSIS 3.0
   specification.

   In this document, we use the following terminology for a DOCSIS
   network:

   Cable access network or hybrid-fiber/coax (HFC) network:  A broadband
      cable access network that may take the form of either an all-coax
      or hybrid-fiber/coax (HFC) network.  The generic term "cable
      network" is used here to cover all cases.  It is the logical or
      physical portion of network between a cable modem and a cable
      modem termination system.

   Core data network:  The data network operated by a cable service
      provider to run DOCSIS high-speed data services.  It connects the
      cable modem termination system to the backoffice systems and the
      rest of the Internet network.

   Home network:  the network connecting CPEs to the cable modem.

   The main elements that participate in a DOCSIS network and the
   provisioning of DOCSIS services include:

   the Cable Modem (CM):  The CM connects to the operator's cable
      network and to a home network, forwarding packets between them.
      Many devices can be attached to the home network, including
      standalone devices and devices embedded in the CM.

   Customer Premises Equipment (CPE):  DOCSIS 3.0 CMs will support CPE
      devices and hosts that may use IPv4, IPv6 or dual stack IPv4 and
      IPv6.  CMs may provide layer 2 bridging of Ethernet transport, but
      the details of this function are out of the scope of this
      document.  Examples of typical CPE devices are home routers, VoIP
      telephony adapters, set-top devices, personal computers, etc.







Droms, et al.          Expires September 21, 2006               [Page 4]


Internet-Draft  DOCSIS 3.0 Requirements for IPv6 support      March 2006


   the Cable Modem Termination System (CMTS):  The CMTS connects the
      operator's core data network with the HFC access network.  At a
      high level, the CMTS possesses two interfaces: a Network Side
      Interface (NSI) connecting the CMTS to the core data network and
      the RF Interface (RFI) connecting the CMTS to the cable network.
      Its main function is to forward packets between these two domains,
      and between upstream and downstream channels on the cable network.

      The CMTS may operate as a layer-2 bridging or layer-3 routing
      device.  In either case, there is a "network-side routing
      function" provided either in the CMTS or by a separate router.
      The CMTS forwarding capabilities for IPv6 are described in more
      detail below.

   various backoffice configuration services:  Various services provide
      configuration and other support to the devices on the DOCSIS
      network.  These services are implemented in servers connected to
      the core data network.  In a DOCSIS 3.0 network, these servers may
      use IPv4, IPv6 or both as appropriate to the particular operator's
      deployment.

   The network diagram in Figure 1 shows the various components
   described about.  The figure illustrates three configurations:

   o  CPEs connected through a bridging CM (CM1)

   o  a CPE router (RTR) with multiple downstream links connected
      through a bridging CM (CM2)

   o  CPEs connected through a routing CM (CM3)





















Droms, et al.          Expires September 21, 2006               [Page 5]


Internet-Draft  DOCSIS 3.0 Requirements for IPv6 support      March 2006


      CPE-+
          |
      CPE-+--(A)----CM1+
          |             \
      CPE-+              |
                         |
      CPE-+              |
          |              |
      CPE-+-(C)+         |
               |         +-(A)-+----+     DNS  SNMP
      CPE-+     \              |    |      |    |     Other
          +-(D)--RTR-CM2---(B)-+CMTS+----Core network-Mgmt
      CPE-+     /              |    |      |    |     Systems
               |         +-(F)-+----+     DHCP TFTP
      CPE-+-(E)+         |
          |              |
      CPE-+              |
                         |
      CPE-+              |
          |             /
      CPE-+- (G)----CM3+
          |
      CPE-+

      <------------->  <------->      <---------------------->
        Home          Cable Access       Core Data Network
        Network       Network


      CM1 is a bridging CM
      CM2 is a bridging CM, RTR is an external CPE router with multiple
        downstream links
      CM3 is a routing CM with a single downstream link

      Links A, B and F are all bridged by the CMTS.

      Customer 2 (CM2) is assigned 2001:DB8:2::/48
      Customer 3 (CM3) is assigned 2001:DB8:3::/48

      Links A, B and F are assigned 2001:DB8:0:0::/64
      Link C is assigned            2001:DB8:2:1::/64
      Link D is assigned            2001:DB8:2:2::/64
      Link E is assigned            2001:DB8:2:3::/64
      Link G is assigned            2001:DB8:3:1::/64



   Figure 1: Example DOCSIS 3.0 network.



Droms, et al.          Expires September 21, 2006               [Page 6]


Internet-Draft  DOCSIS 3.0 Requirements for IPv6 support      March 2006


2.  Motivations for IPv6 in DOCSIS 3.0

   The primary motivations for enabling IPv6 support in cable operator
   networks may vary from one cable operator to another and depend on
   each cable operator's IPv6 adoption strategy.

   Some cable operators view IPv6 support in DOCSIS as a critical
   element for CM provisioning and management to alleviate the IPv4
   address space management issues.

   Some cable operators view IPv6 support as a stepping stone to provide
   IPv6 connectivity within the home.

   Some believe that the basic CM with IPv6 support should initially be
   a link-layer bridge while others have expressed support for a CM
   acting as an IPv6 layer-3 forwarding device with some router
   functionality.

   The main motivations for IPv6 support in DOCSIS 3.0 include:

   o  to provide CM and CPE operations through IPv6

   o  to manage IPv6-only CMs, and, dual-stack IPv4 and IPv6 CMs,

   o  to enable native IPv6 transport over cable access networks with a
      DOCSIS 3.0 CM acting as a bridge or router for IPv6 traffic.

   Interoperability with other DOCSIS versions is a critical requirement
   to support various deployment scenarios and enable IPv6 migration
   with a phased approach.  For example, a 3.0 CM must operate on an
   IPv4 DOCSIS 2.0 network and a 3.0 CMTS must be able to support all
   variants of DOCSIS CMs (3.0 IPv6 CM, 3.0 IPv4 CM, 2.0 IPv4 CM, etc.).


3.  Theory of operations

   This section describes the process for initial configuration and
   provisioning of a DOCSIS 3.0 CM using IPv6.  The description focuses
   on the layer 3 provisioning, although it includes some layer 2
   provisioning that controls the layer 3 provisioning.  This section
   first highlights some of the important design choices that were made
   when defining IPv6 requirements for DOCSIS 3.0 cable modems.  We then
   provide sample flows representing IPv6 message exchanges.

   DOCSIS 3.0 also defines a process for CM configuration using IPv4.
   The details of that provisioning process are beyond the scope of this
   document.




Droms, et al.          Expires September 21, 2006               [Page 7]


Internet-Draft  DOCSIS 3.0 Requirements for IPv6 support      March 2006


   As described in Section 1, a DOCSIS 3.0 CM can operate in either
   bridging or routing mode.  In either case, the CM has a full IP stack
   that can support local applications and that has an IPv4 address, an
   IPv6 address or both assigned to an interface on the cable network.
   The primary use for the local applications is initial configuration,
   which uses DHCP, TFTP and Network Time protocol, and operational
   management, which uses SNMP.

   A DOCSIS 3.0 CM management IP stack can operate in the following
   modes: IPv4 only, IPv6 mode, and dual IPv4-IPv6 mode.  The
   operational mode of a CM is independent of the protocols forwarded by
   the CM to CPEs on the home network; for example, a DOCSIS 3.0 CM
   provisioned and managed in IPv4 supports bridging of traffic for IPv6
   CPEs and vice-versa.

3.1.  CM Configuration and Provisioning

   During initialization, the CM receives some directives on how to
   establish its IP connectivity (IP provisioning mode) using a DOCSIS
   MAC Management Message at layer 2 containing the following
   information: the CM IP provisioning mode (IPv6 or IPv4), an indicator
   of whether the CM should enable Alternative Provisioning Mode (APM),
   and an indicator to enable or disable dual-stack management.  APM and
   dual-stack management will be explained further below.

   For backward compatibility reasons, if the CM does not receive a
   DOCSIS MAC Management Message containing the above parameters from
   the CMTS, the CM operates as though it is connected to a pre DOCSIS
   3.0 network or legacy provisioning system.  In this case, the CM
   performs IPv4 configuration and provisioning in DOCSIS 2.0 mode.

3.1.1.  Steps in CM Provisioning

   The DOCSIS 3.0 provisioning process includes the following steps:

   Layer 2:  The CM begins by performing layer 2 provisioning with the
      CMTS.  The details of this provisioning process are beyond the
      scope of this document.  As part of the layer 2 provisioning, the
      CM receives a message from the CMTS that controls:

      *  Use of IPv4 or IPv6 for CM provisioning and management

      *  Dual-stack management

      *  APM

      The remainder of the provisioning process described here will
      assume the use of IPv6 without dual-stack management and APM.  The



Droms, et al.          Expires September 21, 2006               [Page 8]


Internet-Draft  DOCSIS 3.0 Requirements for IPv6 support      March 2006


      use of dual-stack management and APM will be described later.

   Acquire IPv6 Connectivity:  In this step, the CM acquires a link-
      local IPv6 address on the cable network and an address of larger
      scope to be used for the CM management applications.

      The CM creates a link-local address, assigns that address to the
      CM management interface and uses duplicate address detection
      [RFC2462] to confirm that the link-local address is not already in
      use on the cable network.

      If the CM finds that the link-local address is already in use, the
      CM restarts its provisioning process and a report is sent to the
      cable operators error logging system.

      The CM then uses Neighbor Discovery (ND) [RFC2461] to locate the
      CMTS router and other information from a Router Advertisement (RA)
      message.

      DOCSIS 3.0 defines that IPv6 address assignment to the CM uses
      DHCPv6 [RFC3315], so the 'M' and 'O' flags in the RA are set to
      cause the CM to initiate DHCPv6.

      After receiving the RA, the CM initiates a DHCPv6 message
      exchange.  The DHCPv6 server supplies the IPv6 address for the CM
      management interface, as well as other configuration information.
      Section 5 lists the DHCPv6 options used in CM provisioning.

   Obtain configuration file:  Once the CM has the IPv6 address assigned
      to its management interface, it uses TFTP (over IPv6) to download
      a DOCSIS 3.0 configuration file.  The name and address of this
      file are provided through the DHCPv6 message exchange in the
      previous step.

   Set time of day:  The CM contacts a Network Time protocol server
      [RFC0868] to set its internal clock.  The address of the Network
      Time protocol server is provided through DHCPv6.

   Complete Registration with CMTS:  After the configuration and
      provisioning steps are completed, the CM completes its
      registration with the CMTS.  The CM authenticates itself to the
      CMTS and supplies its layer 2 and IPv6 addresses to the CMTS.  The
      CMTS records these addresses for subsequent validation of traffic
      from the CM







Droms, et al.          Expires September 21, 2006               [Page 9]


Internet-Draft  DOCSIS 3.0 Requirements for IPv6 support      March 2006


3.1.2.  Dual-stack management

   To provide higher reliability for CM management through redundancy, a
   CM can be configured to be managed through SNMP carried over IPv4 or
   IPv6.  In this scenario, after completing the normal configuration
   process, the CM obtains a second IP address to assign to its
   management interface.  For example, if the CM has been provisioned
   through IPv6 and is configured to use dual-stack management, the CM
   uses DHCPv4 to obtain an IPv4 address, which it assigns to its
   management interface.

3.1.3.  Alternative Provisioning Mode (APM)

   A CM can be configured to use APM to improve provisioning
   reliability.  When using APM, the CM first uses the primary
   provisioning protocol (IPv6 or IPv4), as specified by the CMTS.  If
   this provisioning mode fails, the CM then tries to provision itself
   using the other protocol.  For example, if a CM is initially
   configured to use IPv6 for provisioning and to use APM, if the CM is
   unable to contact a TFTP server over IPv6, it will restart the
   provisioning process using IPv4.

3.2.  CM Management

   Prior to registration with the CMTS, the CM is managed via both IPv4
   and IPv6.  For data forwarding requirements related to IPv6 prior to
   CMTS registration, the CM is required to:

   o  respond to SNMP queries and ICMP Echo packets sent to its
      diagnostic IP address from the CMCI port(s).  The diagnostic CM IP
      address is a well-known IP address used only for troubleshooting
      purposes prior to CM registration;

   o  send all DHCPv4 DHCPDISCOVER or DHCPREQUEST, DHCPv6 Solicit or
      Request, TFTP or Time Protocol Request, or IPv6 Router
      Solicitation messages to its RF interface (towards the CMTS) - it
      must not send any of these requests to any other interface,

   o  not forward any packets between its RF interface and its CMCI or
      other any other internal interfaces (embedded eSAFE).

   After successful CMTS registration, the CM applies standard packet
   forwarding rules.  Some frame or packet filtering and processing
   rules may apply based on its configuration file or other requirements
   (for example, the CM must not forward unicast frames addressed to
   unknown destination MAC addresses, or, it must not accept any
   DHCPOFFER, ADVERTISE, etc. from the CMCI interface).  The details on
   the packet forwarding rules are out of scope of this document.



Droms, et al.          Expires September 21, 2006              [Page 10]


Internet-Draft  DOCSIS 3.0 Requirements for IPv6 support      March 2006


3.3.  Motivation for Use of DHCPv6

   As DHCPv4 plays a key role in cable modem provisioning in today's
   network and the cable operator's operations, DHCPv6 is also used in
   IPv6 mode of operation for the cable modem to acquire its IP address
   from the MSO backoffice systems.

   A DOCSIS 3.0 Cable Modem obtains its IP address via DHCPv6, not
   stateless address autoconfiguration.  This design choice was
   motivated by several factors:

   o  the fact that cable networks are operated with highly managed
      requirements and the knowledge and control of IP address
      assignments is deemed important

   o  the importance of minimizing the changes in management and
      operational models (DHCP is the first gate for access network
      control, the binding of IPv6 addresses to DNS hostnames is
      critical in IPv6 and the use of stateful DHCPv6 services to
      perform this binding is seen by some operators as easier to
      implement than with SAAC)

   o  Due to the fact that DNS plays a more important role than in IPv4
      (IPv6 addresses are so error prone to type), DHCP servers are
      perceived as the simplest place to perform dynamic DNS updates in
      both the forward and reverse DNS tree.


4.  High-level IPv6 Requirements for DOCSIS Devices

   Based on the deployment scenarios and cable operator motivations for
   deploying IPv6, the DOCSIS 3.0 specifications address the
   requirements for CM and CMTS operation described in this section.
   Some requirements are centered around CM provisioning and management
   using IPv6 while others are enabling native IPv6 transport for CPEs.

   Cable operators have identified the following requirements for IPv6
   in DOCSIS 3.0:

   o  IPv6-only operation

   o  IPv6 provisioning with dual-stack management

   o  Fallback from IPv6 to IPv4 provisioning

   o  Backward compatibility with devices qualified for previous DOCSIS
      versions




Droms, et al.          Expires September 21, 2006              [Page 11]


Internet-Draft  DOCSIS 3.0 Requirements for IPv6 support      March 2006


   o  Control of CM provisioning modes by cable operator

   o  Provisioning, management and operation of embedded router

   o  Provisioning and operation of CPE router

4.1.  CMTS Requirements for IPv6

   The CMTS provides IP connectivity between hosts attached to the cable
   modems (the hosts attached to the CMs can communicate only via the
   CMTS) and between the CM and the core data network.

   The CMTS can act as a bridge or router: it performs data forwarding
   in transparent bridging or network-layer forwarding mode, or a
   combination of the two.  The link-layer requirements applicable to
   CMTS are out of scope of this document.

   For IPv6, the CMTS participates in Neighbor Discovery (ND) [RFC2461].
   The CMTS must either forward ND packets from one host to the other,
   or facilitate a proxy ND service, which responds on behalf of other
   hosts.  A proxy ND service on the CMTS also reduces the possibility
   of potential denial of service attacks because the ND messages are
   not forwarded to hosts (untrusted entities).  The implementation of
   the proxy ND service is vendor dependent and not specified by the
   CableLabs specifications.

   The CMTS acts as a relay agent for DHCPv6 messages.  The CMTS adds
   specific DHCPv6 relay agent options to pass information about the
   type and location of CMs and CPEs to the DHCPv6 server(s).  The CMTS
   also receives DHCPv6 relay agent options from the DHCPv6 server
   regarding the assignment of prefixes and addresses to CPEs.

   The network-side routing function generates Router Advertisement (RA)
   messages [RFC2461].  In the case of a routing CMTS, the RAs are
   forwarded directly to the cable network.  In the case of a bridging
   CMTS, the network-side routing function is provided b y a separate
   router, which forwards the RAs to the RFI interface for appropriate
   forwarding by the bridging CMTS.

   When the routing CMTS forwards well-known IPv6 multicast packets from
   the NSI to RFI, the CMTS terminates and applies appropriate
   processing.

4.2.  Cable Modem Requirements for IPv6 Support

   The DOCSIS 3.0 CM must support operations in IPv4, IPv6, or both IPv4
   and IPv6 including:




Droms, et al.          Expires September 21, 2006              [Page 12]


Internet-Draft  DOCSIS 3.0 Requirements for IPv6 support      March 2006


   o  Device provisioning for the CM through IPv6 or IPv4.  The choice
      of provisioning mode is controlled by the cable operator through
      the CMTS.  A mode is also defined when provisioning will fall back
      from one IP version to the other in case of failure.  This
      behavior is required to support a variety of operating
      environments and failure conditions.

   o  IPv6 address assignment through DHCPv6 [RFC3315]; Section 3gives
      some of the reasons that led to this choice and how it compares
      with today's IPv4 address assignment mechanism through DHCP.

   o  Element management through IPv6, IPv4, or dual-stack IPv4 and
      IPv6.  The mode of element mode management is controlled by the
      cable operator through the CMTS.

   o  Data forwarding of IPv4 and IPv6 traffic from and to CPE through
      the CM regardless of how the modem is provisioned for the cable
      operator's management purposes.

4.3.  Embedded IPv6 Router Requirements

   A DOCSIS 3.0 CM integrated device may include an embedded IPv6
   router.  This section highlights some of the critical requirements an
   embedded DOCSIS IPv6 router must support.

   For IP-level requirements (IPv6 Routing, Forwarding, Multicast,
   etc.), the embedded router must:

   o  support Neighbor Discovery and Router Solicitation queries from
      IPv6 CPE hosts

   o  forward IPv6 packets to multiple stand-alone IPv6 CPE Routers for
      a single global IPv6 prefix

   o  support propagation of other configuration information such as the
      addresses of DNS servers

   o  support Multicast Listener Discovery (MLD) proxy for MLDv1 and
      MLDv2

   For Provisioning and Management, the embedded router must:

   o  implement a DHCPv6 client to acquire Prefix from the cable
      operator's network and obtain its global-scope IPv6 management
      address(es)

   o  support IPv6 Stateless Autonomous Auto-Configuration (SAAC) for
      CPE hosts



Droms, et al.          Expires September 21, 2006              [Page 13]


Internet-Draft  DOCSIS 3.0 Requirements for IPv6 support      March 2006


   o  implement a DHCPv6 Server with IPv6 Prefix Delegation to CPE hosts

   o  support router configuration via TFTP and other optional protocols
      (like HTTPS)

   o  support SNMPv3 and IPv6 MIBs including the IETF Host and Router
      MIB modules along with the ability to enable or disable the IPv6
      router functionality

   The QoS requirements are being defined and are left out of scope for
   now.  They will be added in a future revision of this I-D.

4.4.  IPv6 Multicast Support

   DOCSIS 3.0 provides enhanced support for IP Multicast with the
   addition of several new capabilities.  The main features in-scope of
   this document include support for Source Specific Multicast (SSM)
   [ID-SSM-ARCH] (forwarding of SSM traffic for MLDv2) and IPv6
   multicast transport (multicast traffic including Neighbor Discovery
   (ND), Router Solicitation (RS), etc.).

   DOCSIS 3.0 supports both the traditional form of IP Multicast, Any
   Source Multicast (ASM) [RFC1112], as well as Source Specific
   Multicast (SSM) which is particularly relevant for broadcast-type IP
   multicast applications.  MLDv2 for IPv6 [RFC3810] is required for
   SSM.

   The membership reports are passed transparently by the CM towards the
   CMTS.  The CMTS operates as an MLD querier, and as an IPv6 multicast
   router for a routing CMTS or listener (snooping switch) for a
   bridging CMTS.  In IPv6 multicast, both the "Any Source Multicast"
   (ASM) and the "Source Specific Multicast" models are supported.

   Specific requirements exist on the CM and CMTS to properly handle
   IPv6 multicast.  For example, in order to successfully obtain its IP
   address and register with the CMTS, the CM needs to receive certain
   multicast packets such as those used for DHCPv6, router discovery and
   duplicate address detection.  Another example of IPv6 multicast
   requirements is that a CMTS MUST forward downstream IPv6 multicast
   traffic to CPE devices joined through MLDv2.  Also, the CM must
   forward IPv6 registration multicast traffic for CPEs behind the CM.

   More details on IPv6 multicast support may be provided in future
   versions of this document.  Other multicast capabilities are included
   in DOCSIS 3.0 but they are out of scope of this document.






Droms, et al.          Expires September 21, 2006              [Page 14]


Internet-Draft  DOCSIS 3.0 Requirements for IPv6 support      March 2006


5.  DOCSIS 3.0 DHCPv6 Requirements

   This section lists the main IETF DHCPv6 client and relay agent DHCP
   options used for CM IPv6 provisioning.  It provides more details on
   how DHCPv6 is used to acquire configuration parameters.

   DHCPv6 Client options include:

   Published IETF RFCs:  as defined in [RFC3315] and [RFC3633]
      Client Identifier option (DUID)
      IPv6 address assignment (IA_NA, IA_TA)
      Prefix assignment (IA_PD)
      Rapid commit
      Reconfigure accept
      Option request

   Current IETF Internet-Drafts (in DHC wg):
      RFC 868 Time Protocol servers
      Time offset

   CableLabs vendor specific options:
      These sub-option parameters are defined as part of the DHCPv6
      Vendor-specific Information option defined in section 22.17 of RFC
      3315, under the CableLabs enterprise number:
      DOCSIS version identifier
      CM capabilities
      TFTP servers
      TFTP configuration file name
      syslog servers
      Device ID (MAC address)

   The DHCP Relay agent options include:

   Published IETF RFCs:
      Interface-ID

   Current IETF Internet-Drafts (in DHC wg):
      Subscriber-ID option
      Assignment information

   CableLabs vendor specific options:
      CMTS capabilities: additional CMTS capability strings are defined
      which contains the DOCSIS version of the relay agent.
      CM MAC address







Droms, et al.          Expires September 21, 2006              [Page 15]


Internet-Draft  DOCSIS 3.0 Requirements for IPv6 support      March 2006


6.  Open Issues

   This could be a section where we seek more guidance or provide a more
   direct view on how we have taken some IPv6 requirements.


7.  Acknowledgments

   This document is based on the work of a large number of people and
   contributors participating in the CableLabs DOCSIS project.  The
   authors would like to recognize and thank the following for their
   assistance and contributions:

   Jason Combs and John Brzozowski of Comcast, Ron da Silva and Chris
   Williams of Time Warner Cable, Victor Blake of Advance New House,
   Kirk Erichsen of Adelphia, Ben Bekele of Cox Communications, Doc R.
   Evans and Dan Torbet of Arris, Margo Dolas and Cliff Danielson of
   Broadcom, Amol Bhagwat of CableLabs, Diego Mazzola of TI and Madhu
   Sudan of Cisco.


8.  Security Considerations

   None.


9.  Normative References

   [RFC0868]  Postel, J. and K. Harrenstien, "Time Protocol", STD 26,
              RFC 868, May 1983.

   [RFC1112]  Deering, S., "Host extensions for IP multicasting", STD 5,
              RFC 1112, August 1989.

   [RFC2131]  Droms, R., "Dynamic Host Configuration Protocol",
              RFC 2131, March 1997.

   [RFC2461]  Narten, T., Nordmark, E., and W. Simpson, "Neighbor
              Discovery for IP Version 6 (IPv6)", RFC 2461,
              December 1998.

   [RFC2462]  Thomson, S. and T. Narten, "IPv6 Stateless Address
              Autoconfiguration", RFC 2462, December 1998.

   [RFC3315]  Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C.,
              and M. Carney, "Dynamic Host Configuration Protocol for
              IPv6 (DHCPv6)", RFC 3315, July 2003.




Droms, et al.          Expires September 21, 2006              [Page 16]


Internet-Draft  DOCSIS 3.0 Requirements for IPv6 support      March 2006


   [RFC3513]  Hinden, R. and S. Deering, "Internet Protocol Version 6
              (IPv6) Addressing Architecture", RFC 3513, April 2003.

   [RFC3633]  Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic
              Host Configuration Protocol (DHCP) version 6", RFC 3633,
              December 2003.

   [RFC3810]  Vida, R. and L. Costa, "Multicast Listener Discovery
              Version 2 (MLDv2) for IPv6", RFC 3810, June 2004.

   [RFI2.0]   CableLabs, "CableLabs Data-Over-Cable Service Interface
              Specifications: Radio Frequency Interface Specification
              SP-RFI2.0-I09-050812", December 2005.


Authors' Addresses

   Ralph Droms
   Cisco Systems, Inc.
   1414 Massachusetts Avenue
   Boxborough, MA  01719
   USA

   Phone: +1 978 936 1674
   Email: rdroms@cisco.com


   Alain Durand
   Comcast Corporation
   1500 Market Street
   Philadelphia, PA  09102
   USA

   Email: alain_durand@cable.comcast.com


   Deepak Kharbanda
   CableLabs
   858 Coal Creek Circle
   Louisville, CO  80027
   USA

   Email: d.kharbanda@cablelabs.com








Droms, et al.          Expires September 21, 2006              [Page 17]


Internet-Draft  DOCSIS 3.0 Requirements for IPv6 support      March 2006


   Jean-Francois Mule
   CableLabs
   858 Coal Creek Circle
   Louisville, CO  80027
   USA

   Email: jfm@cablelabs.com












































Droms, et al.          Expires September 21, 2006              [Page 18]


Internet-Draft  DOCSIS 3.0 Requirements for IPv6 support      March 2006


Full Copyright Statement

   Copyright (C) The Internet Society (2006).

   This document is subject to the rights, licenses and restrictions
   contained in BCP 78, and except as set forth therein, the authors
   retain all their rights.

   This document and the information contained herein are provided on an
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.


Intellectual Property

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at
   http://www.ietf.org/ipr.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at
   ietf-ipr@ietf.org.


Acknowledgment

   Funding for the RFC Editor function is provided by the IETF
   Administrative Support Activity (IASA).





Droms, et al.          Expires September 21, 2006              [Page 19]


Html markup produced by rfcmarkup 1.129c, available from https://tools.ietf.org/tools/rfcmarkup/