Dynamic Host Configuration Protocol
obsoleted by
- rfc-1541 — Dynamic Host Configuration Protocol
Extracted elements (27)
DHCP is intentionally designed as a mechanism rather than a policy: administrative controls such as restricting responses to pre-registered hosts or enforcing local address policies are left entirely to server implementations rather than being mandated by the protocol.
DHCP reuses the BOOTP message format to capture BOOTP relay agent behavior without modification, eliminating the need for a DHCP server on each physical network segment and enabling interoperability with existing BOOTP clients without changes to their initialization software.
Lease times are represented as relative rather than absolute times because clients and servers may not have synchronized clocks. To compensate for clock drift, a server may return a shorter lease to the client than it commits to its own database.
The BROADCAST flag resolves a bootstrapping deadlock: some client implementations cannot receive unicast IP datagrams until configured with a valid IP address, yet need to receive DHCPOFFER/DHCPACK to obtain that address. Setting the flag instructs the server to broadcast its reply.
The client broadcasts DHCPREQUEST (rather than unicasting to the selected server only) so that all other servers that sent DHCPOFFER messages receive implicit notification that their offer was declined, allowing them to free any tentatively reserved addresses.
DHCP is designed to interoperate with BOOTP clients and relay agents: from a client's perspective DHCP is an extension of BOOTP, existing BOOTP clients can interact with DHCP servers without modification, and DHCP must interoperate with BOOTP relay agent behavior as specified in RFC 951.
A client that cannot receive unicast IP datagrams before protocol software is configured SHOULD set the BROADCAST flag to 1 in DHCPDISCOVER and DHCPREQUEST messages; a client that can receive unicast before configuration SHOULD clear it to 0.
A DHCPREQUEST sent in response to a DHCPOFFER MUST include the 'server identifier' option to indicate the selected server; however, a DHCPREQUEST sent during lease renewal (RENEWING or REBINDING states) MUST NOT include a 'server identifier'.
A host with multiple network interfaces MUST use DHCP through each interface independently to obtain configuration parameters for those separate interfaces.
DHCP clients MUST adopt a retransmission strategy using randomized exponential backoff: first retransmission after 4 seconds ±1, second after 8 seconds ±1, doubling each time to a maximum of 64 seconds.
Every DHCP message MUST include the 'DHCP message type' option, which defines the type of the message; additional options may be allowed, required, or prohibited depending on the message type.
If options extend into the 'sname' and 'file' fields, the 'option overload' option MUST appear in the 'options' field; overloaded fields MUST begin at their first octet, MUST be terminated by an 'end' option, and MUST be padded with 'pad' options. The 'options' field MUST be interpreted first.
If the client's lease expires before a DHCPACK is received, the client moves to INIT state and MUST immediately stop all other network processing, then restart initialization as if uninitialized.
Messages broadcast by a client before it has obtained an IP address MUST have the IP header source address set to 0.
Vendors defining 'vendor specific information' options MUST document them in the form of the DHCP Options document, MUST use defined or well-defined data types, and MUST choose options that can be encoded in configuration files for exchange with other vendors' servers.
When a server receives a DHCPDECLINE message, it MUST mark the network address as not allocated and SHOULD notify the local system administrator of a possible configuration problem.
DHCP defines seven message types: DHCPDISCOVER (client broadcast to locate servers), DHCPOFFER (server offer of parameters), DHCPREQUEST (client selection or renewal), DHCPACK (server confirmation with committed address), DHCPNAK (server refusal), DHCPDECLINE (client reports address conflict), and DHCPRELEASE (client relinquishes lease).
DHCP supports three IP address allocation mechanisms: automatic (permanent assignment), dynamic (time-limited lease enabling address reuse), and manual (administrator-assigned address conveyed via DHCP). Dynamic allocation is the only mechanism that allows automatic reuse of addresses.
DHCP uses UDP as its transport: client-to-server messages are sent to port 67 ('DHCP server' port) and server-to-client messages are sent to port 68 ('DHCP client' port).
Lease durations are unsigned 32-bit relative times in seconds; 0xffffffff is reserved to represent 'infinity' and the minimum lease duration is one hour. Times T1 (default 0.5 × lease) and T2 (default 0.875 × lease) govern entry into RENEWING and REBINDING states.
The 'client identifier' option provides an explicit, decoupled client identity to the server, which may be a hardware address or another type (e.g., DNS name); new identifier types are registered with IANA. If absent, the server MUST use 'chaddr' to identify the client.
When a server selects an address in response to DHCPDISCOVER, it applies a priority order: (1) the client's previously recorded address if still available, (2) the address in the 'Requested IP Address' option if valid and unallocated, (3) a new address from the server's pool.
DHCP provides no authentication mechanism for DHCP messages, leaving the protocol vulnerable to malicious servers supplying false configuration parameters or rogue clients claiming addresses. The specification relies entirely on administrative controls and network-layer security rather than cryptographic authentication of DHCP participants.
The DHCP client state machine has eight states: INIT, SELECTING, REQUESTING, BOUND, RENEWING, REBINDING, INIT-REBOOT, and REBOOTING. Key transitions: INIT→SELECTING on DHCPDISCOVER broadcast; REQUESTING→BOUND on DHCPACK; BOUND→RENEWING at T1 expiry (unicast DHCPREQUEST); RENEWING→REBINDING at T2 expiry (broadcast DHCPREQUEST); REBINDING or RENEWING→INIT on lease expiry or DHCPNAK.
A DHCP message has fixed fields: 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), and a minimum 312-octet options field, bringing the minimum total message size to 576 octets.
The 2-octet 'flags' field has its leftmost bit defined as the BROADCAST (B) flag; the remaining 15 bits are reserved (MBZ), MUST be set to zero by clients, and MUST be ignored by servers and relay agents.
The options field begins with the four-octet magic cookie (decimal 99, 130, 83, 99), followed by tagged options; the final option in every DHCP message MUST always be the 'end' option.