Dynamic Host Control Protocol

Dynamic Host Control Protocol (DHCP) is used to provide devices in a network with the configuration parameters. Typically devices need configuration to operate, such as IP address, DNS server address, NTP server details, etc. DHCP allows the devices to talk to a central server, called as DHCP server, and retrieve the configuration from the server. These devices are known as DHCP clients.

Retrieving configuration from a centralized server has the advantage of having to make changes in only one location. Each device does not have to be manually configured. This becomes important when there are large number of devices in a network or devices may connect to the network temporarily. However, having a central server for configuration also introduces a single node of failure. Though there can be multiple servers configured, so that if one server goes down other one can pick up the slack.

A DHCP client can request for the configuration when it boots up or can request for the configuration when it needs to connect to the network. The way DHCP protocol has been defined, the client does not need to know the details of the server. A DHCP client will broadcast a request on its subnet when it needs information, and one or more DHCP servers present in the network will respond back.

Usually, the DHCP server is also built such a way that it also retains information across reboots, so if goes down and is restored back up the DHCP client information is not required to be configured again.

DHCP protocol is based on UDP protocol with port 67 as the DHCP server port and port 68 as the DHCP client port.

IP address allocation

Though various parameters can be configured in DHCP, but the most important parameter that is configured by DHCP is IP address. DHCP supports three mechanisms for IP address allocation - dynamic, automatic, and static allocation.

• In dynamic allocation, DHCP server is free to assign an permanent IP address to a client. The DHCP server would generally be created with a pool of IP addresses that it can choose from, and it assigns the IP address from this pool to the clients. When the client requests for an IP address, DHCP server looks for a free IP address and assigns it to the client.
• In automatic allocation, DHCP server assigns an IP address to a client for a limited period of time (or until the client explicitly relinquishes the address). The DHCP server also remembers the previous assignments to a particular client, so that when the client requests for an IP address again, it can be given the same IP address.
• In static/sticky/manual allocation, a client's IP address is assigned by the network administrator in the DHCP server, and DHCP is used simply to convey the assigned address to the client.

DHCP message structure

A DHCP message has the following format.

   0                   1                   2                   3

   0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   |     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)                   |

   +---------------------------------------------------------------+

DHCP Options

The DHCP message contains several fields for specifying the configuration. However, in order to avoid modifying the core DHCP message everytime a new configuration parameter is required, a variable length field "options" was added to the end of DHCP message. In the options field various the parameters may be specified. Each option has a code, and this code appears in the options field followed by its value. More than one option can be specified in the options field. If a new configuration parameter needs to be added, then a new (unused) code is assigned to it. Existing options and their formats are defined in RFC2132

One such options that is mandatory in the DHCP message is - "DHCP message type" which enables the client and server to determine the DHCP message type. DHCP defines following message types:

1. DHCPDISCOVER
2. DHCPOFFER
3. DHCPREQUEST
4. DHCPACK
5. DHCPNAK
6. DHCPRELEASE
7. DHCPINFORM
8. DHCPDECLINE

Another option that is mandatory to be sent by servers is server identifier, which is an identifier that uniquely identifes the server.

Message Flow for allocating a network address

1. Client broadcasts a DHCPDISCOVER message on its local subnet. DHCPDISCOVER may include options that suggest values for network address and lease duration.
2. Each server may respond with a DHCP offer message that includes an available network address. The IP address is specified in the yiaddr (your ip address) field. If the address is being dynamically allocated, then the server should make sure that this address is not being used by any other client.
3. Client gets the configuration from servers (may be more than one.) It chooses one configuration and sends DHCPREQUEST to all the servers again. This is also a broadcast request. The client fills the server identifier option of the message, so that the server(s) know whose configuration has been selected.
4. DHCP servers receive the DHCPREQUEST. If the server finds that the client selected the configuration of some other server, then they keep the configuration that they sent as available (and can use the configuration for some other client.) If the DHCP server finds that its configuration has been accepted then the server reserves the configuration for this specific client and sends DHCPACK message to the client.
5. The DHCP server whose name was specified in the "server idetifier" option field of DHCPREQUEST message sends DHCPACK message. This message contains all the configuration (along with the IP address in yiaddr field.) The client verifies the configuration and accepts it. It also takes the Lease period from this message which specifies for long this configuration is valid.

DHCP configuration declined by client

When the client receives a DHCPACK message with the configuration parameters, it verifies the parameters. It is possible that the IP address assigned to it is already being used by some other client (which can be determined by sending a arp request.) In this case the client which received this invalid configuration will send DHCPDECLINE message to DHCP server and restart the configuration process starting from DHCPDISCOVER.

Client releasing the configuration

