DHCP Least Negotiation (DORA)

DHCP Least Negotiation (DORA)


In this video from ITFreeTraining I will go into more detail about the process that an IPv4 device uses to obtain an IP Address and other network configuration. The process is called DHCP Lease Negotiation. This video will look at the process as well as the different message types that are used in this process.

Download the PDF handout:

DORA
The process used to obtain an IP Address using DHCP is referred to as DORA. There are four steps involved in the DORA process. These are the discover message, offer message, request message and acknowledgment message. The client uses these messages to obtain network configuration from a DHCP server. I will now have a look at these messages in more detail.

Discover Message/DHCPDISCOVER
The first message that I will look at is the discover message, officially known as DHCP Discover. To understand how this message works, consider that there is a desktop computer on the network attempting to obtain an IP Address. The device does not have any configuration or have any information about what network it is on.
In order to start the process without any configuration, the device sends a broadcast message on the network. This will go to all devices on the network, so on a large network this can be bandwidth intensive.
In the packet that is sent on the network, you will notice the MAC address is set to all F’s. This address is used in Ethernet for a broadcast. Notice next that the source MAC address is set to the device’s MAC address. In this case I have used a simple MAC address. The MAC address will be the MAC address of the network card that is requesting network configuration using DHCP. Following this is the destination IP Address. This is set to 255.255.255.255. This is the IPv4 broadcast address. At this stage, the device does not know the address of the DHCP server. Next, notice the source address. This is set to all zeros as the device does not currently have a valid IP Address that it can use. Lastly, notice that the packet will be sent on the network using UDP on port 67. Only DHCP servers on the network should be listening on this port.

Discover Message/DHCPDISCOVER
Now let’s consider what happens when the device sends the packet out on the network. Consider that there are other computers on the network. There are also two DHCP servers on the network. Since the packet is a broadcast packet, it will go to all devices on the network.
The two desktops on the network are not running DHCP and thus not listening on port 67. For this reason they will drop the packet. However, the two DHCP servers on the network will both receive the packet and they will both respond to it. To see how this works, I will move on to the next message type.

Offer Message/DHCPOFFER
The next message is the DHCP Offer which is the O in DORA. On this network there are two servers running DHCP that can respond to requests from the desktop on the network. If both DHCP servers have free IP Addresses to allocate to devices, they will both respond to the request.
In this case, DHCP server 1 was the first to respond. Whichever DHCP server responds first is important and we will find out why in a moment. Notice that in the response is an offer for an IP Address. The DHCP server has reserved this IP Address for use with that device, if the device decides that it wants to use it. More on that in a moment.
The packet also contains information on the subnet and gateway for the network. It is also possible to give out DNS information at this stage. However, any more configuration than this will be given to the device later on.
Notice that the destination MAC address is set to the device’s MAC address. Since the DHCP server now knows the MAC address of the device, it can send a direct message to the device rather than using a broadcast. It is possible for the device to request that the DHCP Offer message is sent using a broadcast, however it is up to the DHCP server to decide which one it wants to use.
The source address will be the MAC address of the DHCP server. In this case, I have used a simple MAC address to make it easy to understand. Notice that the destination IP Address is 255.255.255.255 or the IP Address used for broadcasting. Remember that the device does not have a valid IP Address at this time and the IP Address is just an offer. The device has not yet accepted it or started using it.
Following this is the source IP Address. This will be configured to the IP Address of the DHCP Server. Lastly, notice that the message is being sent using unicast or port 68. Broadcast generally will not be used unless the device requests it and the server is configured to allow it. Port 68 is used by DHCP servers to respond back to devices. Remember that port 67 is used by devices to communicate with the DHCP server.
Now that we have had a look at the response from the first DHCP server, let’s now consider that the second DHCP server has responded just after the first DHCP server. The information is pretty much the same, so I won’t worry about going through it in detail. Essentially it contains an offer for an IP Address. So the next step is, which of these offers will the device accept?

Which Offer is Accepted?
The next step is that a DHCP Request message is sent to the DHCP server. However, let’s consider that the DHCP client in this example has two DHCP offers so, which one does it accept? Generally speaking, the device will accept the first offer. The second offer will be discarded. If there were any other offers, they would also be discarded.
It is, however, possible for a device to accept any offer. On Linux, it is possible to configure additional options. For example, to favor an offer that has the same IP Address as the device had previously. However, by default, Windows and Linux will accept the first offer. Next, I will have a look at the next step of the DORA process.

