Dynamic Host Configuration Protocol

Automatic assignment of IP numbers to network clients on boot-up eliminates some of IP's administrative complexity.

As an open , standards-based protocol that is robust and WAN efficientnot to mention the fact that it's the protocol of the InternetTCP/IP offers many advantages over other network protocols. But like anything else, TCP/IP has a downside. Its biggest drawback is administrative complexity; great effort is required to keep a TCP/IP network running well.

The problem stems from the protocol's need to have a valid IP address for every device on the network. If you've worked with TCP/IP networks, you're probably aware of several important rules that network administrators must follow when assigning IP addresses:

• The IP address must consist of four bytes (four eight-bit numbers).

• Each IP address must be unique.

• All devices on a segment must have the same network number and subnet number.

• Each subnet number must be unique.

Communicating with nodes on a different subnet or a different network requires a router.

(For more information on TCP/IP addressing, see the Tutorial "IP Addresses and Subnet Masks.")

Assigning an IP address to a nodeand doing it correctlycan be a significant administrative hassle. In particular, you need to track the addresses that have been assigned in order to avoid duplication. Moreover, if a node is moved to a different subnet, the subnet portion of the address must be changed to that of the new subnet. You also need to check that the node-specific portion of the IP address (the remainder, after you exclude the subnet bits) doesn't conflict with any other node on the new subnet.

Automating The Job

Keeping track of IP address assignments and making new assignments sounds like the perfect kind of mind-numbing task to delegate to computersand it is! The Dynamic Host Configuration Protocol (DHCP) was developed to accomplish that exact job. DHCP is fully described in the Internet Requests for Comments (RFC) 1541, but I'll summarize the highlights.

DHCP is based upon the Bootstrap Protocol (BOOTP), a system for automatically delivering configuration information from a BOOTP server to BOOTP clients on boot-upthe point when clients first connect to the network.

