A Brief Overview of DHCP

The Dynamic Host Configuration Protocol (DHCP) is very useful in network administration. DHCP (defined in RFCs 2131 and 2132) is an enhancement of the Bootstrap Protocol (BOOTP). There are two main enhancements with DHCP, it allows a client to obtain an IP address dynamically for a finite period of time, and retrieve other useful IP information, such as DNS, HTTP, or SMTP server addresses. A DHCP server should allow requests from BOOTP clients and be able to respond to them properly. These protocols are especially useful in the configuration of diskless workstations, but can be used to more effectively manage IP address assignment on any network. DHCP uses UDP to perform transactions. Both protocols are used to replace RARP at the Application Layer.

According to RFC2131, DHCP must:

  • Guarantee that any specific network address will not be in use by more that one DHCP client at a time,
  • Retain DHCP client configuration across DHCP client reboot. A DHCP client should, whenever possible, be assigned the same configuration parameters despite restarts of the DHCP mechanism,
  • Allow automated assignment of configuration parameters to new clients to avoid hand configuration for new clients,
  • Support fixed or permanent allocation of configuration parameters to specific clients.

DHCP clients and servers communicate by filling in fields in a specified format. Figure 1 (from RFC2131) shows how the DHCP message is constructed. Numbers in parenthesis indicate the number of octets used by the field. Table 1 (also from RFC2131) explains what the contents of each field are.

op (1) htype (1) hlen (1) hops (1)
xid (4)
secs (2) flags (2)
ciaddr (4)
yiaddr (4)
siaddr (4)
giaddr (4)

chaddr (16)


sname (64)


file (128)


options (variable)

Figure 1: Format of a DHCP message



FIELD LENGTH DESCRIPTION
op 1 Message op code / message type.1 = BOOTREQUEST, 2 = BOOTREPLY
htype 1 Hardware address type, see ARP section in "Assigned Numbers" RFC; e.g., '1' = 10mb ethernet.
hlen 1 Hardware address length (e.g. '6' for 10mb ethernet).
hops 1 Client sets to zero, optionally used by relay agents when booting via a relay agent.
xid 4 Transaction ID, a random number chosen by the client, used by the client and server to associate messages and responses between a client and a server.
secs 2 Filled in by client, seconds elapsed since client began address acquisition or renewal process.
flags 2 Flags (see figure 2).
ciaddr 4 Client IP address; only filled in if client is in BOUND, RENEW or REBINDING state and can respond to ARP requests.
yiaddr 4 'your' (client) IP address.
siaddr 4 IP address of next server to use in bootstrap; returned in DHCPOFFER, DHCPACK by server.
giaddr 4 Relay agent IP address, used in booting via a relay agent.
chaddr 16 Client hardware address.
sname 64 Optional server host name, null terminated string.
file 128 Boot file name, null terminated string; "generic" name or null in DHCPDISCOVER, fully qualified directory-path name in DHCPOFFER.
options var Optional parameters field. See the options documents for a list of defined options.

Table 1: Description of fields in a DHCP message



There is currently only one flag assigned in the 'flags' field. This is the broadcast flag. Some clients cannot accept unicast datagrams before their TCP/IP software is fully configured. To work around this, the client sets the broadcast flag (the leftmost bit in the flags field) which tells the server that it must broadcast its response so the client can retrieve it.

As mentioned before, one of the main purposes of DHCP is to provide the allocation of temporary or permanent IP addresses to clients. The mechanism for this works in the folloing manner: the client requests the use of an address for a specified period of time. The DHCP server guarantees not to reallocate the that address for that time period (called the lease period) and attempts to return the same network address evey time the client requests an address. The client may extend its release with subsequent requests, and may send a message to the server telling it that it no longer needs that address. A client may request a permanent assignement by asking for an "infinite" lease. The server may offer a long, but not infinte, lease to allow for detection of a retired client. The server keeps track of addresses in a database which maps hardware addresses of clients to their assigned IP addresses.

The other main purpose of DHCP is to provide a client with all paramters neccessary for proper functioning of TCP/IP. In the client's request message, it may include a list of requested information in the 'options' field. For instance, if the client needs to know the address of the local DNS server, it may request it by specifying that option in the 'options' field. RFC2132 explains in detail all current available options.

