Overview

 The Dynamic Host Configuration Protocol (DHCP) is a protocol used in the TCP/IP networking model for automatically and dynamically configuring hosts attached to a network with parameters they’ll need to be able to use the network. The protocol is defined in RFC 2131 (reference [1]), which updated and clarified the original specification in RFC 1541 (reference [2]); it uses and extends some facilities defined in the BOOTP (Boot Protocol) specification in RFC 951 (reference [3]). The service provided by DHCP frees a network administrator from having to manually configure each host connected to his network (though the protocol does not prevent this, and can provide partial information for hosts which have been partially configured). One of the widest uses of DHCP is for the automatic assignment of network (IP) addresses to hosts. A system administrator configures the DHCP client module with a pool of addresses which it may allocate. The protocol allows reuse of addresses that have been relinquished by hosts that have disconnected from the network; this is especially valuable when the pool of available addresses is limited and shared among all hosts, as in the case of an internet service provider with many dial-in clients. The protocol uses a client-server approach, with the DHCP client requesting network parameters from a DHCP server designated by the network administrator. One of the interesting features of this protocol involves the issue of the addressing of the DHCP messages exchanged by the client and server during the address allocation sequence. Since the purpose of this exchange is to assign a network address to the client, the protocol must specify a mechanism for the server to convey its responses to the client before the client has a valid network address. In addition, the client need not know an address for a DHCP server to initiate its requests for configuration information. 
 

Services

 DHCP is really an application-layer protocol in the TCP/IP model, residing above and using services provided by the Transport layer. The messages exchanged by DHCP use the unreliable UDP (User Datagram Protocol) packet delivery service provided by the Transport layer. DHCP provides its services to the operating system. The operating system can ask the DHCP client module to request certain specific network parameters (usually including an IP address) from a DHCP server whenever the host detects that it has been connected to a network. The parameters are passed from the DHCP layer to the operating system, which then configures the IP layer of the protocol stack with these settings. Thus DHCP is a particularly interesting protocol in that it in a sense provides services for a layer below it in the protocol stack, though of course indirectly, through the operating system (which resides with it in the application layer). 
 

Peer interface

 The client and server peers communicate by exchanging messages in UDP packets, using UDP ports 67 for the server and 68 for the client. Eight types of messages are exchanged: DHCPDISCOVER, DHCPOFFER, DHCPREQUEST, DHCPACK, DHCPDECLINE, DHCPNAK, DHCPINFORM, and DHCPRELEASE. The message type is contained in the field “DHCP message type” (required, but oddly included in the “options” section of the message); the sequence of exchange of these messages during particular transactions is illustrated in the following section. The basic function of the message types is as follows.

DHCPDISCOVER
Sent by a DHCP client when it first wishes to receive configuration information including a network address, containing a list of parameters for which it would like information. Since the client does not in general know the IP address of a DHCP server, this message is sent to the IP broadcast address 0xffffffff. As such, more than one DHCP server may receive and respond to such a message. This can improve reliability by providing redundancy.

DHCPOFFER
Sent by a DHCP server in response to the receipt of a DHCPDISCOVER message, containing values for the configuration parameters requested. Since the client does not at this point have a valid IP address, the server must either address the message using the client’s hardware (data link) address (supplied in the DHCPDISCOVER message), or broadcast the response, or use some other forwarding mechanism; this is discussed in more detail in the section “Relaying messages and addressing”. In addition, the server is not required at this stage to commit these parameters to this client, or reserve them exclusively for this client for any specified period of time; these are merely proposed values, which must be confirmed through subsequent messages. This improves efficiency in the case in which more than one server responds to a client’s inquiry; since the client will choose parameters from only one of the servers, the others shouldn’t be forced to reserve resources that will not be used.

