Knowledge Base ISC Main Website Ask a Question/Contact ISC
Why does DHCP use raw sockets?
Author: ISC Support Reference Number: AA-00378 Views: 11620 Created: 2011-07-29 13:25 Last Updated: 2017-02-02 17:19 0 Rating/ Voters

The DHCP protocol has some specific requirements to really work properly - in particular being able to transmit to and receive packets sent to the all-ones limited broadcast address (255.255.255.255), and being able to send a unicast without an ARP.  It's not possible to do this via BSD/UDP sockets although dhcpd does also open a BSD/UDP socket (called the "fallback interface") that you will see in netstat.

The raw socket:

  • Receives all DHCP packets, so the DHCP packet sent to the server must come in on the interface the socket is opened on.
  • Transmits directed unicasts (w/out ARP), and special RFC 2131 complying all-ones limited broadcasts.  These are needed in clients' initial configuration stage (when the client does not yet have an address configured).

The BSD/UDP socket:

  • Is read from to empty it and free up buffers (it will receive some packets that are duplicates of packets received via the raw socket.
  • Is used to transmit routed unicasts.  These are used to reply to any relay agent, or to reply to clients apparently in the renewing state.

It is possible to compile raw socket behaviour out for very specific reasons, but this will only work if you never have any directly-connected clients - that is clients on the same
broadcast domain as the DHCP server.  All clients must be reached by relay agents in this case.

DHCP with firewalls and packet filters

dhcpd's raw sockets receive packets before the point at which most OS packet filters and firewalls operate which means that if you want to reliably intercept packets before they reach the DHCP server, it is better to do this externally to the server itself.  For most installations this is unnecessary anyway; ISC DHCP has a comprehensive configuration language with flexible access controls that should be sufficient for most needs.


© 2001-2017 Internet Systems Consortium

For assistance with problems and questions for which you have not been able to find an answer in our Knowledge Base, we recommend searching our community mailing list archives and/or posting your question there (you will need to register there first for your posts to be accepted). The bind-users and the dhcp-users lists particularly have a long-standing and active membership.

ISC relies on the financial support of the community to fund the development of its open source software products. If you would like to support future product evolution and maintenance as well having peace of mind knowing that our team of experts are poised to provide you with individual technical assistance whenever you call upon them, then please consider our Professional Subscription Support services - details can be found on our main website.

Feedback 2
  • #
    [ Borislav]: why raw socket 2015-03-25 14:47

    After kernel 2.2 there is perfectly reasonable solution for all-ones limited broadcasts using SOCK_UDP. You didn't revise your code, using raw socket is not sensible.

  • #
    [Cathy Almond]: Re: why raw socket 2015-05-29 11:54

    The need for raw sockets is more than the one instance that you quoted, including the need (for some clients) to respond with a unicast reply direct to the client's MAC address with the DHCPOFFER, but without (yet) an IP address for the client to which to send.

    Another reason for listening via a raw socket is that the inbound local network broadcast traffic from clients may have what the network stack implementation has defined as an illegal source and be filtered out before reaching the application code (if not using raw socket access). Hence, (and given that we need DHCP to work in as many OS environments as possible), it's safest to manage the filtering of the raw traffic in the DHCP code directly.

Quick Jump Menu