Article

DHCP: The Next Generation Host Configuration Scheme

Bjorn Satdeva

If you have installed a large number of workstations at your site, setting up the initial and minimum configuration for each by hand, you must have wondered if there were not a better and more efficient way to do it. Once the setup is complete, most configuration can be done through automated procedures, such as rdist(1), but it would be nice to automate that initial phase also. And there is in fact an easier way on the way. The Internet Engineering Task Force (IETF) has come up with an RFC, to be implemented soon by several vendors, which can do some of this work. The new method is based on an extension to the older BOOTP protocol and is known as the Dynamic Host Configuration Protocol, or DHCP. This protocol provides a means of sending network configuration information accross the network, from a DHCP server to a client, typically a new workstation.

DHCP has three different mechanisms for assigning a client an IP address:

In "automatic allocation mode" the DHCP server assigns an IP address to the client permanently.

In "dynamic allocation mode" the DHCP server assigns an IP address to the client for a limited amount of time.

In "manual allocation mode" the IP address of the client is explicitly assigned by the system administrator, and the DHCP role here is only to forward that address through the same communication method used with the previous two methods.

The system administrator can configure the server to use these three methods in any combination, in accordance with local site policies. If the administrator uses the dynamic allocation method, then any assigned address can be "recycled" and used again at a later time, after that host no longer needs the address. The RFC which decribes this protocol suggests that this method is useful where IPs are to be assigned to machines that will be in use only temporarily, or where there are a limited number of IP addresses available on the network. My own experience inlcudes an instance where an automatic, but temporary, assignment of IP addresses would have been useful. In that particular case, machines were brought up on the network for a few days while they were installed and configured and then they were disconnected and rolled out the door to be shipped to customers. Even though the production people had an assigned set of IP addresses, they were constantly able to find new ways to use duplicate addresses. DHCP would have been a blessing there.

Since the DHCP protocol and message format is based on the older BOOTP protocol, a brief look at how BOOTP operates will serve as a good introduction to the world of DHCP.

The BOOTP Protocol

BOOTP is a bootstrap protocol (using UDP) which allows a diskless client machine to find out which IP address it should use, the IP address of the boot server, and which file it should load into memory and executed. This bootstrap operation is done in two steps. The BOOTP protocol handles the first step, which consists of finding the relevant IP addresses and determining what file should be transferred from the boot server. The second step, which consists of loading the bootstrap program into memory, is typically done with TFTP, but could be performed with another file transfer protocol, such as FTP.

Although the format of the protocol package is of little interest to system administrators, but in order to understand the protocol, it's necessary to venture a little into this area. The BOOTP protocol uses the same package format for both requests and replies. Each package is 328 bytes long, the first 20 bytes are occupied by the IP header, and the following 8 bytes are used by the UDP header. The remaining 300 bytes are used by the BOOTP protocol.

BOOTP presents a problem for the server of the chicken and egg variety. How can the server send a response to the client, if the client does not yet know its own address? The client cannot respond to Address Resolution Protocol (ARP) requests until it has learned its own address. In UNIX, the server will often solve this problem by cheating. If the server uses the ioctl system call to enter the client into the ARP cache, then the server's ARP module will have the client's IP address in the cache.

If the client already knows its IP address from some other source, then the server can respond in the normal manner.

The Design of DHCP

The goal of the DHCP protocol is to provide a method of configuring a client that has no implicit policies embedded. The intention is to give the local system administrator full control over configuration issues. This is an important feature: too many system administration tools implement implicit policies that may or may not be appropriate for a given site.

Another useful feature of DHCP is that it does not necessarily require manual configuration. Each client is able to discover everything it needs to know without user or system administrator intervention, and is able to enter this information into its own configuration.

DHCP allows the server to be anywhere on the local network (i.e., it does not require the server to be on the local subnet). Because the clients are required to choose one of several replies, it is possible to have multiple servers to increase availability and reliability.

Finally, DHCP has been designed to co-exist with hosts that were configured the old-fashioned way -- that is, by the system administrator editing the configuration files. This backward compatibility means you can start using DHCP without having to reconfigure your existing hosts.

Overview of the Protocol

