ISC Open Source Projects issueshttps://gitlab.isc.org/groups/isc-projects/-/issues2024-01-23T15:27:16Zhttps://gitlab.isc.org/isc-projects/bind9/-/issues/4544"primaries" block documentation issues2024-01-23T15:27:16ZRay Bellis"primaries" block documentation issuesI'm finding the documentation of the "primaries" block confusing.
The ARM claims a `primaries` zone setting is only permissible within mirror, redirect, secondary and stub zones. However I've been using them at least a couple of years ...I'm finding the documentation of the "primaries" block confusing.
The ARM claims a `primaries` zone setting is only permissible within mirror, redirect, secondary and stub zones. However I've been using them at least a couple of years within the `also-notify` section of primary zones.
There's no direct mention of `primaries` in the grammar of an `also-notify` block. I _suspect_ that it's covered by `<remote-servers>` but the only link between `primaries` and `remote-servers` is this text in the glossary:
> remote-servers: A named list of one or more ip_addresses with optional tls_id, server_key, and/or port. A remote-servers list may include other remote-servers lists. See primaries block.
If in fact a `<remote-servers>` reference _is_ a (named) `primaries` list, then that ought to be spelled out more explicitly, and the documentation updated to reflect that this can be used in *any* `allow-notify` block in any applicable zone type.
I'd also suggest that the top level grammar ought to actually be called `xfer-servers` instead of `masters` and then that term used in place of `remote-servers` in the ARM. In the NOTIFY case the listed servers are secondaries, not primaries, and it makes no sense to call them primaries.
[`remote-servers` also causes confusion with `server <prefix> { }` used to specify per-server EDNS overrides, etc]Long-termMatthijs Mekkingmatthijs@isc.orgMatthijs Mekkingmatthijs@isc.orghttps://gitlab.isc.org/isc-projects/kea/-/issues/3228Add monitoring instrumentation around `dhcp-disable` state.2024-02-01T14:49:57ZTomek MrugalskiAdd monitoring instrumentation around `dhcp-disable` state.For details, see [github PR#133](https://github.com/isc-projects/kea/pull/133).For details, see [github PR#133](https://github.com/isc-projects/kea/pull/133).next-stable-2.6https://gitlab.isc.org/isc-projects/bind9/-/issues/4543Re-enable unreachable checks in dnssec system test2024-02-24T07:55:26ZTom KrizekRe-enable unreachable checks in dnssec system testIn https://gitlab.isc.org/isc-projects/bind9/-/merge_requests/8085, a premature [exit statement](https://gitlab.isc.org/isc-projects/bind9/-/blob/b54bdf8d78666d8dcc6d4e1ad74c4af0a130e1a8/bin/tests/system/dnssec/tests.sh#L3711) has been a...In https://gitlab.isc.org/isc-projects/bind9/-/merge_requests/8085, a premature [exit statement](https://gitlab.isc.org/isc-projects/bind9/-/blob/b54bdf8d78666d8dcc6d4e1ad74c4af0a130e1a8/bin/tests/system/dnssec/tests.sh#L3711) has been accidentally added to the `dnssec` test, making the remaining checks unreachable.May 2024 (9.18.27, 9.18.27-S1, 9.19.24)Tom KrizekTom Krizekhttps://gitlab.isc.org/isc-projects/bind9/-/issues/4542XoT: Primaries should be able to have different allow-transfer acls per trans...2024-01-22T13:10:56ZDave KnightXoT: Primaries should be able to have different allow-transfer acls per transport or ACLs should be extended with port and transport options### Description
We can restrict a primary to ONLY allow-transfer on a specific transport, e.g.
allow-transfer port 853 transport tls { acl_for_xot_clients; };
Unless I'm missing something, there's no way to have different rules per tr...### Description
We can restrict a primary to ONLY allow-transfer on a specific transport, e.g.
allow-transfer port 853 transport tls { acl_for_xot_clients; };
Unless I'm missing something, there's no way to have different rules per transport.
I want to require XoT for transfers over the Internet, but allow insecure AXFR to localnets.
It's not possible to have multiple allow-transfer definitions, i.e. this
allow-transfer port 53 transport tcp { acl_for_nonxot_clients; };
allow-transfer port 853 transport tls { acl_for_xot_clients; };
results in
'allow-transfer' redefined near 'allow-transfer'
And my understanding is that we can't refer to ports or transport in an acl.
### Request
Either allow multiple allow-transfer clauses, treating "allow transfer transport tcp" and "allow transfer transport tls" as different things, which can have their own acl specification, or add port and transport to the acl so that this can be controlled there.
### Links / referencesLong-termArtem BoldarievArtem Boldarievhttps://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/3225when applying MT settings from CB the libs compatibility is not rechecked2024-03-27T13:50:40ZRazvan Becheriuwhen applying MT settings from CB the libs compatibility is not recheckedMT disabled -\> check libs (success) -\> load libs -\> CB load config -\> MT enabled -\> no checking of libs -\> could end up with non MT compatible libs loaded and used in MTMT disabled -\> check libs (success) -\> load libs -\> CB load config -\> MT enabled -\> no checking of libs -\> could end up with non MT compatible libs loaded and used in MTnext-stable-3.0https://gitlab.isc.org/isc-projects/kea/-/issues/3224CB commands should use processDhcp[4|6]Config to validate content of global p...2024-02-01T14:46:08ZRazvan BecheriuCB commands should use processDhcp[4|6]Config to validate content of global parameterssetting global parameters using CB commands does not check if values are valid. They are merged into the current config with no check. this could have an undesired effect on the running server.
global scalar parameters v4:
```plaintext...setting global parameters using CB commands does not check if values are valid. They are merged into the current config with no check. this could have an undesired effect on the running server.
global scalar parameters v4:
```plaintext
if ( (config_pair.first == "renew-timer") ||
(config_pair.first == "rebind-timer") ||
(config_pair.first == "valid-lifetime") ||
(config_pair.first == "min-valid-lifetime") ||
(config_pair.first == "max-valid-lifetime") ||
(config_pair.first == "decline-probation-period") ||
(config_pair.first == "dhcp4o6-port") ||
(config_pair.first == "echo-client-id") ||
(config_pair.first == "match-client-id") ||
(config_pair.first == "authoritative") ||
(config_pair.first == "next-server") ||
(config_pair.first == "server-hostname") ||
(config_pair.first == "boot-file-name") ||
(config_pair.first == "server-tag") ||
(config_pair.first == "reservation-mode") ||
(config_pair.first == "reservations-global") ||
(config_pair.first == "reservations-in-subnet") ||
(config_pair.first == "reservations-out-of-pool") ||
(config_pair.first == "calculate-tee-times") ||
(config_pair.first == "t1-percent") ||
(config_pair.first == "t2-percent") ||
(config_pair.first == "cache-threshold") ||
(config_pair.first == "cache-max-age") ||
(config_pair.first == "hostname-char-set") ||
(config_pair.first == "hostname-char-replacement") ||
(config_pair.first == "ddns-send-updates") ||
(config_pair.first == "ddns-override-no-update") ||
(config_pair.first == "ddns-override-client-update") ||
(config_pair.first == "ddns-replace-client-name") ||
(config_pair.first == "ddns-generated-prefix") ||
(config_pair.first == "ddns-qualifying-suffix") ||
(config_pair.first == "ddns-update-on-renew") ||
(config_pair.first == "ddns-use-conflict-resolution") ||
(config_pair.first == "ddns-conflict-resolution-mode") ||
(config_pair.first == "ddns-ttl-percent") ||
(config_pair.first == "store-extended-info") ||
(config_pair.first == "statistic-default-sample-count") ||
(config_pair.first == "statistic-default-sample-age") ||
(config_pair.first == "early-global-reservations-lookup") ||
(config_pair.first == "ip-reservations-unique") ||
(config_pair.first == "reservations-lookup-first") ||
(config_pair.first == "parked-packet-limit") ||
(config_pair.first == "allocator") ||
(config_pair.first == "offer-lifetime") ) {
CfgMgr::instance().getStagingCfg()->addConfiguredGlobal(config_pair.first,
config_pair.second);
continue;
}
```
global scalar parameters v6:
```plaintext
if ( (config_pair.first == "renew-timer") ||
(config_pair.first == "rebind-timer") ||
(config_pair.first == "preferred-lifetime") ||
(config_pair.first == "min-preferred-lifetime") ||
(config_pair.first == "max-preferred-lifetime") ||
(config_pair.first == "valid-lifetime") ||
(config_pair.first == "min-valid-lifetime") ||
(config_pair.first == "max-valid-lifetime") ||
(config_pair.first == "decline-probation-period") ||
(config_pair.first == "dhcp4o6-port") ||
(config_pair.first == "server-tag") ||
(config_pair.first == "reservation-mode") ||
(config_pair.first == "reservations-global") ||
(config_pair.first == "reservations-in-subnet") ||
(config_pair.first == "reservations-out-of-pool") ||
(config_pair.first == "calculate-tee-times") ||
(config_pair.first == "t1-percent") ||
(config_pair.first == "t2-percent") ||
(config_pair.first == "cache-threshold") ||
(config_pair.first == "cache-max-age") ||
(config_pair.first == "hostname-char-set") ||
(config_pair.first == "hostname-char-replacement") ||
(config_pair.first == "ddns-send-updates") ||
(config_pair.first == "ddns-override-no-update") ||
(config_pair.first == "ddns-override-client-update") ||
(config_pair.first == "ddns-replace-client-name") ||
(config_pair.first == "ddns-generated-prefix") ||
(config_pair.first == "ddns-qualifying-suffix") ||
(config_pair.first == "ddns-update-on-renew") ||
(config_pair.first == "ddns-use-conflict-resolution") ||
(config_pair.first == "ddns-conflict-resolution-mode") ||
(config_pair.first == "ddns-ttl-percent") ||
(config_pair.first == "store-extended-info") ||
(config_pair.first == "statistic-default-sample-count") ||
(config_pair.first == "statistic-default-sample-age") ||
(config_pair.first == "early-global-reservations-lookup") ||
(config_pair.first == "ip-reservations-unique") ||
(config_pair.first == "reservations-lookup-first") ||
(config_pair.first == "parked-packet-limit") ||
(config_pair.first == "allocator") ||
(config_pair.first == "pd-allocator") ) {
CfgMgr::instance().getStagingCfg()->addConfiguredGlobal(config_pair.first,
config_pair.second);
continue;
}
```
lists might not be complete. need to check.
only few parameters are checked - one is valid-lifetime:
```plaintext
void
sanityChecks(const SrvConfigPtr& cfg, const ConstElementPtr& global) {
/// Global lifetime sanity checks
cfg->sanityChecksLifetime("valid-lifetime");
/// Shared network sanity checks
const SharedNetwork4Collection* networks = cfg->getCfgSharedNetworks4()->getAll();
if (networks) {
sharedNetworksSanityChecks(*networks, global->get("shared-networks"));
}
}
```
some are not checked even by processDhcp\[4|6\]Config:
```plaintext
if (allow_packet_park) {
// Get the parking limit. Parsing should ensure the value is present.
uint32_t parked_packet_limit = 0;
data::ConstElementPtr ppl = CfgMgr::instance().getCurrentCfg()->
getConfiguredGlobal(CfgGlobals::PARKED_PACKET_LIMIT);
if (ppl) {
parked_packet_limit = ppl->intValue();
}
if (parked_packet_limit) {
auto const& parking_lot =
ServerHooks::getServerHooks().getParkingLotPtr(hook_label);
if (parking_lot && (parking_lot->size() >= parked_packet_limit)) {
// We can't park it so we're going to throw it on the floor.
LOG_DEBUG(packet4_logger, DBGLVL_PKT_HANDLING, parking_lot_full_msg)
.arg(parked_packet_limit)
.arg(query->getLabel());
isc::stats::StatsMgr::instance().addValue("pkt4-receive-drop",
static_cast<int64_t>(1));
rsp.reset();
return;
}
}
```backloghttps://gitlab.isc.org/isc-projects/bind9/-/issues/4540RFC 9471 DNS Glue Requirements in Referral Responses2024-02-08T10:27:45ZPeter DaviesRFC 9471 DNS Glue Requirements in Referral Responses[RFC 9471](https://www.rfc-editor.org/rfc/rfc9471.html) - DNS Glue Requirements in Referral Responses
It would be of help to users to implement RFC 9471 and allow BIND to reply TC=1 when
glue records would make a UDP reply larger than...[RFC 9471](https://www.rfc-editor.org/rfc/rfc9471.html) - DNS Glue Requirements in Referral Responses
It would be of help to users to implement RFC 9471 and allow BIND to reply TC=1 when
glue records would make a UDP reply larger than the maxium allowed.
3.2. Glue for Sibling Domain Name Servers
This document clarifes that when a name server generates a referral response, it
include all available glue records in the additional section. If, after adding glue for all in-domain
name servers, the glue for all sibling domain name servers does not ft due to message size
constraints, the name server set TC=1 but is not obligated to do so.BIND 9.19.xhttps://gitlab.isc.org/isc-projects/kea/-/issues/3223kea v4 returns status-get 0 when not connected to database2024-02-21T09:17:05ZMarcin Godzinakea v4 returns status-get 0 when not connected to databaseDuring the missing lease database connection process, we send 'status-'get' to Kea.
Kea v6 returns:
```
{
"result": 1,
"text": "Error during command processing: no current lease manager is available"
}
```
Kea v4 returns norm...During the missing lease database connection process, we send 'status-'get' to Kea.
Kea v6 returns:
```
{
"result": 1,
"text": "Error during command processing: no current lease manager is available"
}
```
Kea v4 returns normal status:
```
{
"arguments": {
"multi-threading-enabled": true,
(...)
"uptime": 4
},
"result": 0
}
```
Getting result 0 on kea4 is misleading when there is no database connection.
**These features should be included in tests `tests/dhcp/test_database.py::test_db_retry*`. Please inform QA about the merging solution for this issue.**next-stable-2.6https://gitlab.isc.org/isc-projects/bind9/-/issues/4538duplicate TLS session tickets from BIND2024-01-17T18:01:29ZPetr Špačekpspacek@isc.orgduplicate TLS session tickets from BIND### Summary
BIND sends **two** TLS session tickets in a row, in the same TCP frame. This looks like a bug. Probably no real-world impact except consuming a bit of extra bandwidth.
### BIND version affected
* ~"Affects v9.19" : e39b5447...### Summary
BIND sends **two** TLS session tickets in a row, in the same TCP frame. This looks like a bug. Probably no real-world impact except consuming a bit of extra bandwidth.
### BIND version affected
* ~"Affects v9.19" : e39b544704b98ddd8a19e317373b84ac74597f76 - noticed while testing !8646
* ~"Affects v9.18" : 071de1b5b54c27b1291bd97e3a95a93b1996eddc - isc-private/bind9!585
### Steps to reproduce
1. SSLKEYLOGFILE=/tmp/tlskeys /tmp/4527-improve-tls-framing-for-dot/sbin/named -g -c /tmp/named.conf
2. sudo tcpdump -i lo -w /tmp/tls.pcap 'port 853'
3. dig @127.0.0.1 +tls
- [tls.pcap](/uploads/e5836a9693d76f117c9e5c80f15cf2b1/tls.pcap)
- [tlskeys](/uploads/76d398d1c33b7eb90f4c7a14ff27a644/tlskeys)
### What is the current *bug* behavior?
For some reason BIND sends **two** TLS session tickets in a row, in the same TCP frame.
<details>
```
Frame 10: 608 bytes on wire (4864 bits), 608 bytes captured (4864 bits)
Ethernet II, Src: 00:00:00:00:00:00, Dst: 00:00:00:00:00:00
Internet Protocol Version 4, Src: 127.0.0.1, Dst: 127.0.0.1
Transmission Control Protocol, Src Port: 853, Dst Port: 46779, Seq: 766, Ack: 476, Len: 542
Transport Layer Security
TLSv1.3 Record Layer: Handshake Protocol: New Session Ticket
Opaque Type: Application Data (23)
Version: TLS 1.2 (0x0303)
Length: 266
[Content Type: Handshake (22)]
Handshake Protocol: New Session Ticket
Handshake Type: New Session Ticket (4)
Length: 245
TLS Session Ticket
Session Ticket Lifetime Hint: 7200 seconds (2 hours)
Session Ticket Age Add: 1399829672
Session Ticket Nonce Length: 8
Session Ticket Nonce: 0000000000000000
Session Ticket Length: 224
Session Ticket [truncated]: 5f2c5c7290f6b002e39631b54f85b14de2620e615663e5e3a2a5c5194a3e5c47d5da9fc257200fe4318de304b2471b4a1f35607e53e0a3eb04e00421e2539bcdbf486e60ec9900448831dc70c1dcb081c0890d04c337dbe4aef4806dd5004019a0a7edfabbf17de7590
Extensions Length: 0
TLSv1.3 Record Layer: Handshake Protocol: New Session Ticket
Opaque Type: Application Data (23)
Version: TLS 1.2 (0x0303)
Length: 266
[Content Type: Handshake (22)]
Handshake Protocol: New Session Ticket
Handshake Type: New Session Ticket (4)
Length: 245
TLS Session Ticket
Session Ticket Lifetime Hint: 7200 seconds (2 hours)
Session Ticket Age Add: 310059667
Session Ticket Nonce Length: 8
Session Ticket Nonce: 0000000000000001
Session Ticket Length: 224
Session Ticket [truncated]: 5f2c5c7290f6b002e39631b54f85b14dc423d6b1f00ccd25e30d7cf9290c0dc32d8ed4b9c72a8e3555d9ccdba4b3b6299e5306c5bf9ca48f72325e23927d1e9ae572d8937faedeb7b5846b4f8817bef5e537a5ff8e516c20f520ebb535ab37fa64996854d10dcee1291
Extensions Length: 0
```
</details>
### What is the expected *correct* behavior?
I would expect just one ticket.Artem BoldarievArtem Boldarievhttps://gitlab.isc.org/isc-projects/stork/-/issues/1281Deserialize the Kea JSON config lazily2024-01-16T14:48:41ZSlawek FigielDeserialize the Kea JSON config lazilyDeserializing the big Kea config JSON is a very memory-consuming operation. It is stored in the `config` column in the `kea_daemon` table.
The entries of this table are used in many contexts in Stork. Whenever they are fetched, the JSON ...Deserializing the big Kea config JSON is a very memory-consuming operation. It is stored in the `config` column in the `kea_daemon` table.
The entries of this table are used in many contexts in Stork. Whenever they are fetched, the JSON content is deserialized into Go structures, even if all or significant parts of this data are unnecessary, which is quite a common situation.
My proposal is to deserialize this JSON lazily - only when the related data are needed. The solution may be based on the `RawMessage` feature of the `encoding/json` package.backloghttps://gitlab.isc.org/isc-projects/kea/-/issues/3221Minor doc update: server limitations update after ping-check2024-03-20T11:29:29ZTomek MrugalskiMinor doc update: server limitations update after ping-checkThe section 8.12 (DHCPv4 server limitations) still claims this:
> _The DHCPv4 server does not verify that an assigned address is unused. According to RFC 2131, the allocating server should verify that an address is not used by sending a...The section 8.12 (DHCPv4 server limitations) still claims this:
> _The DHCPv4 server does not verify that an assigned address is unused. According to RFC 2131, the allocating server should verify that an address is not used by sending an ICMP echo request._
This is no longer true after ping-check was implemented.kea2.6.0https://gitlab.isc.org/isc-projects/bind9/-/issues/4532An option to not have bind9/dnssec-settime (possibly other tools) reset permi...2024-01-16T20:30:36ZDan MahoneyAn option to not have bind9/dnssec-settime (possibly other tools) reset permissions on a .private file.### Description
The `named` process and `dnssec-settime` (perhaps other tools) will take it upon themselves to change the permissions of a private key on certain changes.
However, we track our key-directory (and other configs) using gi...### Description
The `named` process and `dnssec-settime` (perhaps other tools) will take it upon themselves to change the permissions of a private key on certain changes.
However, we track our key-directory (and other configs) using git, with a group-shared repository.
Typical permissions on .private files are bind:bind with mode 660, but because a normal user (in the bind group) diffs/commits/pushes the repository, these keys can also be user:bind mode 660.
(Noting as well that our tooling is not more comfortable running git tasks as root, complaining of other permissions issues. Also, the less we can do as root, the better.)
With bind's usual permissions model, one cannot do a git diff/git log if the file is owned by bind. If the file is owned by user:bind, bind loses access to it on the permissions change.
Changing the umask under which the process runs doesn't seem to fix this, we tried.
Running a periodic cron job to fix this is a possible workaround, but feels like it shouldn't be necessary.
### Request
For command line tools, an option to not do this.
For `named, an `options` statement that lets us turn this off.
Both retaining the current behavior by default.
### Links / referencesNot plannedhttps://gitlab.isc.org/isc-projects/kea/-/issues/3220Debian apt repository setup installs `apt-transport-https` dummy package2024-03-14T14:31:13ZDirk HeinrichsDebian apt repository setup installs `apt-transport-https` dummy packagePlease stop installing that package. It's a dummy since Debian Buster/Ubuntu 18.04.Please stop installing that package. It's a dummy since Debian Buster/Ubuntu 18.04.outstandingTomek MrugalskiTomek Mrugalskihttps://gitlab.isc.org/isc-projects/stork/-/issues/1278Backend profiler and performance monitor2024-01-16T14:43:02ZSlawek FigielBackend profiler and performance monitorTo improve the quality of our solutions, I propose to add to the Stork project the following:
- Profiler for the backend unit tests
- On-demand profiler for currently executed Stork server or agent
- Performance monitor for system tests...To improve the quality of our solutions, I propose to add to the Stork project the following:
- Profiler for the backend unit tests
- On-demand profiler for currently executed Stork server or agent
- Performance monitor for system tests
These components were implemented to recognize the cause of the performance problems reported in #1263.1.16https://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/3218Kea dhcp v4 server ip reservation configuration using uuid-guid (dhcp option ...2024-03-26T13:17:34ZBenoit SansoniKea dhcp v4 server ip reservation configuration using uuid-guid (dhcp option 97; rfc 4578)Hi,
I would like to set a dhcp v4 reservation ip using "uuid-guid" (that correspond to dhcp option 97 / RFC 4578).
This is my current kea server configuration using an hardware address that works fine :
"reservations": [...Hi,
I would like to set a dhcp v4 reservation ip using "uuid-guid" (that correspond to dhcp option 97 / RFC 4578).
This is my current kea server configuration using an hardware address that works fine :
"reservations": [
{
"hostname": "board",
"hw-address": "01:02:03:04:05:06",
"ip-address": "192.168.0.2",
"option-data": [
{
"name": "boot-file-name",
"data": "file.bin"
}
]
},
When I replaced in this configuration the hw-address by "uuid-guid", the "uuid-guid" filed is not expected by kea dhcp server.
In the documentation I can see that the default host reservation identifiers are:
"host-reservation-identifiers": [ "circuit-id", "hw-address", "duid", "client-id" ]
Is the "uuid-guid" is supported for IP reservation ?
Is it a feature that will be developped in the future ?
If the reservation with "uuid-guid" identifier is supported, What should configuration need to be applied ?
Thanks in advance for your help
Benoitoutstandinghttps://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/stork/-/issues/1276github-friendly security policy2024-01-16T14:41:55ZTomek Mrugalskigithub-friendly security policyThis is mostly to check off some extra check boxes on github.
Something similar as we have in Kea: [Kea security policy](https://github.com/isc-projects/kea/security/policy).
This is just writing down what we already have spread out in...This is mostly to check off some extra check boxes on github.
Something similar as we have in Kea: [Kea security policy](https://github.com/isc-projects/kea/security/policy).
This is just writing down what we already have spread out in several places, condensed and formatted in github friendly format. No specific process changes proposed.1.16Tomek MrugalskiTomek Mrugalskihttps://gitlab.isc.org/isc-projects/kea/-/issues/3216Setting YANG list elements with singlequotes in key values is not possible in...2024-01-18T14:58:00ZAndrei Pavelandrei@isc.orgSetting YANG list elements with singlequotes in key values is not possible in our unit testing frameworkOur internal NETCONF test framework in the form of `YangRepr`, particularly the `YangRepr::set` functionality does not support setting list elements that have singlequotes in the value of a key. This is because setting a node is done by ...Our internal NETCONF test framework in the form of `YangRepr`, particularly the `YangRepr::set` functionality does not support setting list elements that have singlequotes in the value of a key. This is because setting a node is done by providing the xpath as a plain string and singlequotes are used to delimit the value of the key, so upon finding a singlequote in the value, the libyang parser thinks the value ends sooner than it actually does and does not know what to do with the rest of the xpath.
This is not a problem in production code, because production code has no need for setting YANG nodes, but instead is only concerned with retrieving them from the sysrepo datastore.
The issue may become more prevalent if issue 3198 gets merged as it was written at the time this issue was created. It makes `data` a key which is more likely to contain a singlequote than other keys, which is also why this issue became obvious there. The issue occurred in unit tests.
```
[ RUN ] ConfigTestKeaV4.examples4
libyang[0]: Invalid character 0x73 ('s'), perhaps "'Error: here'" is supposed to be a function call.
config_unittests.cc:332: Failure
Failed
json = loadFile(path) threw type: N3isc4yang12NetconfErrorE, what: setting item 'nullopt' at '/kea-dhcp4-server:config/option-data[code='56'][space='dhcp4'][data='Error: here's a DHCPNAK!']': Session::setItem: Couldn't set '/kea-dhcp4-server:config/option-data[code='56'][space='dhcp4'][data='Error: here's a DHCPNAK!']': SR_ERR_INVAL_ARG
Google Test trace:
config_unittests.cc:330:
* Tested file: /home/andrei/work/isc/kea-3198-vivso-suboptions-not-properly-supported-in-netconf/doc/examples/kea4/all-options.json
[ FAILED ] ConfigTestKeaV4.examples4 (509 ms)
```
This change was done to avoid it:
```diff
diff --git a/doc/examples/kea4/all-options.json b/doc/examples/kea4/all-options.json
index 5e7d7ccbc7..f52105691b 100644
--- a/doc/examples/kea4/all-options.json
+++ b/doc/examples/kea4/all-options.json
@@ -691,3 +691,3 @@
"code": 56,
- "data": "Error: here's a DHCPNAK!",
+ "data": "Error: here is a DHCPNAK!",
"name": "dhcp-message"
```
One may think of encoding the singlequote as Kea does with the commas in user-context under the lease CSV files. That is not ideal, if even possible, since the singlequote would need to be decoded in get unctionality which means it has an effect on production code, but moreover it might not be compatible with setting outside `YangRepr`, via e.g. sysrepocfg.outstanding