DHCPREQUEST
Sent by a client upon receipt of one or more DHCPOFFER responses. The client selects the parameters offered in one of the DHCPOFFER messages, and sends a DHCPREQUEST containing these same parameter values back to the specific server which provided them. This is necessary since the server isn’t required to reserve those parameter values (including the suggested IP address) for the client when it makes an offer; thus the client must re-confirm that they are still available.

DHCPACK
Sent by a server on receipt of a DHCPREQUEST message if the requested parameters (e.g., IP address) are still available. At this point, the server reserves these parameters for this client; only on receipt of this message can a client consider those parameters to be its own (it becomes “bound”). Since the client may not have a network address until this message has been received, the server may have to address it in some alternate fashion, as in the case of DHCPOFFER messages.

DHCPNAK
Sent by a server in response to a DHCPREQUEST message which requests parameters that are no longer available. If a client receives this message, it must send another DHCPREQUEST message requesting other parameters (or send a new DHCPDISCOVER message if it has no other outstanding offers).

DHCPDECLINE
Sent by a client to a specific server in response to a DHCPACK message, which contain parameters which the client has determined are not in fact valid. For example, the client might test an IP address it has received by sending an ARP (Address Resolution Protocol) message on its shared LAN to see if any other host has been assigned this address; if it discovers that another host is in fact using this address, it must send a DHCPDECLINE message to the server which supplied the address. This both allows the server to release the resources it has allocated to this client, and inform a system administrator of the problem. (Such a problem might arise in a situation in which a host has been manually configured by an administrator with an IP address, but the DHCP server hasn’t been informed that this address is no longer available in its pool. Though it is suggested that a server test an address before allocating it to a client [1, section 3.1, point 2], for example by “pinging” the address to see if another host is using it, it may be that the test or the response to it is lost, incorrectly suggesting to the server that the address is available.)

DHCPINFORM
This is sent by a client when it needs only certain configuration information, but already has a network address. The server sends a DHCPACK in response with the requested parameters.

DHCPRELEASE
Sent by a client to inform the server that it no longer requires the allocated parameters. This allows the server to return these parameters (such as IP address) to its pool for reallocation. This message is not required; the allocated parameters are generally configured with a finite lifetime (called a “lease”), and are deallocated automatically when the lease expires. This is discussed further in the next section, Leases and Renewals.

Leases and renewals

 When a server has allocated a network address to a client, the address is generally provided as a “lease” for a limited period of time. The length of the lease assigned is configurable by the network administrator, and may be very long or even infinite, providing for permanent assignment of IP addresses to specific clients. (The lease time is specified as an unsigned 32-bit value interpreted in seconds, giving finite lease times from 1 second to approximately 100 years [1, section 3.3]; the value 0xffffffff is reserved to represent an infinite lease time.) The lease record for a client is maintained by the server, containing the assigned configuration information, and is identified by either the combination of the client’s hardware (data link) and assigned network address, or by a unique “client identifier” supplied by the client. For finite leases, the client must periodically renew the lease with the server before it expires if it wants to continue using the assigned network address. Clients generally try to renew their leases well before they expire, as they must stop using the assigned address if they are not successful in renewing the lease. The message exchange for the renewal process is illustrated below.

In the case of infinite or very long-term leases, clients will likely be rebooted many times before the lease has expired. In such cases, the client and servers need not go through the entire process of creating a new lease. The client, remembering the IP address it was previously assigned, simply asks the available DHCP servers if any of them holds a valid lease for it; if it receives an affirmative reply, it can then begin using the corresponding network address. The message exchange for this scenario is detailed below. Interestingly, the client does not try to communicate directly with the server which originally provided the lease (which it could presumably do easily by storing the server’s address). This permits multiple servers to serve configuration information, incorporating load balancing and redundancy by distributing leases which are held.

