[Dnsmasq-discuss] dhcpv6 duid gen

Simon Kelley simon at thekelleys.org.uk
Thu Mar 1 09:50:19 GMT 2012


On 01/03/12 09:39, Jan Seiffert wrote:
> 2012/3/1 Vladislav Grishenko<themiron at mail.ru>:
>> 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.
>
> Hold it, there is IEEE1394, a.k.a Firewire missing.
> RFC3164
> Firewire is the "only" transport with a  EUI-64 instead of the classic
> Mac-Adress with 48 bits.
>

... and then there's all the people doing IPv6 over their legacy 
token-ring networks :-)

Actually, there are lots:
http://www.iana.org/assignments/arp-parameters/arp-parameters.xml


My reading of "The hardware type MUST be a valid hardware type assigned 
by the IANA, as described in RFC 826" is that RFC826 describes the 
assignment process, and hardware types assigned since RFC826 was 
published are included.

Simon.



More information about the Dnsmasq-discuss mailing list