RFC 1541

Dynamic Host Configuration Protocol (RFC 1541) 🎀

Okay bestie, let's get the title block sorted first 💅. RFC 1541 is by R. Droms from Bucknell University, and it's a Standards Track doc from the Network Working Group, dated October 1993. It obsoletes RFC 1531 🦋. Basically, errors crept into RFC 1531 during editing, so this one is the reissued version, and it's the one to read.

Status of this memo ✨

So this RFC specifies an Internet standards track protocol for the whole Internet community, and it's literally 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 🌈.

Abstract 💖

DHCP (the Dynamic Host Configuration Protocol) gives you a framework for passing configuration info to hosts on a TCP/IP network 🧚. It's built on BOOTP [7] and levels it up by adding automatic allocation of reusable network addresses and more configuration options [19]. DHCP copies the behavior of BOOTP relay agents [7, 23], and DHCP participants can work with BOOTP participants too [9]. Because of some errors that slipped into RFC 1531 during editing, this memo is reissued as RFC 1541 🔥.

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  . . . . . . . . . . . . . . . . 39

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. . . . . . . . . . . 31

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. . . . . . . . . . . . 32

---

1. Introduction ✨

DHCP gives configuration parameters to Internet hosts 🌸. It has two components: a protocol for delivering host-specific configuration parameters from a DHCP server to a host, and a mechanism for allocating network addresses to hosts 🧚.

DHCP is built on a client-server model, where designated DHCP server hosts allocate network addresses and deliver configuration parameters to dynamically configured hosts 💜. For 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 a huge variety of hardware and protocol implementations, so reliable operation would be impossible if random hosts were allowed to respond to DHCP requests. For example, IP needs many parameters set inside the protocol implementation software. Since IP can run on lots of different kinds of network hardware, those parameter values can't be guessed or assumed to have correct defaults 💅. Also, distributed address allocation schemes depend on a polling/defense mechanism to discover addresses that are already in use. IP hosts may not always be able to defend their network addresses, so a distributed scheme like that can't be guaranteed to avoid allocating duplicate network addresses 😭.

DHCP supports three mechanisms for IP address allocation 👑. In "automatic allocation", DHCP assigns a permanent IP address to a host. In "dynamic allocation", DHCP assigns an IP address to a host for a limited period of time (or until the host explicitly gives the address back). In "manual allocation", the network administrator assigns a host's IP address, and DHCP is only used to convey the assigned address to the host. A particular network will use one or more of these mechanisms, depending on the policies of the network administrator 🎀.

Dynamic allocation is the only one of the three mechanisms that allows automatic reuse of an address that the host it was assigned to no longer needs. That makes it super useful for hosts that will only be connected to the network temporarily, or for sharing a limited pool of IP addresses among a group of hosts that don't need permanent addresses 🦋. It can also be a good choice for a new host being permanently connected to a network where IP addresses are scarce enough that it matters to reclaim them when old hosts are retired ♻️. 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 format of DHCP messages is based on the format of BOOTP messages 🧸. That's so DHCP captures the BOOTP relay agent behavior described in the BOOTP specification [7, 23], and so existing BOOTP clients can interoperate with DHCP servers. Using BOOTP relay agents means you don't need a DHCP server on every physical network segment 🌈.

1.1 Related Work 🍓

There are several Internet protocols and related mechanisms that tackle some parts of the dynamic host configuration problem 🔍. The Reverse Address Resolution Protocol (RARP) [10] (through the extensions defined in the Dynamic RARP (DRARP) [5]) explicitly addresses network address discovery, and it includes an automatic IP address assignment mechanism. The Trivial File Transfer Protocol (TFTP) [20] provides transport of a boot image from a boot server 💾. The Internet Control Message Protocol (ICMP) [16] can tell hosts about additional routers through "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 also extensible, and official extensions [17] have been defined 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 employs 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 the configuration of 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 via DHCP, a host should be able to exchange packets with any other host in the Internet ✨. The parameters DHCP supplies are listed in Appendix A.

Not all of these parameters are required for a newly initialized host. A client and server may negotiate for the transmission of only those parameters the client requires, or that are specific to a particular subnet 🫧.

DHCP allows but does not require the configuration of host parameters not directly related to the IP protocol 💜. DHCP also doesn't address registering newly configured hosts with the Domain Name System (DNS) [12, 13] 🙃.

