Kea issueshttps://gitlab.isc.org/isc-projects/kea/-/issues2024-03-07T14:55:13Zhttps://gitlab.isc.org/isc-projects/kea/-/issues/3251Fix drop statistics in subnet6_select and RADIUS hook2024-03-07T14:55:13ZFrancis DupontFix drop statistics in subnet6_select and RADIUS hookThe pkt6-receive-drop is not correctly handled in the subnet6_select callout and the RADIUS hook adds another way to mess it.The pkt6-receive-drop is not correctly handled in the subnet6_select callout and the RADIUS hook adds another way to mess it.next-stable-2.6https://gitlab.isc.org/isc-projects/kea/-/issues/3226HA lease updates do not create an accounting entry in v62024-01-25T15:00:10ZAndrei Pavelandrei@isc.orgHA lease updates do not create an accounting entry in v6In v6, HA lease updates are done with the `lease6-bulk-apply` command which is not handled in the `command_processed` RADIUS callout.
This is unlike v4 which does create accounting entries for HA lease updates sent via `lease4-update`.In v6, HA lease updates are done with the `lease6-bulk-apply` command which is not handled in the `command_processed` RADIUS callout.
This is unlike v4 which does create accounting entries for HA lease updates sent via `lease4-update`.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).backloghttps://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/3195Modifying pools using the subnetX_update commands does not update statistics2024-03-27T16:11:27ZMarcin SiodelskiModifying pools using the subnetX_update commands does not update statisticsI tested the latest addition to Stork - pools management. I had a subnet without pools initially. I added some address pools to the subnet and saved the changes. It results in sending `subnet4_update` followed by `config-write`. The stat...I tested the latest addition to Stork - pools management. I had a subnet without pools initially. I added some address pools to the subnet and saved the changes. It results in sending `subnet4_update` followed by `config-write`. The statistics (in particular `total-addresses` counter) has not been changed to reflect the new pools capacity. I am able to force recounting the statistics by sending the `config-reload` command, but that's not how it is supposed to work.kea2.5.8https://gitlab.isc.org/isc-projects/kea/-/issues/3114Second Device Unique ID (duid) on DHCP6-Server2023-12-21T14:31:57ZschniefiSecond Device Unique ID (duid) on DHCP6-ServerI would like to reserve an IPv6 address in a multi-boot system for both the first DUID (Linux) and the second DUID (Windows).\
Is it possible to specify a second DUID in one IPv6 reservation? So as in the following example:
`{ "command"...I would like to reserve an IPv6 address in a multi-boot system for both the first DUID (Linux) and the second DUID (Windows).\
Is it possible to specify a second DUID in one IPv6 reservation? So as in the following example:
`{ "command": "reservation-add", "service": [ "dhcp6" ], "arguments": { "reservation": { "subnet-id": 123, "hostname": "xyz", "ip-addresses": ["1999:123:56a:1800::123"], "duid": "11:11:11:11:11:11", "duid2": "22:22:22:22:22:22" } } }`
When searching for the IPv6 reservation, both the duid and duid2 should be possible inputs:
`{ "command": "reservation-get", "service": [ "dhcp6" ], "arguments": { "subnet-id": 123, "identifier-type": "duid", "identifier": "11:11:11:11:11:11" } }`\
or\
`{ "command": "reservation-get", "service": [ "dhcp6" ], "arguments": { "subnet-id": 123, "identifier-type": "duid2", "identifier": "22:22:22:22:22:22" } }`
For differentiation, the IPv6 reservations should adhere to the following uniqueness criteria:
* unique("ip-address","subnet-id","duid")
* unique("ip-address","subnet-id","duid2")outstandinghttps://gitlab.isc.org/isc-projects/kea/-/issues/3040failure to start up with ppp interfaces2024-02-08T14:35:31ZJaco Kroonfailure to start up with ppp interfaces2023-08-31 23:34:48.506 WARN [kea-dhcp6.dhcpsrv/27456.140590317625408] DHCPSRV_OPEN_SOCKET_FAIL failed to open socket: Failed to open multicast socket on interface ppp0, reason: Failed to open link-local socket on interface ppp0: Failed...2023-08-31 23:34:48.506 WARN [kea-dhcp6.dhcpsrv/27456.140590317625408] DHCPSRV_OPEN_SOCKET_FAIL failed to open socket: Failed to open multicast socket on interface ppp0, reason: Failed to open link-local socket on interface ppp0: Failed to bind socket 20 to fe80::e/port=547: Cannot assign requested address
```
26: ppp0: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1350 qdisc tbf state UNKNOWN group default qlen 3
inet6 fe80::14e4:139f:8862:3dfd peer fe80::e/128 scope link
valid_lft forever preferred_lft forever
```
Obviously we should bind to the local link-local, not the remote one.
kea 2.4.0. 2.5.1 segfaults on my configuration:
```
{
"Dhcp6": {
"interfaces-config": {
"interfaces": [ "ppp0" ]
},
"control-socket": {
"socket-type": "unix",
"socket-name": "/run/kea/kea6-ctrl-socket"
},
"lease-database": {
"type": "memfile",
"lfc-interval": 3600
},
"expired-leases-processing": {
"reclaim-timer-wait-time": 10,
"flush-reclaimed-timer-wait-time": 25,
"hold-reclaimed-time": 3600,
"max-reclaim-leases": 100,
"max-reclaim-time": 250,
"unwarned-reclaim-cycles": 5
},
"renew-timer": 1000,
"rebind-timer": 2000,
"preferred-lifetime": 3000,
"valid-lifetime": 4000,
"option-data": [
{
"name": "dns-servers",
"data": "2c0f:f720::..., 2c0f:f720::..."
}
],
"subnet6": [
{
"subnet": "2c0f:f720:fcf0::/44",
"pd-pools": [
{
"prefix": "2c0f:f720:fcf0::",
"prefix-len": 44,
"delegated-len": 56
}
]
}
],
"loggers": [
{
"name": "kea-dhcp6",
"output_options": [
{
"output": "/var/log/kea/kea-dhcp6.log"
}
],
"severity": "DEBUG",
"debuglevel": 99
}
]
}
}
```
Strace from a re-run (so socket number is different):
```
bind(19, {sa_family=AF_NETLINK, nl_pid=0, nl_groups=00000000}, 12) = 0
getsockname(19, {sa_family=AF_NETLINK, nl_pid=6688, nl_groups=00000000}, [12]) = 0
sendto(19, [{nlmsg_len=20, nlmsg_type=RTM_GETLINK, nlmsg_flags=NLM_F_REQUEST|NLM_F_DUMP, nlmsg_seq=1, nlmsg_pid=0}, {ifi_family=AF_PACKET, ...}], 20, 0, {sa_family=AF_NETLINK, nl_pid=0, nl_groups=00000000}, 12) = 20
recvmsg(19, {msg_name={sa_family=AF_NETLINK ...
ifa_index=if_nametoindex("ppp0")}, [[{nla_len=20, nla_type=IFA_LOCAL}, **inet_pton(AF_INET6, "fe80::14e4:139f:8862:3dfd")], [{nla_len=20, nla_type=IFA_ADDRESS}, inet_pton(AF_INET6, "fe80::e")],** [{nla_len=20, nla_type=IFA_CACHEINFO}, {ifa_prefered=4294967295, ifa_valid=4294967295, cstamp=168714876, tstamp=168714876}], [{nla_len=8, nla_type=IFA_FLAGS}, IFA_F_PERMANENT]]], [{nlmsg_len=72, nlmsg_type=RTM_NEWADDR, nlmsg_flags=NLM_F_MULTI, nlmsg_seq=2, nlmsg_pid=6688}, {ifa_family=AF_INET6, ifa_prefixlen=64, ifa_flags=IFA_F_PERMANENT, ifa_scope=RT_SCOPE_LINK,
...
close(19) = 0
socket(AF_UNIX, SOCK_DGRAM|SOCK_CLOEXEC, 0) = 19
ioctl(19, SIOCGIFINDEX, {ifr_name="ppp0", ifr_ifindex=26}) = 0
close(19) = 0
socket(AF_INET6, SOCK_DGRAM, IPPROTO_IP) = 19
fcntl(19, F_SETFD, FD_CLOEXEC) = 0
setsockopt(19, SOL_SOCKET, SO_REUSEADDR, [1], 4) = 0
setsockopt(19, SOL_SOCKET, SO_REUSEPORT, [1], 4) = 0
setsockopt(19, SOL_IPV6, IPV6_V6ONLY, [1], 4) = 0
bind(19, {sa_family=AF_INET6, sin6_port=htons(547), sin6_flowinfo=htonl(0), inet_pton(AF_INET6, "**fe80::e**", &sin6_addr), sin6_scope_id=if_nametoindex("ppp0")}, 28) = -1 EADDRNOTAVAIL (Cannot assign requested address)
close(19) = 0
```next-stable-2.6https://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/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/2816The default delegated-len should be /642023-05-18T13:35:45ZTomek MrugalskiThe default delegated-len should be /64There's a substantial discussion happening at IETF (6man and v6ops WGs), related to [draft-collink-v6ops-ent64pd](https://datatracker.ietf.org/doc/draft-collink-v6ops-ent64pd/) and [draft-collink-6man-pio-pflag-00](https://datatracker.ie...There's a substantial discussion happening at IETF (6man and v6ops WGs), related to [draft-collink-v6ops-ent64pd](https://datatracker.ietf.org/doc/draft-collink-v6ops-ent64pd/) and [draft-collink-6man-pio-pflag-00](https://datatracker.ietf.org/doc/draft-collink-6man-pio-pflag/).
The leading perspective is that the recommended prefix length for delegation should be /64. This is pretty major change of opinion for Google and Android. We should make sure Kea is ready for those new deployments.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/2731Remove dead code in command processing2023-02-09T14:18:22ZTomek MrugalskiRemove dead code in command processingWhile reviewing #2693, @andrei discovered that adding log messages in ControlledDhcpv4Srv::processCommand() section that handles libreload doesn't actually gets triggered when the command are sent over CA or directly over UNIX socket. Th...While reviewing #2693, @andrei discovered that adding log messages in ControlledDhcpv4Srv::processCommand() section that handles libreload doesn't actually gets triggered when the command are sent over CA or directly over UNIX socket. This should be investigated further. Perhaps processCommand() is no longer needed?
See background and details here: https://gitlab.isc.org/isc-projects/kea/-/merge_requests/1895?commit_id=877d1cfad37bd41d7d7db105ff6de0b83ca710e2#note_345720outstandinghttps://gitlab.isc.org/isc-projects/kea/-/issues/2698iapd prefix not released in time for next advertise2023-07-31T14:10:43ZMarcin Godzinaiapd prefix not released in time for next advertiseOn jenkins, and on slow systems, Kea is unable to release prefix in time for incoming Solicit. \
The problem exists only when releasing prefix.
Problem observed on test: `tests/dhcp/v6/test_prefix_delegation.py::test_prefix_delegation_n...On jenkins, and on slow systems, Kea is unable to release prefix in time for incoming Solicit. \
The problem exists only when releasing prefix.
Problem observed on test: `tests/dhcp/v6/test_prefix_delegation.py::test_prefix_delegation_noprefixavail_release`
1. Test starts Kea
2. Forge sends Solicit with IA-PD and client id and waits for advertise with option 25.
3. Forge Sends Request with IA-PD and client id and waits for reply with option 26 in 25.
4. Forge second Solicit with IA-PD and client id and waits for advertise with option 25.
5. Forge sends Request with IA-PD and client id and waits for reply with option 26 in 25.
6. Both available prefixes are assigned
7. Forge third Solicit with IA-PD and client id and waits for advertise with no lease available.
8. Forge sends Release with client id and waits for reply with confirmation.
9. Forge fourth Solicit with IA-PD and client id and waits for advertise with option 26 in 25
On local VM test passes - Kea can release prefix in a timely manner.
On Jenkins and local VM with CPU slowed down to 2%, the test fails.
It looks like releasing prefix takes over 200ms after log message on slower machine.
Test run with failure:
https://jenkins.aws.isc.org/view/Kea-manual/job/kea-manual/job/tarball-system-tests/235/
Test run with introduced delay after release passes:
https://jenkins.aws.isc.org/view/Kea-manual/job/kea-manual/job/tarball-system-tests/234/
```
2022-12-22 23:00:12.726 DEBUG [kea-dhcp6.packets/2570743.140676907595328] DHCP6_RESPONSE_DATA responding with packet type 7 data is localAddr=[ff02::1:2]:547 remoteAddr=[fe80::21b:2cff:fe00:99]:546
msgtype=7(REPLY), transid=0xa596df
type=00001, len=00014: 00:01:00:01:63:a4:e1:76:00:1b:2c:00:00:99
type=00002, len=00014: 00:01:00:01:2b:37:9d:f8:86:32:67:b7:f6:87
type=00013, len=00041: Success(0) "Summary status for all processed IA_NAs"
type=00025(IA_PD), len=00063: iaid=36171, t1=0, t2=0,
options:
type=00013, len=00047: Success(0) "Lease released. Thank you, please come again."
No relays traversed.
(...)
2022-12-22 23:00:12.862 DEBUG [kea-dhcp6.dhcpsrv/2570743.140676915988032] DHCPSRV_CFGMGR_SUBNET6_IFACE selected subnet 3000::/64 for packet received over interface enp0s9
(...)
2022-12-22 23:00:12.862 WARN [kea-dhcp6.alloc-engine/2570743.140676915988032] ALLOC_ENGINE_V6_ALLOC_FAIL_SUBNET duid=[00:01:00:01:63:a4:e1:76:00:1b:2c:00:00:99], tid=0xa596df: failed to allocate an IPv6 lease in the subnet 3000::/64, subnet-id 1, shared network (none)
```
[kea.log](/uploads/95e0d4cdcc89f28c008e545ccdb63061/kea.log)[kea-dhcp6.conf](/uploads/dbde869ba021c196bf52b92c18149ba0/kea-dhcp6.conf)[leases.csv](/uploads/3e14a6a860d8c28af5b9cac6a35d3daf/leases.csv)[test-steps.txt](/uploads/0b0093adeb71b819eb4e6f72add19f01/test-steps.txt)next-stable-2.6https://gitlab.isc.org/isc-projects/kea/-/issues/2565HA lease v6 updates use the default hwtype and hwaddr_source2023-07-31T13:51:18ZAndrei Pavelandrei@isc.orgHA lease v6 updates use the default hwtype and hwaddr_sourceNotice the discrepancy in the last two columns:
* `server1`:
```
address,duid,valid_lifetime,expire,subnet_id,pref_lifetime,lease_type,iaid,prefix_len,fqdn_fwd,fqdn_rev,hostname,hwaddr,state,user_context,hwtype,hwaddr_source
2001:db8:5...Notice the discrepancy in the last two columns:
* `server1`:
```
address,duid,valid_lifetime,expire,subnet_id,pref_lifetime,lease_type,iaid,prefix_len,fqdn_fwd,fqdn_rev,hostname,hwaddr,state,user_context,hwtype,hwaddr_source
2001:db8:50::11,00:03:00:01:01:03:0d:04:0b:01,4000,1663013972,1,3000,0,5946,128,0,0,,01:03:0d:04:0b:01,0,,1,0
2001:db8:50::12,00:03:00:01:01:04:0e:05:0c:02,4000,1663013972,1,3000,0,3512,128,0,0,,01:04:0e:05:0c:02,0,,1,0
2001:db8:50::d,00:03:00:01:01:05:0f:06:0d:03,4000,1663013972,1,3000,0,5918,128,0,0,,01:05:0f:06:0d:03,0,,1,2
2001:db8:50::e,00:03:00:01:01:06:10:07:0e:04,4000,1663013973,1,3000,0,4936,128,0,0,,01:06:10:07:0e:04,0,,1,2
```
* `server2`:
```
address,duid,valid_lifetime,expire,subnet_id,pref_lifetime,lease_type,iaid,prefix_len,fqdn_fwd,fqdn_rev,hostname,hwaddr,state,user_context,hwtype,hwaddr_source
2001:db8:50::11,00:03:00:01:01:03:0d:04:0b:01,4000,1663013972,1,3000,0,5946,128,0,0,,01:03:0d:04:0b:01,0,,1,2
2001:db8:50::12,00:03:00:01:01:04:0e:05:0c:02,4000,1663013972,1,3000,0,3512,128,0,0,,01:04:0e:05:0c:02,0,,1,2
2001:db8:50::d,00:03:00:01:01:05:0f:06:0d:03,4000,1663013972,1,3000,0,5918,128,0,0,,01:05:0f:06:0d:03,0,,1,0
2001:db8:50::e,00:03:00:01:01:06:10:07:0e:04,4000,1663013973,1,3000,0,4936,128,0,0,,01:06:10:07:0e:04,0,,1,0
```
The ones with `hwaddr_source = 0` are updated from the other peer. `hwtype = 1` is also likely a default that happens to match its source in the examples above.
It looks like `Lease6::toElement()` and `Lease6Parser::parse()` need the `hwtype` and `hwaddr_source` capabilities.backloghttps://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/2520Change v6 vendor-class option definition.2023-03-10T23:20:36ZFrancis DupontChange v6 vendor-class option definition.The idea is to change the DHCPv6 vendor-class (code 16) definition from uint32 + binary into uint32 + tuple array. This has a lot of advantages **but is not backward compatible**. Note if ISC DHCP allows arrays of records for Kea the arr...The idea is to change the DHCPv6 vendor-class (code 16) definition from uint32 + binary into uint32 + tuple array. This has a lot of advantages **but is not backward compatible**. Note if ISC DHCP allows arrays of records for Kea the array flag for a record type means the last field is an array. Currently there is only one standard option using tuples.
Quoting RFC 8415 figures 28 and 29 vendor-class option layout is:
```
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OPTION_VENDOR_CLASS | option-len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| enterprise-number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. .
. vendor-class-data .
. . . . .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
...
The vendor-class-data field is composed of a series of separate
items, each of which describes some characteristic of the client's
hardware configuration. Examples of vendor-class-data instances
might include the version of the operating system the client is
running or the amount of memory installed on the client.
Each instance of vendor-class-data is formatted as follows:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...-+-+-+-+-+-+-+
| vendor-class-len | opaque-data |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...-+-+-+-+-+-+-+
```outstandinghttps://gitlab.isc.org/isc-projects/kea/-/issues/2489Add support for logging and stat collection related to IPv6 HR conflicts2023-06-19T12:21:15ZDan TheisenAdd support for logging and stat collection related to IPv6 HR conflictsThis is related to #2419
Investigate code paths related to IPv6 Host Reservation conflicts, and add a `ALLOC_ENGINE_V6_DISCOVER_ADDRESS_CONFLICT` log message as well as `v6-reservation-conflicts` and `subnet[id].v6-reservation-conflicts...This is related to #2419
Investigate code paths related to IPv6 Host Reservation conflicts, and add a `ALLOC_ENGINE_V6_DISCOVER_ADDRESS_CONFLICT` log message as well as `v6-reservation-conflicts` and `subnet[id].v6-reservation-conflicts` stats to reflect issues with allocating IPv6 Host Reservations.backloghttps://gitlab.isc.org/isc-projects/kea/-/issues/2313kea-dhcp6 has wrong hook label in exception catch block2022-11-02T15:10:40ZThomas Markwalderkea-dhcp6 has wrong hook label in exception catch blockkea-dhcp6 server has try-catch block around the call to leases6_committed hook callout. The catch block calls HookManager to drop parked packet but specifies the wrong hook name:
```
try {
// Call all installed cal...kea-dhcp6 server has try-catch block around the call to leases6_committed hook callout. The catch block calls HookManager to drop parked packet but specifies the wrong hook name:
```
try {
// Call all installed callouts
HooksManager::callCallouts(Hooks.hook_index_leases6_committed_,
*callout_handle);
} catch (...) {
// Make sure we don't orphan a parked packet.
HooksManager::drop("leases4_committed", query);
throw;
}
```
It should be "leases6_committed". I doubt this is having any real impact but it might represent a memory leak under certain error conditions.backloghttps://gitlab.isc.org/isc-projects/kea/-/issues/2305Kea should always return lease file location if memfile is used2022-11-02T15:10:41ZTomek MrugalskiKea should always return lease file location if memfile is usedThis issue came up during Stork sanity checks: https://gitlab.isc.org/isc-projects/stork/-/issues/667. The background of the problem is that Kea does not return lease file location if a default value is used. However, for an average user...This issue came up during Stork sanity checks: https://gitlab.isc.org/isc-projects/stork/-/issues/667. The background of the problem is that Kea does not return lease file location if a default value is used. However, for an average user to determine where the lease file is located, he'd have to figure out compilation options and what prefix was configured during compilation. This is not something average user can do.
The proposal is to always return the lease file location if memfile is used, even if the location is "the default" (because effectively, the default can change from one deployment to another).backloghttps://gitlab.isc.org/isc-projects/kea/-/issues/2297'outbound_interface' support for DHCP6 server?2022-11-02T15:10:40ZKevin Fleming'outbound_interface' support for DHCP6 server?**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? It is possible, but inconvenient and ...**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? It is possible, but inconvenient and inconsistent.
- Have you discussed your idea on kea-users or kea-dev mailing lists? No.
**Is your feature request related to a problem? Please describe.**
I have a pair of Kea DHCP servers without direct connection to the clients (they receive all requests via relay). The machines have a 'transport' interface that is used to route traffic to the rest of the network, but is not the address used for services. The service interface is a 'dummy' interface, and that is the interface configured in the server config files. In spite of that, the server believes that requests are received on the 'transport' interface even though it is only bound to the 'mgmt' interface.
In the DHCP4 server, I can set `outbound_interface` to `use-routing` so that replies can be sent out without having a socket open on the 'transport' interface.
**Describe the solution you'd like**
In the DHCP6 server, support the same `outbound_interface` mechanism as the DHCP4 server supports.
**Describe alternatives you've considered**
If I *also* bind the server to the 'transport' interface, the server can send replies. That is my current configuration.
**Additional context**
I am using Kea 2.0.1, but have checked the docs for 2.1.2 and the code in the repo and this feature is not available in the DHCP6 server.
**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? Possibly.
**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? Yes to all.backlog