Network Working Group B. Volz
Request for Comments: 3942 Cisco Systems, Inc.
Updates: 2132 November 2004
Category: Standards Track
Reclassifying Dynamic Host Configuration Protocol
version 4 (DHCPv4) Options
Status of this 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.
この文書は、インターネットコミュニティのためのインターネット標準トラックプロトコルを指定し、改善のための議論と提案を要求します。このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」（STD 1）の最新版を参照してください。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2004).
著作権（C）インターネット協会（2004）。
Abstract
抽象
This document updates RFC 2132 to reclassify Dynamic Host Configuration Protocol version 4 (DHCPv4) option codes 128 to 223 (decimal) as publicly defined options to be managed by IANA in accordance with RFC 2939. This document directs IANA to make these option codes available for assignment as publicly defined DHCP options for future options.
この文書では、のためにこれらのオプションコードを利用できるようにIANAに指示し、動的ホスト構成プロトコルバージョン4（DHCPv4の）オプションコードRFC 2939.に従い、IANAによって管理される128〜223（10進数）として公に定義されたオプションを再分類するには、このドキュメントの更新のRFC 2132将来のオプションについては、公に定義されたDHCPオプションとして割り当て。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Requirements Notation . . . . . . . . . . . . . . . . . . . . 2
3. Background . . . . . . . . . . . . . . . . . . . . . . . . . . 2
3.1. Publicly Defined Options Range . . . . . . . . . . . . . 2
3.2. Site-Specific Options Range . . . . . . . . . . . . . . 3
4. Reclassifying Options . . . . . . . . . . . . . . . . . . . . 3
5. Security Considerations . . . . . . . . . . . . . . . . . . . 4
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 5
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 5
8.1. Normative References . . . . . . . . . . . . . . . . . . 5
8.2. Informative References . . . . . . . . . . . . . . . . . 6
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 6
Full Copyright Statement . . . . . . . . . . . . . . . . . . . . . 7
The DHCPv4 [RFC2131] publicly defined options range, options 1 - 127, is nearly used up. Efforts such as [RFC3679] help extend the life of this space, but ultimately the space will be exhausted.
公にオプション範囲に定義のDHCPv4 [RFC2131]、オプション1から127は、ほぼ使い果たされます。そのような[RFC3679]などの取り組みは、この空間の寿命を延ばすが、最終的にスペースが排出されます。
This document reclassifies much of the site-specific option range, which has not been widely used for its original intended purpose, to extend the publicly defined options space.
この文書は、広く公に定義されたオプションのスペースを拡張するために、その本来の目的のために使用されていないサイト固有のオプションの範囲の多くを再分類します。
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 [RFC2119].
この文書のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はあります[RFC2119]に記載されているように解釈されます。
The DHCP option space (0 - 255) is divided into two ranges [RFC2132]:
DHCPオプションのスペース（0から255）は、二つの範囲[RFC2132]に分かれています。
1. 1 - 127 are publicly defined options, now allocated in accordance with [RFC2939].
1. 1から127公的に定義されているオプションは、今[RFC2939]に従って割り当てられました。
Options 0 (pad) and 255 (end) are special and defined in [RFC2131].
オプション0（パッド）及び255（端部）が特殊と[RFC2131]で定義されています。
The publicly defined options space (1 - 127) is nearly exhausted. Recent work [RFC3679] will buy more time, as several allocated but unused option codes have been reclaimed. A review could be made from time to time to determine whether there are other option codes that can be reclaimed.
公的に定義されたオプションのスペース（1から127）は、ほぼ排出されます。いくつかの割り当てられたが、未使用のオプションコードを再利用されているとして最近の研究[RFC3679]は、より多くの時間を購入します。レビューを再利用することができ、他のオプションコードがあるかどうかを判断するために、随時行うことができます。
A longer-term solution to the eventual exhaustion of the publicly defined options space is desired. The DHC WG evaluated several solutions:
公的に定義されたオプション空間の最終的な枯渇に長期的解決策が望まれています。 DHC WGは、いくつかのソリューションを評価しました。
1. Using options 126 and 127 to carry 16-bit options as originally proposed by Ralph Droms in late 1996. However, this significantly penalizes the first option assigned to this new space, as it requires implementing the 16-bit option support. Because of this, options 126 and 127 have been reclaimed [RFC3679].
1.もともと後半に1996年にラルフDromsによって提案された16ビットのオプションを運ぶためにオプション126および127を使用して、それが16ビットのオプションのサポートを実装する必要がしかし、これはかなり、この新しい空間に割り当てられた最初のオプションにペナルティを課します。このため、オプション126および127は、[RFC3679]を再利用されてきました。
2. Using a new magic cookie and 16-bit option code format. However, this proposal
2.新しいマジッククッキーと16ビットのオプションコードの形式を使用。しかし、この提案
* penalizes the first option assigned to this new space, as it requires significant changes to clients, servers, and relay agents,
それは、クライアント、サーバ、およびリレーエージェントに大幅な変更を必要とする*、この新しい空間に割り当てられた最初のオプションにペナルティを課します
* could adversely impact existing clients, servers, and relay agents that fail to properly check the magic cookie value,
*悪影響を適切にマジッククッキーの値をチェックするために失敗し、既存のクライアント、サーバ、およびリレーエージェントに影響を与える可能性があり、
* requires support of both message formats for the foreseeable future, and
*予見可能な将来のために、両方のメッセージ・フォーマットのサポートを必要とし、
* requires clients to send multiple DHCPDISCOVER messages -- one for each magic cookie.
*複数のDHCPDISCOVERメッセージを送信するためにクライアントが必要です - 各マジッククッキーについて1。
3. Reclassifying a portion of the site-specific option codes as publicly defined. The impact is minimal, as only those sites presently using options in the reclassified range need to renumber their options.
3.として公に定義サイト固有のオプションコードの一部を再分類。のみ、これらのサイトは、現在、そのオプションを付け直すに組み替え範囲を必要としているオプションを使用するなどの影響は、軽微であります。
The site-specific option range is rather large (127 options in all) and little used. The original intent of the site-specific option range was to support local (to a site) configuration options, and it is difficult to believe a site would need 127 options for this purpose. Further, many DHCP client implementations do not provide a well documented means to request site-specific options from a server or to allow applications to extract the returned option values.
サイト固有のオプションの範囲はかなり大きい（全部で127個のオプション）と少し使用されています。サイト固有のオプションの範囲の本来の目的は、ローカル設定オプション（サイトへ）をサポートすることでした、そしてサイトは、この目的のために127個のオプションが必要と考えていることは困難です。さらに、多くのDHCPクライアントの実装は、サーバから、サイト固有のオプションを要求するか、アプリケーションが返されるオプションの値を抽出できるようにするために十分に文書化する手段を提供していません。
Some vendors have made use of site-specific option codes that violate the intent of the site-specific options, as the options are used to configure features of their products and thus are specific to many sites. This usage could potentially cause problems if a site that has been using the same site-specific option codes for other purposes deploys products from one of the vendors, or if two vendors pick the same site-specific options.
オプションは、自社製品の機能を設定するために使用するため、多くのサイトに固有のものですされているように、一部のベンダーは、サイト固有のオプションの意図に反するサイト固有のオプションコードを利用してきました。他の目的のために同じサイト固有のオプションコードを使用していたサイトが、ベンダーの1から製品を展開している場合、または2つのベンダーが同じサイト固有のオプションを選択する場合は、この使用法は、潜在的な問題を引き起こす可能性があります。
The site-specific option codes 128 to 223 are hereby reclassified as publicly defined options. This leaves 31 site-specific options, 224 to 254.
サイト固有のオプションコード223から128こことして公に定義されたオプションを再分類されています。これは、31サイト固有のオプション、254から224を残します。
To allow vendors that have made use of site-specific options within the reclassified range to publish their option usage and to request an official assignment of the option number to that usage, the following procedure will be used to reclassify these options:
再分類された範囲内で、サイト固有のオプションを利用してきたベンダーはオプションの使用状況を公表し、その利用状況にオプション番号の公式割り当てを要求できるようにするには、次の手順では、これらのオプションを再分類するために使用されます。
1. The reclassified options (128 to 223) will be placed in the "Unavailable" state by IANA. These options are not yet available for assignment to publicly defined options.
1.再分類オプション（223から128）は、IANAによって、「使用不可」の状態に置かれます。これらのオプションはまだ公に定義されたオプションへの割り当てのために利用できません。
2. Vendors that currently use one or more of the reclassified options have 6 months following this RFC's publication date to notify the DHC WG and IANA that they are using particular options numbers and agree to document that usage in an RFC. IANA will move these options from the "Unavailable" to "Tentatively Assigned" state.
現在、再分類の1つ以上のオプションを使用する2.ベンダーは、特定のオプション番号を使用し、RFCでその使用方法を文書化することに同意していることDHC WGとIANAに通知し、このRFCの発行日、次の6ヶ月を持っています。 IANAは、「暫定的に割り当てられた」状態に「使用不可」から、これらのオプションを移動します。
Vendors have 18 months from this RFC's publication date to start the documentation process by submitting an Internet-Draft.
ベンダーは、インターネットドラフトを提出することによって文書化プロセスを開始するには、このRFCの発行日から18ヶ月を持っています。
NOTE: If multiple vendors of an option number come forward and can demonstrate that their usage is in reasonably wide use, none of the vendors will be allowed to keep the current option number, and they MUST go through the normal process of getting a publicly assigned option [RFC2939].
注：オプション番号の複数のベンダーが前方に来て、その使用量は合理的に広く使用されていることを証明することができた場合は、ベンダーのどれも現在のオプション番号を維持するために許可されません、そして、彼らは公に割り当てられ得ることの正常な過程を経なければなりませんオプション[RFC2939]。
3. Any options still classified as "Unavailable" 6 months after the RFC publication date will be moved to the "Unassigned" state by IANA. These options may then be assigned to any new publicly defined options in accordance with [RFC2939].
3.まだRFCの発行日は、IANAによって「未割り当て」状態に移行します6ヶ月後に「使用不可」に分類される任意のオプションを。これらのオプションは、次に、[RFC2939]に従って新しい公的に定義されたオプションに割り当てられてもよいです。
4. For those options in the "Tentatively Assigned" state, vendors have 18 months following this RFC's publication date to submit an Internet-Draft documenting the option. The documented usage MUST be consistent with the existing usage. When the option usage is published as an RFC, IANA will move the option to the "Assigned" state.
「一応割り当てられた」状態でこれらのオプションについては4、ベンダーがオプションを文書化するインターネットドラフトを提出するために、このRFCの発行日、次の18ヶ月を持っています。文書の使用は、既存の利用状況と一致していなければなりません。オプションの使用がRFCとして公開されると、IANAは、「割り当て」状態にオプションを移動します。
If no Internet-Draft is published within the 18 months or should one of these Internet-Drafts expire after the 18 months, IANA will move the option to the "Unassigned" state, and the option may then be assigned to any new publicly defined options in accordance with [RFC2939].
何のインターネットドラフトが18ヶ月以内に公開されていないか、またはこれらのインターネットドラフトの1が18ヶ月後に期限切れにする必要がある場合、IANAは、「未割り当て」の状態にオプションを移動し、オプションは、その後、新しい公に定義されたオプションに割り当てることができ、 [RFC2939]に従っています。
Sites presently using site-specific option codes within the reclassified range SHOULD take steps to renumber these options to values within the remaining range. If a site needs more than 31 site-specific options, the site must switch to using suboptions, as has been done for other options, such as the Relay Agent Information Option [RFC3046].
サイトは現在、再分類の範囲内にサイト固有のオプションコードを使用すると、残りの範囲内の値にこれらのオプションの番号を変更するための措置をとるべきです。サイトは31以上のサイト固有のオプションを必要とする場合は、このようなリレーエージェント情報オプション[RFC3046]などの他のオプション、のために行われているように、サイトには、サブオプションの使用に切り替える必要があります。
This document in and by itself provides no security, nor does it impact existing DCHP security as described in [RFC2131].
それ自体によって、この文書には、セキュリティを提供しない、また、[RFC 2131]で説明したように、既存のDHCPのセキュリティに影響を与えません。
IANA is requested to
IANAはに要求されています
1. expand the publicly defined DHCPv4 options space from 1 - 127 to 1 - 223. The new options (128 - 223) are to be listed as "Unavailable" and MUST NOT be assigned to any publicly defined options.
223新しいオプション（128 - - 223）127 1 - 1 1から公的に定義されたDHCPv4オプションスペース拡大「使用不可」と表示されるが、任意の公的に定義されたオプションに割り当ててはいけません。
2. receive notices from vendors that have been using one or more of the options in the 128-223 range that they are using the option and are willing to document that usage. IANA will list these options as "Tentatively Assigned".
2.彼らはオプションを使用している128から223の範囲内の1つ以上のオプションを使用し、その使用方法を文書化して喜んでいるされているベンダーからの通知を受け取ります。 IANAは、「暫定的に割り当てられた」として、これらのオプションの一覧が表示されます。
3. change the listing of any options listed as "Unavailable" to "Available" 6 months from this RFC's publication date. These options may now be assigned in accordance with [RFC2939].
3.このRFCの発行日から「使用可能」6ヶ月に「使用不可」と表示されたオプションのリストを変更します。これらのオプションは今[RFC2939]に従って割り当てることができます。
4. change the listing of any options listed as "Tentatively-Assigned" to "Unavailable" 18 months from this RFC's publication date and periodically thereafter as long as there is an option listed as "Tentatively-Assigned", if no un-expired Internet-Draft exists documenting the usage.
4.「仮割り当て」としてリストされているオプションのリストを変更するには、このRFCの発行日から「使用不可」18ヶ月とその後定期的に限り、「仮割り当て」としてリストされているオプションがあるとしてノー非期限切れのインターネットの場合-draftは、使用を文書が存在します。
Many thanks to Ralph Droms and Ted Lemon for their valuable input and earlier work on the various alternatives.
様々な代替の貴重な入力およびそれ以前の仕事のためのラルフDromsと、テッドレモンに感謝します。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、BCP 14、RFC 2119、1997年3月。
[RFC2131] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, March 1997.
[RFC2131] Droms、R.、 "動的ホスト構成プロトコル"、RFC 2131、1997年3月。
[RFC2132] Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor Extensions", RFC 2132, March 1997.
[RFC2132]アレクサンダー、S.とR. Droms、 "DHCPオプションとBOOTPベンダー拡張機能"、RFC 2132、1997年3月。
[RFC2939] Droms, R., "Procedures and IANA Guidelines for Definition of New DHCP Options and Message Types", BCP 43, RFC 2939, September 2000.
[RFC2939] Droms、R.、BCP 43、RFC 2939、2000年9月 "新しいDHCPオプションとメッセージタイプの定義のための手順とIANAガイドライン"。
[RFC3046] Patrick, M., "DHCP Relay Agent Information Option", RFC 3046, January 2001.
[RFC3046]パトリック、M.、 "DHCPリレーエージェント情報オプション"、RFC 3046、2001年1月。
[RFC3679] Droms, R., "Unused Dynamic Host Configuration Protocol (DHCP) Option Codes", RFC 3679, January 2004.
[RFC3679] Droms、R.、 "未使用の動的ホスト構成プロトコル（DHCP）オプション・コード"、RFC 3679、2004年1月。
Author's Address
著者のアドレス
Bernard Volz Cisco Systems, Inc. 1414 Massachusetts Ave. Boxborough, MA 01719 USA
バーナード・フォルツシスコシステムズ株式会社1414年マサチューセッツアベニュー。ボックスボロー、MA 01719 USA
Phone: +1 978 936 0382 EMail: volz@cisco.com
電話：+1 978 936 0382 Eメール：volz@cisco.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2004).
著作権（C）インターネット協会（2004）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
この文書では、BCP 78に含まれる権利と許可と制限の適用を受けており、その中の記載を除いて、作者は彼らのすべての権利を保有します。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM 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.
この文書とここに含まれている情報は、基礎とCONTRIBUTOR「そのまま」、ORGANIZATION HE / SHEが表すまたはインターネットソサエティおよびインターネット・エンジニアリング・タスク・フォース放棄すべての保証、明示または、（もしあれば）後援ISに設けられています。黙示、情報の利用は、特定の目的に対する権利または商品性または適合性の黙示の保証を侵害しない任意の保証含むがこれらに限定されません。
Intellectual Property
知的財産
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the IETF's procedures with respect to rights in IETF Documents can be found in BCP 78 and BCP 79.
IETFは、本書またはそのような権限下で、ライセンスがたりないかもしれない程度に記載された技術の実装や使用に関係すると主張される可能性があります任意の知的財産権やその他の権利の有効性または範囲に関していかなる位置を取りません利用可能です。またそれは、それがどのような権利を確認する独自の取り組みを行ったことを示すものでもありません。 IETF文書の権利に関するIETFの手続きの情報は、BCP 78およびBCP 79に記載されています。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IPRの開示のコピーが利用できるようにIETF事務局とライセンスの保証に行われた、または本仕様の実装者または利用者がそのような所有権の使用のための一般的なライセンスまたは許可を取得するために作られた試みの結果を得ることができますhttp://www.ietf.org/iprのIETFのオンラインIPRリポジトリから。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFは、その注意にこの標準を実装するために必要とされる技術をカバーすることができる任意の著作権、特許または特許出願、またはその他の所有権を持ってすべての利害関係者を招待します。 ietf-ipr@ietf.orgのIETFに情報を記述してください。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。