Request for new functionality expire-on-release
This relates to Support ticket #21050
The suggestion is that when Kea server receives DHCPRELEASE, instead of immediately deleting the entire lease, we instead expire it immediately. This then leaves it in the database to be handled in the same way as normally expired leases. The reason for this request is so that the configuration for Lease Affinity applies equally to leases that have lapsed (expired without renewal) and those that have actively been given back.
Why? Well, this is because many a device, when rebooted, will issue a DHCPRELEASE. When it returns from reboot, it won't be assigned the same address that it had before (unless it happens to request it specifically, and it also is still available).
Many operators would like to have this happen auto-magically for their CPE devices, without needing to configure the DROP class to ignore DHCPRELEASE packets. The behaviour in the case of using the DROP class is not ideal anyway, as expired lease addresses are available to be used if the pool from which they're drawn becomes exhausted, whereas active leases (whose DHCPRELEASE has been ignored) are not, until they eventually do expire.
It also conforms more solidly with the RFC 2131, to retain for a given period, records of leases that have been recently deleted:
4.3.4 DHCPRELEASE message
Upon receipt of a DHCPRELEASE message, the server marks the network address as not allocated. The server SHOULD retain a record of the client's initialization parameters for possible reuse in response to subsequent requests from the client.
Adding this new option (which should default to 'no' so as not to change our current behaviour) provides Kea administrators with 3 potential outcomes following DHCPRELEASE:
a) Delete the lease after DHCPRELEASE - it will not be available for lease affinity and is returned to the available pool (this is the current default behaviour and is probably desirable in an environment with short lease times, high client turnover rate, and pressure on pool address availability.
b) Use DROP to ignore the DHCPRELEASE in which case the lease naturally expires (or is reissued when the client comes back and matches the unexpired lease before it does expire); there may or may not be expired-leases-processing as well. This is less ideal because ignoring the DHCPRELEASE means that the address cannot be used by another client, even there are no addresses left in the subnet's pools.
c) Use the (as yet non-existent) option to put RELEASEd leases into expired state - at which point whatever is configured for expired-leases-processing applies. It also means that the address can be used by another client if necessary, which is what is supposed to happen with expired leases and lease affinity.
Also RT #20964