RFC 2489 - Procedure for Defining New DHCP Options 日本語訳

原文URL : https://datatracker.ietf.org/doc/html/rfc2489
タイトル : RFC 2489 - 新しいDHCPオプションを定義する手順
翻訳編集 : 自動生成

[要約] RFC 2489は、新しいDHCPオプションを定義する手順を提供しています。その目的は、DHCPプロトコルの拡張性を向上させ、新しいネットワーク要件に対応するためです。

Network Working Group                                           R. Droms
Request for Comments: 2489                           Bucknell University
BCP: 29                                                     January 1999
Category: Best Current Practice

Procedure for Defining New DHCP Options

新しいDHCPオプションを定義する手順

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.

このドキュメントでは、インターネットコミュニティのためのインターネットのベストプラクティスを示し、改善のためのディスカッションと提案を要求します。このメモの配布は無制限です。

著作権表示

Abstract

概要

The Dynamic Host Configuration Protocol (DHCP) 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."

動的ホスト構成プロトコル（DHCP）は、TCP / IPネットワーク上のホストに構成情報を渡すためのフレームワークを提供します。構成パラメータとその他の制御情報は、DHCPメッセージの「オプション」フィールドに格納されているタグ付きデータ項目で伝達されます。データ項目自体は「オプション」とも呼ばれます。

New DHCP options may be defined after the publication of the DHCP specification to accommodate requirements for conveyance of new configuration parameters. This document describes the procedure for defining new DHCP options.

新しい構成パラメーターの伝達に関する要件に対応するために、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]

This document describes the procedure for defining new DHCP options. The procedure will guarantee that:

このドキュメントでは、新しいDHCPオプションを定義する手順について説明します。手順は以下を保証します：

* allocation of new option numbers is coordinated from a single authority, * new options are reviewed for technical correctness and appropriateness, and * documentation for new options 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 codes. The new procedure outlined in this document will provide guidance to IANA in the assignment of new option codes.

「RFCでIANAの考慮事項セクションを作成するためのガイドライン」（参考文献を参照）に示されているように、IANAはDHCPオプションコードなどの番号を割り当てるための中央機関として機能します。このドキュメントで概説されている新しい手順は、新しいオプションコードの割り当てにおけるIANAへのガイダンスを提供します。

2. Overview and background

2. 概要と背景

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 publically 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 options (128-254) are defined as "Private Use" and require no review by the DHC WG. The public options (1-127) 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.

DHCPオプション番号スペース（1〜254）は2つの部分に分かれています。サイト固有のオプション（128〜254）は「私用」として定義されており、DHC WGによるレビューは必要ありません。パブリックオプション（1-127）は「指定が必要」として定義されており、新しいオプションはIANAによってオプション番号が割り当てられる前に確認する必要があります。レビュープロセスの詳細については、このドキュメントの次のセクションで説明します。

3. Procedure

3. 手順

The author of a new DHCP option 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.

1. 著者は新しいオプションを考案します。

2. The author documents the new option, leaving the option code as "To Be Determined" (TBD), as an Internet Draft.

2. 著者は、新しいオプションを文書化し、オプションコードを「未定」（TBD）のまま、インターネットドラフトとして残します。

The requirement that the new option be documented as an Internet Draft is a matter of expediency. In theory, the new option 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 as an Internet Draft does not automatically bring the option to the attention of the IESG. The author of the new option 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 is reviewed by the IESG. The specification is reviewed by the DHC WG (if it exists) or by the IETF. If the option is accepted for inclusion in the DHCP specification, the specification of the option 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 number to the new option.

5. RFCとして公開された時点で、IANAはDHCPオプション番号を新しいオプションに割り当てています。

4. References

4. 参考文献

[1] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, March 1997.

[1] Droms、R。、「Dynamic Host Configuration Protocol」、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、「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、「RFCでIANAの考慮事項セクションを作成するためのガイドライン」、BCP 26、RFC 2434、1998年10月。

5. Security Considerations

5. セキュリティに関する考慮事項

Information that creates or updates an option number assignment needs to be authenticated.

オプション番号の割り当てを作成または更新する情報は、認証される必要があります。

An analysis of security issues is required for all newly defined DHCP options. The description of security issues in the specification of new options must be as accurate as possible. The specification for a new option 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プロトコル仕様[RFC 2131]のセクション7で説明されています。

6. IANA Considerations

6. IANAに関する考慮事項

RFC 2132 provided guidance to the IANA on the procedure it should follow when assigning option numbers for new DHCP options. This document updates and replaces those instructions. In particular, IANA is requested to assign DHCP option numbers only for options 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は、新しいDHCPオプションにオプション番号を割り当てるときに従う必要がある手順に関するIANAへのガイダンスを提供しました。このドキュメントは、それらの手順を更新して置き換えます。特に、IANAは、RFCとしての公開が承認されたオプションにのみDHCPオプション番号を割り当てるように要求されます。つまり、RFC 2434 [4]で定義されている「IETFコンセンサス」を通じて承認されたドキュメント。

7. Author's Address

7. 著者のアドレス

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

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

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

電話：（717）524-1145メール：droms@bucknell.edu

8. Full Copyright Statement

8. 完全な著作権表示

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.

このドキュメントとここに含まれる情報は「現状有姿」で提供され、インターネット社会およびインターネット技術タスクフォースは、明示または黙示を問わず、ここに記載されている情報の使用が保証するものに限定されないいかなる保証も含め、一切の保証を否認します。商品性または特定の目的への適合性に関する権利または黙示の保証を侵害すること。