<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>