[要約] RFC 3495は、ケーブルラボのクライアント設定のためのDHCPオプションに関する規格です。このRFCの目的は、ケーブルモデムのクライアント設定を効率的に行うための標準化を提供することです。
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.
Copyright（c）The Internet Society（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）オプションを定義します。具体的には、ドキュメントでは、1つのクラスのCableLabsクライアントデバイスを構成するために使用される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].
「必須」、「そうしない」、「必須」、「shall」、「shall "、" ingle "、" should "、" not "、" becommended "、" bay "、および「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.
Cable Television Laboratories、Inc。（CableLabs）は、新しいブロードバンドサービスアーキテクチャの設計と仕様を通じてケーブルテレビ業界にサービスを提供する非営利の研究開発コンソーシアムです。いくつかのCableLabsイニシアチブは、特定のDHCP構成要件を持つDHCPクライアントを定義しています。そのようなイニシアチブの1つは、パケット可能なプロジェクトです。
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は、Voice Over IP（VoIP）サービス提供を提供します。VoIPサービスは、ケーブルモデム（CM）とメディアターミナルアダプター（MTA）の2つの重要なコンポーネントで顧客サイトでサポートされています。CMは、ケーブルRF信号をさまざまな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と呼ばれます（EMTA-図1に示す）。個別にパッケージ化されている場合、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 Embedded-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.
パケット可能なアーキテクチャでは、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オプションは最初に展開され、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）を含むタグオクテットから始まります。オクテットの長さはタグオクテットに続きます。Octetの長さの値には、それ自体やタグOctetは含まれません。長さのオクテットの後には、サブオプション含有量の「長さ」のオクテット（サブオプションカウントではなく、全長）が続きます。オプションレイアウトを以下に示します。
+------+--------+--------------+--------------+---+--------------+
| 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:
サブオプションは、サブオプションコードを含むタグオクテットから始まります。オクテットの長さはタグオクテットに続きます。Octetの長さの値には、それ自体やタグOctetは含まれません。長さのオクテットの後に、サブオプション情報の「長さ」のオクテットが続きます。サブオプションレイアウトを以下に示します。
+-------------------+--------+------------------------+
| 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.
- 完全資格のドメイン名（FQDNS）は、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に設定する必要があります。タイプのオクテットには、4オクテットのIPv4アドレスが続く必要があります。
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の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 |
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
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が必要です。TSPのKerberos Key Distribution Center（KDC）エンティティのアドレスのDNS検索を許可するには、MTAでKerberos Realmの名前が必要です。
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 Realmの名前は、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アプリケーションサーバーの1つのサービスチケットを取得する際に、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.
サブオプションの長さは1でなければなりません。値の値は0〜255分を指定します。0の値は、タイマーを無効にする必要があることを意味します。
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オプション55（パラメーター要求リスト）および60（ベンダークラス識別子）を含むDHCP要求を発行します。オプション55は、DHCPサーバーからCCCオプションを要求します。オプション60は、特定のCableLabsクライアントデバイスタイプを示しているため、DHCPサーバーに特定のCCCサブオプションコンテンツをその応答に設定するよう指示します。特定のクライアントタイプごとに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は、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プロトコルでの攻撃への潜在的な暴露については、DHCPプロトコル仕様[6]のセクション7およびDHCPメッセージの認証[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オプションは、誤ったDHCPサーバーアドレス、誤ったプロビジョニングサーバーアドレス、および誤ったKerberos Realm NameをCableLabsクライアントデバイスに提供することにより、ネットワークトラフィックを誤って指示するために使用できます。この誤解は、いくつかの脅威シナリオにつながる可能性があります。サービス拒否（DOS）攻撃は、アドレス情報が単純に無効であることから生じる可能性があります。潜在的なスヌーパーに住所を提供することにより、中間の攻撃を取り付けることができます。悪意のあるTSPは、Kerberos Realmの指定を変更することにより、顧客が選択した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クライアントはケーブルモデムとCMT（ヘッドエンド）を介してネットワークに接続されています。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 Realm Nameが悪意のあるクライアントデバイスが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から顧客をリダイレクトすることが可能です。Accessプロバイダーネットワークに許可されているすべての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 1035、1987年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、「The Kerberos Network Authentication Service（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/spifications.html
[9] Droms, R. and W. Arbaugh, "Authentication for DHCP Messages", RFC 3118, June 2001
[9] Droms、R。and 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:
著者は、パケット可能なプロビジョニング仕様の開発に貢献したすべての人に心から拡張したいと考えています。
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 Channabasappa（Alopa Networks）;アンジェラ・リダ、リック・モリス、ロドニー・オズボーン（Arris Interactive）;スティーブンベロビンとクリスメルル（AT＆T）;Eugene Nechamkin（Broadcom）;ジョン・バーグ、マリア・スタチェレク、マット・オスマン（ケイブルラブ）;Klaus Hermanns、Azita Kia、Michael Thomas、Paul Duffy（Cisco）;Deepak Patil（COM21）;ジェフ・オリス、リック・ベッター（一般的な楽器/モトローラ）;ロジャー・ルーツ、デビッド・ウォルターズ（ルーセント）;ピーターベイツ（テルコルディア）;パトリック・ミーハン（テラブス）;Satish Kumar、Itay Sherman、Roy Spitzer（Telogy/Ti）、Aviv Goren（Terayon）;Prithivraj Narayanan（Wipro）。
The authors would also like to extend a special "thank you" to Rich Woundy (Comcast) for his thoughtful inputs.
著者はまた、彼の思慮深い入力のために、特別な「ありがとう」を豊かな傷（Comcast）に拡張したいと考えています。
Burcak Beser Juniper Networks 1194 North Matilda Avenue Sunnyvale, CA, 94089
Burcak Beser Juniper Networks 1194 North Matilda Avenue Sunnyvale、CA、94089
EMail: burcak@juniper.net
Paul Duffy Cisco Systems 300 Apollo Drive Chelmsford, MA, 01824
Paul Duffy Cisco Systems 300 Apollo Drive Chelmsford、MA、01824
EMail: paduffy@cisco.com
Copyright (C) The Internet Society (2003). All Rights Reserved.
Copyright（c）The Internet Society（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エディター機能の資金は現在、インターネット協会によって提供されています。