content-type: text/plain; charset="utf-8" X-RT-Original-Encoding: utf-8 Content-Length: 1862 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. 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.