=== W2: does a production node take a DHCPv6 reservation? ===
Window of 2026-09-06, operator offline.

SHORT ANSWER: YES for the x86_64 Fedora nodes -- MAC reservations work. My first
write-up of this file said "MAC reservations do NOT match" and that was WRONG:
I read the result before a full RA/DHCPv6 cycle had completed. The timed
observation I set running (660s, one MaxRtrAdvInterval) then showed the opposite,
and a direct check confirmed it. Recording the mistake because committing the
premature version to git (3c933b9) is exactly the "assert before measuring"
failure this session has been about.

CONFIRMED, direct check 2026-09-06 ~22:47:
    worker0-k8s0  192.168.8.23  ->  2001:470:187e:2::23/128   MATCHES reservation
    worker2-k8s0  192.168.8.25  ->  2001:470:187e:2::25/128   MATCHES reservation
Both are the EXACT reserved addresses, /128, DHCPv6-assigned. The MAC-keyed
scheme -- one source of truth with IPv4 -- works for these nodes.

WHY IT WORKS DESPITE "[no hwaddr info]" IN THE KEA LOG
The DHCP6_QUERY_LABEL "[no hwaddr info]" is about whether the client sent an
explicit hardware-address option; it is NOT the reservation-matching path. For a
`hw-address` host reservation kea extracts the MAC from the client's DUID when
the DUID type carries one (DUID-LLT / DUID-LL embed the link-layer address).
NetworkManager on the Fedora nodes uses such a DUID, so kea matched ::23 and ::25
by MAC even though the query label showed no explicit hwaddr. The earlier
DUID-UUID packets I saw were from other clients, and led me to over-generalise.

NOT YET WORKING: the two arm64 nodes
    worker1-k8s0  192.168.8.13  (Fedora Asahi Remix, arm64)  -> no v6 address
    spark-2935    192.168.8.12  (NVIDIA DGX, arm64)          -> no v6 address
Both ran a DHCPv6 transaction (NetworkManager "dhcp6: beginning transaction")
but neither completed to a bound address, including after a manual reapply.
Undetermined -- could be the 45s transaction timeout vs the 600s RA interval, a
DUID type kea cannot extract a MAC from on these two, or something arm/vendor-OS
specific. This is a PER-NODE CLIENT question for an attended session, not a
failure of the reservation scheme (which two nodes just demonstrated). Do not
hand-configure these unattended.

RA HALF (unchanged, and it was always the safe finding)
RA on bond0.2 carries AdvManagedFlag on, AdvAutonomous off, AdvLinkMTU 1472,
AdvDefaultLifetime 0. NetworkManager (ipv6.method=auto) follows the managed flag
and starts DHCPv6. "ipv6.method=auto will do DHCPv6" is evidence, not inference.

A SECOND FINDING, unrelated, found live and FIXED in-window
`service dhcpv6-server` with no listen-interface renders kea6 with
interfaces: [ "*" ] -- a DHCPv6 server on EVERY VLAN. Observed answering an
unrelated device on bond0.10 (LoT) within seconds of the first apply. Same
family as the kea IPv4 cross-VLAN bug (ISC #1117). Fixed by pinning
listen-interface bond0.2 + a subnet-level interface bond0.2; both routers now
render interfaces: ["bond0.2"].

OPTION (b) mac-sources: VyOS dhcpv6-server global-parameters accepts only
name-server, so kea mac-sources cannot be passed through config, and editing
/run/kea/*.conf is banned drift (regenerated every commit). Moot now that the
default matching works for the Fedora nodes.

STILL OPEN FOR THE ATTENDED SESSION
  - the two arm64 nodes: why the DHCPv6 transaction does not complete.
  - whether to keep MAC keys (works for x86 Fedora, unproven for arm) or move to
    DUID keys / a dynamic range + labctl discovery for uniformity.