Dynamic Host Configuration Protocol
The Dynamic Host Configuration Protocol (DHCP) is a client-server protocol that enables automatic assignment of IP addresses and other network configuration parameters, such as subnet masks, default gateways, and DNS server addresses, to devices on Internet Protocol (IP) networks, thereby simplifying network administration and reducing manual configuration errors.[1] Developed as an extension of the earlier Bootstrap Protocol (BOOTP), DHCP introduces dynamic address allocation with lease times to efficiently reuse IP addresses in large or changing networks.[1] Standardized in RFC 2131 by the Internet Engineering Task Force (IETF) in March 1997, it operates primarily over IPv4 networks using UDP port 67 for servers and port 68 for clients, with a broadcast-based discovery mechanism where clients send DHCPDISCOVER messages to locate available servers.[1] DHCP supports three allocation modes: automatic (permanent assignment), dynamic (temporary lease), and manual (pre-assigned addresses delivered via the protocol), allowing flexibility for different network environments from small offices to enterprise-scale deployments.[1] The protocol's message exchange typically follows a four-step DORA process—DHCPDISCOVER (client broadcast), OFFER (server proposal with IP and options), REQUEST (client selection and confirmation), and ACKNOWLEDGMENT (server approval)—ensuring reliable configuration delivery while supporting relay agents for subnet traversal.[1] Configuration options are encoded in variable-length fields, enabling extensibility for parameters like lease duration, which is locally configured by the server if not specified by the client, and vendor-specific information, with over 50 standardized options defined across related RFCs.[1] Originally built on BOOTP's message format for backward compatibility (as per RFC 951 from 1985), DHCP has become ubiquitous in modern TCP/IP networks, powering the majority of dynamic addressing in homes, businesses, and public Wi-Fi.[1][2] For IPv6 networks, an adapted version known as DHCPv6—detailed in RFC 8415 (November 2018, obsoleting RFC 3315 from 2003)—provides similar functionality but accounts for IPv6's larger address space and stateless autoconfiguration alternatives, using UDP ports 547 (server) and 546 (client) and supporting both stateful address assignment and stateless parameter distribution.[3] This evolution ensures DHCP's relevance in transitioning to and operating IPv6 infrastructures, where it coexists with mechanisms like Router Advertisements for hybrid configuration scenarios.[3] Overall, DHCP's design emphasizes scalability, security considerations (such as authentication options in later extensions), and interoperability, making it a foundational element of IP networking since its initial RFC 1531 definition in 1993.[4][1]Overview
Purpose and Core Functionality
The Dynamic Host Configuration Protocol (DHCP) is a network management protocol used on Internet Protocol (IP) networks whereby devices, known as clients, automatically obtain IP addresses and other configuration parameters from a centralized DHCP server.[5] This client-server model enables hosts to configure themselves dynamically upon connecting to a network, eliminating the need for manual intervention in assigning network identifiers and settings.[5] DHCP addresses the challenges of manual configuration by automating the process, thereby reducing the risk of human errors such as IP address conflicts or incorrect subnet masks that can disrupt network operations.[6] It is particularly suited to dynamic environments, including large-scale enterprise networks and scenarios involving mobile devices that frequently join and leave the network, as it allows for seamless reconfiguration without administrative overhead.[5] Key benefits of DHCP include enhanced scalability, which supports the management of numerous devices across multiple subnets through relay agents that forward requests without requiring a server on every segment; centralized administration, where a single server handles configurations for diverse network segments to simplify updates and maintenance; and the use of temporary leased addresses, which promote efficient reuse of the limited IP address space by reclaiming unused assignments after a defined period.[5][6] These features make DHCP indispensable for modern TCP/IP networks, where static assignment proved inadequate for handling growth and variability.[5] DHCP was developed in the mid-1990s as an extension of the Bootstrap Protocol (BOOTP) to overcome the limitations of static IP assignment, such as administrative burden and inflexibility in expanding networks.[5]Key Components and Terminology
The Dynamic Host Configuration Protocol (DHCP) relies on distinct roles to facilitate network configuration. A DHCP client is defined as an Internet host that employs DHCP to acquire essential parameters, such as an IP address.[7] The DHCP server serves as the counterpart, an Internet host responsible for assigning and returning these configuration parameters to clients.[7] To support operations across multiple subnets, a DHCP relay agent—also referred to as a BOOTP relay agent—acts as an intermediary, forwarding DHCP messages between clients and servers on a local network.[7] Several core terms underpin DHCP functionality. An IP address lease denotes the finite period during which a network address is allocated to a client, promoting efficient address reuse.[8] The lease duration, a configurable parameter set by the server, determines this timeframe. Key configuration elements provided via leases include the subnet mask, which delineates the network and host portions of an IP address per RFC 950.[9] The default gateway identifies preferred routers on the client's subnet for outbound traffic.[10] Additionally, DNS server addresses supply IP locations of domain name servers, ordered by preference, to enable hostname resolution as outlined in RFC 1035.[11] DHCP messages are structured as UDP datagrams to ensure reliable, connectionless transmission.[12] Each message features an opcode (op) field, a single octet specifying the type—1 for BOOTREQUEST (client-initiated) or 2 for BOOTREPLY (server response).[13] The client hardware address (chaddr) field, spanning 16 octets, encodes the client's physical (MAC) address for unique identification.[13] A transaction ID (xid), a 4-octet random value generated by the client, associates specific requests with their replies, preventing mismatches in concurrent exchanges.[13] Standardized UDP ports define the communication endpoints in DHCP: port 67 for servers to receive client broadcasts, and port 68 for clients to receive server responses.[13]History and Development
Origins and Early Specifications
The Bootstrap Protocol (BOOTP), defined in RFC 951 and published in September 1985, served as the primary predecessor to DHCP. Developed by Bill Croft of Stanford University and John Gilmore of Sun Microsystems, BOOTP was designed to enable diskless workstations to automatically obtain their IP addresses, server addresses, and boot file names over IP networks using UDP, facilitating unattended bootstrapping without local storage.[14] This protocol addressed the needs of early networked environments, particularly for booting devices like X Window System terminals and Sun Microsystems workstations, by supporting relay agents to forward requests across subnets and integrating with file transfer protocols such as TFTP.[14] In the early 1990s, the Internet Engineering Task Force (IETF) initiated the development of DHCP as an extension to BOOTP to overcome its limitations in scalability and flexibility. The first standard for DHCP was published in RFC 1531 in October 1993, authored by Ralph Droms of Bucknell University, which introduced dynamic IP address leasing and additional configuration parameters while maintaining backward compatibility with BOOTP clients and relay agents.[15] This evolution was driven by the rapid expansion of the Internet, where the fixed, manual assignment of IP addresses under BOOTP proved unscalable amid growing address scarcity from the proliferation of hosts in enterprise and academic networks.[16] Key motivations included automating host configuration to minimize administrative overhead, enabling temporary and reusable IP allocations to conserve the limited IPv4 address space, and supporting dynamic management across large, subnetted environments without per-host manual setup.[15][16] Initial adoption of DHCP accelerated in the mid-1990s as it became integrated into major operating systems, marking a shift toward automated network configuration in commercial and enterprise settings. Microsoft included native DHCP client support in Windows 95, released in August 1995, which facilitated easier TCP/IP networking for personal computers and contributed to the protocol's widespread use in home and small office environments.[17] In Unix-like systems, early implementations emerged through efforts like those at Carnegie Mellon University and Sun Microsystems, with DHCP support appearing in distributions such as Solaris by the mid-1990s, enabling seamless integration for server and workstation deployments.[16] By this period, DHCP's reference implementations and standards compliance had positioned it as a foundational element for managing IP resources in the burgeoning Internet era.[16]Evolution and Major Revisions
The Dynamic Host Configuration Protocol (DHCP) for IPv4 underwent significant standardization in 1997 with the publication of RFC 2131, which defined the protocol's core mechanics and obsoleted the earlier RFC 1531 by providing clarified semantics for message exchanges, state management, and error handling, while introducing new options for enhanced configuration flexibility.[18] Complementing this, RFC 2132 specified the format and usage of DHCP options and BOOTP vendor extensions, establishing a structured framework for conveying additional parameters such as domain names and vendor-specific data, which remains foundational for option implementation.[19] Subsequent refinements addressed limitations in option handling, notably RFC 3396 in 2002, which introduced encapsulation techniques to support longer options exceeding the 255-byte limit, enabling more complex configurations like embedded sub-options for advanced network services without altering the base protocol structure.[20] These updates ensured backward compatibility while accommodating growing network demands, such as larger payloads for enterprise environments. Adaptation to IPv6 marked a key evolutionary step, with RFC 3315 in 2003 defining DHCPv6 to provide address assignment and parameter distribution tailored to IPv6's stateless autoconfiguration, including support for prefix delegation and relay mechanisms distinct from IPv4.[21] This specification was later updated and obsoleted by RFC 8415 in 2018, which clarified ambiguities, removed deprecated features, and elevated DHCPv6 to Internet Standard status for improved interoperability in modern IPv6 deployments.[22] As of 2025, ongoing IETF drafts, such as the RFC 8415 bis revision, continue to refine DHCPv6 with minor clarifications on timing parameters and message processing, though no fundamental protocol overhauls have occurred since 2018. In parallel, vendor implementations have incorporated enhanced security measures, such as mitigations for vulnerabilities like memory leaks in DHCP services, exemplified by Infoblox's 2022 patches addressing CVE-2022-2929 to prevent service disruptions from malicious traffic, without necessitating core protocol changes.[23]Protocol Mechanics
Message Exchange Process
The message exchange process in DHCP for initial IP address acquisition follows the DORA sequence: Discover, Offer, Request, and Acknowledge. This process enables a client to obtain an IP address and configuration parameters from a DHCP server without prior knowledge of the server's location.[18] The process begins when a DHCP client broadcasts a DHCPDISCOVER message on its local physical subnet to UDP port 67, using the limited broadcast address 255.255.255.255 as the destination IP and the broadcast address for the link layer. This message includes a randomly generated 32-bit transaction identifier (xid) to uniquely correlate subsequent replies and the client's hardware address (chaddr) in the fixed portion of the message to identify the requesting device. The broadcast ensures that any available DHCP servers on the subnet receive the message, even if the client has no assigned IP address.[18] Upon receiving the DHCPDISCOVER, a DHCP server selects an available IP address from its pool and unicasts a DHCPOFFER message back to the client, using the broadcast address 255.255.255.255 only if the client has set the BROADCAST bit in the flags field (indicating it cannot receive unicast traffic before configuration). The DHCPOFFER includes the proposed IP address in the 'yiaddr' field, the same xid and chaddr for matching, and configuration parameters such as subnet mask and default gateway in the options field. Multiple servers may respond with separate offers, allowing the client to choose.[18] The client then broadcasts a DHCPREQUEST message to UDP port 67, again using 255.255.255.255, to indicate acceptance of a specific offer; this message includes the same xid, the chaddr, the server identifier option specifying the chosen server's IP, and the requested IP address option echoing the 'yiaddr' from the selected offer. Other servers receiving this broadcast discard their pending offers upon seeing a different server identifier. The broadcast nature of the DHCPREQUEST informs all servers of the decision without requiring unicast capabilities from the client.[18] Finally, the selected server responds with a unicast DHCPACK message to the now-configured client IP (or broadcast if necessary), containing the assigned IP in 'yiaddr', the lease duration, the matching xid and chaddr, and the full set of configuration parameters. If the server cannot fulfill the request—such as if the requested IP is invalid for the client's subnet—it instead sends a DHCPNAK message, typically broadcast to 255.255.255.255, prompting the client to restart the discovery process.[18]Lease Acquisition and Renewal
Following the initial lease acquisition through the standard message exchange, DHCP clients maintain network address connectivity by renewing their leases at predefined intervals to prevent expiration and ensure continuous operation.[1] The lease lifecycle is governed by two key timers, T1 and T2, which trigger renewal attempts to balance server load while maximizing client uptime. At T1, which defaults to 50% of the lease duration, the client transitions to the RENEWING state and sends a unicast DHCPREQUEST message to the original leasing server to extend the lease.[24] If no DHCPACK response is received by T2, set at 87.5% of the lease duration, the client enters the REBINDING state and broadcasts a DHCPREQUEST to any available server to seek extension or rebinding of its lease.[24] Upon lease expiration at 100% of the duration without a successful renewal, the client releases the address and returns to the INIT state to initiate a new acquisition.[24] These timers are calculated relative to the lease time provided by the server in the DHCPACK message, with the formulas defined as follows: T1 = 0.5 \times \text{lease duration} T2 = 0.875 \times \text{lease duration} This design, specified in RFC 2131, uses fractional values to avoid dependency on synchronized clocks between clients and servers while ensuring timely renewals that distribute load across the network without excessive interruptions to client connectivity.[24] For clients that already have a pre-configured IP address but require additional configuration parameters without assigning a new lease, the DHCPINFORM message is used. The client sends a DHCPINFORM (either unicast or broadcast) with its own IP in the 'ciaddr' field, prompting the server to respond with a DHCPACK containing the requested options but omitting lease time and 'yiaddr' fields, as no address allocation occurs.[25] On the server side, lease management involves maintaining a database to track assigned IP addresses, their associated clients, expiration times, and hardware addresses for verification. Expired leases are marked for reuse, with servers optionally probing the address (e.g., via ICMP Echo Request) before reallocation to confirm availability and prevent conflicts. Upon receiving a DHCPRELEASE from a client, the server immediately marks the address as available for reassignment.[26] This database ensures efficient IP resource utilization in dynamic environments.[27]Address Release and Rebinding
In the Dynamic Host Configuration Protocol (DHCP), clients can explicitly surrender their assigned IP address before the lease expires by transmitting a DHCPRELEASE message directly to the allocating server via unicast.[28] This message identifies the lease using the client's identifier option or the combination of the client hardware address (chaddr) and the IP address in the ciaddr field, allowing the server to promptly recognize and process the release request.[29] Upon receipt, the server marks the address as unallocated, freeing it for reassignment to other clients and thereby preventing potential IP address conflicts in the network.[26] If the client fails to renew its lease—such as when the initial unicast renewal attempt to the original server at time T1 (typically 50% of the lease duration) does not yield a DHCPACK response—the client transitions to the REBINDING state at time T2 (typically 87.5% of the lease duration).[24] In this state, the client broadcasts a DHCPREQUEST message containing its current IP address in the ciaddr field and the requested IP address option to request extension of its lease from any available DHCP server on the network.[30] Responding servers evaluate the request and, if they accept responsibility for the address, reply with a DHCPACK to confirm the rebinding; otherwise, they may send a DHCPNAK to indicate rejection, prompting the client to seek a new address.[30] The DHCPRELEASE process ensures immediate availability of the IP address upon server receipt, as the server updates its allocation records without delay, though it may retain associated client parameters for potential future reuse.[26] This mechanism, combined with rebinding, maintains network efficiency by minimizing address exhaustion and avoiding duplicate assignments, particularly in environments with dynamic client connectivity.[28]Configuration Elements
Client Parameters
DHCP servers provide clients with essential network configuration parameters to enable seamless integration into IP networks. The core parameters include the client's IP address, subnet mask, default gateway, and lease time. The IP address is dynamically allocated from a server-managed pool and conveyed in the 'yiaddr' field of the DHCPOFFER or DHCPACK message.[5] The subnet mask, which defines the network portion of the IP address, is specified using a bitmask value in option 1 of the DHCP message.[5] The default gateway, essential for routing traffic outside the local subnet, is provided via the router option (option 3), listing one or more IP addresses in order of preference.[5] The lease time, set in option 51, indicates the duration in seconds for which the IP address assignment is valid, allowing clients to renew before expiration to maintain connectivity.[5] Beyond these fundamentals, DHCP servers commonly supply additional parameters to support broader network services. Domain Name System (DNS) server addresses are delivered through option 6, listing IP addresses of preferred DNS resolvers for hostname resolution.[31] The domain name itself is specified in option 15, enabling clients to append a search domain for unqualified hostnames.[31] For time synchronization, option 42 provides a list of Network Time Protocol (NTP) server addresses.[31] In environments requiring network booting, such as diskless workstations, option 66 identifies a Trivial File Transfer Protocol (TFTP) server name or IP address for retrieving boot files.[31] These parameters are encoded as DHCP options to allow flexible extension.[31] Parameter assignment occurs through server-configured scopes, where addresses and options are selected from predefined pools based on the client's subnet or class. Servers use the gateway IP address (giaddr) from relay agents to identify the client's subnet and allocate accordingly, ensuring addresses align with the local network topology.[5] Client classification, via the vendor class identifier option, further refines selection by matching device types or user groups to specific pools for tailored configurations.[5] DHCP supports both dynamic and static assignments; while most clients receive temporary addresses from shared pools, reservations enable fixed allocations by mapping a client's MAC address (in the chaddr field) or client identifier to a specific IP, guaranteeing consistent addressing for critical devices.[5]DHCP Options and Encodings
DHCP options provide a flexible mechanism for conveying configuration parameters beyond the fixed fields in DHCP messages, allowing servers to supply clients with additional network settings such as IP addresses for gateways or DNS resolvers.[32] Each option follows a standardized TLV (Type-Length-Value) format: a one-octet code identifying the option type, a one-octet length field specifying the number of data octets to follow (excluding the code and length), and a variable-length value field containing the actual data.[32] The option codes range from 0 to 255, with code 0 designated as the Pad option—a single-octet field used solely for padding to align options on desired boundaries without carrying meaningful data—and code 255 as the End option, a single-octet marker signaling the conclusion of the options list in a message.[32] This structure ensures options can be appended to the 'options' field of DHCP messages or, in some cases, to the 'sname' or 'file' fields when space is limited.[32] The primary option space spans codes 1 through 254, enabling a wide array of parameters to be defined and registered with the Internet Assigned Numbers Authority (IANA).[32] Among these, option 53 (DHCP Message Type) is mandatory for DHCP operations and carries a one-octet value indicating the message's purpose: 1 for DHCPDISCOVER (client broadcast to locate servers), 2 for DHCPOFFER (server response with proposed configuration), 3 for DHCPREQUEST (client acceptance or renewal request), 4 for DHCPDECLINE (client rejection due to address conflict), 5 for DHCPACK (server confirmation), 6 for DHCPNAK (server denial), 7 for DHCPRELEASE (client address surrender), and 8 for DHCPINFORM (client query without address request).[32] Other commonly used options include code 1 for Subnet Mask (a four-octet IP address specifying the client's subnet), code 3 for Router (a list of one or more four-octet IP addresses representing default gateways in order of preference), code 6 for Domain Name Server (a list of four-octet IP addresses for DNS servers), and code 51 for IP Address Lease Time (a four-octet unsigned integer in seconds indicating the duration of the assigned address lease).[32] To illustrate the diversity of options, the following table summarizes these and a few additional representative examples from the standard set defined in RFC 2132:| Code | Option Name | Value Format | Purpose |
|---|---|---|---|
| 1 | Subnet Mask | 4 octets (IP address) | Defines the subnet mask for the assigned IP address. |
| 3 | Router | N × 4 octets (N ≥ 1 IP addresses) | Lists default routers, starting with the preferred one. |
| 6 | Domain Name Server | N × 4 octets (N ≥ 1 IP addresses) | Specifies DNS servers for hostname resolution. |
| 15 | Domain Name | Variable-length string (1-255 octets) | Provides the domain suffix for the client's DNS queries. |
| 51 | IP Address Lease Time | 4 octets (unsigned integer) | Sets the lease duration in seconds (0xffffffff for infinite). |
| 53 | DHCP Message Type | 1 octet (enum: 1-8) | Identifies the type of DHCP message being sent. |
| 54 | DHCP Server Identifier | 4 octets (IP address) | Specifies the IP address of the offering DHCP server. |
Network Integration
Relay Agents and Forwarding
DHCP relay agents serve as intermediaries that enable communication between DHCP clients and servers located on different network subnets. When a client and server are not on the same physical subnet, the relay agent receives broadcast messages from the client and forwards them to one or more remote DHCP servers. This functionality builds on the BOOTP relay agent concept but is adapted for DHCP's stateful nature, allowing dynamic IP address assignment across subnet boundaries.[1] The forwarding process begins when a DHCP client broadcasts a message, such as a DHCPDISCOVER or DHCPREQUEST, to the local broadcast address (255.255.255.255) using UDP destination port 67. The relay agent, listening on UDP port 67, intercepts this broadcast and converts it into a unicast packet destined for the configured DHCP server(s) on UDP port 67. To facilitate the return path, the relay agent modifies the DHCP message by inserting its own IP address into the 'giaddr' (gateway IP address) field of the BOOTP/DHCP header, indicating the originating subnet. The server then unicasts its response, such as a DHCPOFFER or DHCPACK, back to the relay agent's IP address in the 'giaddr' field; the relay agent subsequently broadcasts or unicasts this response to the client based on the message flags and client hardware address. This bidirectional relaying ensures that broadcast traffic does not propagate beyond the local subnet, while preserving the necessary routing information.[1] Relay agents are typically configured with a list of one or more DHCP server IP addresses to which client requests should be forwarded, allowing for load balancing and redundancy across multiple servers. This configuration is implemented in network devices like routers or switches using commands such as 'ip helper-address' in Cisco IOS, which specifies the server addresses and enables the relaying function on specific interfaces. Support for multiple servers ensures that if one is unavailable, requests can be directed to alternatives, enhancing network reliability.[1][33] By centralizing DHCP servers in a single location rather than deploying one per subnet, relay agents reduce administrative overhead and hardware requirements. They also limit broadcast traffic to individual subnets, preventing network congestion in larger environments and improving overall efficiency. This approach is particularly beneficial in enterprise networks where clients are distributed across multiple VLANs or segments.[1]Vendor-Specific Extensions
The Dynamic Host Configuration Protocol (DHCP) supports vendor-specific extensions through dedicated options that allow for customized implementations beyond standard configurations. These extensions enable clients and servers from particular vendors to exchange proprietary data, facilitating features such as specialized booting or network-specific policies.[32] Option 60, known as the Vendor Class Identifier, allows DHCP clients to identify their vendor type and hardware configuration to the server.[32] This option consists of a one-octet code (60), a one-octet length field, and a variable-length identifier string, which might include details like "MSFT 5.0" for Microsoft clients.[32] Servers use this information to tailor responses, such as providing vendor-appropriate IP addresses or parameters.[32] Closely related, Option 43 carries Vendor-Specific Information as opaque binary data interpreted only by vendor-specific code.[32] Its format includes a one-octet code (43), a one-octet length, and variable data that can encapsulate sub-options with their own code-length-value structures, ending with a code 255 terminator.[32] This option is commonly used for proprietary features, such as delivering boot server details in Preboot Execution Environment (PXE) scenarios.[32] The vendor is typically identified via Option 60 to ensure targeted delivery.[32] Option 82, the Relay Agent Information option, provides sub-options for relay agents to insert data about the client's network position.[34] Relay agents add this option to the end of client-to-server packets, including sub-option 1 (Circuit ID) as a local identifier like a port number for routing replies, and sub-option 2 (Remote ID) as a unique host identifier such as a modem ID for policy application.[34] The overall format features a one-octet code (82), a length field, and concatenated sub-options in code-length-value tuples.[34] This extension aids in tracking client locations within complex networks, with relay agents removing it before forwarding server responses.[34] Other notable extensions include Option 81, the Client Fully Qualified Domain Name (FQDN), which enables negotiation between clients and servers for DNS resource record updates.[35] This option's structure comprises a one-octet code (81), length, flags (for update responsibilities like server vs. client A record updates), return codes, and the domain name itself.[35] Additionally, Option 93 specifies the Client System Architecture Type, primarily for PXE clients to indicate their pre-boot environment, such as Intel x86 PC (type 0) or EFI IA-32 (type 6).[36] It uses a one-octet code (93), length (even number of octets), and 16-bit architecture identifiers to help servers select appropriate bootstrap images.[36] These extensions collectively allow for flexible, vendor-tailored DHCP deployments while maintaining interoperability.[32]Client Lifecycle
State Transitions
The DHCP client behavior is governed by a finite state machine that ensures orderly acquisition, maintenance, and release of network configuration parameters, preventing address conflicts during network changes or reboots. This state machine, illustrated in Figure 5 of the specification, defines eight primary states and the events triggering transitions between them, driven primarily by message exchanges and lease timers.[37] The standard states per RFC 2131 are as follows:- INIT: The client enters this initial state upon startup or when no valid lease exists; it broadcasts a DHCPDISCOVER message to locate available DHCP servers on the network.[37]
- SELECTING: Upon receiving one or more DHCPOFFER messages, the client transitions here, evaluates the offers, selects a preferred server, and broadcasts a DHCPREQUEST message indicating its choice.[37]
- REQUESTING: The client moves to this state after sending the DHCPREQUEST, awaiting a DHCPACK from the selected server to confirm the lease; if a DHCPNAK is received or the address proves unusable, it returns to INIT.[37]
- BOUND: Once the DHCPACK is received, the client configures its interface with the assigned parameters and enters this state, where the lease is active; it remains here until the renewal timer T1 expires.[37]
- RENEWING: At T1 (typically 50% of the lease duration), the client unicasts a DHCPREQUEST to the leasing server to extend the lease; a successful DHCPACK returns it to BOUND, while failure leads to REBINDING at T2.[37]
- REBINDING: If renewal fails, at T2 (typically 87.5% of the lease duration) the client broadcasts a DHCPREQUEST to any available server; success returns it to BOUND, but lease expiration reverts it to INIT.[37]
- INIT-REBOOT: Clients rebooting with a previously assigned address (e.g., from non-volatile storage) start here, broadcasting or unicasting a DHCPREQUEST to verify the address's validity, then transitioning to REBOOTING to await response; a DHCPACK confirms transition to BOUND, while a DHCPNAK sends it to INIT.[37]
- REBOOTING: Entered after sending DHCPREQUEST from INIT-REBOOT; the client awaits a DHCPACK (transition to BOUND) or DHCPNAK (to INIT) to verify the previously assigned address.[37]