Am 04.06.2018 um 12:49 schrieb Roy Marples:
> On 03/06/2018 22:20, Simon Kelley wrote:
>> I agree that this is an annoying problem. In DHCPv6 even determining the
>> MAC address of a client is a slightly dodgy operation - there are
>> circumstances where it's not possible. That notwithstanding, dnsmasq
>> does it's best, and allows you to configure an address to allocated by
>> MAC address.
>>
>> The problem here is that the client changes DUID - the desired address
>> gets allocated by MAC address once, but when the DUID changes, the
>> address is already in use by a first DUID/IAID combination, so it can't
>> be allocated, even if the MAC address is the same.
>
> The problem is how the DUID is generated, not the DUID itself.
> DUID-LL is not the default (and shouldn't be either).
> DUID-LLT is a good default, but comes with the aforementioned problems.
>
> These problems are very nicely solved with RFC 6355 which adds DUID-UUID
> where UUID is taken from the hosts firmware. The UUID can then be displayed
> on the node alongside the MAC address for provisioning.
> https://tools.ietf.org/html/rfc6355
>
> The downside is that no client I know of supports this and I keep meaning to
> add support to dhcpcd for it.
This sounds like a really nice solution - it would be cool if this was added to
dhclient and dhcpcd and systemd-networkd, and would be the default.
This should then also fix the problem with automated deployments.
Still, even if support for that is added, it will likely take some years until
all components are fixed...
> The other downside is that not all hosts have a retrievable UUID as it
> depends on both the OS and host itself - for example some OS's present a UUID
> based on the CPUID. Of course this only works if all OS's generate the same
> UUID from the base data.
>
> TL;DR - this isn't a dnsmasq issue and I agree with Simon that it should not
> allow nor encourage RFC violations.
I fully agree it's not a dnsmasq issue (I already mentioned that in my first
mail). I was mainly unaware of RFC6355 (which should indeed be *the* solution),
and am convinced that a workaround on the DHCP server end is significantly
easier to deploy for a full network than to get rid of all clients not yet
using RFC6355,
so I keep wondering whether an optional feature to violate the "old" RFCs would
be feasible until all clients are fixed, which will surely take half a century
or longer.
Alternatively:
Does somebody know of a clean way to administratively expire a lease handed out
by dnsmasq?
Then deployment tooling could forcefully expire an old lease when reinstalling
a node, and after the final reboot in the installed OS.
Right now, I only know one could:
- Stop dnsmasq.
- Purge the lease from the leases-file.
- Restart dnsmasq.
Is there a more convenient way?
Cheers,
Oliver
>
> Roy
>
> _______________________________________________
> Dnsmasq-discuss mailing list
> Dnsmasq-discuss@lists.thekelleys.org.uk
> http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
_______________________________________________
Dnsmasq-discuss mailing list
Dnsmasq-discuss@lists.thekelleys.org.uk
http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
