Network Working Group R. Droms
Request for Comments: 2939 Bucknell University
BCP: 43 September 2000
Obsoletes: 2489
Category: Best Current Practice
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.
版权所有（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）提供了一个框架，用于将配置信息传递给传输控制协议/互联网协议（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.
如“在RFCs中编写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工作组的互联网草案中跟进。DHC工作组没有就DHCP选项编号的分配向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
RFC 2132中规定的程序未明确说明应单独审查新选项的技术正确性、适当性和完整文件。RFC 2132也不要求将新选项提交给IESG审查，并且选项规范的作者是
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注意。最后，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]（128-254）定义为“私人使用”，无需DHC工作组审查。站点特定选项代码（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-127255）定义为“所需规范”，新选项必须在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：
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. 作者记录新选项或消息类型，将选项代码或消息类型代码保留为“待定”（待定），作为互联网草稿。
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.
请注意，仅将新选项或消息类型发布为Internet草稿并不会自动引起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工作组（如果存在）或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] Alexander，S.和R.Droms，“DHCP选项和BOOTP供应商扩展”，RFC 21321997年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，“在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月。
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实现中编码的要求。
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]中的“安全注意事项”部分；e、 （摘自“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节讨论了潜在的攻击风险。
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为IANA提供了在为新DHCP选项或消息类型分配选项编号时应遵循的程序指南。本文档更新并替换这些说明。特别是，IANA被要求仅为已批准发布为RFC的选项或消息类型分配DHCP选项代码或消息类型代码；i、 如RFC 2434[4]所定义，通过“IETF共识”批准的文件。
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
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编辑功能的资金目前由互联网协会提供。