DHCP is not intended for use in configuring routers 🚫.

1.3. Requirements ✨

Okay bestie, quick rules of the game 🎀 All through this doc, the words that show how serious a requirement is get written in CAPS, and there are only a few of them:

• "MUST": This word, or the adjective "REQUIRED", means the item is an absolute requirement of this specification. No wiggle room 🔒
• "MUST NOT": This phrase means the item is an absolute prohibition of this specification. Hard no 🚫
• "SHOULD": This word, or the adjective "RECOMMENDED", means there can be valid reasons in certain situations to skip this item. Before picking a different path, you have to fully understand the implications and carefully weigh the case 🧠
• "SHOULD NOT": This phrase means there can be valid reasons in certain situations where the listed behavior is fine or even useful. Still, before doing any behavior tagged with this label, you need to fully understand the implications and carefully weigh the case 🤔
• "MAY": This word, or the adjective "OPTIONAL", means the item is truly optional. One vendor might include it because a certain market needs it or because it makes the product better, and another vendor can totally skip it 🦋

1.4. Terminology 🌸

This document uses the following terms:

• "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 hands 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 as specified in the BOOTP protocol specification 🚚
• "binding": A binding is a collection of configuration parameters, including at least an IP address, that is associated with, or "bound to", a DHCP client. Bindings are managed by DHCP servers 🔗

1.5. Design goals 💜

Here are the big-picture design goals for DHCP, and honestly they're iconic 👑

• 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 local policies about allocating and accessing local resources wherever that matters 🎀
• Hosts should require no manual configuration. Each host should be able to discover the right local configuration parameters without user intervention and 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 type in any per-host configuration parameters 🙌
• DHCP should not require a server on each subnet. 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 installations might have 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 specific to sending 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 reboots. Whenever possible, a host should be given the same configuration parameters (like a network address) every time it asks 🏠
• Retain host configuration across server reboots. Whenever possible, a host should get the same configuration parameters even if the DHCP mechanism restarts 🔄
• 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 🦋

From the client's point of view, DHCP is an extension of the BOOTP mechanism. This means existing BOOTP clients can talk to DHCP servers without any changes to their initialization software, which is so smart 🧠 A separate document goes into the interactions between BOOTP and DHCP clients and servers [9]. There are also some new, optional transactions that make the interaction between DHCP clients and servers work better. Those are described in sections 3 and 4 ✨

Figure 1 shows the format of a DHCP message, and table 1 describes each field in it. The numbers in parentheses are the size of each field in octets. The field names shown in the figure are the ones used throughout this document to refer to fields in DHCP messages 📝

There are two main differences between DHCP and BOOTP. First, DHCP defines how clients can be given a network address for a fixed lease, which allows network addresses to be reassigned serially to different clients. Second, DHCP gives clients a way to acquire all of the IP configuration parameters they need to operate 💖

DHCP makes one small terminology change to clear up what one field means. The "vendor extensions" field in BOOTP has been renamed the "options" field in DHCP. Similarly, the tagged data items that used to live inside the BOOTP "vendor extensions" field, which were called "vendor extensions," are now simply called "options" 🏷️

DHCP defines a new 'client identifier' option for passing an explicit client identifier to a DHCP server. This fixes the mess of the 'chaddr' field in BOOTP messages, where 'chaddr' was used both as a hardware address for sending BOOTP reply messages and as a client identifier. The 'client identifier' option can hold a hardware address, identical to the contents of the 'chaddr' field, or another type of identifier, like a DNS name. Other client identifier types can be defined as needed for DHCP. New client identifier types will be registered with the IANA [18] and 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] 🌟

   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

DHCP clarifies that the 'siaddr' field is 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 it's ready to supply the next bootstrap service, such as 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 its minimum extended to 312 octets. That bumps the minimum size of a DHCP message up to 576 octets, which is the minimum IP datagram size a host has to be prepared to accept [3]. DHCP clients can negotiate larger DHCP messages through the 'Maximum DHCP message size' option. The options field can also be extended into the 'file' and 'sname' fields 📦

A new option, called 'vendor specific information', was added so the number of options that can be supported can grow [2]. Options encapsulated as 'vendor specific information' have to be carefully defined and documented so clients and servers from different vendors can interoperate. Specifically, vendors defining 'vendor specific information' MUST document those options in the form of the DHCP Options document, MUST choose to represent those options either in data types already defined for DHCP options or in other well-defined data types, and MUST 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, and its semantics 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 shows the format of the 'flags' field 🩷

