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.
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.
Initial configuration: client requires IP address and other parameters
Lease renewal: client has valid IP address from DHCP server,
but lease about to expire
Rebooting, but with valid lease still existing on current
IP address ([1, section 4.4.2])
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.
field | length | description |
tag | 1 | identifies the option type |
length | 1 | length of the option data |
data | variable | data for the option |
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.
J. Sevy, December 1999