- Shopping Bag ( 0 items )
Ships from: acton, MA
Usually ships in 1-2 business days
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.
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:
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.
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.
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...
|1||An Introduction to DHCP||9|
|2||An Example of DHCP in Operation||23|
|3||Configuring the DHCP Server||33|
|4||Configuring TCP/IP Stacks||47|
|5||DHCP Client-Server Model||63|
|6||The Format of DHCP Messages||73|
|7||Transmitting DHCP Messages||87|
|8||DHCP Message Exchanges||99|
|10||Theory of Operation of a DHCP Server||147|
|11||The Microsoft DHCP Server||155|
|12||The ISC DHCP Server||171|
|13||Configuring a DHCP Server||197|
|14||Client Identification and Fixed-Address Allocation||219|
|15||Setting Up a Reliable DHCP Service||235|
|16||Tuning Your DHCP Service||251|
|18||Automatic DHCP Client Registration||285|
|20||Setting Up DHCP in a Small Office or Home||315|
|21||Authentication of DHCP Clients and Servers||327|
|23||Debugging Problems with DHCP||353|
|24||The DHCP Database||369|
|25||Communication between DHCP Servers||387|
|26||Guiding the Evolution of DHCP||397|
|27||DHCP for IPv6||407|
|App. A||Microsoft DHCP Server Examples||421|
|App. B||ISC DHCP Server Configuration File Reference||437|
|App. C||The DHCP Message Format||463|
|App. D||DHCP Options Summary||467|
|App. E||Other DHCP Resources||481|
|App. F: Bibliography||485|
|App. G: Lists of Related RFCs||489|
|App. H||DHCP Server and Operating System Versions||491|
|App. I: Glossary||499|