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
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.
この文書では、CableLabsのアーキテクチャ内に配備様々なデバイスを構成するために使用される動的ホスト構成プロトコル（DHCP）オプションを定義します。 PacketCableのメディアターミナルアダプタ（MTA）：具体的には、ドキュメントはCableLabsのクライアントデバイスの1つのクラスを構成するために使用されるDHCPオプションの内容を説明します。将来の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
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].
この文書のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はあります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.
ケーブルテレビラボラトリーズ社（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）のサービス提供を提供します。ケーブルモデム（CM）とメディアターミナルアダプタ（MTA）：VoIPサービスは、次の2つの主要コンポーネントによって、顧客のサイトでサポートされています。 MTAは、共通電話と互換性のあるアナログ電話へのVoIPプロトコルを変換しながらCMは、様々なIP音声プロトコルに/からケーブルRF信号に変換します。
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| | |
| |-----------| |-------------| |
| |
|----------------------------------------------|
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は、IP設定を取得するためにDHCPプロトコルを利用しています。 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設定プロセスの特定のニーズに、新しいCableLabsのクライアントの構成（CCC）オプションはDHCPプロトコルのために必要とされる（[7]で説明）。 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のオプションは、最初のPacketCable 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 |
+------+--------+--------------+--------------+---+--------------+
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 |
+-------------------+--------+------------------------+
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 |
+---------+---------+--------------------------------------------+
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 |
+-----+-----+-----+-----+-----+-----+
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の符号化は、2つのフォーマットのいずれかに付着します。
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.サブオプションの長さでなければなりません。このタイプのオクテットは、IPv4アドレスを示すために1に設定しなければなりません。タイプオクテットは、IPv4アドレスの4つのオクテットが続かなければなりません。
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。長さオクテットは以下の特定のアドレスタイプを示す単一のオクテットが続かなければなりません。このタイプのオクテットは、FQDNを示すために0に設定しなければなりません。タイプオクテットは、符号化されたFQDNが続かなければなりません。
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のケルベロス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 |
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
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.
長さオクテットはAS-REQ / AS-REP公称（初期）タイムアウト値を含む4つのオクテットが続かなければなりません。この値はミリ秒単位で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 |
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
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.
長さオクテットは、AP-REQ / AP-REP公称（初期）タイムアウト値を含む4つのオクテットが続かなければなりません。この値は秒単位で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のアーキテクチャは、Kerberosプロトコルを介してTSPのネットワークに自分自身を認証するためにMTAが必要です。 Kerberosレルム名は、TSPのKerberosキー配布センター（KDC）エンティティのアドレスのためのDNSルックアップを可能にするために、MTAで必要とされます。
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:
ケルベロスレルム名は、RFC 1510 [5]に記載のドメインスタイルレルム名ごとに符号化されなければなりません。このレルム名はすべて大文字であることと、RFC 1035 [3]セクション3.1で説明した構文に従わなければなりません。次のようにサブオプションがエンコードされています。
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:
このサブオプションは、PacketCableのアプリケーションサーバのいずれかにサービスチケットを取得する際に、MTAが又はTGT（チケット認可チケット）を利用してはならないかどうかを示すブール値を符号化します。次のようにエンコーディングは次のとおりです。
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の値が真と解釈でなければなりませんブール値が含まれていなければなりません。 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.
値のオクテットは0〜255分を指定します。1.サブオプションの長さでなければなりません。 0の値は、タイマーを無効にする必要がありますを意味します。
Code Len Value
+-----+-----+---------+
| 8 | 1 | (0..255)|
+-----+-----+---------+
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オプション55（パラメータ要求リスト）と60（ベンダークラスID）を含み、問題のDHCP要求。オプション55は、DHCPサーバからCCCオプションを要求します。オプション60は、その応答内の特定のCCCのサブオプションの内容を移入するため、DHCPサーバを向ける、特定のCableLabsクライアントデバイスの種類を示します。 CCCサブオプションはそれぞれ特定のクライアントタイプのために移入されたの詳細については、各種のCableLabsプロジェクト仕様書で指定されています。例えば、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パラメータレジストリ（http://www.iana.org/assignments/bootp-dhcp-parameters）にある「CableLabsのクライアントの設定サブオプション」の新しい番号空間を維持するために要求されています。最初のサブオプションコードは、このドキュメントのセクション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は、[2] RFC 2434で説明したように「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]と認証でDHCPプロトコルの攻撃に対する潜在的エクスポージャーDHCPプロトコル仕様のセクション7に記載されている[9]。
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.
CCCオプションは、CableLabsのクライアントデバイスへの不正なDHCPサーバアドレス、間違ったプロビジョニングサーバーのアドレス、および間違ったKerberosレルム名を提供することにより、ネットワークトラフィックをmisdirectするために使用することができます。このミスディレクションは、いくつかの脅威のシナリオにつながることができます。サービス拒否（DoS）攻撃は、アドレス情報は、単に無効であることに起因することができます。 man-in-the-middle攻撃は、潜在的な盗聴者にアドレスを提供することで、マウントすることができます。悪意のある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サーバのセットで構成されています。さらに、正しく設定CMTSは、特定の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に有効な証明書を提示する必要があり、そのサーバーを仮定。証明書の検証プロセスの計算のオーバーヘッドを考えると、このような状況は、DoS攻撃の機会を提示することができます。
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]ブラドナーのは、S.は、BCP 14、RFC 2119、1997年3月の "RFCsにおける使用のためのレベルを示すために"。
[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 1035、1987年11月。
[4] Lemon, T. and S. Cheshire, "Encoding Long Options in the Dynamic Host Configuration Protocol (DHCPv4)", RFC 3396, November 2002.
[4]レモン、T.とS.チェシャー、 "動的ホスト構成プロトコル（DHCPv4の）でエンコーディング長いオプション"、RFC 3396、2002年11月。
[5] Kohl, J. and C. Neuman, "The Kerberos Network Authentication Service (V5)", RFC 1510, September 1993.
[5]コールズ、J.及びC.ノイマン、 "ケルベロスネットワーク認証サービス（V5）"、RFC 1510、1993年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デバイスプロビジョニング仕様"、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のセキュリティ仕様"、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メッセージの認証"、RFC 3118、2001年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).
スーマンスChannabasappa（Alopaネットワーク）。アンジェラリダ、リック・モリス、ロドニー・オズボーン（ARRISインタラクティブ）。スティーブンBellovin氏とクリス・メレ（AT＆T）。ユージンNechamkin（ブロード）。ジョン・バーグ、マリアStachelek、マット・オスマン（CableLabsに）;クラウスHermanns、Azita起亜、マイケル・トーマス、ポール・ダフィー（シスコ）。ディーパックパティル（COM21）。ジェフOllis、リック・フェッター（一般的なインストゥルメント/モトローラ）。ロジャーLoots、デビッド・ウォルターズ（ルーセント）。ピーター・ベイツ（Telcordiaの）;パトリック・ミーハン（テラブス）。サティシュ・クマール、イタイシャーマン、ロイスピッツァー（Telogy / TI）、テルアビブGoren（Terayon）。 Prithivrajナラヤナン（ウィプロ）。
The authors would also like to extend a special "thank you" to Rich Woundy (Comcast) for his thoughtful inputs.
著者らはまた、彼の思いやりの入力のためのリッチWoundy（コムキャスト）に「ありがとう」特別を拡張したいと思います。
Burcak Beser Juniper Networks 1194 North Matilda Avenue Sunnyvale, CA, 94089
Burcak Beserジュニパーネットワークスの1194北マチルダアベニューサニーベール、CA、94089
EMail: burcak@juniper.net
メールアドレス：burcak@juniper.net
Paul Duffy Cisco Systems 300 Apollo Drive Chelmsford, MA, 01824
ポール・ダフィーシスコシステムズ300アポロドライブチェルムズフォード、MA、01824
EMail: paduffy@cisco.com
メールアドレス：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 Editor機能のための基金は現在、インターネット協会によって提供されます。