Network Working Group B. Beser
Request for Comments: 3495 Juniper Networks
Category: Standards Track P. Duffy, Ed.
Cisco Systems
March 2003
Network Working Group B. Beser
Request for Comments: 3495 Juniper Networks
Category: Standards Track P. Duffy, Ed.
Cisco Systems
March 2003
Dynamic Host Configuration Protocol (DHCP) Option for CableLabs Client Configuration
CableLabs客户端配置的动态主机配置协议（DHCP）选项
Status of this Memo
本备忘录的状况
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
本文件规定了互联网社区的互联网标准跟踪协议，并要求进行讨论和提出改进建议。有关本协议的标准化状态和状态，请参考当前版本的“互联网官方协议标准”（STD 1）。本备忘录的分发不受限制。
Copyright Notice
版权公告
Copyright (C) The Internet Society (2003). All Rights Reserved.
版权所有（C）互联网协会（2003年）。版权所有。
Abstract
摘要
This document defines a Dynamic Host Configuration Protocol (DHCP) option that will be used to configure various devices deployed within CableLabs architectures. Specifically, the document describes DHCP option content that will be used to configure one class of CableLabs client device: a PacketCable Media Terminal Adapter (MTA). The option content defined within this document will be extended as future CableLabs client devices are developed.
本文档定义了一个动态主机配置协议（DHCP）选项，用于配置CableLabs体系结构中部署的各种设备。具体而言，本文档描述了将用于配置一类CableLabs客户端设备的DHCP选项内容：PacketCable媒体终端适配器（MTA）。本文档中定义的选项内容将随着未来CableLabs客户端设备的开发而扩展。
Table of Contents
目录
1. Conventions used in this document............................ 2
2. Terminology.................................................. 2
3. Introduction................................................. 3
4. CableLabs Client Configuration Option Format................. 4
5. CableLabs Client Configuration Option: Sub-Option Definitions 5
5.1. TSP's DHCP Server Address Sub-Options.................. 5
5.2. TSP's Provisioning Server Address Sub-Option........... 6
5.3. TSP's AS-REQ/AS-REP Backoff and Retry.................. 6
5.4. TSP's AP-REQ/AP-REP Backoff and Retry.................. 7
5.5. TSP's Kerberos Realm Name Sub-Option................... 8
5.6. TSP's Ticket Granting Server Utilization Sub-Option.... 8
5.7. TSP's Provisioning Timer Sub-Option.................... 8
6. Informational Description of CCC Option Usage................ 9
7. IANA Considerations.......................................... 9
8. Legacy Use Information....................................... 9
9. Procedure for Adding Additional Sub-options.................. 9
10. Security Considerations...................................... 10
11. References................................................... 10
11.1. Normative References................................... 10
11.2. Informative References................................. 11
12. Acknowledgments.............................................. 11
13. Authors' Addresses........................................... 12
14. Full Copyright Statement..................................... 13
1. Conventions used in this document............................ 2
2. Terminology.................................................. 2
3. Introduction................................................. 3
4. CableLabs Client Configuration Option Format................. 4
5. CableLabs Client Configuration Option: Sub-Option Definitions 5
5.1. TSP's DHCP Server Address Sub-Options.................. 5
5.2. TSP's Provisioning Server Address Sub-Option........... 6
5.3. TSP's AS-REQ/AS-REP Backoff and Retry.................. 6
5.4. TSP's AP-REQ/AP-REP Backoff and Retry.................. 7
5.5. TSP's Kerberos Realm Name Sub-Option................... 8
5.6. TSP's Ticket Granting Server Utilization Sub-Option.... 8
5.7. TSP's Provisioning Timer Sub-Option.................... 8
6. Informational Description of CCC Option Usage................ 9
7. IANA Considerations.......................................... 9
8. Legacy Use Information....................................... 9
9. Procedure for Adding Additional Sub-options.................. 9
10. Security Considerations...................................... 10
11. References................................................... 10
11.1. Normative References................................... 10
11.2. Informative References................................. 11
12. Acknowledgments.............................................. 11
13. Authors' Addresses........................................... 12
14. Full Copyright Statement..................................... 13
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14, RFC 2119 [1].
本文件中的关键词“必须”、“不得”、“要求”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照BCP 14、RFC 2119[1]中的描述进行解释。
Definitions of terms used throughout this document:
本文件中使用的术语定义：
* "Telephony Service Provider" or "TSP"
* “电话服务提供商”或“TSP”
The business entity from which a subscriber receives telephony service.
用户从中接收电话服务的业务实体。
See RFC 2131 [6] for additional DHCP terminology.
有关其他DHCP术语，请参见RFC 2131[6]。
Cable Television Laboratories, Inc. (CableLabs) is a non-profit research and development consortium that serves the cable television industry via design and specification of new and emerging broadband service architectures. Several CableLabs initiatives define DHCP clients that have specific DHCP configuration requirements. One such initiative is the PacketCable project.
Cable Television Laboratories，Inc.（CableLabs）是一家非营利性研发财团，通过设计和规范新兴宽带服务架构为有线电视行业提供服务。一些CableLabs计划定义了具有特定DHCP配置要求的DHCP客户端。PacketCable项目就是这样一个倡议。
The PacketCable project is aimed at architecting, qualifying, and supporting Internet-based multimedia services over cable-based packet networks. These new multimedia services will include telephony and videoconferencing, delivered using the basic Internet Protocol (IP) technology that is used to send data via the Internet.
PacketCable项目旨在通过基于电缆的分组网络设计、鉴定和支持基于互联网的多媒体服务。这些新的多媒体服务将包括电话和视频会议，使用通过互联网发送数据的基本互联网协议（IP）技术提供。
PacketCable 1.0 provides Voice over IP (VoIP) service delivery. The VoIP service is supported at the customer site by two key components: a Cable Modem (CM) and a Media Terminal Adapter (MTA). The CM converts the cable RF signals to/from various IP voice protocols, while the MTA converts the VoIP protocols into analog telephony compatible with a common telephone.
PacketCable 1.0提供IP语音（VoIP）服务交付。VoIP服务在客户站点由两个关键组件支持：电缆调制解调器（CM）和媒体终端适配器（MTA）。CM将电缆射频信号转换为各种IP语音协议，MTA将VoIP协议转换为与普通电话兼容的模拟电话。
The CM and MTA may be packaged together or separately. If packaged together, the unit is referred to as an Embedded-MTA (EMTA - depicted in Figure 1). If packaged separately, the MTA is referred to as a Standalone MTA (SMTA).
CM和MTA可以一起包装，也可以单独包装。如果封装在一起，该单元称为嵌入式MTA（图1中所示的EMTA）。如果单独打包，MTA称为独立MTA（SMTA）。
|----------------------------------------------|
| |
| |-----------| |-------------| |
| | | | | |
Telephony | | Media | internal | Cable | | RF Link
----------|---| Terminal |===========| Modem |----|-------
Link | | Adapter | connection| | |
| |-----------| |-------------| |
| |
|----------------------------------------------|
|----------------------------------------------|
| |
| |-----------| |-------------| |
| | | | | |
Telephony | | Media | internal | Cable | | RF Link
----------|---| Terminal |===========| Modem |----|-------
Link | | Adapter | connection| | |
| |-----------| |-------------| |
| |
|----------------------------------------------|
Figure 1. PacketCable 1.0 Embedded-MTA
图1。PacketCable 1.0嵌入式MTA
The CM and MTA are distinct IP devices: each has its own MAC address and IP configuration. The CM and MTA utilize the DHCP protocol to obtain IP configuration. It is assumed that the CM and MTA may be administered by different business entities. The CM communicates with and is configured by the Data Access Provider's (DAP's) DHCP servers. Likewise, the MTA communicates with and is configured by the Telephony Service Provider's (TSP's) DHCP servers.
CM和MTA是不同的IP设备：每个设备都有自己的MAC地址和IP配置。CM和MTA利用DHCP协议获得IP配置。假设CM和MTA可能由不同的业务实体管理。CM与数据访问提供商（DAP）的DHCP服务器通信并由其配置。同样，MTA与电话服务提供商（TSP）的DHCP服务器通信并由其配置。
The PacketCable architecture requires that the business entity controlling the configuration of the CM also determines which business entities control the configuration of the MTA. This is similar to the example found in the PSTN system: individuals can pick their long distance carriers even though the ultimate control of their telephone remains with the local carrier.
PacketCable体系结构要求控制CM配置的业务实体还确定哪些业务实体控制MTA的配置。这类似于PSTN系统中的例子：个人可以选择他们的长途运营商，即使他们的电话最终由本地运营商控制。
Due to specific needs of the MTA configuration process (described in [7]), a new CableLabs Client Configuration (CCC) option is needed for the DHCP protocol. Both CM and MTA DHCP clients will request this option. When requested, both the DAP and TSP DHCP servers will populate this option into DHCP responses. See section 6 for further operational details.
由于MTA配置过程的特殊需要（如[7]所述），DHCP协议需要一个新的CableLabs客户端配置（CCC）选项。CM和MTA DHCP客户端都将请求此选项。当请求时，DAP和TSP DHCP服务器都会将此选项填充到DHCP响应中。更多操作细节见第6节。
It should be noted that, although the CCC option will be initially deployed to support PacketCable VOIP applications, the CCC option will also be used to support various non VOIP applications. Use of the CCC option does not necessarily mean that the service provider is a TSP.
应该注意的是，尽管CCC选项最初将部署为支持分组电缆VOIP应用，但CCC选项也将用于支持各种非VOIP应用。使用CCC选项并不一定意味着服务提供商是TSP。
The option begins with a tag octet containing the option code (code 122). A length octet follows the tag octet. The value of the length octet does not include itself or the tag octet. The length octet is followed by "length" octets of sub-option content (total length, not sub-option count). The option layout is depicted below:
该选项以包含选项代码（代码122）的标记八位字节开始。一个长度八位字节跟随在标记八位字节之后。长度八位字节的值不包括自身或标记八位字节。长度八位字节后面是子选项内容的“长度”八位字节（总长度，而不是子选项计数）。选项布局如下所示：
+------+--------+--------------+--------------+---+--------------+
| 122 | Length | Sub-option 1 | Sub-option 2 |...| Sub-option n |
+------+--------+--------------+--------------+---+--------------+
+------+--------+--------------+--------------+---+--------------+
| 122 | Length | Sub-option 1 | Sub-option 2 |...| Sub-option n |
+------+--------+--------------+--------------+---+--------------+
When the total length of a CCC option exceeds 255 octets, the procedure outlined in [4] MUST be employed to split the option into multiple, smaller options.
当CCC选项的总长度超过255个八位字节时，必须采用[4]中概述的程序将选项拆分为多个较小的选项。
A sub-option begins with a tag octet containing the sub-option code. A length octet follows the tag octet. The value of the length octet does not include itself or the tag octet. The length octet is followed by "length" octets of sub-option information. The sub-option layout is depicted below:
子选项以包含子选项代码的标记八位字节开始。一个长度八位字节跟随在标记八位字节之后。长度八位字节的值不包括自身或标记八位字节。长度八位字节后接子选项信息的“长度”八位字节。子选项布局如下图所示：
+-------------------+--------+------------------------+
| Sub-option Code | Length | Sub-option information |
+-------------------+--------+------------------------+
+-------------------+--------+------------------------+
| Sub-option Code | Length | Sub-option information |
+-------------------+--------+------------------------+
The sub-option codes are summarized below.
子选项代码汇总如下。
+---------+---------+--------------------------------------------+
| Sub- | Sent to | Description |
| option | | |
| Code | | |
+===================+============================================+
| 1 | CM | TSP's Primary DHCP Server Address |
+---------+---------+--------------------------------------------+
| 2 | CM | TSP's Secondary DHCP Server Address |
+---------+---------+--------------------------------------------+
| 3 | MTA | TSP's Provisioning Server Address |
+---------+---------+--------------------------------------------+
| 4 | MTA | TSP's AS-REQ/AS-REP Backoff and Retry |
+---------+---------+--------------------------------------------+
| 5 | MTA | TSP's AP-REQ/AP-REP Backoff and Retry |
+---------+---------+--------------------------------------------+
| 6 | MTA | TSP's Kerberos Realm Name |
+---------+---------+--------------------------------------------+
| 7 | MTA | TSP's Ticket Granting Server Utilization |
+---------+---------+--------------------------------------------+
| 8 | MTA | TSP's Provisioning Timer Value |
+---------+---------+--------------------------------------------+
| 9 - 255 | | Reserved for future extensions |
+---------+---------+--------------------------------------------+
+---------+---------+--------------------------------------------+
| Sub- | Sent to | Description |
| option | | |
| Code | | |
+===================+============================================+
| 1 | CM | TSP's Primary DHCP Server Address |
+---------+---------+--------------------------------------------+
| 2 | CM | TSP's Secondary DHCP Server Address |
+---------+---------+--------------------------------------------+
| 3 | MTA | TSP's Provisioning Server Address |
+---------+---------+--------------------------------------------+
| 4 | MTA | TSP's AS-REQ/AS-REP Backoff and Retry |
+---------+---------+--------------------------------------------+
| 5 | MTA | TSP's AP-REQ/AP-REP Backoff and Retry |
+---------+---------+--------------------------------------------+
| 6 | MTA | TSP's Kerberos Realm Name |
+---------+---------+--------------------------------------------+
| 7 | MTA | TSP's Ticket Granting Server Utilization |
+---------+---------+--------------------------------------------+
| 8 | MTA | TSP's Provisioning Timer Value |
+---------+---------+--------------------------------------------+
| 9 - 255 | | Reserved for future extensions |
+---------+---------+--------------------------------------------+
The following sections provide detailed descriptions of each sub-option. There are a few general formatting rules:
以下各节提供了每个子选项的详细说明。有一些通用格式规则：
- Fully Qualified Domain Names (FQDNs) MUST be encoded per RFC 1035 [3] section 3.1. Note that a terminating 0 is required. Also note that compression, as described in RFC 1035 [3] section 4.1.4, MUST NOT be applied.
- 完全限定域名（FQDN）必须按照RFC 1035[3]第3.1节进行编码。请注意，需要终止0。还应注意，不得采用RFC 1035[3]第4.1.4节所述的压缩。
- IPv4 addresses MUST be encoded as 4 binary octets in network byte-order (high order byte first).
- IPv4地址必须按网络字节顺序（先是高阶字节）编码为4个二进制八位字节。
- All multi-octet quantities MUST be encoded per network byte-ordering.
- 所有多八位组数量必须按网络字节顺序编码。
The TSP DHCP Server Address sub-options identify the DHCP servers from which an MTA is permitted to accept a DHCP OFFER. Sub-option 1 is the address of the TSP's primary DHCP server. Sub-option 2 is the address of the TSP's secondary DHCP server.
TSP DHCP服务器地址子选项标识允许MTA接受DHCP服务的DHCP服务器。子选项1是TSP的主DHCP服务器的地址。子选项2是TSP的辅助DHCP服务器的地址。
The sub-option length MUST be 4 and the sub-option MUST include the DHCP server's IPv4 address as follows:
子选项长度必须为4，并且子选项必须包括DHCP服务器的IPv4地址，如下所示：
Code Len Address
+-----+-----+-----+-----+-----+-----+
| 1/2 | 4 | a1 | a2 | a3 | a4 |
+-----+-----+-----+-----+-----+-----+
Code Len Address
+-----+-----+-----+-----+-----+-----+
| 1/2 | 4 | a1 | a2 | a3 | a4 |
+-----+-----+-----+-----+-----+-----+
This option contains the address of the TSP's Provisioning server. MTAs communicate with the Provisioning server at various stages in their provisioning process.
此选项包含TSP配置服务器的地址。MTA在其资源调配过程的不同阶段与资源调配服务器通信。
The address can be configured as either an IPv4 address or as an FQDN. The encoding of sub-option 3 will adhere to one of 2 formats.
该地址可以配置为IPv4地址或FQDN。子选项3的编码将遵循两种格式之一。
1. IPv4 address. The sub-option length MUST be 5. The length octet MUST be followed by a single octet that indicates the specific address type that follows. This type octet MUST be set to 1 to indicate an IPv4 address. The type octet MUST be followed by 4 octets of IPv4 address:
1. IPv4地址。子选项长度必须为5。长度八位字节后面必须有一个八位字节，表示后面的特定地址类型。此类型的八位字节必须设置为1以指示IPv4地址。类型八位字节后必须跟有IPv4地址的4个八位字节：
Code Len Type Address
+-----+-----+-----+-----+-----+-----+-----+
| 3 | 5 | 1 | a1 | a2 | a3 | a4 |
+-----+-----+-----+-----+-----+-----+-----+
Code Len Type Address
+-----+-----+-----+-----+-----+-----+-----+
| 3 | 5 | 1 | a1 | a2 | a3 | a4 |
+-----+-----+-----+-----+-----+-----+-----+
2. FQDN. The length octet MUST be followed by a single octet that indicates the specific address type that follows. This type octet MUST be set to 0 to indicate an FQDN. The type octet MUST be followed by the encoded FQDN:
2. FQDN。长度八位字节后面必须有一个八位字节，表示后面的特定地址类型。此类型的八位字节必须设置为0以指示FQDN。类型八位组后面必须跟编码的FQDN：
Code Len Type FQDN
+-----+-----+-----+-----+-----+ +-----+
| 3 | n+1 | 0 | f1 | f2 |...| fn |
+-----+-----+-----+-----+-----+ +-----+
Code Len Type FQDN
+-----+-----+-----+-----+-----+ +-----+
| 3 | n+1 | 0 | f1 | f2 |...| fn |
+-----+-----+-----+-----+-----+ +-----+
It is not anticipated that additional type codes, beyond IPv4 (1) and FQDN (0), will be required. Thus, IANA will not be required to maintain a registry of type codes.
除IPv4（1）和FQDN（0）之外，预计不需要其他类型代码。因此，IANA无需维护类型代码注册表。
This sub-option configures an MTA's Kerberos AS-REQ/AS-REP timeout, backoff, and retry mechanism.
此子选项配置MTA的Kerberos AS-REQ/AS-REP超时、退避和重试机制。
RFC 1510 [5] does not define a backoff/retry mechanism to be employed when an AS-REQ/AS-REP message exchange fails. This sub-option contains parameters required by the backoff/retry mechanism outlined in [8].
RFC 1510[5]未定义在AS-REQ/AS-REP消息交换失败时采用的退避/重试机制。此子选项包含[8]中概述的退避/重试机制所需的参数。
The encoding of this sub-option is depicted below:
此子选项的编码如下所示：
Code Len Nom Timeout Max Timeout Max Retries
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
| 4 |12 |n1 |n2 |n3 |n4 |m1 |m2 |m3 |m4 |r1 |r2 |r3 |r4 |
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
Code Len Nom Timeout Max Timeout Max Retries
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
| 4 |12 |n1 |n2 |n3 |n4 |m1 |m2 |m3 |m4 |r1 |r2 |r3 |r4 |
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
The length octet of this sub-option MUST contain the value 12.
此子选项的长度八位字节必须包含值12。
The length octet MUST be followed by 4 octets containing the AS-REQ/AS-REP nominal (initial) timeout value. This value is a 32 bit unsigned quantity in units of milliseconds.
长度八位字节后必须有4个八位字节，其中包含AS-REQ/AS-REP标称（初始）超时值。此值是以毫秒为单位的32位无符号量。
The next 4 octets MUST contain the AS-REQ/AS-REP maximum timeout value. This value is a 32 bit unsigned quantity in units of seconds.
接下来的4个八位字节必须包含AS-REQ/AS-REP最大超时值。此值是以秒为单位的32位无符号量。
The final 4 octets MUST contain the AS-REQ/AS-REP maximum retry count. This value is a 32 bit unsigned quantity.
最后4个八位字节必须包含AS-REQ/AS-REP最大重试次数。此值是32位无符号量。
This sub-option configures an MTA's Kerberos AP-REQ/AP-REP timeout, backoff, and retry mechanism.
此子选项配置MTA的Kerberos AP-REQ/AP-REP超时、退避和重试机制。
RFC 1510 [5] does not define a backoff/retry mechanism to be employed when an AP-REQ/AP-REP message exchange fails. This sub-option contains parameters required by the backoff/retry mechanism outlined in [8].
RFC 1510[5]未定义AP-REQ/AP-REP消息交换失败时采用的退避/重试机制。此子选项包含[8]中概述的退避/重试机制所需的参数。
The encoding of this sub-option is depicted below:
此子选项的编码如下所示：
Code Len Nom Timeout Max Timeout Max Retries
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
| 5 |12 |n1 |n2 |n3 |n4 |m1 |m2 |m3 |m4 |r1 |r2 |r3 |r4 |
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
Code Len Nom Timeout Max Timeout Max Retries
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
| 5 |12 |n1 |n2 |n3 |n4 |m1 |m2 |m3 |m4 |r1 |r2 |r3 |r4 |
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
The length octet of this sub-option MUST contain the value 12.
此子选项的长度八位字节必须包含值12。
The length octet MUST be followed by 4 octets containing the AP-REQ/AP-REP nominal (initial) timeout value. This value is a 32 bit unsigned quantity in units of seconds.
长度八位字节后必须有4个八位字节，其中包含AP-REQ/AP-REP标称（初始）超时值。此值是以秒为单位的32位无符号量。
The next 4 octets MUST contain the AP-REQ/AP-REP maximum timeout value. This value is a 32 bit unsigned quantity in units of seconds.
接下来的4个八位字节必须包含AP-REQ/AP-REP最大超时值。此值是以秒为单位的32位无符号量。
The final 4 octets MUST contain the AP-REQ/AP-REP maximum retry count. This value is a 32 bit unsigned quantity.
最后4个八位字节必须包含AP-REQ/AP-REP最大重试次数。此值是32位无符号量。
The PacketCable architecture requires an MTA to authenticate itself to the TSP's network via the Kerberos protocol. A Kerberos Realm name is required at the MTA to permit a DNS lookup for the address of the TSP's Kerberos Key Distribution Center (KDC) entity.
PacketCable体系结构需要MTA通过Kerberos协议向TSP的网络进行身份验证。MTA需要Kerberos领域名称，以允许DNS查找TSP的Kerberos密钥分发中心（KDC）实体的地址。
The Kerberos Realm name MUST be encoded per the domain style realm name described in RFC 1510 [5]. This realm name MUST be all capital letters and conform to the syntax described in RFC 1035 [3] section 3.1. The sub-option is encoded as follows:
Kerberos领域名称必须按照RFC 1510[5]中描述的域样式领域名称进行编码。此域名必须全部大写，并符合RFC 1035[3]第3.1节中描述的语法。子选项的编码如下所示：
Code Len Kerberos Realm Name
+-----+-----+-----+-----+ +-----+
| 6 | n | k1 | k2 |...| kn |
+-----+-----+-----+-----+ +-----+
Code Len Kerberos Realm Name
+-----+-----+-----+-----+ +-----+
| 6 | n | k1 | k2 |...| kn |
+-----+-----+-----+-----+ +-----+
This sub-option encodes a boolean value which indicates whether an MTA should or should not utilize a TGT (Ticket Granting Ticket) when obtaining a service ticket for one of the PacketCable application servers. The encoding is as follows:
此子选项编码一个布尔值，该值指示MTA在获取某个PacketCable应用程序服务器的服务票证时是否应使用TGT（票证授予票证）。编码如下：
Code Len Value
+-----+-----+-----+
| 7 | 1 | 1/0 |
+-----+-----+-----+
Code Len Value
+-----+-----+-----+
| 7 | 1 | 1/0 |
+-----+-----+-----+
The length MUST be 1. The last octet contains a Boolean value which MUST be either 0 or 1. A value of 1 MUST be interpreted as true. A value of 0 MUST be interpreted as false.
长度必须为1。最后一个八位字节包含一个布尔值，该值必须为0或1。值1必须解释为true。值0必须解释为false。
The provisioning timer defines the maximum time allowed for the MTA provisioning process to complete. If this timer expires before the MTA has completed the provisioning process, the MTA should reset the timer and re-start its provisioning process from the beginning.
设置计时器定义MTA设置过程完成所允许的最长时间。如果此计时器在MTA完成设置过程之前过期，MTA应重置计时器并从头开始重新启动其设置过程。
The sub-option length MUST be 1. The value octet specifies 0 to 255 minutes. A value of 0 means the timer MUST be disabled.
子选项长度必须为1。值八位字节指定0到255分钟。值为0表示必须禁用计时器。
Code Len Value
+-----+-----+---------+
| 8 | 1 | (0..255)|
+-----+-----+---------+
Code Len Value
+-----+-----+---------+
| 8 | 1 | (0..255)|
+-----+-----+---------+
6. Informational Description of CCC Option Usage.
6. CCC选项使用的信息说明。
Cablelabs client devices issue DHCP requests that include DHCP options 55 (Parameter Request List) and 60 (Vendor Class Identifier). Option 55 will request the CCC option from the DHCP server. Option 60 will indicate the specific Cablelabs client device type, thus directing the DHCP server to populate specific CCC sub-option content in its responses. The details of which CCC sub-options are populated for each specific client type are specified in various Cablelabs project specifications. For example, specific usage of the CCC option for the PacketCable project is described in [7].
Cablelabs客户端设备发出DHCP请求，其中包括DHCP选项55（参数请求列表）和60（供应商类别标识符）。选项55将从DHCP服务器请求CCC选项。选项60将指示特定的Cablelabs客户端设备类型，从而指示DHCP服务器在其响应中填充特定的CCC子选项内容。各种Cablelabs项目规范中规定了为每种特定客户类型填充CCC子选项的详细信息。例如，PacketCable项目中CCC选项的具体用法如[7]所述。
Note that client devices never populate the CCC option in their DHCP requests.
请注意，客户端设备从不在其DHCP请求中填充CCC选项。
IANA has assigned a value of 122 for the DHCP option code described in this document.
IANA已为本文档中描述的DHCP选项代码分配了值122。
The CableLabs Client Configuration option initially used the site-specific option value of 177 (0xB1). The use of the site-specific option is to be deprecated now that IANA has issued an official option number.
CableLabs客户端配置选项最初使用站点特定选项值177（0xB1）。由于IANA已经发布了正式的选项编号，因此不推荐使用特定于站点的选项。
IANA is requested to maintain a new number space of "CableLabs Client Configuration Sub-options", located in the BOOTP-DHCP Parameters Registry (http://www.iana.org/assignments/bootp-dhcp-parameters). The initial sub-option codes are described in section 4 of this document.
IANA需要在BOOTP-DHCP参数注册表中保留一个新的“CableLabs客户端配置子选项”编号空间(http://www.iana.org/assignments/bootp-dhcp-parameters). 本文件第4节描述了初始子选项代码。
IANA is requested to register codes for future CableLabs Client Configuration Sub-options via an "IETF Consensus" approval policy as described in RFC 2434 [2].
IANA被要求通过RFC 2434[2]中所述的“IETF共识”批准政策注册未来CableLabs客户端配置子选项的代码。
Potential exposures to attack in the DHCP protocol are discussed in section 7 of the DHCP protocol specification [6] and in Authentication for DHCP Messages [9].
DHCP协议规范[6]第7节和DHCP消息的身份验证[9]中讨论了DHCP协议中可能存在的攻击风险。
The CCC option can be used to misdirect network traffic by providing incorrect DHCP server addresses, incorrect provisioning server addresses, and incorrect Kerberos realm names to a Cablelabs client device. This misdirection can lead to several threat scenarios. A Denial of Service (DoS) attack can result from address information being simply invalid. A man-in-the-middle attack can be mounted by providing addresses to a potential snooper. A malicious TSP can steal customers from the customer selected TSP, by altering the Kerberos realm designation.
通过向Cablelabs客户端设备提供不正确的DHCP服务器地址、不正确的配置服务器地址和不正确的Kerberos领域名称，CCC选项可用于误导网络流量。这种误导可能导致多种威胁情景。地址信息完全无效可能导致拒绝服务（DoS）攻击。中间人攻击可以通过向潜在的窥探者提供地址来发动。恶意TSP可以通过更改Kerberos领域名称从客户选择的TSP中窃取客户。
These threats are mitigated by several factors.
这些威胁通过几个因素得以缓解。
Within the cable delivery architecture required by PacketCable, the DHCP client is connected to a network through a cable modem and the CMTS (head-end). The CMTS is explicitly configured with a set of DHCP servers to which DHCP requests are forwarded. Further, a correctly configured CMTS will only allow downstream traffic from specific IP addresses/ranges.
在PacketCable所需的电缆传输体系结构中，DHCP客户端通过电缆调制解调器和CMTS（前端）连接到网络。CMTS被显式配置为一组DHCP服务器，DHCP请求被转发到这些服务器。此外，正确配置的CMT将只允许来自特定IP地址/范围的下游流量。
Assuming that server addresses and Kerberos realm name were successfully spoofed to the point that a malicious client device was able to contact a KDC, the client device must still present valid certificates to the KDC before being service enabled. Given the computational overhead of the certificate validation process, this situation could present a DoS opportunity.
假设服务器地址和Kerberos领域名称被成功欺骗到恶意客户端设备能够联系KDC的程度，则在启用服务之前，客户端设备必须仍然向KDC提供有效证书。考虑到证书验证过程的计算开销，这种情况可能会带来拒绝服务的机会。
Finally, it is possible for a malicious (although certified) TSP to redirect a customer from the customer's selected TSP. It is assumed that all TSP's permitted onto an access providers network are trusted entities that will cooperate to insure peaceful coexistence. If a TSP is found to be redirecting customers, this should be handled as an administrative matter between the access provider and the TSP.
最后，恶意（尽管经过认证）TSP可能会从客户选择的TSP重定向客户。假设允许接入提供商网络的所有TSP都是可信实体，它们将合作确保和平共处。如果发现TSP正在重定向客户，则应将其作为访问提供商和TSP之间的管理事项处理。
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[1] Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[2] Narten, N. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.
[2] Narten，N.和H.Alvestrand，“在RFCs中编写IANA注意事项部分的指南”，BCP 26，RFC 2434，1998年10月。
[3] Mockapetris, P., "Domain Names - Implementation and Specification", STD 13, RFC 1035, November 1987.
[3] Mockapetris，P.，“域名-实现和规范”，STD 13，RFC 10351987年11月。
[4] Lemon, T. and S. Cheshire, "Encoding Long Options in the Dynamic Host Configuration Protocol (DHCPv4)", RFC 3396, November 2002.
[4] Lemon，T.和S.Cheshire，“动态主机配置协议（DHCPv4）中的长选项编码”，RFC 3396，2002年11月。
[5] Kohl, J. and C. Neuman, "The Kerberos Network Authentication Service (V5)", RFC 1510, September 1993.
[5] Kohl，J.和C.Neuman，“Kerberos网络身份验证服务（V5）”，RFC15101993年9月。
[6] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, March 1997.
[6] Droms，R.，“动态主机配置协议”，RFC 2131，1997年3月。
[7] "PacketCable MTA Device Provisioning Specification", PKT-SP-
PROV-I05-021127. http://www.packetcable.com/specifications.html
[7] "PacketCable MTA Device Provisioning Specification", PKT-SP-
PROV-I05-021127. http://www.packetcable.com/specifications.html
[8] "PacketCable Security Specification", PKT-SP-SEC-I07-021127,
http://www.packetcable.com/specifications.html
[8] "PacketCable Security Specification", PKT-SP-SEC-I07-021127,
http://www.packetcable.com/specifications.html
[9] Droms, R. and W. Arbaugh, "Authentication for DHCP Messages", RFC 3118, June 2001
[9] Droms，R.和W.Arbaugh，“DHCP消息的身份验证”，RFC31182001年6月
The authors would like to extend a heartfelt thanks to all those who contributed to the development of the PacketCable Provisioning specifications:
作者衷心感谢所有为制定PacketCable供应规范做出贡献的人：
Sumanth Channabasappa (Alopa Networks); Angela Lyda, Rick Morris, Rodney Osborne (Arris Interactive); Steven Bellovin and Chris Melle (AT&T); Eugene Nechamkin (Broadcom); John Berg, Maria Stachelek, Matt Osman (CableLabs); Klaus Hermanns, Azita Kia, Michael Thomas, Paul Duffy (Cisco); Deepak Patil (Com21); Jeff Ollis, Rick Vetter (General Instrument/Motorola); Roger Loots, David Walters (Lucent); Peter Bates (Telcordia); Patrick Meehan (Tellabs); Satish Kumar, Itay Sherman, Roy Spitzer (Telogy/TI), Aviv Goren (Terayon); Prithivraj Narayanan (Wipro).
Sumanth Channabasapa（Alopa网络）；安吉拉·利达、里克·莫里斯、罗德尼·奥斯本（阿里斯互动）；Steven Bellovin和Chris Melle（AT&T）；尤金·内查姆金（博通）；约翰·伯格、玛丽亚·斯塔切莱克、马特·奥斯曼（有线实验室）；克劳斯·赫尔曼斯、阿齐塔·基亚、迈克尔·托马斯、保罗·达菲（思科）；迪帕克帕蒂尔（Com21）；Jeff Ollis，Rick Vetter（通用仪器/摩托罗拉）；罗杰·罗伯茨，大卫·沃尔特斯（朗讯）；彼得·贝茨（特尔科迪亚）；帕特里克·米汉（特拉布）；萨蒂什·库马尔、伊泰·谢尔曼、罗伊·斯皮策（Telogy/TI）、阿维夫·戈伦（Terayon）；Prithivraj Narayanan（Wipro）。
The authors would also like to extend a special "thank you" to Rich Woundy (Comcast) for his thoughtful inputs.
作者还想向Rich Woundy（Comcast）表示特别的“感谢”，感谢他深思熟虑的投入。
Burcak Beser Juniper Networks 1194 North Matilda Avenue Sunnyvale, CA, 94089
Burcak Beser Juniper Networks加利福尼亚州桑尼维尔北马蒂尔达大道1194号，邮编94089
EMail: burcak@juniper.net
EMail: burcak@juniper.net
Paul Duffy Cisco Systems 300 Apollo Drive Chelmsford, MA, 01824
马萨诸塞州切姆斯福德阿波罗大道300号保罗·达菲思科系统公司，邮编01824
EMail: paduffy@cisco.com
EMail: paduffy@cisco.com
Copyright (C) The Internet Society (2003). All Rights Reserved.
版权所有（C）互联网协会（2003年）。版权所有。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
本文件及其译本可复制并提供给他人，对其进行评论或解释或协助其实施的衍生作品可全部或部分编制、复制、出版和分发，不受任何限制，前提是上述版权声明和本段包含在所有此类副本和衍生作品中。但是，不得以任何方式修改本文件本身，例如删除版权通知或对互联网协会或其他互联网组织的引用，除非出于制定互联网标准的需要，在这种情况下，必须遵循互联网标准过程中定义的版权程序，或根据需要将其翻译成英语以外的其他语言。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上述授予的有限许可是永久性的，互联网协会或其继承人或受让人不会撤销。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS 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.
本文件和其中包含的信息是按“原样”提供的，互联网协会和互联网工程任务组否认所有明示或暗示的保证，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
Acknowledgement
确认
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC编辑功能的资金目前由互联网协会提供。