diff --git a/docs/CURRENT-STATE.md b/docs/CURRENT-STATE.md index de799ee..43d363d 100644 --- a/docs/CURRENT-STATE.md +++ b/docs/CURRENT-STATE.md @@ -453,7 +453,18 @@ recorded in the amendment, including that it deliberately spends the inner roots' ZERO-DIFF property, and that whether re-commissioning preserves the D-134 statics and pinned MACs must be verified BEFORE the apply (the 2026-07-20 MAC-regeneration incident - is the precedent). Remaining: R2-R11 blocking, R12-R15 standing, in + is the precedent). + **R2 RULED 2026-07-27 -- exact utterance "Carve v6 and deploy dual-stack as ruled + (Recommended)"**, recorded as a D-101 RULING NOTE (re-confirmation, no amendment; + design-decisions.md is the authority). **This CHANGES THE PLAN: D-101's "Remaining open + item" -- the org ULA /48 and per-DC GUA carve -- was carried as non-blocking "pending + NetBox assignment" and is now a STAGE-5 PRECONDITION**, because dual-stack cannot deploy + against literals that do not exist. R9 and R11 inherit dual-family from it; the L3-9 + overlay collision must be reconciled BEFORE either authority location is populated (the + dangerous merge order is the one that PASSES -- it silently drops every v6 leg). R8 + (octavia family) is NOT resolved by it. A new sub-question **R2a (which literals)** is + QUEUED, not ruled -- the shape is the operator's, and hard rule 2 forbids inventing a + prefix. Remaining: R2a, R3-R11 blocking, R12-R15 standing, in `docs/audit/queued-rulings-20260727.md`. - Position inside Stage 3: deploy step A EXECUTED 2026-07-19 (6/0/6 exact; convergence zero -- diff --git a/docs/audit/queued-rulings-20260727.md b/docs/audit/queued-rulings-20260727.md index 80fe36d..cc57b82 100644 --- a/docs/audit/queued-rulings-20260727.md +++ b/docs/audit/queued-rulings-20260727.md @@ -96,6 +96,45 @@ dc0 goes dual-stack, making the v4/v6 delta itself the experiment (the D-135 per-DC-difference pattern applied to address family). +OPERATOR UTTERANCE: **"Carve v6 and deploy dual-stack as ruled (Recommended)"** -- +RULED 2026-07-27. **R2 IS CLOSED.** Recorded as a D-101 RULING NOTE (re-confirmation, +no amendment -- `docs/design-decisions.md` is the authority). **Consequence that +changes the plan: D-101's "Remaining open item" (the org ULA /48 and per-DC GUA +carve), until now carried as non-blocking "pending NetBox assignment", is now a +STAGE-5 PRECONDITION** -- dual-stack cannot deploy against literals that do not +exist. R9 and R11 both inherit "dual-family" from this. The L3-9 overlay collision +must be reconciled BEFORE either authority location is populated; note the dangerous +direction is the one that PASSES (vips overlay last silently drops every v6 leg and +reports green). R8 is NOT resolved by this ruling. **Immediate next sub-question, +queued not ruled: WHICH literals** -- see R2a below. + +--- + +## R2a. WHICH IPv6 literals? (opened by the R2 ruling) + +R2 directs that the org ULA /48 and per-DC GUA carve be assigned; it does not assign +them. This is an apex assignment and under D-136's unruled coupling the working apex +is `office1-netbox` (10.10.1.10), with `netbox.baldurkeep.com` a read-only v1 +reference. + +What is already measured: the only IPv6 in the whole cloud today is +`2602:f3e2:f01:100::/64` on the Office1 base fabric, so a GUA allocation of +`2602:f3e2:f01::/48` demonstrably exists and is partly in use. The ULA side has no +existing assignment at all. + +I am deliberately NOT proposing specific prefixes -- picking your address space is +yours, and hard rule 2 forbids me inventing a literal. What needs deciding is the +SHAPE, after which the actual values are a mechanical carve: + +**Options:** +- **(a)** ULA per RFC 4193 (pseudo-random /48), with a per-DC /56 out of it and a + per-plane /64; GUA carved per-DC /56 out of the existing `2602:f3e2:f01::/48`. + Symmetric with the D-134 v4 band discipline. +- **(b)** ULA only on the v6-only planes (data-tenant, storage, replication) with + GUA reserved for provider-public, per D-101's family matrix read strictly. +- **(c)** Assign in NetBox first and let the carve fall out of the apex record -- + couples this to the D-136 render-pipeline question rather than pre-empting it. + OPERATOR UTTERANCE: --- diff --git a/docs/design-decisions.md b/docs/design-decisions.md index 593330d..8a7bb54 100644 --- a/docs/design-decisions.md +++ b/docs/design-decisions.md @@ -2055,6 +2055,54 @@ upstream IPv6 breakage there (LP #1911788, #1913409); operator sub-ruling pending (see the D-136 open questions). +### RULING NOTE 2026-07-27 -- D-101 RE-CONFIRMED against measured substrate; the literals move ONTO the Stage-5 critical path + +**Status:** RULED 2026-07-27 (operator, GA-R5). This NOTE, like its 2026-07-25 predecessor, +records a ruling and AMENDS NOTHING in D-101's matrix. + +Question as presented, verbatim: "R2 -- Address family. D-101 RULED dual-stack for both DCs +*this deployment* and closed the v4-only option, but there is zero IPv6 anywhere in the DC +substrate: no v6 subnet on any of the 12 plane fabrics, no v6 link on any of the 18 nodes. +How should Stage 5 proceed?" Options presented: (a) carve v6 and deploy dual-stack as ruled; +(b) deploy v4-only now and add v6 after, via an explicit D-101 amendment; (c) dc0 dual-stack +/ dc1 v4-only as a per-DC experiment. Operator selection, exact utterance: +**"Carve v6 and deploy dual-stack as ruled (Recommended)"**. + +**What made this a live question rather than a settled one.** The 2026-07-27 Stage-5 +grounding audit MEASURED the substrate against the 07-25 ruling and found the ruling +unimplemented: `maas admin subnets read` returns exactly ONE IPv6 subnet cloud-wide +(`2602:f3e2:f01:100::/64`, on `fabric-0`, the Office1 base net, space `undefined`); none of +the ten named plane fabrics nor either metal-admin fabric carries an IPv6 subnet; zero IPv6 +links exist across all 18 nodes; and every node reports `default_gateways.ipv6 = NONE`. +D-101's family matrix requires ULA on data-tenant, storage and replication plus a ULA leg on +metal-admin and metal-internal -- none of which has any MAAS v6 presence to bind against. + +**Effect -- the consequential part.** D-101's "Remaining open item" above (the exact NetBox +literals: org ULA /48, per-DC GUA carve) has until now been carried as "pending NetBox +assignment ... not a ratification question", i.e. non-blocking. **It is now a STAGE-5 +PRECONDITION.** Dual-stack cannot be deployed against literals that do not exist, so the +assignment moves onto the critical path ahead of `juju deploy`. + +**Sequenced consequences, all of which now inherit "dual-family" from this ruling:** +1. The `vr1-dc1-vips` / `dc-dc-ipv6-family-matrix` per-key REPLACE collision must be + reconciled BEFORE either authority location is populated. The audit MEASURED it in both + directions (finding L3-9): with the ipv6 overlay applied last the merged input FAILS with + ten `vip not a triple` errors; with the vips overlay last the v6 legs are REPLACED + wholesale and the result **silently PASSES as pure-v4**. The second is the dangerous one -- + it is a green gate over a lost ruling. +2. Any VIP added under R11 (vault, designate) is dual-family from the outset. Adding v4-only + VIPs and re-doing them later means re-issuing certificate SANs on a live cloud. +3. R9 (where dc1's OpenStack-layer literals live) must be answered knowing both families + are in scope. +4. Octavia's family remains the standing sub-ruling recorded in the 07-25 note and is + presented separately as R8; this ruling does NOT resolve it. + +**NOT ruled here, and queued as the immediate next sub-question:** WHICH literals. The org +ULA /48 (RFC 4193 pseudo-random) and the per-DC GUA carve out of the existing +`2602:f3e2:f01::/48` allocation are an apex assignment, and under D-136's unruled coupling +the apex is `office1-netbox`. This ruling directs that they be assigned; it does not assign +them. + --- ## D-102: IPv6 tenant addressing and MTU sub-policy (VR1)