diff --git a/docs/CURRENT-STATE.md b/docs/CURRENT-STATE.md index d85bacb..67a097f 100644 --- a/docs/CURRENT-STATE.md +++ b/docs/CURRENT-STATE.md @@ -1270,8 +1270,34 @@ which now exists -- no rack leg, no DHCPv6), via DHCPv6 (needs a v6 dynamic range AND `dhcpd6`, both absent by design), or via SLAAC/RA (needs a router advertising on the plane -- the rack or the edge). These have materially different consequences and only the first is - already satisfied. **NOT INVENTED: presented to the operator rather than chosen.** The legs - are NOT applied. + already satisfied. **NOT INVENTED: presented to the operator rather than chosen.** + **RULED 2026-07-27 (GA-R5), exact utterance: "MAAS static assignment is correct"** -- + recorded on the D-134 R4 amendment, which is the authority. **IT CLOSES WORK RATHER THAN + OPENING IT:** the v6 carve already applied IS SUFFICIENT for node addressing; **the + rack-bridge v6 legs are NOT needed and were NOT applied**, so `dc-rack-net.sh`'s `LEGS` + table stays v4-only; `dhcpd6` staying **off** is CORRECT rather than a gap (MAAS starts it + only for a v6 dynamic range, and none should exist under this ruling); and no plane needs a + router advertising RAs, so the DC edges take no new role. It mirrors how v4 node addressing + already works here (D-134 statics, one octet per node) -- the low-delta answer. + **THIS RESOLVES U17.** Its finding that "the rack bridges need v6 too" was measured on the + DATA PATH and was correct as an observation, but under static assignment nothing consumes a + rack v6 leg -- so the widening it proposed does not follow. Another instance of the standing + lesson: the observation held, the conclusion did not. + **VERIFICATION OWED AT STAGE-5 FIRST BOOT** -- nodes are powered off in `Ready`, so that MAAS + actually assigns the v6 statics cannot be observed until first boot, the same one-time window + **G17** exists for. PROPOSED, not adopted (amending a gate row is the operator's): fold a + fourth G17 assertion that a booted node carries a global v6 address from its plane's `/64` in + the ruled `::100`-`::200` band. G17's current three assertions are unchanged. +- **RENDER-PIPELINE STEP 3 IS COMPLETE 2026-07-27.** Every authoritative source now carries the + ruled values: **MAAS** (12 v6 plane subnets carved; 24 D-134 bands + both FIP pools reserved; + `dc-plane-ipam check` pass=24 fail=0 and `reserve` planned=0 on BOTH DCs), **`lib-net.sh`** + (dc1 FIP pool set, with the R9/D-133 unsets now guarded by new harness cases), and the + **NetBox apex** (ip-ranges 3 -> 27, ip-addresses 4 -> 160, IPv6 0 -> 78, 156 VIP objects). + Two decisions that had been RULED-BUT-NEVER-BUILT are now artifacts: **D-134's bands** and, + in the apex, the **D-020/R11 VIP set including vault `.61` and designate `.62`**. Machines + measured 18 Ready + 2 Deployed unchanged across every mutation. **Steps 4-6 (build the + renderer, dry-run it, audit the chain) are now unblocked -- the apex finally has something + real to pull.** - Position inside Stage 3: deploy step A EXECUTED 2026-07-19 (6/0/6 exact; convergence zero -- `docs/audit/outer-plan-20260719-postA-converged.txt`). **Deploy step B diff --git a/docs/changelog-20260727-stage5-phase0.md b/docs/changelog-20260727-stage5-phase0.md index 8bf5004..fe736ae 100644 --- a/docs/changelog-20260727-stage5-phase0.md +++ b/docs/changelog-20260727-stage5-phase0.md @@ -401,3 +401,27 @@ **Revert.** Delete the created objects by description prefix: `ip-ranges` whose description starts `D-134 `, and `ip-addresses` whose description starts `VIP `. Both are additive records; no live address is affected. + +## 13. Node IPv6 acquisition RULED -- MAAS static assignment; step 3 closes + +**Ruling.** Operator, exact utterance: "MAAS static assignment is correct". Recorded on +the D-134 R4 amendment. Question as presented offered (a) MAAS static assignment, +(b) DHCPv6, (c) SLAAC/RA. + +**It closes work rather than opening it.** The v6 carve already applied is sufficient; +**the rack-bridge v6 legs are NOT needed and were not applied** (`dc-rack-net.sh`'s LEGS +table stays v4-only); `dhcpd6` staying off is correct, not a gap; no plane needs a router +advertising RAs. Mirrors how v4 node addressing already works (D-134 statics). + +**Resolves U17.** Its "the rack bridges need v6 too" was a correct observation on the data +path, but under static assignment nothing consumes a rack v6 leg, so the widening does not +follow. The observation held; the conclusion did not. + +**Verification owed at Stage-5 first boot.** Nodes are powered off, so that MAAS actually +assigns the v6 statics cannot be observed yet -- the one-time window G17 exists for. +PROPOSED, not adopted: a fourth G17 assertion that a booted node carries a global v6 +address from its plane's /64 in the ruled ::100-::200 band. + +**STEP 3 COMPLETE.** MAAS, lib-net and the apex all carry the ruled values. No revert entry +here -- this item ruled that a mutation is NOT required; items 9-12 carry the reverts for +what was applied. diff --git a/docs/design-decisions.md b/docs/design-decisions.md index c1cc447..d376359 100644 --- a/docs/design-decisions.md +++ b/docs/design-decisions.md @@ -5406,6 +5406,33 @@ block that has no node statics competing for them. That is deliberate consistency, not an oversight. +**NODE IPv6 ACQUISITION RULED 2026-07-27 (GA-R5).** Question as presented: with the v6 +plane subnets now carved in MAAS, how do NODES actually acquire a v6 address -- (a) MAAS +STATIC assignment at deploy, which needs only the subnet and is already satisfied; +(b) DHCPv6, which needs a v6 dynamic range and `dhcpd6`, both absent by design; or +(c) SLAAC/RA, which needs a router advertising on each plane and would make the rack a +router. The three differ materially and only (a) is already satisfied. Operator answer, +exact utterance: **"MAAS static assignment is correct"**. + +**EFFECT, and it CLOSES rather than opens work.** (1) The v6 carve already applied IS +SUFFICIENT for node addressing -- nothing further is required in MAAS. (2) **The +rack-bridge v6 legs are NOT needed**, which resolves the U17 sweep item: its finding that +"the rack bridges need v6 too" was measured on the DATA PATH, but with static assignment +nothing consumes a rack v6 leg, so `dc-rack-net.sh`'s `LEGS` table stays v4-only and is +NOT extended. (3) `dhcpd6` staying **off** is CORRECT, not a gap -- MAAS starts it only +for a v6 dynamic range, and under this ruling none should exist. (4) No plane needs a +router advertising RAs, so the DC edges take no new role. This mirrors how v4 node +addressing already works here (D-134 statics, one octet per node), which is why it is the +low-delta answer. + +**VERIFICATION OWED AT STAGE-5 FIRST BOOT, not assertable now.** Every node is powered off +in `Ready`, so that MAAS actually assigns the v6 statics cannot be observed until first +boot -- the same one-time window gate **G17** already exists for. PROPOSED (not adopted +here, since amending a gate row is the operator's): fold a fourth assertion into G17 -- +that a booted node carries a global v6 address from its plane's `/64` in the ruled +`::100`-`::200` node band. Recorded so the window is not missed; G17's current three +assertions are unchanged by this entry. + **REVIEW OWED AT PROJECT CLOSE, by the same ruling** ("make a note to review at the end of the project to review for adjustment"): revisit whether the GUA leg should instead pack from `::1`, once the cloud is live and the v6 behaviour has been observed. Recorded as forward