When a lease expires, or a server receives a DHCPRELEASE message from a client indicating that a lease is no longer needed, the server will remove the corresponding lease record and return the associated IP address to its pool of assignable addresses. However, one of the design goals mentioned in RFC 2131 [1, section 1.6] is for the DHCP server to attempt to provide the same IP address to a host between host reboots. This will happen automatically in the case of a still-valid lease, but can be implemented even for relinquished leases if the server reserves deallocated addresses and stores the corresponding expired lease records for some period of time, and inspects these when allocating a new lease for a host to see if a prior lease existed. These “reserved” addresses could easily be reclaimed if they are needed for allocation to other hosts; the obvious disadvantage with this approach is in the extra storage required on the server.

Peer exchanges

 A typical set of peer exchanges is given below. In this, we assume that the DHCP servers are on the same subnet as the client, so that messages can be directly exchanged without the intervention of a BOOTP relay agent (a complication discussed in the section “Relaying messages and addressing”)

Initial configuration: client requires IP address and other parameters

1. Client broadcasts DHCPDISCOVER message
2. Servers broadcast DHCPOFFER messages
3. Client selects one offer, broadcasts DHCPREQUEST message identifying the selected server
4. Selected server broadcasts DHCPACK or DHCPNAK message
   1. if client receives DHCPNAK, returns to step 3; if no remaining offers, returns to step 1.

Comments:

• The client may offer a suggested IP address in its DHCPDISCOVER message.
• The client broadcasts its DHCPREQUEST message, even though at this point it has the IP address of the selected server (supplied in the DHCPOFFER message), so that other servers can see the message and understand that the client is effectively declining their offers [1, section 3.1, point 4].

Lease renewal: client has valid IP address from DHCP server, but lease about to expire

1. Client sends DHCPREQUEST addressed to specific server holding its lease
2. Server sends DHCPACK or DHCPNAK addressed to client
   1. if DHCPNAK, client must obtain a new address using DHCPDISCOVER.

Comments:

• The client indicates to the server that this is an existing lease extension request by not including the “server identifier” option in the options field. The message may include a suggested lease time or other options.
• If the client receives a DHCPNAK message in response to its request, it is being told that its address will be invalid (perhaps reassigned) when its lease expires. As such, it must not use its network address after expiration of the lease, and must obtain a new address.
• Initial communication is unicast, since both the client and server know the other’s network address, and the client’s is still valid until the lease expires. If the server doesn’t respond within a specified timeout interval (which expires before the lease does), the client then broadcasts its request to any servers that might be listening, in the hope that another server might be now holding its lease; one will send a DHCPACK if it can extend the lease on the client’s address (for example, the responding server might be the backup for the previous server, which has been taken out of service). If the client receives no response before its lease expiration, it must acquire a new lease using a DHCPDISCOVER message.

Rebooting, but with valid lease still existing on current IP address ([1, section 4.4.2])

1. Client broadcasts DHCPREQUEST with requested IP address
2. Server sends DHCPACK or DHCPNAK
   1. if DHCPNAK, client must obtain a new address using DHCPDISCOVER.

Comments:

• The client’s DHCPREQUEST message is broadcast, and doesn’t include an identifier for the server, even though the client knows the identity of the server which originally provided its lease. This permits multiple servers to be used to manage leases, which can be useful for load balancing. On the other hand, at most one server must respond; otherwise, multiple leases could be held on multiple servers for a single client, wasting resources on the servers. As such, it is specified as part of the protocol that a server may respond to the received DHCPREQUEST only if it has a lease record for the client; otherwise, it must not reply [1, section 4.3.2].

Message formats

Messages in DHCP are of variable length, depending on the number of optional fields included. The byte-layout and description of the fields is in table 1, from [1, section 2]. 
 

Table 1: DHCP message byte layout (lengths of fields given in bytes)