2.1 Configuration parameters repository ✨

Okay bestie, DHCP's first job is basically a super organised notebook 📓💖. It keeps persistent storage of network parameters for network clients. The model is a key-value entry for each client, where the key is some unique identifier (like 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). That lets the same hardware address be reused serially or at the same time on different subnets, and it works even when hardware addresses aren't globally unique 🦋. Or the key might be the pair (IP-subnet-number, hostname), which lets the server hand out parameters smartly to a host that moved to a different subnet or changed hardware addresses (say the network interface failed and got swapped out) 🫶.

A client can query the DHCP service to grab its configuration parameters. The client's interface to this repository is just protocol messages that request configuration parameters, plus responses from the server carrying those parameters 💅.

2.2 Dynamic allocation of network addresses 🌸

The second service is handing out temporary or permanent network (IP) addresses to hosts. The basic idea is so simple: a client requests to use an address for some period of time. The allocation mechanism (the whole collection of DHCP servers) promises not to reallocate that address during the requested time, and it tries to give back the same address every time the client asks 😭. That period of allocation is called a "lease" [11]. The client may extend its lease with later requests. When it no longer needs the address, the client may send a message to release it back to the server 🧚. If a client wants a permanent assignment, it may ask for an infinite lease. Even with "permanent" addresses, a server may choose to give out lengthy but non-infinite leases, so it can still notice when a host has been retired 👑.

Now, sometimes you run out of addresses, and then reassigning them is necessary 💀. In those environments, the allocation mechanism will reuse addresses whose lease has expired. The server should use whatever information is available in the configuration information repository to pick an address to reuse. For example, the server may choose the least recently assigned address 🍓. As a consistency check, the allocation mechanism may probe the reused address, e.g., with an ICMP echo request, before allocating it. And the client will probe the newly received address, e.g., with ARP 🔥.

---

3. The Client-Server Protocol ✨

Next up, the message format! DHCP uses the BOOTP message format defined in RFC 951, and you can see it in table 1 and figure 1 🌈. Every DHCP message a client sends to a server has BOOTREQUEST in its 'op' field. Messages going the other way, from server to client, use BOOTREPLY in the 'op' field 💜.

The first four octets of the 'options' field are the (decimal) values 99, 130, 83 and 99, in that order. Yes, it's the same magic cookie defined in RFC 1497, so it's not a brand-new thing, just a familiar friend 🙈. After that cookie comes a list of tagged parameters called "options" ⭐. All of the "vendor extensions" listed in RFC 1497 are also DHCP options, so nothing gets left out. If you want the complete set of options defined for DHCP, there's a separate document for that [2] 📚.

Several options have been defined so far 🎀. One option, the "DHCP message type" option, must be included in every DHCP message, since it sets the "type" of that message. Other options may be allowed, required, or not allowed, depending on the message type. It's giving strict-but-fair energy 💅.

Throughout this document, a DHCP message carrying a 'DHCP message type' option gets called by its type. So a message with 'DHCP message type' option type 1 is called a "DHCPDISCOVER" message. Iconic naming, no notes 🦋💖

3.1 Client-server interaction - allocating a network address ✨

okay so this is the whole group chat between a client and a server when the client wants a network address 💬🎀 the messages are in table 2 and the timing is in figure 3 🦋 if the client already knows its address, some steps can be skipped, and that shortcut is in section 3.2 💅

1. DHCPDISCOVER: the client shouts into the void 📣 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 are not on the same physical subnet.
2. DHCPOFFER: servers slide into the DMs 🍓 Each server may respond with a DHCPOFFER message that includes an available network address in the yiaddr field (and other configuration parameters in DHCP options). Servers need not reserve the offered network address, although the protocol will work more efficiently if the server avoids allocating the offered network address to another client. The server unicasts the DHCPOFFER message to the client (using the DHCP/BOOTP relay agent if necessary) if possible, or may broadcast the message to a broadcast address (preferably 255.255.255.255) on the client's subnet.
3. DHCPREQUEST: the client picks a favourite 💖 The client receives one or more DHCPOFFER messages from one or more servers. It may choose to wait for multiple responses. The client chooses one server to request configuration parameters from, based on the parameters offered in the DHCPOFFER messages. The client broadcasts a DHCPREQUEST message that MUST include the 'server identifier' option to indicate which server it has selected, and it may include other options specifying desired configuration values. This DHCPREQUEST message is broadcast and relayed through DHCP/BOOTP relay agents.

