DHCPv6 PD oddity with client changing prefix size.

[Tim DeNike]

Awesome.  Will do!

On Tue, Aug 15, 2017 at 7:36 AM, Thomas Markwalder <tmark at isc.org> wrote:

> Hello Tim:
>
> 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:
>
> 1. Configured a server to have two PD pools in the same subnet, one /64
> and the other /60,  prefix-length-mode = exact
> 2. Solicits from the same client with prefix length hints of /64 and /60 ,
> are offered leases of /64 and /60, respectively
> (confirming hints are being honored as expected)
> 3. Client solicits a /64, and accepts the offered /64 PD lease
> 4. Client releases /64 PD lease
> 5. Client solicits a /60
> 6. Server offers prior /64 PD lease
>
> (Note prefix value for all solicits was "::")
>
> 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.
>
> We are also planning to change the default prefix-length-mode to "prefer"
> as this is more in line with RFC 8168, as well
> as providing a less-stringent default user experience.
>
> FYI, the issue we did correct in 4.3.6 was this:
>
> "- The server nows checks both the address and length of a prefix
> delegation
>   when attempting to match it to a prefix pool.  This ensures the server
>   responds properly when pool configurations change such that once valid,
>   "in-pool" delegations are now treated as being invalid.  During lease
>   file loading at startup, the server will discard any PD leases that
>   are deemed "out-of-pool" either by address or mis-matched prefix length.
>   Clients seeking to renew or rebind such leases will get a response of
>   No Binding in the case of the former, and the prefix delegation with
>   lifetimes set to zero in the case of the latter. Thanks to Mark Nejedlo
>   at TDS Telecom for reporting this issue.
>   [ISC-Bugs #35378]"
>
>
> Sincerely,
>
> Thomas Markwalder
> ISC Software Engineering
>
>
>
>
>
>
> On 8/14/17 1:53 PM, Tim DeNike wrote:
>
> Running 4.3.5 in an ISP environment.  Delivering prefixes via DHCPv6-PD.
>
> By default we give users a /64 but will allow them to request a /60 or /56.
>
> Everything works fine with the /64s and /60s EXCEPT if a user changes
> prefix lengths.
>
> 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.
>
> 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.
>
> 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".
>
> We do have "prefix-length-mode exact;" set.
>
> Seems like a simple oversight/unintended side effect.
>
> Thoughts?
>
> Tim
>
>
> _______________________________________________
> dhcp-users mailing listdhcp-users at lists.isc.orghttps://lists.isc.org/mailman/listinfo/dhcp-users
>
>
>
> _______________________________________________
> dhcp-users mailing list
> dhcp-users at lists.isc.org
> https://lists.isc.org/mailman/listinfo/dhcp-users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.isc.org/pipermail/dhcp-users/attachments/20170815/ed35fa87/attachment.html>