Request Message/DHCPREQUEST
The next step is that the device needs to put in a request to accept the IP Address that it has been offered. Even though the device has been offered an IP Address, it has not yet accepted it. For this reason it is not able to use the IP Address yet. Also, remember that it may have been given multiple offers. The device needs to inform the other DHCP servers it is not accepting their offers and it needs to do this without a valid IP Address.
To do this, the device sends another broadcast on the network. The details of the broadcast are the same as the previous broadcasts, so I won’t worry about going through them. Source and destination addresses are the same and the packet will be sent via UDP on port 67. The important point to remember is that the device has received an offer for an IP Address only. However, the device is not able to use it yet.

Request Message/DHCPREQUEST
Let’s now consider what happens when the device sends the packet out on the network. There are other computers and devices on the network and the two DHCP servers. Since the packet is a broadcast packet, it will go to all devices on the network.
Like before, since the desktops are not listening on port 67 for DHCP messages, they will drop the packets. The two DHCP servers receive the message as well. The second DHCP server will see the broadcast and now knows that its offer has not been accepted and it can now offer that IP Address to a different device. The first DHCP server now moves on to the last part of the DORA process.

Acknowledgment Message/DHCPACK
The last message that is sent on the network is the acknowledgment message. This message is sent from the DHCP server to the DHCP client. This message informs the device that it can use the IP Address. The DHCP Acknowledgment also contains any other additional configuration information. As we will see in later videos, there are a huge number of settings that can be configured in addition to the basic network settings. For example, proxy settings can be configured via a DHCP server, but more on that in later videos. The important point to remember here is that these additional DHCP settings are sent over the network.
I won’t worry about pointing out the details of the information sent in the message, because it is much the same as the DHCP Offer message covered earlier in the video. Source, destination and port are the same. Notice that the destination IP Address is still all 255’s. Even though this is the last message that is sent and confirms the device can use the IP Address, until the device receives this message it is not actually using the IP Address.
Once this message is sent, the DHCP server will record this IP Address as being allocated to that device. It will not allocate the IP Address to any other device. The device is now free to use the IP Address for network communication. In most cases, the process will go as expected; however, I will cover one last message type that is used when something goes wrong.

Negative Acknowledgment/DHCPNAK
The last message is the negative acknowledgment message. This message replaces the acknowledgment message. The source, destination and port used in the message are the same as the acknowledgment message so I won’t worry about going through it again.
The negative acknowledgment message informs the device it is not able to use the IP Address. Normally the whole process takes microseconds, so it is unlikely that the DHCP server is going to change its mind about allocating the IP Address. However, it is possible. It is more likely that the client took too long to respond to the DHCP Offer message. This can happen if there are problems on the network. For example, a network outage. When this occurs, the DHCP client will (upon receiving the negative acknowledgment message) l need to restart the DORA process in order to get an IP Address.
There has been a lot covered in this video, so I will perform a summary of the main points.

Summary
The process of obtaining an IP Address using IPv4 is called DORA. The DORA process consists of four messages; discover, offer, request and acknowledgment. The name DORA is made by taking the first letter of each message.

Summary
The DHCP Discover message is the first message in the DORA process. It is when a DHCP client sends a broadcast on the network attempting to locate a DHCP server.

Summary
The second message is the offer message. This message contains an IP Address that is offered to the client to use. If there are multiple DHCP servers on the network, the client may receive multiple offer messages. It is up to the client to decide which one it wants to use. Generally the first offer message that it receives will be the one it uses.

Summary
The DHCP Request message is where the DHCP client sends a broadcast on the network informing all DHCP servers which offer it wishes to accept. Generally, the first offer is accepted. Since the message is sent via a broadcast, all DHCP servers now know if their offer was accepted or rejected.

Summary
The DHCP Acknowledgment message is when the server informs the client that it can use that IP Address. The message also contains any additional DHCP configuration. The DHCP server will now record that IP Address as being allocated to that DHCP client and not allocate it to anyone else.

Summary
All packets are sent via UDP. Servers listen on port 67. Clients listen on port 68. Since the client does not have an IP Address it will use broadcasts to communicate. The server will respond with a unicast message. The client can request a broadcast for a response, but ultimately it is up to the server to decide which one will be used.
Well, I would like to thank you for watching this video from ITFreeTraining on the DORA process. For more free videos on this course and others, please see our web page or YouTube channel. Until next time, thanks for watching.

References
“Installing and Configuring Windows Server 2012 R2 Exam Ref 70-410” pages 219-221
“Dynamic Host Configuration Protocol” https://www.ietf.org/rfc/rfc2131.txt
“Investigation of DHCP Packets using Wireshark” http://research.ijcaonline.org/volume63/number4/pxc3885155.pdf

Credits
Trainer: Austin Mason http://ITFreeTraining.com
Voice Talent: HP Lewis http://hplewis.com
Quality Assurance: Brett Batson http://www.pbb-proofreading.uk