Lightening your darkroom with DHCP

As part of an ongoing quest to illuminate the depths, clarify the obscure and lighten your darkroom, over the next few weeks Gearhead plans to cover some of the nuts and bolts of network protocols - that is unless we get sidetracked by some cool tool.

This week we will look at Dynamic Host Configuration Protocol (DHCP). Gearhead will bet that many of you have used DHCP without knowing it, and probably just as many have knowingly used DHCP but don't really know anything about it.

DHCP and its predecessor, BOOTP, were developed to address the major headache of running around and setting up IP addresses on Domain Name System servers, gateways and other machines. Even more aggravating is when the IP address space needs to be changed for some reason. The role of these protocols is to automatically configure devices on a network.

In operation, a BOOTP server listens for broadcasts from devices requesting configuration data and, using the device's media access control (MAC) address, looks in a table and replies with the various parameters - IP address, default router and so on.

This was fine and dandy except that the limitations of BOOTP were numerous. For example, if you assigned Bill's machine address X and it died and was replaced, you had to manually change the BOOTP table to the new MAC address. Doesn't sound like much of a problem, but when you have several thousand PCs, not only is manual address reclamation a huge task, it is guaranteed that you will make errors.

DHCP was designed to overcome the inflexibility of BOOTP, so it supports three ways to allocate IP addresses: automatic allocation assigns a permanent address to a client; dynamic allocation provides a time-limited allocation or lease; and good old static allocation, which works well for things like servers.

In the leasing model, before the lease terminates, the client device must request a renewal and, most commonly, the DHCP will grant one. This is vital because if for some reason the lease isn't renewed, the device should (if the client side is properly designed) lose all IP-based network access.

This is one of the gotchas with DHCP (every serious protocol has gotchas): If the DHCP server goes down or becomes unavailable for any reason (and if you try to run DHCP in a WAN environment, the risks are obviously greater), then the lease can't be renewed. Sayonara device upon lease expiration.

Here's where network design becomes important. DHCP servers need to be located on the same reliable network as the clients rather than across a WAN. This means you need to either allocate subnets to each DHCP server, use static allocation (ugh! although you can then have redundant DHCP servers all serving up the same address space, which you obviously can't with dynamic allocation) or allow very long leases so connectivity problems are unlikely to matter.

Next week: Into the bowels of DHCP. Address your messages to Gearhead at gh@gibbs.com.