On 14/05/2019 14:29, Oliver Freyermuth wrote:
Same here. In an automated deployment situation, client changes DUID in each
phase:
- PXE (if done via IPv6)
- Installation time (from ramdisk)
- Final OS after installation
This may improve if newer versions of dhcpcd get packaged in installer ramdisks
and OS, and also for systemd-dhcp,
but I am still unaware of any implementation of machine-id as base for the
client DUID in dhclient and of course the implementations are all not exactly
the same.
And then there is still the UEFI doing the PXE part, systems with broken
machine-id etc.... And of course, dual booting if not set up with identical
cliend-DUID.
In general, my belief is that the RFC was made without real life use cases in
mind and hence did not think of these.
The patch is very helpful to overcome these issues and matches user expectation
(when specifying a MAC address in the config file, I want it to be used).
Speaking for dhcpcd (as yay, I am the author) - if the OS presents a
stable UUID dhcpcd will use that for the DUID:
https://tools.ietf.org/html/rfc6355
https://roy.marples.name/cgit/dhcpcd.git/tree/src/duid.c#n63
So a fully automated deployment using dhcpcd AND a kernel which reports
a stable UUID then all is good.
But not everyone uses dhcpcd>=7.0.6 with the UUID code in, nor a kernel
which reports a stable UUID.
There is literally no reason to use dhclient anymore - and hasn't been
for a number of years.
Roy
_______________________________________________
Dnsmasq-discuss mailing list
[email protected]
http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
