DHCP

DHCP stands for Dynamic Host Configuration Protocol, and is used to centrally allocate and manage TCP/ IP configurations of client nodes.


If you’ve got more than a handful of computers to manage, then DHCP can help to save a great deal of time and trouble in setting up and administering a TCP/ IP network. DHCP offers the following features:

The Dynamic Host Configuration Protocol (DHCP) provides configuration parameters to Internet hosts. DHCP consists of two components: a protocol for delivering host-specific configuration parameters from a DHCP server to a host and a mechanism for allocation of network addresses to hosts.

DHCP is built on a client-server model, where designated DHCP server hosts allocate network addresses and deliver configuration parameters to dynamically configured hosts. Throughout the remainder of this document, the term "server" refers to a host providing initialization parameters through DHCP, and the term "client" refers to a host requesting initialization parameters from a DHCP server.

A host should not act as a DHCP server unless explicitly configured to do so by a system administrator. The diversity of hardware and protocol implementations in the Internet would preclude reliable operation if random hosts were allowed to respond to DHCP requests. For example, IP requires the setting of many parameters within the protocol implementation software. Because IP can be used on many dissimilar kinds of network hardware, values for those parameters cannot be guessed or assumed to have correct defaults.

Also, distributed address allocation schemes depend on a polling/defense mechanism for discovery of addresses that are already in use. IP hosts may not always be able to defend their network addresses, so that such a distributed address allocation scheme cannot be guaranteed to avoid allocation of duplicate network addresses.

DHCP supports three mechanisms for IP address allocation. In "automatic allocation", DHCP assigns a permanent IP address to a host. In "dynamic allocation", DHCP assigns an IP address to a host for a limited period of time (or until the host explicitly relinquishes the address). In "manual allocation", a host's IP address is assigned by the network administrator, and DHCP is used simply to convey the assigned address to the host.

A particular network will use one or more of these mechanisms, depending on the policies of the network administrator.

Dynamic allocation is the only one of the three mechanisms that allows automatic reuse of an address that is no longer needed by the host to which it was assigned. Thus, dynamic allocation is particularly useful for assigning an address to a host that will be connected to the network only temporarily or for sharing a limited pool of IP addresses among a group of hosts that do not need permanent IP addresses. Dynamic allocation may also be a good choice for assigning an IP address to a new host being permanently connected to a network where IP addresses are sufficiently scarce that it is important to reclaim them when old hosts are retired.

Manual allocation allows DHCP to be used to eliminate the error-prone process of manually configuring hosts with IP addresses in environments where (for whatever reasons) it is desirable to manage IP address assignment outside of the DHCP mechanisms.

The format of DHCP messages is based on the format of BOOTP messages, to capture the BOOTP relay agent behavior described as part of the BOOTP specification [7, 23] and to allow interoperability of existing BOOTP clients with DHCP servers. Using BOOTP relaying agents eliminates the necessity of having a DHCP server on each physical network segment.

DHCP can quickly become an essential piece of an organization's data network. Once set up, DHCP (Dynamic Host Configuration Protocol) is usually hardly noticed, silently and faithfully performing its duties day in and day out. Unfortunately, the hardest thing about DHCP is getting it to that point.

This article discusses some of the reasons why an organization would want to use DHCP, along with the many different issues that need to be considered when designing a DHCP infrastructure. Some of these considerations include planning for IP address use. An organization needs to determine how its existing environment is used and what types of users and workstations are being utilized (such as mobile users and network devices).

In large-scale DHCP implementations, the topology of the network becomes a very important factor. The network topology dictates where DHCP servers and/or relay agents must be placed. The needs of the DHCP client must be considered, including which DHCP options are supported by the client's operating system and which options and their correspomding values need to be assigned. Finally, all of these elements are brought together to implement the DHCP scopes.

How DHCP Works

For a detailed description of DHCP, we suggest that you download RFC 1541 from any of the Internet draft repository sites. A good place to start is ds.internic.net, available via FTP, Gopher and HTTP. For a less detailed description, read on.

DHCP is an extension of BOOTP, the previous IP allocation specification. So, existing BOOTP devices can communicate with DHCP servers and allow DHCP requests to cross routers running BOOTP forwarders. This level of backward compatibility makes it easy for administrators to upgrade their network devices from BOOTP to DHCP as needed, without having to replace all of the clients at once or having to upgrade all of the routers.

Several major advancements beyond the BOOTP specifications provide significant advantages. For example, DHCP supports the concept of a "lease" whereby a server can allocate an address to a client for a specific amount of time. If you have more devices than IP addresses, using shorter leases can help to keep you from running out of addresses. If you have more addresses than devices, you can utilize permanent leases or you can assign fixed addresses to specific devices similar to BOOTP's mechanism.

Also, DHCP incorporates a much more robust dialogue during lease negotiation. Since the addresses can be assigned to the devices on an ad-hoc basis, mechanisms need to be incorporated into the assignment procedure that allow for a broader range of options, as well as for a broader range of error handling conditions. BOOTP protocol only allowed for two types of messages (request and reply), while DHCP has seven possible message types that can be used during the address assignment sequence.

When a DHCP device attaches itself to the network for the first time, it broadcasts a DHCPDISCOVER packet. A DHCP servers on the local segment will see the broadcast and return a DHCPOFFER packet that contains an IP address and other information. The servers may or may not conduct some sort of preliminary testing prior to offering the address, such as generating an ARP or an ICMP echo to see if the address is already in use by another node somewhere. If your network does not have a DHCP server on every segment, you will need to configure your routers to provide BOOTP relay agents that forward the broadcasts to a predefined server on a remote segment.

The client may receive multiple DHCPOFFER packets from any number of servers, so it must choose between them, and broadcast a DHCPREQUEST packet that identifies the explicit server and lease offer that it likes the best. This decision may be based on which offer has the longest lease or which offer provides the most information that the specific client needs for optimal operation (more on this later). The non-chosen servers would notice the explicit DHCPREQUEST packet and go on about their business.

Assuming that the offer is still valid, the chosen server would return a DHCPACK that tells the client the lease is finalized. If the offer is no longer valid for some reason-perhaps due to a time-out or another client allocating the lease-then the selected server must respond with a DHCPNAK message. This would cause the client to send another DHCPDISCOVER packet, starting the process over again.

Once the client receives a DHCPACK, then all ownership and maintenance of the lease is the responsibility of the client. For example, a client may refuse an offer that is detailed in the DHCPACK message, and it is the client's responsibility to do so. Clients are supposed to test the addresses that have been offered to them by conducting ARP broadcasts. So if another node responds to the ARP, the client would assume that the offered address is in use. At this point, the client would reject the offer by sending a DHCPDECLINE message to the offering server, and would also send another DHCPDISCOVER packet, thereby starting the process yet again.

Once the client has the lease, it must be renewed prior to the lease expiration through another DHCPREQUEST message. If a client finishes using a lease prior to its expiration date, the client is supposed to send a DHCPRELEASE message to the server so that the lease can be made available to other nodes. If the server doesn't hear from the client by the end of the lease, it marks the lease as non-renewed, and makes it available for other clients to use.

This sequence of events is pretty straightforward and leaves a lot of room to correct any miscommunication between the clients and the servers. This is a good thing, because most of the implementations that we studied at in our labs didn't follow the letter of the law very well. Only because of the negotiation.