Internet DRAFT - draft-mule-cablelabs-docsis3-ipv6
draft-mule-cablelabs-docsis3-ipv6
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]
