[kea-dev] Decline support requirements in Kea 1.0

Francis Dupont fdupont at isc.org
Thu Jun 25 18:19:18 UTC 2015


I have implemented a temporary state in the host (reservation) class,
it can be used for decline (I use it for secure DHCPv6 to store two
timestamps). This state is mutable (the setter is declared const)
and its extend/lifetime is the same than the host object, i.e.,
it is reset at restart or config reload. IMHO it is perfect for
keeping the (transient) fact an address is already in use.

Regards

Francis Dupont <fdupont at isc.org>

PS: from memory: #3915

Tomek Mrugalski writes:
> All,
> 
> Here's another requirements documents written as a preparation for Kea
> 1.0. This one covers DECLINE messages support:
> 
> http://kea.isc.org/wiki/DeclineRequirements
> 
> There is one topic that's not covered by the requirements yet: how to
> handle declined addresses in the host reservation context. One
> reasonable approach is to maintain consistency with what is already
> coded. Right now when the server discovers that the reserved address is
> used by someone else (there's a lease for someone else), it treats the
> reservation as unusable, prints a warning and continues as if there were
> no reservation. I'd like to handle the decline case in similar way.
> I'm not sure if that requires to be codified in the requirements page,
> though.
> 
> Similar to lease expiration discussion, we want to close this discussion
> by end of July.
> 
> Comments? Thoughts? Tomatoes?
> 
> Tomek
> 
> _______________________________________________
> kea-dev mailing list
> kea-dev at lists.isc.org
> https://lists.isc.org/mailman/listinfo/kea-dev
> 


More information about the kea-dev mailing list