<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<p>Hi Harald, Simon,<br>
</p>
<p>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.</p>
<p>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.<br>
</p>
<div class="moz-cite-prefix">On 9/17/21 13:33, Harald Jensas wrote:<br>
</div>
<blockquote type="cite"
cite="mid:18ce6a6e-3d7e-8db6-03e3-86af820f3606@redhat.com">On
9/16/21 21:32, Petr Menšík wrote:
<br>
<blockquote type="cite">Hi!
<br>
<br>
There is also bug on Red Hat bugzilla [1] for this issue, which
contains
<br>
a bit more comments about it.
<br>
<br>
I would make short summary here. The problem is client on the
same
<br>
machine with the same DUID and mac address requests IPv6. Before
it
<br>
processes Advertisement, it requests IPv6 again, this time with
<br>
different IAID.
<br>
<br>
So there are two different request, the only difference are IAID
and
<br>
requested options set. Now if the second request gets processed
first,
<br>
it assigns lease first. Consider --dhcp-sequential-ip is in use.
<br>
Then first request processes advertisement and attempts to
request the
<br>
same IP.
<br>
Now it would fail.
<br>
<br>
How should it react according to RFC 8415 [2]? In current
situation,
<br>
dnsmasq responds with No address available error. Could it
instead
<br>
respond with different address? How should the server and the
client
<br>
behave, when advertised address is no longer available? Is it
broken on
<br>
both sides?
<br>
</blockquote>
<br>
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:
<br>
"""
<br>
The server MAY assign different addresses and/or delegated
prefixes
<br>
to an IA than those included within the IA of the client's
Request
<br>
message.
<br>
"""
<br>
<br>
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.
<br>
<br>
I tested this with both static and dynamic configuration,
"sequential-ip" enabled, and it seems to work.
<br>
<br>
If I change the 'dhcp-host' entry in the static config to contain
just *one* address, it fails as expected with:
<br>
option: 13 status 2 address unavailable <br>
option: 13 status 2 no addresses available
<br>
<br>
<br>
I tested with the following configurations ...
<br>
<br>
Static config:
<br>
--------------
<br>
log-dhcp
<br>
port=0
<br>
dhcp-range=set:range0,2001::,static,64,10m
<br>
dhcp-host=00:84:ed:01:00:10,tag:dhcpv6,client.localdomain,[2001::20],[2001::21],[2001::22],[2001::23]
<br>
dhcp-sequential-ip
<br>
# dhcpv6s for Client System Architecture Type (61)
<br>
dhcp-match=set:efi6,option6:61,0007
<br>
dhcp-match=set:efi6,option6:61,0009
<br>
dhcp-match=set:efi6,option6:61,0011
<br>
dhcp-option=tag:efi6,option6:bootfile-url,tftp://[2001::2]/shimx64.efi
<br>
<br>
Dynamic config with sequential-ip:
<br>
---------------------------------
<br>
log-dhcp
<br>
port=0
<br>
<br>
dhcp-range=set:range0,2001::10,2001::100,64,10m
<br>
dhcp-sequential-ip
<br>
# dhcpv6s for Client System Architecture Type (61)
<br>
dhcp-match=set:efi6,option6:61,0007
<br>
dhcp-match=set:efi6,option6:61,0009
<br>
dhcp-match=set:efi6,option6:61,0011
<br>
dhcp-option=tag:efi6,option6:bootfile-url,tftp://[2001::2]/shimx64.efi
<br>
<br>
<br>
<br>
Regards,
<br>
Harald
<br>
<br>
[1] <a class="moz-txt-link-freetext" href="https://datatracker.ietf.org/doc/html/rfc8415#section-18.3.2">https://datatracker.ietf.org/doc/html/rfc8415#section-18.3.2</a>
<br>
[2] <a class="moz-txt-link-freetext" href="https://bugzilla.redhat.com/show_bug.cgi?id=1998448#c36">https://bugzilla.redhat.com/show_bug.cgi?id=1998448#c36</a>
<br>
[3] <a class="moz-txt-link-freetext" href="https://bugzilla.redhat.com/show_bug.cgi?id=1998448#c41">https://bugzilla.redhat.com/show_bug.cgi?id=1998448#c41</a><br>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<pre class="moz-quote-pre" wrap="">_______________________________________________
Dnsmasq-discuss mailing list
<a class="moz-txt-link-abbreviated" href="mailto:Dnsmasq-discuss@lists.thekelleys.org.uk">Dnsmasq-discuss@lists.thekelleys.org.uk</a>
<a class="moz-txt-link-freetext" href="https://lists.thekelleys.org.uk/cgi-bin/mailman/listinfo/dnsmasq-discuss">https://lists.thekelleys.org.uk/cgi-bin/mailman/listinfo/dnsmasq-discuss</a>
</pre>
</blockquote>
<pre class="moz-signature" cols="72">--
Petr Menšík
Software Engineer
Red Hat, <a class="moz-txt-link-freetext" href="http://www.redhat.com/">http://www.redhat.com/</a>
email: <a class="moz-txt-link-abbreviated" href="mailto:pemensik@redhat.com">pemensik@redhat.com</a>
PGP: DFCF908DB7C87E8E529925BC4931CA5B6C9FC5CB</pre>
</body>
</html>