Issue Regarding Bit 1 and 0 of the Broadcast Flag in DHCPMessage?

[D_Ace]

According to the definition from  https://www.ietf.org/rfc/rfc2131.txt  about DHCP, on page 24 it is stated that the DHCP Offer message will be sent as unicast or broadcast depending on the DHCP Discover message's broadcast flag being 0 (unicast) or 1 (broadcast). I conducted an experiment and used Wireshark to capture the message; however, it does not match the description in RFC 2131. The DHCP Discover packet sets the broadcast flag to 0 (unicast), but the DHCP Offer is sent as a broadcast with the MAC destination as FFFF... and IP Destination as 255.255.255.255. According to the RFC, when the broadcast flag is 0, the IP and MAC destination in dhcp offer should be the IP address from the 'yiaddr' field and the MAC destination should be 'chaddr' field. I am confused about this, can anyone help explain why? Happy to receive anyone's support

[MHM Cisco World]

this lab for you one router use flag and other not 
see how R1 (local dhcp server) send offer and ACK 
I show you column of IP and Mac 
MHM

[D_Ace]

Thank you for your response, but the problem is still not clear, your picture is that R2's f0/0 sends broadcast, flag =1 and the address is broadcast, and on R3 f1/1 sends DHCP Discover broadcast, but dhcp offer is unicast (flag = 0) which is reasonable. As for my problem, as in the image I provided, DHCP offer set flag = 0 (u) but dhcp offer sends with broadcast address, is this unreasonable? If according to rfc, when flag = 0, ip and mac will be unicast.

[MHM Cisco World]

check above comment 
MHM 

[MHM Cisco World]

I see where you are confuse 
this flag send by client but the Server can accept it or not 
in your case client send the flag but the server dont accept it 

MHM

[MHM Cisco World]

https://www.mist.com/documentation/microsoft-dhcp-servers-default-broadcast/

Check this link the server sometime follow RFC and some not follow it 

MHM

[D_Ace]

yes sir, I understand what you mean, it means that even though the client has set flag = 0 (unicast), the server does not accept it and will still respond to the broadcast, and when the offer message is responded to, The flag in the dhcp offer will still remain the same as when the client initially sent it, is that true?

[MHM Cisco World]

I will check in my lab to see the flag send and receive between client and server in both cases 

MHM

[D_Ace]

dear sir, I tried testing again and capturing the dhcp message to check the flag field in those 2 cases. Here are the results:
Case 1, dhcp client sends dhcp discover and set flag = 0, then dhcp offer set flag = 0 (unicast), and the correct ip and mac addresses are unicast ip and unicast mac, as shown below:

Then I continued testing with the case of flag = 1 (broadcast), when dhcp discover set flag = 1, the dhcp offer also has flag = 1, and the ip address, and the mac of the dhcp offer is also shown as mac and ip broadcast, this is reasonable according to rfc, as shown below.


Going back to the problem I was asking initially, the dhcp offer message set flag = 0(unicast), however the ip and mac are broadcast, what does this mean, the server received flag = 0, however not accepted Receive and send unicast, still send broadcast and keep the client sending flag? It seems absurd compared to the above two cases. So what is the purpose of this flag when it can be rejected by the server, and why does the server refuse, when receiving flag = 0, and still send the message in broadcast style. I'm very confused, and feel unclear. The image below is of the switch core.

[MHM Cisco World]

I check in lab the flag in DHCP offer match what use as source / destination 
unicast or broadcast 
it seem that your server ignore this flag, so it not cisco issue it DHCP server vendor issue 
what is your DHCP server ?

[D_Ace]

dear Sir, my dhcp server is Alcatel Switch, it seems Alcatle is required to send broadcast