[Dnsmasq-discuss] dhcpv6 duid gen

[Vladislav Grishenko]

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
addresses.
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
00-00-00-00-00-00-4D-62-00-00-00-00-00-00-00-00
          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.
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.

Best Regards, Vladislav Grishenko