docs: AT&T PD is a hard /64 at NH3, tested on the wire

AT&T support guessed 'I do not believe att will do that' from a DNS
provisioning desk. The guess was correct, but it needed proving rather
than accepting, so the UDM solicited DHCPv6-PD at /48, /56 and /60. All
three returned the same single /64. This is not a case of nobody having
asked -- the ask was made three ways.

Proven by temporarily enabling PD on nh3-iot, the only NH3 VLAN with
zero clients, then setting ipv6_pd_prefixid to 0, 15 and 16. All three
returned an identical c11f prefix, which only happens when exactly one
/64 is delegated; with a larger block the prefix-id moves the LAN within
it.

Records a mistake worth not repeating: I first read the gap between the
WAN address (c110) and the delegated prefix (c11f) as evidence of a /60.
It is not -- AT&T assigns those from different parts of their pool and
the spread means nothing.

NH3 was fully restored afterwards, with rollback artifacts kept. Also
captures the concrete ask for AT&T Business, phrased as something their
provisioning team can verify against their own DHCPv6 logs, and the
consequence if refused: NH3 can host exactly one v6 segment against
ESH's 256.

persistent-memory.md

@@ -127,6 +127,8 @@ _As of 2026-08-18 — **gen seat SWAPPED to `absolute-heresy` and operator-confi
 
 - **EVIDENCE HOLD (partial):** WT #394 FILE half STILL STANDS — do NOT delete on-disk gen dirs (`fiction/rex390-dcc`, `rex392-dcc`, `b59c147c5ce0`); rex393-fiction-* + r42-gate-* KEEP.
 
