Kea issueshttps://gitlab.isc.org/isc-projects/kea/-/issues2024-03-27T12:56:42Zhttps://gitlab.isc.org/isc-projects/kea/-/issues/2979RAI based flex-id reservations2024-03-27T12:56:42ZPeter DaviesRAI based flex-id reservationsRAI based flex-id reservations:
When providing dhcp services for customer equipment, maintaining a consistent IP
address is often desired even when customers replace their equipment.
Host reservations may be defined using a ...RAI based flex-id reservations:
When providing dhcp services for customer equipment, maintaining a consistent IP
address is often desired even when customers replace their equipment.
Host reservations may be defined using a flex-id host identifier based on some
RAI options; however, the lease data will typically contain the hw-address as
the identifier.
This works well until the customer replaces his equipment and there is an active
lease on the reserved address with the old client's hw-address. In this case,
Kea will regard this as an address conflict.
Enabling the "replace-client-id" flex-id flag can mitigate this; however, changing
the value of this flag on a running Kea server will cause address conflicts.
Is there a way to address this problem?
[RT #20140](https://support.isc.org/Ticket/Display.html?id=20140)kea2.5.8https://gitlab.isc.org/isc-projects/kea/-/issues/2976Implement the ISC DHCP stash-agent-options in Kea2024-03-27T12:56:52ZFrancis DupontImplement the ISC DHCP stash-agent-options in KeaSee #218 for details but the idea is to handle v4 renew/rebind queries as they went thought a relay. As far as I can remember the idea is to use the hint (requested or client address) from the query to look up the lease and extract the R...See #218 for details but the idea is to handle v4 renew/rebind queries as they went thought a relay. As far as I can remember the idea is to use the hint (requested or client address) from the query to look up the lease and extract the RAI from its user context. Requires some design but on the paper this should do the job...
Note this is for v4 only because v6 requires a specific setup on both the client and the server for direct unicast queries so the problem never occurs in the real world.kea2.5.8https://gitlab.isc.org/isc-projects/kea/-/issues/1339calling expired can cause races2023-07-31T13:13:53ZRazvan Becheriucalling expired can cause racesas @fdupont mentioned, calling expire can cause races within the kea code:
```
lease->expired() // false here
...
// some time passes
lease->expired() // true here
```as @fdupont mentioned, calling expire can cause races within the kea code:
```
lease->expired() // false here
...
// some time passes
lease->expired() // true here
```next-stable-2.6Razvan BecheriuRazvan Becheriuhttps://gitlab.isc.org/isc-projects/kea/-/issues/3144redetect-interfaces command2024-02-08T14:35:31ZTomek Mrugalskiredetect-interfaces commandThe idea is to tell Kea to redetect network interfaces. There's `re-detect` flag in `interfaces-config` that can be used in `config-set`. But this requires a general heavy-weight reconfiguration of the whole server.
The idea here is tha...The idea is to tell Kea to redetect network interfaces. There's `re-detect` flag in `interfaces-config` that can be used in `config-set`. But this requires a general heavy-weight reconfiguration of the whole server.
The idea here is that Kea could be told that some new interfaces appeared or disappeared (VLAN, PPP, some other tunnel etc.) and Kea should redetect them. For an added bonus, there should be a way to tell Kea to open sockets on those new interfaces. This can be done either by telling Kea to open the on any newly detected interfaces or perhaps return a list of interfaces and have a dedicated call `open-socket` or something similar? Anyway, this would be useful to have a mini-design for.
This problem is not new and there are many requests in this problem space:
- A [nicely described use case in #3040](https://gitlab.isc.org/isc-projects/kea/-/issues/3040#note_414899)
- #1084
- #3062
- possibly couple morenext-stable-2.6https://gitlab.isc.org/isc-projects/kea/-/issues/2943strict check for prefix and prefix length for ipv6 PDs in lease and host cons...2023-07-01T15:01:21ZRazvan Becheriustrict check for prefix and prefix length for ipv6 PDs in lease and host constructorsThe safest way to make sure Kea internally does not construct a PD lease with invalid prefix and prefix length is to add the check in lease and host constructors.
Currently (after the merge of #2725) the possibility to send invalid PD l...The safest way to make sure Kea internally does not construct a PD lease with invalid prefix and prefix length is to add the check in lease and host constructors.
Currently (after the merge of #2725) the possibility to send invalid PD leases to clients comes from the database (either lease or host) which are maintained consistent when using KEA API, but the user can always add entries using database CLI and the data will reach the clients unchecked.
This proposal is robust and simple.
If some flexibility is needed in UTs, a 'test' flag can be set in a static/global variable which can disable these checks.next-stable-2.6https://gitlab.isc.org/isc-projects/kea/-/issues/2763Lease start time of state2023-04-28T07:24:29ZFrancis DupontLease start time of stateBoth v4 Bulk Leasequery (BLQ) and RADIUS accounting have use of keeping the start time of state for assigned leases i.e. the date of the transistion to the default (0) state. This ticket proposes to keep it in the user context, the RADIU...Both v4 Bulk Leasequery (BLQ) and RADIUS accounting have use of keeping the start time of state for assigned leases i.e. the date of the transistion to the default (0) state. This ticket proposes to keep it in the user context, the RADIUS table keeping it can be reused for the design.next-stable-2.6https://gitlab.isc.org/isc-projects/kea/-/issues/2714RFE: HA plugin ability to detect partner inabilty to receive client requests ...2023-07-31T14:12:57ZKevin FlemingRFE: HA plugin ability to detect partner inabilty to receive client requests and transition it to 'partner-down'---
name: Feature request
about: HA plugin ability to detect partner inabilty to receive client requests and transition it to 'partner-down'
---
**Some initial questions**
- Are you sure your feature is not already implemented in the l...---
name: Feature request
about: HA plugin ability to detect partner inabilty to receive client requests and transition it to 'partner-down'
---
**Some initial questions**
- Are you sure your feature is not already implemented in the latest Kea version? Yes
- Are you sure what you would like to do is not possible using some other mechanisms? Yes
- Have you discussed your idea on kea-users or kea-dev mailing lists? Yes
**Is your feature request related to a problem? Please describe.**
(This issue was created as a result of an extensive thread on kea-users)
When the HA plugin is being used in either hot-standby or load-balancing mode, Kea peers are able to notice some forms of communications failures and force the other peers to the 'partner-down' state in order to provide service to clients supported by the other peer.
However, in a situation where client requests are not being delivered to a peer, but it is otherwise fully operational including the peer-to-peer communications link, clients supported by that peer will not be serviced, but the other peer(s) care unable to notice the issue and take action to correct it. This situation could arise when the Kea peers are using separate network links for client traffic and HA traffic, or when the Kea peers are receiving client traffic via a DHCP relay and the relay configuration is incorrect.
**Describe the solution you'd like**
One (or more) opt-in mechanisms that the Kea admin can choose to enhance the ability to detect peer failures to service clients, even when the peer's Kea daemon is otherwise fully operational.
**Describe alternatives you've considered**
Some discussions about external monitoring solutions have occurred, and that is certainly an option which some admins could choose.
**Funding its development**
Kea is run by ISC, which is a small non-profit organization without any government funding or any permanent sponsorship organizations. Are you able and willing to participate financially in the development costs? Yes
**Participating in development**
Are you willing to participate in the feature development? ISC team always tries to make a feature as generic as possible, so it can be used in wide variety of situations. That means the proposed solution may be a bit different that you initially thought. Are you willing to take part in the design discussions? Are you willing to test an unreleased engineering code? Yesnext-stable-2.6https://gitlab.isc.org/isc-projects/kea/-/issues/2529patching query options core hook2023-08-10T13:23:02ZFrancis Dupontpatching query options core hookThe idea is to clone the flex option core hook into a similar hook patching the query vs the response. It should be simpler (no client class) and will solve a lot of customer problems including the RAI link selector one.
The only not ea...The idea is to clone the flex option core hook into a similar hook patching the query vs the response. It should be simpler (no client class) and will solve a lot of customer problems including the RAI link selector one.
The only not easy point (code and doc can be reused at a very high level) is to pick a name for it!next-stable-2.6https://gitlab.isc.org/isc-projects/kea/-/issues/878performance: implement backend statistics2023-07-31T13:02:12ZTomek Mrugalskiperformance: implement backend statisticsWe want to be able to measure the following:
* looking for reservations took X us,
* looking for leases took Y us.
* Z queries per packet were conducted.
* W total queries performed by backend, average response time was A.
* possibly st...We want to be able to measure the following:
* looking for reservations took X us,
* looking for leases took Y us.
* Z queries per packet were conducted.
* W total queries performed by backend, average response time was A.
* possibly stats by query type (getLease4byHWAddr, getLease4ByAddr, etc.)
* possibly query by SQL type (A number of SELECTs, B number of INSERTs, C number of DELETEs)
This, on its own, wouldn't improve any performance, but it will be an essential tool for assessing other performance improvement proposals.next-stable-2.6https://gitlab.isc.org/isc-projects/kea/-/issues/2499don't extend dhcpdb_create scripts any more2024-03-27T13:32:29ZWlodzimierz Wenceldon't extend dhcpdb_create scripts any moreWe should stop to make two paths of database creation. It leads to mistakes more work during releases additional jobs to check differences. So rather to develop scripts like `dhcpdb_create.mysql` (`dhcpdb_create.pgsql`) and upgrade scrip...We should stop to make two paths of database creation. It leads to mistakes more work during releases additional jobs to check differences. So rather to develop scripts like `dhcpdb_create.mysql` (`dhcpdb_create.pgsql`) and upgrade scripts (eg. upgrade_009_to_010.sh.in) separately we should develop just upgrade scripts which will be executed by dhcpdb_create.sh script.
It's ugly to do it this late in a process but it will make our life much easier in the future.
- [ ] as part of the refactor process, please make sure there's a VERY good reason why there's .in version that needs to be expanded during configure.next-stable-3.0https://gitlab.isc.org/isc-projects/kea/-/issues/1623Config Backend migration tool2024-03-21T12:22:05ZCathy AlmondConfig Backend migration tool---
name: Control block/configuration migration tool
about: Similar to #1078, this is a request for tools to assist Kea users who decide to change their back-end provisioning - in this instance, their configuration. This should (ideally...---
name: Control block/configuration migration tool
about: Similar to #1078, this is a request for tools to assist Kea users who decide to change their back-end provisioning - in this instance, their configuration. This should (ideally) cater for all scenarios, so not just changing which DB backend is being used, but also migration from not-CB to CB and vice versa
---
I don't think anyone else has opened this yet - but if we do tackle this, it would be worth bearing in mind that configuration/CB backend version control or logging might also turn out to be A Thing - so we need to consider that use case/evolution in the design too.
**Is your feature request related to a problem? **
See [Support ticket #17332](https://support.isc.org/Ticket/Display.html?id=17332) for details of which customer for whom this would be useful.
The likelihood is that they will wish to implement CB backend on the DB backend on which it's available now, but migrate to their preferred DB backend, once there is CB support there too (as well as complete coverage of all configuration options in the CB - at the moment there isn't).
**Update**: As discussed in [Porto](https://pad.isc.org/p/porto2022-stork-roadmap-and-backlog#L31), we'd like to make more generic. While the ultimate solution will likely cover Stork overseeing the migration, some parts of the functionality should be implemented in Kea. In particular, the following was discussed:
- `config-get`/`config-set` like commands that would retrieve/set the full configuration from CB
Once the above is implemented, it will open up plenty of opportunities for Stork. In particular, scenarios such as: "add subnets defined in a config file to CB, delete subents from config file, write updated config file to disk". The same can be repeated for other configuration elements (shared networks, classes, HR, etc).next-stable-3.0https://gitlab.isc.org/isc-projects/kea/-/issues/1463Performance improvement: lookup leases by address first when address is avail...2023-07-31T13:14:28ZAndrei Pavelandrei@isc.orgPerformance improvement: lookup leases by address first when address is availableEdit: TLDR: This issue is about looking up leases by address hint in renews and v6 requests. Currently, they are first searched by DUID/client ID. Because these are not primary keys, but indexes, this lookup is slower. Searching by addre...Edit: TLDR: This issue is about looking up leases by address hint in renews and v6 requests. Currently, they are first searched by DUID/client ID. Because these are not primary keys, but indexes, this lookup is slower. Searching by address which is a primary key should be significantly faster. I imagine this as a few lines of code changed, although it is affecting the allocation engine. There are concerns that this might affect host reservations, RADIUS or other aspects. I expect that to come up in tests.
---
When designing database scehmas, it is desirable to look at access patterns in order to define keys or indexes or maybe entire table definitions. When looking at the DHCP protocol, we can easily figure out that the key that we most want to use in a lookup is the client's identifier which is usually the DUID or client ID. This is not the case for current Kea since address is clearly chosen as sole primary key across all backends for the lease databases. This is probably because it is chosen based on it's unique properties. A v6 client can have multiple addresses per DUID and maybe it's the same for v4 in same strange use cases. This could have been solved by storing addresses as a list in DUID/clientID-keyed tables at the cost of complexity. But that is not my proposal.
We can leverage the current table structure by looking up by address when possible. This is effectively the case when an address hint is provided. A well known case when this happens is during the renew process, but I think I remember reading from a RFC that it can be provided in other DHCP messages as well. But a well-behaved client should (RFC SHOULD?) always send the address in their RENEW (I think it's still called REQUEST for DHCPv4?) and RENEWs are 99% of the DHCP messages sent in networks with high uptime. So it is an optimization for RENEW.
Concerns:
* Security? Honoring DHCP clients requesting address directly might lead to address starvation?
* No, after lookup by address finds nothing, the usual DISCOVER & SOLICIT messages go through with looking up by DUID/clientID. And then it will find the lease that belonged to the malicious client. Even if it did, add that to the list of security issues. Clients spoofing their DUID/clientID doesn't do the same?
* Are we sure we aren't providing the address to the wrong client?
* Yes. We can check in-memory/in-server if the DUIDs/clientIDs match. Even though what harm can the right lease given to the wrong client do?
* Does this affect the ability to reserve addresses/prefixes, RADIUS, hooks or other use-cases?
* To be investigated. I don't know. Because firstly I don't understand why host reservations are looked up before leases. This optimization is less impactful if we still search by DUID/clientID in hosts first. I would move the address lookup in the lease database at the beginning of the packet processing. But then why not move the DUID/clientID lookup at the beginning as well? If the client has an active lease, doesn't it stop there?backloghttps://gitlab.isc.org/isc-projects/kea/-/issues/2996implement draft-ietf-dhc-addr-notification2023-11-10T11:53:16ZVicky Riskvicky@isc.orgimplement draft-ietf-dhc-addr-notificationImplement https://datatracker.ietf.org/doc/draft-ietf-dhc-addr-notification/, once there is a client implementation to test with, possibly Android from Google.
Also known as "Registering Self-generated IPv6 Addresses using DHCPv6" this...Implement https://datatracker.ietf.org/doc/draft-ietf-dhc-addr-notification/, once there is a client implementation to test with, possibly Android from Google.
Also known as "Registering Self-generated IPv6 Addresses using DHCPv6" this draft implements a message from the DHCPv6 client to a DHCPv6 server to log the address the client is using. This enables the server administrator to better troubleshoot issues related to DHCP, because there is a centralized record of addresses associated with the clients using them.
The requirements in the draft include accepting the registration message from the client, returning an appropriately formed acknowledgement, logging a lease in the lease db, and retiring the address after the preferred lifetime has elapsed without a refresh.
[ [ After receiving this ADDR-REG-INFORM message, the address
registration server SHOULD verify that the address being registered
is "appropriate to the link" as defined by [RFC8415]. If the server
believes that address being registered is not appropriate to the
link [RFC8415], it MUST drop the message, and SHOULD log this fact.
If the address is appropriate, the server:
- [ ] SHOULD register or update a binding between the provided Client
Identifier and IPv6 address in its database;
- [ ] SHOULD log the address registration information (as is done
normally for clients which have requested an address), unless
configured not to do so;
- [ ] SHOULD mark the address as unavailable for use and not include it
in future ADVERTISE messages.
- [ ] SHOULD send back an ADDR-REG-REPLY message.
- [ ] If the address registration server does not receive such a refresh
after the preferred lifetime has passed, it SHOULD remove the record
of the Client-Identifier-to-IPv6-address binding.
There aren't any specific requirements in the draft about how to facilitate finding or monitoring these 'leases' so that is all implementation-specific. We might want to log receipt of these messages, if we can't mark the leases to indicate it was reported by the client, rather than a 'regular' dynamic lease from the DHCPv6 server.
- consider some indication on the lease record that this is self-assigned that would facilitate filtering and locating just this kind of lease records
- consider some log message indicating this was a self-assigned address reported by the clientbackloghttps://gitlab.isc.org/isc-projects/kea/-/issues/2897Cross-check - server should check its HA partner config2023-06-15T13:50:50ZTomek MrugalskiCross-check - server should check its HA partner configHere's an idea for new HA capability. On startup (or when explicit command is called), the server retrieves its partner configuration with `config-get` and checks it for consistency: if the subnets and pools are defined the same way, if ...Here's an idea for new HA capability. On startup (or when explicit command is called), the server retrieves its partner configuration with `config-get` and checks it for consistency: if the subnets and pools are defined the same way, if the subnet-ids match etc.
Right now the doc says those should be the same, with the only difference being server-name, but we don't check it.
What to do with spotted differences is to be determined. We could print a warning, refuse HA connection, shutdown, or even maybe the primary attempt to fix its partner's config.
This is merely an idea. If we like it, the first step would be to turn this into more coherent design. Hence the ~design.backloghttps://gitlab.isc.org/isc-projects/kea/-/issues/2271Extend the infinite lifetime feature to full DHCP2022-11-02T15:10:41ZFrancis DupontExtend the infinite lifetime feature to full DHCPFollowup of #897 which uses infinite lifetime only for BOOTP.
Already discussed design points:
- skip Cassandra/CQL support
- add a new lease state to make static/sticky leases independent of the real lifetime
- by default static/sti...Followup of #897 which uses infinite lifetime only for BOOTP.
Already discussed design points:
- skip Cassandra/CQL support
- add a new lease state to make static/sticky leases independent of the real lifetime
- by default static/sticky leases can't be released
- add new config flags to allow infinite lifetimesbackloghttps://gitlab.isc.org/isc-projects/kea/-/issues/1801Durable DDNS update queue (Persistence Manager for D2)2023-06-08T19:48:37ZVicky Riskvicky@isc.orgDurable DDNS update queue (Persistence Manager for D2)**Problem**
The DDNS update queue in the D2 process is not durable and queued requests may be lost if the process is stopped or crashes. The retry mechanism is non configurable, making two more attempts 100ms apart if the target DNS ser...**Problem**
The DDNS update queue in the D2 process is not durable and queued requests may be lost if the process is stopped or crashes. The retry mechanism is non configurable, making two more attempts 100ms apart if the target DNS server cannot be reached.
**Desired Solution**
- [ ] A durable queue persists pending updates between restarts and crashes.
- [ ] A new configuration parameter is used to set the number of seconds that the D2 process waits for a response before retrying the DNS update.
- [ ] An additional configuration parameter is used to limit the number of times that D2 process tries to send the DNS update.
This may be covered in the design of a Persistence Manager in [this wiki document](https://gitlab.isc.org/isc-projects/kea/-/wikis/designs/ddns-design#addendum-persistencemgr-design-point8).backloghttps://gitlab.isc.org/isc-projects/kea/-/issues/1746multiple contact points for MySQL and PostgreSQL2023-04-06T12:02:31ZAndrei Pavelandrei@isc.orgmultiple contact points for MySQL and PostgreSQLFor the purpose of highly-available database connectivity, eliminating single point of failures in cluster nodes, and benefitting from Galera and Percona's active-active responsiveness, Kea could use the ability to specify multiple conta...For the purpose of highly-available database connectivity, eliminating single point of failures in cluster nodes, and benefitting from Galera and Percona's active-active responsiveness, Kea could use the ability to specify multiple contact points in the same database access set.
Ideally, it would be less work if you could pass the responsibility of shuffling through the nodes onto the database library, like in Cassandra.
But if this is not an option, to avoid contention on selecting the connection to be used, a connection could be randomly chosen by each thread.
Design document: TODObackloghttps://gitlab.isc.org/isc-projects/kea/-/issues/1739Implement FORCERENEW support (RFC3203)2022-11-02T17:06:58ZTomek MrugalskiImplement FORCERENEW support (RFC3203)This is roughly a v4 equivalent of RECONFIGURE message in v6. This is not a popular feature (due to lack of support among clients), but it is being requested sporadically.
* [asking about forcerenew on kea-users](https://lists.isc.org/p...This is roughly a v4 equivalent of RECONFIGURE message in v6. This is not a popular feature (due to lack of support among clients), but it is being requested sporadically.
* [asking about forcerenew on kea-users](https://lists.isc.org/pipermail/kea-users/2020-October/002910.html)
* [another one from 2017](http://kea-users.7364.n8.nabble.com/Kea-users-FORCERENEW-feature-td435.html)backloghttps://gitlab.isc.org/isc-projects/kea/-/issues/321Make it possible to start the server without all the configured interfaces re...2024-02-08T14:36:54ZVicky Riskvicky@isc.orgMake it possible to start the server without all the configured interfaces ready (GH#91)<Originally reported on Github as issue #91 by karaluh on July 6, 2018>
Dibbler has an "inactive-mode" option, which works like this, according to the official docs:
During normal startup, client tries to bind all interfaces defined in...<Originally reported on Github as issue #91 by karaluh on July 6, 2018>
Dibbler has an "inactive-mode" option, which works like this, according to the official docs:
During normal startup, client tries to bind all interfaces defined in a configuration file. If such attempt
fails, client reports an error and gives up. Usually that is best action. However, in some cases it is possible that interface is not ready yet, e.g. WLAN interface did not complete association. Dibbler attempt to detect link-local addresses, bind any sockets or initiate any kind of communication will fail. To work around this disadvantage, a new mode has been introduced in the 0.6.0RC4 version. It is possible to modify client behavior, so it will accept downed and not running interfaces. To do so, inactive-mode
keyword must be added to client.conf file. In this mode, client will accept inactive interfaces, will add
them to inactive list and will periodically monitor its state. When the interface finally goes on-line, client
will try to configure it."
My use case is PD over PPP interfaces which come and go as they please during the server process lifetime and mostly aren't there when the server starts.backloghttps://gitlab.isc.org/isc-projects/kea/-/issues/2131revisit and extend D2 update retry code2022-02-25T12:09:25ZFrancis Dupontrevisit and extend D2 update retry codeThe waiting delay between two attempts is not clear and for GSS-TSIG to be able to set the number of retries is requested.
This ticket should stay in the core code. Note the idea to save and restore the NCR queue is not considered here ...The waiting delay between two attempts is not clear and for GSS-TSIG to be able to set the number of retries is requested.
This ticket should stay in the core code. Note the idea to save and restore the NCR queue is not considered here (it has its own ticket #1801).
Opening a design phaseoutstandingFrancis DupontFrancis Dupont