This is just a normal udp broadcast packet sent to FF:FF:FF:FF:FF:FF / 255.255.255.255. You do not need raw sockets to receive it.

There is an ISC dhcp article here with more info on why they need it: https://kb.isc.org/docs/aa-00379

But I just thought about it some more.. In a normal unix socket, you don't set the destination mac address when sending a packet. You just set the destination IP address and the kernel figures out the destination MAC address using a static, cached or dynamic ARP lookup.

But since the dhcp client has not been assigned the IP yet, ARP would fail.

The DHCP server would need to set a static ARP entry before sending the response, and hope the kernel properly fills the destination MAC. This causes more problems..

Its much easier and reliable to just craft the exact headers required as-per the RFC, especially in a cross-platform piece of software like the ISC dhcp server.

It's the fact that TCP/UDP socket interface doesn't expose macaddress, dnsmasq IIRC does the same