4.7. Application-Layer Broadcasting: DHCP¶

4.7.1. DHCP Overview¶

The specification for DHCP is defined in RFC 2131. The full protocol is significantly more complex than either HTTP or DNS, because DHCP requires multiple steps rather than the basic request-response structure. DHCP message exchanges can include negotiation back and forth between the client and server based on the hardware and software requirements of each. Additionally, clients can abort the request before the protocol completes, and the server would need to recognize when this happens and close the connection to free up resources. Implementing the full specification requires building state machines for both the client and server. In this section, though, we limit the discussion to the most basic type of (successful) exchange because it illustrates a new socket programming technique not discussed previously: broadcasting.

Figure 4.7.1: Sequence of DHCP messages across a network

Figure 4.7.1 illustrates the sequence of messages across a network for a DHCP request. To initiate a DHCP request, a new client (such as a laptop) uses UDP to broadcast a DHCP discover message, which declares that the sender is trying to find a DHCP server. In other words, the client sends a message using a reserved IP address that indicates the client does not know the destination. If the client is connected to a router that is running a DHCP server, the router would accept the message and would not forward it. However, if there is no intervening router (e.g., the client is connected via an Ethernet cable), then the message is sent to all hosts on the local network. Most devices on the network are not running DHCP servers, so they have no process listening at the well-known DHCP port number (67). For instance, a connected smart TV or network-accessible storage (NAS) hard drive would not be listening for incoming DHCP requests. For these devices, the OS simply ignores the message.

When the broadcast message is received by a DHCP server, the server replies by broadcasting a DHCP offer that informs the client of the server’s IP address, as well as proposing an IP address for the client to use. If there are multiple DHCP servers running on the network, then any that receives the DHCP discover message will respond with a DHCP offer. The client accepts the offer by sending a DHCP request. Although this message is broadcast, the body of the request contains information to designate which DHCP server’s offer is being accepted. That server confirms the configuration to all devices by broadcasting a final DHCP ACK (acknowledgement) that declares the new client has successfully been assigned to that particular IP address.

4.7.2. DHCP Protocol Messages¶

RFC 2131 defines the core structure of DHCP messages, which is shown in Table 4.10. In this illustration, each row of the table is 32 bits (four bytes) wide, and some fields would require multiple rows, as they are larger than four bytes in size. While this structure shows the relative ordering of the fields, the exact structure depends on the type of message. Depending on the type, some fields may be required, others are optional, and still more are not allowed. RFC 2132 specifies the allowable options.

For the four basic messages shown in Figure 4.7.1, the important fields to consider are op, xid, yiaddr, and siaddr. The op field can be set to either BOOTREQUEST (1) or BOOTREPLY (2), indicating if the message is coming from the client or the server. As in DNS, the xid is a random integer to denote the transaction ID, connecting replies with the specific requests. The yiaddr is used to indicate your (the client’s) IP address, while siaddr is the DHCP server’s address. The other fields, described in the RFC, are beyond the scope of this book. Table 4.11 shows the values of these fields for a sample DHCP request. All messages are sent to the destination IP address 255.255.255.255, which is the reserved value that indicates a broadcast message. The client uses 0.0.0.0 as its source address for the UDP messages, indicating the sending host has no valid address, while the DHCP server can use its own address.

The client distinguishes itself from other new clients by picking a random value to use as the xid, which is 42 for the DHCP discover message in this case; after the server replies with the same xid value, the client and the server repeat the same value again in the later messages. A DHCP discover message from another new client might have 587 for its xid. By receiving a broadcast message with xid 42 from the server, the client that started with 42 has reasonable assurance that it is the intended recipient.

The other fields in the DHCP message establish the new client’s IP configuration. When the server sends the DHCP offer, the yiaddr field contains a proposed value for the client’s address. The client could reject the address, but here we assume that the offer is accepted. The client indicates that it accepts the offer by using the same value in its DHCP request, and the server confirms the acceptance in the DHCP ACK. In addition, these messages establish that the client knows the IP address of the DHCP server (siaddr), along with the duration of the lease—the time during which the client owns this IP address. In this case, the client will have a lease on the address 192.168.1.7 for a maximum of 86,400 seconds (24 hours). When the lease expires, the client would contact the server to renew the lease. At that point, the client would not need to repeat the full protocol; since the client knows the IP address of the server, it does not need to begin back at the DHCP discover stage.