I'm working on adding support for IPv6/DHCPv6 on smart-proxy side, and have come across several issues on which I'd like to hear your thoughts.
- It is not possible to assign ipv6 addresses to host records (reservations) when ISC dhcpd is used. This is due to a limitation in host record serialization code in dhcpd [1], which assumes that fixed address is always four octets long. I can see two possible approaches to compensate for this. One approach would be to define host records without ip addresses. To ensure that dns records stay valid, preferred-lifetime dhcpv6 option can be used to extend lease duration. On host removal, lease state or lease expiry date can be updated, or lease object can be destroyed altogether. As ipv6 addresses are managed by a dhcp server in this scenario, after a host has been created, an additional call to smart-proxy will be required to discover its ip address. Another approach is to delegate dns record updates to dhcp server. Client fqdn or partial hostname can be passed to dhcp server via “client fqdn” option [2]. This approach may require additional client configuration — I don’t know how various linux distributions configure their dhcpclient (I think recent windows clients send this information by default). - It is difficult to determine host’s client id (dhcp unique identifier, AKA DUID) its value depends on os, dhcp client, and even version of the client. DUID is persistent across system reboots, but may be lost on os (re)installation. [3] has more details on how various client generate DUID. To simplify host management/reduce support issues, it might be necessary to configure host DUID during system install, possibly by using uuid value from system’s DMI table [4]. - PXE uses client id (UUID/GUID) that is different from that of the host. This will result in two ipv6 addresses being allocated to every host that uses PXE. One approach is allocate ipv6 addresses from different pools with different preferred-lifetime options. In this approach PXE pool would have very short lease durations. Clients that belong to the PXE pool can be identified by the presence of “boot file url” dhcp option. Another approach is to have smart-proxy act as a simple dhcp server. It would answer dhcp requests containing “boot file url” itself and ignore/relay all other requests to the main dhcp server. This approach could result in less orchestration in Foreman: for example, with this approach pxe boot configuration can be generated on demand and served via http, without any config files created/updated on a tftp server. Thoughts? -d [1] https://source.isc.org/cgi-bin/gitweb.cgi?p=dhcp.git;a=blob;f=server/db.c;h=94f1584fd44e17ac0dfecf9fc9e3fd3da01ecb8d;hb=HEAD#l395 [2] https://tools.ietf.org/html/rfc4704#section-4 [3] https://wiki.fysik.dtu.dk/it/IPv6_configuration#dhcpv6-unique-identifier-duid [4] https://wiki.fysik.dtu.dk/it/IPv6_configuration#id25 -- You received this message because you are subscribed to the Google Groups "foreman-dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