To help make sure that any DHCP/BOOTP relay agents forward the DHCPREQUEST message to the same set of DHCP servers that received the original DHCPDISCOVER message, the DHCPREQUEST message must use the same value in the DHCP message header's secs field and be sent to the same IP broadcast address as the original DHCPDISCOVER message. The client times out and retransmits the DHCPDISCOVER message if it receives no DHCPOFFER messages. 🔁

4. DHCPACK or DHCPNAK: the server makes it official 👑 The servers receive the DHCPREQUEST broadcast from the client. The servers that were not selected by the DHCPREQUEST message use it as notification that the client has declined their offer. The server selected in the DHCPREQUEST message commits the binding for the client to persistent storage and responds with a DHCPACK message containing the configuration parameters for the requesting client. The combination of chaddr and the assigned network address constitutes 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. The yiaddr field in the DHCPACK messages is filled in with the selected network address.

If the selected server is unable to 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 to a client in a DHCPOFFER message as available if the server receives no DHCPREQUEST message from that client. 🧚

   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 message

Table 1 is the field cheat sheet 📋 every field in a DHCP message, how many octets it takes up, and what it's for.

                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 address

Figure 3 is the timeline 🕰️ the server that gets picked, the server that doesn't, and the client, all in one picture.

   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 messages

5. DHCPACK: the client gets its gift 🎁 The client receives the DHCPACK message with the configuration parameters. The client performs a final check on the parameters (e.g., ARP for the allocated network address), and notes the duration of the lease and the lease identification cookie specified in the DHCPACK message. At this point, the client is configured ✨ 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 the configuration process, to avoid excessive network traffic in case of looping. 🔄

If the client receives a DHCPNAK message, the client restarts the configuration process.

The client times out and retransmits the DHCPREQUEST message if it receives neither a DHCPACK nor a DHCPNAK message. The client retransmits the DHCPREQUEST according to the retransmission algorithm in section 4.1. If the client receives neither a DHCPACK nor a DHCPNAK message 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 the initialization process has failed and is restarting. 😭

6. DHCPRELEASE: the graceful goodbye 🦋 The client may choose to relinquish its lease on a network address by sending a DHCPRELEASE message to the server. The client identifies the lease to be released by including its network address in the ciaddr field and its hardware address in the chaddr field. 💜

3.2 Client-server interaction - reusing a previously allocated network address 🔁

okay so bestie, what if a client already remembers its address? maybe it got one from DHCP earlier, or from somewhere outside the protocol entirely 👀. then it's allowed to skip some of the steps from the last section, because it already has a head start 💅. figure 4 shows the timing for this glow-up version of the exchange 🦋

1. The client broadcasts a DHCPREQUEST message on its local subnet. The DHCPREQUEST message includes the client's network address in the ciaddr field. DHCP/BOOTP relay agents pass the message on to DHCP servers that are not on the same subnet 📡
2. 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 respond with a DHCPNAK message to the client 🙈

3. The client gets the DHCPACK message with its configuration parameters 🎀. The client does one last check on the parameters (same as section 3.1), and makes a note of the lease duration 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 configuration process by requesting a new network address 😭. this corresponds to 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               v

Figure 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 cannot reuse its remembered network address 💀. it has to request a brand new address by restarting the configuration process, this time using the full, non-abbreviated procedure from section 3.1. this also corresponds to the client moving 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 ⏰. 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, 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

4. 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 the lease identification cookie

Note that in this case, where the client keeps its network address locally, the client will not normally release its lease during a graceful shutdown 🌙. only when the client really needs to give up its lease, for example because it is 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 mean "infinity". the minimum lease duration is one hour ⭐

clients and servers may not have synchronized clocks, so times are sent in DHCP messages as relative times, which get interpreted against the client's local clock 🕰️. an unsigned 32 bit word counting seconds covers relative times from 0 to roughly 100 years, which is plenty for what DHCP needs to measure 💜

the lease duration interpretation in the previous paragraph assumes that the client and server clocks are stable relative to each other 🧐. if the two clocks drift apart, the server may consider the lease expired before the client does. to make up for this, the server may send the client a shorter lease duration than the one it 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 🙌. there are two tricks to cut down on how many parameters get sent from server to 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 those defaults, it just uses the default values 💅. second, in its initial DHCPDISCOVER or DHCPREQUEST message, a client can give the server a list of the specific parameters it cares about 📝

