[Dnsmasq-discuss] dhcpv6 duid gen

[Vladislav Grishenko]

Little additions:

> Allowing to specify from options would be useful too, eg. for multiple
> dnsmasq instances

Per RFC3315 "A DHCP client that generates a DUID-LLT using this (using sort
of time source) mechanism MUST provide an administrative interface that
replaces the existing DUID with a newly-generated DUID-LLT."

> 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.

Not allowed for server, but RECONFIGURE implementation could be handy,
including cases of changing options. 

Best Regards, Vladislav Grishenko


> -----Original Message-----
> From: Vladislav Grishenko [mailto:themiron at mail.ru]
> Sent: Thursday, March 01, 2012 5:07 AM
> To: dnsmasq-discuss at lists.thekelleys.org.uk
> Cc: Simon Kelley (simon at thekelleys.org.uk)
> Subject: dhcpv6 duid gen
> 
> 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