As mentioned above, DHCP is essentially a number of extensions to the BOOTP protocol. DHCP servers are thus able to interact with clients that can speak BOOTP (though, such clients cannot take advantage of the DHCP extensions). There are two main differences between BOOTP and DHCP. First, DHCP is capable of assigning an IP address to a client for a limited amount of time (the RFC calls this a lease), allowing the address to be recycled when no longer needed. Second, DHCP has a mechanism in place that allows the client to obtain all the IP-related information it needs to be able to operate on the network.

DHCP does show some small differences from BOOTP (the RFC calls these "clarifications"). The vendor extension field in the BOOTP protocol becomes the options field in DHCP, and this field now has a minimum size 0f 312 bytes (larger packet sizes can be negotiated through the "maximum DHCP message size" option). New with DHCP is a "client identifier" option which is used to pass an explicit client identifier to a DHCP server. This change eliminates the overloading of the chaddr field in BOOTP messages, where chaddr is used both as a hardware address for transmission of BOOTP reply messages and as a client identifier. The package format for DHCP is shown in Figure 1. The fields of a DHCP message are shown to Figure 2.

DHCP also provides for vendor specific extensions, through the "vendor specific information" option. The intent here is to allow vendors to implement extensions to the protocol, yet still be able to communicate with servers or clients from other vendors. In fact, the RFC states: "Options encapsulated as 'vendor specific information' must be carefully defined and documented so as to allow for interoperability between clients and servers from diferent vendors." The RFC goes on to specify a number of guidelines vendors must adhere to in order to use this option.

The Dynamic Allocation of IP Addresses

One of the services provided by DHCP is the assignment of IP addresses to clients, whether on a temporary or a permanent basis. The method employed is simple. When a client requests an IP address, it will specify how long the address will be needed. The server(s) will not reallocate that address within the requested amount of time, which is the amount of time the "lease" of the address is valid. The client can extend its lease, or it may give the address back to the server if the address is no longer needed. A lease can be anywhere from one hour (the minimum) to about 100 years; it can also be a permanent lease (a lease of infinite length), as the maximum value for the lease is infinite.

The server can reuse addresses for which the lease has expired. The RFC assigns both the server and the client the responsibility for ensuring that such an addresses is indeed free, but under some circumstances duplicate IP addresses may still occur. It is also possible for the lease on the IP address to expire while the client is up and active. According to the RFC, this should not happen with well-behaved and well-implemented servers and clients, but I think this feature falls in the category of "if you don't absolutely need it, you don't want it!"

A DHCP Example

The following steps represent a small example of how DHCP assigns an IP address to a client. The example refers to various DHCP messages (see Figure 3 for a description of DHCP messages). Figure 4 gives a graphical timeline of the interaction.

1. The client broadcasts a DHCPDISCOVER message to tell the world it needs to know its own IP address.

2. Each server that receives the message responds with a DHCPOFFER message that includes an IP address in the yiaddr field. The server can also return other kinds of configuration information as DHCP options.

3. Based on the configuration parameters offered in the DHCPOFFER messages sent by the servers, the client chooses one server from which to request configuration parameters. It broadcasts a DHCPREQUEST message that identifies which server it has chosen to be configured from.

4. The servers not selected by the client use the message as notification that the client has chosen to use another server. The server selected by the client responds with a DHCPACK message, which contains the configuration parameters for the client.

If the selected server is unable to satisfy the DHCPREQUEST message, it sends a DHCPNAK message (although in this case one wonders why the server responded in the first place).

5. Upon receiving the DHCPACK message containing its configuration parameters, the client performs a check on those parameters (e.g., by sending an ARP for allocated network address), and notes how long it will be allowed to use the address (that is, how long the lease is). Unless the client finds a problem, it is now configured. If the client does find a problem, it notifies the server with a DHCPDECLINE message, and then must start the configuration process over again.

6. If the client at some point finds that it no longer needs the IP address it has been assigned, it can return that address by sending a DHCPRELEASE message to the server. The server is then free to to assign the address to another client.

If the client already knows what IP address it wants to use, it does not need to go through as many steps as in the previous example. Instead, it will follow the process shown in Figure 5 and outlined below:

1. The client broadcasts a DHCPREQUEST.

2. If the request is valid, the servers that know the client's configuration respond with a DHCPACK message. For invalid requests, the servers send a DHCPNAK message.

3. When the client receives the DHCPACK message with its configuration parameters, it performs a check on those parameters in the same manner as in the example above.

