Am 03.06.2018 um 23:20 schrieb Simon Kelley:
> 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.

I fully agree. The problem is that for my case, the RFCs do not offer any 
solution. 
My case is: A machine boots via PXE, fetches an address in the installer 
environment,
deploys the operating system, reboots - and gets no address anymore, since the 
DUID/IAID
will necessarily be different between the temporary installer environment and 
the final runtime environment. 

In short, DHCPv6 is impossible to use (in accordance with thr RFCs) for any 
automated deployment via PXE. 
The only way is to use IPv4 in addition, and trust in the fallbacks, and wait 
for leases to time out. 

So the RFCs are broken for this very common usecase - that's why my statement 
was if dnsmasq is willing to offer a workaround
for the RFCs, which don't cover one of the most common usecases, unless I'm 
missing something. 

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

The other option would be to modify all automated Linux installers (Kickstart / 
Anaconda,
Preseed / Debian Installer) to use type-3 DUIDs. Since right now they appear to 
use dhclient / dhcpce
without any special configuration, that's not the case... 

That would be a way out in accordance with the RFCs, but things would still 
fail if a machine is reinstalled - 
it can't fetch an address when rebooting via PXE, until the old DUID/IAID lease 
from the past life is expired,
which may take days. 

TL;DR: The RFCs did not think about automated machine deployment :-(. 
One needs to violate the RFCs to allow for that in a DHCPv6 environment. 

Cheers,
        Oliver

> 
> 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@lists.thekelleys.org.uk
>>> http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
>>>
>>
>> _______________________________________________
>> Dnsmasq-discuss mailing list
>> Dnsmasq-discuss@lists.thekelleys.org.uk
>> http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
>>
> 
> 
> _______________________________________________
> Dnsmasq-discuss mailing list
> Dnsmasq-discuss@lists.thekelleys.org.uk
> http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
> 


_______________________________________________
Dnsmasq-discuss mailing list
Dnsmasq-discuss@lists.thekelleys.org.uk
http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss

Reply via email to