The DHCP Handbook: Understanding, Deploying, and Managing Automated Configuration Services

The DHCP Handbook: Understanding, Deploying, and Managing Automated Configuration Services

by Ralph Droms, Ted Lemons
DHCP is an authoritative overview and expert guide to the set up and management of a DHCP server. The book begins with a thorough technical introduction to DHCP—how it was developed, how it interacts with other protocols such as TCP/IP, etc. Part II discusses how DHCP operates; including initial configurations, handling rebooting and lease extension, and DHCP


DHCP is an authoritative overview and expert guide to the set up and management of a DHCP server. The book begins with a thorough technical introduction to DHCP—how it was developed, how it interacts with other protocols such as TCP/IP, etc. Part II discusses how DHCP operates; including initial configurations, handling rebooting and lease extension, and DHCP relay agents. In Part III, the authors share their expertise on the efficient use of DHCP in different environments. Part IV covers the technical intricacies of the interaction between DHCP servers and clients, and how to optimally manage each relationship. The final section covers network hardware, inter-server communication, security, SNMP, and IP mobility. The book concludes with several appendices that provide a rich resource for networking professionals working with DHCP.

Product Details

New Riders
Publication date:
Network Architecture and Development Series
Product dimensions:
7.69(w) x 9.45(h) x 1.57(d)

Read an Excerpt

Chapter 1: An Introduction to DHCP

The Dynamic Host Configuration Protocol (DHCP) automates the process of configuring new and existing devices on TCP/IP networks. DHCP performs many of the same functions a network administrator carries out when connecting a computer to a network. DHCP enables a program to automatically manage policy decisions and bookkeeping tasks. Replacing manual configuration by a program adds flexibility, mobility, and control to networked computer configurations.

This chapter provides an overview of how network administrators allocate, manage, and configure IP addresses, and shows how they can use DHCP to accomplish these same tasks. It also introduces some of the basic terminology required to understand the capabilities that the protocol provides and examines some reasons for, and caveats about, using DHCP.

1.1 Configuring Devices on the Network

Any network administrator using TCP/IP can testify that manually configuring computers attached to a network is a time-consuming and error-prone process. Indeed, at almost any site-regardless of whether DHCP is in use the address assignment and configuration process is automated in some way.

One of the authors of this book, Ted Lemon, worked as a network administrator at the Digital Equipment Corporation (DEC) campus in Palo Alto, California, before DHCP was available to simplify the tasks of address management and configuration. The DEC campus used a central IP address administration system, which was based on a single list, or host table, of computers, IP addresses, and Domain Name System (DNS) names for the entire network.

In order to help introduce you to the task that a DHCP server performs, we will first describe to you, from Ted's perspective, what network administrators did before DHCP became widely available.

As part of the network administration task, we updated the host table with new computers as they were added to the network and changed the entries for computers as their names and addresses changed. Periodically, we ran a shell script on the host table to update the DNS server database. We configured individual computers manually, from the entries in the host table, by physically walking up to each computer and entering the configuration information.

Users had a variety of questions about connecting their computers to the campus network. Usually, they wanted to know what IP address they could use for their computer. To respond to such questions, we asked the following:

  • Who are you?
  • Is this a new device, or was it connected to the network before?
  • What is its old IP address?
  • Where do you need to install this device?
  • In what department do you work?

1.1.1 IP Address Allocation

After we obtained this information, we decided whether to give the user an IP address. It was usually easy to make this decision; if the user was an employee or contractor working in a DEC Palo Alto building, then we gave the user an address. Next we decided what IP address to assign the user. To do this, we had to know what network segments were present at the site, which segment or segments were available in the user's office, and how those network segments were configured.

If we supported a single network segment with a single IP subnet, answering these questions would have been simple, and everyone would have been allocated addresses from that subnet. However, the DEC Palo Alto campus network consisted of many network segments, routed together through a backbone network. Thus, it was a bit more difficult to assign IP addresses. In essence, each network administrator had to remember which network segments were available in which buildings, on which floors, and, in some cases, in which offices. If our memories were faulty, the address allocation was not successful, and we had to perform the process again.

After we determined the network segment to which the user's computer would be attached, we determined whether any IP addresses were available on it and chose one for the user. If not-and this was often the case-then we examined the host table for addresses that appeared to be no longer in use. Occasionally, we configured a new network segment and moved some devices to it to expand the pool of available addresses.

1.1.2 Configuration Information

  • The addresses of the default routers for the network segment to which the device was to be connected
  • The addresses of a primary and secondary domain name server that the device would use
  • The subnet mask and broadcast address

If the device needed specific network services that were not used by all devices on the network, we also informed the user how to access those services and programmed that information into the device. For example, we manually configured a diskless Network File System (NFS) client's NFS mount information, and usually gave different information to each diskless NFS client.

