RFC 2939

Procedures and IANA Guidelines for Definition of New DHCP Options and Message Types

📅 published September 2000, from ietf

Network Working Group 🎀 Request for Comments: 2939, also known as RFC 2939, which makes it a total main character ✨

  • Category: Best Current Practice (BCP: 43) 💅
  • Author: Ralph Droms (R. Droms), Bucknell University 🎓
  • Date: September 2000 📅
  • Obsoletes: 2489 🪦

Title: Procedures and IANA Guidelines for Definition of New DHCP Options and Message Types 🦋

Status of this Memo ✨

okay so this bit is the official disclaimer 💅 This document is a Best Current Practice for the Internet Community, and it's asking everyone for discussion and suggestions for improvements 🫶 Distribution of this memo is unlimited, so share it with everyone 🌈

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

Abstract 🌸

okay so DHCP (Dynamic Host Configuration Protocol) gives configuration info to hosts on a Transmission Control Protocol/Internet Protocol (TCP/IP) network 🖥️ The config stuff and other control info live in tagged data items stored in the 'options' field of the DHCP message, and those data items are also called "options" 🍓

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 that 'DHCP Message Type' option 👑

New DHCP options and message types may be defined after the DHCP spec gets published, so we can carry new config parameters or support new protocol semantics 🧚 This document describes the procedure for defining new DHCP options and message types 💖

1. Introduction ✨

The Dynamic Host Configuration Protocol (DHCP) [1] gives hosts configuration info over a TCP/IP network 🌈 Config parameters and other control info are carried in tagged data items stored in the 'options' field of the DHCP message, and those data items are also called "options" [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 🦋

This document is the procedure for defining new DHCP options and message types, and it's giving organized 💜 The procedure will guarantee that:

  • 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 assigning numbers like DHCP option and message type codes 🧾 The new procedure in this document gives IANA guidance on assigning new option and message type codes 💖

This document updates and replaces RFC 2489 🦋

2. Overview and background 🌸

This document specifies procedures for defining new option codes and message types 💅

2.1. New DHCP option codes 🍓

The procedure in this document modifies and clarifies the procedure for defining new options in RFC 2131 [2] 😭 The big change is when a new DHCP option gets its option number: it's not assigned until the spec for the option is about to be published as an RFC ✨

Since RFC 2132 came out, the option number space for publicly defined DHCP options (1-127) has almost been exhausted 💀 A lot of the defined option numbers were never 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 about assigning DHCP option numbers 😤

The procedure in RFC 2132 doesn't clearly say that 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, or say that the author of an option spec is responsible for bringing it to the IESG's attention 🙃 And finally, RFC 2132 doesn't make it clear that newly defined options are not to be put into products, included in other specs, or otherwise used until the option's spec 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 their codes will be assigned when the relevant RFCs are published 🦋 Usually the IESG will ask for input on prospective assignments from appropriate sources (for example, 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 🧩 Before an option code is assigned, it is not appropriate to put new options into products, include the spec in other documents, or otherwise use the new options 🛑

The DHCP option number space (1-254) is split into two parts 🍰 The site-specific option codes (128-254) are defined as "Private Use" and need no review by the DHC WG 🔒 Site-specific option codes (128-254) MUST NOT be defined for use by any publicly distributed DHCP server, client or relay agent implementations 🚨 These codes are explicitly reserved for private definition and use within a site or an organization 🏠

The public option codes (0-127, 255) are defined as "Specification Required", and new options must be reviewed before IANA assigns an option number 🔍 The details of the review process are in the next section of this document 📖

2.2. New DHCP message types 🧚

RFC 2131 doesn't 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 their codes will be assigned when the relevant RFCs are published 🌈

Usually the IESG will ask for input on new message types from appropriate sources (for example, a relevant Working Group if one exists) 🫶 Before a message type code is assigned, it is not appropriate to put new message types into products, include the spec in other documents, or otherwise use them 🚫

3. Procedure 💅

The author of a new DHCP option or message type follows these steps to get approval for the option and get the spec published as an RFC 🎀

  1. The author devises the new option or message type. 💡
  2. The author documents the new option or message type as an Internet Draft, leaving the option code or message type code as "To Be Determined" (TBD) 📝

Requiring an Internet Draft is a matter of expediency 🙃 In theory the new option or message type could be written on the back of an envelope for submission 😂 In practice the spec will become an Internet Draft as part of the review process anyway 🦋

  1. The author submits the Internet Draft for review by the IESG 📬 Ideally the author submits it to the DHC Working Group, but they can submit it directly to the IESG if they want 🫶

Just publishing the new option or message type as an Internet Draft does NOT automatically bring it to the IESG's attention, so the author has to explicitly forward a request for action on the new option to the DHC WG or the IESG 👀

  1. The IESG reviews the spec for the new option or message type 🔍 The spec 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, it gets published as an RFC 🎉 It may be published as either a standards-track or a non-standards-track RFC 💜
  2. When it's published as an RFC, IANA assigns a DHCP option code or message type code to the new option or message type 🥳

Okay bestie, this is the legal bit 📜 so I'm keeping the wording exactly as written, because the permissions and disclaimers only work if the words stay the same 💅

Copyright (C) The Internet Society (2000). 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. 💀

Acknowledgement 🫶

Funding for the RFC Editor function is currently provided by the Internet Society. 💜

📦 where this page comes from