+- **🔴 NH3/AT&T IPv6 PD is a HARD `/64` — TESTED ON THE WIRE 2026-08-19, not inferred.** AT&T support (Christopher, `prov-dns@att.com`) said "I do not believe att will do that" and punted to consumer sales — **and he was right, though his team is DNS provisioning and the answer was a guess.** Verified empirically: the NH3 UDM solicited DHCPv6-PD at **/48, /56 AND /60** and AT&T returned **the same single `/64` (`2600:1700:b25:c11f::/64`) every time**. So it is NOT "nobody ever asked" — the request was made three ways and the server answers `/64` regardless. **How it was proven:** the PD is invisible until a LAN claims it, so `nh3-iot` (the only NH3 VLAN with **0 clients**) was temporarily set `ipv6_interface_type: pd`; then `ipv6_pd_prefixid` was set to 0, 15 and 16 — **all three returned the identical `c11f` prefix**, which is the signature of a single delegated `/64` (with any larger block the prefix-id moves the LAN within it). ⚠ **Do NOT read the WAN address vs LAN prefix gap as evidence of block size** — WAN is `c110`, delegated is `c11f`, and I initially misread that spread as a `/60`; AT&T just assigns the two from different places in their pool. **NH3 UDM was fully restored** (nh3-iot back to `none`, WAN back to `pd_size=64`); rollback artifacts at `nh3-dev:~/backups/nh3-udm/`. **THE ASK FOR AT&T BUSINESS** (this is business fiber at a commercial park — the residential org cannot change it, and 800-288-2020 is the wrong number): *"circuit solicits DHCPv6-PD at /48, /56 and /60; server returns a single /64 in all three cases; please increase the delegation size on the provisioning profile"* — a claim they can verify against their own DHCPv6 logs. Consequence if they refuse: **NH3 can only ever have ONE v6 segment**, vs ESH's `/56` (256), which makes NH3 the prefix-constrained site in any fleet v6 design.
+
 - **⏳ COGENT IPv6 PROVISIONING REQUESTED for Anaheim/colo (operator, 2026-08-19).** The colo is the last site with no v6 (ESH has a `/56` from Cityside, NH3 has AT&T v6 on `2600:1700:b25:c110::48`). **Diagnosis from our side before the ticket:** `diagnose sniffer packet wan1 "ip6"` on ana-gw caught **exactly one RA in 90s, from `fe80::ea0a:b9ff:fe3b:2c16`** — so an IPv6-capable router IS one hop away on the circuit terminating `38.120.12.42/29` — but `set autoconf enable` (SLAAC) got no global address after 2min of RA intervals, and `execute ping6` to both `2606:4700:4700::1111` and `2001:4860:4860::8888` was 100% loss. **That pattern = router present, circuit not provisioned for v6** (RA likely carries no Prefix Information Option). FortiGate-side v6 config was **fully reverted** after testing — `wan1` is back to no v6, v4/IPsec untouched throughout. ⚠ FortiOS gotcha for when it lands: SLAAC is `config ipv6 / set autoconf enable`, NOT an `ip6-mode` (that only takes static/dhcp/pppoe/delegated). **WHEN COGENT PROVISIONS:** ask for DHCPv6-PD size (ESH got a `/56` from Cityside; NH3 only gets a single `/64` from AT&T, so a `/56` or better is the ask), then the colo becomes the fleet's only site with BOTH a static public v4 (`38.120.12.42`) and routable v6 — which makes it the natural v6 hub, since ESH is CGNAT'd on v4 and NH3 is prefix-constrained.
 
 - **🟡 ESH IPv6 LAN naming — a DOCS CONVENTION ONLY, not wire-level.** Fun hexspeak names picked 2026-08-18 for the six ESH LANs: **RESERVED for a future DMZ** = **4411:DBAD** ("FOR ALL DA BAD" — no DMZ network exists on the ESH UDM yet; name claimed 2026-08-19 against the day one is built). `esh-cameras`=**1533:FACE5** ("I SEE FACES" — operator's pick 2026-08-19, and the best of the set), `esh-mgmt`=**15DA:B055** ("IS DA BOSS" — 15=IS, DA literal, B055=BOSS; revised 2026-08-19), `esh-server`=**4411:B105** ("FOR ALL BIOS" — operator's pick 2026-08-19; shares the 411 with userland's CAFE:4411), `esh-userland`=**CAFE:4411** ("CAFE FOR ALL" — operator's pick 2026-08-19; 411 also being US directory assistance is a bonus), `esh-iot`=**4DBA:D107** ("FOR DA BAD IOT" — 4=FOR, D=DA, BAD, 107=IOT; same 8 digits, re-glossed 2026-08-19), Default=**4BA5:3417** ("A BASE FOR IT" — operator's pick 2026-08-19; 8 digits, words straddle the group boundary like `4DBA:D107`). **Investigated and confirmed these CANNOT be made literal on the wire**: (1) a network's only nameable slot is its `/64` subnet id (`ipv6_pd_prefixid`), which is 2 hex digits (0-255) — not enough room to spell a 4-char word; (2) the gateway's own address is fixed at `::1` by the UniFi platform, no field to customize it (`ipv6_aliases` exists but schema unknown, not attempted blind); (3) UniFi has **no IPv6 equivalent of `use_fixedip`/`fixed_ip`** (checked the client schema directly) — individual devices cannot be pinned to a chosen v6 address the way v4 static reservations work; SLAAC devices self-assign via EUI-64 (MAC-derived, stable) or privacy-extension (random, rotates). So the names are a mnemonic for humans/docs, not something that will ever appear in a `dig`/`ip -6` output. Only `esh-cameras` has v6 live at all (`2607:73c0:402:1d00::/64`, PD from the ESH `/56`); the other five stay `ipv6_interface_type: none` pending a firewall-policy pass before enabling SLAAC fleet-wide. ⚠ **Precision that matters here: SLAAC gives hosts globally *ADDRESSABLE* addresses, NOT globally *reachable* ones.** Addressability is a property of the address; reachability is a firewall policy decision, and operator's position (2026-08-19) is unambiguous — **no 1:1 inbound pass-through, ever**. v6 removes NAT, it does not remove the firewall, and conflating the two is how people talk themselves into thinking v6 means automatic exposure. The firewall-policy pass is about writing explicit default-deny inbound rules for each v6 segment, not about deciding whether to expose anything.