docs: park the BGW210 v6 work pending the Device Access Code

Operator will retrieve the BGW210 Device Access Code from the NH3 office
and vault it, after which the IPv6 LAN settings page can be driven
remotely.

Parked on the henge as reclaim-nh3-s-7-unclaimed-ipv6-64s-from-the with
everything needed to resume cold: the verified facts about the /60 split
and the seven unclaimed prefixes, why AT&T cannot fix it, the exact page
to start at, what to look for in priority order, the other settings
pages behind the same login, and the wpa_supplicant fallback with its
warning about modifying NH3's only uplink.

Suggested vault path unifi/bgw210-nh3-device-access-code, matching the
existing unifi/* credentials.

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. **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.
+- **🔴 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. **⏳ PARKED pending the Device Access Code:** `reclaim-nh3-s-7-unclaimed-ipv6-64s-from-the` on the henge. Operator will fetch the BGW210 Device Access Code (12 digits, on the unit's label) next time he is at the NH3 office and **vault it — suggested path `unifi/bgw210-nh3-device-access-code` — after which this is drivable remotely.** First stop is `http://192.168.1.254/cgi-bin/ip6lan.ha` (**confirmed to exist, currently redirects to Login**); check for a delegation size/count control, a v6 pass-through/bridge option, or a way to stop the BGW reserving `c110`-`c117`. If the UI can do it, that is a SUPPORTED fix and the wpa_supplicant bypass is unnecessary. Other settings pages behind the same login: `ippass.ha` (how v4 passthrough was set up), `dhcpserver.ha`, `firewall.ha`, `broadbandconfig.ha`, `packetfilter.ha`, `remoteaccess.ha`, `restart.ha`. 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.