From 4bfd864f10b68b71482b35c818559068ef8d5797 Mon Sep 17 00:00:00 2001 From: Thomas Voss Date: Wed, 27 Nov 2024 20:54:24 +0100 Subject: doc: Add RFC documents --- doc/rfc/rfc2489.txt | 283 ++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 283 insertions(+) create mode 100644 doc/rfc/rfc2489.txt (limited to 'doc/rfc/rfc2489.txt') diff --git a/doc/rfc/rfc2489.txt b/doc/rfc/rfc2489.txt new file mode 100644 index 0000000..42e066e --- /dev/null +++ b/doc/rfc/rfc2489.txt @@ -0,0 +1,283 @@ + + + + + + +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 + +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. + +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." + + 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. + +1. Introduction + + 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] + + This document describes the procedure for defining new DHCP options. + The procedure will guarantee that: + + * 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. + + + +Droms Best Current Practice [Page 1] + +RFC 2489 Defining New DCHP Options January 1999 + + + 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. + +2. Overview and background + + 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. + + 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 + + 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. + + 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. + + 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 + + + + +Droms Best Current Practice [Page 2] + +RFC 2489 Defining New DCHP Options January 1999 + + + 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. + +3. Procedure + + 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: + + 1. The author devises the new option. + + 2. The author documents the new option, leaving the option code as + "To Be Determined" (TBD), as an Internet Draft. + + 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. + + 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. + + 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. + + 5. At the time of publication as an RFC, IANA assigns a DHCP option + number to the new option. + +4. References + + [1] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, + March 1997. + + [2] Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor + Extensions", RFC 2132, March 1997. + + + +Droms Best Current Practice [Page 3] + +RFC 2489 Defining New DCHP Options January 1999 + + + [3] Droms, R. and K. Fong, "NetWare/IP Domain Name and Information", + RFC 2142, November 1997. + + [4] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA + Considerations Section in RFCs", BCP 26, RFC 2434, October 1998. + +5. Security Considerations + + 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 currently provides no authentication or security mechanisms. + Potential exposures to attack are discussed in section 7 of the + DHCP protocol specification [RFC 2131]. + +6. IANA Considerations + + 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]. + +7. Author's Address + + Ralph Droms + Computer Science Department + 323 Dana Engineering + Bucknell University + Lewisburg, PA 17837 + + Phone: (717) 524-1145 + EMail: droms@bucknell.edu + + + + + + + + + + +Droms Best Current Practice [Page 4] + +RFC 2489 Defining New DCHP Options January 1999 + + +8. Full Copyright Statement + + Copyright (C) The Internet Society (1999). All Rights Reserved. + + 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. + + + + + + + + + + + + + + + + + + + + + + + + +Droms Best Current Practice [Page 5] + -- cgit v1.2.3