Dynamic Host Configuration Protocol

In the early days of networking, when a device wanted to communicate over a network, it needed to be assigned an address by hand. As networks grew, this manual process quickly became cumbersome. To solve this problem, Bootstrap Protocol (BOOTP) was created to automatically assign addresses to network-connected devices. BOOTP was later  replaced with the more sophisticated Dynamic Host Configuration Protocol (DHCP).

DHCP is an application layer protocol responsible for allowing a device to automatically obtain an IP address (and addresses of other important network assets, such as DNS servers and routers). Most DHCP servers today also provide other parameters to clients, such as the addresses of the default gateway and DNS servers in use on the network.

The DHCP Packet Structure

DHCP packets can carry quite a lot of information to a client. As shown in Figure 7-1, the following fields are present within a DHCP packet:

OpCode Indicates whether the packet is a DHCP request or a DHCP reply
Hardware Type The type of hardware address (10MB Ethernet, IEEE 802, ATM, and so on)
Hardware Length The length of the hardware address
Hops Used by relay agents to assist in finding a DHCP server
Transaction ID A random number used to pair requests with responses
Seconds Elapsed Seconds since the client first requested an address from the DHCP server
Flags The types of traffic the DHCP client can accept (unicast, broadcast, and so on)
Client IP Address The client’s IP address (derived from the Your IP Address field)
Your IP Address The IP address offered by the DHCP server (ultimately becomes the Client IP Address field value)
Server IP Address The DHCP server’s IP address
Gateway IP Address The IP address of the network’s default gateway
Client Hardware Address The client’s MAC address
Server Host Name The server’s host name (optional)
Boot File A boot file for use by DHCP (optional)
Options Used to expand the structure of the DHCP packet to give it more features

Figure 7-1: The DHCP packet structure

The DHCP Renewal Process

The primary goal of DHCP is to assign addresses to clients during the renewal process. The renewal process takes place between a single client and a DHCP server, as shown in the file dhcp_nolease_renewal.pcap. The DHCP renewal
process is often referred to as the DORA process because it uses four types of DHCP packets: discover, offer, request, and acknowledgment, as shown in Figure 7-2. Here, we’ll take a look at each type of DORA packet.

Figure 7-2: The DHCP DORA process

The Discover Packet

As you can see in the referenced capture file, the first packet is sent from 0.0.0.0 on port 68 to 255.255.255.255 on port 67. The client uses 0.0.0.0 because it does not yet have an IP address. The packet is sent to 255.255.255.255 because this is the network-independent broadcast address, thus ensuring that this packet will be sent out to every device on the network. Because the device doesn’t know the address of a DHCP server, this first packet is sent in an attempt to find a DHCP server that will listen.

Examining the Packet Details pane, the first thing we notice is that DHCP relies on UDP as its transport layer protocol. DHCP is very concerned with the speed at which a client receives the information it’s requesting. DHCP has its own built-in reliability measures, which means UDP is a perfect fit. You can see the details of the discovery process by examining the first packet’s DHCP portion in the Packet Details pane, as shown Figure 7-3.

TIPS Because Wireshark still references BOOTP when dealing with DHCP, you’ll see a Bootstrap Protocol section in the Packets Detail pane, rather than a DHCP section. Nevertheless, I’ll refer to this as the packet’s DHCP portion throughout this book.

Figure 7-3: The DHCP discover packet

This packet is a request, identified by the (1) in the Message Type field . Most of the fields in this discovery packet are either blank (as you can see in the IP Address fields ) or pretty self-explanatory, based on the listing of DHCP fields in the previous section. The meat of this packet is in its four option fields:

DHCP Message Type This is option type 53 (t=53), with length 1 and a value of 1 . These values indicate that this is a DHCP discover packet.

Client Identifier This provides additional information about the client requesting an IP address.
Requested IP Address This supplies the IP address the client would like to receive (typically its previously used IP address).
Parameter Request List This lists the different configuration items (IP addresses of other important network devices) the client would like to receive from the DHCP server.

The Offer Packet

The second packet in this file lists valid IP addresses in its IP header, showing a packet traveling from 192.168.0.1 to 192.168.0.10, as shown in Figure 7-4. The client does not actually have the 192.168.0.10 address yet, so the server
will first attempt to communicate with the client using its hardware address, as provided by ARP. If communication is not possible, it will simply broadcast the offer to communicate.

Figure 7-4: The DHCP offer packet

The DHCP portion of this second packet, called the offer packet, indicates that the message type is a reply . This packet contains the same transaction ID as the previous packet , which tells us that this reply is indeed to respond to
our original request.

The offer packet is sent by the DHCP server in order to offer its services to the client. It does so by supplying information about itself and the addressing it wants to provide the client. In Figure 7-4, the IP address 192.168.0.10 in the Your (Client) IP Address field is being offered to the client . The value 192.168.0.1 in the Next Server IP Address field indicates that our DHCP server and default gateway share the same IP address.

The first option listed identifies the packet as a DHCP Offer . The options that follow are supplied by the server and indicate the additional information it can offer, along with the client’s IP address. You can see that it offers the following:

1. A subnet mask of 255.255.255.0
2. A renewal time of 30 minutes
3. A rebinding time value of 52 minutes and 30 seconds
4. An IP address lease time of 1 hour
5. A DHCP server identifier of 192.168.0.1

The Request Packet

Once the client receives an offer from the DHCP server, it should accept it with a DHCP request packet, as shown in Figure 7-5.

Figure 7-5: The DHCP request packet

The third packet in this capture still comes from IP address 0.0.0.0, because we have not yet completed the process of obtaining an IP address . The packet now knows the DHCP server it is communicating with.

The Message Type field shows that this packet is a request . Although every packet in this capture file is part of the same renewal process, it has a new transaction ID, since this is a new request/reply transaction . This packet is similar to the discover packet, in that all of its IP addressing information is blank.

Finally, in the options fields , we see that this is a DHCP Request. Notice that the requested IP address is no longer blank, and that the DHCP Server Identifier field also contains an address.

The Acknowledgment Packet

In the final step in this process, the DHCP server sends the requested IP addresses to the client in an acknowledgment packet and records that information in its database, as shown in Figure 7-6.

The client now has an IP address and can use it to begin communicating on the network.

DHCP In-Lease Renewal

When a DHCP server assigns an IP address to a device, it leases it to the client. This means that the client is allowed to use the IP address for only a limited amount of time before it must renew the lease. The DORA process just discussed
occurs the first time a client gets an IP address or when its lease time has expired. In either case, the device is considered to be out of lease.

When a client with an IP address in-lease reboots, it must perform a truncated version of the DORA process in order to reclaim its IP address. This process is called an in-lease renewal.

In the case of a lease renewal, the Discovery and Offer packets are unnecessary. Think of it as the same DORA process used in an out-of-lease renewal, but the in-lease renewal doesn’t need to do as much, leaving only the request and acknowledgment steps. You’ll find a sample capture of an in-lease renewal in the file dhcp_inlease_renewal.pcap.

DHCP Options and Message Types

DHCP’s real flexibility lies in its available options. As you’ve seen, the packet’s DHCP options can vary in size and content. The packet’s overall size depends on the combination of options used. You can view a full list of the many DHCP options at http://www.iana.org/assignments/bootp-dhcp-parameters/.

The only option required in all DHCP packets is the Message Type option (option 53). This option identifies how the DHCP client or server will process the information contained within the packet. There are eight message types, as defined in Table 7-1.