<html>
  <head>
    <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
  </head>
  <body>
    <p>Hi Simon,</p>
    <p>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.<br>
    </p>
    <div class="moz-cite-prefix">On 9/17/21 21:16, Petr Menšík wrote:<br>
    </div>
    <blockquote type="cite"
      cite="mid:04f78fa5-e5d3-f036-8da4-95d6ea08fac7@redhat.com">
      <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"
          moz-do-not-send="true">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"
          moz-do-not-send="true">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"
          moz-do-not-send="true">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 moz-txt-link-freetext" href="mailto:Dnsmasq-discuss@lists.thekelleys.org.uk" moz-do-not-send="true">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" moz-do-not-send="true">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/" moz-do-not-send="true">http://www.redhat.com/</a>
email: <a class="moz-txt-link-abbreviated moz-txt-link-freetext" href="mailto:pemensik@redhat.com" moz-do-not-send="true">pemensik@redhat.com</a>
PGP: DFCF908DB7C87E8E529925BC4931CA5B6C9FC5CB</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>