nfdhcpd is a userspace server written in python and based on NFQUEUE [1]. The administrator can enable processing of DHCP, NS, RS, DHCPv6 requests on individual TAP interfaces by injecting nfdhcpd in the processing pipeline for IP packets dynamically (by mangling the corresponding packet types and redirect them to the appropriate nfqueue).
The daemon runs on the host and is controlled by manipulating files under its state directory. Creation of a new file under this directory (“binding file”) instructs the daemon to reply on the requests arriving on the specified TAP interface.
a) The service can be activated dynamically, per-interface, by manipulating iptables accordingly. There is no need to restart the daemon, or edit (potentially read-only) configuration files, you only need to drop a file containing the required info under /var/lib/nfdhcpd.
b) There is no interference to existing DHCP servers listening to port 67. Everything happens directly via NFQUEUE.
c) The host doesn’t even need to have an IP address on the interfaces where DHCP replies are served, making it invisible to the VMs. This may be beneficial from a security perspective. Similarly, it doesn’t matter if the TAP interface is bridged or routed.
d) Binding files provide a TAP-MAC mapping. In other words, requests coming from unregistered TAP interfaces (without a binding file) are ignored, and packet processing happens as if nfdhcpd didn’t exist in the first place. Requests coming from a registered device with but with different are considered as snooping attempts and are dropped.
e) nfdhcpd is written in pure Python and uses scapy for packet processing. This has proved super-useful when trying to troubleshooting networking problems in production.
a) nfdhcpd starts. Upon initialization, it creates an NFQUEUE (e.g., 42, configurable), and listens on it for incoming DHCP requests. It also begins to watch its state directory, /var/lib/nfdhcpd via inotify().
b) A new VM gets created, let’s assume its NIC has address mac0, lives on TAP interface tap0, and is to receive IP address ip0 via DHCP.
c) Someone (e.g., a Ganeti KVM ifup script, or in our case snf-network [2] creates a new binding file informing nfdhcpd that it is to reply to DHCP requests from MAC mac0 on TAP interface tap0, and include IP ip0 in the DHCP reply.
d) The ifup script or the administrator injects nfdhcpd in the processing pipeline for packets coming from tap0, using iptables:
# iptables -t mangle -A PREROUTING -i tap0 -m udp -p udp --dport 67 -j NFQUEUE --queue-num 42
e) From now on, whenever a DHCP request is sent out by the VM, the iptables rule will forward the packet to nfdhcpd, which will consult its bindings database, find the entry for tap0, verify the source MAC, and inject a DHCP reply for the corresponding IP address into tap0.
A binding file in nfdhcpd’s state directory is named after the physical interface where the daemon is to receive incoming DHCP requests from, and defines at least the following variables:
The configuration file for nfdhcp is /etc/nfdhpcd/nfdhcpd.conf. Three sections are defined: general, dhcp, ipv6.
Note that nfdhcpd can run as nobody. This and other options related to its execution environment are defined in general section.
In the dhcp section we define the options related to DHCP responses. Specifically:
In the ipv6 section we define the options related to IPv6 responses. Currently nfdhcpd supports IPv6 stateless configuration [3]. The instance will get an auto-generated IPv6 (MAC to eui64) based on the IPv6 prefix exported by Router Advertisements (O flag set, M flag unset). This kind of RA will make instance query for nameservers and domain search list via DHCPv6 request. nfdhcpd, currently and in case of IPv6, is supposed to work on a routed setup where the instances are not on the same collision domain with the external router and thus any RA/NA should be served locally. Specifically:
In order nfdhcpd to be able to process incoming requests you have to mangle the corresponding packages. Please note that in case of bridged setup the kernel understands that the packets are coming from the bridge (logical indev) and not from the tap (physical indev). Specifically:
For a bridged setup replace tap+ with br+ in case of DHCP. Using nfdhcpd for IPv6 in a bridged setup does not make any sense. The above rules are included in /etc/ferm/nfdhcpd.ferm . In case you use ferm, this file should be included in /etc/ferm/ferm.conf. Otherwise an rc.local script can be used to issue those rules upon boot.
A useful way to see the clients registered in nfdhpcd runtime context one can send SIGUSR1 and see the list in the logfile:
# kill -SIGUSR1 $(cat /var/run/nfdhcpd/nfdhpcd.pid) && tail -n 100 /var/log/nfdhcpd/nfdhpcd.log