[Dnsmasq-discuss] dhcpv6 duid gen
simon at thekelleys.org.uk
Thu Mar 1 09:59:03 GMT 2012
On 29/02/12 23:07, Vladislav Grishenko wrote:
> Hi, Simon
> Currenly 2.60 uses first interface and its hw type as (time) link-layer duid
> source with exceptions of loopback and ppp.
> RFC3315 says "The hardware type MUST be a valid hardware type assigned by
> the IANA, as described in RFC 826", which describes only 48bit-long ethernet
> So, if there's any kind non-ethernet interfaces in system, which has first
> index, dnsmasq duid generation is obviously wrong.
> Example - 6to4 tunnel interfaces
> sit0 Link encap:UNSPEC HWaddr
> NOARP MTU:1480 Metric:1
> RX packets:0 errors:0 dropped:0 overruns:0 frame:0
> TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
> collisions:0 txqueuelen:0
> RX bytes:0 (0.0 b) TX bytes:0 (0.0 b)
> So, instead of checking device flags, it's better to check against encap
> type and allow only ether&ieee802, like dhcp6s/wide-dhcpv6 do.
> Allowing to specify from options would be useful too, eg. for multiple
> dnsmasq instances,
> Also, HAVE_BROKEN_RTC has issue, duid length and allocation should be equal
> to maclen+4, not maclen+8, because time bits are not used.
Oops. Thanks. Will fix that.
> Seems it's not a good idea to use LLT duid type now even with RTC machines,
> because if lease file is lost and dnsmasq restarted, it will get new duid
> and will ignore any renew requests completely.
> This leads to a much more longer client renew, possibly authoritative option
> could be used to avoid it, can't say now is it per RFC.
The alternative is to not store the duid in the filesystem and rely 1)
finding the same interface each time if there is more than one and 2)
the MAC address not changing because the ethernet interface was swapped out.
My guess is that the MAC address will change under dnsmasq more often
than the lease file is lost.
More information about the Dnsmasq-discuss