How DHCP Works

For a detailed description of DHCP, we suggest that you download RFC 1541 from any of the Internet draft repository sites. A good place to start is ds.internic.net, available via FTP, Gopher and HTTP. For a less detailed description, read on.

DHCP is an extension of BOOTP, the previous IP allocation specification. So, existing BOOTP devices can communicate with DHCP servers and allow DHCP requests to cross routers running BOOTP forwarders. This level of backward compatibility makes it easy for administrators to upgrade their network devices from BOOTP to DHCP as needed, without having to replace all of the clients at once or having to upgrade all of the routers.

Several major advancements beyond the BOOTP specifications provide significant advantages. For example, DHCP supports the concept of a "lease" whereby a server can allocate an address to a client for a specific amount of time. If you have more devices than IP addresses, using shorter leases can help to keep you from running out of addresses. If you have more addresses than devices, you can utilize permanent leases or you can assign fixed addresses to specific devices similar to BOOTP's mechanism.

Also, DHCP incorporates a much more robust dialogue during lease negotiation. Since the addresses can be assigned to the devices on an ad-hoc basis, mechanisms need to be incorporated into the assignment procedure that allow for a broader range of options, as well as for a broader range of error handling conditions. BOOTP protocol only allowed for two types of messages (request and reply), while DHCP has seven possible message types that can be used during the address assignment sequence.

When a DHCP device attaches itself to the network for the first time, it broadcasts a DHCPDISCOVER packet. A DHCP servers on the local segment will see the broadcast and return a DHCPOFFER packet that contains an IP address and other information. The servers may or may not conduct some sort of preliminary testing prior to offering the address, such as generating an ARP or an ICMP echo to see if the address is already in use by another node somewhere. If your network does not have a DHCP server on every segment, you will need to configure your routers to provide BOOTP relay agents that forward the broadcasts to a predefined server on a remote segment.

The client may receive multiple DHCPOFFER packets from any number of servers, so it must choose between them, and broadcast a DHCPREQUEST packet that identifies the explicit server and lease offer that it likes the best. This decision may be based on which offer has the longest lease or which offer provides the most information that the specific client needs for optimal operation (more on this later). The non-chosen servers would notice the explicit DHCPREQUEST packet and go on about their business.

Assuming that the offer is still valid, the chosen server would return a DHCPACK that tells the client the lease is finalized. If the offer is no longer valid for some reason-perhaps due to a time-out or another client allocating the lease-then the selected server must respond with a DHCPNAK message. This would cause the client to send another DHCPDISCOVER packet, starting the process over again.

Once the client receives a DHCPACK, then all ownership and maintenance of the lease is the responsibility of the client. For example, a client may refuse an offer that is detailed in the DHCPACK message, and it is the client's responsibility to do so. Clients are supposed to test the addresses that have been offered to them by conducting ARP broadcasts. So if another node responds to the ARP, the client would assume that the offered address is in use. At this point, the client would reject the offer by sending a DHCPDECLINE message to the offering server, and would also send another DHCPDISCOVER packet, thereby starting the process yet again.

Once the client has the lease, it must be renewed prior to the lease expiration through another DHCPREQUEST message. If a client finishes using a lease prior to its expiration date, the client is supposed to send a DHCPRELEASE message to the server so that the lease can be made available to other nodes. If the server doesn't hear from the client by the end of the lease, it marks the lease as non-renewed, and makes it available for other clients to use.

This sequence of events is pretty straightforward and leaves a lot of room to correct any miscommunication between the clients and the servers. This is a good thing, because most of the implementations that we studied at in our labs didn't follow the letter of the law very well. Only because of the negotiation model's failure-centric approach does the technology work at all.