Streamlining Network Administration with DHCP
Larry Bennett Configuring networked systems for TCP/IP can be an administrative headache. Whenever systems are installed or moved to a different segment they need an address, name, subnet mask, and the address of a default gateway. Likewise, changes to the network - such as a DNS name server moving to a new machine, or a new router being installed for use as the default gateway - require configuration data to be changed on all client systems. If there are hundreds or thousands of clients, the cost of manually making these changes mounts quickly. In addition to the tedium and the cost of manual configuration, there's also the potential for error. Two machines with the same IP address cause problems; if one of the machines happens to be an important file or application server, it could cause a big problem. One solution is the Dynamic Host Configuration Protocol (DHCP). The network administrator defines client attributes (IP address, subnet mask, etc.) in one place: a DHCP server. Thus, whenever a network client boots, the server provides the information the client needs to get its TCP/IP stack up and running. (See Figure 1 for a description of how the protocol works.) The DHCP server does all the dirty work of TCP/IP configuration, so the administrator's time and energy can be spent actually managing and improving the network. System administrators who have implemented DHCP report very high satisfaction with the results. It saves time when systems are installed and prevents misconfiguration, which is a common source of trouble in TCP/IP networks. DHCP also makes changes to the network very easy to implement. For example, one administrator was able to renumber seven subnetworks with 150 systems merely by updating the DHCP server. DHCP is also useful with systems that move frequently - either portables or just PCs that move from one department to another. DHCP automatically reassigns an IP address appropriate for the current location. DHCP may sound a little like BOOTP, the Bootstrap Protocol. That's not surprising, because DHCP is based on BOOTP. But while BOOTP provides a simple address assignment function, DHCP offers much more. I'll begin by looking at the DHCP protocol. It's an Internet Engineering Task Force (IETF) Draft Standard, described in Request for Comments (RFC) 2131 and 2132. Three Types of Address Allocation The DHCP specification supports three different types of address assignment (manual, automatic, and dynamic) to meet the needs of varying types of hosts and networks. With manual allocation, the administrator chooses an address for the client, and the DHCP server delivers it. Manual allocation gives total control to the administrator; nothing is left to chance. This type of allocation is ideal for a client that needs a specific permanent address, for example a DNS name server that other systems reference by address. The administrator enters the required address in the DHCP server along with a client ID, typically the medium access control (MAC) address. The first time the client boots, it contacts the DHCP server. Based on the client's identifier, the DHCP server searches its tables and gives the client its IP address. The client has the address on an "infinite lease" (permanent assignment). That means if the machine's taken off the net, the administrator must go to the DHCP server and remove the address manually. Why not just configure the IP address on the client itself? First, because using DHCP saves time. All the configuration can be done from one location rather than on each individual system. This unified approach makes it easier to keep track of network configuration and to pass administrative duties to assistants or successors. All of your systems - PCs, UNIX systems, diskless workstations, and portables - have their configuration data in one place, regardless of what part of the network they're in. Also, the DHCP server can give your client other configuration parameters in addition to the address; I'll discuss this in detail below. Automatic allocation hands over the task of address selection to the DHCP server. This works well for systems that don't need a specific address. Assume you want to install twenty new PCs. The DHCP server is primed with a range of appropriate IP addresses. When one of the PCs is initialized for the first time, the server automatically selects an IP address from the range and delivers it to the client. The server notes the IP address-MAC address pair in its table. Then, every time the PC comes up, the server checks its table and returns that same address to it. Like manual allocation, automatic allocation as described in the RFCs gives the client an "infinite lease" - that is, the address is a permanent assignment. If the client is removed from the network, the address assignment remains in the server's tables until the administrator removes it. So, automatic allocation is best for stable environments in which the client stays on one network for a long while, and in which there are plenty of addresses to go around. Dynamic allocation takes the automation of address assignment one step further. As with automatic allocation, the server selects and assigns an address from its pool, but with a "fixed term" rather than an infinite lease. That means the client gets the address for a certain period of time. The lease can be any duration the administrator chooses. For instance, suppose a portable computer typically stays connected to the network for up to 4 hours. The DHCP server can be configured to give this client a 4-hour lease. When the client goes down, the server can recapture the IP address and offer it to another host. If the original client wants to continue operation longer than 4 hours, it can renew the lease. If the client doesn't renew before the lease expires, the server takes the address back. In practice, the server will try not to reassign that address unless necessary, holding it in reserve for the original client. But if addresses are in demand, it can assign the address to another host. (See Figure 2 for details of how clients handle lease renewal.) Dynamic allocation is good for intermittently connected systems, such as portables. Dynamic assignment can also be useful in a stable environment in which the network manager wants to cut down on "IP address hoarding." People will be able to keep only the addresses they're actually using. This can be very useful when addresses are in short supply. Custom Configuration DHCP's capabilities are not limited to addresses. It can serve nearly any TCP/IP configuration parameter a system might need. Most systems will need not just an IP address but a domain name, a subnet mask, and the locations of default gateways and name servers. DHCP can serve these, and many more. More than 70 of these options are defined in RFC 2132. A sampling of the available options is listed below.
The network administrator simply defines a value for each parameter of interest, and enters it in the DHCP server's tables. Parameters can be defined on a network-wide basis if desired. But DHCP also allows administrators to define parameters for individual hosts, or for subnets or other groups. For instance, each subnet can have a different default gateway, or the length of an address lease can be set differently for a certain machine type. The DHCP spec refers to this capability as "persistent storage of network parameters." The client's identifier is called a key. This may be simply the MAC address, or a more complex ID such as subnet number plus MAC address. The server matches the key to its entries and delivers the appropriate configuration profile. Suppose that 10 new PCs are about to be installed in the accounting department. The administrator has defined a set of configuration parameters appropriate for machines on the accounting subnet, including a range of addresses, domain name, subnet mask, default router, and name server. The lease duration for this group is defined as 90 days, since they're not expected to move around often. All this information has been defined to the DHCP server. As each machine is booted, it will broadcast a DHCPDISCOVER message. The server will recognize which subnet the machine is on and deliver the appropriate parameters in its DHCPOFFER. The server knows the subnet from which the request originated for one of two reasons:
Although DHCP has more bells and whistles than BOOTP, it uses the basic BOOTP message formats and the BOOTP port numbers. Like BOOTP, it relies on UDP (the User Datagram Protocol) for message transmission. The reason for these similarities is that the designers considered it vital that DHCP clients be able to use BOOTP relay agents. A relay agent, as mentioned above, is a router or other system configured to forward address requests to other networks. When a DHCP or BOOTP client initializes, it broadcasts a request for a server. This broadcast is sent only on the local network, since forwarding it to others would generate a large amount of traffic - even looping packets. Without relays, every local network would need a DHCP server. This would be a management nightmare because each must be configured to serve the correct information to clients. Relays solve this problem by taking client broadcasts from a particular network and forwarding them directly on to the DHCP server. By ensuring there is a relay on each network, a single DHCP server can handle a relatively large internetwork. It's also important to use relays when switches are used to create virtual LANS. Each switched segment needs a relay, or DHCP messages will not get off the virtual LAN to the server. The DHCP spec makes it mandatory for implementations to support BOOTP relays. Interoperability between DHCP clients and BOOTP servers (or vice versa) is allowed by the DHCP RFCs, but not required. So, support depends on your implementation. For instance, some vendors' TCP/IP stacks will not allow a DHCP client to get an address from a BOOTP server. However, most DHCP server implementations include some level of support for BOOTP. Remember that a BOOTP client cannot accept a dynamic lease from a DHCP server; it will hang onto any address it's given until the administrator takes it away. DHCP and DNS The Domain Name System (DNS) maps domain names, such as www.samag.com, into the IP addresses they represent. DNS name servers are configured with files that determine how names correspond to addresses. If you are using DHCP to hand out addresses, how do you keep the DNS synchronized with DHCP? I'll look at two basic cases. The first case is that of a host which requires a specific name. This includes the classic "well-known host" such as a Web or file server, but can also be a client that you wish to access by name. Whenever the DHCP server gives one of these hosts a new address, you must alter the mapping in your name server's configuration files. Otherwise, the next time an application tries to access the well-known host by name, the DNS will return the wrong IP address. The second case is that of an anonymous or generic host. You don't care what its name and address are, and nobody else does either. Fine, but you're not necessarily off the DHCP-DNS hook. Suppose you're using automatic allocation in a large dynamic environment. Because the DHCP server tries to reserve a particular address for each client, the server will potentially allocate a large number of different addresses - one for each client that ever requests an address. Thus, you need to define a large number of name-to-address mappings to handle each address that may be allocated. This can burden you with precisely the sort of administrative chore you are using DHCP to avoid. It can also mean wasted disk space and poor DNS performance. The solution to this problem is automated DNS updating, (i.e., making the DHCP server inform the name server of the addresses assigned). Until recently, there was no standard way to automatically update the DNS, since the original DNS spec provided only for manual editing of the zone files (the data files containing DNS name-to-IP-address mappings). However in April 1997, a spec for automatic DNS updating was published (RFC 2136, "Dynamic Updates in the Domain Name System"). The spec defines a way for DHCP servers to inform DNS servers of changes to DNS name-to-IP-address mappings. The information is included in a DNS Message, which is sent via UDP or TCP. In the meantime, various proprietary methods of DHCP-DNS updating have emerged. For instance, IBM's AIX DHCP implementation includes a function called Dynamic DNS. And, increasing numbers of vendors have entered the market with integrated DHCP-DNS management packages. Cisco (www.cisco.com) offers DHCP-DNS Manager, an "integrated suite of TCP/IP management applications" for UNIX and Windows NT servers. Cisco's DHCP server creates names for each address in its automatic allocation pool. When the server gives a new host a name and address, it updates the DNS Manager, which replaces the primary name server. There are several other DNS-DHCP solutions available from other vendors, including:
DHCP and CIDR Increasingly, network managers are building large physical networks, that is, LANs made up of hundreds of nodes, using switches to link together individual segments. Such networks usually need a Class B IP address, since a Class C allows only up to 254 systems. However, it is difficult to get a Class B address these days, so, managers must make do with blocks of Class C addresses. This procedure leads to routing tables becoming bloated with large numbers of Class C addresses. CIDR (Classless Interdomain Routing) was developed to avoid this resulting inefficiency. CIDR allows contiguous Class C network addresses to be "supernetted" into a super-address, so that routers can treat the block of network addresses as a single entity. A network mask indicates which bits of the IP address refer to the supernet. For example, rather than assigning the Class C networks 206.82.6.0 and 206.82.7.0 to two separate LANs, they are assigned to systems on one large physical network. The addresses are aggregated using supernetting so that external routing tables need list only this super-address and its associated network mask. (Note that the two addresses differ only in the least significant bit of the third octet; thus the mask can indicate that this bit is to be ignored when determining the network portion of the address.) This use of supernetting requires special support in DHCP servers. In particular, the server must be able to understand that a group of Class C network addresses is treated as a single address range, and allocate addresses from the range accordingly. In the example just mentioned, you would want the server to allocate addresses from the range 206.82.6.1 through 206.82.7.254. One vendor claiming to have such support in their server is Cisco. DHCP and IPv6 Interest in DHCP is booming due to the growth of TCP/IP intranets and the Internet. But the fate of DHCP depends on what happens to IP addressing in the future. And, IP addressing may soon undergo a radical change with the advent of IP version 6. The exponential growth of the Internet has strained the capacity of IP version 4's three-tier, 32-bit addressing scheme. CIDR, which allows more efficient use of class C networks, has eased the pain, but only temporarily. There simply aren't enough unique IP addresses for all potential users under the current scheme. Hence the development of IPv6, which (among many other features) incorporates a 128-bit addressing scheme. The core elements of IPv6 are documented in RFC 1883 and RFC 1884, which were issued in December 1995. How soon will IPv6 happen, and how will it affect DHCP? Several big networking vendors are now developing for IPv6, but most industry analysts agree the new protocol will take years to displace IPv4, due to the huge installed base of IPv4-compliant systems. Some industry players are hoping that fixes to IPv4 will prolong its life indefinitely. These fixes include add-on security and Quality of Service features and Network Address Translation that allows intranets to use unregistered IP addresses, with translation at the router gateway. At this time, IPv6 exists only in test implementations, and no major ISPs have upgraded to the protocol. In the meantime, those who want to get a headstart on IPv6 will be running dual TCP/IP stacks and tunneling IPv6 packets over existing IPv4 networks by encapsulating them in IPv4 datagrams. And, they can also start thinking about address management for IPv6. A new IPv6-compliant DHCP is described in two IETF draft documents (draft-ietf-dhc-dhcpv6-10.txt and draft-ietf-dhc-dhcpv6ext-06.txt), both published in May 1997. DHCPv6 IPv6 includes an autoconfiguration capability, referred to as "stateless," as part of the base protocol. This will automatically provide a workable address for an IPv6 system. However, DHCPv6 provides a stateful counterpart to IPv6's stateless autoconfiguration capability. DHCPv6 gives the network manager tighter control over the way addresses are assigned, in addition to providing for configuration of attributes other than addresses. The draft spec for DHCPv6 introduces several significant changes to the protocol:
Some network managers have expressed concern about implementing DHCPv4 in their networks with IPv6 looming on the horizon. However, it's likely to be a long time before the IPv6 train gathers enough steam to require a DHCP upgrade. Rather than hold your breath, it makes sense to take advantage of the benefits offered now by existing DHCP implementations. Experience implementing DHCPv4 will put you in a good position if the switch is eventually made. The protocols are very similar. Are You in Control? DHCP is undoubtedly convenient, but once the DHCP server starts handing out addresses, who has control of your network? An informal survey, conducted by asking a question in the newsgroups comp.d-com.net-management and comp.unix.admin, provided some insight into system administrators' experiences with the issue of control. All respondents had implemented DHCP in their networks, which ranged in size from 125 machines in 6 subnets to 700 machines in a 10-site WAN. Without exception, these administrators were extremely satisfied with DHCP. They said things like, "DHCP is the greatest thing since sliced bread" and "I consider DHCP gaining control, not losing it." One administrator stated, "I prefer DHCP since this way I can at least prevent users from doing really silly misconfiguration ...". Respondents also mentioned the ease of centrally updating gateways and DNS servers, the ability of users to log in at any one of several locations and get the same configuration, and the way DHCP lets them move machines from one subnet to another without "forever reassigning numbers and troubleshooting strange TCP/IP errors." But can't DHCP cause problems when you don't know which machine has which IP address? One respondent stated that he only needed to know the addresses of servers, routers, and hubs - and those were given static addresses. Another said that when he needs to know which system has a particular IP address, he queries his (Windows NT) DHCP server for the corresponding MAC address. He then uses SNMP to query his hubs to determine the physical port to which the MAC address is attached. From there he can identify the system. Conclusion DHCP lets the network administrator save time and energy, rationalize TCP/IP configuration, and avoid costly manual configuration errors. This protocol offers several types of automated address assignment, making it suitable for a range of networks and systems. Depending on the implementation, DHCP can interoperate with BOOTP clients and servers, automatically update the DNS with name and address assignments, and accommodate the use of CIDR blocks to create multiple logical networks on a single large physical network. Thus, DHCP can reduce the drudgery of TCP/IP network administration, allowing you to get on with planning and managing your network. About the Author
Larry Bennett is an independent consultant specializing in UNIX networking, TCP/IP and network managment. He is the author of the recent book Multiprotocol Network Management: A Practical Guide to NetView for AIX, published by McGraw-Hill. He can be reached on the Internet at: lcb@munetworks.com.
|