RFC 4039
Rapid Commit Option for the Dynamic Host Configuration Protocol version 4 (DHCPv4)
RFC 4039: Rapid Commit Option for DHCPv4 🎀
okay bestie, let's get into it ✨ This one is RFC 4039, titled Rapid Commit Option for the Dynamic Host Configuration Protocol version 4 (DHCPv4). It's a Standards Track doc from March 2005 🦋 The authors are S. Park and P. Kim from SAMSUNG Electronics, plus B. Volz from Cisco Systems. It's filed under the Network Working Group. The header doesn't list anything it obsoletes or updates, so there's no old RFC it's replacing or patching 💅
Status of This Memo ✨
This document specifies an Internet standards track protocol for the Internet community, and it's asking for discussion and suggestions for improvements 🌸 To find out where this protocol stands in standardization, check the current edition of the "Internet Official Protocol Standards" (STD 1). Distribution of this memo is unlimited.
Copyright Notice 💜
Copyright (C) The Internet Society (2005).
Abstract 🔥
This doc defines a brand new DHCPv4 option, modeled on the DHCPv6 Rapid Commit option. Its whole purpose is to get IP address and config info using a 2-message exchange instead of the usual 4-message exchange, so client setup goes way faster 🏃♀️💨
Table of Contents 🧚
1. Introduction................................................... 2
2. Requirements................................................... 2
3. Client/Server Operations....................................... 2
3.1. Detailed Flow............................................ 3
3.2. Administrative Considerations............................ 6
4. Rapid Commit Option Format..................................... 7
5. IANA Considerations............................................ 7
6. Security Considerations........................................ 7
7. References..................................................... 7
7.1. Normative References..................................... 7
7.2. Informative References................................... 8
8. Acknowledgements............................................... 8
Authors' Addresses................................................ 9
Full Copyright Statement.......................................... 101. Introduction 🦋
okay so picture environments with lots of high mobility, where the network attachment point keeps changing 🚗💨 In those places, it's really useful to configure clients fast. And here's the thing: the protections from the normal (and longer) 4-message exchange might not even be needed there, so the speed-up is lowkey worth it ✨
The 4-message exchange is honestly iconic for one reason: redundancy. You can have multiple DHCP servers without wasting addresses, because addresses only get provisionally assigned to a client until the client picks one of them and requests it 🫶 The 2-message exchange can be used when there's only one server around, or when addresses are plentiful and having several servers commit addresses for the same client isn't a problem 🌈
This document adds a new Rapid Commit option for DHCPv4, modeled on the DHCPv6 Rapid Commit option [RFC3315]. It's how you kick off that 2-message exchange to speed up client config in certain environments 🎀 Here's the flow: a client advertises that it supports the option by sending it in DHCPDISCOVER messages. The server then decides whether to allow the 2-message exchange based on its configuration info. It can either handle the DHCPDISCOVER the usual way, as defined in [RFC2131], or it can commit the client's configuration info and move on to sending a DHCPACK message that carries the Rapid Commit option, as defined here 💅
2. Requirements 💖
The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL, when they appear in this document, are to be interpreted as described in [RFC2119] 🙈
3. Client/Server Operations 🍓
If a client that supports the Rapid Commit option wants to use the rapid commit capability, it includes a Rapid Commit option in the DHCPDISCOVER messages it sends. The client MUST NOT include it in any other messages. A client and server only use this option when they're configured to do so 🔥
A client that sent a DHCPDISCOVER with the Rapid Commit option still processes responses as described in [RFC2131]. But here's the twist: if the client receives a DHCPACK message with a Rapid Commit option, it SHOULD process that DHCPACK immediately, without waiting for any additional DHCPOFFER or DHCPACK messages, and use the address and configuration info inside it 👑
A server that supports the Rapid Commit option MAY respond to a DHCPDISCOVER that included the Rapid Commit option with a DHCPACK that includes the Rapid Commit option and fully committed address and configuration info. A server MUST NOT include the Rapid Commit option in any other messages. 🧚
The Rapid Commit option MUST NOT appear in a Parameter Request List option [RFC2132]. 🚫
All other DHCP operations are as documented in [RFC2131] 🌸
3.1. Detailed Flow ✨
okay so this part is revised from Section 3.1 of [RFC2131], and it's where Rapid Commit gets its own moment 💅 here's the whole flow, step by step:
- bestie, the client broadcasts a DHCPDISCOVER message on its local physical subnet 🦋 If the client supports the Rapid Commit option and intends to use the rapid commit capability, it includes a Rapid Commit option in the DHCPDISCOVER message. The DHCPDISCOVER message MAY include options that suggest values for the network address and lease duration. BOOTP relay agents may pass the message on to DHCP servers not on the same physical subnet.
- Each server may respond with either a DHCPOFFER message or a DHCPACK message with the Rapid Commit option. The DHCPACK one only happens if the DHCPDISCOVER had a Rapid Commit option and the server's configuration policies allow Rapid Commit, so no cap, it's a two-part check 🔥 Both of these come with an available network address in the 'yiaddr' field, plus the other configuration parameters in DHCP options. Servers sending a DHCPOFFER need not reserve the offered network address, although the protocol will work more efficiently if the server avoids allocating the offered address to another client 🌸 Servers sending the DHCPACK message commit the binding for the client to persistent storage before sending the DHCPACK. The combination of 'client identifier' or 'chaddr' and the assigned network address makes a unique identifier for the client's lease, and both the client and server use it to identify that lease in any DHCP messages 🫶 The server transmits the DHCPOFFER or DHCPACK message to the client, using the BOOTP relay agent if necessary.
When allocating a new address, servers SHOULD check that the offered network address is not already in use. For example, the server may probe the offered address with an ICMP Echo Request 👀
Servers SHOULD be implemented so that network administrators MAY choose to disable probes of newly allocated addresses 🎀
Figure 3 in [RFC2131] shows the flow for the normal 4-message exchange. Figure 1 below shows the 2-message exchange.
Server Client Server
(not selected) (selected)
v v v
| | |
| Begins initialization |
| | |
| _____________/|\____________ |
|/DHCPDISCOVER | DHCPDISCOVER \|
| w/Rapid Commit| w/Rapid Commit|
| | |
Determines | Determines
configuration | configuration
| | Commits configuration
| Collects replies |
|\ | ____________/|
| \________ | / DHCPACK |
| DHCPOFFER\ |/w/Rapid Commit|
| (discarded) | |
| Initialization complete |
| | |
. . .
. . .
| | |
| Graceful shutdown |
| | |
| |\_____________ |
| | DHCPRELEASE \|
| | |
| | Discards lease
| | |
v v vFigure 1 Timeline diagram when Rapid Commit is used
- The client receives one or more DHCPOFFER or DHCPACK messages (a DHCPACK only if the Rapid Commit option was sent in the DHCPDISCOVER) from one or more servers 📬 If a DHCPACK with the Rapid Commit option comes in, the client may immediately jump ahead to step 5 below, as long as the offered configuration parameters are acceptable ✨ The client may choose to wait for multiple responses. Then it picks one server to request or accept configuration parameters from, based on what the DHCPOFFER and DHCPACK messages offered. If the client picks a DHCPACK, it advances to step 5. Otherwise, the client broadcasts a DHCPREQUEST message that MUST include the 'server identifier' option to say which server it picked. The message MAY include other options that specify desired configuration values. The 'requested IP address' option MUST be set to the value of 'yiaddr' from the DHCPOFFER message from that server 💖 This DHCPREQUEST is broadcast and relayed through DHCP/BOOTP relay agents. To help make sure the relay agents forward the DHCPREQUEST to the same set of DHCP servers that got the original DHCPDISCOVER, the DHCPREQUEST MUST use the same value in the DHCP message header's 'secs' field, and it MUST be sent to the same IP broadcast address as the original DHCPDISCOVER 🧚 The client times out and retransmits the DHCPDISCOVER message if it gets no DHCPOFFER messages.
- The servers receive the DHCPREQUEST broadcast from the client 👂 Servers that weren't selected treat the message as notice that the client turned down their offers. The server that was selected commits the binding for the client to persistent storage and responds with a DHCPACK message that contains the configuration parameters for the requesting client. Same deal as before: the combination of 'client identifier' or 'chaddr' and the assigned network address is the unique identifier for the lease, used by both sides in any DHCP messages. Any configuration parameters in the DHCPACK SHOULD NOT conflict with the earlier DHCPOFFER the client is responding to. The server SHOULD NOT check the offered network address at this point. The 'yiaddr' field in the DHCPACK messages gets filled in with the selected network address 🌈
If the selected server can't satisfy the DHCPREQUEST (for example, the requested address has already been allocated), the server SHOULD respond with a DHCPNAK message 💀
A server MAY choose to mark addresses offered to clients in DHCPOFFER messages as unavailable. The server SHOULD mark an address offered to a client in a DHCPOFFER message as available again if it receives no DHCPREQUEST message from that client 🍓
- The client receives the DHCPACK message with the configuration parameters 🎉 The client SHOULD perform a final check on the parameters (for example, ARP for the allocated network address), and it notes the lease duration given in the DHCPACK message. At this point, the client is configured, periodt 👑 If the client detects that the address is already in use (for example, through ARP), the client MUST send a DHCPDECLINE message to the server, and it restarts the configuration process. The client SHOULD wait a minimum of ten seconds before restarting the configuration process, so it doesn't create excessive network traffic if things loop 😭
If the client receives a DHCPNAK message, the client restarts the configuration process 🙈
The client times out and retransmits the DHCPREQUEST message if it receives neither a DHCPACK nor a DHCPNAK message. It does this according to the retransmission algorithm in section 4.1 of [RFC2131]. The client should choose to retransmit the DHCPREQUEST enough times to give an adequate chance of reaching the server, without making the client (and the person using it) wait too long before giving up. For example, a client retransmitting as described in section 4.1 of [RFC2131] might retransmit the DHCPREQUEST message four times, for a total delay of 60 seconds, before restarting the initialization procedure. If the client receives neither a DHCPACK nor a DHCPNAK message after using the retransmission algorithm, the client reverts to INIT state and restarts the initialization process. The client SHOULD notify the user that initialization has failed and is restarting 🫣
- The client may choose to give up its lease on a network address by sending a DHCPRELEASE message to the server 👋 It identifies the lease to be released with its 'client identifier' or 'chaddr' and network address in the DHCPRELEASE message. If the client used a 'client identifier' when it got the lease, it MUST use the same 'client identifier' in the DHCPRELEASE message 🌸
3.2. Administrative Considerations
Okay, this part is for the network admins 🧑💻 Network administrators MUST only enable the use of Rapid Commit on a DHCP server if one of the following conditions is met:
- The server is the only server for the subnet.
- When multiple servers are present, they may each commit a binding for all clients, so each server must have sufficient addresses available.
A server MAY allow configuration for a different (likely shorter) initial lease time for addresses assigned when Rapid Commit is used, so unused addresses can be reclaimed faster 🧹
4. Rapid Commit Option Format ✨
The Rapid Commit option is used to indicate the use of the two-message exchange for address assignment 🦋 The code for the Rapid Commit option is 80. The format of the option is:
Code Len
+-----+-----+
| 80 | 0 |
+-----+-----+A client MUST include this option in a DHCPDISCOVER message if the client is prepared to perform the DHCPDISCOVER-DHCPACK message exchange described earlier 💅
A server MUST include this option in a DHCPACK message sent in response to a DHCPDISCOVER message when it completes the DHCPDISCOVER-DHCPACK message exchange 🫶
5. IANA Considerations 📋
IANA has assigned value 80 for the Rapid Commit option code in accordance with [RFC2939] 🌈
6. Security Considerations 🚨
bestie, read this part carefully 😭🔥
The concepts in this document do not significantly alter the security considerations for DHCP (see [RFC2131] and [RFC3118]). However, use of this option could expedite denial of service attacks by allowing a mischievous client to consume all available addresses more rapidly, or to do so without requiring two-way communication. Injecting DHCPDISCOVER messages with the Rapid Commit option is enough to cause a server to allocate an address, and that's the whole scary part 💀
7. References 📚
7.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2131] Droms, R., "Dynamic Host Configuration Protocol", RFC
2131, March 1997.7.2. Informative References 📚
okay these are the bonus reads, bestie 🧚 they're not required but they give you the full backstory on how DHCP got this cute
[RFC2132] Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor Extensions", RFC 2132, March 1997.
[RFC2939] Droms, R., "Procedures and IANA Guidelines for Definition of New DHCP Options and Message Types", BCP 43, RFC 2939, September 2000.
[RFC3118] Droms, R. and W. Arbaugh, "Authentication for DHCP Messages", RFC 3118, June 2001.
[RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., and M. Carney, "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", RFC 3315, July 2003.
8. Acknowledgements 🫶
Special thanks to Ted Lemon and Andre Kostur for their many valuable comments 💖 Thanks to Ralph Droms for his review comments during WGLC 🙌 Thanks to Noh-Byung Park and Youngkeun Kim for their supports on this work ✨
Particularly, the authors would like to acknowledge the implementation contributions by Minho Lee of SAMSUNG Electronics 👑
Authors' Addresses 🦋
Soohong Daniel Park
Mobile Platform Laboratory
SAMSUNG Electronics
416, Maetan-3dong, Yeongtong-Gu
Suwon, Korea
Phone: +82-31-200-4508
EMail: soohong.park@samsung.comPyungsoo Kim
Mobile Platform Laboratory
SAMSUNG Electronics
416, Maetan-3dong, Yeongtong-Gu
Suwon, Korea
Phone: +82-31-200-4635
EMail: kimps@samsung.comBernie Volz
Cisco Systems, Inc.
1414 Massachusetts Ave.
Boxborough, MA 01719
USA
Phone: +1-978-936-0382
EMail: volz@cisco.comFull Copyright Statement 🎀
Copyright (C) The Internet Society (2005).
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM 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.
Intellectual Property 💜
okay so the IETF isn't picking a side on who owns what 🙃 it takes no position on whether any Intellectual Property Rights or other rights might apply to the tech in this document, or whether any license for them is available. It also doesn't claim it went looking for those rights itself. If you want the details on how rights work for RFC documents, check out BCP 78 and BCP 79 📖
Copies of IPR disclosures sent to the IETF Secretariat, plus any assurances of licenses, or the results of trying to get a general license or permission for implementers or users, can be found in the IETF online IPR repository at http://www.ietf.org/ipr 🔍
The IETF also invites anyone to flag any copyrights, patents, patent applications, or other proprietary rights that might cover technology needed to implement this standard. Send that info to the IETF at ietf-ipr@ietf.org 💌
Acknowledgement 🌈
Funding for the RFC Editor function is currently provided by the Internet Society 💅✨
📦 where this page comes from
- ietf: rfc4039 2005-03
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms