Read an Excerpt
Chapter 1: An Introduction to DHCPThe 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 NetworkAny 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 AllocationAfter 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 DevicesIn 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 SegmentsFrom 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 ServicesAs 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 NetworkAs the organization grew, we restructured the network. On one occasion, the entire DEC corporate network number changed from Class B (126.96.36.199) to Class A (188.8.131.52). 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 AddressesMachines 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...