DHCPv6 PD oddity with client changing prefix size.

[Thomas Markwalder]

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 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/a504e2d5/attachment.html>