RFC3495 日本語訳
3495 Dynamic Host Configuration Protocol (DHCP) Option for CableLabsClient Configuration. B. Beser, P. Duffy, Ed.. March 2003. (Format: TXT=26817 bytes) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
英語原文
Network Working Group B. Beser
Request for Comments: 3495 Juniper Networks
Category: Standards Track P. Duffy, Ed.
Cisco Systems
March 2003
Beserがコメントのために要求するワーキンググループB.をネットワークでつないでください: 3495年の杜松はカテゴリをネットワークでつなぎます: エド標準化過程P.ダフィー、シスコシステムズ2003年3月
Dynamic Host Configuration Protocol (DHCP) Option
for CableLabs Client Configuration
CableLabsクライアント構成のためのDynamic Host Configuration Protocol(DHCP)オプション
Status of this Memo
この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.
このドキュメントは、インターネットコミュニティにインターネット標準化過程プロトコルを指定して、改良のために議論と提案を要求します。 このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」(STD1)の現行版を参照してください。 このメモの分配は無制限です。
Copyright Notice
版権情報
Copyright (C) The Internet Society (2003). All Rights Reserved.
Copyright(C)インターネット協会(2003)。 All rights reserved。
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アーキテクチャの中で配布された様々なデバイスを構成するのに使用されるDynamic Host Configuration Protocol(DHCP)オプションを定義します。 明確に、ドキュメントは1つのクラスのCableLabsクライアントデバイスを構成するのに使用されるDHCPオプション内容について説明します: PacketCableメディアティーエー(MTA)。 将来のCableLabsクライアントデバイスが開発されているのに従って、このドキュメントの中に定義されたオプション内容は広げられるでしょう。
Beser & Duffy Standards Track [Page 1] RFC 3495 DHCP Option for CableLabs Clients March 2003
BeserとダフィーStandardsは2003年のクライアント行進のときにCableLabsのためにRFC3495DHCPオプションを追跡します[1ページ]。
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. このドキュメントで中古のコンベンション… 2 2. 用語… 2 3. 序論… 3 4. CableLabsクライアント設定オプション形式… 4 5. CableLabsクライアント設定オプション: サブオプション定義5 5.1。 ティースプーンフルのDHCPサーバアドレスサブオプション… 5 5.2. ティースプーンフルはサーバアドレスサブオプションに食糧を供給しています… 6 5.3. レップとしてのREQとしてのティースプーンフルの/Backoffと再試行… 6 5.4. ティースプーンフルのAP-REQ/AP-レップBackoffと再試行… 7 5.5. ティースプーンフルのケルベロス分野名前サブオプション… 8 5.6. サーバ利用サブオプションを承諾するティースプーンフルのチケット… 8 5.7. ティースプーンフルはタイマサブオプションに食糧を供給しています… 8 6. CCCオプション用法の情報の記述… 9 7. IANA問題… 9 8. レガシーは情報を使用します… 9 9. 追加サブオプションを加えるための手順… 9 10. セキュリティ問題… 10 11. 参照… 10 11.1. 標準の参照… 10 11.2. 有益な参照… 11 12. 承認… 11 13. 作者のアドレス… 12 14. 完全な著作権宣言文… 13
1. Conventions used in this document
1. 本書では使用されるコンベンション
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"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTはBCP14(RFC2119[1])で説明されるように本書では解釈されることであるべきです。
2. Terminology
2. 用語
Definitions of terms used throughout this document:
このドキュメント中で使用される用語の定義:
* "Telephony Service Provider" or "TSP"
* 「電話サービスプロバイダー」か「ティースプーンフル」
The business entity from which a subscriber receives telephony service.
加入者が電話サービスを受ける企業体。
See RFC 2131 [6] for additional DHCP terminology.
追加DHCP用語のためのRFC2131[6]を見てください。
Beser & Duffy Standards Track [Page 2] RFC 3495 DHCP Option for CableLabs Clients March 2003
BeserとダフィーStandardsは2003年のクライアント行進のときにCableLabsのためにRFC3495DHCPオプションを追跡します[2ページ]。
3. Introduction
3. 序論
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.
ケーブルTelevision研究所Inc.(CableLabs)は新しくて現れている広帯域サービスアーキテクチャのデザインと仕様でケーブルテレビ産業に役立つ非営利の研究開発共同体です。 いくつかのCableLabsイニシアチブが特定のDHCP構成必要条件を持っているDHCPクライアントを定義します。 そのようなイニシアチブの1つは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.
インターネットを利用するマルチメディアがケーブルベースのパケット網の上のサービスであるとarchitectingして、資格を与えて、サポートするのを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.
PacketCable1.0はボイス・オーバー IP(VoIP)サービス配送を提供します。 VoIPサービスは顧客サイトで2つの主要なコンポーネントで後押しされています: ケーブルモデム(CM)とメディアティーエー(MTA)。 CMは様々なIP声のプロトコルからの/にケーブルRF信号を変換します、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は一緒にか別々にパッケージされるかもしれません。 一緒にパッケージされるなら、ユニットはEmbedded-MTA(EMTA--図1では、表現される)と呼ばれます。 別々にパッケージされるなら、MTAはStandalone MTA(SMTA)と呼ばれます。
|----------------------------------------------|
| |
| |-----------| |-------------| |
| | | | | |
Telephony | | Media | internal | Cable | | RF Link
----------|---| Terminal |===========| Modem |----|-------
Link | | Adapter | connection| | |
| |-----------| |-------------| |
| |
|----------------------------------------------|
|----------------------------------------------| | | | |-----------| |-------------| | | | | | | | 電話| | メディア| 内部| ケーブル| | rfリンク----------|---| 端末|===========| モデム|----|------- リンク| | アダプター| 接続| | | | |-----------| |-------------| | | | |----------------------------------------------|
Figure 1. PacketCable 1.0 Embedded-MTA
図1。 PacketCable1.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は、Data Access Providerの(DAP)のDHCPサーバによってコミュニケートして、構成されています。 同様に、MTAはTelephony Service Providerの(TSP)のDHCPサーバによってコミュニケートして、構成されています。
Beser & Duffy Standards Track [Page 3] RFC 3495 DHCP Option for CableLabs Clients March 2003
BeserとダフィーStandardsは2003年のクライアント行進のときにCableLabsのためにRFC3495DHCPオプションを追跡します[3ページ]。
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])で説明されていて、新しいCableLabs Client Configuration(CCC)オプションがDHCPプロトコルに必要です。 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であることを意味するというわけではありません。
4. CableLabs Client Configuration Option Format
4. CableLabsクライアント設定オプション形式
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 | 長さ| サブオプション1| サブオプション2|...| サブオプション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 |
+-------------------+--------+------------------------+
+-------------------+--------+------------------------+ | サブオプションコード| 長さ| サブオプション情報| +-------------------+--------+------------------------+
Beser & Duffy Standards Track [Page 4] RFC 3495 DHCP Option for CableLabs Clients March 2003
BeserとダフィーStandardsは2003年のクライアント行進のときにCableLabsのためにRFC3495DHCPオプションを追跡します[4ページ]。
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 |
+---------+---------+--------------------------------------------+
+---------+---------+--------------------------------------------+ | サブ| 発信します。| 記述| | オプション| | | | コード| | | +===================+============================================+ | 1 | CM| ティースプーンフルのプライマリDHCPサーバアドレス| +---------+---------+--------------------------------------------+ | 2 | CM| ティースプーンフルのセカンダリDHCPサーバアドレス| +---------+---------+--------------------------------------------+ | 3 | MTA| ティースプーンフルはサーバアドレスに食糧を供給します。| +---------+---------+--------------------------------------------+ | 4 | MTA| レップとしてのREQとしてのティースプーンフルの/Backoffと再試行| +---------+---------+--------------------------------------------+ | 5 | MTA| ティースプーンフルのAP-REQ/AP-レップBackoffと再試行| +---------+---------+--------------------------------------------+ | 6 | MTA| ティースプーンフルのケルベロス分野名| +---------+---------+--------------------------------------------+ | 7 | MTA| サーバ利用を承諾するティースプーンフルのチケット| +---------+---------+--------------------------------------------+ | 8 | MTA| ティースプーンフルはタイマ値に食糧を供給します。| +---------+---------+--------------------------------------------+ | 9 - 255 | | 今後の拡大のために、予約されます。| +---------+---------+--------------------------------------------+
5. CableLabs Client Configuration Option: Sub-Option Definitions
5. CableLabsクライアント設定オプション: サブオプション定義
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.
- 完全に、RFC1035[3]部3.1単位でQualified Domain Names(FQDNs)をコード化しなければなりません。 終わっている0が必要であることに注意してください。 また、RFC1035[3]部4.1の.4で説明される圧縮を適用してはいけないことに注意してください。
- IPv4 addresses MUST be encoded as 4 binary octets in network
byte-order (high order byte first).
- ネットワークバイトオーダーにおける4つの2進の八重奏としてIPv4アドレスをコード化しなければなりません(高値は最初に、バイトを命令します)。
- All multi-octet quantities MUST be encoded per network byte-
ordering.
- ネットワークバイト注文単位ですべてのマルチ八重奏量をコード化しなければなりません。
5.1. TSP's DHCP Server Address Sub-Options
5.1. ティースプーンフルのDHCPサーバアドレスサブオプション
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 Server AddressサブオプションはMTAがDHCP OFFERを受け入れることが許可されるDHCPサーバを特定します。 サブオプション1はTSPのプライマリDHCPサーバのアドレスです。サブオプション2はTSPのセカンダリDHCPサーバのアドレスです。
Beser & Duffy Standards Track [Page 5] RFC 3495 DHCP Option for CableLabs Clients March 2003
BeserとダフィーStandardsは2003年のクライアント行進のときにCableLabsのためにRFC3495DHCPオプションを追跡します[5ページ]。
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 |
+-----+-----+-----+-----+-----+-----+
コードレンアドレス+-----+-----+-----+-----+-----+-----+ | 1/2 | 4 | a1| a2| a3| a4| +-----+-----+-----+-----+-----+-----+
5.2. TSP's Provisioning Server Address Sub-Option
5.2. ティースプーンフルはサーバアドレスサブオプションに食糧を供給します。
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のProvisioningサーバのアドレスを含んでいます。プロセスに食糧を供給する際にMTAsは様々な段階のProvisioningサーバとコミュニケートします。
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つを固く守るでしょう。
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 |
+-----+-----+-----+-----+-----+-----+-----+
レンTypeが+であると扱うコード-----+-----+-----+-----+-----+-----+-----+ | 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 |
+-----+-----+-----+-----+-----+ +-----+
コードレンタイプ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はタイプコードの登録を維持する必要はないでしょう。
5.3. TSP's AS-REQ/AS-REP Backoff and Retry
5.3. レップとしてのREQとしてのティースプーンフルの/Backoffと再試行
This sub-option configures an MTA's Kerberos AS-REQ/AS-REP timeout, backoff, and retry mechanism.
このサブオプションはMTAのケルベロスAS-REQ/AS-REPタイムアウト、backoff、および再試行メカニズムを構成します。
Beser & Duffy Standards Track [Page 6] RFC 3495 DHCP Option for CableLabs Clients March 2003
BeserとダフィーStandardsは2003年のクライアント行進のときにCableLabsのためにRFC3495DHCPオプションを追跡します[6ページ]。
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].
AS-REQ/AS-REP交換処理が失敗する場合、RFC1510[5]は、使われるためにbackoff/再試行メカニズムを定義しません。 このサブオプションは[8]に概説されたbackoff/再試行メカニズムによって必要とされたパラメタを含んでいます。
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 |
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
コードレンNomタイムアウトマックスのタイムアウトマックスの再試行+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ | 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ビットの未署名の量です。
5.4. TSP's AP-REQ/AP-REP Backoff and Retry
5.4. ティースプーンフルのAP-REQ/AP-レップBackoffと再試行
This sub-option configures an MTA's Kerberos AP-REQ/AP-REP timeout, backoff, and retry mechanism.
このサブオプションはMTAのケルベロスAP-REQ/AP-REPタイムアウト、backoff、および再試行メカニズムを構成します。
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].
AP-REQ/AP-REP交換処理が失敗する場合、RFC1510[5]は、使われるためにbackoff/再試行メカニズムを定義しません。 このサブオプションは[8]に概説されたbackoff/再試行メカニズムによって必要とされたパラメタを含んでいます。
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 |
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
コードレンNomタイムアウトマックスのタイムアウトマックスの再試行+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ | 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ビットの未署名の量です。
Beser & Duffy Standards Track [Page 7] RFC 3495 DHCP Option for CableLabs Clients March 2003
BeserとダフィーStandardsは2003年のクライアント行進のときにCableLabsのためにRFC3495DHCPオプションを追跡します[7ページ]。
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ビットの未署名の量です。
5.5. TSP's Kerberos Realm Name Sub-Option
5.5. ティースプーンフルのケルベロス分野名前サブオプション
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がケルベロスプロトコルでTSPのネットワークにそれ自体を認証するのを必要とします。 ケルベロスRealm名が、TSPのケルベロスKey Distributionセンター(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:
RFC1510[5]で説明されたドメインスタイル分野名単位でケルベロスRealm名をコード化しなければなりません。 この分野名は、大文字であり、RFC1035[3]部3.1で説明された構文に従わなければなりません。 サブオプションは以下の通りコード化されます:
Code Len Kerberos Realm Name
+-----+-----+-----+-----+ +-----+
| 6 | n | k1 | k2 |...| kn |
+-----+-----+-----+-----+ +-----+
コードレンケルベロス分野名+-----+-----+-----+-----+ +-----+ | 6 | n| k1| k2|...| kn| +-----+-----+-----+-----+ +-----+
5.6. TSP's Ticket Granting Server Utilization Sub-Option
5.6. サーバ利用サブオプションを承諾するティースプーンフルのチケット
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(チケットGranting Ticket)を利用するはずがないかどうかを示すブール値をコード化します。 コード化は以下の通りです:
Code Len Value
+-----+-----+-----+
| 7 | 1 | 1/0 |
+-----+-----+-----+
コードレン価値+-----+-----+-----+ | 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の値を解釈しなければなりません。
5.7. TSP's Provisioning Timer Sub-Option
5.7. ティースプーンフルはタイマサブオプションに食糧を供給します。
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は、始めからタイマをリセットして、プロセスに食糧を供給するのを再開するはずです。
Beser & Duffy Standards Track [Page 8] RFC 3495 DHCP Option for CableLabs Clients March 2003
BeserとダフィーStandardsは2003年のクライアント行進のときにCableLabsのためにRFC3495DHCPオプションを追跡します[8ページ]。
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)|
+-----+-----+---------+
コードレン価値+-----+-----+---------+ | 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(パラメタRequest List)と60(ベンダーClass Identifier)を含んでいる要求をDHCPに出します。 オプション55はDHCPサーバからCCCオプションを要求するでしょう。オプション60は特定のCablelabsクライアント装置タイプを示すでしょう、その結果、応答における特定のCCCサブオプション内容に居住するようDHCPサーバに指示します。 それぞれの特定のクライアントタイプのためにCCCサブオプションに居住する詳細は様々なCablelabsプロジェクト仕様で指定されます。 例えば、PacketCableプロジェクトのためのCCCオプションの特定の用法は[7]で説明されます。
Note that client devices never populate the CCC option in their DHCP requests.
クライアントデバイスが彼らのDHCP要求におけるCCCオプションに決して居住しないことに注意してください。
7. IANA Considerations
7. IANA問題
IANA has assigned a value of 122 for the DHCP option code described in this document.
IANAは本書では説明されたDHCPオプションコードのために122の値を割り当てました。
8. Legacy Use Information
8. レガシーは情報を使用します。
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 Client Configurationオプションは初めは、177(0xB1)のサイトの特定のオプション価値を使用しました。 サイト特有のオプションの使用はIANAが公式のオプション番号を発行したので推奨しないことです。
9. Procedure for Adding Additional Sub-options
9. 追加サブオプションを加えるための手順
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 Parameters Registry( 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が今後のCableLabs Client Configuration Sub-オプションのためにRFC2434[2]で説明されるように「IETFコンセンサス」承認の方針でコードを示すよう要求されています。
Beser & Duffy Standards Track [Page 9] RFC 3495 DHCP Option for CableLabs Clients March 2003
BeserとダフィーStandardsは2003年のクライアント行進のときにCableLabsのためにRFC3495DHCPオプションを追跡します[9ページ]。
10. Security Considerations
10. セキュリティ問題
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 Messages[9]のためのAuthenticationで論じられます。
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.
不正確なDHCPサーバアドレスを提供することによってネットワークトラフィックに誤った指導するのにCCCオプションを使用できると不正確な食糧を供給するサーバは扱って、不正確なケルベロス分野は、Cablelabsクライアントデバイスと命名します。 この誤まった指示はいくつかの脅威シナリオにつながることができます。 サービス妨害(DoS)攻撃は単に無効のアドレス情報から生じることができます。 潜在的詮索好きにアドレスを提供することによって、介入者攻撃を仕掛けることができます。 悪意があるTSPは、顧客の選択された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要求が転送される1セットの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.
サーバアドレスとケルベロス分野名が首尾よく悪意があるクライアントデバイスが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の間の管理件として扱われるべきです。
11. References
11. 参照
11.1. Normative References
11.1. 引用規格
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[1] ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、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問題部に書くためのガイドライン」BCP26、RFC2434(1998年10月)。
Beser & Duffy Standards Track [Page 10] RFC 3495 DHCP Option for CableLabs Clients March 2003
BeserとダフィーStandardsは2003年のクライアント行進のときにCableLabsのためにRFC3495DHCPオプションを追跡します[10ページ]。
[3] Mockapetris, P., "Domain Names - Implementation and
Specification", STD 13, RFC 1035, November 1987.
[3]Mockapetris、P.、「ドメイン名--、実装と仕様、」、STD13、RFC1035、11月1987日
[4] Lemon, T. and S. Cheshire, "Encoding Long Options in the Dynamic
Host Configuration Protocol (DHCPv4)", RFC 3396, November 2002.
[4] レモンとT.とS.チェーシャー州、「Dynamic Host Configuration Protocol(DHCPv4)における長いオプションをコード化します」、RFC3396、2002年11月。
[5] Kohl, J. and C. Neuman, "The Kerberos Network Authentication
Service (V5)", RFC 1510, September 1993.
[5] コールとJ.とC.ヌーマン、「ケルベロスネットワーク認証サービス(V5)」、RFC1510 1993年9月。
[6] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, March
1997.
[6]Droms、R.、「ダイナミックなホスト構成プロトコル」、RFC2131、1997年3月。
11.2. Informative References
11.2. 有益な参照
[7] "PacketCable MTA Device Provisioning Specification", PKT-SP-
PROV-I05-021127. http://www.packetcable.com/specifications.html
[7] PKT-SP- PROV-I05-021127「仕様に食糧を供給するPacketCable MTAデバイス」、 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メッセージのための認証」、RFC3118、2001年6月
12. Acknowledgments
12. 承認
The authors would like to extend a heartfelt thanks to all those who contributed to the development of the PacketCable Provisioning specifications:
作者はPacketCable Provisioning仕様の開発に貢献したすべての人に心からの感謝を表したがっています:
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ネットワーク)。 アンジェラ・リダ、リックモリス、ロドニー・オズボーン(アリスInteractive)。 スティーブンBellovinとクリス・メレ(AT&T)。 ユージンNechamkin(Broadcom)。 ジョン・バーグ、マリアStachelek、マットオスマン朝(CableLabs)。 クラウスHermanns、Azita Kia、マイケル・トーマス、ポール・ダフィー(シスコ)。 Deepakパティル(Com21)。 ジェフ・オリス、リック・フェッター(ゼネラルインスツルメント/モトローラ)。 デヴィッド・ウォルターズ、ロジャーは略奪します(透明な)。 ピーターは(Telcordia)を和らげます。 パトリック・ミーハン(Tellabs)。 サティシュ・クマー、Itayシャーマン、ロイ・スピッツァー(Telogy/TI)、Avivゴーレン(Terayon)。 Prithivrajナラヤナン(ウィプロ)。
The authors would also like to extend a special "thank you" to Rich Woundy (Comcast) for his thoughtful inputs.
また、作者は彼の考え深い入力のためにリッシュWoundy(コムキャスト)を「ありがとうございます」という特別番組を広げたがっています。
Beser & Duffy Standards Track [Page 11] RFC 3495 DHCP Option for CableLabs Clients March 2003
BeserとダフィーStandardsは2003年のクライアント行進のときにCableLabsのためにRFC3495DHCPオプションを追跡します[11ページ]。
13. Authors' Addresses
13. 作者のアドレス
Burcak Beser Juniper Networks 1194 North Matilda Avenue Sunnyvale, CA, 94089
Burcak Beser杜松は1194の北のマチルダ・Avenueサニーベル、カリフォルニア 94089をネットワークでつなぎます。
EMail: burcak@juniper.net
メール: burcak@juniper.net
Paul Duffy Cisco Systems 300 Apollo Drive Chelmsford, MA, 01824
Driveチェルムズフォード、ポールダフィーシスコシステムズ300アポロMA 01824
EMail: paduffy@cisco.com
メール: paduffy@cisco.com
Beser & Duffy Standards Track [Page 12] RFC 3495 DHCP Option for CableLabs Clients March 2003
BeserとダフィーStandardsは2003年のクライアント行進のときにCableLabsのためにRFC3495DHCPオプションを追跡します[12ページ]。
14. Full Copyright Statement
14. 完全な著作権宣言文
Copyright (C) The Internet Society (2003). All Rights Reserved.
Copyright(C)インターネット協会(2003)。 All rights reserved。
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.
それに関するこのドキュメントと翻訳は、コピーして、それが批評するか、またはそうでなければわかる他のもの、および派生している作品に提供するか、または準備されているかもしれなくて、コピーされて、発行されて、全体か一部広げられた実現を助けるかもしれません、どんな種類の制限なしでも、上の版権情報とこのパラグラフがそのようなすべてのコピーと派生している作品の上に含まれていれば。 しかしながら、このドキュメント自体は何らかの方法で変更されないかもしれません、インターネット協会か他のインターネット組織の版権情報か参照を取り除くのなどように、それを英語以外の言語に翻訳するのが著作権のための手順がインターネットStandardsの過程で定義したどのケースに従わなければならないか、必要に応じてさもなければ、インターネット標準を開発する目的に必要であるのを除いて。
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機能のための基金は現在、インターネット協会によって提供されます。
Beser & Duffy Standards Track [Page 13]
Beserとダフィー標準化過程[13ページ]
一覧
スポンサーリンク
