DHCP reuses the BOOTP message format and relay agent behavior to allow existing BOOTP clients to interoperate with DHCP servers without modification, and to avoid requiring a DHCP server on each physical network segment.

ip

DHCP supports three IP address allocation mechanisms: automatic (permanent assignment), dynamic (time-limited lease enabling reuse), and manual (administrator-assigned, DHCP used only for delivery). Dynamic allocation is the only mechanism allowing automatic reuse of addresses no longer needed.

ip

Lease durations are represented as relative times in unsigned 32-bit seconds (0xffffffff = infinity) rather than absolute timestamps, because clients and servers may not have synchronized clocks. A server may return a shorter lease duration to the client than it commits internally to compensate for clock drift.

ip

The minimum options field size was extended to 312 octets, bringing the minimum DHCP message to 576 octets—the minimum IP datagram size a host must accept per Host Requirements RFCs. This ensures DHCP messages are always deliverable without fragmentation.

ip

The 'vendor extensions' field from BOOTP was renamed 'options' in DHCP to clarify that these are general configuration parameters, not vendor-specific data. A new 'client identifier' option was added to decouple client identification from the hardware address ('chaddr') field.

ip

A host with multiple network interfaces must run DHCP independently through each interface to obtain configuration parameters for each. DHCP is not intended for use in configuring routers.

ip

DHCP is designed to interoperate with BOOTP: existing BOOTP clients can use DHCP servers without modification. DHCP/BOOTP relay agents forward messages transparently. A separate RFC details interactions between BOOTP and DHCP clients and servers.

ip

A client that cannot receive unicast IP datagrams before its protocol software is configured SHOULD set the BROADCAST bit to 1 in DHCPDISCOVER and DHCPREQUEST messages. A server or relay agent SHOULD honor the BROADCAST bit: if set, send as IP broadcast to 255.255.255.255; if clear, send unicast to 'yiaddr'/'chaddr'.

ip

After receiving DHCPACK, a client SHOULD broadcast an ARP reply to announce its new IP address and clear outdated ARP cache entries on the client's subnet. Before sending ARP to probe a suggested address, the client MUST use 0 as the sender's IP address to avoid corrupting ARP caches.

ip

DHCP clients MUST adopt a retransmission strategy with randomized exponential backoff: first retransmission after 4 seconds ±1 second uniform random, next after 8 seconds ±1, doubling each time up to a maximum of 64 seconds.

ip

DHCP messages broadcast by a client prior to obtaining an IP address MUST have the source address field in the IP header set to 0. DHCP uses UDP port 67 (server) and port 68 (client).

ip, udp

If options extend into the 'sname' and 'file' fields, the 'option overload' option MUST appear in the 'options' field. The 'options' field MUST be interpreted first, then 'file', then 'sname'. Each overloaded field MUST begin with the first octet, be terminated by 'end', and padded with 'pad' options.

ip

If the lease expires before the client receives a DHCPACK, the client moves to INIT state and MUST immediately stop any other network processing. If subsequently given a new network address, the client MUST NOT continue using the previous network address.

ip

If the server does not receive a 'client identifier' option from the client, the server MUST use the contents of the 'chaddr' field to identify the client and associate it with its lease.

ip

T1 defaults to 0.5 * lease_duration and T2 defaults to 0.875 * lease_duration; both SHOULD be chosen with random 'fuzz' around these fixed values to avoid synchronization of client reacquisition across multiple hosts. T1 and T2 are configurable by the server through options.

ip

The 'DHCP message type' option MUST be included in every DHCP message. This option defines the type of the DHCP message, and additional options may be allowed, required, or not allowed depending on the message type.

ip

The DHCPREQUEST message from a client responding to a DHCPOFFER MUST include the 'server identifier' option to indicate which server was selected. The DHCPREQUEST must use the same 'secs' value and be sent to the same broadcast address as the original DHCPDISCOVER.

ip

Upon receipt of a DHCPDECLINE message, the server MUST mark the network address as not allocated and SHOULD notify the local system administrator of a possible configuration problem.

ip

Vendors defining 'vendor specific information' options MUST document those options in the DHCP Options document format, MUST use defined or well-defined data types, and MUST choose options that can be readily encoded in configuration files for interoperability across vendors.

ip

DHCP clarifies the 'siaddr' field as the address of the next bootstrap server, distinct from the 'server identifier' option which always contains the responding DHCP server's own address. A server may return its own address in 'siaddr' if it supplies the next bootstrap service.

ip

Lease time T1 and T2 renewal timers: at T1 the client unicasts DHCPREQUEST to the original server (RENEWING state); at T2 the client broadcasts DHCPREQUEST to any server (REBINDING state). In both states, if no response arrives, the client retransmits at half the remaining interval down to a minimum of 60 seconds.

ip

Seven DHCP message types are defined: DHCPDISCOVER (client broadcast to locate servers), DHCPOFFER (server offer), DHCPREQUEST (client selects server or renews), DHCPACK (server confirms), DHCPNAK (server refuses), DHCPDECLINE (client rejects parameters), and DHCPRELEASE (client relinquishes address).

ip

The 'client identifier' option allows a client to supply an explicit identifier (e.g., hardware address or DNS name) to the server, eliminating overloading of 'chaddr'. If absent, the server uses 'chaddr' as the client identifier. New client identifier types are registered with IANA.

ip, registry

The first four octets of the 'options' field MUST contain the magic cookie decimal values 99, 130, 83, 99 (matching RFC 1497). Subsequent option data consists of tagged TLV parameters; the last option must always be the 'end' option.

ip

The 'giaddr' (gateway IP address) field carries the relay agent's address. If non-zero, the server sends return messages to UDP port 67 on the relay agent at 'giaddr'. If zero and 'ciaddr' is set, the server unicasts to 'ciaddr'; otherwise it broadcasts or uses 'chaddr' for link-layer delivery.

ip

DHCP provides no authentication of DHCP messages. Clients may be misled by rogue servers, and the address pool may be exhausted by malicious clients sending many DHCPDISCOVER messages with spoofed hardware addresses. The protocol relies on the network infrastructure to limit exposure to such attacks.

security, ip

DHCP client state machine has seven states: INIT (begin, send DHCPDISCOVER), SELECTING (collect DHCPOFFER messages), REQUESTING (send DHCPREQUEST, await DHCPACK/DHCPNAK), BOUND (configured, await T1), RENEWING (T1 expired, unicast DHCPREQUEST to original server), REBINDING (T2 expired, broadcast DHCPREQUEST), and INIT-REBOOT (reuse known address, send DHCPREQUEST with 'ciaddr'). DHCPNAK or lease expiration drives return to INIT.

ip

DHCP message format inherits BOOTP structure: op (1 octet), 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). Total minimum size is 576 octets.

ip

The 'flags' field (2 octets) has a single defined bit: the BROADCAST (B) flag at the leftmost position. Remaining 15 bits are MBZ (MUST BE ZERO). Clients set B=1 when they cannot receive unicast before being configured with an IP address.

ip