[Dnsmasq-discuss] DHCPv6 with dnsmasq for automated deployments

Simon Kelley simon at thekelleys.org.uk
Sun Jun 3 22:20:17 BST 2018


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 obvious solution is to prioritise MAC address over DUID/IAID and
allocate anyway, but there are at least two reasons why I'm not happy
with that.

First, as I mentioned above getting the MAC address is not always
possible/reliable.

Second, it flat-out violates the relevant RFCs. DHCPv6 is predicated on
clients being identified by DUID/IAID. Allocating the same address to
two different DUID/IAIDs, because of hints from an (unreliable) MAC
address violates the DHCP prime directive: thou shall not give the same
address to two different machines.

Looking at Kevin's logs, the client is flat out buggy. It's using a
type-1 DUID which consists of a time and a MAC address. The reason for
the time is to ensure uniqueness when the DUID is created, but the NAS
seems to be updating it on every reboot. That's just plain wrong. type-1
DUID are meant for devices which have non volatile storage: they
generate the DUID once and store it. If they can't store it (which seems
unlikely for a NAS, but let's give it the benefit of the doubt), they
should use type-3 DUIDs, without the time field. It's all very clear in
RFC 3315, section 9.


TLDR; these clients are violating the RFCs. The only feasible way to
make them behave is for dnsmasq to violate the RFC too, in a way which
may well break stuff badly. I'm not prepared to implement that in dnsmasq.


Cheers,

Simon.



On 27/05/18 18:36, Oliver Freyermuth wrote:
> Am 25.05.2018 um 17:23 schrieb P W:
>> On Fri, May 25, 2018 at 03:34:08PM +0200, Oliver Freyermuth wrote:
>>> Am 25.05.2018 um 15:30 schrieb Kevin Darbyshire-Bryant:
>>>>> On 25 May 2018, at 13:07, Oliver Freyermuth wrote:
>>>>>
>>>>> Dear dnsmasqers,
>>>>>
>>>>> I fear the following is a design issue of DHCPv6, but I wonder if there's a way to overcome it with dnsmasq...
>>>> <snip>
>>>>
>>>> Hi Oliver,
>>>>
>>>> I???ve a similar/same problem when rebooting some QNAP NAS boxen,
>>>> first boot/introduction to dnsmasq and they get both IPv4 & v6
>>>> addresses set to fixed values based on MAC address.  On reboot whilst
>>>> IPv4 is fine, IPv6 is not reallocated to the original address but
>>>> rather a new one.  By curious co-incidence I just started looking
>>>> into this problem today though it has been bugging me for months :-)
>>>> Have tried various combinations of MAC address & DUID.
>>>>
>>>
>>> Dear Kevin, 
>>>
>>> I think it's exactly the same issue. 
>>> Comparing:
>>>> Fri May 25 12:47:13 2018 daemon.info dnsmasq-dhcp[26168]: 5514926 DHCPREQUEST(br-lan) 00:01:00:01:22:9a:b4:43:24:5e:be:0c:bc:ba
>>> with
>>>> Fri May 25 12:59:40 2018 daemon.info dnsmasq-dhcp[26168]: 12603117 DHCPSOLICIT(br-lan) 00:01:00:01:22:9a:b7:2b:24:5e:be:0c:bc:ba
>>> it seems the QNAP NAS box is using a fresh client DUID each reboot... 
>>
>>
>> Patches Welcome
> 
> At the moment, there's sadly too much in my queue to start on another OpenSource project - but I'll look into it once this changes,
> which sadly won't be in the very near future. 
> If anybody else has time at hand, of course I can offer to test a patch (the setup is here). 
> 
> Cheers,
> 	Oliver
> 
>>
>> _______________________________________________
>> Dnsmasq-discuss mailing list
>> Dnsmasq-discuss at lists.thekelleys.org.uk
>> http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
>>
> 
> _______________________________________________
> Dnsmasq-discuss mailing list
> Dnsmasq-discuss at lists.thekelleys.org.uk
> http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
> 




More information about the Dnsmasq-discuss mailing list