Getting down with DHCP

OK, let's get down with it! Well, down at least as far as Dynamic Host Configuration Protocol is concerned. Your feedback has made it quite clear that Gearhead better get into the details of DHCP or face the consequences.

So DHCP is a client/server system. When, for whatever reason, a network client is without a valid IP address, it is said to be in the INIT state. In this state, the client knows nothing about the network so the first task is to find the DHCP server.

The client sends out a broadcast message (that's a message to both the Ethernet address FF:FF:FF:FF:FF:FF and the IP address 255.255.255.255) called DHCPDISCOVER. This message should be delivered to all DHCP servers on the same network segment, and if the segment has any attached DHCP relay agents, the DHCPDISCOVER message should be forwarded.

When a server receives a DHCPDISCOVER message, it looks in its IP address tables to see if the client should receive either the next address from the pool of available IP addresses or a static address based on the client's media access control (MAC) address, which is the address assigned to the network interface by the manufacturer of that card.

The selected IP address is sent to the client MAC address in a message called a DHCPOFFER. This message specifies the DHCP server IP address, the allocated client IP address, the IP address lease time, the renewal time (normally half the lease duration to prevent the lease from expiring before a renewal is attempted), the rebinding time (a timeout after a failed renewal at which the client, having failed to renew its lease, issues another DHCPDISCOVER request).

The client is now in the SELECTING state and the client issues a DHCPREQUEST message to the server that responded. The server should now respond with a DHCPACK message to confirm the lease, and the client is then considered to be in the BOUND state and should make a persistent record of the lease data.

This record is an important aspect of DHCP because when a machine restarts, it should check to see if the recorded lease expired. If the lease hasn't expired, then the client is in the INIT-REBOOT state and tries to determine whether the lease is still valid by sending out a DHCPREQUEST message containing the IP address.

If the address is still valid according to the DHCP server, the client will receive a DHCPACK message and, if not, a DHCPNAK message. In the latter case, the client transitions to the INIT state and starts all over again.

Now when half of the lease has expired, the client issues a new DHCPREQUEST for the current address and if a DHCPACK is requested, carries on updating the lease data. If a DHCPNAK or no response is received, then the client reverts to the INIT state and the process starts all over.

That's the basics of the DHCP lease process, and it will come as no surprise to you that, in reality, the state machine for the DHCP is a little more complex than we have outlined here. Gearhead recommends you check out a fine book: The DHCP Handbook by Ralph Downs and Ted Lemon, which will give you far more detail than you could ever dream of wanting to know.

INIT yourself at gh@gibbs.com.