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.
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 MAC address is not in the ARP table). 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
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
I have a DHCP-related question I hope someone can answer.
I have a customer that is currently using a flat network (using vlan 1). To keep it simple, letâs say each location has a single switch. The switch management subnet falls in the 172.x.x.x range, and the VoIP phones (using DHCP provided by the router) is in the 192.x.x.x range.
If I look in any switch that is using the default vlan, I only see arp entries in the 172.x.x. range (the switch management subnet). I see nothing in the 192.x.x.x range, even though the phones are working.
Weâre doing some design changes and moving away from the default vlan and using two separate vlans (vlan 10 for VoIP and vlan 20 for management). For sites using this new design, everything is working. However, in this case, I DO see arp entries in the 192.x.x.x range (along with the 172.x.x.x range).
So, my question is, why do I NOT see arp entries for the 192.x.x.x range (the VoIP subnet) in switches using just vlan 1, but in the switches where we have split out the VoIP and management traffic into two separate VLANs, I DO see arp entries for the 192.x.x.x range?
Hello Andy
This behaviour is to be expected. Even though ARP is a Layer 2 protocol, it is only used by Layer 3 interfaces. So, if your switch has an SVI on VLAN 1 with an IP address of 172.16.10.5/24 for example, then it will have sent out ARP requests for the MAC addresses of devices on the 172.X16.10.0/24 subnet. It will never populate its ARP table with MAC addresses corresponding to IP addresses outside of the subnet of the interface such as 192.168.x.x.
Now you have created two VLANs on the switch, and I am assuming that you have configured an SVI on VLAN 10 with an IP address such as 192.168.10.5/24 for example. This interface will now send ARP requests for the MAC addresses corresponding to that subnet, thus populating the ARP table with those IP address/MAC address combinations as well.
I hope this has been helpful!
Laz
Phase Layer 3 Layer 2
Discover Broadcast Broadcast
Offer Broadcast Unicast
Request Broadcast Broadcast
Ack Broadcast Unicast
DHCP offer and ack messages are unicast at layer 2 (destined to mac address of the host requesting layer 3).
Why canât the host learn the mac address the DHCP server from the Offer message and send the Request message also as layer 2 unicast.
Also, which layer does this Bootp protocol actually work on?
Please help me understand.
Thanks
Ajeet
Please see the attached image and let me know if it is right or wrong?
Thanks
Ajeet
Hello Ajeet
Take a look at this post. I believe it will answer your question.
Also, BootP is implemented using the UDP protocol, so it does function up to Layer 4.
I hope this has been helpful!
Laz
Hello Ajeet
According to my previous post, in most cases, the Layer 2 destination for a DHCPREQUEST is the MAC broadcast address. However, as stated in the previous post, whether it is a broadcast or unicast communication largely depends on the OS being used.
Also, the acknowledgement at the end may also have an L2 broadcast destination depending on the parameters set by the OS. The RFC 2131 states the following:
If the âgiaddrâ field in a DHCP message from a client is non-zero,
the server sends any return messages to the âDHCP serverâ port on the
BOOTP relay agent whose address appears in âgiaddrâ. If the âgiaddrâ
field is zero and the âciaddrâ field is nonzero, then the server
unicasts DHCPOFFER and DHCPACK messages to the address in âciaddrâ.
If âgiaddrâ is zero and âciaddrâ is zero, and the broadcast bit is
set, then the server broadcasts DHCPOFFER and DHCPACK messages to
0xffffffff. If the broadcast bit is not set and âgiaddrâ is zero and
âciaddrâ is zero, then the server unicasts DHCPOFFER and DHCPACK
messages to the clientâs hardware address and âyiaddrâ address. In
all cases, when âgiaddrâ is zero, the server broadcasts any DHCPNAK
messages to 0xffffffff.
where
So it really depends on whether it is an IP address that is being initially requested or if it is a renewal of an already leased address.
I hope this has been helpful!
Laz
DHCP DISCOVER, OFFER, REQUEST AND ACK ARE ALL BROADCAST?
Because I see in wireshark that all have the destination of 255.255.255.255.
Is it Right?
I think that the offer, request, and ack should be unicast packet address because both client and server know about each other after the server receives a DHCP discovery.
Could you explain better?
thanks
Rodrigo