4 294 967 296 IPv4 addresses. Theres quite a few. Even though we have run out of IP-addresses in the IPv4 space since a while back, we still have to manage the dynamic nature of client moving around in our networks. In order to handle IP-allocation we usually rely on DHCP. Now, for IPv6 there are a few additional methods of assigning devices IP-addresses dynamically, but we will dive into that in future blog posts. Right now, I want to dive deep into the workings of DHCP and the various relevant options.
DHCP - Dynamic Host Configuration Protocol
Dynamic Host Configuration Protocol, or DHCP, is an extension of the Bootstrap Protocol, or BOOTP, aiming to allow the dynamic allocation of IP-resources and IP-configuration to hosts. It operates in a client-server model, where a single, or multiple DHCP-servers allocate the device an IP-address. Generally, you want to only allow your own servers to be the ones that respons to client messages. Usually these DHCP-servers need to be explicitly configured, since the settings needed for IP communication vary from network to network. Settings like IP-range, default gateway, lease time and DNS-servers. There are actually three operational modes which DHCP can run in: automatic, dynamic and manual. Automatic is rarely used since this permanently assigns an IP-address to a device, while dynamic allows for a set lease time whereafter the IP-assignment expires and will need to be renewed by the client. Manual is much like it sounds, manually assigning an IP-address to a host.
The DHCP packet
DHCP packets contain a lot of information. It is important to note that the packets used to transmit the DHCP data is actually BOOTP packets containing DHCP information. This becomes relevant as we deepdive into the different fields present in the packet. BOOTP in it’s turn uses UDP as a transport layer.
Here is a visual digram generated by Wireshark of a DHCP Discovery packet:
![[image2.png]]
In this we can see the following relevant BOOTP/DHCP fields:
| Name | Description |
|---|---|
| Message type | This defines the type of BOOTP message. |
| Hardware type | The hardware type used, ie. the protocol used. Such as Ethernet (1) or Frame Relay (15). This can be found under the section “ADDRESS RESOLUTION PROTOCOL PARAMETERS” on page 163-164 in RFC1700. |
| Hardware address length | The length of the hardware address in bytes. In the case of Ethernet, this would be 6. |
| Hops | This is a hop count for DHCP relay agents. The client sets this to zero, and it is then incremented by one for each DHCP relay in the path. |
| Transaction ID | This is a random number generated by the client which is used by both the client and the server throughout that specific DHCP transation. |
| Seconds elapsed | This field is populated only be the client and denotes the total time since the client initiated the DHCP process. |
| BOOTP flags | This field allows the DHCP server to adapt the type of transmission that is used to send the client the BOOTP packets. In the case that a client cannot receive unicast before having a configured IP-address the BOOTP flag can be set to use broadcast instead of unicast. This is decided by the client. |
| Client IP address | This field is used when renewing, bound or rebindning an IP-address. |
| Your IP address | The IP-address currently used by the client. |
| Next server IP address | This field is used to signal which DHCP server the client should use in all the following DHCP communication. This is decided by the server. |
| Relay agent IP address | This field is used when the DHCP packets are relayed to the server. Commonly the gateway of the network is also the DHCP-relay. |
| Client hardware address | The MAC-address of the client. |
| Server hostname | This field is optional. |
| Boot file name | This field gives the path to a boot file. Null means “generic”. |
| Options | The options fields are a set of mandatory/optional values which can be sent to the client. This includes the common option 43 and 82. |
Message types and DHCP timeline
There are a few different types of messages sent during the DHCP process. The process is always initiated by the client.
The first time a client requests an IP-address it will send out a DHCPDISCOVER packet to the IPv4 broadcast (or in the case of IPv6 it’s a bit different using a IPv6 multicast address “FF02::1:2”) destination address, since the IP configuration for the network is not known.
![[image4.png]]
This packet is then read by the DHCP server, which will respond with a DHCPOFFER containing the IP configuration, along with other BOOTP options. The offer packet is sent using the newly assigned IPv4 address as the destination of the IP packet, however, with the Layer 2 destination address of the client, unless the BOOTP flag is set to broadcast, in that case broadcast is used instead. The offer also contains the unicast address of the DHCP-server.
![[image5.png]]
If the client accepts the offer it will send a request to the broadcast address again, but this time containing the requested IP-address option as a DHCP Option.
![[image3.png]]
The final step is then that the server will send an acknowledgement back to the client. This is done using pure unicast.
![[image6.png]]