From bd209951ac9ea98c214c25c96deaedec0721a43f Mon Sep 17 00:00:00 2001 From: Vuong Hoang Date: Mon, 24 Aug 2026 07:02:53 -0700 Subject: [PATCH] =?UTF-8?q?docs(ipv6):=20correct=20the=20NH3=20delegation?= =?UTF-8?q?=20finding=20=E2=80=94=20eight=20/64s,=20not=20one?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit The note concluded AT&T delegates a single /64 and that reading the address pattern as a /60 was a mistake. A later finding in the same session overturned that by reading the BGW's own statistics page, and that correction was never written down; it survived only in the transcript and surfaced again while assessing whether more prefixes could be claimed. The gateway holds the /60 and rations it, keeping half for itself and delegating the top eight /64s one at a time. Both observations agree: a prefix-id only carves within a delegation already held, so the earlier test could not have moved a lone /64 regardless. The limit is that UniFi solicits once, which makes the requester the ceiling rather than the carrier. --- .../2026-08-17-fleet-ipv6-mesh.md | 38 +++++++++++++++++++ 1 file changed, 38 insertions(+) diff --git a/persistent-memory.d/2026-08-17-fleet-ipv6-mesh.md b/persistent-memory.d/2026-08-17-fleet-ipv6-mesh.md index b248c49..188c5ef 100644 --- a/persistent-memory.d/2026-08-17-fleet-ipv6-mesh.md +++ b/persistent-memory.d/2026-08-17-fleet-ipv6-mesh.md @@ -127,3 +127,41 @@ Cloudflare DNS-edit token, so this is self-serve. WireGuard holds keys in kernel memory, so no restart was needed. The parent `/etc/wireguard` was already 700, which capped the real exposure to root-capable contexts inside the LXC — but the modes were still wrong. + +--- + +## CORRECTION (recorded 2026-08-24): "AT&T delegates exactly ONE /64" is the +## per-REQUEST truth, not the total — eight /64s exist and are unclaimed + +The section above concludes AT&T hands out a single `/64` and that the +`c110`/`c11f` pattern reading as a `/60` was a misread. **That conclusion was +itself superseded later in the same session, and the correction never made it +into memory** — it survived only in the session transcript, and was recovered +2026-08-24 while assessing a proposal to grab more prefixes. + +Reading the **BGW's own LAN statistics page** gave the whole picture: + +``` +BGW WAN v6 2001:506:70b2:8958::1 <- AT&T's transit prefix +BGW LAN v6 2600:1700:b25:c110::/64 <- the BGW keeps this for itself +Delegated 2600:1700:b25:c11f::/64 <- what the UDM got +``` + +**The BGW holds the `/60` and rations it**, keeping `c110`–`c117` for itself and +delegating from the top down — the UDM got `c11f`, the last one. So +`c118`–`c11f` are **eight delegatable /64s that genuinely exist and are yours**, +sitting unclaimed. + +Both observations are compatible, which is why the first one looked conclusive: +the prefix-ID test only carves *within* a delegation already held, so a UDM +holding one `/64` cannot move it no matter what prefix-ID you set. The BGW +issues **one `/64` per IA_PD request**, and **UniFi solicits exactly once**. + +**Consequence — the ceiling is the requester, not the carrier.** More prefixes +need more IA_PD requests (multiple IAIDs, or multiple client DUIDs), which the +UDM will not do. That is what makes a separate DHCPv6-PD client viable, and it +is why "ask AT&T for a bigger delegation" may be aimed at the wrong party: this +looks like BGW rationing rather than a provisioning-profile limit. + +Live state at correction time: `wan_dhcpv6_pd_size: 64`, `wan1 v6 +2600:1700:b25:c110::48`, all 5 NH3 LANs still `ipv6_interface_type: none`.