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