Network Working Group R. Droms
Request for Comments: 2939 Bucknell University
BCP: 43 September 2000
Obsoletes: 2489
Category: Best Current Practice
Procedures and IANA Guidelines for Definition of
New DHCP Options and Message Types
Status of this 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.
著作権（C）インターネット協会（2000）。全著作権所有。
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".
DHCP（Dynamic Host Configuration Protocol）は、伝送制御プロトコル/インターネットプロトコル（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プロトコルメッセージは、「DHCPメッセージタイプ」オプション（オプションコード51）によって識別されます。各メッセージタイプは、「DHCPメッセージタイプ」オプションで運ばれたデータ値によって定義されます。
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オプションおよびメッセージタイプを定義するための手順を説明します。
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].
動的ホスト構成プロトコル（DHCP）[1] TCP / IPネットワーク上のホストに設定情報を渡すためのフレームワークを提供します。設定パラメータとその他の制御情報は、DHCPメッセージの「オプション」フィールドに格納されているタグ付きデータ項目に運ばれます。データ項目自体はまた、「オプション」と呼ばれている[2]。
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プロトコルメッセージは、「DHCPメッセージタイプ」オプション（オプションコード51）によって識別されます。各メッセージタイプは、「DHCPメッセージタイプ」オプションで運ばれたデータ値によって定義されます。
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.
、「RFCでIANA問題部に書くためのガイドライン」に示されているように、（参考文献を参照）、IANAは、DHCPオプションとメッセージタイプコードなど番号の割り当てのための中央機関として機能します。このドキュメントで概説新しいプロシージャは、新しいオプションとメッセージタイプコードの割り当てにIANAにガイダンスを提供します。
This document updates and replaces RFC 2489.
このドキュメントは、アップデートとRFC 2489を置き換えます。
This document specifies procedures for defining new option codes and message types.
この文書は、新しいオプションコードとメッセージタイプを定義するための手順を指定します。
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.
この文書に記載された手順を変更し、RFC 2131に新しいオプションを定義するための手順を明確にした[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.
RFC 2132の出版以来、公に定義されたDHCPオプション（1-127）のオプション数のスペースがほとんど使い果たされています。定義されたオプション番号の多くは、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 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.
RFC 2132で指定された手順は明らかに新しいオプションが技術的な正確性、妥当性および完全なドキュメントのために、個別に検討されるべきであることを述べるものではありません。 RFC 2132はまた、新しいオプションがレビューのためにIESGに提出されることを必要とせず、オプション仕様の作者は、IESGの注意に新しいオプションをもたらすための責任があること。最後に、RFC 2132には、オプションの仕様は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によって承認されたRFCで文書化され、それらのオプションのためのコードは、関連するRFCが公開されている時に割り当てられます。典型的には、IESGは、適切な供給源（例えば、関連するワーキンググループが存在する場合）から、将来の割り当ての入力を求めます。関連オプションのグループは、単一の仕様に合わせて、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によってオプション番号の割り当てに検討する必要があります。レビュープロセスの詳細は、このドキュメントの次のセクションに記載されています。
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.
RFC 2131には、新しいDHCPメッセージタイプを定義するための任意のメカニズムを指定していません。将来的には、新しいDHCPメッセージタイプは、IESGによって承認されたRFCで文書化され、これらの新しいメッセージタイプのコードは、関連するRFCが公開されている時に割り当てられます。
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は、適切な供給源（例えば、関連するワーキンググループが存在する場合）からの新しいメッセージタイプの入力を求めます。先行メッセージタイプコードの割り当てに、製品に新しいメッセージ・タイプを組み込む他のドキュメントで指定を含むか、またはそうでなければ、新しいメッセージ・タイプを利用することは適切ではありません。
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としてオプションの指定のオプションと公開のための承認を得るために、次の手順を実行します：
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）を文書化します。
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.
新しいオプションまたはメッセージタイプは、インターネットドラフトとして文書化する要件は便宜の問題です。理論的には、新しいオプションまたはメッセージタイプは、提出用封筒の裏に文書化することができ、実際問題として、仕様が最終的にレビュープロセスの一環として、インターネットドラフトになります。
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による検討のためのインターネットドラフトを提出します。好ましくは、著者はDHC作業部会にインターネットドラフトを提出しますが、著者はIESGに直接インターネットドラフトを提出することもできます。
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.
単にインターネットドラフトとして新しいオプションまたはメッセージのタイプを公開すると、自動的に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オプションコードまたはメッセージタイプコードを割り当てます。
[1] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, March 1997.
[1] Droms、R.、 "動的ホスト構成プロトコル"、RFC 2131、1997年3月。
[2] Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor Extensions", RFC 2132, March 1997.
[2]アレクサンダー、S.とR. Droms、 "DHCPオプションとBOOTPベンダー拡張機能"、RFC 2132、1997年3月。
[3] Droms, R. and K. Fong, "NetWare/IP Domain Name and Information", RFC 2142, November 1997.
[3] Droms、R.とK.フォン、 "NetWareの/ IPドメイン名と情報"、RFC 2142、1997年11月。
[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問題部に書くためのガイドライン"、BCP 26、RFC 2434、1998年10月。
[5] Droms, R., "Procedure for Defining New DHCP Options", RFC 2489, January 1999.
[5] Droms、R.、RFC 2489、1999年1月 "の定義新しいDHCPオプションの手順"。
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メッセージタイプの定義が含まれるようにRFC 2489 [5]で指定された新しいDHCPオプションを定義するための手順を拡張します。サイト固有のオプションコードを予約する言語は、サイト固有のオプションコードは一般に配布DHCPの実装でエンコードされてはならない要件を強調するために強化されています。
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]。例えば、（[3] "のNetWare / IPドメイン名と情報" から）。
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プロトコル仕様[RFC 2131]のセクション7に記載されています。
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].
RFC 2132およびRFC 2489には、新しいDHCPオプションまたはメッセージタイプのためのオプション番号を割り当てるときに、それは従うべき手順にIANAへの指導を提供します。このドキュメントの更新とは、それらの命令を置き換えます。具体的には、IANAは、唯一のRFCとして公表のために承認されたオプションまたはメッセージタイプのためのDHCPオプションコードまたはメッセージ・タイプ・コードを割り当てることが要求されています。即ち、RFC 2434で定義される「IETFコンセンサス」を介して承認された文書[4]。
Ralph Droms Computer Science Department 323 Dana Engineering Bucknell University Lewisburg, PA 17837
ラルフDromsコンピュータサイエンス学部323ダナエンジニアリングバックネル大学ルイスバーグ、PA 17837
Phone: (570) 524-1145 EMail: droms@bucknell.edu
電話：（570）524-1145 Eメール：droms@bucknell.edu
Copyright (C) The Internet Society (2000). All Rights Reserved.
著作権（C）インターネット協会（2000）。全著作権所有。
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機能のための基金は現在、インターネット協会によって提供されます。