1.1.3 Configuring Network Devices

In general, we got network configuration information into devices in two ways. When configuring a knowledgeable user's machine, we gave the information directly to that user; thus, it took a minute or two to configure a machine over the phone or via a single email message exchange. However, for users who could not configure their own machines, this process took some time. We had to determine where the user was, walk to that user's station (possibly in a different building), log in as root, type the necessary information, restart the machine, and then verify that it worked correctly.

1.1.4 Moving Devices to Different Network Segments

From time to time, a user would move from one office to another, or a user's machine would move from a lab into an office. If the network segment (or segments) to which the user's devices were attached was not available in the new location, we would de-allocate the IP addresses previously assigned to those devices and allocate them new ones on the network segment (or segments) available in the new location.

1.1.5 Moving or Adding Network Services

As organizations within DEC Palo Alto grew, it was not uncommon for us to add new facilities such as printers, name servers, and Network Time Protocol (NTP) servers to the network and then manually configure the addresses for each client. Because we did not always have time to modify the configurations of existing functioning clients, we disseminated information about new network services when new machines were installed or when users complained that, for example, they couldn't access printers closest to their cubicles.

1.1.6 Renumbering the Network

As the organization grew, we restructured the network. On one occasion, the entire DEC corporate network number changed from Class B ( to Class A ( This necessitated changing the IP address of every network device on the Palo Alto campus-more than 1,000 computers. Because we did not have an automatic configuration mechanism, network administrators had to renumber the machines, a process that consisted of walking to every machine and manually changing its IP address. Because people worked odd hours at DEC Palo Alto, we often forced people out of the buildings as we updated the machines. We, then, waited for problem reports indicating which machines were renumbered incorrectly.

1.1.7 Reclaiming Disused IP Addresses

Machines for which we allocated IP addresses eventually failed, moved out of our jurisdiction, or were reassigned to different users and reinstalled, at which time the machines lost their old identities. When we were aware of these transitions, we easily updated our records and reclaimed the IP addresses belonging to such machines. However, if the transfer occurred without our knowledge, then we were not aware that these IP addresses were no longer in use.

In such cases, we had no reliable way to determine whether an IP address was no longer in use. Although we often used the ping command (ICMP Echo Request/Reply protocol) to determine whether an address was still in use, no response to such a command unfortunately indicated only that the address was not in use at that moment. The address could have been configured in a device that was powered off. We eventually found ways of handling this problem. First, we tried to locate the person who owned the device for which the IP address was allocated. If we couldn't find the owner of the device, we pinged a suspect IP address periodically for about a month, and if we did not receive a response during that period, we reclaimed the address. Occasionally someone powered up a device that was disused for a few months, and the new device to which the old device's IP address was assigned started behaving erratically...

Meet the Author

Ralph Droms, Ph.D., is an educator, Consultant, and author. He is the chair of the IETF Dynamic Host Configuration (DHC) Working Group on automated configuration of networked computers and is an Associate Professor of Computer Science at Bucknell University. Ralph organized the DHC Working Group in 1989. He has chaired the working group since its inception and is a key contributor to the design and development of DHCP. Ralph is also editor of the DHCP RFCs and continues to participate in the evolution of DHCP. Previously, Ralph was a member of the computer science faculty at Pennsylvania State University. He has also been on the research staff at IBM and Burroughs (Unisys). Since joining the Computer Science Department at Bucknell in 1987, Ralph has guided students through the study of TCP/IP internetworking, operating systems, and computer architecture. He also served as Co-Director of the computer center at Bucknell, where he supervised the design and implementation of the campus-wide multi-protocol network. As a consultant in network architecture and infrastructure design, Ralph works with large and small companies on a variety of TCP/IP issues including network architecture, server strategies and configurations, and the use of DHCP, DNS, and other technologies in network management.

Ted Lemon is the author of the Internet Software Consortium DHCP Distribution, a popular Open Source distribution that includes a DHCP server, DHCP client, and relay agent. He started programming in 1977, when he decided to make a few changes to the Star Trek game, and has been working in the computer industry since 1983. Ted first encountered the DHCP protocol whileworking as a network administrator at Digital Equipment Corporation in the early 1990s, and he has been active in the IETF DHC Working Group since 1996. He is convinced that, while answering questions on the ISC DHCP mailing lists, he has answered roughly half of the questions ever asked about DHCP, and he was motivated to work on this book in hopes of being able to help answer these questions more efficiently. He currently works for Internet Engines, Inc., developing the latest version of the ISC DHCP distribution.

Customer Reviews

Average Review:

Write a Review

and post it to your social network


Most Helpful Customer Reviews

See all customer reviews >