Doesn't ISC DHCPD use " fixed-address6", "range6", etc for DHCPv6. The code you linked seems to be related to "fixed-address" which is the ipv4 variant.
Another question I have, does DHCP really need to be the one assigning the address? Should DHCP just be providing config info, and leave the address up to SLAAC? [1] [1] https://tools.ietf.org/html/rfc3736 On Mon, Mar 6, 2017 at 10:53 AM, Dmitri Dolguikh <witlessb...@gmail.com> wrote: > 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 foreman-dev+unsubscr...@googlegroups.com. > For more options, visit https://groups.google.com/d/optout. > -- 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 foreman-dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