field	length	description
op	1	message type: 1 = boot request (from client), 2 = boot reply (from server)
htype	1	hardware address type: value specifies type of hardware in use, according to specifications in RFC 1700, Assigned Numbers
hlen	1	hardware address length (in bytes)
hops	1	used by relay agents (discussed below); client sets to 0
xid	4	transaction id, randomly chosen by client; this is an identifier, not a sequence number, used so the client will know that a broadcast response from a DHCP server is for it, and not for another client
secs	2	seconds since client began configuration request; used by relay agents in deciding whether to forward request to another network (discussed below in “Relaying messages and addressing”)
flags	2	only the first bit is used; called the broadcast bit (discussed below in “Relaying messages and addressing”)
ciaddr	4	client IP address; filled in by client only when its network address is known to be valid
yiaddr	4	IP address assigned by server to client (“y” for “your” address)
siaddr	4	DHCP server IP address to use for next part of configuration sequence note: current server’s address supplied in “server identifier” option!
giaddr	4	BOOTP relay agent IP address (see section “Relaying messages and addressing”); used by server to relay responses back to client when server is not on client’s subnet, using BOOTP protocol relay servers; if giaddr = 0, client and server are on same subnet, so relay not needed
chaddr	16	client hardware address
sname	64	server name (optional); null-terminated string
file	128	boot file name (optional); fully qualified path name on host with IP address siaddr; used in Boot Protocol [4], to specify boot file for client
options	variable

Options:
The options field is of variable size, and contains various required and optional parameters stored as tag,value pairs called “options”. The format of each option is shown in Table 2. (Two options, “pad” and “end”, don’t have this format: they each consist of a single-byte tag, without any length or value sub-fields.). Here, the tag byte is one of the values specified in RFC 2132 [4], and serves to identify the option. The length byte gives the length (in bytes) of the value data following. One required option for all DHCP messages is the “DHCP message type” option, which specifies the type of the DHCP message. The last option must be the “end” option. Other options may provide such information as the subnet mask a client should use on its network, the IP addresses of routers and domain name servers, and similar information needed for a client to properly configure its network protocol stack. RFC 2132 [4] describes many additional options.

Table 2: Format of DHCP options

field	length	description
tag	1	identifies the option type
length	1	length of the option data
data	variable	data for the option

  
 

