RFC 1531
Dynamic Host Configuration Protocol
Dynamic Host Configuration Protocol 🎀 RFC 1531, a Standards Track doc from R. Droms at Bucknell University, dated October 1993. The header doesn't list anything it obsoletes or updates, so it's a clean start 💖
Status of this memo 🦋
Okay so this RFC is an Internet standards track protocol for the Internet community, and it's asking for discussion and suggestions for improvements 🫶 For the current standardization state and status of this protocol, check the current edition of the "Internet Official Protocol Standards." Distribution of this memo is unlimited, so share it with everyone 🌈
Abstract ✨
Okay bestie, this is the main vibe. The Dynamic Host Configuration Protocol (DHCP) gives you a framework for passing configuration info to hosts on a TCP/IP network 💅 It's based on BOOTP [7] and adds automatic allocation of reusable network addresses plus extra configuration options [19]. DHCP also captures how BOOTP relay agents behave [7, 23], and DHCP participants can interoperate with BOOTP participants [9]. Iconic, honestly 👑
Table of Contents 📚
Table of Contents
1. Introduction. . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1 Related Work. . . . . . . . . . . . . . . . . . . . . . . . . 4
1.2 Problem definition and issues . . . . . . . . . . . . . . . . 4
1.3 Requirements. . . . . . . . . . . . . . . . . . . . . . . . . 5
1.4 Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6
1.5 Design goals. . . . . . . . . . . . . . . . . . . . . . . . . 6
2. Protocol Summary . . . . . . . . . . . . . . . . . . . . . . . 8
2.1 Configuration parameters repository . . . . . . . . . . . . . 10
2.2 Dynamic allocation of network addresses . . . . . . . . . . . 11
3. The Client-Server Protocol . . . . . . . . . . . . . . . . . . 11
3.1 Client-server interaction - allocating a network address. . . 12
3.2 Client-server interaction - reusing a previously allocated
network address . . . . . . . . . . . . . . . . . . . . . . . 17
3.3 Interpretation and representation of time values. . . . . . . 19
3.4 Host parameters in DHCP . . . . . . . . . . . . . . . . . . . 19
3.5 Use of DHCP in clients with multiple interfaces . . . . . . . 20
3.6 When clients should use DHCP. . . . . . . . . . . . . . . . . 20
4. Specification of the DHCP client-server protocol . . . . . . . 21
4.1 Constructing and sending DHCP messages. . . . . . . . . . . . 21
4.2 DHCP server administrative controls . . . . . . . . . . . . . 23
4.3 DHCP server behavior. . . . . . . . . . . . . . . . . . . . . 24
4.3.1 DHCPDISCOVER message. . . . . . . . . . . . . . . . . . . . 24
4.3.2 DHCPREQUEST message . . . . . . . . . . . . . . . . . . . . 27
4.3.3 DHCPDECLINE message . . . . . . . . . . . . . . . . . . . . 29
4.3.4 DHCPRELEASE message . . . . . . . . . . . . . . . . . . . . 29
4.4 DHCP client behavior. . . . . . . . . . . . . . . . . . . . . 29
4.4.1 Initialization and allocation of network address. . . . . . 29
4.4.2 Initialization with known network address . . . . . . . . . 33
4.4.3 Initialization with a known DHCP server address . . . . . . 34
4.4.4 Reacquisition and expiration. . . . . . . . . . . . . . . . 34
4.4.5 DHCPRELEASE . . . . . . . . . . . . . . . . . . . . . . . . 35
5. Acknowledgments. . . . . . . . . . . . . . . . . . . . . . . . 35
6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 36
7. Security Considerations. . . . . . . . . . . . . . . . . . . . 37
8. Author's Address . . . . . . . . . . . . . . . . . . . . . . . 38
A. Host Configuration Parameters . . . . . . . . . . . . . . . . 39List of Figures 🌸
List of Figures
1. Format of a DHCP message . . . . . . . . . . . . . . . . . . . 9
2. Format of the 'flags' field. . . . . . . . . . . . . . . . . . 10
3. Timeline diagram of messages exchanged between DHCP client and
servers when allocating a new network address. . . . . . . . . 15
4. Timeline diagram of messages exchanged between DHCP client and
servers when reusing a previously allocated network address. . 18
5. State-transition diagram for DHCP clients. . . . . . . . . . . 31List of Tables 🍓
List of Tables
1. Description of fields in a DHCP message. . . . . . . . . . . . 14
2. DHCP messages. . . . . . . . . . . . . . . . . . . . . . . . . 16
3. Fields and options used by DHCP servers. . . . . . . . . . . . 25
4. Fields and options used by DHCP clients. . . . . . . . . . . . 321. Introduction ✨
DHCP gives configuration parameters to Internet hosts 🧚 It has two parts: a protocol for delivering host-specific configuration parameters from a DHCP server to a host, and a mechanism for allocating network addresses to hosts.
It's built on a client-server model, where designated DHCP server hosts hand out network addresses and deliver configuration parameters to dynamically configured hosts. In the rest of this document, "server" means a host providing initialization parameters through DHCP, and "client" means a host requesting initialization parameters from a DHCP server.
A host should not act as a DHCP server unless a system administrator explicitly configures it to do so 🙈 The Internet has so much hardware and protocol diversity that reliable operation would be impossible if random hosts answered DHCP requests. IP, for example, needs many parameters set inside the protocol software. Because IP runs on many dissimilar kinds of network hardware, those values can't be guessed or assumed to have correct defaults. Distributed address allocation schemes also depend on a polling and defense mechanism to discover addresses already in use. IP hosts may not always be able to defend their addresses, so a scheme like that can't be guaranteed to avoid handing out duplicate addresses 💀
DHCP supports three mechanisms for IP address allocation 🦋 With automatic allocation, DHCP assigns a permanent IP address to a host. With dynamic allocation, DHCP assigns an IP address to a host for a limited period of time (or until the host explicitly gives it up). With manual allocation, the network administrator assigns a host's IP address, and DHCP is only used to convey that address to the host. A given network can use one or more of these, depending on the administrator's policies.
Dynamic allocation is the only one of the three that allows automatic reuse of an address the host no longer needs 👑 That makes it great for hosts that are only connected temporarily, or for sharing a limited pool of IP addresses among a group of hosts that don't need permanent ones. It's also a solid pick for a new permanently connected host on a network where IP addresses are scarce, since you can reclaim them when old hosts retire. Manual allocation lets DHCP replace the error-prone process of manually configuring hosts with IP addresses, in environments where, for whatever reasons, you want to manage IP address assignment outside of DHCP.
The format of DHCP messages is based on the format of BOOTP messages 💖 That way it captures the BOOTP relay agent behavior described in the BOOTP specification [7, 23], and existing BOOTP clients can work with DHCP servers. Using BOOTP relay agents means you don't need a DHCP server on every physical network segment 🫶
1.1 Related Work 🌈
Several Internet protocols and related mechanisms cover parts of the dynamic host configuration problem, so let's check the squad 👯♀️ The Reverse Address Resolution Protocol (RARP) [10] (and its extensions in Dynamic RARP (DRARP) [5]) explicitly addresses network address discovery and includes an automatic IP address assignment mechanism. The Trivial File Transfer Protocol (TFTP) [20] transports a boot image from a boot server. The Internet Control Message Protocol (ICMP) [16] tells hosts about additional routers through "ICMP redirect" messages. ICMP can also give subnet mask info through the "ICMP mask request" message, and other info through the (obsolete) "ICMP information request" message. Hosts can find routers through the ICMP router discovery mechanism [8].
BOOTP is a transport mechanism for a collection of configuration information. It's extensible too, and official extensions [17] exist for several configuration parameters. Morgan has proposed extensions to BOOTP for dynamic IP address assignment [15]. The Network Information Protocol (NIP), used by the Athena project at MIT, is a distributed mechanism for dynamic IP address assignment [19]. The Resource Location Protocol RLP [1] provides location of higher level services. Sun Microsystems diskless workstations use a boot procedure that combines RARP, TFTP and an RPC mechanism called "bootparams" to deliver configuration info and operating system code to diskless hosts. (Sun Microsystems, Sun Workstation and SunOS are trademarks of Sun Microsystems, Inc.) Some Sun networks also use DRARP and an auto-installation mechanism to automate configuring new hosts in an existing network 🌸
In other related work, the path minimum transmission unit (MTU) discovery algorithm can determine the MTU of an arbitrary internet path [14]. Comer and Droms have proposed using the Address Resolution Protocol (ARP) as a transport protocol for resource location and selection [6]. Finally, the Host Requirements RFCs [3, 4] mention specific requirements for host reconfiguration and suggest a scenario for initial configuration of diskless hosts 🧁
1.2 Problem definition and issues 💅
DHCP is designed to supply hosts with the configuration parameters defined in the Host Requirements RFCs ✨ After getting parameters through DHCP, a host should be able to exchange packets with any other host on the Internet. The parameters DHCP supplies are listed in Appendix A.
Not all of these parameters are needed for a newly initialized host 🙃 A client and server can negotiate to transmit only the parameters the client needs or that are specific to a particular subnet.
DHCP allows, but doesn't require, configuring host parameters that aren't directly related to the IP protocol. DHCP also doesn't handle registering newly configured hosts with the Domain Name System (DNS) [12, 13]. And DHCP is not intended for configuring routers, so don't go there bestie 🚫
Part 1 of 9 is done, so more is coming 💖 Stay tuned, we're just getting started 🧚
1.3 Requirements
okay bestie, so the capitalized words are doing the heavy lifting here 💅 every single one of these has a specific job, so I'm keeping them exactly as the spec wrote them:
- "MUST": this word, or the adjective "REQUIRED," means the item is an absolute requirement of the spec 🔥
- "MUST NOT": this phrase means the item is an absolute prohibition 🚫
- "SHOULD": this word, or the adjective "RECOMMENDED," means there can be valid reasons in certain situations to ignore the item. But you have to understand the full implications and really weigh things before you pick a different path 🤔
- "SHOULD NOT": this phrase means there can be valid reasons in certain situations where the listed behavior is acceptable or even useful. You still have to understand the full implications and carefully weigh the case before doing anything this label describes 🫶
- "MAY": this word, or the adjective "OPTIONAL," means the item is truly optional 🦋 one vendor might include it because a marketplace needs it or because it makes the product better, and another vendor might skip it totally, and both are fine ✨
1.4 Terminology
this document uses these terms, so let's get the vocab down 🎀
- "DHCP client": a DHCP client is an Internet host that uses DHCP to get configuration parameters, like a network address 💜
- "DHCP server": a DHCP server is an Internet host that sends configuration parameters back to DHCP clients 🧚
- "BOOTP relay agent": a BOOTP relay agent is an Internet host or router that passes DHCP messages between DHCP clients and DHCP servers. DHCP is designed to use the same relay agent behavior that's specified in the BOOTP protocol specification 🌸
- "binding": a binding is a collection of configuration parameters, including at least an IP address, that's associated with (or "bound to") a DHCP client. DHCP servers are the ones who manage bindings 👑
1.5 Design goals
the design goals for DHCP are giving major main character energy, so here's the list 💖
- DHCP should be a mechanism rather than a policy. DHCP must let local system administrators control configuration parameters wherever they want to. For example, local admins should be able to enforce their own policies about allocating and accessing local resources wherever that's needed 🔥
- Hosts should require no manual configuration. Each host should be able to find the right local configuration parameters without a user doing anything, and then fold those parameters into its own configuration 🌈
- Networks should require no hand configuration for individual hosts. In normal situations, the network manager shouldn't have to enter any per-host configuration parameters at all 🍓
- DHCP should not require a server on each subnet. To allow for scale and economy, DHCP must work across routers or through the help of BOOTP/DHCP relay agents 🦋
- A DHCP host must be prepared to receive multiple responses to a request for configuration parameters. Some setups might include multiple, overlapping DHCP servers to boost reliability and performance ✨
- DHCP must coexist with statically configured, non-participating hosts and with existing network protocol implementations 🫶
- DHCP must interoperate with the BOOTP relay agent behavior described by RFC 951 and by Wimer [21] 💅
- DHCP must provide service to existing BOOTP clients 🎀
The following list gives design goals that are specific to the transmission of the network layer parameters. DHCP must:
- Guarantee that any specific network address will not be in use by more than one host at a time 🔒
- Retain host configuration across host reboot. A host should, whenever possible, be assigned the same configuration parameters (e.g., network address) in response to each request 🧸
- Retain host configuration across server reboots. Whenever possible, a host should be assigned the same configuration parameters despite restarts of the DHCP mechanism 🌙
- Allow automatic assignment of configuration parameters to new hosts, so nobody has to hand-configure new hosts 🪄
- Support fixed or permanent allocation of configuration parameters to specific hosts 💎
2. Protocol Summary ✨
okay so from the client's point of view, DHCP is basically an extension of the BOOTP mechanism 🦋 that means existing BOOTP clients can talk to DHCP servers without needing any changes to their initialization software, which is iconic. A separate document details the interactions between BOOTP and DHCP clients and servers [9]. There are some new, optional transactions that make the interaction between DHCP clients and servers way smoother, and those are described in sections 3 and 4 💜
Figure 1 gives the format of a DHCP message, and table 1 describes each of the fields in the DHCP message 🎀 the numbers in parentheses show the size of each field in octets. The field names in the figure are the names used all throughout this document, so keep them in your back pocket 🧚
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| op (1) | htype (1) | hlen (1) | hops (1) |
+---------------+---------------+---------------+---------------+
| xid (4) |
+-------------------------------+-------------------------------+
| secs (2) | flags (2) |
+-------------------------------+-------------------------------+
| ciaddr (4) |
+---------------------------------------------------------------+
| yiaddr (4) |
+---------------------------------------------------------------+
| siaddr (4) |
+---------------------------------------------------------------+
| giaddr (4) |
+---------------------------------------------------------------+
| |
| chaddr (16) |
| |
| |
+---------------------------------------------------------------+
| |
| sname (64) |
+---------------------------------------------------------------+
| |
| file (128) |
+---------------------------------------------------------------+
| |
| options (312) |
+---------------------------------------------------------------+Figure 1: Format of a DHCP message
There are two big differences between DHCP and BOOTP 🔥 First, DHCP defines mechanisms that let clients get a network address for a fixed lease, which allows network addresses to be reassigned in series to different clients. Second, DHCP gives clients a way to acquire all of the IP configuration parameters they need in order to operate 💅
DHCP also brings in a small terminology change so the meaning of one of the fields is clearer 🌈 the "vendor extensions" field from BOOTP is now called the "options" field in DHCP. Likewise, the tagged data items that lived inside the BOOTP "vendor extensions" field, which used to be called "vendor extensions," are now just called "options" ✨
DHCP defines a new 'client identifier' option that passes an explicit client identifier to a DHCP server 🫶 this fixes the overloading of the 'chaddr' field in BOOTP messages, where it was being used for reply messages and as a client identifier, which was messy 💀 The 'client identifier' option can contain a hardware address, identical to the contents of the 'chaddr' field, or it can hold another type of identifier, like a DNS name. Other client identifier types may be defined as needed for use with DHCP. New client identifier types will be registered with the IANA [18] and will be included in new revisions of the Assigned Numbers document, and they'll also be described in detail in future revisions of the DHCP Options [2] 🍓
DHCP clarifies how the 'siaddr' field is interpreted: it's the address of the server to use in the next step of the client's bootstrap process 🧸 A DHCP server may return its own address in the 'siaddr' field, if the server is ready to supply the next bootstrap service (for example, delivering an operating system executable image). A DHCP server always returns its own address in the 'server identifier' option 🪄
The options field is now variable length, with the minimum extended to 312 octets. This brings the minimum size of a DHCP message up to 576 octets, which is the minimum IP datagram size a host must be prepared to accept [3] 🌙 DHCP clients may negotiate the use of larger DHCP messages through the 'Maximum DHCP message size' option. The options field may also be extended into the 'file' and 'sname' fields 💜
A new option, called 'vendor specific information', was added to allow more options to be supported [2] 🌸 Options encapsulated as 'vendor specific information' must be carefully defined and documented so that clients and servers from different vendors can interoperate 🔥 In particular, vendors defining 'vendor specific information' MUST document those options in the form of the DHCP Options document. They MUST choose to represent those options either in data types already defined for DHCP options or in other well-defined data types. They MUST also choose options that can be readily encoded in configuration files for exchange with servers provided by other vendors. Options included as 'vendor specific options' MUST be readily supportable by all servers 👑
1 1 1 1 1 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
B| MBZ |
-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+B: BROADCAST flag
MBZ: MUST BE ZERO (reserved for future use)
Figure 2: Format of the 'flags' field
DHCP uses the 'flags' field [21] 🦋 the leftmost bit is defined as the BROADCAST (B) flag. The semantics of this flag are discussed in section 4.1 of this document. The remaining bits of the flags field are reserved for future use. They MUST be set to zero by clients and ignored by servers and relay agents 🫶 Figure 2 gives the format of the
2.1 Configuration parameters repository ✨
okay so the first big job of DHCP is basically being a persistent storage locker for network settings 🗄️💖 the model is that the DHCP service keeps a key-value entry for each client. the key is some unique identifier (like an IP subnet number plus a unique identifier within that subnet), and the value holds all the configuration parameters for that client 🎀
for example, the key could be the pair (IP-subnet-number, hardware-address) 🦋 this lets the same hardware address get reused serially or even concurrently on different subnets, which is super useful since hardware addresses aren't always globally unique 🙈 or the key could be the pair (IP-subnet-number, hostname) 💅 this is iconic because the server can assign parameters smartly to a host that got moved to a different subnet, or one that changed hardware addresses (like when the network interface failed and got swapped out) 🫶
a client can query the DHCP service to fetch its configuration parameters 🌸 the client interface to this repository is just protocol messages: the client asks for parameters, and the server responds with messages carrying them ✨
2.2 Dynamic allocation of network addresses 🌈
the second service is handing out temporary or permanent network (IP) addresses to hosts 💜 the basic mechanism is honestly simple: a client requests to use an address for some period of time 🧚 the allocation mechanism (aka the collection of DHCP servers) promises not to reallocate that address within the requested time, and it tries to give back the same address every time the client asks 🥹 in this document, that period of time an address is allocated to a client is called a "lease" [11] ⭐ the client can extend its lease with later requests 🍓 and when it no longer needs the address, it can send a message to release the address back to the server 🕊️ a client can ask for a permanent assignment by requesting an infinite lease 👑 even then, a server may choose to give out lengthy but non-infinite leases, so it can still detect when the host has been retired 💀 (very smart, honestly)
sometimes an environment runs out of addresses and they have to be reassigned 😭 in that case, the allocation mechanism will reuse addresses whose lease has expired 🔥 the server should use whatever info is available in the configuration information repository to pick an address to reuse 🧠 for example, it might choose the least recently assigned address 🍃 as a consistency check, the allocation mechanism may probe the reused address before allocating it, e.g., with an ICMP echo request 🔍 and the client will probe the newly received address, e.g., with ARP 🫧
3. The Client-Server Protocol 🎀
okay the protocol part is where it gets really fun 💅 DHCP uses the BOOTP message format defined in RFC 951, which is shown in table 1 and figure 1 🌷 the op field of every DHCP message sent from a client to a server contains BOOTREQUEST 📤 and BOOTREPLY goes in the op field of every DHCP message sent from a server to a client 📥
the first four octets of the options field contain the (decimal) values 99, 130, 83 and 99, in that order 🪄 this is the same magic cookie defined in RFC 1395 ✨ the rest of the options field is a list of tagged parameters called "options" 🏷️ all of the "vendor extensions" listed in RFC 1395 are also DHCP options, which is giving continuity 🤝 a separate document gives the complete set of options defined for use with DHCP [2] 📚
several options have been defined so far 🌟 one in particular, the DHCP message type option, must be included in every DHCP message 🚨 this option defines the "type" of the DHCP message 🎫 additional options may be allowed, required, or not allowed, depending on the DHCP message type 🧩
throughout this document, any DHCP message that includes a DHCP message type option gets referred to by its type 💖 for example, a DHCP message with DHCP message type option type 1 is called a "DHCPDISCOVER" message 🍭
3.1 Client-server interaction - allocating a network address ✨
okay so this is the whole dance between a client and a server when a client needs an address 💅 we're going through the DHCP messages from table 2 below, and figure 3 shows the timing for a typical client-server interaction 🦋 if the client already knows its address, some steps can get skipped. that shortcut lives in section 3.2, bestie 🫶
- The client broadcasts a DHCPDISCOVER message on its local physical subnet. 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 that aren't on the same physical subnet 🌸
- Each server may respond with a DHCPOFFER message that includes an available network address in the
yiaddrfield (plus other configuration parameters in DHCP options) 🎀 servers don't need to reserve the offered address, but honestly the protocol works way more efficiently if the server avoids giving that same address to another client 💖 the server unicasts the DHCPOFFER message to the client (using the DHCP/BOOTP relay agent if necessary) if possible. otherwise it may broadcast the message to a broadcast address (preferably 255.255.255.255) on the client's subnet 📡 - The client gets one or more DHCPOFFER messages from one or more servers. it can choose to wait for multiple responses 🧚 then it picks one server to request configuration parameters from, based on what the DHCPOFFER messages offered 👑 the client broadcasts a DHCPREQUEST message that MUST include the
server identifieroption to say which server it picked, and it may include other options asking for specific configuration values. this DHCPREQUEST message 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'ssecsfield and be sent to the same IP broadcast address as the original DHCPDISCOVER. if the client gets no DHCPOFFER messages, it times out and retransmits the DHCPDISCOVER message 😭 - the servers receive the DHCPREQUEST broadcast from the client. the servers that weren't selected use the message as a notification that the client declined their offer 🙈 the selected server commits the binding for the client to persistent storage and responds with a DHCPACK message containing the configuration parameters for the requesting client ✨ the combo of
chaddrand the assigned network address makes a unique identifier for the client's lease, and both the client and server use it to identify a lease referred to in any DHCP messages 🌈 theyiaddrfield in the DHCPACK messages gets filled in with the selected network address 💜
if the selected server can't satisfy the DHCPREQUEST message (e.g., the requested network 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 in a DHCPOFFER message as available again if it doesn't receive a DHCPREQUEST message from that client 🍓
- the client receives the DHCPACK message with the configuration parameters 🎉 it does a final check on the parameters (e.g., ARP for the allocated network address), notes the duration of the lease, and notes the lease identification cookie specified in the DHCPACK message. at this point, the client is configured, periodt 💅 if the client detects a problem with the parameters in the DHCPACK message, it sends a DHCPDECLINE message to the server and restarts the configuration process. the client should wait a minimum of ten seconds before restarting, so it doesn't spam the network with traffic if things start looping 😩
if the client receives a DHCPNAK message, it restarts the configuration process ✨
the client times out and retransmits the DHCPREQUEST message if it receives neither a DHCPACK nor a DHCPNAK message. it retransmits the DHCPREQUEST according to the retransmission algorithm in section 4.1. if it still gets neither a DHCPACK nor a DHCPNAK after ten retransmissions of the DHCPREQUEST message, 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 can relinquish its lease on a network address by sending a DHCPRELEASE message to the server 🦋 it identifies the lease to be released by putting its network address in the
ciaddrfield and its hardware address in thechaddrfield 🫶
Here's the field layout for a DHCP message 📋
FIELD OCTETS DESCRIPTION
----- ------ -----------
op 1 Message op code / message type.
1 = BOOTREQUEST, 2 = BOOTREPLY
htype 1 Hardware address type, see ARP section in "Assigned
Numbers" RFC; e.g., '1' = 10mb ethernet.
hlen 1 Hardware address length (e.g. '6' for 10mb
ethernet).
hops 1 Client sets to zero, optionally used by relay-agents
when booting via a relay-agent.
xid 4 Transaction ID, a random number chosen by the
client, used by the client and server to associate
messages and responses between a client and a
server.
secs 2 Filled in by client, seconds elapsed since client
started trying to boot.
flags 2 Flags (see figure 2).
ciaddr 4 Client IP address; filled in by client in
DHCPREQUEST if verifying previously allocated
configuration parameters.
yiaddr 4 'your' (client) IP address.
siaddr 4 IP address of next server to use in bootstrap;
returned in DHCPOFFER, DHCPACK and DHCPNAK by
server.
giaddr 4 Relay agent IP address, used in booting via a
relay-agent.
chaddr 16 Client hardware address.
sname 64 Optional server host name, null terminated string.
file 128 Boot file name, null terminated string; "generic"
name or null in DHCPDISCOVER, fully qualified
directory-path name in DHCPOFFER.
options 312 Optional parameters field. See the options
documents for a list of defined options.
Table 1: Description of fields in a DHCP messageNow the timeline 🕰️ (figure 3)
Server Client Server
(not selected) (selected)
v v v
| | |
| Begins initialization |
| | |
| _____________/|\_____________ |
|/ DHCPDISCOVER | DHCPDISCOVER \|
| | |
Determines | Determines
configuration | configuration
| | |
|\ | ____________/|
| \_________ | /DHCPOFFER |
| DHCPOFFER\ |/ |
| \ | |
| Collects replies |
| \| |
| Selects configuration |
| | |
| _____________/|\_____________ |
|/ DHCPREQUEST | DHCPREQUEST \|
| | |
| | Commits configuration
| | |
| | _____________/|
| |/ DHCPACK |
| | |
| Initialization complete |
| | |
. . .
. . .
| | |
| Graceful shutdown |
| | |
| |\_____________ |
| | DHCPRELEASE \|
| | |
| | Discards lease
| | |
v v v
Figure 3: Timeline diagram of messages exchanged between DHCP
client and servers when allocating a new network addressHere's the cheat sheet for all the DHCP messages from table 2 📝
Message Use
------- ---
DHCPDISCOVER - Client broadcast to locate available servers.
DHCPOFFER - Server to client in response to DHCPDISCOVER with
offer of configuration parameters.
DHCPREQUEST - Client broadcast to servers requesting offered
parameters from one server and implicitly declining
offers from all others.
DHCPACK - Server to client with configuration parameters,
including committed network address.
DHCPNAK - Server to client refusing request for configuration
parameters (e.g., requested network address already
allocated).
DHCPDECLINE - Client to server indicating configuration parameters
(e.g., network address) invalid.
DHCPRELEASE - Client to server relinquishing network address and
cancelling remaining lease.
Table 2: DHCP messages3.2 Client-server interaction - reusing a previously allocated network address ✨
okay so if a client already remembers a network address it got before (either from DHCP or some other way outside the protocol), it's allowed to skip some of the steps from the last section 🫶 the main character move here is reusing what you already have. Figure 4 shows the timing for this kind of exchange.
- The client broadcasts a DHCPREQUEST message on its local subnet. The DHCPREQUEST message includes the client's network address in the
ciaddrfield. DHCP/BOOTP relay agents pass the message on to DHCP servers that are not on the same subnet. - Servers that know the client's configuration parameters reply to the client with a DHCPACK message.
If the client's request is invalid (for example, the client has moved to a new subnet), servers may reply to the client with a DHCPNAK message 💀
- The client gets the DHCPACK message with the configuration parameters. It does one last check on the parameters (same as section 3.1), and it notes how long the lease lasts and the lease identification cookie in the DHCPACK message. At this point the client is configured 🎀
If the client spots a problem with the parameters in the DHCPACK message, it sends a DHCPDECLINE message to the server and restarts the whole configuration process by asking for a new network address. This is the client moving to the INIT state in the DHCP state diagram, which is described in section 4.4 🔥
Server Client Server
v v v
| | |
| Begins |
| initialization |
| | |
| /|\ |
| ___________/ | \___________ |
| /DHCPREQUEST | DHCPREQUEST\ |
|/ | \|
| | |
Locates | Locates
configuration | configuration
| | |
|\ | /|
| \ | ___________/ |
| \ | / DHCPACK |
| \_______ |/ |
| DHCPACK\ | |
| Initialization |
| complete |
| \| |
| | |
| (Subsequent |
| DHCPACKS |
| ignored) |
| | |
| | |
v v vFigure 4: Timeline diagram of messages exchanged between DHCP client and servers when reusing a previously allocated network address
If the client gets a DHCPNAK message, it can't reuse its remembered network address anymore 😭 It has to ask for a brand new address by restarting the configuration process, this time using the full (non-abbreviated) procedure from section 3.1. This also means the client is moving to the INIT state in the DHCP state diagram.
The client times out and sends the DHCPREQUEST message again if it gets neither a DHCPACK nor a DHCPNAK message. The time between retransmissions MUST be chosen according to the algorithm given in section 4.1. If the client gets no answer after sending 4 DHCPREQUEST messages, it MAY choose to keep using the previously allocated network address and configuration parameters for the rest of the unexpired lease. This corresponds to moving to the BOUND state in the client state transition diagram shown in figure 5 🦋
- The client may choose to give up its lease on a network address by sending a DHCPRELEASE message to the server. The client identifies the lease to be released with the lease identification cookie.
Note that in this case, where the client keeps its network address locally, the client will not normally give up its lease during a graceful shutdown. The client only sends a DHCPRELEASE message when it really needs to give up its lease, for example when it is about to be moved to a different subnet 🧚
3.3 Interpretation and representation of time values ⏰
A client gets a lease for a network address for a fixed period of time, which may be infinite. Throughout the protocol, times are represented in units of seconds. The time value 0xffffffff is reserved to represent "infinity". The minimum lease duration is one hour.
As clients and servers may not have synchronized clocks, times are represented in DHCP messages as relative times, to be interpreted with respect to the client's local clock. Representing relative times in units of seconds in an unsigned 32 bit word gives a range of relative times from 0 to approximately 100 years, which is more than enough for measuring relative times in DHCP 🌈
The lease duration interpretation algorithm in the previous paragraph assumes that client and server clocks are stable relative to each other. If there is drift between the two clocks, the server may consider the lease expired before the client does. To make up for this, the server may return a shorter lease duration to the client than the server commits to in its local database of client information 💅
3.4 Host parameters in DHCP 🍓
Not every client needs every parameter listed in Appendix A. Two techniques cut down on the number of parameters sent from the server to the client. First, most parameters have defaults defined in the Host Requirements RFCs. If the client gets no parameters from the server that override those defaults, the client uses the default values. Second, in its initial DHCPDISCOVER or DHCPREQUEST message, a client may give the server a list of the specific parameters it's interested in.
The client SHOULD include the maximum DHCP message size option to let the server know how large the server may make its DHCP messages. The parameters returned to a client may still be bigger than the space allocated to options in a DHCP message. In that case, two additional options flags (which must appear in the options field of the message) indicate that the file and sname fields are to be used for options 🙈
The client can tell the server which configuration parameters it's interested in by including the parameter request list option. The data portion of this option explicitly lists the options requested by tag number.
On top of that, the client may suggest values for the network address and lease time in the DHCPDISCOVER message. The client may include the be assigned, and may include the IP address lease time option to suggest the lease time it would like. No other options representing "hints" at configuration parameters are allowed in a DHCPDISCOVER or DHCPREQUEST message. The ciaddr field is only filled in within a DHCPREQUEST message, when the client is requesting use of a previously allocated IP address.
If a server gets a DHCPREQUEST message with an invalid ciaddr, the server SHOULD reply to the client with a DHCPNAK message, and it may choose to report the problem to the system administrator. The server may include an error message in the message option 🫶
3.5 Use of DHCP in clients with multiple interfaces 🔌
A host with multiple network interfaces must use DHCP through each interface independently to get configuration information parameters for those separate interfaces.
3.6 When clients should use DHCP 🌸
A host should use DHCP to reacquire or verify its IP address and network parameters whenever the local network parameters may have changed. For example, that's at system boot time or after a disconnection from the local network, since the local network configuration may change without the host's or user's knowledge 👑
If a host knows about a previous network address and can't reach a local DHCP server, the host may keep using the previous network address until the lease for that address expires. If the lease expires before the host can reach a DHCP server, the host must immediately stop using the previous network address and may tell local users about the problem 😭
4. Specification of the DHCP client-server protocol ✨
In this section, we assume that a DHCP server has a block of network addresses it can hand out when requests for new addresses come in. Each server also keeps a database of allocated addresses and leases in local permanent storage 💜
4.1. Constructing and sending DHCP messages ✨
okay so DHCP clients and servers both build their messages the same way 💅. They fill in the fixed-format part of the message, then tack tagged data items onto the variable-length options area. That area starts with a four-octet 'magic cookie' (we covered it back in section 3 🍓), followed by the options. The last option must always be the 'end' option, no exceptions bestie 🫶.
DHCP runs over UDP 🦋. Client-to-server messages go to the 'DHCP server' port (67), and server-to-client messages go to the 'DHCP client' port (68).
Messages a client broadcasts before it has its IP address must have the source address field in the IP header set to 0 🙈.
Now the 'giaddr' field decides where replies go 🎀. If 'giaddr' is non-zero, the server sends any return messages to the 'DHCP server' port on the DHCP relaying agent whose address is in 'giaddr'. If 'giaddr' is zero, the client is on the same subnet, so the server sends replies to the client's network address (if one was supplied in the 'ciaddr' field), or to the client's hardware address, or to the local subnet broadcast address.
Options can overflow 📦. If the options in a DHCP message extend into the 'sname' and 'file' fields, the 'option overload' option MUST appear in the 'options' field, with value 1, 2 or 3, as specified in the DHCP options document [2]. When 'option overload' is present in the 'options' field, the options in the 'options' field MUST be terminated by an options field. The options in the 'sname' and 'file' fields (if they're in use, as indicated by the 'option overload' option) MUST begin with the first octet of the field, MUST be terminated by an 'end' option, and MUST be followed by 'pad' options to fill the rest of the field. Any individual option in the 'options', 'sname' and 'file' fields MUST be entirely contained in that field. The 'options' field MUST be interpreted first, so any 'option overload' options can be interpreted. The 'file' field MUST be interpreted next (if the options), followed by the 'sname' field 🧚.
Retransmission is the client's job 💪. DHCP clients are responsible for all message retransmission. The client MUST adopt a retransmission strategy that uses a randomized exponential backoff algorithm to decide the delay between retransmissions. The delay before the first retransmission MUST be 4 seconds, randomized by a uniform random number from the range -1 to +1. Clients whose clocks have resolution finer than a second may pick a non-integer randomization value. The delay before the next retransmission MUST be 8 seconds, randomized by a uniform number from the range -1 to +1. The retransmission delay MUST be doubled with each subsequent retransmission, up to a maximum of 64 seconds. The client MAY show retransmission attempts to the user as a progress indicator for the configuration process ⏳. The rest of this section spells out, for each DHCP message, when the client should keep retransmitting that message forever and when it should give up on that message and try a different one.
Unicast is the normal vibe, but it's not always possible 🌸. Usually, DHCP servers and BOOTP relay agents try to deliver DHCPOFFER, DHCPACK and DHCPNAK messages straight to the client with unicast delivery. The IP destination address in the IP header is set to the DHCP 'yiaddr' address, and the link-layer destination address is set to the DHCP 'chaddr' address. Unfortunately, some client implementations can't receive these unicast IP datagrams until they've been configured with a valid IP address. That creates a deadlock, because the client's IP address can't be delivered until the client has been configured with an IP address 😭.
Here's how the BROADCAST bit saves the day 🌈:
A client that can't receive unicast IP datagrams until its protocol software has been configured with an IP address SHOULD set the BROADCAST bit in the 'flags' field to 1 in any DHCPDISCOVER or DHCPREQUEST messages it sends. The BROADCAST bit is a hint to the DHCP server and BOOTP relay agent that they should broadcast any messages to the client on the client's subnet. A client that can receive unicast IP datagrams before its protocol software has been configured SHOULD clear the BROADCAST bit to 0. The BOOTP clarifications document discusses the ramifications of using the BROADCAST bit [21].
A server or relay agent that sends or relays a DHCP message directly to a DHCP client (that is, not to a relay agent named in the 'giaddr' field) SHOULD examine the BROADCAST bit in the 'flags' field. If the bit is set to 1, the DHCP message SHOULD be sent as an IP broadcast, using an IP broadcast address (preferably 255.255.255.255) as the IP destination address and the link-layer broadcast address as the link-layer destination address. If the BROADCAST bit is cleared to 0, the message SHOULD be sent as an IP unicast to the IP address in the 'yiaddr' field and the link-layer address in the 'chaddr' field. If unicasting isn't possible, the message MAY be sent as an IP broadcast, using an IP broadcast address (preferably 255.255.255.255) as the IP destination address and the link-layer broadcast address as the link-layer destination address 🦋.
4.2. DHCP server administrative controls 👑
DHCP servers aren't required to respond to every DHCPDISCOVER and DHCPREQUEST message they get 🙅♀️. For example, a network admin who wants tight control over the hosts on the network might configure DHCP servers to respond only to hosts that were registered earlier through some external mechanism. The DHCP specification only describes the interactions between clients and servers when they choose to interact. Describing every administrative control a sysadmin might want is out of scope for the DHCP spec 🫠. Specific DHCP server implementations can include any controls or policies a network administrator wants.
In some environments, a DHCP server has to look at the 'chaddr' field and/or the 'class-identifier' option in the DHCPDISCOVER or DHCPREQUEST messages when it picks the right parameters for a particular client 🧐. For example, an organization might run a separate bootstrap server for each type of client it uses. In that case the DHCP server has to examine the 'class-identifier' to decide which bootstrap server address to put in the 'siaddr' field of a DHCPOFFER or DHCPACK message.
A DHCP server MUST use some unique identifier to associate a client with its lease 🔑. The client may choose to explicitly provide that identifier through the 'client identifier' option. If the client doesn't provide a 'client identifier' option, the server MUST use the contents of the 'chaddr' field to identify the client.
DHCP clients are free to use any strategy they like for choosing a DHCP server from among those whose DHCPOFFER messages they receive 🍭. The client implementation of DHCP should provide a mechanism that lets the user select the 'class-identifier' value directly.
4.3. DHCP server behavior 🎬
A DHCP server handles incoming DHCP messages from a client based on the current state of the binding for that client 💜. A DHCP server can receive the following messages from a client:
DHCPDISCOVERDHCPREQUESTDHCPDECLINEDHCPRELEASE
Table 3 gives the use of the fields and options in a DHCP message by a server. The rest of this section walks through what the DHCP server does for each possible incoming message. Stay tuned, it's about to get very iconic 🌟.
4.3.1 DHCPDISCOVER message ✨
okay so when a server gets a DHCPDISCOVER from a client, it's time to pick a network address for that client 🫶 If there's nothing free, the server can choose to tell the system administrator about the problem, and it can also reply with a DHCPNAK 💀 If it does reply, it can add an error message to the 'message' option. When an address IS available, the server picks it in this order:
- the client's previous address from its binding, if that address is in the server's pool of available addresses and not already allocated, else
- the address from the
'Requested IP Address'option, if that address is valid and not already allocated, else - a brand-new address from the server's pool of available addresses.
Here's the field breakdown for each of the three replies. It's giving very organized 🎀
Field DHCPOFFER DHCPACK DHCPNAK
----- --------- ------- -------
'op' BOOTREPLY BOOTREPLY BOOTREPLY
'htype' (From "Assigned Numbers" RFC)
'hlen' (Hardware address length in octets)
'hops' 0 0 0
'xid' 'xid' from client 'xid' from client 'xid' from client
DHCPDISCOVER DHCPREQUEST DHCPREQUEST
message message message
'secs' 0 0 0
'ciaddr' 0 'ciaddr' from 'ciaddr' from
DHCPREQUEST or 0 DHCPREQUEST or 0
'yiaddr' IP address offered IP address 0
to client assigned to client
'siaddr' IP address of next IP address of next 0
bootstrap server bootstrap server
'flags' if 'giaddr' is not 0 then 'flags' from client message else 0
'giaddr' 0 0 0
'chaddr' 'chaddr' from 'chaddr' from 'chaddr' from
client client DHCPREQUEST client DHCPREQUEST
DHCPDISCOVER message message
message
'sname' Server host name Server host name (unused)
or options or options
'file' Client boot file Client boot file (unused)
name or options name or options
'options' options optionsNow the options, which is where the BCP 14 vibes get intense 🔥
Option DHCPOFFER DHCPACK DHCPNAK
------ --------- ------- -------
Requested IP address MUST NOT MUST NOT MUST NOT
IP address lease time MUST MUST MUST NOT
Use 'file'/'sname' MAY MAY MUST NOT
fields
DHCP message type DHCPOFFER DHCPACK DHCPNAK
Parameter request list MUST NOT MUST NOT MUST NOT
Message SHOULD SHOULD SHOULD
Client identifier MUST NOT MUST NOT MUST NOT
Class identifier MUST NOT MUST NOT MUST NOT
Server identifier MUST MAY MAY
Maximum message size MUST NOT MUST NOT MUST NOT
All others MAY MAY MUST NOT
Table 3: Fields and options used by DHCP serversLike we talked about in section 4.2, a server MAY, for admin reasons, hand out a different address than the one the client asked for 🙈 It can also refuse to give a client an address even when free ones are sitting right there. Not strictly needed for DHCP to work, but the server should not reuse the address it picked until the client answers the DHCPOFFER. The server may choose to record that address as offered to the client 🦋
The server must also pick an expiration time for the lease, and it goes like this:
- IF the client didn't ask for a specific lease in the DHCPDISCOVER message and the client already has an assigned network address, the server returns the lease expiration time previously assigned to that address (note that the client must explicitly request a specific lease to extend the expiration time on a previously assigned address), ELSE
- IF the client didn't ask for a specific lease in the DHCPDISCOVER message and the client doesn't have an assigned network address, the server assigns a locally configured default lease time, ELSE
- IF the client did ask for a specific lease in the DHCPDISCOVER message (regardless of whether the client has an assigned network address), the server may choose either to return the requested lease (if it's acceptable to local policy) or select another lease.
Once the address and lease are sorted, the server builds a DHCPOFFER with the offered configuration parameters 💅 It's important that every DHCP server returns the same parameters (apart from a newly allocated network address, which is the one possible exception). That way the host behaves predictably no matter which server it ends up picking 👑 The configuration parameters MUST be selected by applying the following rules in the order given below. The network administrator is responsible for configuring multiple DHCP servers so their responses match. The server MUST return to the client:
- the client's network address, as determined by the rules earlier in this section, plus the subnet mask for the network the client is connected to,
- the expiration time for the client's lease, as determined by the rules earlier in this section,
- the parameters the client requested, following these rules:
- IF the server has been explicitly configured with a default value for the parameter, the server MUST include that value in an appropriate option in the
'option'field, ELSE - IF the server recognizes the parameter as one defined in the Host Requirements Document, the server MUST include the default value for that parameter as given in the Host Requirements Document in an appropriate option in the
'option'field, ELSE - The server MUST NOT return a value for that parameter,
- IF the server has been explicitly configured with a default value for the parameter, the server MUST include that value in an appropriate option in the
- any parameters from the existing binding that differ from the Host Requirements documents' defaults,
- any parameters specific to this client (identified by the contents of
'chaddr'in the DHCPDISCOVER or DHCPREQUEST message), for example as configured by the network administrator, - any parameters specific to this client's class (identified by the contents of the
'class identifier'option in the DHCPDISCOVER or DHCPREQUEST message), for example as configured by the network administrator. These parameters MUST be identified by an exact match between the client's'client class'and the client class identified in the server, - parameters with non-default values on the client's subnet.
Last step: the server copies the 'xid' field from the DHCPDISCOVER into the DHCPOFFER's 'xid' field, and then sends that DHCPOFFER off to the requesting client 🌈
4.3.2 DHCPREQUEST message 💜
A DHCPREQUEST can show up in two situations. Either a client is replying to a DHCPOFFER from a server, or a client is checking a previously allocated IP address. If the DHCPREQUEST has a 'server identifier' option, it's answering a DHCPOFFER. If it doesn't, it's a request to renew or extend an existing lease ✨
Let's start with the DHCPOFFER reply. If the server named in the 'server identifier' option is this server, it checks that the requested parameters are acceptable. Usually they match what was sent in the DHCPOFFER, but the client is allowed to ask for a different lease duration 🙈 There's also no requirement that the server cache the DHCPOFFER's parameters. The server must simply check that the parameters in the DHCPREQUEST are acceptable. If they are, the server records the new client binding and sends a DHCPACK back to the client 🎀
If the requested parameters aren't acceptable (for example, the requested lease time doesn't fly with local policy), the server sends a DHCPNAK to the client. The server may choose to include an error message in the 'message' option 💀
If a different server is named in the 'server identifier' field, the client picked someone else 😭 The server may throw out anything it cached about that client's request, and it may free the address it had offered.
Quick tea: the client may collect a bunch of DHCPOFFERs and pick the "best" one 💅 It tells the winner by naming that server in the DHCPREQUEST. If the client gets no acceptable offers, it may just send another DHCPDISCOVER instead. Because of that, servers might never see a DHCPREQUEST that tells them whether the client accepted their offer. Since servers haven't committed any addresses based on a DHCPOFFER, they're free to reuse offered addresses for later requests. As an implementation detail, servers should not reuse offered addresses, and they may use an implementation-specific timeout to decide when an offered address can be reused 🦋
Now the second case, when there's no 'server identifier' option. The client is renewing or extending an address it already has. The server checks that the requested parameters are acceptable. If the parameters in the DHCPREQUEST match the previous ones, or if the requested lease extension (signaled by an extended 'IP address lease time' option) is acceptable, the server returns a DHCPACK to the requesting client. Otherwise, it returns a DHCPNAK. Notably, if the previously allocated address in the client's 'ciaddr' field doesn't match the address the server has recorded for that client, the server sends a DHCPNAK 🙅♀️
A DHCP server picks the parameters for a DHCPACK using the same rules it uses for building a DHCPOFFER, as described in section 4.3.1 💖
4.3.3 DHCPDECLINE message 🌸
If the server gets a DHCPDECLINE, the client found out some other way that the suggested address is already in use 😬 The server MUST mark that network address as not allocated, and SHOULD let the local system administrator know about a possible configuration problem.
4.3.4 DHCPRELEASE message 🧚
When the server gets a DHCPRELEASE, it marks the network address as not allocated 🫶 The server should keep a record of the client's initialization parameters, in case the client asks for them again later and they can be reused.
4.4. DHCP client behavior ✨
okay so bestie, here's the client side 💖 Figure 5 is a state-transition diagram for a DHCP client, and a client can receive three kinds of messages from a server: DHCPOFFER, DHCPACK, and DHCPNAK. Table 4 shows which fields and options a client uses in each DHCP message. The rest of this section walks through what the client does for each incoming message. The next part covers the full configuration procedure from section 3.1, and the part after that covers the abbreviated one from section 3.2 🧚
DHCPOFFERDHCPACKDHCPNAK
4.4.1. Initialization and allocation of network address
the client starts out in INIT state and makes a DHCPDISCOVER message 🎀 It should wait a random time between one and ten seconds so it doesn't sync up with every other device booting at startup 🙈 It sets ciaddr to all 0x00000000. It MAY ask for specific parameters by including the 'parameter request list' option. It MAY also suggest a network address and/or lease time using the 'requested IP address' and 'IP address lease time' options. The client MUST include its hardware address in the chaddr field so the server can deliver the DHCP reply messages 🫶 It MAY include a different unique identifier in the 'client identifier' option. If the client does not include the
The client makes a random transaction identifier, records it, and puts it in the xid field 🦋 It also writes down its own local time so it can work out the lease expiration later ⏰ Then it broadcasts the DHCPDISCOVER on the local hardware broadcast address, to the all-ones IP broadcast address and the 'DHCP server' UDP port 📡
If a DHCPOFFER arrives with an xid that doesn't match the xid of the most recent DHCPDISCOVER, that DHCPOFFER must be silently discarded 🙅♀️ Any DHCPACK messages that show up at this point must be silently discarded too 💀
The client collects DHCPOFFER messages for a while, then picks one of the (possibly many) that came in. For example, it could take the first one, or the one from the server it used last time 👑 It pulls the server address out of the 'server identifier' option in that DHCPOFFER. How long it collects and how it picks one are implementation dependent, so that's up to the implementer 💅 The client MAY check that the suggested address isn't already in use. For instance, if the network supports ARP, the client may send an ARP request for the suggested request. When it broadcasts that ARP request, the client must fill in its own hardware address as the sender's hardware address, and 0 as the sender's IP address, so it doesn't mess up the ARP caches of other hosts on the same subnet 🧠 If the address looks like it's already taken, the client sends a DHCPDECLINE message to the server and waits for another DHCPOFFER 😭 Since it doesn't have a valid network address yet, the client must broadcast that DHCPDECLINE message 📣
-------- -------
| | +-------------------------->| |<-------------------+
| INIT/ | | +-------------------->| INIT | |
| REBOOT |DHCPNAK/ +---------->| |<---+ |
| |Restart| | ------- | |
-------- | DHCPNAK/ | | |
| Discard offer | -/Send DHCPDISCOVER |
-/Send DHCPREQUEST | | |
| | | DHCPACK v | |
----------- | (not accept.)/ ----------- | |
| | | Send DHCPDECLINE | | | |
| REBOOTING | | | | SELECTING | | |
| | | / | | | |
----------- | / ----------- | |
| | / | | |
DHCPACK/ | / +----------------+ | |
Record lease, | | v | |
set timers ------------ | |
| +----->| | DHCPNAK, Lease expired/ |
| | | REQUESTING | Halt network |
DHCPOFFER/ | | | |
Discard ------------ | |
| | | | ----------- |
| +--------+ DHCPACK/ | | |
| Record lease, set -----| REBINDING | |
| timers T1, T2 / | | |
| | DHCPACK/ ----------- |
| v Record lease, set ^ |
+----------------> ------- /Timers T1,T2 | |
+----->| |<---+ | |
| | BOUND |<---+ | |
DHCPOFFER, DHCPACK, | | | T2 expires/ DHCPNAK/
DHCPNAK/Discard ------- | Broadcast Halt network
| | | | DHCPREQUEST |
+-------+ | DHCPACK/ | |
T1 expires/ Record lease, set | |
Send DHCPREQUEST timers T1, T2 | |
to leasing server | | |
| ---------- | |
| | |------------+ |
+->| RENEWING | |
| |----------------------------+
----------
Figure 5: State-transition diagram for DHCP clientsokay this diagram is giving main character energy 🎀 Here's the field-by-field breakdown for each message type 💅
Field DHCPDISCOVER DHCPREQUEST DHCPDECLINE,
DHCPRELEASE
----- ------------ ----------- -----------
'op' BOOTREQUEST BOOTREQUEST BOOTREQUEST
'htype' (From "Assigned Numbers" RFC)
'hlen' (Hardware address length in octets)
'hops' 0 0 0
'xid' selected by client selected by client selected by
client
'secs' (opt.) (opt.) 0
'flags' Set 'BROADCAST' Set 'BROADCAST'
flag if client flag if client
requires broadcast requires broadcast
reply reply
0
'ciaddr' 0 previously ciaddr
allocated newtork
address
'yiaddr' 0 0 0
'siaddr' 0 0 0
'giaddr' 0 0 0
'chaddr' client's hardware client's hardware client's
hardware
address address address
'sname' options, if options, if (unused)
indicated in indicated in
'sname/file' 'sname/file'
option; otherwise option; otherwise
unused unused
'file' options, if options, if (unused)
indicated in indicated in
'sname/file' 'sname/file'
option; otherwise option; otherwise
'generic' name or 'generic' name or
null null
'options' options options (unused)
Option DHCPDISCOVER DHCPREQUEST DHCPDECLINE,
DHCPRELEASE
------ ------------ ----------- -----------
Requested IP address MAY MUST NOT MUST NOT
IP address lease time MAY MAY MUST NOT
Use 'file'/'sname' fields MAY MAY MAY
DHCP message type DHCPDISCOVER DHCPREQUEST DHCPDECLINE/
DHCPRELEASE
Client identifier MAY MAY MAY
Class identifier SHOULD SHOULD MUST NOT
Server identifier MUST NOT MUST (after MUST
DHCPDISCOVER),
MUST NOT (when
renewing)
Parameter request list MAY MAY MUST NOT
Maximum message size MAY MAY MUST NOT
Message SHOULD NOT SHOULD NOT SHOULD
Site-specific MAY MAY MUST NOT
All others MUST NOT MUST NOT MUST NOT
Table 4: Fields and options used by DHCP clientsOnce the parameters look good, the client writes down the server address from the 'server identifier' field and puts it in the 'server identifier' field of a DHCPREQUEST broadcast message 📣 When the DHCPACK from the server shows up, the client is initialized and moves to BOUND state 🎉 The DHCPREQUEST carries the same xid as the DHCPOFFER 🦋 The client works out its lease expiration as the time it sent the original request plus the lease duration from the DHCPOFFER ⏰ The client SHOULD broadcast an ARP reply to announce its new IP address and clear out any old ARP cache entries on hosts in its subnet, which is a very clean move 🧹✨
4.4.2. Initialization with known network address
the client begins in INIT-REBOOT state and sends a DHCPREQUEST with the ciaddr field set to its network address 🌸 It may ask for specific configuration parameters by including the random transaction identifier and inserts that identifier into the computing the lease expiration. The client MUST NOT include a 'server identifier' in the DHCPREQUEST message 🙅♀️ Then it broadcasts the DHCPREQUEST on the local hardware broadcast address to the 'DHCP server' UDP port 📡
heads up bestie: the source text for this part got a little scrambled in the middle, so I kept the wording as it came in, word for word, instead of guessing what it was supposed to say 🙈
Once a DHCPACK whose xid matches the one in the client's DHCPREQUEST arrives from any server, the client is initialized and moves to BOUND state 🎀 The client records the lease expiration time as the sum of the time the DHCPREQUEST was sent and the lease duration from the DHCPACK message 🔥
4.4.3. Initialization with a known DHCP server address
when the DHCP client knows the address of a DHCP server, whether it's in INIT or REBOOTING state, it may use that address in its DHCPDISCOVER or DHCPREQUEST instead of the IP broadcast address 🧚 If the client gets no response to DHCP messages sent to the IP address of a known DHCP server, it reverts to using the IP broadcast address 💜 Ngl, that's a super smart fallback 👑
4.4.4. Reacquisition and expiration 🔁
Okay bestie, the client keeps two timers, T1 and T2, that decide when it tries to extend its lease on its network address 💅. T1 is when the client goes into RENEWING state and tries to reach the server that originally gave it the address. T2 is when it goes into REBINDING state and tries to reach any server 🦋.
When T1 hits (after the client has accepted the lease), it moves into RENEWING and unicasts a DHCPREQUEST to the server to extend its lease ✨. It makes up a random transaction identifier and drops it into the 'xid' field of that DHCPREQUEST. It also records the local time it sent the DHCPREQUEST, because that's how it figures out when the lease expires 🕰️. The client MUST NOT include a 'server identifier' in the DHCPREQUEST message 🙅♀️.
Any DHCPACK messages that arrive with an 'xid' that does not match the
When the client receives a DHCPACK from the server, it computes the lease expiration time as the sum of the time it sent the DHCPREQUEST and the duration of the lease in the DHCPACK message 🎉. The client has successfully reacquired its network address, goes back to BOUND state, and can keep on doing its networking thing 🌸.
If no DHCPACK shows up before T2 (and T2 is later than T1) and before the lease on its network address expires, the client moves to REBINDING state and broadcasts a DHCPREQUEST to extend its lease 📡. It sets the 'ciaddr' field in that DHCPREQUEST to its current network address. Again, the client MUST NOT include a 'server identifier' in the DHCPREQUEST message 🙅♀️.
The server can configure T1 and T2 through options, and if it doesn't, T1 defaults to (0.5 * duration_of_lease) and T2 defaults to (0.875 * duration_of_lease) 🧮. T1 and T2 should be picked with some random "fuzz" around a fixed value, so that a bunch of clients don't all try to reacquire at the exact same moment and cause a stampede 🌀.
In both RENEWING and REBINDING state, if the client gets no response to its DHCPREQUEST, it should wait one-half of the remaining time until T1 expires (in RENEWING state) or T2 expires (in REBINDING state), down to a minimum of 60 seconds, before it retransmits the DHCPREQUEST ⏳.
If the lease expires before the client gets a DHCPACK, the client moves to INIT state 😱. It MUST immediately stop any other network processing and asks for network initialization parameters like it was never initialized in the first place 🛑. If the client then gets a DHCPACK that hands it its previous network address, it SHOULD keep on doing network processing 💖. But if it's given a brand new network address, it MUST NOT keep using the previous one, and it SHOULD tell the local users about the problem 🚨.
4.4.5. DHCPRELEASE 👋
If the client doesn't need its assigned network address anymore (like when it's gracefully shutting down), it sends a DHCPRELEASE message to the server 🌙. Just so you know, DHCP working correctly does NOT depend on DHCPRELEASE messages actually getting sent, so it's not the end of the world if one gets lost 🫶.
5. Acknowledgments 🫶
Greg Minshall, Leo McLaughlin and John Veizades patiently helped shape the design of DHCP through countless discussions, meetings and mail conversations 💜. Jeff Mogul first proposed the client-server model for DHCP 👑. Steve Deering dug through the various IP RFCs to put together the list of network parameters that DHCP supplies 🔍. Walt Wimer brought a ton of practical BOOTP experience and wrote a document clarifying how BOOTP/DHCP relay agents behave 🎀. Jesse Walker analysed DHCP in detail and pointed out several inconsistencies in earlier specifications of the protocol 🧠. Steve Alexander reviewed Walker's analysis and the protocol fixes that came out of Walker's work 🔧. And of course, every member of the Dynamic Host Configuration Working Group of the IETF has helped design the protocol through discussion and review 🌈.
6. References 📚
[1] Acetta, M., "Resource Location Protocol", RFC 887, CMU, December 1983.
[2] Alexander, S., and R. Droms, "DHCP Options and BOOTP Vendor Extensions", RFC 1533, Lachman Technology, Inc., Bucknell University, October 1993.
[3] Braden, R., Editor, "Requirements for Internet Hosts -- Communication Layers", STD 3, RFC 1122, USC/Information Sciences Institute, October 1989.
[4] Braden, R., Editor, "Requirements for Internet Hosts -- Application and Support, STD 3, RFC 1123, USC/Information Sciences Institute, October 1989.
[5] Brownell, D, "Dynamic Reverse Address Resolution Protocol (DRARP)", Work in Progress.
[6] Comer, D., and R. Droms, "Uniform Access to Internet Directory Services", Proc. of ACM SIGCOMM '90 (Special issue of Computer Communications Review), 20(4):50--59, 1990.
[7] Croft, B., and J. Gilmore, "Bootstrap Protocol (BOOTP)", RFC 951, Stanford and SUN Microsystems, September 1985.
[8] Deering, S., "ICMP Router Discovery Messages", RFC 1256, Xerox PARC, September 1991.
[9] Droms, D., "Interoperation between DHCP an BOOTP" RFC 1534, Bucknell University, October 1993.
[10] Finlayson, R., Mann, T., Mogul, J., and M. Theimer, "A Reverse Address Resolution Protocol", RFC 903, Stanford, June 1984.
[11] Gray C., and D. Cheriton, "Leases: An Efficient Fault-Tolerant Mechanism for Distributed File Cache Consistency", In Proc. of the Twelfth ACM Symposium on Operating Systems Design, 1989.
[12] Mockapetris, P., "Domain Names -- Concepts and Facilities", STD 13, RFC 1034, USC/Information Sciences Institute, November 1987.
[13] Mockapetris, P., "Domain Names -- Implementation and Specification", STD 13, RFC 1035, USC/Information Sciences Institute, November 1987.
[14] Mogul J., and S. Deering, "Path MTU Discovery", RFC 1191, November 1990.
[15] Morgan, R., "Dynamic IP Address Assignment for Ethernet Attached Hosts", Work in Progress.
[16] Postel, J., "Internet Control Message Protocol", STD 5, RFC 792, USC/Information Sciences Institute, September 1981.
[17] Reynolds, J., "BOOTP Vendor Information Extensions", RFC 1497, USC/Information Sciences Institute, August 1993.
[18] Reynolds, J., and J. Postel, "Assigned Numbers", STD 2, RFC 1340, USC/Information Sciences Institute, July 1992.
[19] Jeffrey Schiller and Mark Rosenstein. A Protocol for the Dynamic Assignment of IP Addresses for use on an Ethernet. (Available from the Athena Project, MIT), 1989.
[20] Sollins, K., "The TFTP Protocol (Revision 2)", RFC 783, NIC, June 1981.
[21] Wimer, W., "Clarifications and Extensions for the Bootstrap Protocol", RFC 1532, Carnegie Mellon University, October 1993.
7. Security Considerations 🚨
DHCP is built directly on UDP and IP, which are inherently insecure 😭. On top of that, DHCP is generally meant to make maintaining remote and/or diskless hosts easier. Setting those hosts up with passwords or keys may not be impossible, but it can be really difficult and annoying 🙄. So, DHCP in its current form is quite insecure 💀.
Unauthorized DHCP servers can be set up really easily 👀. Those servers can then send false and potentially disruptive info to clients, like incorrect or duplicate IP addresses, incorrect routing information (including spoofed routers, and so on), and incorrect domain nameserver addresses (like spoofed nameservers) 🕸️. Clearly, once that seed information is in place, an attacker can go on to compromise the affected systems 😱.
Malicious DHCP clients can pretend to be legitimate clients and retrieve information meant for those legit clients 🎭. And where dynamic allocation of resources is used, a malicious client could claim all the resources for itself, which denies them to legitimate clients 🙅♀️. Not it!
8. Author's Address 🖋️
Ralph Droms, Computer Science Department, 323 Dana Engineering, Bucknell University, Lewisburg, PA 17837 🏫
Phone: (717) 524-1145 📞
EMail: droms@bucknell.edu 💌
A. Host Configuration Parameters 🎀
IP-layer_parameters,_per_host:_
Be a router on/off HRC 3.1
Non-local source routing on/off HRC 3.3.5
Policy filters for
non-local source routing (list) HRC 3.3.5
Maximum reassembly size integer HRC 3.3.2
Default TTL integer HRC 3.2.1.7
PMTU aging timeout integer MTU 6.6
MTU plateau table (list) MTU 7
IP-layer_parameters,_per_interface:_
IP address (address) HRC 3.3.1.6
Subnet mask (address mask) HRC 3.3.1.6
MTU integer HRC 3.3.3
All-subnets-MTU on/off HRC 3.3.3
Broadcast address flavor 0x00000000/0xffffffff HRC 3.3.6
Perform mask discovery on/off HRC 3.2.2.9
Be a mask supplier on/off HRC 3.2.2.9
Perform router discovery on/off RD 5.1
Router solicitation address (address) RD 5.1
Default routers, list of:
router address (address) HRC 3.3.1.6
preference level integer HRC 3.3.1.6
Static routes, list of:
destination (host/subnet/net) HRC 3.3.1.2
destination mask (address mask) HRC 3.3.1.2
type-of-service integer HRC 3.3.1.2
first-hop router (address) HRC 3.3.1.2
ignore redirects on/off HRC 3.3.1.2
PMTU integer MTU 6.6
perform PMTU discovery on/off MTU 6.6
Link-layer_parameters,_per_interface:_
Trailers on/off HRC 2.3.1
ARP cache timeout integer HRC 2.3.2.1
Ethernet encapsulation (RFC 894/RFC 1042) HRC 2.3.3
TCP_parameters,_per_host:_
TTL integer HRC 4.2.2.19
Keep-alive interval integer HRC 4.2.3.6
Keep-alive data size 0/1 HRC 4.2.3.6Key:
MTU = Path MTU Discovery (RFC 1191, Proposed Standard)
RD = Router Discovery (RFC 1256, Proposed Standard)
📦 where this page comes from
- ietf: rfc1531 1993-10
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms