Introduction to DHCP

Fernando,
This question was answered in the comments just a few lines up ^^^^

Rene misspoke in the video.

Hello Rene,

Thank you very much for your clear explanation,i have a small query on this topic

I understand that DHCP uses UDP 67 and 68 for its communication,but IP allocation process should be reliable right?

So my question here is why DHCP uses UDP instead of TCP? Any specific reason behind that?

Thanks and Regards,
HARI

Hi Hariharan,
I would think there are two reasons for this:

  1. The DHCP processes itself, via DORA (Discovery Offer Request and Acknowledgement, in IPv4) has all the reliability it needs without the additional overhead of TCP. If any of those DORA messages are lost, the client will simply retry.

  2. Aside from some implementations with DHCP renewals, the client will not have an source IP address - instead it is 0.0.0.0, so establishing a SYN, SYN-ACK, ACK TCP session would not be possible.

--Andrew

Hi Rene/Andrew,
I am able to understand that discover, offer packets are broadcast. How about Request and Acknowledgement ? whether it is broadcast ? When we use relay agent it will be unicast. However i want to know about if there is no relay in our network? Please let know.

- Thanks!

Hi Saranya,
This topic can be a little bit confusing because there are two different layers that can perform broadcast or unicast - Layer 2 and Layer 3.

Here is a summary of what happens at each layer for each phase:

Phase      Layer 3      Layer 2
Discover   Broadcast    Broadcast
Offer      Broadcast    Unicast
Request    Broadcast    Broadcast
Ack        Broadcast    Unicast

Note:
Layer 3 broadcast = 255.255.255.255
Layer 2 broadcast = FFFF.FFFF.FFFF

You may notice that layer 3 is always broadcast. This is because the whole purpose of DHCP is for the client to establish its layer 3 address, which will not happen until the conclusion of DORA. Additionally, you may notice that all communication from the DHCP server at layer 2 is unicast. The reason for this is because the DHCP server obtained the client’s MAC address when the client sent out its initial Discover message.

5 Likes

Dear Rene/Andrew,
Thank you for this great lesson. Mr Andrew with reference to your reply # 27608 above particularly this point " Additionally, you may notice that all communication from the DHCP server at layer 2 is unicast. The reason for this is because the DHCP server obtained the client’s MAC address when the client sent out its initial Discover message.", I am still confused on where broadcast happens and where unicast happens. From the Wireshark captures above I do not see Unicast happening anywhere. Even for Offer and Ack from the server the dest mac address seems to broadcast instead of unicast to the end device.

Could you please clarify on this. Thank you very much.

Srikanth,
I have seen conflicting information as well. For example, the link below supports what you are seeing (no unicasts)
https://www.cloudshark.org/captures/0009d5398f37

However, in the following Wireshark Wiki site, it supports what I was saying (Offer and ACK from the server are layer 2 unicast)

https://wiki.wireshark.org/SampleCaptures?action=AttachFile&do=get&target=dhcp.pcap

My only conclusion is that different vendors must have implemented how the DHCP server handles Offer and ACK differently.

FYI: I read through the RFC on DHCP (https://www.ietf.org/rfc/rfc2131.txt)

The RFC does not mandate what method the DHCP server uses to communicate with the client. I suspect because of this, like I said earlier, different vendors will implement this differently. In my opinion, having the server use layer 2 unicast messages makes more sense from an efficiency standpoint.

Thank you Mr. Andrew.

Hi Rene/Andrew,

Still im not understanding how you guys saying offer packet would be broadcast , Here im attaching 2 wireshark captures (One is with a fresh PC another one with renewing a existing DHCP IP).

In both captures i can see like below.
Discovery : Broadcast
Offer : Unicast
Request : Broadcast
Acknowledgement : Unicast

I can see ARP comes into play here , Is that make the difference.

Im unable to attach 2 files here , Will attach as next comment.

Attached…

Sorry , Your security features didnt let me upload the files.Any email ID’s available so that i can send it over.??

Ajay,
Did you see my earlier comments from August 15th? I provided evidence of Offer packets being implemented both as Broadcast and Unicast. It seems to be implemented differently for different vendors. The capture files you are trying to show are likely from a vendor that happens to use the Unicast method.

FYI: I read through the RFC on DHCP (https://www.ietf.org/rfc/rfc2131.txt)

The RFC does not mandate what method the DHCP server uses to communicate with the client. I suspect because of this, like I said earlier, different vendors will implement this differently. In my opinion, having the server use layer 2 unicast messages makes more sense from an efficiency standpoint.

19 posts were merged into an existing topic: Introduction to DHCP

andrew
Could you please explain why OFFER message from server at layer 2 is broadcasted while i think it should be unicast in nature as DHCP sever has already got the client MAC address in client DISCOVERY message.

1 Like

Hello Samit

This is an excellent question and it shows that you’re thinking deeply about the subject. It is true that the DHCPOFFER when sent can technically be sent using a unicast MAC address since the MAC address of the host making the request, and thus the destination of the DHCPOFFER frame, is known. However, some operating systems and NIC drivers don’t always use this logic when operating DHCP.

Some client implementations are unable to receive such unicast frames until the implementation has been configured with a valid IP address. Remember, when we encapsulate, we find the destination MAC address from the ARP table by looking up the associated IP address (or by an ARP request if the . In this case we don’t yet have an IP address so we can’t derive the destination MAC using ARP. The device sending the DHCPOFFER has to be smart enough to populate the destination MAC address not with ARP but with the info it has.

But the host must also be smart enough to interpret such a frame correctly, and not all are.

For this reason, the DHCPDISCOVER message has what is called a BROADCAST flag. If a host requires that the DHCP implementation have a valid IP address before being able to receive a unicast frame with its MAC address, then the BROADCAST flag in the DHCPDISCOVER is set to 1. This means that the DHCPOFFER will be sent as a broadcast. If the flag is set to 0, then the DHCPOFFER will be sent as a unicast frame with the appropriate destination MAC address.

All of this comes from page 24 of RFC2321 that defines DHCP. This goes beyond CCNA and even CCNP level so it’s good to know, but not for certification. CCNA just focuses on the default situation where the BROADCAST flag is set to 1.

I hope this has been helpful!

Laz

1 Like

Andrew,
If a host requires a valid ip address then broadcast flag bit should be set to 0 in that case but you have mentioned 1, please correct if I am wrong

Hello Samit

Yes, a client that cannot receive unicast IP datagrams until its protocol software has been configured with an IP address should set the broadcast bit to 1. This indicates to the DHCP server to respond with a DHCPOFFER message as a broadcast and not as a unicast.

I hope this has been helpful!

Laz

Hi Rene,

DHCP server provides ip address to the host. Is there any additional information DHCP server provides along with ip address? For example subnet mask, gateway.

Regards,
Swapnil

Hello Swapnil

DHCP can provide a multitude of information to hosts. The most common implementations include IP address, subnet mask, default gateway and DNS server. There are many more elements that DHCP can offer and these are called DHCP options. Some of the most common include NTP servers, log servers, cookie servers, interface MTU, default TCP TTL, NetBIOS name server and IRC chat server to name just a few.

These options are indicated using an option number. DHCP option numbers can range any where from 0 to 255. Some of these numbers are standard vendor-independent numbers while others are used by specific vendors. You can find information about these DHCP options at the following link or just search for them on the Internet, there are many available lists:
https://www.cisco.com/c/en/us/td/docs/security/asa/asa84/configuration/guide/asa_84_cli_config/basic_dhcp.html#wp1226344

One other widely used DHCP option is option 150 which is used primarily by Cisco IP phones to discover the local TFTP server. This is required as phones must reach this server to download their configuration which will give them info such as their extension number and other configured parameters.

I hope this has been helpful!

Laz

1 Like