Relaying messages and addressing

 As mentioned in the introduction, one interesting feature of DHCP is in its message exchange and addressing mechanism before a client has been configured with a valid IP address, or knows the address of a DHCP server on its subnet. This is handled by clients and servers broadcasting their messages until each knows an address for the other. When a client is first looking for a server, it addresses its DHCPDISCOVER message to the IP broadcast address 0xffffffff (with the source address field set to 0, since it does not at this stage have a valid IP address) so that any available servers will respond. In addition, it sets the “broadcast” bit in the flags field according to how it would like the server to address its responses. If the broadcast bit is 0, this indicates that the server can address the response by constructing a data link frame directly using the client’s hardware address (supplied in the client’s message), and that the IP layer in the client’s TCP/IP stack will accept the message even though it hasn’t yet been configured with an IP address. Some TCP/IP implementations, however, may not pass through messages when the IP address of the client has not been specified, since in general the IP layer will only accept and forward messages to the Transport layer if they have the correct IP address. In this case, the client sets the broadcast bit to 1, indicating to the server that it should send its responses to the IP broadcast address 0xffffffff. With this approach, the server’s response will be broadcast to all of the hosts on the client’s subnet (the IP broadcast address will be resolved to the data link broadcast address), and the IP layer on each host will forward the broadcast message to the upper layers. However, it then becomes necessary for a DHCP client to be able to tell if such a broadcast message is intended for it or some other client. This is handled by the client including a randomly generated value in the xid (“transaction id”) field of its DHCPDISCOVER message, used to identify received responses. The server will copy this value into its reply, and the client will only accept responses which have the correct value. Since the xid value is randomly generated by the client as its identifier, there is a small probability that two clients on the subnet will choose the same value for xid, leading them to misinterpret server responses intended for the other client as being intended for them. (It seems odd that this field is used rather than the chaddr (“client hardware address”) field, since these addresses are guaranteed to be unique and are also passed back and forth by client and server.) 
 By the above mechanism, the server messages can always be forwarded to the client when the client and server are on the same subnet. However, this would require a DHCP server on each subnet. To permit a single DHCP server to service a number of subnets, the protocol allows the use of BootP relay agents, one per subnet, whose only function is to relay DHCP messages between the server and client. Since they do no allocation of addresses or other parameters, their configuration is quite simple, and the function can easily be provided by any selected host on the subnet. When such a relay agent receives a client’s DHCP broadcast message, it repackages it and forwards it to the network address of its designated DHCP server, including in the giaddr field its own IP address. With the giaddr field non-zero, the server knows the message has been forwarded by a relay agent, and addresses its responses to this agent, which then forwards the message to the client on the its local subnet, using the addressing techniques discussed in the previous paragraph. In addition, the server will often (though is not required to) assign an address to the client based on the relay agent’s address, since this can indicate which subnet the client belongs to since the client and relay agent are usually on the same subnet [1, section 4.3.1]. 
 Certain of the fields in a client’s message may be used by a relay agent to determine handling. The secs field is set by the client to indicate the number of seconds since it first began trying to acquire its IP address and configuration parameters. The value will thus be non-zero in the case in which it does not get responses to its DHCPDISCOVER and DHCPREQUEST messages. A relay agent might choose not to forward client requests unless the secs field exceeds a certain value [3, section 8]. In this way any local DHCP server on the subnet will be allowed to respond first to handle the request, without it being simultaneously forwarded to remote servers. The hops field was introduced into the BootP protocol [3] so that gateways with even less functionality than the minimal relay agents (i.e., not having even the address of a server configured into them) could still forward requests across to another subnet which might have a server attached. In this case, the hops field is to be incremented by each successive gateway so that client requests can be discarded when they have traveled more than several subnets away [3, section 8]. 
 

Security

 In the RFC [1, section 7], it is noted that DHCP as defined is potentially very insecure, allowing for spoofing of server functions and denial-of-service attacks by rogue clients (e.g., repeatedly requesting IP addresses until all have been allocated). While it is perhaps possible to configure servers to only accept requests from hosts with specific hardware addresses, or to only take requests from the local subnet (ignoring messages forwarded by relay agents or over gateways), it is acknowledged that security has not been addressed in any detail. 
 

Further client  and server implementation details

 The document [1] discusses additional details for effective implementation of DHCP. Among other matters considered are specific timing issues, such as how long a client should wait for responses before it rebroadcasts its requests [1, section 4.1], and a detailed state-transition diagram [1, Figure 5] indicating the precise sequence a client should use to obtain information under various conditions. Additional server implementation issues include restriction of services to externally identified clients and unique identification of clients and their leases (section 4.2). 
 

Critique

 The Dynamic Host Configuration Protocol has been widely implemented and tremendously successful at providing IP address assignment and other network configuration information automatically, greatly simplifying a network administrator’s job. It is very effective, and quite efficient in its message design and robust in its message-exchange sequences. However, there are a few minor areas in which it is perhaps less than optimal in its design. Some of these are discussed below.

To begin with, there are two fields used for the client’s network address, ciaddr and yiaddr, with slightly different functions. However, there should be no cases in which both yiaddr and ciaddr are needed (and would have different values); as such, they could be replaced by a single field. From [1, section 4.4.1, Table 5], the client always sets yiaddr to 0 in its messages to the server. From [1, section 4.3.1, Table 3], the server sets ciaddr to 0 in its responses, except in the single case of a DHCPACK message responding to a DHCPREQUEST message in which ciaddr has been supplied by the client. The client supplies a value for ciaddr only if it already has a valid network address that the server may thus send its responses to – for example, in the case of a client renewing its lease on its IP address (before the lease has expired). However, there is really no need for the server to include the value of ciaddr in its DHCPACK response; the value is only needed for addressing the IP packet to the client, and will thus be placed in the “destination address” field of the IP header. The client needn’t bother to inspect the ciaddr field on receiving the message to know that this message is intended for it (and not a broadcast message intended for another client) – it already has both its randomly-generated xid value and its hardware address value in chaddr to tell it this (both of these are filled in by the server in its responses with the values that the client supplied). Thus the two network address fields ciaddr and yiaddr are never both needed in any DHCP message, and could be replaced by a single field whose interpretation would depend on whether the client or server were receiving the message.

