diff --git a/docs/pfi/ipv6-naming-scheme.md b/docs/pfi/ipv6-naming-scheme.md
index 88cf470..1cfab74 100644
--- a/docs/pfi/ipv6-naming-scheme.md
+++ b/docs/pfi/ipv6-naming-scheme.md
@@ -113,21 +113,59 @@ observed to actually move.
 
 ## Deployed
 
-| host | address | status |
-|---|---|---|
-| `esh-docker-vm` (AdGuard) | `2607:73c0:402:1d02:4411:b105:50:45` | **live** 2026-08-24 |
+All three Linux hosts on `esh-server` now carry the segment name, with the last
+two groups reading straight off their IPv4 address:
 
-This is not decorative. The ESH UDM advertises an IPv6 resolver to clients 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
-pointed at AdGuard's **MAC-derived SLAAC address**, which would break if that
-VM's NIC ever changed. It now points at the scheme address, which will not.
+| host | address | v4 | applied via |
+|---|---|---|---|
+| `esh-docker-vm` (AdGuard) | `2607:73c0:402:1d02:4411:b105:50:45` | 10.0.50.45 | `if-up.d` on `ens18` |
+| `esh-pve-nas` | `2607:73c0:402:1d02:4411:b105:50:55` | 10.0.50.55 | `if-up.d` on `vmbr0` |
+| `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
-(`dhcpdv6_dns_auto=false` + `dhcpdv6_dns_1=<address>`); verified on the wire by
-soliciting an RA and parsing option type 25. See
-[`reference_unifi_dns_rdnss_limits`] in auto-memory for why that field is only
-honoured when an explicit server is supplied.
+`esh-docker-vm`'s is load-bearing, not decorative: the ESH UDM advertises an
+IPv6 resolver to clients via RDNSS, macOS prefers it over the DHCPv4-supplied
+one, so whatever sits there is what resolves `*.internal` for every Mac on the
+network. It previously pointed at AdGuard's **MAC-derived SLAAC address**, which
+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`.