docs: NH3 v6 root cause is the BGW210, and seven /64s are unclaimed

Operator suggested checking the BGW on its 192.x management address,
which turned out to give the whole picture from unauthenticated status
pages.

The CPE is a BGW210-700 on firmware 4.28.7 at 192.168.1.254. AT&T does
hand it a /60 -- c110 through c11f. The BGW keeps c110-c117 for itself
and re-delegates up to eight individual /64s on c118-c11f, top-down. Our
UDM holds c11f, delegation number eight.

So the earlier conclusion that AT&T only grants a /64 was right about
the symptom and wrong about the cause. Seven further /64s are available
and simply never solicited, because UniFi exposes a single
wan_dhcpv6_pd_size integer with no field for how many prefixes to
request. The documented workaround is repeated -P flags to dhclient,
which the UniFi UI cannot express.

This also settles that an AT&T ticket cannot help: the rationing is CPE
firmware behaviour, not provisioning. Records the two real options --
accept one /64, or bypass the BGW entirely with wpa_supplicant EAP-TLS
on the UDM to negotiate the full /60 -- with the warning that the latter
modifies NH3's only uplink and needs a planned window.

persistent-memory.md

@@ -127,7 +127,7 @@ _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.
+- **🔴 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. **ROOT CAUSE FOUND 2026-08-19 — it is the BGW, not AT&T, and EIGHT /64s are actually available.** The CPE is a **BGW210-700, firmware 4.28.7**,management reachable at **`http://192.168.1.254`** (v4 is already IP-passthrough — the UDM holds public `70.230.226.88` directly — but passthrough covers v4 ONLY; v6 always terminates on the BGW). Its `/cgi-bin/lanstatistics.ha` and `/cgi-bin/broadbandstatistics.ha` are readable unauthenticated and give the whole picture: BGW WAN v6 = `2001:506:70b2:8958::1`, **BGW LAN v6 = `2600:1700:b25:c110::/64` (it keeps this for itself)**, delegated to the UDM = `2600:1700:b25:c11f::/64`. **So AT&T DOES hand the BGW a `/60`** (`c110`-`c11f`); the BGW keeps `c110`-`c117` and re-delegates **up to EIGHT individual `/64`s on `c118`-`c11f`**, top-down. Our UDM got `c11f` = delegation #8. **The other seven are sitting unclaimed** — not withheld by AT&T, just never solicited, because **UniFi exposes only a single `wan_dhcpv6_pd_size` integer and no 'number of prefixes' field**, so it asks once. The documented workaround is `dhclient -6 -P -P -P...` (one `-P` per prefix), which UniFi cannot express. ⇒ **An AT&T ticket CANNOT fix this** — it is CPE firmware behaviour, so Christopher's 'att won't do that' was accidentally right. Real options: (a) accept one `/64`; (b) **full BGW bypass via wpa_supplicant/EAP-TLS on the UDM** (documented working on UDM Pro; extract the BGW's 802.1X certs, authenticate to AT&T directly, negotiate the whole `/60` yourself) — ⚠ modifies NH3's ONLY uplink and must survive UDM firmware updates, so it needs a planned window with physical access, NOT an ad-hoc change. Consequence if left alone: **NH3 has 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.