The client SHOULD include the 'maximum DHCP message size' option so the server knows how large its DHCP messages are allowed to be 📏. the parameters returned to a client may still be too big for the space allocated to options in a DHCP message. in that case, two extra options flags (which must appear in the 'options' field of the message) say that the 'file' and 'sname' fields should be used for options too 🗂️

the client can tell the server which configuration parameters it's interested in by including the 'parameter request list' option. the data in this option explicitly lists the requested options by tag number 🏷️

the client can also suggest values for its 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 would like. no other options that act as "hints" for 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 asking to keep using a previously allocated IP address 🦋

If a server receives a DHCPREQUEST message with an invalid 'ciaddr', 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.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 🔍. think system boot, or after getting disconnected from the local network, since the local network configuration can change without the host's or the user's knowledge 👻

if a host knows a previous network address and can't reach a local DHCP server, it may keep using the previous network address until that lease expires 🫠

if the lease expires before the host can reach a DHCP server, the host must immediately stop using the previous network address 🚨 and it may let local users know 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 whenever 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 ✨

Okay bestie, DHCP clients and servers both build their messages the same way 💅 They fill in the fixed-format section of the message, then tack on tagged data items in the variable-length option area. The options area starts with a four-octet 'magic cookie' (we covered that back in section 3 🍓), followed by the options. The last option is always the end option 🙈

DHCP runs on UDP 🦋 Messages from a client go to the 'DHCP server' port (67), and messages from a server go to the 'DHCP client' port (68).

Before a client has its IP address, any DHCP message it broadcasts has to have the source address field in the IP header set to 0 🌸

Now for giaddr, which is kind of the routing brain here 🧠 If giaddr is non-zero, the server sends 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 return messages either to the client's network address (if one was supplied in ciaddr), or to the client's hardware address, or to the local subnet broadcast address ✨