In addition, DHCP messages have designated fields for a server name and a file name, both of which are optional and come before the options fields. Since these will often be empty, the protocol specifies that they may be used to hold options from the options field, with some somewhat complex rules for how the options data should be incorporated within them – for example, no option (consisting of a tag, length and value) may cross the border of either field if it is included within it, and “pad” options are used to fill out the fields if needed. It would make much more sense for these to have originally been included just as two additional options among the others, appearing within the options field only if they were needed. This would have reduced the complexity of the processing, and could potentially shorten messages since the bits comprising these two (currently required) fields would not need to be included if the options list were small. (In fact, one of the options currently allocated (with tag 67) is for a bootfile name [4, section 9.5], for the situation in which the filename field is being used to hold other options!)

In a related issue, it is unusual that the DHCP message type is not within a designated field, but is instead included as a required option in the options field. It would seem logical that the message type would be given a designated field of its own; the current 8 types of DHCP messages would require only 3 bits, so that allocating a single byte for such a field would leave plenty of room for possible future extensions (and existing BootP message types). The advantage with leaving this as an option is that there is thus no restriction on the number of different message types that can be included in the future. Even designating one full byte to a “message type” field would have limited the number of different message types to 256, which could at some point become too limiting.

Another more significant current limitation is in the number of different options. As discussed above, options are specified as (tag, length, value) triples, where the tag and length components are each one byte. Thus there are only 256 different tags, i.e., there can be only 256 different options. This could prove to be significantly limiting in the future, as many options have already been defined (76, as of 1997 [4]). One way to overcome this limitation would be to designate one of the current tags as denoting an “extended” option, which would signify that the “value” subfield of the (tag, length, value) triple should itself be interpreted as a (tag, length, value) triple, but whose tag now consists of 2 (or more) bytes. This would allow definition of many additional options.

There are other fields that could seemingly be eliminated – for example, the siaddr field, which isn’t used at all for DHCP messages. However, since DHCP was developed as an extension to the BootP Protocol, and is designed to operate concurrently with it [5], some of these fields do in fact play an important role in the latter protocol and are thus justified in being retained in DHCP messages.

The protocol specifies that when a server offers a network address to a client, it is not required to reserve that address for any period of time until it receives and accepts a DHCPREQUEST for the address from the client. As such, the server would be permitted to re-offer the same address to a different client immediately after offering it to the first client, allocating it to the first client which responds and sending a DHCPNAK to the loser (who might have to start the configuration process over). While this permits maximum flexibility on the part of servers, especially in the case in which a server has a relatively small pool of available addresses, it could obviously lead to inefficiencies. As such, the protocol suggests (but does not require [1, section 4.3.1]) that servers actually be implemented in such a way as to avoid re-offering the same address to more than one client in a short period of time.

References

1. RFC 2131, “Dynamic Host Configuration Protocol”, R. Droms, March 1997.
2. RFC 1531, “Dynamic Host Configuration Protocol”, R. Droms, October 1993.
3. RFC 951, “Bootstrap Protocol (BootP)”, W. Croft, J. Gilmore, September 1985.
4. RFC 2132, “DHCP Options and BOOTP Vendor Extensions”, S. Alexander, R. Droms, March 1997.
5. RFC 1534, “Interoperation Between DHCP and BOOTP”, D. Droms, October 1993.

J. Sevy, December 1999