Kea issueshttps://gitlab.isc.org/isc-projects/kea/-/issues2023-04-11T11:07:55Zhttps://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/2812rfc7078: address selection policy v6 options2023-04-13T13:41:55ZTomek Mrugalskirfc7078: address selection policy v6 optionsWe need to implement address selection policies options defined in RFC7078. These are not likely to be popular options yet, but people doing experiments with multi-homing would love to see them supported. If/when multi-homing takes off, ...We need to implement address selection policies options defined in RFC7078. These are not likely to be popular options yet, but people doing experiments with multi-homing would love to see them supported. If/when multi-homing takes off, it would be better if Kea was part of the solution.backloghttps://gitlab.isc.org/isc-projects/kea/-/issues/2818Read YAML configuration file2023-04-13T13:47:19ZVicky Riskvicky@isc.orgRead YAML configuration fileIn today's webinar on configuring custom options, a participant asked whether we could enable configuration in YAML instead of JSON. Carsten revealed that he uses a YAML <-> JSON translator so he can work in YAML but still feed Kea JSON....In today's webinar on configuring custom options, a participant asked whether we could enable configuration in YAML instead of JSON. Carsten revealed that he uses a YAML <-> JSON translator so he can work in YAML but still feed Kea JSON. It was suggested that maybe we could make Kea recognize whether the configuration file is in YAML or JSON, and in case of YAML, run this translator first. It seems like there might be a useful usability improvement in here somewhere.backloghttps://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/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/2825Deprecate extended JSON in favor for compliant JSON comments2023-04-20T12:55:56ZCarsten StrotmannDeprecate extended JSON in favor for compliant JSON comments---
name: Deprecate extended JSON in favor for compliant JSON comments/includes
Kea DHCP uses an extended JSON format with comments and includes that deviates from "standard" JSON (RFC 8259).
While it is nice to have comments and incl...---
name: Deprecate extended JSON in favor for compliant JSON comments/includes
Kea DHCP uses an extended JSON format with comments and includes that deviates from "standard" JSON (RFC 8259).
While it is nice to have comments and includes in the configuration file, the current implementation is not compliant with the JSON specs and breaks other tools JSON parser.
For non-trivial Kea DHCP configuration files, it is highly recommended to use a text editor with JSON support (VS Code, VIM, Emacs, BBEdit etc) or a JSON editor. However, the current "extensions" break the JSON support in these tools/editors so that they cannot be used. The loss of these tools is hurting more than the extra functions implemented in the extended JSON format.
I propose that the current extension are being deprecated and replaced with comments and includes that are valid according to the JSON RFC, so that non-Kea tools can be used when working with Kea configuration files.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/2911New classification expressions "contains"2023-06-15T14:01:23ZCarsten StrotmannNew classification expressions "contains"---
name: Feature request
about: New classification expressions "contains"
---
Sometimes I find the need to classify a DHCP client based on a string of byte-sequence in the DHCP request, but the string or byte-sequence might vary in po...---
name: Feature request
about: New classification expressions "contains"
---
Sometimes I find the need to classify a DHCP client based on a string of byte-sequence in the DHCP request, but the string or byte-sequence might vary in position inside the packet (option) data (based on version of the client product).
A new classification expression that will search a sub-string or byte-sequence inside packet data and reporting the boolean value based on the existence of this sub-string or byte-sequence would be helpful.
Proposed example:
```
"client-classes": [
{ "name": "foo",
"test": "contains(substring(option[60].hex,0,3),'bar','i')",
"option-data": [{
"name": "domain-name", "data": "bar.example.com" }]
},
{ "name": "baz",
"test": "contains(hexstring(option[55].hex),'01:79:03','')",
"option-data": [{
"name": "domain-name", "data": "quux.example.com" }]
},
```
Proposed syntax format
contains('base-string','search-string','options')
where 'options' modify the search, e.g. using 'i' for case-insensitive searchnext-stable-2.6https://gitlab.isc.org/isc-projects/kea/-/issues/2914Improvement in hook scripts (feature request) to add routes2023-06-22T13:37:45ZBruno MeirellesImprovement in hook scripts (feature request) to add routesHi friends,
I'm trying to create a script to add routes when IPv6 addresses and prefixes are allocated, but the "committed" hook is not displaying the address, prefix, and type.(iana or iapd)
If possible, please include the address, pr...Hi friends,
I'm trying to create a script to add routes when IPv6 addresses and prefixes are allocated, but the "committed" hook is not displaying the address, prefix, and type.(iana or iapd)
If possible, please include the address, prefix, and type in the "committed" hook.
Thank you very much!
my debug:
```
2023-06-11T10:05:08.100984-03:00 router kea-dhcp6[6794]: QUERY6_TYPE: REQUEST
2023-06-11T10:05:08.101714-03:00 router kea-dhcp6[6794]: QUERY6_REMOTE_ADDR: fe80::d080:d807:a57f:d2cf
2023-06-11T10:05:08.102103-03:00 router kea-dhcp6[6794]: QUERY6_IFACE_NAME: enp1s0
2023-06-11T10:05:08.102418-03:00 router kea-dhcp6[6794]: LEASE6_TYPE:
2023-06-11T10:05:08.102719-03:00 router kea-dhcp6[6794]: LEASE6_ADDRESS:
2023-06-11T10:05:08.103161-03:00 router kea-dhcp6[6794]: LEASE6_PREFIX_LEN:
2023-06-11T10:05:08.103495-03:00 router kea-dhcp6[6794]: LEASE6_AT0_ADDRESS:
2023-06-11T10:05:08.103794-03:00 router kea-dhcp6[6794]: LEASES6_AT0_STATE: default
2023-06-11T10:05:08.104093-03:00 router kea-dhcp6[6794]: LEASES6_AT0_SUBNET_ID: 1
2023-06-11T10:05:08.104394-03:00 router kea-dhcp6[6794]: LEASE6_AT0_PREFIX_LEN:
2023-06-11T10:05:08.104689-03:00 router kea-dhcp6[6794]: LEASE6_AT0_TYPE:
2023-06-11T10:05:08.104981-03:00 router kea-dhcp6[6794]: LEASE6_AT1_ADDRESS:
2023-06-11T10:05:08.105282-03:00 router kea-dhcp6[6794]: LEASES6_AT1_STATE: default
2023-06-11T10:05:08.105757-03:00 router kea-dhcp6[6794]: LEASES6_AT1_SUBNET_ID: 1
2023-06-11T10:05:08.106111-03:00 router kea-dhcp6[6794]: LEASE6_AT1_PREFIX_LEN:
2023-06-11T10:05:08.106418-03:00 router kea-dhcp6[6794]: LEASE6_AT1_TYPE:
2023-06-11T10:05:08.106719-03:00 router kea-dhcp6[6794]: LEASE6_AT2_ADDRESS:
2023-06-11T10:05:08.107018-03:00 router kea-dhcp6[6794]: LEASES6_AT2_STATE: default
2023-06-11T10:05:08.107315-03:00 router kea-dhcp6[6794]: LEASES6_AT2_SUBNET_ID: 1
2023-06-11T10:05:08.107615-03:00 router kea-dhcp6[6794]: LEASE6_AT2_PREFIX_LEN:
2023-06-11T10:05:08.107913-03:00 router kea-dhcp6[6794]: LEASE6_AT2_TYPE:
2023-06-11T10:05:08.108264-03:00 router kea-dhcp6[6794]: LEASE6_AT3_ADDRESS:
2023-06-11T10:05:08.108577-03:00 router kea-dhcp6[6794]: LEASES6_AT3_STATE: default
2023-06-11T10:05:08.108874-03:00 router kea-dhcp6[6794]: LEASES6_AT3_SUBNET_ID: 1
2023-06-11T10:05:08.109173-03:00 router kea-dhcp6[6794]: LEASE6_AT3_PREFIX_LEN:
2023-06-11T10:05:08.109544-03:00 router kea-dhcp6[6794]: LEASE6_AT3_TYPE:
```next-stable-2.6https://gitlab.isc.org/isc-projects/kea/-/issues/2974New localize DHCP server command2023-09-01T14:23:21ZFrancis DupontNew localize DHCP server commandThe idea is to add a new command which returns the selected subnet (id and text) with eventually the shared network from supplied parametes as an IP address, client classes (for guards) or interface name.The idea is to add a new command which returns the selected subnet (id and text) with eventually the shared network from supplied parametes as an IP address, client classes (for guards) or interface name.next-stable-2.6https://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/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/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/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/3018motd (message of the day) in kea2023-08-24T13:35:43ZTomek Mrugalskimotd (message of the day) in keaWe could implement a message in Kea, the if configured, would be logged when Kea is started or reconfigured. Trivial to implement.
This would be useful in Docker. We need to put some config file in a Docker image, with the expectation t...We could implement a message in Kea, the if configured, would be logged when Kea is started or reconfigured. Trivial to implement.
This would be useful in Docker. We need to put some config file in a Docker image, with the expectation that the user will replace it with a real config. If the user doesn't, Kea should start, but print something like "please edit your config file, map your volume when starting Docker image, etc.". The text would be configurable in a config file.
This is similar to Unix idea of `/etc/motd` (its content is printed as a welcome message to the user every time he/she logs in).backloghttps://gitlab.isc.org/isc-projects/kea/-/issues/3023Implement RFC3118: DHCPv4 authentication2023-09-21T10:10:23ZTomek MrugalskiImplement RFC3118: DHCPv4 authenticationAs pointed out by [@manu's audit](https://gitlab.isc.org/isc-private/kea/-/wikis/Kea-Security-Review-02-2023#14-support-authentication-in-dhcpv4-protocol), we should implement RFC3118 (DHCPv4 authentication).As pointed out by [@manu's audit](https://gitlab.isc.org/isc-private/kea/-/wikis/Kea-Security-Review-02-2023#14-support-authentication-in-dhcpv4-protocol), we should implement RFC3118 (DHCPv4 authentication).backloghttps://gitlab.isc.org/isc-projects/kea/-/issues/3035Expose interface-id in dhcpv6 hook points2023-09-21T13:22:34ZSorin EsanuExpose interface-id in dhcpv6 hook pointsHello!
I see useful to expose option18 (interface id) and, eventually, option37 (remote id) to dhcpv6 hook points, in a similar way that option82 is sent in dhcpv4 hook points (QUERY4_OPTION_82 or QUERY4_OPTION_82_SUB_OPTION_1).
Thank you!Hello!
I see useful to expose option18 (interface id) and, eventually, option37 (remote id) to dhcpv6 hook points, in a similar way that option82 is sent in dhcpv4 hook points (QUERY4_OPTION_82 or QUERY4_OPTION_82_SUB_OPTION_1).
Thank you!next-stable-2.6https://gitlab.isc.org/isc-projects/kea/-/issues/3049permit ddns-qualifying-suffix option in pool scope2023-09-21T18:21:11Zalimdipermit ddns-qualifying-suffix option in pool scopeHi Folks,
I'm happy with kea dhcp so far as it really fulfills the needs.
However when it come to ddns, I'm a bit frustrated as it's not possible to segragate pool clients in different dns zones.
ddns-qualifying-suffix is either global,...Hi Folks,
I'm happy with kea dhcp so far as it really fulfills the needs.
However when it come to ddns, I'm a bit frustrated as it's not possible to segragate pool clients in different dns zones.
ddns-qualifying-suffix is either global, shared network or subnet but **not** pool.
Let's say I want all defined client in a subnet (those with reservation) to have a fqdn foo.bar and the unknown ones (choosed from the pool) to have guest.foo.bar, didn't find a way to do it.
It would be really helpful to scope ddns-qualifying-suffix to poolbackloghttps://gitlab.isc.org/isc-projects/kea/-/issues/3061Include wildcards2023-09-21T13:48:46ZTomek MrugalskiInclude wildcardsOne Kea user wrote:
> we use puppet to define our service configurations and Kea seems to have support for including a single file, yet not a complete directory that we could fill easily. That kind of including a full directory that is ...One Kea user wrote:
> we use puppet to define our service configurations and Kea seems to have support for including a single file, yet not a complete directory that we could fill easily. That kind of including a full directory that is exclusive under control of a configuration management solution seems to be lacking and causes us to add a preparser to the deployment, which is very well possible but somewhat doesn't feel right. Are we simply not seeing "the solution" that you originally designed here?
This is a proposal to extend the syntax `<?include "file.json"?>` to be able to use wildcards and include multiple files.
Personally, I don't think this would be a very popular feature. But on the other hand, it opens up some interesting use cases.backloghttps://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.0