<div dir="ltr">Awesome.  Will do!</div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Aug 15, 2017 at 7:36 AM, Thomas Markwalder <span dir="ltr"><<a href="mailto:tmark@isc.org" target="_blank">tmark@isc.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
  
    
  
  <div text="#000000" bgcolor="#FFFFFF">
    <div class="m_-4187656153960701806moz-cite-prefix">Hello Tim:<br>
      <br>
      I retested your scenario with 4.3.6 which we released on 7/31. 
      While it does contain a correction for one issue with prefix
      delegation it does not address your scenario which I tested as:<br>
      <br>
      1. Configured a server to have two PD pools in the same subnet,
      one /64 and the other /60,  prefix-length-mode = exact<br>
      2. Solicits from the same client with prefix length hints of /64
      and /60 , are offered leases of /64 and /60, respectively<br>
      (confirming hints are being honored as expected)<br>
      3. Client solicits a /64, and accepts the offered /64 PD lease<br>
      4. Client releases /64 PD lease<br>
      5. Client solicits a /60<br>
      6. Server offers prior /64 PD lease<br>
      <br>
      (Note prefix value for all solicits was "::")<br>
      <br>
      If you would be so kind as to open a bug for this, we should be
      able to work it into 4.4.0 which is slated for January '18.<br>
      <br>
      We are also planning to change the default prefix-length-mode to
      "prefer" as this is more in line with RFC 8168, as well<br>
      as providing a less-stringent default user experience.<br>
      <br>
      FYI, the issue we did correct in 4.3.6 was this:<br>
      <br>
      "- The server nows checks both the address and length of a prefix
      delegation<br>
        when attempting to match it to a prefix pool.  This ensures the
      server<br>
        responds properly when pool configurations change such that once
      valid,<br>
        "in-pool" delegations are now treated as being invalid.  During
      lease<br>
        file loading at startup, the server will discard any PD leases
      that<br>
        are deemed "out-of-pool" either by address or mis-matched prefix
      length.<br>
        Clients seeking to renew or rebind such leases will get a
      response of<br>
        No Binding in the case of the former, and the prefix delegation
      with<br>
        lifetimes set to zero in the case of the latter. Thanks to Mark
      Nejedlo<br>
        at TDS Telecom for reporting this issue.<br>
        [ISC-Bugs #35378]"<br>
      <br>
      <br>
      Sincerely,<br>
      <br>
      Thomas Markwalder<br>
      ISC Software Engineering<div><div class="h5"><br>
      <br>
      <br>
      <br>
      <br>
      <br>
      On 8/14/17 1:53 PM, Tim DeNike wrote:<br>
    </div></div></div>
    <blockquote type="cite"><div><div class="h5">
      
      <div dir="ltr">Running 4.3.5 in an ISP environment.  Delivering
        prefixes via DHCPv6-PD.
        <div><br>
        </div>
        <div>By default we give users a /64 but will allow them to
          request a /60 or /56.</div>
        <div><br>
        </div>
        <div>Everything works fine with the /64s and /60s EXCEPT if a
          user changes prefix lengths.</div>
        <div><br>
        </div>
        <div>IE:  User plugs in and enables DHCPv6, they get a /64. 
          They decide they want a /60 so change their prefix hint to /60
          release/renew, they get the same /64 back again.</div>
        <div><br>
        </div>
        <div>The only way to get them to acquire a /60 is to either
          manually remove the /64 lease from the leases file or wait out
          until the default-lease-time has expired.</div>
        <div><br>
        </div>
        <div>Apparently when the client releases the prefix, it is still
          held for them so they can get it back.  No problem with that
          functionality.  Makes sense.  But if the client releases and
          requests a prefix that doesn't have a length that matches the
          previous lease then they should be allocated a prefix from the
          pool that does match based on the rules of
          "prefix-length-mode".</div>
        <div><br>
        </div>
        <div>We do have "prefix-length-mode exact;" set.</div>
        <div><br>
        </div>
        <div>Seems like a simple oversight/unintended side effect.</div>
        <div><br>
        </div>
        <div>Thoughts?</div>
        <div><br>
        </div>
        <div>Tim</div>
      </div>
      <br>
      <fieldset class="m_-4187656153960701806mimeAttachmentHeader"></fieldset>
      <br>
      </div></div><span class=""><pre>______________________________<wbr>_________________
dhcp-users mailing list
<a class="m_-4187656153960701806moz-txt-link-abbreviated" href="mailto:dhcp-users@lists.isc.org" target="_blank">dhcp-users@lists.isc.org</a>
<a class="m_-4187656153960701806moz-txt-link-freetext" href="https://lists.isc.org/mailman/listinfo/dhcp-users" target="_blank">https://lists.isc.org/mailman/<wbr>listinfo/dhcp-users</a></pre>
    </span></blockquote>
    <p><br>
    </p>
  </div>

<br>______________________________<wbr>_________________<br>
dhcp-users mailing list<br>
<a href="mailto:dhcp-users@lists.isc.org">dhcp-users@lists.isc.org</a><br>
<a href="https://lists.isc.org/mailman/listinfo/dhcp-users" rel="noreferrer" target="_blank">https://lists.isc.org/mailman/<wbr>listinfo/dhcp-users</a><br></blockquote></div><br></div>