On 2024-08-09 19:55, Sten Carlsen wrote:
AFAIK both DHCPD and KEA will keep track of who gets which address and
hand these out each time the device connects again even if the lease
has run out.
I use 30min lease time and even after a couple of months the device
gets the same address. This is standard and now and again someone wants
a new and random address, mostly ISPs that charge for you getting the
same address - semi fixed addressing.
The only thing that will prevent this is if the lease has been handed
out to another device and that will only happen if there are no other
addresses to give out than previously used addresses.
This was the other part of your requirement as I read it.
That's an interesting suggestion! Reading up on how kea deals with
expired leases [1] (nicely documented BTW), I see that I can set
`hold-reclaimed-time` in order for kea to hold onto expired leases for
longer. There is this concept of 'lease affinity' where a client gets
its
old allocation if kea finds an expired lease in its database. There some
caveats according to the docs:
There is no guarantee that lease affinity will work every time; if
a server is running out of addresses, it will reassign expired
addresses to new clients. Also, clients can request specific
addresses and the server tries to honor such requests if possible.
Administrators who want to ensure a client keeps its address, even
after periods of inactivity, should consider using host reservations
or leases with very long lifetimes.
Since it's just a home network, I don't expect clients explicitly
request addresses used by other hosts, and the pool should not be
running out of addresses. So using this in combination with the random
allocator (to reduce the chance kea might select an address for which an
expired lease already exists) might approximate the behavior I desire.
I'll experiment with that.
[1]:
https://kea.readthedocs.io/en/kea-2.6.1/arm/lease-expiration.html#configuring-lease-affinity
Cheers, Wilhelm
--
Best regards
Sten Carlsen
A pessimist is a person that can find a problem for every solution.
On 9 Aug 2024, at 18.37, Francis Dupont <[email protected]> wrote:
There is a long history of specs for stable IPv6 addresses using some
kind of hash (the idea is more interesting for IPv6 because its large
address space even for a link ensure a negligible collision rate).
Regards
Francis Dupont <[email protected]>
PS: the random allocator is really random so responds to different
constraints.
--
ISC funds the development of this software with paid support
subscriptions. Contact us at https://www.isc.org/contact/ for more
information.
To unsubscribe visit https://lists.isc.org/mailman/listinfo/kea-users.
Kea-users mailing list
[email protected]
https://lists.isc.org/mailman/listinfo/kea-users
--
ISC funds the development of this software with paid support subscriptions.
Contact us at https://www.isc.org/contact/ for more information.
To unsubscribe visit https://lists.isc.org/mailman/listinfo/kea-users.
Kea-users mailing list
[email protected]
https://lists.isc.org/mailman/listinfo/kea-users
