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

Thu Jan 27 13:34:19 UTC 2022

Hi Simon,

I would like to re-post previous patches updating dhcpv6 address
conflict. It helps network booting many machines at similar time on ipv6
network. Just first patch has functional change, other are simple
improvements.

On 9/17/21 21:16, Petr Menšík wrote:
>
> Hi Harald, Simon,
>
> I made an alternative change, which I think has similar output. I
> think the use of DHCP6UNSPEC is suspicious itself and does not have
> any good error code assigned by RFC 8415, because it should not result
> in an error. I have tried to add also MUST require from the RFC,
> refusing off-link requests with NotOnLink error. Not yet tested it
> myself, I have no IPv6 booting environment available (yet). That is in
> patch1.
>
> Patch2 is just bunch of const changes, reduction of repeated status
> code filling into dedicated function. Should not change behaviour,
> just reduces few lines and some cosmetic changes.
>
> On 9/17/21 13:33, Harald Jensas wrote:
>> On 9/16/21 21:32, Petr Menšík wrote:
>>> Hi!
>>>
>>> There is also bug on Red Hat bugzilla [1] for this issue, which
>>> contains
>>> a bit more comments about it.
>>>
>>> I would make short summary here. The problem is client on the same
>>> machine with the same DUID and mac address requests IPv6. Before it
>>> processes Advertisement, it requests IPv6 again, this time with
>>> different IAID.
>>>
>>> So there are two different request, the only difference are IAID and
>>> requested options set. Now if the second request gets processed first,
>>> it assigns lease first. Consider --dhcp-sequential-ip is in use.
>>> Then first request processes advertisement and attempts to request the
>>> same IP.
>>> Now it would fail.
>>>
>>> How should it react according to RFC 8415 [2]? In current situation,
>>> dnsmasq responds with No address available error. Could it instead
>>> respond with different address? How should the server and the client
>>> behave, when advertised address is no longer available? Is it broken on
>>> both sides?
>>
>> I think Petr may be on to something with "Could it instead respond
>> with a different address?". It seems this is ok based on rfc8415
>> 18.3.2 [1] which states the following:
>> """
>>    The server MAY assign different addresses and/or delegated prefixes
>>    to an IA than those included within the IA of the client's Request
>>    message.
>> """
>>
>> With the below patch I got dnsmasq to reply with a new address to the
>> request with the already leased address. This makes dnsmasq behave
>> similar to kea-dhcp6, see Bugzilla comments #36 and #41 [2][3] which
>> also contain a pcap files.
>>
>> I tested this with both static and dynamic configuration,
>> "sequential-ip" enabled, and it seems to work.
>>
>> If I change the 'dhcp-host' entry in the static config to contain
>> just *one* address, it fails as expected with:
>>   option: 13 status  2 address unavailable
>>   option: 13 status  2 no addresses available
>>
>>
>> I tested with the following configurations ...
>>
>> Static config:
>> --------------
>> log-dhcp
>> port=0
>> dhcp-range=set:range0,2001::,static,64,10m
>> dhcp-host=00:84:ed:01:00:10,tag:dhcpv6,client.localdomain,[2001::20],[2001::21],[2001::22],[2001::23]
>>
>> dhcp-sequential-ip
>> # dhcpv6s for Client System Architecture Type (61)
>> dhcp-match=set:efi6,option6:61,0007
>> dhcp-match=set:efi6,option6:61,0009
>> dhcp-match=set:efi6,option6:61,0011
>> dhcp-option=tag:efi6,option6:bootfile-url,tftp://[2001::2]/shimx64.efi
>>
>> Dynamic config with sequential-ip:
>> ---------------------------------
>> log-dhcp
>> port=0
>>
>> dhcp-range=set:range0,2001::10,2001::100,64,10m
>> dhcp-sequential-ip
>> # dhcpv6s for Client System Architecture Type (61)
>> dhcp-match=set:efi6,option6:61,0007
>> dhcp-match=set:efi6,option6:61,0009
>> dhcp-match=set:efi6,option6:61,0011
>> dhcp-option=tag:efi6,option6:bootfile-url,tftp://[2001::2]/shimx64.efi
>>
>>
>>
>> Regards,
>> Harald
>>
>> [1] https://datatracker.ietf.org/doc/html/rfc8415#section-18.3.2
>> [2] https://bugzilla.redhat.com/show_bug.cgi?id=1998448#c36
>> [3] https://bugzilla.redhat.com/show_bug.cgi?id=1998448#c41
>>
>> _______________________________________________
>> Dnsmasq-discuss mailing list
>> Dnsmasq-discuss at lists.thekelleys.org.uk
>> https://lists.thekelleys.org.uk/cgi-bin/mailman/listinfo/dnsmasq-discuss
> -- 
> Petr Menšík
> Software Engineer
> Red Hat, http://www.redhat.com/
> email: pemensik at redhat.com
> PGP: DFCF908DB7C87E8E529925BC4931CA5B6C9FC5CB

-- 
Petr Menšík
Software Engineer
Red Hat, http://www.redhat.com/
email: pemensik at redhat.com
PGP: DFCF908DB7C87E8E529925BC4931CA5B6C9FC5CB
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.thekelleys.org.uk/pipermail/dnsmasq-discuss/attachments/20220127/427fda6f/attachment-0001.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0003-Add-support-for-option6-names-of-RFC-5970.patch
Type: text/x-patch
Size: 937 bytes
Desc: not available
URL: <http://lists.thekelleys.org.uk/pipermail/dnsmasq-discuss/attachments/20220127/427fda6f/attachment-0003.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0002-Move-dhcp6-status-code-to-subroutine-add-consts.patch
Type: text/x-patch
Size: 12949 bytes
Desc: not available
URL: <http://lists.thekelleys.org.uk/pipermail/dnsmasq-discuss/attachments/20220127/427fda6f/attachment-0004.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-Offer-alternative-DHCPv6-address-if-requested-is-tak.patch
Type: text/x-patch
Size: 3846 bytes
Desc: not available
URL: <http://lists.thekelleys.org.uk/pipermail/dnsmasq-discuss/attachments/20220127/427fda6f/attachment-0005.bin>