Issues with support of IPv6/DHCPv6 in Smart-Proxy

[lzap]

Unfortunately, there is no management api and the
only way to integrate with it is via db (not sure how stable the
schema is, or if it even has been documented).

For the record, Kea 1.2 now supports management API and also file-based storage.

[lzap]

@lzap

For the record, Kea 1.2 now supports management API and also file-based storage.

Few years later, I read more of the Kea documentation any my impression is that the management API is present but only very limited portion of it. Parts which Foreman would require (record management) is a Premium hook (plugin) which requires subscription. It’s not free.

Kea also does strictly stick with DUIDs for IPv6, there is a support for MAC address via Client Link Layer Option recognition but that does not cover all the use cases or hardware. Finally, Kea is not present in RHEL 9 (Beta).

All and all, while Kea is definitely one of the best DHCP servers out there, it has its quirks and it does not solve problems of devops/admins in 2021.

As was mentioned by Ewoud, ISC DHCP (the old implementation) now supports MAC-based reservations for IPv6. I was not able to find this feature mentioned in their changelog but RHEL8 now has version 4.3.6 which should have this feature (unless this was a debian-only patch). Unfortunately, this does not help much because omapi does not support IPv6 record creation so Foreman cannot utilize that without modifying configuration files and restarting the daemon. Not something we want to do I guess although I’ve seen this in production too.

An interesting project called dhcpy6d was mentioned, but it intentionally breaks the DHCPv6 contract and I have some concerns about scalability. But it could be a way if we want to keep the tight DHCP records management in Foreman:

Any experience with dhcpy6d for IPv6 stateful DHCP

Hey, I am looking into future options for our IPv6 DHCP management which is currently - ehm - none. One project was mentioned years ago and it looks like it’s still well and alive: dhcpy6d. In short: the problem of DHCPv6 is that MAC address is no longer present in the request, instead technically a random UID (DUID) is sent. This does not fit very well with Foreman workflow where MAC address of a provisioning interface is the key identifier. It’s a tiny DHCPv6 server that is written in Pytho…

To me, it looks like the best approach might be the idea of having two DHCP servers on the same network. One would be only serving PXE clients providing network-boot information (filename option, TFTP server option) and the other would provide network credentials (IP address, router, netmask).

However, I was never sold on the idea of utilizing netboot, the experimental project mentioned above. If you click on the link you will find out that the project is no longer maintained. The idea is valid tho.

Proposal: What you feel about utilizing dnsmasq to do PXE-DHCP (and possibly even TFTP) services? It can be configured in a way that it will only reply to PXE clients providing required filename/TFTP options for both TFTP/PXE and UEFI HTTP boot clients.

This PXEDHCP could be actually a new foreman-proxy feature, there would be no API because there is nothing to configure - it’s completely static. As long as PXE/HTTP directory is managed by Foreman and MAC-based Grub2/PXELinux/iPXE configuration file is deployed, the client will pick it up. It will contain the provisioning UUID (token) that will allow loading of additional templates.

https://wiki.fogproject.org/wiki/index.php?title=ProxyDHCP_with_dnsmasq

The only question is - would this work in real production? I mean obviously it’s something we can verify in our labs or libvirt networks, however, I can imagine some poor DHCP client implementations might not expect two DHCP replies (although specs allow that and even define exactly what to do).