Sometimes options spill over into the sname and file fields 📦 When that happens, the option overload option MUST appear in the options field, with value 1, 2 or 3, as specified in the DHCP options document [2]. If option overload is present 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 sname and file (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 options, sname and file MUST be entirely contained in that field. The options in options MUST be interpreted first, so that any option overload options can be interpreted. The file field MUST be interpreted next (if the option overload option says file holds DHCP options), followed by sname 🧩

Okay this next bit is so important 🔁 DHCP clients are responsible for all message retransmission. The client MUST adopt a retransmission strategy that incorporates a randomized exponential backoff algorithm to determine the delay between retransmissions. The delay before the first retransmission MUST be 4 seconds, randomized by the value of a uniform random number chosen from the range -1 to +1. Clients with clocks that provide resolution granularity of less than one second may choose a non-integer randomization value. The delay before the next retransmission MUST be 8 seconds, randomized by the value of a uniform number chosen from the range -1 to +1. The retransmission delay MUST be doubled with subsequent retransmissions, up to a maximum of 64 seconds. The client MAY provide an indication of retransmission attempts to the user as an indication of the progress of the configuration process. The protocol specification in the rest of this section will describe, for each DHCP message, when it's appropriate for the client to retransmit that message forever, and when it's appropriate for a client to abandon that message and attempt to use a different DHCP message 💖

Normally, DHCP servers and BOOTP relay agents try to deliver DHCPOFFER, DHCPACK and DHCPNAK messages straight to the client using 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 such unicast IP datagrams until they've been configured with a valid IP address. That creates a deadlock 😭 The client's IP address can't be delivered until the client has been configured with an IP address, and round and round it goes.

A client that cannot 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 that client sends. The BROADCAST bit is a hint to the DHCP server and BOOTP relay agent to 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 sending or relaying a DHCP message directly to a DHCP client (i.e., not to a relay agent specified in the giaddr field) SHOULD examine the BROADCAST bit in the flags field. If that 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 receive 🙅‍♀️ For example, a network administrator who wants stringent control over the hosts on the network might configure DHCP servers to respond only to hosts that were previously registered through some external mechanism. The DHCP specification only describes the interactions between clients and servers when the clients and servers choose to interact. Describing every administrative control that system administrators might want is beyond its scope 👑 Specific DHCP server implementations can incorporate any controls or policies a network administrator wants.

In some environments, a DHCP server has to consider the values of the chaddr field and/or the class-identifier option included in the DHCPDISCOVER or DHCPREQUEST messages when determining the correct parameters for a particular client 🧐 For example, an organization might have a separate bootstrap server for each type of client it uses. That means the DHCP server has to examine the class-identifier to figure out which bootstrap server address to return 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 does not 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 for selecting a DHCP server from among those that send them a DHCPOFFER message 🦋 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 processes 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:

• DHCPDISCOVER
• DHCPREQUEST
• DHCPDECLINE
• DHCPRELEASE

Table 3 gives the use of the fields and options in a DHCP message by a server. The rest of this section describes what the DHCP server does for each possible incoming message 💜

4.3.1 DHCPDISCOVER message 💌

Okay bestie, when a server gets a DHCPDISCOVER from a client, it picks a network address for that client 🦋. If no address is free, the server may tell the system administrator about the problem, and it may reply to the client with a DHCPNAK message. If the server does respond to the client, it may include an error message in the 'message' option. If an address IS available, the server picks the new address in this order ✨:

• The client's previous address as recorded in the client's 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.

Here's the field and option chart for the three reply messages. It's giving 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              options

  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 servers

As described in section 4.2, a server MAY, for administrative reasons, hand out an address other than the one requested, or refuse to give an address to a particular client even when free addresses are available 🙅‍♀️.

Not strictly required for DHCP to work, but the server should not reuse the picked network address before the client responds to the server's DHCPOFFER message 🤞. The server may also choose to record the address as offered to the client 📝.

The server must also choose an expiration time for the lease, and it goes like this ⏰:

• 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.

Once the network address and lease are sorted, the server builds a DHCPOFFER message with the offered configuration parameters 🎀. It's super important that all DHCP servers return the same parameters (with the possible exception of a newly allocated network address) so the host behaves predictably no matter which server the client picks 👑. 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 they all respond uniformly 🧚. The server MUST return to the client:

• The client's network address, as determined by the rules given earlier in this section, and the subnet mask for the network to which the client is connected,
• 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 the following 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,
• Any parameters from the existing binding that differ from the Host Requirements documents defaults,
• Any parameters specific to this client (as identified by the contents of 'chaddr' 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 '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 'client class' and the client class identified in the server,
• Parameters with non-default values on the client's subnet.

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 🎯

A DHCPREQUEST message can come from a client answering a DHCPOFFER from a server, or from a client double-checking a previously allocated IP address 🔍. If the DHCPREQUEST has a 'server identifier' option, it's replying to a DHCPOFFER. If not, it's a request to renew or extend an existing lease 🔄.

Let's start with the DHCPREQUEST that answers a DHCPOFFER. If the server is named in the 'server identifier' option of the DHCPREQUEST, the server checks that the requested parameters are acceptable 🧐. Usually the requested parameters will match what was sent back in the DHCPOFFER, but the client may ask for a different lease duration. Also, the server doesn't have to cache the parameters from the DHCPOFFER. The server must simply check that the parameters requested in the DHCPREQUEST are acceptable. If they are, the server records the new client binding and returns a DHCPACK message to the client 🥳.

If the requested parameters are unacceptable (for example, the requested lease time breaks local policy), the server sends a DHCPNAK message to the client 🙃. The server may choose to return an error message in the 'message' option.

If a different server is named in the 'server identifier' field, the client picked a different server to get its configuration parameters 👋. The server may discard any information it cached about the client's request, and may free the network address it had offered to the client.

Note that the client may collect several DHCPOFFER messages and pick the "best" one 🏆. The client indicates its choice by naming the offering server in the DHCPREQUEST message. If the client gets no acceptable offers, it may try another DHCPDISCOVER message. Because of this, servers may never get a specific DHCPREQUEST that tells them whether or not the client accepted their offer 🤷‍♀️. Since servers haven't committed any address assignments based on a DHCPOFFER, they are free to reuse offered network addresses in response to 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 ⏳.

In the second case, when there is no 'server identifier' option, the client is renewing or extending a previously allocated IP address 🌸. The server checks that the requested parameters are acceptable. If the parameters in the DHCPREQUEST match the previous parameters, or if the request to extend the lease (shown by an extended 'IP address lease time' option) is acceptable, the server returns a DHCPACK message to the requesting client ✅. Otherwise, the server returns a DHCPNAK message to the client ❌. Specifically, if the previously allocated network address in the client's 'ciaddr' field doesn't match the network address the server recorded for that client, the server sends a DHCPNAK to the client 🚫.

A DHCP server picks the parameters to return in a DHCPACK message using the same rules used to build a DHCPOFFER message, as given in section 4.3.1 💅.

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 the network address as not allocated, and SHOULD notify the local system administrator about 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 keep a record of the client's initialization parameters so it can reuse them if the client sends more requests later 💜.

4.4 DHCP client behavior 🎀

okay bestie, this is the client side 🧚 the part where your device decides what to do once the server starts talking back. 💅 Figure 5 is the state diagram for the client. A client can receive exactly three kinds of messages from a server:

• DHCPOFFER
• DHCPACK
• DHCPNAK

Table 4 shows which fields and options a client uses in each message it sends. The rest of this section goes through what the client does for every message it could get back. 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. ✨

4.4.1 Initialization and allocation of network address 🌸

The client starts in INIT state and forms a DHCPDISCOVER message. It should wait a random time between one and ten seconds so that not everyone starts DHCP at the exact same moment 🙈 The client sets ciaddr to 0x00000000. The client MAY request specific parameters by including the 'parameter request list' option. The client MAY suggest a network address and/or lease time by including the 'requested IP address' and 'IP address lease time' options. The client MUST include its hardware address in the chaddr field so replies can get delivered back to it. The client MAY include a different unique identifier in the 'client identifier' option. If the client leaves out the 'client identifier' option, the server uses the contents of chaddr to figure out whose lease it is.

The client makes a random transaction identifier and records it, then stuffs that identifier into the xid field. It also records its own local time, which it needs later to work out when the lease expires ⏰ After that, it broadcasts the DHCPDISCOVER on the local hardware broadcast address, sends it to the 0xffffffff IP broadcast address, and aims it at the 'DHCP server' UDP port.

If the xid of an incoming DHCPOFFER doesn't match the xid of the most recent DHCPDISCOVER, that DHCPOFFER must be silently discarded. Any DHCPACK messages that arrive must be silently discarded too 🙅‍♀️

The client collects DHCPOFFER messages for a while and picks one of the (possibly many) that show up. It could be the first one, or the one from the server it used before 💜 It then pulls the server address out of the 'server identifier' option in that DHCPOFFER. How long the client keeps collecting and how it chooses are implementation dependent. The client may check the suggested address to make sure nobody is already using it. For example, if the client is on a network that supports ARP, it may send 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. That way it won't confuse ARP caches on other hosts on the same subnet. If the address looks like it's already in use, the client sends a DHCPDECLINE message to the server and waits for another DHCPOFFER. Since the client doesn't have a valid network address yet, it must broadcast the 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     |               |
                         |   ----------             |               |
                         |  |          |------------+               |
                         +->| RENEWING |                            |
                            |          |----------------------------+
                             ----------

Figure 5: State-transition diagram for DHCP clients 🦋

  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 clients 🍓

If the parameters look good, the client records the address of the server that sent them, taken from the 'server identifier' field. It then sends that address in the 'server identifier' field of a DHCPREQUEST broadcast message 🫶 Once the DHCPACK message from the server arrives, the client is initialized and moves to BOUND state 👑 The DHCPREQUEST message carries the same xid as the DHCPOFFER message. The client works out the lease expiration time by adding the time the original request was sent to the lease duration from the DHCPOFFER message. The client SHOULD broadcast an ARP reply to announce its new IP address and clear any outdated ARP cache entries on the hosts in its subnet. no cap, that ARP reply is the last little glow-up before the client is fully settled in 💖

4.4.2 Initialization with known network address 🦋

The client starts in INIT-REBOOT state and sends a DHCPREQUEST message with ciaddr set to its network address. The client may request specific configuration parameters by including the 'parameter request list' option. It generates and records a random transaction identifier and puts it in the xid field. It 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 on the local hardware broadcast address and sends it to the 'DHCP server' UDP port.

Once a DHCPACK message 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 message was sent and the duration of the lease from the DHCPACK message. that's the whole reboot-with-a-known-address arc, and honestly it's giving clean and efficient 🧚

4.4.3 Initialization with a known DHCP server address ✨

okay so if the client already knows the address of a DHCP server 🫶 and it's in either INIT or REBOOTING state, it may send its DHCPDISCOVER or DHCPREQUEST straight to that address instead of the IP broadcast address. but if the client gets no response to messages sent to a known DHCP server's IP address, it reverts to using the IP broadcast address 🦋

4.4.4 Reacquisition and expiration

okay this is the lease timing section and it's giving clockwork 🕰️✨ the client keeps two times, T1 and T2, which tell it when to keep trying to extend its lease on its network address. T1 is when the client enters the RENEWING state and tries to contact the server that originally issued its network address. T2 is when it enters the REBINDING state and tries to contact any server 💅

at T1, after the client accepts the lease on its network address, it moves to RENEWING state and sends a DHCPREQUEST message to the server by unicast to extend its lease 💖 it makes a random transaction identifier and puts it in the 'xid' field of the DHCPREQUEST. it also records the local time it sends that DHCPREQUEST, because that's how it works out the lease expiration time later. and the client MUST NOT include a 'server identifier' in the DHCPREQUEST message 🙈

any DHCPACK that shows up with an 'xid' that doesn't match the 'xid' of the client's DHCPREQUEST gets silently discarded 🤫 when the right DHCPACK arrives, the client computes the lease expiration time as the sum of the time it sent the DHCPREQUEST and the duration of the lease in the DHCPACK 🧮 the client has successfully reacquired its network address, goes back to BOUND state, and may continue network processing. main character energy 👑

if no DHCPACK arrives before T2 (T2 > T1) and the lease on its network address is about to expire, the client moves to REBINDING state and sends a DHCPREQUEST message by broadcast to extend its lease 📢 it sets the 'ciaddr' field in the 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 ⚙️ by default, T1 is (0.5 * duration_of_lease) and T2 is (0.875 * duration_of_lease). also, T1 and T2 should be picked with some random "fuzz" around a fixed value, so that clients don't all reacquire at the exact same moment and sync up 🌈✨

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 the expiration of T1 (in RENEWING state) or T2 (in REBINDING state), down to a minimum of 60 seconds, before retransmitting the DHCPREQUEST message 🍓

⚠️ bestie, the worst case: if the lease expires before the client gets a DHCPACK, it moves to INIT state, MUST immediately stop any other network processing, and requests network initialization parameters as if it were uninitialized. if it then gets a DHCPACK allocating its previous network address, it SHOULD continue network processing. but if it's given a new network address, it MUST NOT keep using the previous one, and it SHOULD notify the local users of the problem 😭

4.4.5 DHCPRELEASE

okay so if the client doesn't need its assigned network address anymore (like when it's gracefully shut down 🌙), it sends a DHCPRELEASE message to the server 📨 just so you know, DHCP's correct operation does not depend on DHCPRELEASE messages actually being transmitted 🧚

---

5. Acknowledgments 🎀

big thank-you energy to Greg Minshall, Leo McLaughlin and John Veizades, who patiently helped shape the design of DHCP through countless discussions, meetings and mail threads 🫶 Jeff Mogul first proposed the client-server based model for DHCP 👑 Steve Deering searched 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 analyzed DHCP in detail and pointed out several inconsistencies in earlier specifications of the protocol 🧐 Steve Alexander reviewed Walker's analysis and the fixes to the protocol that came out of Walker's work ✨ and of course, every member of the Dynamic Host Configuration Working Group of the IETF contributed to the design of 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 1542, Carnegie Mellon University, October 1993.

7. Security Considerations 🔐

okay this part is serious, bestie 😭 DHCP is built directly on UDP and IP, which are as yet inherently insecure. and DHCP is generally meant to make maintenance of remote and/or diskless hosts easier. while it's perhaps not impossible, configuring those hosts with passwords or keys may be difficult and inconvenient. so DHCP in its current form is quite insecure 💀

unauthorized DHCP servers can be set up really easily 🚨 they can then send false and potentially disruptive info to clients, like incorrect or duplicate IP addresses, incorrect routing information (including spoof routers, etc.), incorrect domain nameserver addresses (like spoof nameservers), and so on. honestly, once that seed info is in place, an attacker can keep compromising the affected systems 😱

malicious DHCP clients could also 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 would deny resources to legitimate clients 🫠

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.6

Key:

   MTU = Path MTU Discovery (RFC 1191, Proposed Standard)
   RD = Router Discovery (RFC 1256, Proposed Standard)