[Kea-users] plans to support DHCPLEASEQUERY?

[Tomek Mrugalski]

On 18.01.2016 10:27, bert hubert wrote:
> Are there plans to support DHCPLEASEQUERY (RFC 4388)? I checked the source,
> it does define this option, but I find no actual code to support it. I
> think.
Leasequery is a more complex feature than it looks at the first glance.
What you mentioned is just part of the whole leasequery protocol.
Actually, there are three types of leasequery:

1. "basic" leasequery, where an external entity ("requestor") asks about
a single address or client. This is what most people typically think of
when they say leasequery. That's RFC4388 for DHCPv4 and RFC5007 for DHCPv6.

2. bulk leasequery. This is conducted over TCP and allows quering for
multiple leases. One typical use case is for the relay to ask the server
for all leases associated with a specific relay-id (or have other thing
in common). This may be convenient in various cases, e.g. the relay
rebooted, lost all information and tries to repopulate its internal
state. That's RFC6926 for DHCPv4 and RFC5460 for DHCPv6.

3. active leasequery. A requestor can connect to the server and
"subscribe" to any changes made to the lease database. This may be
useful for lots of different use cases. Two most commonly mentioned are
a management system that gets near real-time feedback from the DHCP
server and another one is a high availability (or failover like)
solution: you have your primary server that feeds all the changes to a
secondary server that's ready to take over if primary becomes
unavailable for whatever reason. This is also done over TCP, but may
also be done over TLS. That's a recent standard (Dec. 2015), so many
people are not even aware of its existence. It's RFC7724 for DHCPv4 and
RFC7653 for DHCPv6.

While you may be interested only in a subset of those features, from the
software development perspective it would be useful if we are prepared
to implement all three eventually, so the architecture should cover them
all. Also, in Kea we try to keep parity between DHCPv4 and DHCPv6, so if
we implement RFC4388, we'll also need to do RFC5007. So it may be
slightly more complex than just responding to DHCPLEASEQUERY packet. :)

> Many large scale operators store user preferences based on customer circuit
> ID or hardware address, things we would love to be able to query from the
> DHCP server.
I would love those large scale operators to come forward and share their
desired use cases. The more details the better. I do understand that
they may not be willing to share them publicly, but it's perfectly fine
to send this kind of information off the list to one of ISC engineers
directly.

> This data then of course also needs to be known (relayed to) the DHCP
> server, does anyone know if Kea will support this?
We have several choices here. We currently do reservations based on MAC
address or DUID, but we have other reservation types in mind: client-id
is almost working, we have plans to implement reservations based on
remote-id soon. Also implementing reservations based on circuit-id is
not that different. Depending on what type of preferences you have in
mind, this type of data could possibly be stored in the reservations
data in the database.

If you chose to store that data in MySQL (available now) or in
PostgreSQL (will be in the next couple months), you can access and
manage (add, query, update, delete) this data using normal SQL tools. We
also plan to design an API for handling reservations via Kea control
channel. The design is planned for Kea 1.1.

If you want to keep this data (user preferences) in some external
repository, you could use hooks. Those hooks could either consult
external database to obtain the necessary information. Or you could do
the other way around - hooks could report the client's status and
details, including client's circuit-id.

Finally, there's an option to wait a bit and use leasequery when it will
become available. It's a bit blurry at the moment when that will happen.
There are couple ways how you could help the situation. Sharing the use
cases helps us better understand how important and essential a given
feature is. The more people say why they need a feature, the more likely
it is that we'll implement it. We do our best to implement the most
requested features first.

Also, there are other options available. Kea is actively looking for
companies that are willing to help ISC fund Kea development. We don't
ask for money for nothing, though. We do offer professional Kea support
in return. We also did a custom development contract in the past and are
will to do it again.

Hope that (and Marcin's answer) addresses your question.

Cheers,
Tomek