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

SHORT ANSWER: the RA half works; the RESERVATION half does not, and the reason
is structural rather than a misconfiguration.

WHAT WORKS
  - RA is emitted on bond0.2 with AdvManagedFlag on, AdvAutonomous off,
    AdvLinkMTU 1472, AdvDefaultLifetime 0 (deliberately not a default router).
  - NetworkManager on worker0 SAW it and acted: 
      dhcp6 (eno1): activation: beginning transaction (timeout in 45 seconds)
    So "ipv6.method=auto follows the managed flag" is now EVIDENCE, not
    inference. That was the open question this window set out to close.
  - kea-dhcp6 runs on both routers and receives SOLICITs on bond0.2.

WHAT DOES NOT WORK, AND WHY
  Every DHCPv6 packet kea logs is annotated [no hwaddr info]:

    duid=[00:04:69:d9:30:64:c3:4e:...]  [no hwaddr info]   <- DUID-UUID (type 4)
    duid=[00:04:25:11:e0:0a:7b:c4:...]  [no hwaddr info]   <- DUID-UUID
    duid=[00:01:00:01:31:78:0a:ae:...]  [no hwaddr info]   <- DUID-LLT (type 1)

  DHCPv6 identifies a client by DUID, not by MAC. kea can sometimes DERIVE a MAC
  (its mac-sources machinery), but here it derives nothing -- including from a
  DUID-LLT, which does embed one. So `hw-address` reservations cannot match, and
  a node that solicits gets no reserved address.

  VyOS accepting `static-mapping <name> mac` is therefore necessary but NOT
  sufficient: it renders valid kea config ("hw-address": "78:55:36:08:28:fb",
  confirmed in /run/kea/kea-dhcp6.conf) that simply never matches these clients.
  The plan's assumption -- "reservations keyed on MAC, one source of truth with
  IPv4" -- does not survive contact with DHCPv6.

OPTIONS, none free, for an attended session:
  a) Key reservations on DUID (VyOS static-mapping supports `duid`). Works, but a
     DUID is client-generated: it is a SECOND source of truth, it must be
     harvested per node, and it changes if a node is rebuilt -- which is exactly
     the "out of the box for new nodes" property we were trying to preserve.
  b) Set kea `mac-sources` explicitly and see whether any method recovers a MAC
     from these clients. Cheap to try; may simply not work for DUID-UUID.
  c) Drop reservations: hand out a dynamic range and have labctl DISCOVER the
     node's address rather than predict it. The k3s preflight (914135c) already
     refuses to write a node-ip the node does not hold, so discovery is safe --
     but the address is then not knowable before the node boots.
  d) SLAAC with no-autonomous cleared, and accept EUI-64 addresses. Stable per
     NIC and needs no server state at all, but the address is not ours to choose.

A SECOND FINDING, unrelated and worse if unnoticed
  `service dhcpv6-server` with no listen-interface renders kea6 with
  interfaces: [ "*" ] -- a DHCPv6 server on EVERY VLAN. Observed live: kea began
  answering SOLICIT/REQUEST from an unrelated device on bond0.10 (LoT) within
  seconds of the first apply. Same family as the kea IPv4 cross-VLAN bug (ISC
  #1117) this estate already fought. Fixed by pinning
  `set service dhcpv6-server listen-interface bond0.2` plus a subnet-level
  `interface bond0.2`; both routers now render interfaces: ["bond0.2"].