Under DHCP, a computer is designated as the DHCP server. All of the other computers on the networkat least, those that need an IP addresswill be DHCP clients (computers that already have a permanently set IP address don't need to participate). The network administrator needs to initially configure the DHCP server. Part of that configuration process involves assigning the DHCP server a block of IP address numbers that it can dispense to nodes that need IP addresses.

When a new node comes onto the network assuming it is capable of being a DHCP clientit will broadcast a request for an IP address. Simply put, the DHCP server will respond by checking its table of address assignments, selecting the next available address, and sending a response back to the requesting node.

The actual process is more complex than that, as the requesting client must first find a DHCP server. Also, the protocol is constructed so that a client may negotiate with more than one DHCP server.

Here's how it works: A DHCP client that is in need of configuration broadcasts a dhcpdiscover packet in search of servers (see Figure 1). This packet will contain the hardware address of the requesting client, for example, its Ethernet or Token Ring address. It might also contain a suggested IP address. Next, one or more DHCP servers will evaluate the request and respond with a dhcpoffer packet, which contains an offer of a specific IP address, together with a "lease period" (the length of time the client may use the address).

Figure 1: A DHCP client negotiates IP address "lease" through this sequence of packet exchanges.

The client then selects one from among the dhcpoffer packets it receives. (The client's selection will depend on its design; it may seek the longest lease, for example.) The client then issues a dhcprequest packet, which contains the address of the server that issued the dhcpoffer it prefers.

The chosen server then issues an acknowledgment packet (dhcpack), which closes the negotiations. The dhcpack packet contains the IP address and lease period that have been agreed upon. The server now marks this address as committed; it cannot be assigned to any other client for the duration of the lease. The client configures itself to use its new assigned address and begins normal network operation.

Note that more than one DHCP server may respond to a dhcpdiscover with a dhcpoffer. The client must pick one offer, responding with a dhcprequest packet containing the server identifier for the server it has chosen. The other servers monitor the dhcprequest packet and infer from the server identifier that their offers were not chosen; they then know that the IP addresses they offered are still available for assignment to another client.

As mentioned, the selected server finalizes the offer by issuing the dhcpack, but in the event that the server cannot commit the configuration, it will issue a dhcpnak (negative-acknowledgment) packet. In this case, the client must start the whole request process over again, from the top.

Dispensing Ip Addresses

DHCP provides for IP addresses to be allocated in three different ways: With automatic allocation , the DHCP server assigns a permanent IP address to a DHCP client requesting an address. Using dynamic allocation , the DHCP server would assign an IP address for a limited period of time (the "lease period") or until the DHCP client specifically relinquishes it, whichever comes first. The third method is manual allocation in which the IP address is chosen by the network administrator, but the DHCP server is used to convey the assignment to a DHCP client.

Dynamic allocation is particularly useful for computers that will connect to the network only occasionally. When a DHCP client is about to disconnect from the network, and thus no longer needs an IP address, it can notify the DHCP server, which can then reassign the number to the next node that needs an address. Dynamic allocation makes more efficient use of a limited number of IP addresses. A group of occasional users, for example, can share a smaller pool of IP addresses than if each required a permanent address of its own.

Dynamic allocation won't work for every node, however. If the IP addresses of network servers were to change frequently and randomly , network clients would have a hard time finding servers. Thus, as a general rule, it's best to use static addresses for servers and dynamic addresses for clients.

As mentioned earlier, DHCP is an offshoot of BOOTP. Where DHCP differs from BOOTP is that the BOOTP server merely stores a preset configuration for a BOOTP client and delivers it on boot-up. It doesn't eliminate the need to set up a configuration for the client. DHCP, by contrast, automatically configures DHCP clients, using rules pre-established by the administrator.

When setting up DHCP on a network, you must decide where to locate the DHCP servers. You could put one server on each subnet, or you could have one central DHCP server to which all the clients must connect in order to get an IP configuration. Because much of the communications between DHCP clients and servers take place via broadcasts, the central DHCP server approach requires that routers be capable of forwarding DHCP packets or that some other type of "relay agent" forwards the packets. BOOTP uses relay agents, and DHCP takes advantage of this. The format of DHCP packets is specifically designed to be nearly identical to BOOTP packets, so that BOOTP relay agents can forward DHCP packets.

Figure 2 shows a simple two-subnet network, in which a router is acting as a relay agent. When a DHCP client on Subnet 1 issues a broadcast in order to discover a DHCP server, the router forwards the packet onto Subnet 2 where the DHCP server resides, using the unicast address of the DHCP server as the destination address. The router also notes from which subnet the discovery packet was issued and encodes that information into the discovery packet. When the DHCP server issues a reply packet, the router will forward it to Subnet 1, using IP unicast or broadcast, depending on the client's capabilities. A DHCP client on Subnet 2 doesn't need the services of a relay agent, because it can interact directly with the DHCP server (both are on the same subnet).

Figure 2: Unless there's a DHCP server on each subnet, intervening routers must be capable of being BOOTP relay agents, which can forward BOOTP and DHCP packets.

Who's Using It

The first RFCs for DHCP were issued in 1993. Most vendors have adopted it and developed products that support it. Most prominently, perhaps, is Microsoft, which built DHCP server capability into Windows NT 3.5 and higher. Windows for Workgroups 3.11 and Windows 95/98 both have DHCP client capability. Thus, you could set up one or more Windows NT Servers to be DHCP servers. Other networked nodes running Windows 95, Windows for Workgroups, Windows NT Workstation, or Windows NT Server could be DHCP clients.

Apple's Open Transport (the successor to MacTCP) includes DHCP client capability. SunSoft's (Mountain View, CA) SolarNet PC Admin network management software includes a DHCP server. Many of the third-party TCP/IP packages for Windows have DHCP client capability. On Technology (Cambridge, MA) announced a DHCP server NLM for NetWare 3.11 and 4.x file servers, and subsequent versions of NetWare servers and NDS have native support for DHCP.

The Simple Life

DHCP can simplify life dramatically for managers of TCP/IP networks. It automates the process of assigning an initial IP address to a client, easing the task of adding new clients to a network. Moreover, if a client moves from one subnet to another, DHCP can make the appropriate adjustments to the client's IP configuration. Lastly, dynamic allocation lets you time-share a block of IP addresses among many clients, reducing the total number of IP addresses required.

This tutorial, number 91, by Alan Frank, was originally published in the March 1996 issue of LAN Magazine/Network Magazine.