DHCP – Dynamic Host Control Protocol

I expose in this blog post my DHCP study notes. We aboard the allocation types and the packet format. Then we see a real wireshark trace.

In the following sections I refer to DHCP clients and DHCP servers as simply “client” and “server”.

DHCP allocation types

There are three types of DHCP allocations:

  • dynamic allocation: the basic one. A client is assigned an IP address from the DHCP pool and the address can be revoked or changed
  • automatic allocation: A client is assigned an IP address from the DHCP pool and the address is never revoked
  • manual allocation: A client is assigned the same IP address. And this IP address is not part of the DHCP pool

DHCP message format

DHCP messages are extensions of BOOTP messages. They basically have the same format except that DHCP adds some fields.

The format of a DHCP message is as follows:

dhcp message format
Message format © support.huawei.com
  • Op: stands for Operations. Identifies whether the message is a request (1) or a reply (2)
  • Htype: the type of link layer address that is observed in ARP. In Ethernet networks, HTYPE=1
  • Hlen: the length -in bytes- of the hardware address. In Ethernet networks, HLEN = 6
  • Hops: the number of DHCP relay agents this packet has traversed.
  • Transaction Identifier, aka xid: identifies a client-server request/response communication
  • Secs: the time since which the client has tried to get (or renew) an IP address
  • Flags: only the first bit is defined in the protocol, which is called the broadcast flag. If set to 1, then the requesting client only supports broadcast answers and not unicast.
  • ciaddr: Client IP Address
  • yiaddr: Your IP Address. The IP address as suggested by a DHCP server
  • siaddr: Next Server IP Address; the IP address of a DHCP server that the client will remember to contact in his next boot
  • giaddr: Gateway IP Address; this field is not filled by the DHCP server. Instead, it is filled by a DHCP/BOOTP relay agent when the packet traverses it
  • chaddr: Client Hardware Address
  • sname: Server Host Name
  • file: BOOTP file name path
  • Options: this field is variable in length in DHCP. However in BOOTP, it was fixed. The Options field is used extensively in DHCP and provides useful information such as the subnet mask, the IP address lease time, the DNS server IP address

Here are some of the options:

  • DHCP message type: popular values are request, discover, offer, ack
  • Client Identifier: this option contains the hardware address of the client. It identifies a DHCP client. In the past network engineers used to identify a DHCP client by the chaddr field. Nowadays, there is a trend of no longer identifying a DHCP client by its hardware address filed; instead, we identify it by the Client Identifier option.
    • The Client Identifier is automatically generated and is MAC-address based.
  • DHCP server Identifier, like Client Identifier, the Server Identifier option identifies a DHCP server for a particular DHCP client.

A complete list of DHCP options can be found here.

Magic cookie

The first 4 Bytes of the Options field are set to the decimal value 63 82 53 63, which is called the magic cookie. The magic cookie is found on all DHCP messages, whether they are requests or replies.

How the protocol works

A client that joins a network needs to get an IP address. It sends a DHCPDISCOVER message and waits for one or more answers from any available DHCP server. The servers can be attached to the same or different broadcast domain. They send their replies in DHCPOFFER messages. If the client receives more than one reply, it has the freedom to choose whatever IP address from whatever DHCP server it likes.

Once the client “likes” an offer, it sends a DHCPREQUEST. The elected server replies with DHCPACK. If the IP address requested could not be given, the server replies with a DHCPNACK instead.

message exchange © h3c.com

At this stage, there is an optional verification step, where the client checks whether the IP address exists somewhere on the broadcast domain. This is part of RFC 5227 Address Conflict Detection ACD and is done by means of ARP requests and replies. if the client receives an ARP reply for the IP address (or even a Gratuitous ARP reply), it means that it is already taken by another host. So it sends a DHCPDECLINE to the DHCP server and retries to get another IP address after a period of 10 seconds (recommended value).

Note that, if the client has already an IP address and simply wishes to renew it, it does not go through the DHCPDISCOVER and DHCPOFFER phases. It directly go to the DHCPREQUEST stage.

DHCP Relay agent

packet flow with a Relay agent © h3c.com

Lease time, Renewal time and Rebinding time

The lease time (T) is the time during which a client benefits from the assigned IP address, without requesting a renewal. The renewal time (T1) is the time at which the client must renew its IP address lease from the server that gave it the lease. The rebinding time (T2) is the time at which the client must renew its IP address lease from any server available.

By default, the following formulas hold true:

T1 = T/2

T2 = 7*T/8

DHCP Finite State Machine

Figure: Finite State Machine © TCP/IP Illustrated: The Protocols.

The Finite State Machine (FSM) on the right describes the states of a client. The states and arrows in bold describe the standard operation of our protocol. Ideally, the client goes through the following states:

  • Init: no IP address obtained yet,
  • Selecting: the client is collecting offers
  • Requesting: the client made its choice and waits for an answer
  • Bound: the client receives a confirmation that it can get the requested IP address

I’ll highlight some particular transitions in the FSM:

  • the client can go from the Requesting state back to the Init state if it declines the DHCP offer, with a DHCPDECLINE, or if the server sent a DHCPNACK.
  • At half the lease time (T/2), the client enters the Renewing state. If nothing happens and the rebinding time expires (T2), the client requests any server for DHCP information.

Wireshark example

Options are encoded usually in this order:

  1. Option type (1 Byte)
  2. Option length (1 Byte)
  3. Option value (variable length)

For example, the packet below contains many Options among which we have Option 51, the IP Lease Time. The lease time is encoded as follow:

  • 0x33 –> option type: 51 in decimal
  • 0x04 –> option length is 4 Bytes
  • 0x00000e10 –> option value: 3600 seconds, in decimal.
the options field
Figure: Lease time (T) in a DHCPOFFER message

Here is another example for Option 58:

option 58
Figure: option 58, the Renewal time (T1), in a DHCPOFFER packet

We saw earlier that Rebinding time = T2 = 7*T/8.

T = 3600 seconds in the previous packet, so T2 = 7*3600/8 = 3150 seconds:

Figure: option 59, the Rebinding time in a DHCPOFFER message

Here is the magic cookie:

magic cookie
Figure: magic cookie in the DHCP message. Notice the hex value.

How can a server determine what a client wants? It’s the Option 55: Parameter Request List,  the DHCPDISCOVER message


Option 55
figure: Option 55: Parameter Request List, in the DHCPDISCOVER message


In this video, Tony Fortunato exposes a real-life example of a DHCP client not getting an IP address. After the server sent a DHCPACK, the client sent a DHCPDECLINE:


Message types

  • DHCPFORCERENEW: sent by the server to force the client to get back to the Renew state. The client requests the same IP address in a DHCPREQUEST. The server can either respond with DHCPACK or DHCPNACK. DHCPFORCERENEW is often used when there is a major network addressing change.
Message type sent by Unicast or broadcast
DHCPDISCOVER client broadcast
DHCPOFFER server broadcast or unicast – depending on the Broadcast flag
DHCPREQUEST client broadcast (if first time) – unicast (if in the Renewal state)
DHCPACK server broadcast (although I have seen a Wireshark capture where DHCPACK is unicast)
DHCPNACK server broadcast
DHCPFORCERENEW server unicast


TCP/IP Illustrated, Volume 1: The Protocols (2nd Edition)

RFC IPv4 Address Conflict Detection

Investigation of DHCP Packets Using Wireshark

Be First to Comment

Leave a Reply

Your email address will not be published. Required fields are marked *