A separate 'client identifier' option was introduced to decouple the client's logical identity from 'chaddr' (the hardware address), which was previously overloaded in BOOTP both as a transmission address and a client identifier. This allows identifiers such as DNS names or serial numbers that persist across hardware changes.

ip

DHCP clients broadcast DHCPREQUEST (during SELECTING) rather than unicasting directly to the chosen server so that all servers that received the original DHCPDISCOVER also receive the DHCPREQUEST, enabling non-selected servers to release any tentatively held addresses.

ip

DHCP messages use the BOOTP message format (RFC 951) to enable BOOTP relay agents to forward DHCP messages without modification, eliminating the need for a DHCP server on every physical subnet. This also allows existing BOOTP clients to interoperate with DHCP servers without software changes.

ip

The BROADCAST flag in the 'flags' field was added to handle clients whose TCP/IP stack cannot receive unicast IP datagrams before being configured with an IP address; setting this bit instructs servers and relay agents to broadcast replies rather than unicast to the uninitialized client.

ip

DHCP must interoperate with BOOTP relay agents as specified in RFC 951 and RFC 1542; existing BOOTP clients interoperate with DHCP servers because DHCP is a superset of the BOOTP message format. DHCP servers must also provide service to BOOTP clients.

ip

DHCPINFORM is a new message type added in RFC 2131 (not present in RFC 1541), allowing a client with an externally configured address to request other local configuration parameters without triggering address allocation.

ip

If a DHCP server has no record of a client sending DHCPREQUEST in INIT-REBOOT state, the server MUST remain silent (rather than sending DHCPNAK) to allow peaceful coexistence of multiple non-communicating DHCP servers on the same network segment.

ip

A client MUST be prepared to receive a DHCP message with an 'options' field of at least 312 octets, implying readiness to receive a 576-octet message (the minimum IP datagram size). Larger messages may be negotiated via the 'maximum DHCP message size' option.

ip

A DHCPREQUEST generated during RENEWING state MUST fill in 'ciaddr' with the client's current IP address and MUST NOT include 'server identifier' or 'requested IP address' options; the message is sent unicast directly to the server.

ip

A DHCPREQUEST in SELECTING state MUST include the 'server identifier' option indicating the chosen server, and the 'requested IP address' option MUST be set to the yiaddr value from the chosen DHCPOFFER. The message MUST use the same 'secs' value and broadcast address as the original DHCPDISCOVER.

ip

DHCP clients MUST use UDP port 67 (DHCP server port) for client-to-server messages and servers send replies to UDP port 68 (DHCP client port). A server with multiple network addresses MAY use any of its addresses in outgoing messages.

ip, udp

If a client uses a 'client identifier' in any message, it MUST use that same identifier in all subsequent messages so that servers correctly identify the client. The identifier MUST be unique to the client within its subnet.

ip

If the client detects that the address in the DHCPACK message is already in use (e.g., via ARP), the client MUST send a DHCPDECLINE message to the server and restart the configuration process, waiting a minimum of ten seconds before restarting to avoid excessive traffic.

ip

If the options extend into the 'sname' and 'file' fields (option overload), the 'option overload' option MUST appear in the 'options' field. Options MUST be interpreted in order: 'options' field first, then 'file' field, then 'sname' field.

ip

If the server receives a 'client identifier' option, the server MUST use that identifier to identify the client in all interactions. If no 'client identifier' is provided, the server MUST use the 'chaddr' field to identify the client.

ip

Lease times in DHCP messages are represented as relative times in unsigned 32-bit seconds; 0xffffffff represents infinity. Because client and server clocks may not be synchronized, the server may return a shorter lease than it commits to its database to compensate for clock drift.

ip

Servers SHOULD probe a newly allocated address (e.g., with ICMP Echo Request) before offering it, and clients SHOULD probe the received address (e.g., with ARP) before using it, to avoid duplicate address assignment.

ip

The client MUST adopt a retransmission strategy using a randomized exponential backoff algorithm. The initial retransmission delay SHOULD be 4 seconds randomized ±1; subsequent delays SHOULD double up to a maximum of 64 seconds.

ip

The server MUST choose a 'server identifier' address that is reachable from the client. When giaddr is zero (same subnet), the server SHOULD select the IP address used for communication on that subnet; when the message arrived via a relay agent, the server SHOULD choose an address from the receiving interface.

ip

The server MUST NOT send a lease expiration time to the client in response to a DHCPINFORM message and SHOULD NOT fill in 'yiaddr'; the server unicasts the DHCPACK reply directly to the 'ciaddr' field of the DHCPINFORM.

ip

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

ip

When giaddr is 0x0 in a DHCPREQUEST or when sending a DHCPNAK with giaddr zero, the server MUST broadcast the DHCPNAK to the 0xffffffff broadcast address because the client may lack a correct network address and may not answer ARP requests.

ip

A lease binding is the collection of configuration parameters, including at least an IP address, associated with a DHCP client. The combination of 'client identifier' (or 'chaddr') and assigned network address constitutes the unique identifier for a lease, used by both client and server.

ip

DHCP defines eight message types: DHCPDISCOVER (client broadcast to locate servers), DHCPOFFER (server response with offered parameters), DHCPREQUEST (client selects an offer or renews a lease), DHCPACK (server commits configuration), DHCPNAK (server rejects client address), DHCPDECLINE (client reports address in use), DHCPRELEASE (client relinquishes lease), and DHCPINFORM (client requests parameters without address allocation).

ip

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

ip

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

ip

DHCP in RFC 2131 provides no authentication mechanism for DHCP messages, making it vulnerable to unauthorized servers sending bogus replies, malicious clients impersonating legitimate ones, and resource exhaustion attacks that deplete the address pool. The protocol relies entirely on physical network security.

security, ip

The DHCP client state machine has states: INIT (send DHCPDISCOVER), SELECTING (collect DHCPOFFER replies, send DHCPREQUEST), REQUESTING (await DHCPACK/DHCPNAK), BOUND (configured, wait for T1), RENEWING (T1 expired, unicast DHCPREQUEST to server), REBINDING (T2 expired, broadcast DHCPREQUEST), INIT-REBOOT (send DHCPREQUEST with prior address), and REBOOTING (await DHCPACK/DHCPNAK). DHCPNAK in most states returns client to INIT.

ip

A DHCP message consists of 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), followed by a variable-length options field. Total fixed portion is 236 octets.

ip, udp

The 2-octet 'flags' field has bit 0 defined as the BROADCAST (B) flag; the remaining 15 bits are reserved and MUST be set to zero by clients and ignored by servers and relay agents.

ip