How the Lease Works

The concept of the lease of an IP address is new, and a look at how DHCP implements this is worthwhile.

When a server sends configuration data to a client (via a DHCPACK message), it must specifiy how long the client can use the IP address it is assigning. This is done by in one of the following three methods:

If the client already has an IP address assigned, and it does not explicitly request a specific lease time, the server returns the lease period previously negotiated with the client.

If the client does not yet have an IP address assigned and does not explicitly request a specific lease time, the server will set the lease period to the local configured default.

If the client requests a specific lease time and the request is not in conflict with the local policies implemented in the server configuration, the server will confirm the requested time. If the request does conflict with local policies, the server will offer the client a lease that accords with those policies. The client can then choose whether it wants to accept the offer or be configured from another server.

To make all this work, the servers themselves must be consistently configured. The RFC requires that a server always return:

The client's network address and the subnet mask for the network to which the client is connected.

The expiration time for the client's lease.

Parameters requested by the client, according to the one of the following rules:

-- If the server has been explicitly configured with a default value for the parameter, the server must include that value in an appropriate option in the option field.

-- If the server recognizes the parameter as a parameter defined in the Host Requirements Document (RFC 1122 & 1123), the server must include the default value for that parameter as given in the Host Requirements Document in an appropriate option in the option field.

-- The server must not return a value for that parameter.

Any parameters from the existing binding that differ from the Host Requirements Document defaults.

Any parameters specific to this client (as identified by the contents of chaddr in the DHCPDISCOVER or DHCPREQUEST message), e.g., as configured by the network administrator.

Any parameters specific to this client's class (as identified by the contents of the class identifier option in the DHCPDISCOVER or DHCPREQUEST message), e.g., as configured by the network administrator: the parameters must be identified by an exact match between the client's client class and the client class identified in the server.

Parameters with non-default values on the client's subnet.

If all these conditions are met, the server inserts the xid field from the DHCPDISCOVER message into the xid field of the DHCPOFFER message and sends the DHCPOFFER message to the requesting client.

Security Considerations

DHCP is built directly on UDP and IP, which are still inherently insecure. Furthermore, DHCP is generally intended to make maintenance of remote and/or diskless hosts easier. While perhaps not impossible, configuring such hosts with passwords or keys may be difficult and inconvenient. Therefore, DHCP in its current form is quite insecure.

Unauthorized DHCP servers can be set up easily. Such servers can then send false and potentially disruptive information to clients, such as incorrect or duplicate IP addresses, incorrect routing information (including spoof routers, etc.), incorrect domain nameserver addresses (such as spoof nameservers), and so on. Once this seed information is in place, an attacker can further compromise affected systems.

Malicious DHCP clients could masquerade as legitimate clients and retrieve information intended for those legitimate clients. Where dynamic allocation of resources is used, a malicious client could claim all resources for itself, thereby denying resources to legitimate clients.

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, nor can they be 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 such a distributed address allocation scheme cannot be guaranteed to avoid allocation of duplicate network addresses.

Conclusion

Much of the information in this article has been taken from RFC 1541, which is freely available from ftp.internic.net and many other ftp servers. BOOTP is described in RFC 951.

Several vendors (see Figure 6) are working on providing servers and clients for DHCP, and we should have a multitude to choose from in the near future. The one implementation I have had the opportunity to work with is from Competive Automation, one of the first companies to ship a commercial version of this product. As of this writing they are also the only company I know of that is committed to addressing some of the security problems in the protocol, although I hope other companies will soon follow suit.

DHCP has the promise of enabling system administrators to make the configuration process fully automated, but the unresolved security issues raise a cautionary red flag. A university or the engineering arm of a commercial organization should be able to reap the benefits, while a financial organization will probably want to wait for good vendor extensions or, even better, security amendments to the protocol from the IETF.

About the Author

Bjorn Satdeva is the president of /sys/admin, inc., a consulting firm which specializes in large installation system administration. Bjorn is also co-founder and former president of Bay-LISA, a San Francisco Bay Area user's group for system administrators of large sites. Bjorn can be contacted at /sys/admin, inc., 2787 Moorpark Ave., San Jose, CA 95128; electronically at bjorn@sysadmin.com; or by phone at (408) 241-3111.