RFC 2489

RFC 2489: Procedure for Defining New DHCP Options 🎀

okay so this is BCP 29 (Best Current Practice 💅), written by Ralph Droms of Bucknell University, dated January 1999. It's a Best Current Practice doc, not a standard, and it's the official how-to for getting a brand new DHCP option approved. It modifies and clarifies the option-definition procedure in RFC 2131 (Section 2), and it updates and replaces the IANA instructions in RFC 2132 (Section 6). Nothing in the title block says it obsoletes anything. 🦋

---

Status of this Memo ✨

this doc is an Internet Best Current Practice for the Internet Community, and it's asking for discussion and suggestions for improvements 🗣️. distribution is totally unlimited, so share it with everyone 💖

Copyright Notice 🌸

Copyright (C) The Internet Society (1999). All Rights Reserved. 🔒

Abstract 📝

the Dynamic Host Configuration Protocol (DHCP) is basically the framework for passing configuration info to hosts on a TCP/IP network 🌐. config parameters and other control info ride along in tagged data items stored in the options field of the DHCP message. those data items are literally called "options" 🎀

new DHCP options can be defined after the DHCP spec gets published, so they can handle new config parameters that show up later 🧚. this doc explains the procedure for defining them ✨

1. Introduction 💅

okay so DHCP [1] is the framework for passing config info to hosts on a TCP/IP network. the params and control info are carried in tagged data items stored in the 'options' field of the DHCP message, and those items are called "options." [2] 🎀

this doc describes how to define new DHCP options, and the procedure guarantees three things, bestie 👑:

• allocation of new option numbers is coordinated from a single authority,
• new options get reviewed for technical correctness and appropriateness, and
• documentation for new options is complete and published.

as "Guidelines for Writing an IANA Considerations Section in RFCs" (see references) explains, IANA is the central authority for assigning numbers like DHCP option codes 🔢. the new procedure in this doc gives IANA guidance on assigning new option codes, so it's giving organized 💜

2. Overview and background 🌈

the procedure here modifies and clarifies how RFC 2131 [2] tells you to define new options. the big change is when a new option gets its number. under this procedure, the option number isn't assigned until the spec for that option is about to be published as an RFC ⏰ (not earlier, not whenever, specifically then 🙈)

since RFC 2132 came out, the option number space for publically defined DHCP options (1-127) is basically almost used up 😭. a bunch of the defined option numbers never got followed up with Internet Drafts submitted to the DHC WG. there's also been a lack of specific guidance from the DHC WG to IANA on assigning DHCP option numbers

the procedure in RFC 2132 doesn't clearly say new options get reviewed one by one for technical correctness, appropriateness, and complete documentation. RFC 2132 also doesn't require new options to be submitted to the IESG for review, and it doesn't say the author of an option spec is responsible for bringing the option to the IESG's attention. and finally, RFC 2132 doesn't make it clear that newly defined options aren't supposed to be built into products, included in other specs, or otherwise used until the option's spec gets published as an RFC 🚫

going forward, new DHCP option codes get assigned by IETF consensus ✨. new options will be documented in RFCs approved by the IESG, and their codes get assigned when those RFCs are published. usually the IESG asks for input on prospective assignments from the right sources (for example, a relevant Working Group, if there is one) 🧠. groups of related options can be combined into a single spec and reviewed together as a set by the IESG 🫶. and before an option code is assigned, it's not appropriate to build new options into products, include the spec in other docs, or use the new options in any way 💀

the DHCP option number space (1-254) is split into two parts. the site-specific options (128-254) are defined as "Private Use," and they don't need DHC WG review 🏠. the public options (1-127) are defined as "Specification Required," so new options must be reviewed before IANA assigns an option number 🔍. the details of the review process are in the next section 👀

3. Procedure 📋

the author of a new DHCP option follows these steps to get approval for the option and get the option's spec published as an RFC 🎀:

1. the author devises the new option. 💡
2. the author documents the new option as an Internet Draft, with the option code left as "To Be Determined" (TBD).

the Internet Draft requirement is just for convenience 🙃. in theory you could write the option down on the back of an envelope and submit that, but in practice the spec will end up as an Internet Draft during review anyway 📮

3. the author submits the Internet Draft for review by the IESG. ideally the author submits it to the DHC Working Group, but the author can also submit it straight to the IESG 📬.

⚠️ just publishing the new option as an Internet Draft does not automatically bring it to the IESG's attention. the author has to explicitly forward a request for action on the new option to the DHC WG or the IESG 🙅‍♀️

4. the IESG reviews the spec for the new option. the DHC WG (if it exists) or the IETF also reviews it. if the option gets accepted for inclusion in the DHCP spec, the spec is published as an RFC 🎉. it can be published as a standards-track RFC or a non-standards-track RFC 🌸
5. when the RFC is published, 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.

[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 🔐

ok this section is serious, bestie 😤. information that creates or updates an option number assignment needs to be authenticated 🔑. no skipping this!!

an analysis of security issues is required for every newly defined DHCP option 💀. the description of security issues in a new option's spec must be as accurate as possible 🙏. a new option's spec can reference the "Security Considerations" section of the DHCP spec [1]. for example, the "NetWare/IP Domain Name and Information" [3] spec says:

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 gave IANA guidance on how to assign option numbers for new DHCP options. this doc updates and replaces those instructions 🔄. specifically, IANA is asked to assign DHCP option numbers only for options that have been approved for publication as RFCs, meaning documents 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

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.

---

the end, bestie 🌈💖✨