Kea issueshttps://gitlab.isc.org/isc-projects/kea/-/issues2022-02-25T12:09:25Zhttps://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 Duponthttps://gitlab.isc.org/isc-projects/kea/-/issues/1345Ability to always-respond to all requests in HA active-active mode to support...2021-01-22T13:30:51ZEwald van GeffenAbility to always-respond to all requests in HA active-active mode to support anycast DHCPMy impression is that ISC KEA doesn't always respond to all requests. I think this is due to the 1/n split.
I run two KEA instances sharing a single BGP anycast /32 IP prefix. DHCP Requests get routed via a DHCP relay towards the closes...My impression is that ISC KEA doesn't always respond to all requests. I think this is due to the 1/n split.
I run two KEA instances sharing a single BGP anycast /32 IP prefix. DHCP Requests get routed via a DHCP relay towards the closest ISC KEA instance according to BGP. Load balancing is externally handled. This means KEA should respond to all requests it receives and not impose any load-balancing logic.
I think this is where the magic happens [1]
From my understanding active_servers needs to reflect the current server instance id (pri,sec).
[1] https://github.com/isc-projects/kea/blob/457111f9db051723ff9f8e7fb621872d0aa10363/src/hooks/dhcp/high_availability/query_filter.cc#L316outstandinghttps://gitlab.isc.org/isc-projects/kea/-/issues/237ISC DHCP per class lease limit2023-07-13T18:35:36ZFrancis DupontISC DHCP per class lease limitQuote from ISC DHCP 1dhcpd.conf.5`
>>>
PER-CLASS LIMITS ON DYNAMIC ADDRESS ALLOCATION
You may specify a limit to the number of clients in a class that can be
assigned leases. The effect of this will be to make it difficul...Quote from ISC DHCP 1dhcpd.conf.5`
>>>
PER-CLASS LIMITS ON DYNAMIC ADDRESS ALLOCATION
You may specify a limit to the number of clients in a class that can be
assigned leases. The effect of this will be to make it difficult for a
new client in a class to get an address. Once a class with such a
limit has reached its limit, the only way a new client in that class
can get a lease is for an existing client to relinquish its lease,
either by letting it expire, or by sending a DHCPRELEASE packet.
Classes with lease limits are specified as follows:
class "limited-1" {
lease limit 4;
}
This will produce a class in which a maximum of four members may hold a
lease at one time.
>>>
Often associated with cloned classes. Requested by a customer but a priori not easy to implement.
Note that in Kea lease assignment is done before calling setReservedClientClasses.
Support tickets: [support#18293](https://support.isc.org/Ticket/Display.html?id=18293), [support#17523](https://support.isc.org/Ticket/Display.html?id=17523), [support#19968](https://support.isc.org/Ticket/Display.html?id=19968)
Being implemented in Kea.ISC DHCP Migrationhttps://gitlab.isc.org/isc-projects/kea/-/issues/3315hooks should use their own IOService instance and register it with the main I...2024-03-28T14:54:01ZRazvan Becheriuhooks should use their own IOService instance and register it with the main IOServicerelated to https://gitlab.isc.org/isc-projects/kea/-/issues/3308
to properly load and run IOService poll so that configuration errors are detected before configuration is applied and to unload hooks and safely call all close callbacks, ...related to https://gitlab.isc.org/isc-projects/kea/-/issues/3308
to properly load and run IOService poll so that configuration errors are detected before configuration is applied and to unload hooks and safely call all close callbacks, a "local" IOService instance should be used by each hook. this guarantees that there can be no handlers referencing objects created in the hook that are called after hook unload.
hooks that use main io service:
premium:
* gss_tsig
* forensic_log
* lease_query
* ping_check
* radius
core:
* high_availability
* mysql_cb
* pbsql_cb
* run_script
all hooks requiring IOService should do the following:
```plaintext
int unload() {
if (getMainIOService()) {
getMainIOService()->unregisterExternalIOService(getIOService());
}
getIOService()->stop();
getIOService()->restart();
try {
getIOService()->poll();
} catch (...) {
}
...
}
int dhcp4_srv_configured(CalloutHandle& handle) {
handle.getArgument("io_context", getMainIOService());
if (!getMainIOService()) {
// Should not happen!
handle.setStatus(isc::hooks::CalloutHandle::NEXT_STEP_DROP);
const string error("Error: io_context is null");
handle.setArgument("error", error);
return (1);
}
...
getMainIOService()->registerExternalIOService(getIOService());
...
}
int dhcp6_srv_configured(CalloutHandle& handle) {
handle.getArgument("io_context", getMainIOService());
if (!getMainIOService()) {
// Should not happen!
handle.setStatus(isc::hooks::CalloutHandle::NEXT_STEP_DROP);
const string error("Error: io_context is null");
handle.setArgument("error", error);
return (1);
}
...
getMainIOService()->registerExternalIOService(getIOService());
...
}
void
IOService::registerExternalIOService(IOServicePtr io_service) {
external_io_services_.push_back(io_service);
}
void
IOService::unregisterExternalIOService(IOServicePtr io_service) {
auto it = std::find(external_io_services_.begin(), external_io_services_.end(), io_service);
if (it != external_io_services_.end()) {
external_io_services_.erase(it);
}
}
void
IOService::pollExternalIO() {
for (auto& io_service : external_io_services_) {
io_service->poll();
}
}
```
built on top of #3281
I confirm it fixes the crash in #3308https://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/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/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/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-28T14:24:33ZFrancis 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/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/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/2802Implement `bundle` command2023-04-11T11:07:55ZTomek MrugalskiImplement `bundle` commandThe idea for this API call came from @marcin. Here's the discussion: https://pad.isc.org/p/stork-cb-migration#L64
The overall long term goal is to have a command that could include multiple other commands and run them one after another ...The idea for this API call came from @marcin. Here's the discussion: https://pad.isc.org/p/stork-cb-migration#L64
The overall long term goal is to have a command that could include multiple other commands and run them one after another as one change-set. Couple scenarios where this might be useful:
- changing subnet and all host reservations in it
- deleting subnet and all leases associated
- reservation migration from config file to database
This mechanism, if implemented correctly, will be very powerful.
One important feature of this new command is the ability to rollback changes if configurable number of errors is reached. It's important to acknowledge that full rollback in generic case is not possible, so this rollback should be limited to DB operations _for now_. We hope to expand the rollback in the future to maybe cover some other commands, but it will never be possible to rollback everything.
Since there are many ways how this could be implemented, I think the first step would be come up with a mini-design. Couple paragraphs in the ticket or on wiki should do the trick.outstandinghttps://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/2708HA pool rebalancing2023-02-02T14:23:33ZTomek MrugalskiHA pool rebalancingThis idea is not new. It was recently brought up by @cathya in Porto (see [notes](https://pad.isc.org/p/porto2022-kea-features-for-stork#L58). The overall concept is to design and implement a mechanism similar to the one in ISC DHCP. Whe...This idea is not new. It was recently brought up by @cathya in Porto (see [notes](https://pad.isc.org/p/porto2022-kea-features-for-stork#L58). The overall concept is to design and implement a mechanism similar to the one in ISC DHCP. When there are two servers in load-balancing, it is possible that one of them will run out of addresses while the other one still has many.
Couple random comments:
- The pool rebalancing would somehow make both partners negotiate the pools and rebalance them.
- Using a hysteresis approach with high/low threshold would prevent the mechanism to go crazy when running out of addresses. We don't want it to go crazy when there's one or two addresses left.
- The pool dynamism would add extra complexity as the modified pool range would need to be stored somewhere that would survive crashes/reboots etc.
This requires a ~design. It's a complicated feature request with a high potential for endless tweaks, conflicting tuning requests etc.
We will do it one day, but this would require a lot of design, testing and tuning.outstandinghttps://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/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/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).backlog