Dynamic Host Configuration Protocol

Here comes the third and last communication networks article. This time, I wrote about DHCPv4:

Dynamic Host Configuration Protocol

The Dynamic Host Configuration Protocol (DHCP) provides means for automatic network configuration of networked stations. It was designed to unify and extend other protocols such as the Bootstrap Protocol (BOOTP), the Reverse Address Resolution Protocol (RARP) and the ICMP “mask” and “information” requests. DHCP uses a client/server model, it’s packets are sent using UDP.

Without DHCP, every machine that is connected to an IP network needs to be manually configured. It needs at least an IP address, a network mask and a gateway (router) address to be able to communicate with other IP stations. In addition to that, DHCP can deliver information about Domain Name System (DNS) servers, the location of a boot image for diskless stations, time servers and much more. The complete list of predefined options was written down in RFC 2132, but it is also possible to extend DHCP with user defined (“vendor”) options.

There are several approaches on how to use the IP address configuration feature of DHCP: one could statically configure the clients with an IP address. DHCP would then be used to get additional information about the network. Another use case is the permanent allocation of an IP address for each client: DHCP would configure the clients with an address that never expires. Most commonly, a third option is used: Every assignment of an IP address has an expiry date set which is also known as lease time. Clients can renew their lease before it expires to avoid changing their IP address. This is called dynamic IP address allocation and has the big advantage that addresses used for machines that no longer exist can be reused for new machines. In a network where only a fraction of the machines are online at a time, there can be even more machines than IP addresses by using dynamic allocation.

There can be multiple DHCP servers in one subnet, for example to increase reliability. However, it is extremely important that they either offer different blocks of IP addresses or synchronize their data to prevent a single IP address being assigned to multiple clients at the same time.

Structure of a DHCP packet

Because DHCP is backwards compatible in a way that allows DHCP servers to serve both DHCP and BOOTP clients, the structure of a packet is somewhat complicated and sometimes redundant. I will not explain every header field as this can be looked up in RFC 2131.

The DHCP packet structure
(original diagram can be found in RFC 2131; numbers in braces show the size, measured in bytes)

Most important parts of a packet

  • Every packet can be attributed to a session by its transaction ID (xid).
  • Client’s IP address (ciaddr) is only used when the client has a manually configured IP address and requests additional information.
  • The address to be assigned to a client is stored in assigned IP address (yiaddr).
  • options contains a variable list of data records. Most of the information passed over DHCP is stored as an option record.

DHCP message types

Client to server


The client sends a DHCPDISCOVER to the local network via broadcast to get information about the DHCP server(s) to choose from. DHCP servers should answer with a DHCPOFFER.


This message is also sent via broadcast and requests from the chosen DHCP server some information as defined in the option records. It is only used if an IP address was manually configured.


DHCPREQUEST is used to aquire an IP address and additional information as defined in the options.


If the client aquired an IP address that is apparently used by another machine (may be checked using ARP or ICMP echo requests), it sends a DHCPDECLINE to inform the server about these circumstances.


A client may choose to return its lease by sending a DHCPRELEASE if it shuts down or is moved to another subnet.

Server to client


As a reply to DHCPDISCOVER, each server sends a DHCPOFFER to the client. If it receives multiple offers, the client may choose which offer it will accept by sending a DHCPREQUEST or DHCPINFORM including the chosen server’s id.


If a DHCPREQUEST or DHCPINFORM message gets accepted by the server, it sends a DHCPACK message containing all the data requested by the client.


This is sent if the client sent an invalid request. This happens for example if the client tries to renew it’s lease which already expired.

Example of a DHCP session

This is an example of a typical DHCP session in a network with two DHCP servers which dynamically assigned IP addresses:

  • The client in need of an IP address and additional configuration data broadcasts a DHCPDISCOVER.
  • Both servers reply with a DHCPOFFER, optionally containing information about the concrete data to expect from the particular server.
  • The client chooses one of the replys, for example by length of the lease time or simply the one that arrived first.
  • It sends a DHCPREQUEST to the chosen server, including a list of information needed and (optionally) its preferred IP address.
  • The server returns a DHCPACK with the authoritative list of information records. In addition, it marks the IP address assigned to the client in its internal database as used.
  • The client now configures itself with the information it received.


DHCP is a flexible protocol that makes it easier for both users and network administrators to use and maintain networked devices. Due to its flexibility, it is not possible to discuss all the possibilities in a relatively short article. For more information I strongly recommend to have a look at the RFCs referenced below. Especially the possibility of having one DHCP server serving multiple subnets using relay agents might be interesting.


Join the Conversation

1 Comment

Leave a comment

Your email address will not be published.

This site uses Akismet to reduce spam. Learn how your comment data is processed.