[Dnsmasq-discuss] DHCPv6 - network booting 'address in use'

[Harald Jensas]

On 9/15/21 21:22, Geert Stappers via Dnsmasq-discuss wrote:
> On Wed, Sep 15, 2021 at 08:23:47AM +0200, Harald Jensas wrote:
>> On 9/14/21 21:12, Geert Stappers via Dnsmasq-discuss wrote:
>>> On Tue, Sep 14, 2021 at 04:58:10PM +0200, Harald Jensas wrote:
>>>> Hi,
>>>>
>>>> We are seeing an issue whit network booting over DHCPv6 is failing.
>>>> The UEFI firmware is starting two DHCPv6 transactions, with separate IAID's.
>>>> Initially one transactions succeeds, while the other transaction fails
>>>> because the same address (fd42::200) is advertised.
>>>>
>>>> On error, the client tries to recover by restarting the transaction with a
>>>> new SOLICIT, the second address (fd42::201) in the host's range
>>>> [fd42::200/126] is advertised by dnsmasq.
>>>>
>>>> Despite requesting the second address, the dnsmasq is refusing the lease:
>>>> dnsmasq-dhcp: 14744450 nest size: 16 option: 13 status  1 address in use
>>>> dnsmasq-dhcp: 14744450 sent size: 24 option: 13 status  2 no addresses available
>>>
>>> Why the   /126?
>>>
>>
>> When network booting with DHCPv6 different stages in the boot process may
>> not use the same IAID. The /126 reseves a range of IPv6 address to the host,
>> in the case where the previous stage in the chain did not release it's lease
>> allocating a range ensures there are addresses available for the subseqent
>> steps.
> 
> Ah, thanks.  The dnsmasq manual page even states the /126
> 
> (Wild???) idea to get beyond current obstacle: Try  /125
> 

This does not help, it seems dnsmasq continues to offer the first (or 
last) address in the range until the lease is confirmed.

dnsmasq would have to keep track of addresses already advertised, and 
not re-advertise the same address before some period for this to help.

> 
> Other thing to consider:  Make with a network sniffer a libpcap file
> with the capture on DHCPv6, put it on a webserver and share the wget URL.
> It enables more people to see what is going over the wire.
> 

I did a traffic capture, and it turns out the error handling patch my 
colleague tried to add in the client does not quite work as expected. 
Apparently the client caches the initial advertisement, and continues to 
request the initial address instead of the new address offered.

19	73.362476	fe80::2057:f8ff:fedd:fe3b	fe80::284:edff:fe01:10	DHCPv6 
208	Advertise XID: 0x1646c1 CID: 00010001283e92480084ed010010 IAA: 2001::22
22	75.360796	fe80::284:edff:fe01:10	ff02::1:2	DHCPv6	219	Request XID: 
0x1546c1 CID: 00010001283e92480084ed010010 IAA: 2001::23


--
Harald