[要約] RFC 2939は、新しいDHCPオプションとメッセージタイプの定義の手順とIANAガイドラインについて説明しています。このRFCの目的は、DHCPプロトコルの拡張性を向上させ、新しいオプションとメッセージタイプの追加を効果的に管理することです。

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

新しいDHCPオプションとメッセージタイプの定義に関する手順とIANAガイドライン

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.

このドキュメントは、インターネットコミュニティのインターネットの最良のプラクティスを指定し、改善のための議論と提案を要求します。このメモの配布は無制限です。

Copyright Notice

著作権表示

Copyright (C) The Internet Society (2000). All Rights Reserved.

Copyright(c)The Internet Society(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".

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プロトコルメッセージは、「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オプションとメッセージタイプを定義する手順について説明します。

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].

動的ホスト構成プロトコル(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.

示されているように、「RFCSでIANA考慮事項セクションを書くためのガイドライン」(参考文献を参照)、IANAは、DHCPオプションやメッセージタイプコードなどの数字の割り当ての中央当局として機能します。このドキュメントで概説されている新しい手順は、新しいオプションとメッセージタイプコードの割り当てにおけるIANAへのガイダンスを提供します。

This document updates and replaces RFC 2489.

このドキュメントは、RFC 2489を更新および置き換えます。

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.

このドキュメントで説明されている手順は、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によって承認されたRFCSで文書化され、これらのオプションのコードは、関連する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によるオプション番号を割り当てる前に、新しいオプションをレビューする必要があります。レビュープロセスの詳細は、このドキュメントの次のセクションに記載されています。

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.

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は、適切なソースからの新しいメッセージタイプに関する入力を求めます(たとえば、存在する場合は関連するワーキンググループ)。メッセージタイプコードを割り当てる前に、新しいメッセージタイプを製品に組み込む、他のドキュメントに仕様を含める、または新しいメッセージタイプを使用することは適切ではありません。

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)としてインターネットのドラフトとして残します。

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オプションコードまたはメッセージタイプコードを割り当てます。

4. References
4. 参考文献

[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] Alexander、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. Fong、「ネットウェア/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。、「新しいDHCPオプションを定義する手順」、RFC 2489、1999年1月。

5. Changes from RFC 2489
5. RFC 2489からの変更

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.

このドキュメントは、RFC 2489 [5]で指定された新しいDHCPオプションを定義する手順を拡張して、新しい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]の「セキュリティ上の考慮事項」セクションを参照できます。たとえば、(「ネットウェア/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プロトコル仕様[RFC 2131]のセクション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].

RFC 2132およびRFC 2489は、新しいDHCPオプションまたはメッセージタイプにオプション番号を割り当てるときに従うべき手順に関するIANAにガイダンスを提供しました。このドキュメントは、これらの指示を更新および置き換えます。特に、IANAは、RFCSとして公開されたオプションまたはメッセージタイプに対してのみDHCPオプションコードまたはメッセージタイプコードを割り当てるように要求されます。すなわち、RFC 2434 [4]で定義されている「IETFコンセンサス」を通じて承認された文書。

8. Author's Address
8. 著者の連絡先

Ralph Droms Computer Science Department 323 Dana Engineering Bucknell University Lewisburg, PA 17837

ラルフドロムコンピューターサイエンス部門323ダナエンジニアリングバックネル大学ルイスバーグ、ペンシルベニア州17837

Phone: (570) 524-1145 EMail: droms@bucknell.edu

電話:(570)524-1145メール:droms@bucknell.edu

9. 完全な著作権声明

Copyright (C) The Internet Society (2000). All Rights Reserved.

Copyright(c)The Internet Society(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エディター機能の資金は現在、インターネット協会によって提供されています。