docs(ipv6): all three esh-server hosts now carry the segment name

esh-pve-nas and esh-vm-db join esh-docker-vm on 4411:b105, at
:50:55 and :50:60 respectively, each applied by the same prefix-deriving
if-up.d hook so the last two groups read straight off the IPv4 address.

Two obstacles are recorded because both will recur. The Proxmox node had
link-local only despite every relevant sysctl appearing correct, because
its bridge carries per-interface forwarding and the kernel ignores router
advertisements on a forwarding interface unless accept_ra is explicitly
two rather than one. The fix takes the advertised prefix while declining
the default route, so the hypervisor gains an address without any change
to how it routes; this was verified after applying, with the v6 default
route count still at zero.

The database VM refuses key authentication for the privileged accounts
and its unprivileged login cannot escalate without a password, so the
hook went in through the QEMU guest agent from the hypervisor, which
executes as root inside the guest. The document notes the base64
indirection needed to get a multi-line script through intact.

docs/pfi/ipv6-naming-scheme.md

@@ -113,21 +113,59 @@ observed to actually move.
 
 ## Deployed
 
-| host | address | status |
+All three Linux hosts on `esh-server` now carry the segment name, with the last
-|---|---|---|
+two groups reading straight off their IPv4 address:
-| `esh-docker-vm` (AdGuard) | `2607:73c0:402:1d02:4411:b105:50:45` | **live** 2026-08-24 |
 
-This is not decorative. The ESH UDM advertises an IPv6 resolver to clients via
+| host | address | v4 | applied via |
-RDNSS, and macOS prefers it over the DHCPv4-supplied one — so whatever sits
+|---|---|---|---|
-there is what resolves `*.internal` for every Mac on the network. It previously
+| `esh-docker-vm` (AdGuard) | `2607:73c0:402:1d02:4411:b105:50:45` | 10.0.50.45 | `if-up.d` on `ens18` |
-pointed at AdGuard's **MAC-derived SLAAC address**, which would break if that
+| `esh-pve-nas` | `2607:73c0:402:1d02:4411:b105:50:55` | 10.0.50.55 | `if-up.d` on `vmbr0` |
-VM's NIC ever changed. It now points at the scheme address, which will not.
+| `esh-vm-db` | `2607:73c0:402:1d02:4411:b105:50:60` | 10.0.50.60 | `if-up.d` on `ens18` |
 
-Both `esh-userland` and `esh-server` advertise it
+`esh-docker-vm`'s is load-bearing, not decorative: the ESH UDM advertises an
-(`dhcpdv6_dns_auto=false` + `dhcpdv6_dns_1=<address>`); verified on the wire by
+IPv6 resolver to clients via RDNSS, macOS prefers it over the DHCPv4-supplied
-soliciting an RA and parsing option type 25. See
+one, so whatever sits there is what resolves `*.internal` for every Mac on the
-[`reference_unifi_dns_rdnss_limits`] in auto-memory for why that field is only
+network. It previously pointed at AdGuard's **MAC-derived SLAAC address**, which
-honoured when an explicit server is supplied.
+would have broken if that VM's NIC ever changed. Both `esh-userland` and
+`esh-server` now advertise the scheme address instead
+(`dhcpdv6_dns_auto=false` + `dhcpdv6_dns_1=<address>`), verified on the wire by
+soliciting an RA and parsing option type 25.
+
+### ⚠ Proxmox bridges need `accept_ra=2` or SLAAC never runs
+
+`esh-pve-nas` had **link-local only** despite `accept_ra=1`, `autoconf=1` and
+IPv6 enabled — every sysctl looked correct. The cause: **`vmbr0.forwarding = 1`**
+(Proxmox sets per-interface forwarding on bridges), and the kernel ignores RAs on
+a forwarding interface unless `accept_ra` is explicitly **`2`**. `accept_ra=1`
+means "accept only if not forwarding", so it silently did nothing.
+
+Fixed in `/etc/sysctl.d/60-ipv6-accept-ra.conf` on that host:
+
+```
+net.ipv6.conf.vmbr0.accept_ra = 2
+net.ipv6.conf.vmbr0.accept_ra_defrtr = 0
+```
+
+`accept_ra_defrtr=0` is deliberate — it takes the advertised **prefix** (so
+SLAAC configures an address) while **declining the default route**, so a
+hypervisor gains an IPv6 identity with no change to its routing behaviour.
+Verified after: SLAAC address present, v6 default routes still **0**, v4 intact.
+
+Expect the same on any other Proxmox node when its LAN gets IPv6.
+
+### Getting into a host with no direct root
+
+`esh-vm-db` refuses key auth for `root` and `infra-ops`, and `lkraven`'s sudo
+wants a password. It is VMID 101 on `esh-pve`, and the **QEMU guest agent** runs
+as uid 0 inside it, so the hook was installed with:
+
+```
+qm guest exec 101 -- /bin/sh -c 'echo <base64> | base64 -d > /etc/network/if-up.d/... '
+```
+
+base64 because quoting a multi-line script through two SSH layers mangles it.
+Worth remembering as the general path for guests whose credentials are not
+vaulted.
 
 Natural next candidates, both on `esh-server` and both real Linux hosts:
 `esh-pve-nas` → `…:4411:b105:50:55`, `esh-vm-db` → `…:4411:b105:50:60`.