The request from DHCP client to a server involves a "four-way handshake." First, the client boradcasts a "DHCPDISCOVER" message to the local subnet asking for configuration information. In this message, the client fills in the 'xid' field with a unique identifier (usually a randomly generated number). It also fills in the 'chaddr' filed with its hardware, or MAC, address. It may request additional information as described above. The client then collects one or more "DHCPOFFER" messages from one or more DHCP servers with matching values in the 'xid' field. The client chooses one to accept based upon the offered configuration parameters. The client then sends a "DHCPREQUEST" message specifying its selected server. Servers not selected use this message as notification that the client has declined their offer. The selected server then responds with a "DHCPACK" message if the requested parameters are acceptable, or a "DHCPNAC" message if they are not. The timeline for this four-way handshake is outlined below in Figure 2 (from RFC2131).

Figure 2: Timeline diagram for DHCP client-server message exchange



In case of lost messages, the client is responsible for timing out and retransmitting request messages. DHCP also allows for the client to request a specific IP address if it retains knowledge of a previous assignment. In this case, the client broadcasts a "DHCPREQUEST" message specifying an IP address with the 'requested IP address' option. Figure 3 shows the modified timeline diagram for this transaction.

Figure 3: Timeline diagram for DHCP client-server message exchange when using previously allocated IP address



The state machine (Figure 4) for a DHCP client is very complex. It is explained in detail in RFC2131. I have included the diagram itself here. It is essentially a longhand outline of Figure 2.

 --------                               -------
|        | +-------------------------->|       |<-------------------+
| INIT-  | |     +-------------------->| INIT  |                    |
| REBOOT |DHCPNAK/         +---------->|       |<---+               |
|        |Restart|         |            -------     |               |
 --------  |  DHCPNAK/     |               |                        |
    |      Discard offer   |      -/Send DHCPDISCOVER               |
-/Send DHCPREQUEST         |               |                        |
    |      |     |      DHCPACK            v        |               |
 -----------     |   (not accept.)/   -----------   |               |
|           |    |  Send DHCPDECLINE |           |                  |
| REBOOTING |    |         |         | SELECTING |<----+            |
|           |    |        /          |           |     |DHCPOFFER/  |
 -----------     |       /            -----------   |  |Collect     |
    |            |      /                  |   |       |  replies   |
DHCPACK/         |     /  +----------------+   +-------+            |
Record lease, set|    |   v   Select offer/                         |
timers T1, T2   ------------  send DHCPREQUEST      |               |
    |   +----->|            |             DHCPNAK, Lease expired/   |
    |   |      | REQUESTING |                  Halt network         |
    DHCPOFFER/ |            |                       |               |
    Discard     ------------                        |               |
    |   |        |        |                   -----------           |
    |   +--------+     DHCPACK/              |           |          |
    |              Record lease, set    -----| REBINDING |          |
    |                timers T1, T2     /     |           |          |
    |                     |        DHCPACK/   -----------           |
    |                     v     Record lease, set   ^               |
    +----------------> -------      /timers T1,T2   |               |
               +----->|       |<---+                |               |
               |      | BOUND |<---+                |               |
  DHCPOFFER, DHCPACK, |       |    |            T2 expires/   DHCPNAK/
   DHCPNAK/Discard     -------     |             Broadcast  Halt network
               |       | |         |            DHCPREQUEST         |
               +-------+ |        DHCPACK/          |               |
                    T1 expires/   Record lease, set |               |
                 Send DHCPREQUEST timers T1, T2     |               |
                 to leasing server |                |               |
                         |   ----------             |               |
                         |  |          |------------+               |
                         +->| RENEWING |                            |
                            |          |----------------------------+
                             ----------

Figure 3: State-transition diagram for DHCP clients



In this fashion, DHCP can be used to correctly configure any workstation on the local subnet. This protocol is very useful in network management. It can relieve the burden of maintaining databases of assigned IP addresses by network administrators. It also makes it easy to change given parameters across the network. If the DNS server address changes, the DHCP server takes care of distributing that information. Each workstation does not need to be manually configured. This helps in keeping the network running smoothly, and gives the network administrator one less thing to worry about.