Network Working Group R. Droms
Request for Comments: 2489 Bucknell University
BCP: 29 January 1999
Category: Best Current Practice
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.
本文件规定了互联网社区的最佳现行做法，并要求进行讨论和提出改进建议。本备忘录的分发不受限制。
Copyright Notice
版权公告
Copyright (C) The Internet Society (1999). All Rights Reserved.
版权所有（C）互联网协会（1999年）。版权所有。
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选项的过程。
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.
如“在RFCs中编写IANA注意事项指南”一节所述（见参考文献），IANA充当分配数字（如DHCP选项代码）的中央机构。本文件中概述的新程序将为IANA分配新选项代码提供指导。
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工作组的互联网草案中跟进。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 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
DHCP选项编号空间（1-254）分为两部分。现场特定选项（128-254）定义为“私人使用”，无需DHC工作组审查。公共选项（1-127）为
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.
定义为“所需规范”，新选项必须在IANA分配选项编号之前进行审查。本文件下一节给出了审查过程的详细信息。
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. 作者记录了新选项，将选项代码保留为“待定”（待定），作为互联网草稿。
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工作组或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工作组（如果存在）或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选项编号。
[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月。
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]中的“安全注意事项”部分；e、 g.（摘自“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 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选项编号；i、 如RFC 2434[4]所定义，通过“IETF共识”批准的文件。
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
Copyright (C) The Internet Society (1999). All Rights Reserved.
版权所有（C）互联网协会（1999年）。版权所有。
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.
本文件和其中包含的信息是按“原样”提供的，互联网协会和互联网工程任务组否认所有明示或暗示的保证，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。