The client may choose to relinquish its configuration parameters. This is possible in scenario when a client is shutting down, or getting disconnected from the network and it wants to tell the server that it can assign its configuration/ip address to some other client. In this case the client will send DHCPRELEASE message to the server. Once, a client has released a configuration/IP-address it needs to reacquire the configuration parameters it needs to use them.

Reusing a previous configuration

It is possible that a client remembers a previous configuration and may request the DHCP server to provide the same configuration again. In this scenario it may skip some of the configuration messages:

1. Client broadcasts the DHCPREQUEST message containing the old configuration parameters. The message includes the old IP address assigned to the client in the "requested IP address" option and the old requested configuration in "parameter request list" option.
2. The servers receive the DHCPREQUEST. If the server finds that the requested configuration is invalid and the client belonged to it, then the server sends DHCPNAK message. However, if the server finds that the configuration is invalid but the client belonged to some other server, then it does not send any message.
3. The server to which the client belonged, sends the DHCPACK message to the client containing the configuration as well.
4. When the client receives the DHCPACK message from its intended server, then it will verify the configuration and use the configuration. If the client does not receive either DHCPACK or DHCPNAK message then the client will retransmit the DHCPREQUEST (at most four times) and if even then it has not received a response (probably because no servers is sure that whether the client belonged to them or not), then it will start the configuration retrieval process from beginning by sending the DHCPDISCOVER request.

Identification of client

A typical network may have hunderds of devices being managed by the same DHCP server. When a client sends a message, it needs to send an unique identifier so that the server can know which client is sending the request. The first thing that comes to mind is that the hardware identifier (such as mac address) can be used to identify the client. If the DHCP client chooses to identify itself with the hardware address, then it needs to fill this value in "chadd" (client hardware address) of the DHCP message. On the server side the configuration would be provided for this hardware address.

Instead of hardware address, client can also use a string identifier (such as hostname, or manufacturer serial number, or the home address of the customer.) This string identifier needs to be sent in the "client identifier" option. On the server side the configuration would be done corresponding to this identifier itself.

Whatever the DHCP client chooses to identify itself with, it should make sure that it uses the same value to identify itself for the duration it has the configuration.

DHCP Bindings

DHCP has a logical concept of bindings. Binding is association of a client with its configuration at the server's end. When in the beginning the cleint has not contacted the server, the client has an inactive binding. Once the client retrieves and accepts the information from the server, the binding becomes active. If the client releases the configuration or does not renew the configuration, then the binding is considered to be expired.

DHCP Lease

When the server provides the configuration to a client, it is provided for a limited period of time. This time period is called the lease of the configuration. After the lease period has expired the DHCP client needs to stop using the configuration and reacquire the configuration. It is however possible for client to renew the lease before its expiry, so that it doesn't have to reacquire the configuration again.

DHCP Lease duration

When the client sends a message, it specifies a DHCP lease duration in its message (DHCPDISCOVER or DHCPREQUEST.) However, this is only a suggested or requested value and server would actually determine the lease period. The server can choose any value for the lease but it should be less than or equal to the suggested/requested value, but not greater than that. The server would send the actual lease duration in the "DHCP lease" field in DHCPACK message. The DHCP lease is specified in seconds.

DHCP Lease Renewal

DHCP client can try to renew its lease before its expiry as well. DHCP client can send DHCPREQUEST message to the DHCP server for renewing and extending its lease. In the DHCPREQUEST message, the client will fill the suggested value for the DHCP lease. The server will then send the the actual lease duration on the DHCPACK message (making sure that the provided lease time is either equal or less than the suggested lease duration.) This new lease duration is the new lease period starting from the time this DHCPACK was received.

The DHCP client can send the DHCPREQUEST for lease renewal at two times - T1 (renewal Timer) and T2 (Rebinding timer). T1 and T2 are time intervals after the lease starting time, when a client can try for lease renewal. The client tries at time T1 for lease renewal and if it is unsuccessful only then it tries again at time T2. T1 and T2 can be configured by DHCP server via DHCP options, and if the server does not configure these then client should assume the default values of (0.5 * lease duration) for T1 and (0.875 * lease duration) for T2. This means that if DHCP client received a DHCP lease of 100 seconds, then it should try for lease renewal at 50 seconds (0.5 * 100) first. If the client is not successful in renewing the lease, then it should try again at 87.5 seconds.

However, if the DHCP client gets a DHCPACK response from DHCP server at 50 seconds, with a lease duration of 100 seconds, then the timers need to be reset since the new lease has started. Now, the client should send the next lease renal message at 50 seconds from the point it received the DHCPACK message.

Retrieving configuration while already having an IP Address

It is possible that the client has the IP address already (because of manual provisioning or other means) and just wants to get the other configuration parameters from the server. In this case it can send a DHCPINFORM message to the server. DHCP server in this case would send a DHCPACK message with the configuration parameters. In this scenario, the client doesn't need to have an active/exsiting binding with the server.