Rapid Commit Option for the Dynamic Host Configuration Protocol version 4 (DHCPv4)
Extracted elements (20)
The 2-message exchange is appropriate in environments with high client mobility and frequent attachment-point changes, where the protections of the 4-message exchange (avoiding address waste with multiple servers) may not be needed. It is safe when only one server is present or when addresses are plentiful.
The Rapid Commit option for DHCPv4 is explicitly modeled on the DHCPv6 Rapid Commit option (RFC 3315), bringing equivalent 2-message exchange capability to DHCPv4.
A server MAY allow configuration for a shorter initial lease time for addresses assigned via Rapid Commit, to expedite reclaiming addresses not used by clients.
A server that receives a DHCPDISCOVER with Rapid Commit MAY respond with either a normal DHCPOFFER (falling back to 4-message exchange) or a DHCPACK with Rapid Commit (2-message exchange), based on its configuration policies. Both paths are valid; the client handles either.
A client MUST include the Rapid Commit option in a DHCPDISCOVER message if it is prepared to perform the 2-message DHCPDISCOVER-DHCPACK exchange.
A client MUST NOT include the Rapid Commit option in any DHCP message other than DHCPDISCOVER.
A server MUST include the Rapid Commit option in a DHCPACK message when completing the DHCPDISCOVER-DHCPACK 2-message exchange.
A server MUST NOT include the Rapid Commit option in any message other than a DHCPACK sent in response to a DHCPDISCOVER that contained the Rapid Commit option.
If a client detects that the allocated address is already in use (e.g., via ARP), the client MUST send a DHCPDECLINE message to the server and restart the configuration process.
If a client receives a DHCPACK with the Rapid Commit option, it SHOULD process it immediately (without waiting for additional DHCPOFFER or DHCPACK messages) and use the address and configuration information contained therein.
If a client used a 'client identifier' when it obtained the lease, it MUST use the same 'client identifier' in the DHCPRELEASE message.
Network administrators MUST only enable Rapid Commit on a DHCP server if either the server is the only server for the subnet, or multiple servers are present and each can commit a binding for all clients with sufficient addresses available.
Servers sending a DHCPACK in the rapid commit flow MUST commit the binding for the client to persistent storage before sending the DHCPACK.
The Rapid Commit option MUST NOT appear in a Parameter Request List option.
In the rapid commit 2-message exchange, a server responds to DHCPDISCOVER (with Rapid Commit) with a DHCPACK that includes a Rapid Commit option and fully committed address and configuration information, bypassing the DHCPOFFER/DHCPREQUEST steps.
The Rapid Commit option (code 80, length 0) is a new DHCPv4 option that signals willingness to use the 2-message exchange (DHCPDISCOVER + DHCPACK) instead of the normal 4-message exchange. It has no data payload beyond the code and length fields.
IANA assigned option code 80 to the Rapid Commit option for DHCPv4, in accordance with RFC 2939 procedures for new DHCP option codes.
Use of the Rapid Commit option can expedite denial-of-service attacks: a mischievous client can consume all available addresses more rapidly, or do so without requiring two-way communication, since injecting DHCPDISCOVER messages with Rapid Commit is sufficient to cause a server to allocate an address.
In the 2-message flow, the client broadcasts DHCPDISCOVER with Rapid Commit option; if it receives a DHCPACK with Rapid Commit, it may immediately advance to the configured state (step 5), skipping DHCPREQUEST and the normal DHCPOFFER selection steps. If no rapid-commit DHCPACK is received, the normal 4-message exchange proceeds.
The Rapid Commit option encoding is: Code=80 (1 octet), Len=0 (1 octet), with no value bytes. It is the shortest possible DHCP option form.