Kea issueshttps://gitlab.isc.org/isc-projects/kea/-/issues2024-03-28T17:32:26Zhttps://gitlab.isc.org/isc-projects/kea/-/issues/3283CableLabs option (RFC3495): Inconsistent "option_def" usage in client class d...2024-03-28T17:32:26ZPeter DaviesCableLabs option (RFC3495): Inconsistent "option_def" usage in client class definitionsInconsistent "option_def" usage in client class definitions:
Using Kea 2.5.6 - I have yet to try with 2.4.1.
The following "option-def" statement is accepted in the global scope of a
configuration file:
```
...
"opt...Inconsistent "option_def" usage in client class definitions:
Using Kea 2.5.6 - I have yet to try with 2.4.1.
The following "option-def" statement is accepted in the global scope of a
configuration file:
```
...
"option-def": [ {
"name": "Option_122", "code": 122, "type": "empty", "encapsulate": "Option_122_space" }, {
"name": "Option_122_1", "code": 1, "space": "Option_122_Space", "type": "ipv4-address" }, {
"name": "Option_122_2", "code": 2, "space": "Option_122_Space", "type": "ipv4-address" }
],
...
```
However, if this "option-def" is defined within a client class as:
```
...
"client-classes": [{
"name": "Docsis_Class", "test": "substring(option[60].hex,0,6) == 'docsis'",
"option-def": [ {
"name": "Option_122", "code": 122, "type": "empty", "encapsulate": "Option_122_space" }, {
"name": "Option_122_1", "code": 1, "space": "Option_122_Space", "type": "ipv4-address" }, {
"name": "Option_122_2", "code": 2, "space": "Option_122_Space", "type": "ipv4-address" } ],
"option-data": [ {
"name": "Option_122_1", "data": "10.0.0.68", "code": 1, "space": "Option_122_Space" }, {
"name": "Option_122_2", "data": "10.0.0.69", "code": 2, "space": "Option_122_Space" } ]
}],
...
```
The following message is generated, and Kea exits:
```
Error encountered: Not allowed option definition for code '122' in space 'dhcp4'
```
If the "Option_122" "option-def" is changed to private option "224" as:
```
...
"client-classes": [{
"name": "Docsis_Class", "test": "substring(option[60].hex,0,6) == 'docsis'",
"option-def": [ {
"name": "Option_122", "code": 224, "type": "empty", "encapsulate": "Option_122_space" }, {
"name": "Option_122_1", "code": 1, "space": "Option_122_Space", "type": "ipv4-address" }, {
"name": "Option_122_2", "code": 2, "space": "Option_122_Space", "type": "ipv4-address" } ],
"option-data": [ {
"name": "Option_122_1", "data": "10.0.0.68", "code": 1, "space": "Option_122_Space" }, {
"name": "Option_122_2", "data": "10.0.0.69", "code": 2, "space": "Option_122_Space" } ]
}],
...
```
Then the following error is generated, and Kea exits:
```
Error encountered: Not allowed option definition for code '1' in space 'Option_122_Space'
```
[SF00001775](https://isc.lightning.force.com/lightning/r/Case/500S6000006TLtj/view)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/3133Read TSIG secret from file2024-03-27T22:49:58ZIulian MegheaRead TSIG secret from file---
name: Feature request
about: Suggest an idea for this project
---
Allow reading tsig-keys (at least the secret) from an external file. This way it can integrate better with secret management tools.
For example the configuration cou...---
name: Feature request
about: Suggest an idea for this project
---
Allow reading tsig-keys (at least the secret) from an external file. This way it can integrate better with secret management tools.
For example the configuration could use more relaxed permissions but the file containing the tsig secret can use very restrictive permissions.kea2.5.8https://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/2820Optionally log transaction ID with log messages2024-03-27T12:55:48ZDarren AnkneyOptionally log transaction ID with log messagesIt could be useful to have a `%` parameter available for the pattern in the loggers section to add the transaction id to each message logged. It's already logged on some messages but not all.
Example:
```
2023-03-30 20:26:27.518 DEBUG ...It could be useful to have a `%` parameter available for the pattern in the loggers section to add the transaction id to each message logged. It's already logged on some messages but not all.
Example:
```
2023-03-30 20:26:27.518 DEBUG [kea-dhcp4.hosts/283769.281473780088704] HOSTS_CFG_GET_ONE_SUBNET_ID_ADDRESS4 get one host with reservation for subnet id 1 and IPv4 address 192.168.115.202
```
vs.
```
2023-03-30 20:26:27.518 DEBUG [kea-dhcp4.alloc-engine/283769.281473780088704] ALLOC_ENGINE_V4_REQUEST_ALLOC_REQUESTED [hwtype=1 00:0c:01:02:03:06], cid=[01:00:0c:01:02:03:06], tid=0x3: trying to allocate requested address 192.168.115.202
```
Having a way to log it consistently before the start of the message would be helpful when trying to find all of the messages that occurred with a particular exchange. It could even be useful to match these up to packets in a pcap.
[RT21953](https://support.isc.org/Ticket/Display.html?id=21953)kea2.5.8https://gitlab.isc.org/isc-projects/kea/-/issues/2984Add support for Delegated-IPv6-Prefix to RADIUS hook2024-03-27T12:55:24ZDarren AnkneyAdd support for Delegated-IPv6-Prefix to RADIUS hookCurrently, the RADIUS hook can create a reservation for an IP address based on the content of framed-ipv6-address (https://www.rfc-editor.org/rfc/rfc6911#section-3.1) in the access-accept response. It would be nice to also be able to cr...Currently, the RADIUS hook can create a reservation for an IP address based on the content of framed-ipv6-address (https://www.rfc-editor.org/rfc/rfc6911#section-3.1) in the access-accept response. It would be nice to also be able to create a reservation for a prefix based on the content of delegated-ipv6-prefix (https://www.rfc-editor.org/rfc/rfc4818) in the access-accept response.
[RT22056](https://support.isc.org/Ticket/Display.html?id=22056)kea2.5.8https://gitlab.isc.org/isc-projects/kea/-/issues/3140Feature request: Add Statistics Counters for dropped packets (for various dif...2024-03-27T12:51:09ZCathy AlmondFeature request: Add Statistics Counters for dropped packets (for various different reasons)---
name: Feature request: Add Statistics Counters for dropped packets (for various different reasons)
about: Add different packet counters for dropped packets such as ones dropped due to HA ignoring them, or to Kea being disabled.
---
...---
name: Feature request: Add Statistics Counters for dropped packets (for various different reasons)
about: Add different packet counters for dropped packets such as ones dropped due to HA ignoring them, or to Kea being disabled.
---
This is loosely related to issue #3125 for counting some dropped packets due to HA (#3125 is more about not logging them unnecessarily though, or being able to disable the per-event logging).
This is a request to add a specific packet counts for both HA and for other dropped packets such as ones dropped due to kea being disabled.
Customer requesting this feature currently has an issue where they can't tell if an operator has misconfigured their network such that Kea wasn't receiving any traffic or if it was in a disabled state due to Kea HA sync.
Version 2.2
See [SF1429](https://isc.lightning.force.com/lightning/r/Case/5007V00002ZyA1sQAF/view)next-stable-3.0https://gitlab.isc.org/isc-projects/kea/-/issues/2819Add max TTL time to D22024-03-27T12:49:15ZDarren AnkneyAdd max TTL time to D2With the addition of being able to set the DDNS TTL with `ddns-ttl-percent` to some percentage of lease time, it might be a good idea to add a maximum possible TTL to the `kea-ddns` configuration. This should be an absolute time limit. ...With the addition of being able to set the DDNS TTL with `ddns-ttl-percent` to some percentage of lease time, it might be a good idea to add a maximum possible TTL to the `kea-ddns` configuration. This should be an absolute time limit. For example, `3600` for one hour maximum TTL length. In this example, if Kea sent something higher than this, D2 would truncate the TTL to `3600`. If the proposed setting is not present in D2 then there should be no change from current behavior which, I believe, is no limit to the length of the TTL.
[RT21610](https://support.isc.org/Ticket/Display.html?id=21610)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/1186JSON translator tool for CB2024-03-21T12:21:55ZPeter DaviesJSON translator tool for CB---
name: JSON translator tool for CB
about: Importing elements from a json configuration into CB
---
**Some initial questions**
This request looks like an extension to GT [#333](https://gitlab.isc.org/isc-projects/kea/-/issues/333) "pa...---
name: JSON translator tool for CB
about: Importing elements from a json configuration into CB
---
**Some initial questions**
This request looks like an extension to GT [#333](https://gitlab.isc.org/isc-projects/kea/-/issues/333) "parser libraries for servers (for netconf)
**Is your feature request related to a problem? Please describe.**
When migrating from a json based configuration to the Configuration Backend the user must identify each element in the configuration, locate the correct hooks command and apply the appropriate parameters
**Describe the solution you'd like**
A tool which takes a json configuration file as an input. The tool should identify any elements that are CB configurable for the current Kea version and produce a set of command which will create the appropriate elements in the CB.
**Describe alternatives you've considered**
As an extra function of keama
**Additional context**
Customer ticket RT [#16203](https://support.isc.org/Ticket/Display.html?id=16203)next-stable-3.0https://gitlab.isc.org/isc-projects/kea/-/issues/2343CB migration assistant2024-03-21T12:21:07ZPeter DaviesCB migration assistant---
name: CB migration assistant
about: A method to migrate to CB
---
When users need to migrate from a file-based json configuration to the Configuration Backend, or to migrate between the supported databases, it would be useful if **...---
name: CB migration assistant
about: A method to migrate to CB
---
When users need to migrate from a file-based json configuration to the Configuration Backend, or to migrate between the supported databases, it would be useful if **Kea** provided some tool to support this.
Possible methods could:
The implementation of two new **CB** commands ie:
**remote-server4-config-get**
and
**remote-server4-config-set**
Or alternatively the enhancement of the **kea-admin** tool to provide this functionality.
[RT #17095](https://support.isc.org/Ticket/Display.html?id=17095)
[RT #20167](https://support.isc.org/Ticket/Display.html?id=20167)
[RT #21508](https://support.isc.org/Ticket/Display.html?id=21508)
Requested migrations: MySQL -> Postgres, also config to MySQL, config to PostgreSQL.next-stable-3.0https://gitlab.isc.org/isc-projects/kea/-/issues/3082kea-ctrl-agent and dual stack listening2024-03-21T11:45:53ZDarren Ankneykea-ctrl-agent and dual stack listeningThe `kea-ctrl-agent` can presently only listen on one address, be that an IPv4 or IPv6 address. If you have a dual stack on the equipment where you want to listen, then you have to choose either the IPv4 or the IPv6 address to configure...The `kea-ctrl-agent` can presently only listen on one address, be that an IPv4 or IPv6 address. If you have a dual stack on the equipment where you want to listen, then you have to choose either the IPv4 or the IPv6 address to configure in the `kea-ctrl-agent.json`.
I propose to add a new parameter to the kea-ctrl-agent configuration "http-hosts" as shown:
```
{
"Control-agent": {
"http-hosts": [
"2001:db8::2",
"10.1.2.2"
],
"http-port": 8000,
"control-sockets": {
"dhcp4": {
"socket-type": "unix",
"socket-name": "/tmp/socket4"
}
}
}
}
```
This would allow listening on multiple IP addresses especially in a dual stack environment. Also, the new parameter would preserve backward compatibility.
FYI: I did solve this problem by running two copies of the `kea-ctrl-agent`. However, I'm not convinced that is a good solution. Configurations and other details included below for illustration.
<details><summary>kea-dhcp4.json</summary>
```
{
"Dhcp4": {
"control-socket": {
"socket-type": "unix",
"socket-name": "/tmp/socket4"
},
"interfaces-config": {
"interfaces": [
"ens256"
]
},
"lease-database": {
"type": "memfile",
"persist": false
},
"subnet4": [
{
"subnet": "10.1.2.0/24",
"id": 1,
"option-data": [
{
"name": "routers",
"data": "10.1.2.1"
}
],
"pools": [
{
"pool": "10.1.2.100 - 10.1.2.254"
}
]
}
],
"loggers": [
{
"name": "kea-dhcp4",
"severity": "INFO",
"output_options": [
{
"output": "stdout"
}
]
}
]
}
}
```
</details>
<details><summary>kea-ctrl-agent-v4.json</summary>
```
{
"Control-agent": {
"http-host": "10.1.2.2",
"http-port": 8000,
"control-sockets": {
"dhcp4": {
"socket-type": "unix",
"socket-name": "/tmp/socket4"
}
}
}
}
```
</details>
<details><summary>kea-ctrl-agent-v6.json</summary>
```
{
"Control-agent": {
"http-host": "2001:db8::2",
"http-port": 8000,
"control-sockets": {
"dhcp4": {
"socket-type": "unix",
"socket-name": "/tmp/socket4"
}
}
}
}
```
</details>
<details><summary>Configuration of ens256</summary>
```
3: ens256: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
link/ether 00:0c:29:c0:5f:47 brd ff:ff:ff:ff:ff:ff
altname enp26s0
inet 10.1.2.2/24 brd 10.1.2.255 scope global ens256
valid_lft forever preferred_lft forever
inet6 2001:db8::2/64 scope global
valid_lft forever preferred_lft forever
inet6 fe80::20c:29ff:fec0:5f47/64 scope link
valid_lft forever preferred_lft forever
```
</details>
<details><summary>Daemon command lines</summary>
```
kea-dhcp4 -c kea-dhcp4.json
```
```
kea-ctrl-agent -c kea-ctrl-agent-v4.json
```
```
kea-ctrl-agent -c kea-ctrl-agent-v6.json
```
</details>
<details><summary>Send config-get with curl to both</summary>
```
curl -X POST -H "Content-Type: application/json" -d '{ "command": "config-get", "service": [ "dhcp4" ] }' http://10.1.2.2:8000/ | jq
```
```
curl -X POST -H "Content-Type: application/json" -d '{ "command": "config-get", "service": [ "dhcp4" ] }' http://[2001:db8::2]:8000/
```
</details>
Both returned a result successfully.
[SF1260](https://isc.lightning.force.com/lightning/r/Case/5007V00002X2x4cQAB/view)next-stable-3.0https://gitlab.isc.org/isc-projects/kea/-/issues/3217Neighbor discovery for dhcpv62024-02-19T21:40:42ZVaclav MichalekNeighbor discovery for dhcpv6This is a request to implement IPv6 neighbor discovery mechanism (rfc4861) in DHCPv6 server to obtain MAC hardware addresses.
The method is also suggested in [related issue](https://gitlab.isc.org/isc-projects/kea/-/issues/1729 "Feature...This is a request to implement IPv6 neighbor discovery mechanism (rfc4861) in DHCPv6 server to obtain MAC hardware addresses.
The method is also suggested in [related issue](https://gitlab.isc.org/isc-projects/kea/-/issues/1729 "Feature request: DHCPv6 - use real MAC address from dhcp6 request (mac-sources=raw)").
**Is your feature request related to a problem? Please describe.**
The feature is needed for reliable host-based reservations and identification of DHCPv6 clients.
**Describe the solution you'd like**
Two new mac-source methods (query OS neighbor cache, neighbor discovery) are to be implemented.
```plaintext
"mac-sources": [ "neigh-cache", "neigh-discovery" ]
```
**Describe alternatives you've considered** At this time, there is no practical alternative.
**Funding its development** No funding.
**Participating in development** I am planning to write the code (though with no experience with Kea developement).
**Contacting you** ... E-mail in my profile.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/1084Kea does not recover from interface down when Kea starts2024-02-08T14:35:31ZRob AusteinKea does not recover from interface down when Kea startsProblem scenario: Debian 9 server running Kea 1.7.1 package, server has three interfaces: eth1 serves directly connected hosts, eth2 and eth3 serve via DHCP relays, so must use "raw" rather than "udp" configuration. Problem is: server i...Problem scenario: Debian 9 server running Kea 1.7.1 package, server has three interfaces: eth1 serves directly connected hosts, eth2 and eth3 serve via DHCP relays, so must use "raw" rather than "udp" configuration. Problem is: server is part of a large rack of equipment, and we have no control over the order in which things come up, not to mention various replacement and reinstall scenarios. Kea quietly fails to listen on interfaces that show no carrier at the time Kea first starts, and never notices when they come up.
So far I have not thought of anything better than a separate process which monitors link states (eg with PyRoute2) and sends a config-reload control message whenever any of the interfaces comes up. This seems kind of lame.
Is this a known issue? Note that this is not the "new interface" problem: we know all the interfaces and list them in the config file, we just can't guarantee that they'll be up (and in some cases they *can't* come up until after Kea does because they're waiting for a DHCP lease in order to install the software that will eventually bring up the other end of the link).
Is this something ISC is likely to be able to fix anytime soon? Is there a better workaround?
Thanks! (Obligatory note: on the whole I'm very happy with Kea as a replacement for isc-dhcpd, don't think I'm complaining about the new thing... I just need to find a solution to this problem.)outstandinghttps://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/856Enable dynamic prefix support2024-02-07T22:34:55ZTiago GasparEnable dynamic prefix support---
name: Enable dynamic prefix support
about: Allow dynamic prefixes in a interface
---
**Some initial questions**
- Are you sure your feature is not already implemented in the latest Kea version?
From all I've searched all over the ...---
name: Enable dynamic prefix support
about: Allow dynamic prefixes in a interface
---
**Some initial questions**
- Are you sure your feature is not already implemented in the latest Kea version?
From all I've searched all over the internet this is not a standard kea nor ISC-DHCP option
- Are you sure what you would like to do is not possible using some other mechanisms?
I can't see any other way to do this without a wacky faulty scipt
- Have you discussed your idea on kea-users or kea-dev mailing lists?
No, I'm new to this of contributing and have no idea on how to do that
**Is your feature request related to a problem? Please describe.**
So I have a Linux system, in this case OpenWRT as the main router in my home, and I receive a IPv6 prefix from my ISP of size /56 and OpenWRT receives it and assigns it to each interface with the size I describe, but as the prefix is dynamic I can't configure the prefix in kea's config files because it is constantly changing.
**Describe the solution you'd like**
My suggestion is that kea could allow us to set a interface to listen on (as it does) and in the `"subnet":` option it could allow us to set a network like ::/60 (witch is the address for unspecified network)
**Describe alternatives you've considered**
I've considered setting only the listening interface and no subnet option but theãt wouldn't work as Kea also works as a stateless DHCPv6 server, so this is the best way I can think that the server can work as stateless and stateful DHCPv6 with or without a dynamic prefix
**Additional context**
I have a OpenWRT in my house and my ISP gives me a IPv6 Dynamic prefix, although OpenWRT natively handles IPv6 very well with Odhcpd, it doesn't offer many options to give out to clients besides the required ones like DNS and Gateway so I decided to dich odhcpd and I thought of dhcpd but I saw that Kea was a new, better DHCP meant to replace dhcpd at some point so as I'm all for the new and better I installed Kea and got this problem.
**Funding its development**
I'm curently studying so I don't have the money to fund it, but I work in networking every day so I can help you develop this feature asn needed and as I can
**Participating in development**
Yes absolutely! I'm here as needed Just ask, sometimes I can take a bit because of school but I will answer
**Contacting you**
I'd rather you contact me trough github or through here, I will enable e-mail notifications and if you really need to talk I'll privately send my phone numberoutstandinghttps://gitlab.isc.org/isc-projects/kea/-/issues/2407GSS-TSIG max-inactivity-interval2024-02-01T11:44:22ZPeter DaviesGSS-TSIG max-inactivity-interval
MS DNS servers seem to silently invalidate "inactive" GSS contexts. As a
result of that, if Kea doesn't perform a successful DDNS request-reply exchange
with GSS-TSIG for a certain period, the MS server invalidates the correspondin...
MS DNS servers seem to silently invalidate "inactive" GSS contexts. As a
result of that, if Kea doesn't perform a successful DDNS request-reply exchange
with GSS-TSIG for a certain period, the MS server invalidates the corresponding
GSS-TSIG key and starts refusing subsequent requests with GSS-TSIG using that
context.
Those subsequent requests will be responded with "broken" responses as
described above, with the RCODE being REFUSED. We heard this "certain period"
is 165s, and it certainly seems to be a few minutes, but we've not explicitly
confirmed the exact period (or the existence of such "invalidation timer").
From Kea's point of view, those responses just look like broken GSS-TSIG token,
so it cannot tell whether the context is invalidated in the MS server. So the
only possible workaround right now is to rekey GSS-TSIG keys quite often,
whether or not it's been actively used. This is where my other ticket
([#20794](https://support.isc.org/Ticket/Display.html?id=20794)) matters.
see #2404
From our experiments, if we rekey GSS-TSIG keys about every 150s and set key
lifetime to 160s, this problem didn't happen. But such a frequent rekeying is
a waste if the key is being actively used. For example, if we keep triggering
DDNS updates every 30s or so, the problem didn't seem to happen even with the
default rekey-interval (2700s).
So I'd suggest introducing some kind of "max-inactivity-interval". Kea would
keep track of the use of generated GSS-TSIG keys, and if a key isn't used for a
successful DDNS update attempt for the specified interval, it would trigger
rekeying and expire the inactive one as soon as the new key becomes available.
see [RT #20795](https://support.isc.org/Ticket/Display.html?id=20795)next-stable-3.0https://gitlab.isc.org/isc-projects/kea/-/issues/3188Support hot plugging network interfaces2024-02-01T10:52:48ZJakub OkońskiSupport hot plugging network interfaces---
name: Feature request
about: Suggest an idea for this project
---
I'm migrating to kea from the previous ISC DHCP4 server and I noticed a difference in behavior. Kea refuses to start if an interface declared in `interfaces-config` i...---
name: Feature request
about: Suggest an idea for this project
---
I'm migrating to kea from the previous ISC DHCP4 server and I noticed a difference in behavior. Kea refuses to start if an interface declared in `interfaces-config` is not present when Kea starts.
I want to be able to declare subnets & definitions for a USB adapter that I sometimes hotplug to the gateway. Without support from Kea, I'd need to keep two different configs and reload Kea at appropriate times. I assume it's also going to fail when a network interface it's listening on disappears.next-stable-2.6https://gitlab.isc.org/isc-projects/kea/-/issues/3219Implement RFC9527: Homenet DHCPv6 options2024-01-25T14:54:51ZTomek MrugalskiImplement RFC9527: Homenet DHCPv6 optionsA new set of three DHCPv6 options are being published in [RFC9527](https://www.rfc-editor.org/authors/rfc9527.html). If this link no longer works, it means the RFC is published.
The options' formats are reasonably simple (a 16-bits long...A new set of three DHCPv6 options are being published in [RFC9527](https://www.rfc-editor.org/authors/rfc9527.html). If this link no longer works, it means the RFC is published.
The options' formats are reasonably simple (a 16-bits long bit field + fqdn) and are DHCPv6 only. There's no special processing - normal ORO stuff, although the server will likely keep some values user specific (so will be used mainly as host reservation options).backlog