RFC2939 日本語訳
2939 Procedures and IANA Guidelines for Definition of New DHCP Optionsand Message Types. R. Droms. September 2000. (Format: TXT=13631 bytes) (Obsoletes RFC2489) (Also BCP0043) (Status: BEST CURRENT PRACTICE)
プログラムでの自動翻訳です。
英語原文
Network Working Group R. Droms Request for Comments: 2939 Bucknell University BCP: 43 September 2000 Obsoletes: 2489 Category: Best Current Practice
Dromsがコメントのために要求するワーキンググループR.をネットワークでつないでください: 2939Bucknell大学BCP: 43 2000年9月は以下を時代遅れにします。 2489年のカテゴリ: 最も良い現在の習慣
Procedures and IANA Guidelines for Definition of New DHCP Options and Message Types
新しいDHCPオプションとメッセージタイプの定義のための手順とIANAガイドライン
Status of this Memo
このMemoの状態
This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. Distribution of this memo is unlimited.
このドキュメントはインターネット共同体、要求議論、および提案のためのインターネットBest Current Practicesを改良に指定します。 このメモの分配は無制限です。
Copyright Notice
版権情報
Copyright (C) The Internet Society (2000). All Rights Reserved.
Copyright(C)インターネット協会(2000)。 All rights reserved。
Abstract
要約
The Dynamic Host Configuration Protocol (DHCP) provides a framework for passing configuration information to hosts on a Transmission Control Protocol/Internet Protocol (TCP/IP) network. Configuration parameters and other control information are carried in tagged data items that are stored in the 'options' field of the DHCP message. The data items themselves are also called "options".
Dynamic Host Configuration Protocol(DHCP)は伝送制御プロトコル/インターネット・プロトコル(TCP/IP)ネットワークで設定情報をホストに渡すのにフレームワークを提供します。 設定パラメータと他の制御情報はDHCPメッセージの'オプション'分野に保存されるタグ付けをされたデータ項目で運ばれます。 また、データ項目自体は「オプション」と呼ばれます。
DHCP protocol messages are identified by the 'DHCP Message Type' option (option code 51). Each message type is defined by the data value carried in the 'DHCP Message Type' option.
'DHCP Message Type'オプション(オプションコード51)でDHCPプロトコルメッセージは特定されます。 それぞれのメッセージタイプは'DHCP Message Type'オプションで運ばれたデータ値によって定義されます。
New DHCP options and message types may be defined after the publication of the DHCP specification to accommodate requirements for conveyance of new configuration parameters or to accommodate new protocol semantics. This document describes the procedure for defining new DHCP options and message types.
新しいDHCPオプションとメッセージタイプは、DHCP仕様の公表の後に新しい設定パラメータの運送か新しいプロトコル意味論に対応するという要件を収容するために定義されるかもしれません。 このドキュメントは新しいDHCPオプションとメッセージタイプを定義するための手順について説明します。
1. Introduction
1. 序論
The Dynamic Host Configuration Protocol (DHCP) [1] provides a framework for passing configuration information to hosts on a TCP/IP network. Configuration parameters and other control information are carried in tagged data items that are stored in the 'options' field of the DHCP message. The data items themselves are also called "options" [2].
Dynamic Host Configuration Protocol(DHCP)[1]はTCP/IPネットワークで設定情報をホストに渡すのにフレームワークを提供します。 設定パラメータと他の制御情報はDHCPメッセージの'オプション'分野に保存されるタグ付けをされたデータ項目で運ばれます。 また、データ項目自体は「オプション」[2]と呼ばれます。
Droms Best Current Practice [Page 1] RFC 2939 Procedures for New DHCP Options September 2000
新しいDHCPオプション2000年9月のためのDromsの最も良い現在の習慣[1ページ]RFC2939手順
DHCP protocol messages are identified by the 'DHCP Message Type' option (option code 51). Each message type is defined by the data value carried in the 'DHCP Message Type' option.
'DHCP Message Type'オプション(オプションコード51)でDHCPプロトコルメッセージは特定されます。 それぞれのメッセージタイプは'DHCP Message Type'オプションで運ばれたデータ値によって定義されます。
This document describes the procedure for defining new DHCP options and message types. The procedure will guarantee that:
このドキュメントは新しいDHCPオプションとメッセージタイプを定義するための手順について説明します。 手順は、以下のことを保証するでしょう。
* allocation of new option numbers and message type numbers is coordinated from a single authority, * new options and message types are reviewed for technical correctness and appropriateness, and * documentation for new options and message types is complete and published.
* 新しいオプションとメッセージタイプのためのドキュメンテーションは、新しいオプション番号とメッセージ形式数の配分はただ一つの権威から調整されて、*新しいオプションとメッセージタイプは技術的な正当性と適切さのために見直されて、完全で*発表されています。
As indicated in, "Guidelines for Writing an IANA Considerations Section in RFCs", (see references), IANA acts as a central authority for assignment of numbers such as DHCP option and message type codes. The new procedure outlined in this document will provide guidance to IANA in the assignment of new option and message type codes.
にみられるように、「RFCsにIANA問題部に書くためのガイドライン」、(参照を見ます)、IANAはDHCPオプションやメッセージタイプコードなどの数の課題のための主要な権威として機能します。 本書では概説された新しい手順は新しいオプションとメッセージタイプコードの課題で指導をIANAに供給するでしょう。
This document updates and replaces RFC 2489.
このドキュメントは、RFC2489をアップデートして、取り替えます。
2. Overview and background
2. 概要とバックグラウンド
This document specifies procedures for defining new option codes and message types.
このドキュメントは新しいオプションコードとメッセージタイプを定義するための手順を指定します。
2.1 New DHCP option codes
2.1 新しいDHCPオプションコード
The procedure described in this document modifies and clarifies the procedure for defining new options in RFC 2131 [2]. The primary modification is to the time at which a new DHCP option is assigned an option number. In the procedure described in this document, the option number is not assigned until specification for the option is about to be published as an RFC.
本書では説明された手順は、RFC2131[2]で新しいオプションを定義するための手順を変更して、はっきりさせます。 オプション番号が新しいDHCPオプションに割り当てられる時までプライマリ変更があります。 本書では説明された手順で、オプション番号はRFCとして発行されようとしているまでオプションのための仕様がことである割り当てられません。
Since the publication of RFC 2132, the option number space for publicly defined DHCP options (1-127) has almost been exhausted. Many of the defined option numbers have not been followed up with Internet Drafts submitted to the DHC WG. There has been a lack of specific guidance to IANA from the DHC WG as to the assignment of DHCP option numbers.
RFC2132の公表以来、公的に定義されたDHCPオプション(1-127)のためのオプション数のスペースはほとんど消耗しています。 定義されたオプション番号の多くがインターネットDraftsをDHC WGに提出している状態で追求されていません。 DHCPオプション番号の課題に関してDHC WGからのIANAへの特定の指導の不足がありました。
The procedure as specified in RFC 2132 does not clearly state that new options are to be reviewed individually for technical correctness, appropriateness and complete documentation. RFC 2132 also does not require that new options are to be submitted to the IESG for review, and that the author of the option specification is
RFC2132の指定されるとしての手順は、新しいオプションが技術的な正当性、適切さ、および完全なドキュメンテーションのために個別に見直されることであると明確に述べません。 RFC2132も新しいオプションがレビューのためにIESGに提出することであり、オプション仕様の作者がそうであることを必要としません。
Droms Best Current Practice [Page 2] RFC 2939 Procedures for New DHCP Options September 2000
新しいDHCPオプション2000年9月のためのDromsの最も良い現在の習慣[2ページ]RFC2939手順
responsible for bringing new options to the attention of the IESG. Finally, RFC 2132 does not make clear that newly defined options are not to be incorporated into products, included in other specifications or otherwise used until the specification for the option is published as an RFC.
新しいオプションをIESGの注意にもたらすのに責任があります。 最終的に、RFC2132は、新たに定義されたオプションがオプションのための仕様がRFCとして発表されるまで、製品に組み入れられないで、また他の仕様に含まれてもいなくていなくて、また別の方法で使用もされないことであることを明らかにしません。
In the future, new DHCP option codes will be assigned by IETF consensus. New DHCP options will be documented in RFCs approved by the IESG, and the codes for those options will be assigned at the time the relevant RFCs are published. Typically, the IESG will seek input on prospective assignments from appropriate sources (e.g., a relevant Working Group if one exists). Groups of related options may be combined into a single specification and reviewed as a set by the IESG. Prior to assignment of an option code, it is not appropriate to incorporate new options into products, include the specification in other documents or otherwise make use of the new options.
将来、新しいDHCPオプションコードはIETFコンセンサスによって割り当てられるでしょう。 新しいDHCPオプションはIESGによって承認されたRFCsに記録されるでしょう、そして、関連RFCsが発行されるとき、それらのオプションのためのコードは割り当てられるでしょう。 通常、IESGは適切なソースから将来の課題に関する入力を求めるでしょう(例えば関連作業部会は1であるなら存在します)。 関連するオプションのグループは、ただ一つの仕様に合併されて、セットとしてIESGによって批評されるかもしれません。 オプションコードの課題の前に、新しいオプションを製品に組み入れるか、他のドキュメントの仕様を含んでいるか、またはそうでなければ、新しいオプションを利用するのが適切ではありません。
The DHCP option number space (1-254) is split into two parts. The site-specific option codes [2] (128-254) are defined as "Private Use" and require no review by the DHC WG. Site-specific options codes (128-254) MUST NOT be defined for use by any publicly distributed DHCP server, client or relay agent implementations. These option codes are explicitly reserved for private definition and use within a site or an organization.
DHCPオプション数のスペース(1-254)は2つの部品に分けられます。 サイト特有のオプションコード[2](128-254)は「私用」と定義されて、DHC WGでレビューを全く必要としません。 コード(128-254)を定義してはいけないサイト特有のオプションはどんな公的に分配されたDHCPでもサーバ、クライアントまたは中継エージェント実装を使用します。 これらのオプションコードは個人的な定義と使用のためにサイトか組織の中で明らかに予約されます。
The public option codes (0-127, 255) are defined as "Specification Required" and new options must be reviewed prior to assignment of an option number by IANA. The details of the review process are given in the following section of this document.
公共のオプションコード(0-127、255)は「仕様が必要である」と定義されます、そして、IANAによるオプション番号の課題の前に新しいオプションを見直さなければなりません。 吟味の過程の詳細はこのドキュメントの以下のセクションで明らかにされます。
2.2 New DHCP message types
2.2 新しいDHCPメッセージタイプ
RFC 2131 does not specify any mechanism for defining new DHCP message types. In the future, new DHCP message types will be documented in RFCs approved by the IESG, and the codes for these new message types will be assigned at the time the relevant RFCs are published.
RFC2131は新しいDHCPメッセージタイプを定義するのにどんなメカニズムも指定しません。 将来、新しいDHCPメッセージタイプはIESGによって承認されたRFCsに記録されるでしょう、そして、関連RFCsが発行されるとき、これらの新しいメッセージタイプのためのコードは割り当てられるでしょう。
Typically, the IESG will seek input on new message types from appropriate sources (e.g., a relevant Working Group if one exists). Prior to assignment of a message type code, it is not appropriate to incorporate new message types into products, include the specification in other documents or otherwise make use of the new message types.
通常、IESGは適切なソースから新しいメッセージタイプに関する入力を求めるでしょう(例えば関連作業部会は1であるなら存在します)。 メッセージタイプコードの課題の前に、新しいメッセージタイプを製品に組み入れるか、他のドキュメントの仕様を含んでいるか、またはそうでなければ、新しいメッセージタイプを利用するのが適切ではありません。
Droms Best Current Practice [Page 3] RFC 2939 Procedures for New DHCP Options September 2000
新しいDHCPオプション2000年9月のためのDromsの最も良い現在の習慣[3ページ]RFC2939手順
3. Procedure
3. 手順
The author of a new DHCP option or message type will follow these steps to obtain approval for the option and publication of the specification of the option as an RFC:
新しいDHCPオプションかメッセージタイプの作者はオプションの仕様のオプションと公表のためにRFCとして承認を得るためにこれらの方法に従うでしょう:
1. The author devises the new option or message type.
1. 作者は新しいオプションかメッセージタイプについて工夫します。
2. The author documents the new option or message type, leaving the option code or message type code as "To Be Determined" (TBD), as an Internet Draft.
2. 作者は新しいオプションかメッセージタイプを記録します、「未定」としてのオプションコードかメッセージタイプコードを(TBD)に残して、インターネットDraftとして。
The requirement that the new option or message type be documented as an Internet Draft is a matter of expediency. In theory, the new option or message type could be documented on the back of an envelope for submission; as a practical matter, the specification will eventually become an Internet Draft as part of the review process.
新しいオプションかメッセージタイプがインターネットDraftとして記録されるという要件は便宜の問題です。 理論上、服従のための封筒の裏に新しいオプションかメッセージタイプを記録できました。 実際問題として、仕様は結局、吟味の過程の一部としてインターネットDraftになるでしょう。
3. The author submits the Internet Draft for review by the IESG. Preferably, the author will submit the Internet Draft to the DHC Working Group, but the author may choose to submit the Internet Draft directly to the IESG.
3. 作者はIESGによるレビューのためにインターネットDraftを提出します。 望ましくは、作者はDHC作業部会にインターネットDraftを提出するでしょうが、作者は、直接IESGにインターネットDraftを提出するのを選ぶかもしれません。
Note that simply publishing the new option or message type as an Internet Draft does not automatically bring the option to the attention of the IESG. The author of the new option or message type must explicitly forward a request for action on the new option to the DHC WG or the IESG.
インターネットDraftが自動的にIESGの注意にオプションをもたらさないので単に新しいオプションかメッセージタイプを発表して、それに注意してください。 新しいオプションかメッセージタイプの作者は明らかに新しいオプションへの動作を求める要求をDHC WGかIESGに転送しなければなりません。
4. The specification of the new option or message type is reviewed by the IESG. The specification is reviewed by the DHC WG (if it exists) or by the IETF. If the option or message type is accepted for inclusion in the DHCP specification, the specification of the option or message type is published as an RFC. It may be published as either a standards-track or a non-standards-track RFC.
4. 新しいオプションかメッセージタイプの仕様はIESGによって再検討されます。 仕様はDHC WG(存在しているなら)かIETFによって再検討されます。 DHCP仕様での包含のためにオプションかメッセージタイプを受け入れるなら、RFCとしてオプションかメッセージタイプの仕様を発表します。 それは標準化過程か非標準化過程RFCのどちらかとして発行されるかもしれません。
5. At the time of publication as an RFC, IANA assigns a DHCP option code or message type code to the new option or message type.
5. RFCとしての公表時点で、IANAはDHCPオプションコードかメッセージタイプコードを新しいオプションかメッセージタイプに割り当てます。
4. References
4. 参照
[1] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, March 1997.
[1]Droms、R.、「ダイナミックなホスト構成プロトコル」、RFC2131、1997年3月。
[2] Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor Extensions", RFC 2132, March 1997.
[2] アレクサンダーとS.とR.Droms、「DHCPオプションとBOOTPベンダー拡大」、RFC2132、1997年3月。
Droms Best Current Practice [Page 4] RFC 2939 Procedures for New DHCP Options September 2000
新しいDHCPオプション2000年9月のためのDromsの最も良い現在の習慣[4ページ]RFC2939手順
[3] Droms, R. and K. Fong, "NetWare/IP Domain Name and Information", RFC 2142, November 1997.
[3]Droms、R.、K.フォン、および「NetWare/IPドメイン名と情報」、RFC2142、11月1997日
[4] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.
[4]Narten、T.とH.Alvestrand、「RFCsにIANA問題部に書くためのガイドライン」BCP26、RFC2434(1998年10月)。
[5] Droms, R., "Procedure for Defining New DHCP Options", RFC 2489, January 1999.
[5]Droms、R.、「新しいDHCPオプションを定義するための手順」、RFC2489、1999年1月。
5. Changes from RFC 2489
5. RFC2489からの変化
This document extends the procedures for defining new DHCP options specified in RFC 2489 [5] to include the definition of new DHCP message types. The language reserving site-specific option codes has been strengthened to emphasize the requirement that site-specific option codes must not be encoded in publicly distributed DHCP implementations.
このドキュメントは新しいDHCPメッセージタイプの定義を含むようにRFC2489[5]で指定された新しいDHCPオプションを定義するための手順を広げています。 公的に分配されたDHCP実装でサイト特有のオプションコードをコード化してはいけないという要件を強調するためにサイト特有のオプションコードを予約する言語を強化してあります。
6. Security Considerations
6. セキュリティ問題
Information that creates or updates an option code or message type code assignment needs to be authenticated.
オプションコードかメッセージタイプコード課題を作成するか、またはアップデートする情報は、認証される必要があります。
An analysis of security issues is required for all newly defined DHCP options or message types. The description of security issues in the specification of new options or message types must be as accurate as possible. The specification for a new option or message type may reference the "Security Considerations" section in the DHCP specification [1]; e.g., (from "NetWare/IP Domain Name and Information" [3]):
安全保障問題の分析がすべての新たに定義されたDHCPオプションかメッセージタイプに必要です。 新しいオプションかメッセージタイプの仕様に基づく、安全保障問題の記述はできるだけ正確でなければなりません。 新しいオプションかメッセージタイプへの仕様はDHCP仕様[1]で「セキュリティ問題」セクションに参照をつけるかもしれません。 例えば、(「NetWare/IPドメイン名と情報」[3])から:
DHCP currently provides no authentication or security mechanisms. Potential exposures to attack are discussed in section 7 of the DHCP protocol specification [RFC 2131].
DHCPは現在、どんな認証もセキュリティー対策も提供しません。DHCPプロトコル仕様[RFC2131]のセクション7で攻撃する潜在被曝について議論します。
7. IANA Considerations
7. IANA問題
RFC 2132 and RFC 2489 provided guidance to the IANA on the procedure it should follow when assigning option numbers for new DHCP options or message types. This document updates and replaces those instructions. In particular, IANA is requested to assign DHCP option codes or message type codes only for options or message types that have been approved for publication as RFCs; i.e., documents that have been approved through "IETF consensus" as defined in RFC 2434 [4].
RFC2132とRFC2489は新しいDHCPオプションかメッセージタイプのオプション番号を割り当てるときそれが従うべきである手順のIANAに指導を供給しました。 このドキュメントは、それらの指示をアップデートして、置き換えます。 特に、IANAが公表のためにRFCsとして承認されたオプションかメッセージタイプのためだけにオプションコードかメッセージタイプコードをDHCPに割り当てるよう要求されています。 すなわち、RFC2434[4]で定義されるように「IETFコンセンサス」を通して承認されたドキュメント。
Droms Best Current Practice [Page 5] RFC 2939 Procedures for New DHCP Options September 2000
新しいDHCPオプション2000年9月のためのDromsの最も良い現在の習慣[5ページ]RFC2939手順
8. Author's Address
8. 作者のアドレス
Ralph Droms Computer Science Department 323 Dana Engineering Bucknell University Lewisburg, PA 17837
ラルフDromsコンピュータ理学部323ダナ・工学Bucknell大学リューイスバーグ、PA 17837
Phone: (570) 524-1145 EMail: droms@bucknell.edu
以下に電話をしてください。 (570) 524-1145 メールしてください: droms@bucknell.edu
Droms Best Current Practice [Page 6] RFC 2939 Procedures for New DHCP Options September 2000
新しいDHCPオプション2000年9月のためのDromsの最も良い現在の習慣[6ページ]RFC2939手順
9. Full Copyright Statement
9. 完全な著作権宣言文
Copyright (C) The Internet Society (2000). All Rights Reserved.
Copyright(C)インターネット協会(2000)。 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機能のための基金は現在、インターネット協会によって提供されます。
Droms Best Current Practice [Page 7]
Dromsの最も良い現在の習慣[7ページ]
一覧
スポンサーリンク