RFC 2131
Dynamic Host Configuration Protocol
RFC 2131: Dynamic Host Configuration Protocol 🎀
part 1 of 11 💖
Okay bestie, the title block first, because it's giving official paperwork 📜 This is RFC 2131, a Standards Track doc from the Network Working Group, written by R. Droms at Bucknell University and dated March 1997. The header says it obsoletes 1541, so it replaces RFC 1541 🫶 Section 1.1 describes it as updating the DHCP spec that appears in RFC1541, so both are true.
Status of this memo 📜
This doc specifies an Internet standards track protocol for the Internet community, and it asks for discussion and suggestions for improvements 💬 For the standardization state and status of this protocol, check the current edition of the "Internet Official Protocol Standards" (STD 1). Distribution of this memo is unlimited 🌈
Abstract 🌸
The Dynamic Host Configuration Protocol (DHCP) is a framework for passing configuration information to hosts on a TCPIP network ✨ DHCP is based on the Bootstrap Protocol (BOOTP) [7], and it adds automatic allocation of reusable network addresses and extra configuration options [19]. It also captures the behavior of BOOTP relay agents [7, 21], and DHCP participants can interoperate with BOOTP participants [9] 🦋
Table of Contents 📚
1. Introduction. . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1 Changes to RFC1541. . . . . . . . . . . . . . . . . . . . . . 3
1.2 Related Work. . . . . . . . . . . . . . . . . . . . . . . . . 4
1.3 Problem definition and issues . . . . . . . . . . . . . . . . 4
1.4 Requirements. . . . . . . . . . . . . . . . . . . . . . . . . 5
1.5 Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6
1.6 Design goals. . . . . . . . . . . . . . . . . . . . . . . . . 6
2. Protocol Summary. . . . . . . . . . . . . . . . . . . . . . . 8
2.1 Configuration parameters repository . . . . . . . . . . . . . 11
2.2 Dynamic allocation of network addresses . . . . . . . . . . . 12
3. The Client-Server Protocol. . . . . . . . . . . . . . . . . . 13
3.1 Client-server interaction - allocating a network address. . . 13
3.2 Client-server interaction - reusing a previously allocated
network address . . . . . . . . . . . . . . . . . . . . . . . 17
3.3 Interpretation and representation of time values. . . . . . . 20
3.4 Obtaining parameters with externally configured network
address . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
3.5 Client parameters in DHCP . . . . . . . . . . . . . . . . . . 21
3.6 Use of DHCP in clients with multiple interfaces . . . . . . . 22
3.7 When clients should use DHCP. . . . . . . . . . . . . . . . . 22
4. Specification of the DHCP client-server protocol. . . . . . . 22
4.1 Constructing and sending DHCP messages. . . . . . . . . . . . 22
4.2 DHCP server administrative controls . . . . . . . . . . . . . 25
4.3 DHCP server behavior. . . . . . . . . . . . . . . . . . . . . 26
4.4 DHCP client behavior. . . . . . . . . . . . . . . . . . . . . 34
5. Acknowledgments. . . . . . . . . . . . . . . . . . . . . . . .42
6. References . . . . . . . . . . . . . . . . . . . . . . . . . .42
7. Security Considerations. . . . . . . . . . . . . . . . . . . .43
8. Author's Address . . . . . . . . . . . . . . . . . . . . . . .44
A. Host Configuration Parameters . . . . . . . . . . . . . . . .45
List of Figures
1. Format of a DHCP message . . . . . . . . . . . . . . . . . . . 9
2. Format of the 'flags' field. . . . . . . . . . . . . . . . . . 11
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. . . . . . . . . . . 34
List of Tables
1. Description of fields in a DHCP message. . . . . . . . . . . . 10
2. DHCP messages. . . . . . . . . . . . . . . . . . . . . . . . . 14
3. Fields and options used by DHCP servers. . . . . . . . . . . . 28
4. Client messages from various states. . . . . . . . . . . . . . 33
5. Fields and options used by DHCP clients. . . . . . . . . . . . 371. Introduction ✨
DHCP is the Dynamic Host Configuration Protocol, and it hands 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 allocate network addresses and deliver configuration parameters to dynamically configured hosts 💅 In 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 many kinds of hardware and protocol implementations that random hosts answering DHCP requests would break reliable operation. IP needs lots of parameters set inside the protocol implementation software, and since 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/defense mechanism to discover addresses already in use. IP hosts may not always be able to defend their addresses, so such a scheme can't be guaranteed to avoid allocating duplicate network addresses.
DHCP supports three mechanisms for IP address allocation 🌸 With "automatic allocation", DHCP assigns a permanent IP address to a client. With "dynamic allocation", DHCP assigns an IP address to a client for a limited period of time (or until the client explicitly relinquishes the address). With "manual allocation", the network administrator assigns a client's IP address, and DHCP is only used to convey that address to the client. A particular network will use one or more of these mechanisms, depending on the policies of its network administrator 🦋
Dynamic allocation is the only one of the three that allows automatic reuse of an address the client no longer needs 👑 That makes it perfect for a client that's only connected to the network temporarily, or for sharing a limited pool of IP addresses among clients that don't need permanent ones. It's also a good pick for a new client that's permanently connected to a network where addresses are scarce enough that reclaiming them from retired clients really matters 🍓 Manual allocation lets DHCP eliminate the error-prone process of manually configuring hosts with IP addresses, in environments where (for whatever reasons) it's desirable to manage IP address assignment outside of the DHCP mechanisms 💖
The DHCP message format is based on the BOOTP message format. That captures the BOOTP relay agent behavior described in the BOOTP specification [7, 21], and it lets existing BOOTP clients interoperate with DHCP servers 🫶 Using BOOTP relay agents means you don't need a DHCP server on each physical network segment 🌈
1.1 Changes to RFC 1541 🔥
This document updates the DHCP protocol specification that appears in RFC1541 💅 A new DHCP message type, DHCPINFORM, has been added; see section 3.4, 4.3 and 4.4 for details ✨ The classing mechanism for identifying DHCP clients to DHCP servers has been extended to include "vendor" classes, as defined in sections 4.2 and 4.3 🎀 The minimum lease time restriction has been removed. Finally, many editorial changes clarify the text, thanks to experience gained in DHCP interoperability tests 🌸
1.2 Related Work 🦋
Several Internet protocols and related mechanisms tackle parts of the dynamic host configuration problem 🧚 The Reverse Address Resolution Protocol (RARP) [10] explicitly addresses network address discovery, and it includes an automatic IP address assignment mechanism. Its extensions, defined in the Dynamic RARP (DRARP) [5], go further. The Trivial File Transfer Protocol (TFTP) [20] transports a boot image from a boot server 💜 The Internet Control Message Protocol (ICMP) [16] informs hosts of additional routers via "ICMP redirect" messages. ICMP can also provide subnet mask information through the "ICMP mask request" message, and other information through the (obsolete) "ICMP information request" message. Hosts can locate 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] are defined for several configuration parameters. Morgan 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 with RARP, TFTP, and an RPC mechanism called "bootparams" to deliver configuration information 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] ✨ The Address Resolution Protocol (ARP) has been proposed 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.3 Problem definition and issues 🔥
DHCP is designed to supply DHCP clients with the configuration parameters defined in the Host Requirements RFCs 💖 After getting parameters via DHCP, a DHCP client should be able to exchange packets with any other host in the Internet 😭 The TCP/IP stack parameters DHCP supplies are listed in Appendix A 📚
Not all of these parameters are required for a newly initialized client 🧚 A client and server may negotiate for the transmission of only those parameters the client requires, or those specific to a particular subnet 🦋
DHCP allows but does not require the configuration of client parameters that aren't directly related to the IP protocol 💜 DHCP also doesn't address registering newly configured clients with the Domain Name System (DNS) [12, 13] 🍓
DHCP is not intended for configuring routers 🙈
1.4 Requirements
okay bestie, so there are these special capitalized words in this doc, and they're not just vibes, they're literal rules 💅 Every time you see one, it's doing real work:
- "MUST": ✨ This word, or the adjective "REQUIRED," means the item is an absolute requirement of this spec. No wiggle room, periodt.
- "MUST NOT": 🙈 This phrase means the item is an absolute prohibition of this spec. Absolutely not, no exceptions.
- "SHOULD": 🌸 This word, or the adjective "RECOMMENDED," means there might be valid reasons in certain situations to ignore the item. But the full implications should be understood, and the case should be carefully weighed before choosing a different path.
- "SHOULD NOT": 🍓 This phrase means there might be valid reasons in certain situations where the listed behavior is acceptable or even useful. Still, the full implications should be understood, and the case carefully weighed before doing anything described with this label.
- "MAY": 🦋 This word, or the adjective "OPTIONAL," means the item is truly optional. One vendor might include it because a marketplace requires it or because it makes the product better, for example. Another vendor might skip the same item, and both are totally fine 🫶
1.5 Terminology
okay so this document uses a few terms, and knowing them is literally the key to understanding everything else 🧚
- "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 (or just 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. Iconic continuity 👑
- "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.6 Design goals
okay, this section is literally the vision board for DHCP 🔥 Here's the list of general design goals:
- DHCP should be a mechanism rather than a policy. DHCP must let local system administrators control configuration parameters where they want to. For example, local admins should be able to enforce their own local policies about allocating and accessing local resources, if they want. 👑
- Clients should require no manual configuration. Each client should be able to discover the right local configuration parameters without any user intervention, and then fold those parameters into its own configuration. 💅
- Networks should require no manual configuration for individual clients. Under normal circumstances, the network manager shouldn't have to enter any per-client configuration parameters. 🫶
- 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 relay agents. 🦋
- A DHCP client must be prepared to receive multiple responses to a request for configuration parameters. Some installations 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 in RFC 951 and in RFC 1542 [21]. 🧚
- DHCP must provide service to existing BOOTP clients. 💖
The next list gives design goals specific to sending network layer parameters. DHCP must:
- Guarantee that any specific network address will not be in use by more than one DHCP client at a time. 🔒
- Retain DHCP client configuration across DHCP client reboots. A DHCP client should, whenever possible, be assigned the same configuration parameters (for example, a network address) in response to each request. 🍓
- Retain DHCP client configuration across server reboots. Whenever possible, a DHCP client should be assigned the same configuration parameters even if the DHCP mechanism restarts. 🌈
- Allow automated assignment of configuration parameters to new clients, so nobody has to hand-configure new clients. ⭐
- Support fixed or permanent allocation of configuration parameters to specific clients. 💜
2. Protocol Summary 🎀
okay bestie, from the client's point of view DHCP is basically an extension of BOOTP 🌸 so existing BOOTP clients can talk to DHCP servers without anyone touching their startup software. no cap, that's iconic. RFC 1542 [2] covers how BOOTP and DHCP clients and servers interact [9]. there are also some new optional transactions that make the client and server dance smoother, and we'll get into those in sections 3 and 4 ✨
Figure 1 shows what a DHCP message looks like and Table 1 explains every field in it 💅 the numbers in parentheses are how many octets each field takes up. the field names from the figure are what this whole doc uses, so pls memorize them 🧚
There are two main differences between DHCP and BOOTP 👑. First, DHCP lets clients get a network address on a finite lease, so addresses can be passed along to different clients one after another. Second, DHCP gives the client every IP configuration parameter it needs to actually operate. main character energy 💖
DHCP also made a small terminology glow-up 💜 the BOOTP "vendor extensions" field is now the "options" field, and the tagged data items that used to be called "vendor extensions" are now just "options." simple, clean, slay.
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 (variable) |
+---------------------------------------------------------------+
Figure 1: Format of a DHCP messageDHCP defines a new 'client identifier' option 🦋 it passes an explicit client identifier to the DHCP server. this fixes the old BOOTP mess where 'chaddr' was doing double duty as both the hardware address for sending BOOTP replies AND the client identifier 🙈 the 'client identifier' is an opaque key, so the server isn't supposed to interpret it. it can hold a hardware address (same as 'chaddr'), or some other kind of identifier, like a DNS name. The 'client identifier' chosen by a DHCP client MUST be unique to that client within the subnet to which the client is attached. If the client uses a 'client identifier' in one message, it MUST use that same identifier in all subsequent messages, so every server correctly identifies the client 🫶
DHCP also clarifies that 'siaddr' is the address of the server to use in the next step of the client's bootstrap process. a DHCP server may put its own address in 'siaddr' if it's ready to supply the next bootstrap service (like delivering an operating system executable image) 🌈 and a DHCP server ALWAYS returns its own address in the 'server identifier' option. (okay, technically that word is not in caps in the original, so I'm keeping it exactly as written: a DHCP server always returns its own address in the 'server identifier' option 💅)
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
began address acquisition or renewal process.
flags 2 Flags (see figure 2).
ciaddr 4 Client IP address; only filled in if client is in
BOUND, RENEW or REBINDING state and can respond
to ARP requests.
yiaddr 4 'your' (client) IP address.
siaddr 4 IP address of next server to use in bootstrap;
returned in DHCPOFFER, DHCPACK 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 var Optional parameters field. See the options
documents for a list of defined options.
Table 1: Description of fields in a DHCP messageThe 'options' field is now variable length 🌸 a DHCP client must be prepared to receive DHCP messages with an 'options' field of at least length 312 octets. that means a DHCP client must be prepared to receive a message of up to 576 octets, which is the minimum IP datagram size an IP host must be prepared to accept [3]. DHCP clients may negotiate larger DHCP messages through the 'maximum DHCP message size' option 🍓 and the options field may be further extended into the 'file' and 'sname' fields.
Now for the messy part 🙃 if a client is using DHCP for initial configuration (before its TCP/IP software is fully set up), DHCP needs some creative use of the client's TCP/IP software and a liberal interpretation of RFC 1122. The TCP/IP software SHOULD accept and forward to the IP layer any IP packets delivered to the client's hardware address before the IP address is configured. DHCP servers and BOOTP relay agents may not be able to deliver DHCP messages to clients that cannot accept hardware unicast datagrams before the TCP/IP software is configured 😭
To work around clients that can't accept IP unicast datagrams before their TCP/IP software is configured (the issue from the paragraph above), DHCP uses the 'flags' field [21]. The leftmost bit is defined as the BROADCAST (B) flag, and section 4.1 of this document explains what that flag means. 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 shows the format of the 'flags' field 💜
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' field2.1 Configuration parameters repository ✨
okay this part is lowkey my favorite 🧚 the first service DHCP provides is persistent storage of network parameters for network clients. the model is that the DHCP service stores a key-value entry for each client, where the key is some unique identifier (for example, an IP subnet number plus a unique identifier within that subnet) and the value holds the client's configuration parameters 💖
For example, the key might be the pair (IP-subnet-number, hardware-address). (note that the "hardware-address" should be typed by the type of hardware to accommodate possible duplication of hardware addresses resulting from bit-ordering problems in a mixed-media, bridged network 🙈) this lets the same hardware address be reused serially or concurrently on different subnets, and it also works for hardware addresses that aren't globally unique 🦋 Alternatively, the key might be the pair (IP-subnet-number, hostname). that lets the server assign parameters smartly to a client that has moved to a different subnet or changed hardware addresses (maybe the network interface failed and got replaced 😭). The protocol defines that the key will be (IP-subnet-number, hardware-address) unless the client explicitly supplies an identifier using the 'client identifier' option 🫶 A client can query the DHCP service to retrieve its configuration parameters. The client interface to the configuration parameters repository is protocol messages: requests for configuration parameters, and responses from the server carrying those parameters 👑
2.2. Dynamic allocation of network addresses 🌸
Okay so, the second thing DHCP does is hand out network (IP) addresses to clients, either temporarily or permanently 💖. The basic idea is super simple. A client asks to use an address for some amount of time. The allocation mechanism (that's the whole collection of DHCP servers) promises not to give that address to anyone else during the requested time, and it tries to give the client the same address every time it asks 🫶. This document calls that stretch of time a "lease" [11] ✨. The client can extend its lease by sending more requests 🦋. When it's done with the address, it can send a message to give it back to the server 💅.
Want a permanent address? The client can ask for an infinite lease 👑. Even then, though, a server might choose a long but not infinite lease so it can still notice when a client has been retired 🙈. Tbh that's a smart move.
Sometimes there aren't enough addresses to go around, so the allocation mechanism has to reuse ones whose lease has expired 💀. The server should use whatever info it has in the configuration information repository to pick which address to reuse 🧚. For example, it might pick the least recently assigned address 🍓. As a consistency check, the allocating server SHOULD probe the reused address before handing it out, e.g., with an ICMP echo request 🔥, and the client SHOULD probe its newly received address, e.g., with ARP 🎀. Double-checking is giving responsible, bestie 💜.
3. The Client-Server Protocol ✨
Here's where it gets fun 🌈. DHCP uses the BOOTP message format defined in RFC 951, which you can see in table 1 and figure 1 💖. Every DHCP message a client sends to a server has BOOTREQUEST in its op field 🫶. Every DHCP message a server sends back to a client uses BOOTREPLY in its op field 🦋.
The first four octets of the options field are the decimal values 99, 130, 83 and 99, in that order 🔮. This is the same magic cookie defined in RFC 1497 [17] ✨. After that cookie, the rest of the options field is a list of tagged parameters called "options" 💅. All the "vendor extensions" listed in RFC 1497 are DHCP options too, which is so iconic 👑. RFC 1533 has the complete list of options defined for DHCP 📚.
A handful of options exist already 🍓. One of them, the "DHCP message type" option, has to show up in every single DHCP message 🔥. It tells you what "type" of message it is 💜. Other options might be allowed, required, or not allowed, depending on the message type 🙈.
Throughout this document, a DHCP message with a 'DHCP message type' option gets named after its type 🎀. For example, a DHCP message whose 'DHCP message type' option is type 1 is called a "DHCPDISCOVER" message 🧚. Easy peasy, lemon squeezy 🍋✨.
3.1. Client-server interaction - allocating a network address ✨
Okay bestie, this is the play-by-play of how clients and servers chat when a client needs a network address 💅. It uses the DHCP messages from table 2 below, and figure 3 shows the timing in a typical interaction 🕰️. If the client already knows its address, some steps can get skipped. That shortcut lives in section 3.2 🦋.
Step 1: 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 🌸.
Step 2: Each server may respond with a DHCPOFFER message that includes an available network address in the yiaddr field (plus other configuration parameters in DHCP options) 🎁. Servers need not reserve the offered address, although things run more smoothly if the server avoids giving that same address to another client 🧚. When allocating a new address, servers SHOULD check that the offered address isn't 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 🙈. The server sends the DHCPOFFER message to the client, using the BOOTP relay agent if necessary 📬.
Table 2 is the cheat sheet for every DHCP message 📋:
Message Use
------- ---
DHCPDISCOVER - Client broadcast to locate available servers.
DHCPOFFER - Server to client in response to DHCPDISCOVER with
offer of configuration parameters.
DHCPREQUEST - Client message to servers either (a) requesting
offered parameters from one server and implicitly
declining offers from all others, (b) confirming
correctness of previously allocated address after,
e.g., system reboot, or (c) extending the lease on a
particular network address.
DHCPACK - Server to client with configuration parameters,
including committed network address.
DHCPNAK - Server to client indicating client's notion of network
address is incorrect (e.g., client has moved to new
subnet) or client's lease as expired
DHCPDECLINE - Client to server indicating network address is already
in use.
DHCPRELEASE - Client to server relinquishing network address and
cancelling remaining lease.
DHCPINFORM - Client to server, asking only for local configuration
parameters; client already has externally configured
network address.
Table 2: DHCP messagesFigure 3 is the timeline of who says what, and when 🗓️:
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 vFigure 3: Timeline diagram of messages exchanged between DHCP client and servers when allocating a new network address 🧾
Step 3: The client gets one or more DHCPOFFER messages from one or more servers 💌. It's allowed to wait for multiple responses if it wants to 🕒. Then it picks one server to ask for configuration parameters, based on what those offers are giving 👑. The client broadcasts a DHCPREQUEST message that MUST include the server identifier option to say which server it picked 🎯. It MAY include other options too, asking for specific configuration values 🍓. The requested IP address option MUST be set to the yiaddr value from the server's DHCPOFFER message 💖. This DHCPREQUEST is broadcast and relayed through DHCP/BOOTP relay agents 📡. To help make sure the relay agents forward it 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. It also MUST 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 😭.
Step 4: The servers receive the DHCPREQUEST broadcast from the client 📻. Any servers that weren't selected treat the message as a heads-up that the client declined their offer 🥲. The selected server commits the binding for the client to persistent storage, then responds with a DHCPACK message carrying the configuration parameters for the requesting client ✅. The combo of client identifier (or chaddr) and the assigned network address forms a unique identifier for the client's lease 🪪. Both the client and server use that combo to point to a lease in any DHCP messages 🫶. Any configuration parameters in the DHCPACK SHOULD NOT conflict with the ones in the earlier DHCPOFFER the client is answering 🙅. 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 theDHCPREQUEST(for example, the requested address has already been given out), the server SHOULD respond with aDHCPNAKmessage 🚫.
A server MAY choose to mark addresses it offered in DHCPOFFER messages as unavailable 🔒. The server SHOULD mark an offered address as available again if it gets no DHCPREQUEST from that client 🔓.
Step 5: The client gets the DHCPACK with its configuration parameters 🎉. It SHOULD do a final check on those parameters (for example, ARP for the allocated network address) and note the lease duration from the DHCPACK ⏳. At this point, the client is configured 💅. If the client finds the address is already in use (say, through ARP), it MUST send a DHCPDECLINE message to the server and restart the configuration process 🛑. Before restarting, it SHOULD wait a minimum of ten seconds, so a looping situation doesn't flood the network with traffic 🌀. If the client gets a DHCPNAK, it restarts the configuration process 🔄. If it gets neither a DHCPACK nor a DHCPNAK, it times out and retransmits the DHCPREQUEST ⏰. It does this following the retransmission algorithm in section 4.1 ✨. The client should choose to retransmit the DHCPREQUEST enough times to have a good chance of reaching the server, without making the client (and the person using it) wait forever before giving up 😩. For example, a client retransmitting as described in section 4.1 might send the DHCPREQUEST four times, for a total delay of 60 seconds, before restarting the initialization procedure ⏱️. If neither a DHCPACK nor a DHCPNAK shows up after the retransmission algorithm has run its course, the client reverts to INIT state and restarts initialization 🔁. The client SHOULD notify the user that initialization failed and is restarting 📣.
Step 6: 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 with chaddr and the network address in the DHCPRELEASE message 🗝️. If the client used a client identifier when it got the lease, it MUST use that same client identifier in the DHCPRELEASE message 💜.
3.2. Client-server interaction - reusing a previously allocated network address ✨
okay so if a client remembers and wants to reuse a network address it already got 🫶, it's allowed to skip some of the steps from the last section 💅. figure 4 shows the timing for a client doing this, and it's giving very clean timeline energy 🦋
- the client broadcasts a DHCPREQUEST message on its local subnet 📡. the message includes the client's network address in the
'requested IP address'option. since the client hasn't received its network address yet, it MUST NOT fill in the'ciaddr'field 🙅♀️. BOOTP relay agents pass the message on to DHCP servers that aren't on the same subnet. if the client used a'client identifier'to get its address, the client MUST use the same'client identifier'in the DHCPREQUEST message 🎀. - servers that know the client's configuration parameters respond with a DHCPACK message to the client 💌. Servers SHOULD NOT check that the client's network address is already in use. the client may respond to ICMP Echo Request messages at this point 🙈.
Server Client Server
v v v
| | |
| Begins |
| initialization |
| | |
| /|\ |
| _________ __/ | \__________ |
| /DHCPREQU EST | DHCPREQUEST\ |
|/ | \|
| | |
Locates | Locates
configuration | configuration
| | |
|\ | /|
| \ | ___________/ |
| \ | / DHCPACK |
| \ _______ |/ |
| DHCPACK\ | |
| Initialization |
| complete |
| \| |
| | |
| (Subsequent |
| DHCPACKS |
| ignored) |
| | |
| | |
v v v Figure 4: Timeline diagram of messages exchanged between DHCP
client and servers when reusing a previously allocated
network addressokay now the spicy part 🌶️. if the client's request is invalid (like, the client moved to a new subnet 🧳), servers SHOULD respond with a DHCPNAK message to the client. but servers SHOULD NOT respond if their information isn't guaranteed to be accurate 🤨. for example, a server that spots a request for an expired binding owned by another server SHOULD NOT respond with a DHCPNAK, unless the servers are using an explicit mechanism to keep coherency among themselves 💀.
if 'giaddr' is 0x0 in the DHCPREQUEST message, the client is on the same subnet as the server 👯. the server MUST broadcast the DHCPNAK message to the 0xffffffff broadcast address, because the client might not have a correct network address or subnet mask, and it might not be answering ARP requests 📢. otherwise, the server MUST send the DHCPNAK message to the IP address of the BOOTP relay agent, as recorded in 'giaddr'. the relay agent will then forward it directly to the client's hardware address, so the DHCPNAK can still get delivered even if the client has moved to a new network 🚚✨.
- the client receives the DHCPACK message with configuration parameters 🎁. it does a final check on the parameters (same as in section 3.1) and notes the duration of the lease in the DHCPACK message. the specific lease is implicitly identified by the
'client identifier'or'chaddr'and the network address. at this point, the client is configured 🥳.
if the client detects that the IP address in the DHCPACK message is already in use, the client MUST send a DHCPDECLINE message to the server and restart the configuration process by requesting 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.
if the client receives a DHCPNAK message, it can't reuse its remembered network address. it has to request a new address by restarting the configuration process, this time using the (non-abbreviated) procedure from section 3.1 🔄. this also means the client moves to the INIT state in the DHCP state diagram.
the client times out and retransmits the DHCPREQUEST message if it gets neither a DHCPACK nor a DHCPNAK message ⏰. it retransmits according to the retransmission algorithm in section 4.1. the client should choose to retransmit the DHCPREQUEST enough times to get a good chance of reaching the server, without making the client (and the person using it) wait overly long before giving up. e.g., a client retransmitting as described in section 4.1 might retransmit the DHCPREQUEST message four times, for a total delay of 60 seconds, before restarting the initialization procedure 🕐. if the client gets neither a DHCPACK nor a DHCPNAK message after using the retransmission algorithm, the client 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 👋. it identifies the lease to be released with its
'client identifier', or with'chaddr'and the network address, in the DHCPRELEASE message.
note that in this case, where the client keeps its network address locally, the client won't normally give up its lease during a graceful shutdown 🛑. only when the client really needs to give up its lease (e.g., it's about to be moved to a different subnet) will it send a DHCPRELEASE message 📦.
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" 💜.
clients and servers might not have synchronized clocks, so 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 from 0 to approximately 100 years, which is plenty for measuring relative times in DHCP 🙌.
the lease duration algorithm in the previous paragraph assumes that the client and server clocks are stable relative to each other. if there's drift between the two clocks, the server may consider the lease expired before the client does 😵💫. to make up for that, 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. Obtaining parameters with externally configured network address 🔧
if a client got a network address some other way (e.g., manual configuration), it may use a DHCPINFORM request message to get other local configuration parameters 🛠️. servers that receive a DHCPINFORM message build a DHCPACK message with any local configuration parameters that fit the client, but without allocating a new address, checking for an existing binding, filling in 'yiaddr', or including lease time parameters 🙅. the servers SHOULD unicast the DHCPACK reply to the address given in the 'ciaddr' field of the DHCPINFORM message 🎯.
The server SHOULD check the network address in a DHCPINFORM message for consistency, but MUST NOT check for an existing lease. the server forms a DHCPACK message containing the configuration parameters for the requesting client and sends it directly to the client 📬.
3.5. Client parameters in DHCP 🧁
not all clients need every parameter listed in Appendix A 🙃. there are two techniques used to cut down 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 doesn't get any parameters from the server that override the defaults, it uses those default values 🫧. second, in its initial DHCPDISCOVER or DHCPREQUEST message, a client may give the server a list of specific parameters it's interested in 📝. if the client includes a list of parameters in a DHCPDISCOVER message, it MUST include that list in any later DHCPREQUEST messages 🔁.
The client SHOULD include the 'maximum DHCP message size' option to let the server know how big the server is allowed to make its DHCP messages 📏. the parameters returned to a client might still be bigger than the space allocated to options in a DHCP message. when that happens, two additional options flags (which must appear in the 'options' field of the message) say that the 'file' and 'sname' fields are to be used for options 🗂️.
the client can tell the server which configuration parameters it cares about by including the 'parameter request list' option 💅. the data portion of this option lists the requested options by tag number 🏷️.
the client may also suggest values for the network address and lease time in the DHCPDISCOVER message 💭. it may include the 'requested IP address' option to suggest that a particular IP address be assigned, and it may include the 'IP address lease time' option to suggest the lease time it'd like ⏱️. other options representing "hints" at configuration parameters are allowed in a DHCPDISCOVER or DHCPREQUEST message. however, servers may ignore those additional options, so multiple servers may not return identical values for some options 🤷♀️. the 'requested IP address' option is only filled in on a DHCPREQUEST message when the client is verifying network parameters it got before 🔍. the client fills in the 'ciaddr' field only when it's correctly configured with an IP address in the BOUND, RENEWING or REBINDING state 🌸.
if a server receives a DHCPREQUEST message with an invalid 'requested IP address', the server SHOULD respond 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.6. Use of DHCP in clients with multiple interfaces 🌈
a client with multiple network interfaces must use DHCP through each interface independently to get configuration information parameters for those separate interfaces 🦋✨.
3.7. When clients should use DHCP 🦋
okay so a client SHOULD use DHCP to reacquire or verify its IP address and network parameters whenever the local network parameters may have changed 👀 like at system boot or after it gets disconnected from the local network, bc the local network config can change without the client or the user knowing. literally so sneaky 💀
if a client knows a previous network address but can't reach a local DHCP server, it may keep using that previous address until the lease runs out 🫶 but if the lease expires before the client can reach a DHCP server, the client must immediately stop using that previous address, and it may tell local users what's going on. no cap, that's a hard stop 😭
4. Specification of the DHCP client-server protocol 🎀
this part assumes a DHCP server has a block of network addresses it can hand out when someone asks for a new one 🧚 each server also keeps a database of allocated addresses and leases in local permanent storage 💜
4.1. Constructing and sending DHCP messages 💅
both DHCP clients and servers build their messages by filling in the fields in the fixed format section and then tacking tagged data items onto the variable length option area 🌸 the options area starts with a four-octet 'magic cookie' (which was described in section 3), and then come the options. the last option must always be the 'end' option, no exceptions 🙈
DHCP uses UDP as its transport protocol 🍓 messages from a client to a server go to the 'DHCP server' port (67), and messages from a server to a client go to the 'DHCP client' port (68). a server with multiple network addresses (like a multi-homed host) MAY use any of its network addresses in outgoing DHCP messages ✨
the 'server identifier' field does two jobs: it identifies a DHCP server inside a DHCP message, and it's the destination address clients use when talking to servers 🫶 a server with multiple network addresses MUST be ready to accept any one of them as identifying that server in a DHCP message 🔥 bc connectivity can be incomplete, a server MUST pick an address for its 'server identifier' that, as far as it knows, the client can reach 💖 for example, if the DHCP server and the DHCP client are on the same subnet (so the 'giaddr' field in the client's message is zero), the server SHOULD pick the IP address it's using to talk on that subnet as the 'server identifier' 👑 if it's using several IP addresses on that subnet, any of them can be used. if the server got the message through a DHCP relay agent, it SHOULD choose an address from the interface the message was received on as the 'server identifier' (unless it has other, better info to make the choice with) 🌈 and DHCP clients MUST use the IP address from the 'server identifier' option for any unicast requests to the DHCP server 💅
DHCP messages broadcast by a client before it has its IP address must have the source address field in the IP header set to 0. 🙈
if the 'giaddr' field in a DHCP message from a client is non-zero, the server sends any return messages to the 'DHCP server' port on the BOOTP relay agent whose address is in 'giaddr' 🧚 if 'giaddr' is zero and 'ciaddr' is nonzero, the server unicasts DHCPOFFER and DHCPACK messages to the address in 'ciaddr' 💜 if 'giaddr' and 'ciaddr' are both zero and the broadcast bit is set, the server broadcasts DHCPOFFER and DHCPACK messages to 0xffffffff 🦋 if the broadcast bit is not set and 'giaddr' and 'ciaddr' are both zero, the server unicasts DHCPOFFER and DHCPACK messages to the client's hardware address and the 'yiaddr' address 🌸 and in every case where 'giaddr' is zero, the server broadcasts any DHCPNAK messages to 0xffffffff ⭐
now the overload rules, which are kinda intense but iconic 🔥 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 RFC 1533 🎀 when 'option overload' is in the 'options' field, the options in 'options' MUST be terminated by an 'end' option, and they MAY contain one or more 'pad' options to fill the options field 🫶 the options in the 'sname' and 'file' fields (if they're in use, as the 'option overload' option says) MUST begin at 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 single 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 👑 then the 'file' field MUST be interpreted next (if 'option overload' says the 'file' field holds DHCP options), followed by the 'sname' field 🌈
some option values are too long for the 255 octets a single option can hold (like a list of routers in a 'router' option [21]) 😭 options may appear only once, unless the options document says otherwise, and the client concatenates the values of multiple instances of the same option into one parameter list for configuration 🍓
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 SHOULD be chosen to give replies from the server enough time to arrive, based on the characteristics of the internetwork between the client and the server 💅 for example, on a 10Mb/sec Ethernet internetwork, the delay before the first retransmission SHOULD be 4 seconds, randomized by a uniform random number from the range -1 to +1 🦋 clients whose clocks have sub-second resolution may pick a non-integer randomization value 🧚 the delay before the next retransmission SHOULD be 8 seconds, randomized by a uniform number from the range -1 to +1 🌸 the retransmission delay SHOULD be doubled with each later retransmission, up to a max of 64 seconds 💜 and the client MAY show the user retransmission attempts as a sign that configuration is making progress ⭐
the 'xid' field is how the client matches incoming DHCP messages to its pending requests 🫶 a DHCP client MUST choose 'xid's so that the chance of using an 'xid' that another client is also using is minimized 💖 for example, a client may pick a different random initial 'xid' each time it reboots, and then use sequential 'xid's until the next reboot 🎀 picking a new 'xid' for each retransmission is an implementation decision 👑 a client may reuse the same 'xid' or pick a new one for each retransmitted message 🌈
normally, 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 😭 which creates a deadlock: the client's IP address can't be delivered until the client has been given an IP address 💀
a client that can't receive unicast IP datagrams until its protocol software has 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 telling the DHCP server and BOOTP relay agent to broadcast messages to the client on the client's subnet 🦋 a client that can receive unicast IP datagrams before its protocol software is configured SHOULD clear the BROADCAST bit to 0 🍓 the BOOTP clarifications document talks about the ramifications of using the BROADCAST bit [21] ✨
when a server or relay agent sends or relays a DHCP message directly to a DHCP client (so, not to a relay agent named in the 'giaddr' field), it SHOULD examine the BROADCAST bit in the 'flags' field 🧚 if that bit is set to 1, the message SHOULD be sent as an IP broadcast, using an IP broadcast address (preferably 0xffffffff) 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 💖 and if unicasting isn't possible, the message MAY be sent as an IP broadcast, again using an IP broadcast address (preferably 0xffffffff) 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 are not required to answer every DHCPDISCOVER and DHCPREQUEST they get 🙈. A network admin who wants tight control over who joins the network might set servers to respond only to clients that were registered in advance through some outside process. The DHCP spec only covers what happens when clients and servers decide to talk to each other. Describing every admin control out there is beyond its scope 💅. Individual server implementations can bake in whatever controls or policies a network admin wants.
In some environments, a server has to look at the vendor class options that come in DHCPDISCOVER or DHCPREQUEST messages before it can work out the right parameters for a particular client 🎀.
A DHCP server needs some unique identifier to link a client to its lease 🔗. The client MAY explicitly supply that identifier through the 'client identifier' option. If the client does supply a 'client identifier', it MUST use the same 'client identifier' in all later messages, and the server MUST use that identifier to recognize the client. If the client doesn't send a 'client identifier' option, the server MUST use the contents of the 'chaddr' field to identify the client. It's super important for a DHCP client to pick an identifier that's unique within the subnet it's attached to, and to put it in the 'client identifier' option 💖. Using 'chaddr' as the unique identifier can lead to unexpected results, since that value is tied to a hardware interface that could get moved to a different client 😭. Some sites like to use a manufacturer's serial number as the 'client identifier' so a client's network address doesn't randomly change when hardware gets shuffled between computers 🧚. Sites can also use a DNS name as the 'client identifier', which ties address leases to the DNS name instead of one specific hardware box 🌈.
Clients are free to use any strategy they like for picking a DHCP server out of the ones that send them a DHCPOFFER message 👑. The client implementation of DHCP SHOULD provide a way for the user to pick the 'vendor class identifier' values directly ⭐.
4.3. DHCP server behavior
A DHCP server handles each incoming DHCP message from a client based on the current state of the binding for that client 🦋. A server can receive these messages from a client:
- DHCPDISCOVER
- DHCPREQUEST
- DHCPDECLINE
- DHCPRELEASE
- DHCPINFORM
Table 3 shows how a server uses the fields and options in a DHCP message 💜. The rest of this section walks through what the server does for each possible incoming message 🍓.
4.3.1. DHCPDISCOVER message
When a server gets a DHCPDISCOVER message from a client, it picks a network address for that client 🌸. If no address is free, the server may choose to report the problem to the system administrator. If an address is free, the new address SHOULD be chosen like this:
- The client's current address as recorded in the client's current binding, ELSE
- The client's previous address as recorded in the client's (now expired or released) binding, if that address is in the server's pool of available addresses and not already allocated, ELSE
- The address requested in the
'Requested IP Address'option, if that address is valid and not already allocated, ELSE - A new address allocated from the server's pool of available addresses; the address is selected based on the subnet from which the message was received (if
'giaddr'is 0) or on the address of the relay agent that forwarded the message ('giaddr'when not 0).
As covered in section 4.2, a server MAY, for administrative reasons, assign an address other than the one requested, or it may refuse to allocate an address to a particular client even when free addresses are available 🙅♀️.
Heads up: in some network setups (for example, internets with more than one IP subnet on a single physical network segment), the DHCP client might need an address from a different subnet than the one recorded in 'giaddr' 🧩. So DHCP doesn't require the client to get an address from the subnet in 'giaddr'. The server is free to pick some other subnet, and how the assigned IP address gets chosen is beyond the scope of the DHCP spec ✨.
Not required for DHCP to work correctly, but the server SHOULD NOT reuse the selected network address before the client responds to the server's DHCPOFFER message 💅. The server may choose to record the address as offered to the client.
The server must also pick an expiration time for the lease, like so 🕰️:
- IF the client has not requested 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 has not requested a specific lease in the DHCPDISCOVER message and the client does not have an assigned network address, the server assigns a locally configured default lease time, ELSE
- IF the client has requested 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 the lease is acceptable to local policy) or select another lease.
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 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' 'flags' from 'flags' from 'flags' from
client DHCPDISCOVER client DHCPREQUEST client DHCPREQUEST
message message message
'giaddr' 'giaddr' from 'giaddr' from 'giaddr' from
client DHCPDISCOVER client DHCPREQUEST client DHCPREQUEST
message message message
'chaddr' 'chaddr' from 'chaddr' from 'chaddr' from
client DHCPDISCOVER client DHCPREQUEST client DHCPREQUEST
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 options
Option DHCPOFFER DHCPACK DHCPNAK
------ --------- ------- -------
Requested IP address MUST NOT MUST NOT MUST NOT
IP address lease time MUST MUST (DHCPREQUEST) MUST NOT
MUST NOT (DHCPINFORM)
Use 'file'/'sname' fields MAY MAY MUST NOT
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 MAY
Vendor class identifier MAY MAY MAY
Server identifier MUST MUST MUST
Maximum message size MUST NOT MUST NOT MUST NOT
All others MAY MAY MUST NOT
Table 3: Fields and options used by DHCP serversOnce the server has settled on the network address and the lease, it builds a DHCPOFFER message with the configuration parameters it's offering 🎁. It really matters that all DHCP servers return the same parameters (other than maybe a freshly allocated network address) so clients act predictably no matter which server they pick 🫶. The configuration parameters MUST be chosen by applying the following rules, in the order given. Network admins are responsible for setting up multiple DHCP servers so their responses match. The server MUST return the following to the client:
- The client's network address, as determined by the rules given earlier in this section,
- The expiration time for the client's lease, as determined by the rules given earlier in this section,
- Parameters requested by the client, according to 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 a parameter 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
The server MUST supply as many of the requested parameters as possible and MUST omit any parameters it cannot provide. The server MUST include each requested parameter only once unless explicitly allowed in the DHCP Options and BOOTP Vendor Extensions document.
- Any parameters from the existing binding that differ from the Host Requirements Document defaults,
- Any parameters specific to this client (as identified by the contents of
'chaddr'or'client identifier'in the DHCPDISCOVER or DHCPREQUEST message), e.g., as configured by the network administrator, - Any parameters specific to this client's class (as identified by the contents of the
'vendor class identifier'option in the DHCPDISCOVER or DHCPREQUEST message), e.g., as configured by the network administrator. The parameters MUST be identified by an exact match between the client's vendor class identifiers and the client's classes identified in the server, - Parameters with non-default values on the client's subnet.
The server MAY choose to return the 'vendor class identifier' it used to pick the parameters in the DHCPOFFER message, which helps the client decide which DHCPOFFER to accept 🦄. The server copies the 'xid' field from the DHCPDISCOVER message into the 'xid' field of the DHCPOFFER message, then sends that DHCPOFFER to the requesting client 🎉.
4.3.2 DHCPREQUEST message ✨
Okay bestie, the DHCPREQUEST message is the client basically saying "ok I choose you 💅" or "hey can I keep my address pls 🥺". It can come from three different vibes: a client answering a DHCPOFFER, a client double-checking an address it already has, or a client trying to extend its lease 🦋. If the message has a server identifier option, it's answering an offer. If it doesn't, it's a request to verify or extend an existing lease. 🌸
Also, consistency is everything here 👑. If the client uses a client identifier in a DHCPREQUEST message, it MUST use that exact same client identifier in every message after that. And if the client put a list of requested parameters in its DHCPDISCOVER message, it MUST include that same list in all the later messages too. No switching up halfway through, periodt 💖
Any configuration parameters in the DHCPACK message SHOULD NOT conflict with the ones in the earlier DHCPOFFER the client is answering 🎀. The client SHOULD use the parameters from the DHCPACK for its configuration ✨.
Clients send DHCPREQUEST messages like this:
DHCPREQUESTgenerated duringSELECTINGstate:- The client puts the address of the chosen server in
server identifier.ciaddrMUST be zero, andrequested IP addressMUST be filled in with theyiaddrvalue from the chosen DHCPOFFER. - Lowkey this is the "shopping" moment 🛍️. The client might collect a bunch of DHCPOFFER messages and pick the "best" one. It shows its pick by naming the offering server in the DHCPREQUEST. If it gets no acceptable offers, it may choose to try another DHCPDISCOVER message instead. So the servers might never see a DHCPREQUEST that tells them whether the client took their offer 🙈. Since servers haven't committed any address on the basis of 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 mechanism to decide when an offered address can be reused ⏳.
- The client puts the address of the chosen server in
DHCPREQUESTgenerated duringINIT-REBOOTstate:server identifierMUST NOT be filled in. Therequested IP addressoption MUST be filled in with the client's notion of its previously assigned address, andciaddrMUST be zero. The client is basically checking that its cached configuration is still legit 🧐. The server SHOULD send a DHCPNAK message to the client if therequested IP addressis incorrect, or if it's on the wrong network 🚫.- Figuring out whether an
INIT-REBOOTclient is on the right network is a whole investigation 🔍. The server looks atgiaddr, therequested IP addressoption, and does a database lookup. If the server finds the client is on the wrong net (meaning applying the local subnet mask, or the remote subnet mask whengiaddrisn't zero, to therequested IP addressoption value doesn't match reality), the server SHOULD send a DHCPNAK message to the client. - If the network is correct, the DHCP server should check whether the client's notion of its IP address is correct. If it isn't, the server SHOULD send a DHCPNAK message to the client. If the DHCP server has no record of this client, then it MUST remain silent, and it MAY output a warning to the network administrator. This is what keeps non-communicating DHCP servers peacefully coexisting on the same wire 🤝 so no drama.
- If
giaddris 0x0 in the DHCPREQUEST message, the client is on the same subnet as the server. The server MUST broadcast the DHCPNAK message to the 0xffffffff broadcast address, because the client might not have a correct network address or subnet mask, and it might not be answering ARP requests 📡. - If
giaddris set in the DHCPREQUEST message, the client is on a different subnet. The server MUST set the broadcast bit in the DHCPNAK, so the relay agent will broadcast the DHCPNAK to the client, for the same reasons: the client might not have a correct network address or subnet mask, and it might not be answering ARP requests 🧃.
DHCPREQUESTgenerated duringRENEWINGstate:server identifierMUST NOT be filled in. Therequested IP addressoption MUST NOT be filled in.ciaddrMUST be filled in with the client's IP address. This client is fully configured and just trying to extend its lease 🌈. This message gets unicast, so no relay agents are involved in sending it. Sincegiaddrisn't filled in, the DHCP server trusts the value inciaddrand uses it when replying to the client.- A client MAY choose to renew or extend its lease before T1 ⏰. The server may choose not to extend the lease, as a policy decision by the network administrator, but it should return a DHCPACK message regardless 💜.
DHCPREQUESTgenerated duringREBINDINGstate:server identifierMUST NOT be filled in. Therequested IP addressoption MUST NOT be filled in.ciaddrMUST be filled in with the client's IP address. Same energy as before: the client is fully configured and trying to extend its lease 🍓. This message MUST be broadcast to the 0xffffffff IP broadcast address. The DHCP server SHOULD checkciaddrfor correctness before replying to the DHCPREQUEST 🔎.- The DHCPREQUEST from a REBINDING client is meant for sites with multiple DHCP servers and some mechanism for keeping the leases managed by those servers consistent 🧩. A DHCP server MAY extend a client's lease only if it has local administrative authority to do so 🙌.
4.3.3 DHCPDECLINE message
If the server gets a DHCPDECLINE message, the client has found out some other way that the suggested network address is already in use 😬. The server MUST mark that network address as not available, and it SHOULD notify the local system administrator of a possible configuration problem 📣.
4.3.4 DHCPRELEASE message
When the server receives a DHCPRELEASE message, it marks the network address as not allocated 🕊️. The server SHOULD retain a record of the client's initialization parameters, so it can reuse them if the client asks again later 💾.
4.3.5 DHCPINFORM message
The server answers a DHCPINFORM message by sending a DHCPACK message directly to the address given in the ciaddr field of the DHCPINFORM message 📬. The server MUST NOT send a lease expiration time to the client, and it SHOULD NOT fill in yiaddr. It includes other parameters in the DHCPACK message as defined in section 4.3.1 🧁.
4.3.6 Client messages
Table 4 breaks down how messages from clients differ depending on their state 📊.
---------------------------------------------------------------------
| |INIT-REBOOT |SELECTING |RENEWING |REBINDING |
---------------------------------------------------------------------
|broad/unicast |broadcast |broadcast |unicast |broadcast |
|server-ip |MUST NOT |MUST |MUST NOT |MUST NOT |
|requested-ip |MUST |MUST |MUST NOT |MUST NOT |
|ciaddr |zero |zero |IP address |IP address|
---------------------------------------------------------------------
Table 4: Client messages from different states4.4 DHCP client behavior 🦋
Figure 5 is a state-transition diagram for a DHCP client 🗺️. A client can receive these messages from a server:
DHCPOFFERDHCPACKDHCPNAK
The DHCPINFORM message isn't shown in figure 5. A client just sends the DHCPINFORM and waits for DHCPACK messages 🙏. Once the client has picked its parameters, it's finished with the configuration process 🎉.
Table 5 shows how a client uses the fields and options in a DHCP message. The rest of this section describes what the DHCP client does for each possible incoming message 💅. The description in the following section matches the full configuration procedure from section 3.1, and the text after that matches the abbreviated configuration procedure from section 3.2 ✨.
-------- -------
| | +-------------------------->| |<-------------------+
| INIT- | | +-------------------->| INIT | |
| REBOOT |DHCPNAK/ +---------->| |<---+ |
| |Restart| | ------- | |
-------- | DHCPNAK/ | | |
| Discard offer | -/Send DHCPDISCOVER |
-/Send DHCPREQUEST | | |
| | | DHCPACK v | |
----------- | (not accept.)/ ----------- | |
| | | Send DHCPDECLINE | | |
| REBOOTING | | | | SELECTING |<----+ |
| | | / | | |DHCPOFFER/ |
----------- | / ----------- | |Collect |
| | / | | | replies |
DHCPACK/ | / +----------------+ +-------+ |
Record lease, set| | v Select offer/ |
timers T1, T2 ------------ send DHCPREQUEST | |
| +----->| | 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 clients4.4.1 Initialization and allocation of network address 🌸
okay so the client starts out in INIT state and whips up a DHCPDISCOVER message 💖 it SHOULD wait a random time between one and ten seconds so it doesn't show up at the same time as everyone else at startup 🫶 then it sets 'ciaddr' to 0x00000000. it MAY request 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 if that's needed for DHCP reply messages to actually get delivered 💅 it MAY include a different unique identifier in the 'client identifier' option, which we'll get into in section 4.2 🎀 and if the client put a list of requested parameters in its DHCPDISCOVER, it MUST include that same list in every message after that 👑
the client generates a random transaction identifier, stores it, and puts it in the 'xid' field 🦋 it also records its own local time so it can work out the lease expiration later ⏰ then it broadcasts the DHCPDISCOVER to the local hardware broadcast address and the 0xffffffff IP broadcast address, using the 'DHCP server' UDP port 🌈
if the 'xid' of a DHCPOFFER that shows up doesn't match the 'xid' of the most recent DHCPDISCOVER, that DHCPOFFER must be silently discarded 💀 and any DHCPACK messages that arrive must be silently discarded too, no exceptions 🙈
the client collects DHCPOFFER messages for a while, then picks one out of the (possibly many) that came in. it could go with the first one, or the one from the server it used last time 🍓 then it pulls the server address out of the 'server identifier' option in that DHCPOFFER ✨ how long it collects offers and how it picks one are totally up to the implementation, so do your thing 💜
Field DHCPDISCOVER DHCPREQUEST DHCPDECLINE,
DHCPINFORM DHCPRELEASE
----- ------------ ----------- -----------
'op' BOOTREQUEST BOOTREQUEST BOOTREQUEST
'htype' (From "Assigned Numbers" RFC)
'hlen' (Hardware address length in octets)
'hops' 0 0 0
'xid' selected by client 'xid' from server selected by
DHCPOFFER message client
'secs' 0 or seconds since 0 or seconds since 0
DHCP process started DHCP process started
'flags' Set 'BROADCAST' Set 'BROADCAST' 0
flag if client flag if client
requires broadcast requires broadcast
reply reply
'ciaddr' 0 (DHCPDISCOVER) 0 or client's 0 (DHCPDECLINE)
client's network address client's network
network address (BOUND/RENEW/REBIND) address
(DHCPINFORM) (DHCPRELEASE)
'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
unused unused
'options' options options (unused)Option DHCPDISCOVER DHCPREQUEST DHCPDECLINE,
DHCPINFORM DHCPRELEASE
------ ------------ ----------- -----------
Requested IP address MAY MUST (in MUST
(DISCOVER) SELECTING or (DHCPDECLINE),
MUST NOT INIT-REBOOT) MUST NOT
(INFORM) MUST NOT (in (DHCPRELEASE)
BOUND or
RENEWING)
IP address lease time MAY MAY MUST NOT
(DISCOVER)
MUST NOT
(INFORM)
Use 'file'/'sname' fields MAY MAY MAY
DHCP message type DHCPDISCOVER/ DHCPREQUEST DHCPDECLINE/
DHCPINFORM DHCPRELEASE
Client identifier MAY MAY MAY
Vendor class identifier MAY MAY MUST NOT
Server identifier MUST NOT MUST (after MUST
SELECTING)
MUST NOT (after
INIT-REBOOT,
BOUND, RENEWING
or REBINDING)
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 MAY MAY MUST NOT
Table 5: Fields and options used by DHCP clientsonce the parameters look good, the client writes down the address of the server that gave them, using the 'server identifier' field, and sends that same address in the 'server identifier' field of a DHCPREQUEST broadcast message 🎀 when the DHCPACK from the server shows up, the client is all set up and moves into BOUND state 🥳 the DHCPREQUEST has the same 'xid' as the DHCPOFFER, and the client works out the lease expiration as the time it sent the original request plus the lease duration from the DHCPACK 💖
the client SHOULD check that the suggested address isn't already being used 🙈 for example, if the network supports ARP, the client may issue an ARP request for the suggested address. 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 with ARP caches on other hosts on the same subnet 🧚 if the address looks like it's already in use, the client MUST send a DHCPDECLINE message to the server 😭 and the client SHOULD broadcast an ARP reply to announce its new IP address and clear out any outdated ARP cache entries on hosts on its subnet 📣
4.4.2 Initialization with known network address ✨
the client starts out in INIT-REBOOT state and sends a DHCPREQUEST message 🌈 it MUST insert its known network address as a 'requested IP address' option in that DHCPREQUEST 💅 it may request specific configuration parameters by including the 'parameter request list' option 🍓 it generates a random transaction identifier, records it, and puts it in the 'xid' field 🦋 it also records its own local time so it can compute the lease expiration later ⏰ the client MUST NOT include a 'server identifier' in the DHCPREQUEST message 🙅 then it broadcasts the DHCPREQUEST to the local hardware broadcast address using the 'DHCP server' UDP port 📡
once a DHCPACK with an 'xid' field matching the one in the client's DHCPREQUEST shows up from any server, the client is initialized and moves into BOUND state 🎉 the client works out the lease expiration as the time the DHCPREQUEST was sent plus the lease duration from the DHCPACK 👑
4.4.3 Initialization with an externally assigned network address 🌷
the client sends a DHCPINFORM message 💜 it may request specific configuration parameters by including the 'parameter request list' option ✨ it generates a random transaction identifier, records it, and puts it in the 'xid' field 🦋 the client puts its own network address in the 'ciaddr' field 🎀 and the client SHOULD NOT request lease time parameters, since this one is already set up externally 🙅
then the client unicasts the DHCPINFORM to the DHCP server if it knows the server's address. otherwise, it broadcasts the message to the limited (all 1s) broadcast address 📡 DHCPINFORM messages MUST be directed to the 'DHCP server' UDP port 🫶
once a DHCPACK with an 'xid' field matching the one in the client's DHCPINFORM arrives from any server, the client is initialized 🥳
if the client doesn't get a DHCPACK within a reasonable amount of time (60 seconds or 4 tries if it's using the timeout suggested in section 4.1), then it SHOULD display a message to the user about the problem 📣 and then it SHOULD start network processing using suitable defaults, as per Appendix A 🛟
4.4.4 Use of broadcast and unicast 🦋
the DHCP client broadcasts DHCPDISCOVER, DHCPREQUEST and DHCPINFORM messages, unless the client knows the address of a DHCP server 📡 the client unicasts DHCPRELEASE messages to the server 💌 and since the client is turning down the IP address the server gave it, the client broadcasts DHCPDECLINE messages 🙅
when the DHCP client knows a DHCP server's address, whether it's in INIT or REBOOTING state, it may use that address in its DHCPDISCOVER or DHCPREQUEST instead of the IP broadcast address 💅 it may also unicast DHCPINFORM messages to a known DHCP server 🎀 but 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 🔁
4.4.5 Reacquisition and expiration 🔄✨
Okay bestie, so the client keeps track of two timers, T1 and T2 🕰️. They decide when it tries to extend its lease on its network address. T1 is when the client goes into the RENEWING state and tries to reach the server that originally handed out its address. T2 is when it goes into the REBINDING state and tries to reach any server 😱. T1 MUST be earlier than T2, and T2 MUST be earlier than the moment the client's lease actually expires. Non-negotiable, no cap 💅.
No clock syncing drama here 🙅♀️. T1 and T2 get sent in options as relative times [2].
At time T1 the client slides into the RENEWING state and sends a DHCPREQUEST message (via unicast) to the server, asking to extend its lease 💌. The client sets the ciaddr field in the DHCPREQUEST to its current network address. It also records the local time when that DHCPREQUEST goes out, because it needs that for working out the lease expiration time ⏱️. The client MUST NOT include a server identifier in the DHCPREQUEST message. Main character energy, but make it make sense 🎀.
Any DHCPACK messages with an xid that doesn't match the xid of the client's DHCPREQUEST message get silently discarded 🫥. Not your message, bestie. When the client gets a DHCPACK from the server, it works out the lease expiration time by adding the time it sent the DHCPREQUEST to the duration of the lease in that DHCPACK. Iconic math ✨. The client has successfully reacquired its network address, goes back to the BOUND state, and may keep on with network processing 🎉.
If no DHCPACK shows up before T2, the client moves to the REBINDING state and sends a DHCPREQUEST message (via broadcast) to extend its lease 📢. It sets the ciaddr field in the DHCPREQUEST to its current network address. Same deal as before: the client MUST NOT include a server identifier in the DHCPREQUEST message 🙅♀️.
T1 and T2 are configurable by the server through options 🎛️. T1 defaults to (0.5 * duration_of_lease) and T2 defaults to (0.875 * duration_of_lease). Times T1 and T2 SHOULD be chosen with some random "fuzz" around a fixed value, so that a whole crowd of clients doesn't try to reacquire at the exact same moment 🌪️. Very strategic.
A client MAY choose to renew or extend its lease before T1 🏃♀️. The server MAY choose to extend the client's lease according to policy set by the network administrator 🧑💼. The server SHOULD return T1 and T2, and their values SHOULD be adjusted from the original values to account for the time remaining on the lease ⏳.
In both the RENEWING and REBINDING states, if the client gets no response to its DHCPREQUEST message, it SHOULD wait before retransmitting. In RENEWING it waits one-half of the remaining time until T2, and in REBINDING it waits one-half of the remaining lease time. The wait goes down to a minimum of 60 seconds 🧘♀️. Patience is a whole aesthetic 🌸.
If the lease expires before the client receives a DHCPACK, the client moves to the INIT state. It MUST immediately stop any other network processing 🛑 and requests network initialization parameters as if the client were uninitialized, like a fresh start 🌱. If the client then receives a DHCPACK allocating its previous network address, it SHOULD continue network processing 🙌. If the client is given a new network address instead, it MUST NOT continue using the previous network address 🚫, and it SHOULD notify the local users of the problem 📣. This is a lot of drama, but it's a good kind of drama 💀.
4.4.6 DHCPRELEASE 👋
If the client no longer needs its assigned network address (for example, it's getting gracefully shut down 🥀), the client sends a DHCPRELEASE message to the server. Lowkey, the correct operation of DHCP does not depend on DHCPRELEASE messages actually getting sent 🫶. Not every goodbye has to be dramatic, bestie 🦋.
5. Acknowledgments 🙏
The author thanks the many (and far too numerous to mention!) members of the DHC WG 🫶. They've been putting in tireless and ongoing effort on DHCP and this document, and they deserve all the flowers 🌷.
The efforts of J Allard, Mike Carney, Dave Lapp, Fred Lien and John Mendonca in organizing DHCP interoperability testing sessions are gratefully acknowledged 🎀. Those people are literal legends 👑.
The development of this document was supported in part by grants from the Corporation for National Research Initiatives (CNRI), Bucknell University and Sun Microsystems 💜. Thank you for the funding, babes 🍓.
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 and 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 1700, USC/Information Sciences Institute, October 1994.
- [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 1542, Carnegie Mellon University, October 1993.
7. Security Considerations 💀
DHCP is built directly on UDP and IP, which are, sadly, inherently insecure 😭. On top of that, DHCP is generally meant to make maintenance of remote and/or diskless hosts easier. Configuring such hosts with passwords or keys may be difficult and inconvenient, and while it's perhaps not impossible, that's a lot of effort. So DHCP in its current form is quite insecure. Bestie, we need to talk 🚨.
Unauthorized DHCP servers may be easily set up 🕵️♀️. Such servers can then send false and potentially disruptive information to clients, like incorrect or duplicate IP addresses, incorrect routing information (including spoof routers, etc.), incorrect domain nameserver addresses (such as spoof nameservers), and so on. Clearly, once this seed information is in place, an attacker can further compromise affected systems. Absolutely unhinged behavior, no notes 💀.
Malicious DHCP clients could masquerade as legitimate clients and retrieve information meant for those legitimate clients 🎭. Where dynamic allocation of resources is used, a malicious client could claim all the resources for itself, which denies resources to legitimate clients 🙅♀️. Not the vibe at all 😤.
8. Author's Address 📮
Ralph Droms
Computer Science Department
323 Dana Engineering
Bucknell University
Lewisburg, PA 17837
Phone: (717) 524-1145
EMail: droms@bucknell.eduA. 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.6
Key:
MTU = Path MTU Discovery (RFC 1191, Proposed Standard)
RD = Router Discovery (RFC 1256, Proposed Standard)📦 where this page comes from
- ietf: rfc2131 1997-03
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms