Pass 5 (W3) -- IPv6-unlock posture reconciliation, classification matrix, Roosevelt-delta

Author: W3 worker, follow-on to the container-elim pass (D-144, RULED 2026-08-10). Scope: posture reconciliation against the standing IPv6 rulings, the CLASSIFICATION MATRIX across every family-bearing surface touched or adjacent to the collapse, the Roosevelt-delta, and the honest (a)-genuine-unlocks-vs-(b)-independent-work framing. READ-ONLY; nothing built, nothing executed, no D-number minted or amended here (GA-R5 -- findings are LOGGED, never ruled).

Inputs read in full this session: docs/audit/container-elim-pass/FINAL-PLAN.md; docs/design-decisions.md D-101 (:2243-2412), D-124 + its four amendments (:4978-5170), D-134 + all amendments incl. the 2026-08-10 .8 client-VM one (:5885-6250), D-138 (:7091-7159), D-139 both rulings (:7280-7409), D-141 (:8003-8055), D-143 (:8110-8208), D-144 including its DEC package (:8210-8330); docs/audit/container-elim-pass/pass5-w1-mgmt-v6.md (full) and docs/audit/container-elim-pass/pass5-w2-metal-data-v6.md (full) -- both landed mid-session; their precise, line-cited rows are IMPORTED into this matrix rather than re-derived, per the tasking's "pull from W1/W2 once written" instruction. Every row below sourced from W1/W2/FINAL-PLAN/design-decisions.md is cited to its origin; none are re-derived independently unless marked [W3].

1. Posture reconciliation -- the standing rule, and where each surface class sits against it

The standing principle (D-101, operator verbatim, :2274-2280): "We are building as close to full IPv6 as possible on every layer possible... using IPv4 where necessary only because it is necessary." Restated as the rule (:2282): IPv6 unless IPv4 is NECESSARY. Every v4 leg is a justified exception, never a neutral default choice (:2282-2290). D-139 Ruling A (:7280-7338, RULED 2026-07-31) is D-101's own APPLICATION, not a revision: it names, per plane, exactly what forces v4 -- metal-admin (PXE, the MAAS region API dial, the node-DNS forwarder, the v4-only D-134 utility band, a rack with no global v6) and provider-public (tenant FIPs against a still-v4 internet, external API VIPs, the edge default route) stay dual-stack; the other five planes (metal-internal, data-tenant, storage, replication, lb-mgmt) are IPv6-only. D-141 (:8003-8055) narrows the posture ONE further notch for a specific, named case: container-hosted API-charm VIPs are dual-stack-AUTHORED but v4-active/v6-reserved, gated on juju LP #1723240 + per-charm fixes -- this is not a cloud-wide v4 lean, it is the one place D-101's default is provably blocked today (memory pointer confirmed against the primary source this session).

Reconciliation test applied to every surface below: does a proposed v6 change (a) apply an ALREADY-ruled family (mechanical, no new decision), (b) touch a NAMED v4-necessity (D-141's LP #1723240 case; PXE), or (c) fall into a gap no ruling has adjudicated? Class (c) is the one this pass must not silently resolve -- GA-R5 forbids picking for the operator, so gaps are logged as candidate DEC material, not flipped.

Ruled-vs-built distinction, imported from W2 (important -- do not conflate the two): for the four now-IPv6-only planes, the v4 subnets are ruled REMOVED but still live in MAAS today -- D-139's own execution list states plainly "none of it is done" (design-decisions.md:7437), and v4 is removed LAST, "after each is proven" (:7443, per pass5-w2-metal-data-v6.md Section 2). A row marked ALREADY-v6 below means the FAMILY RULING is settled, not that the v4 side is already gone from the build.

D-143 axis discipline (:8153-8158, :8321-8323): the re-IP is explicitly "a v4-only re-IP" -- "The IPv6 family matrix, the 'IPv6 wherever possible' principle... and the dual-stack ruling are UNTOUCHED." No v6 literal changes value because of D-143; only v4 second/third octets shift 12->13 (D-134's octet-preserving map, :8169-8173). Every row below that touches a v6 family is therefore [D-139- independent] with respect to the [D-143] axis, on top of whatever it is with respect to [CE].

2. The classification matrix

Classes used (the tasking specified four -- ALREADY-v6, FLIP-TO-v6-NOW-POSSIBLE, DUAL-STACK-REQUIRED, FORCED-v4 -- this pass's evidence required five more to avoid mis-stating an unruled or in-flight surface as one of the four):

Matrix shape (19 rows): ALREADY-v6 = 6 (rows 3, 10, 11, 12, 13-family-half, 14); DUAL-STACK-REQUIRED = 2 (rows 8, 9); FLIP-TO-v6-NOW-POSSIBLE = 1 (row 1); v6-CAPABLE-BY-DESIGN(new) = 2 (rows 5, 6); FORCED-v4 = 2 (rows 15, 17); UNRULED-GAP = 2 (rows 2, 4); DUAL-AUTHORED-STATUS-GATED = 1 (row 16); CONDITIONAL/OPEN = 1 (row 7); RETIRED/N/A = 2 (rows 18, 19). 6+2+1+2+2+2+1+1+2 = 19. (Row 13 counted once, under ALREADY-v6, with its carrier-open half called out in the reason column and Section 4 below -- not double-counted.)

The honest headline: only ONE row (row 1) is a clean, single "the collapse newly makes this v6-possible" unlock, and even it is UNVERIFIED pending DEC-15. Rows 5/6 are collapse-created SURFACES that happen to be v6-capable by construction, not existing v4 surfaces flipped to v6. An empty-or-near-empty FLIP-TO-v6-NOW-POSSIBLE class is itself the finding, not a gap in this pass's search.

3. Roosevelt-delta -- bare metal has no virtualization substrate

Judged surface-by-surface against the operator's "module deployment project" lens (FINAL-PLAN Section 3, :135-142, imported rather than re-derived):

Transfers verbatim (v4-forced on bare metal too -- not a virtualization artifact):

• Row 15, PXE ruling. The v4-first RULING is unscoped to VR1 and nothing in D-101/D-139 limits it to this deployment, so it transfers as a posture. What does NOT transfer as a settled fact is a capability claim -- whether Roosevelt's actual firmware/MAAS stack could do v6-only PXE/HTTP-boot is genuinely unmeasured here (per row 15/pass5-w2's explicit UNVERIFIED verdict); this pass does not assert PXE is protocol-impossible over v6 in general, only that this repo has built and ruled a v4-first path and never tested an alternative to compare against.
• Row 16, LP #1723240. This is a juju-layer defect (state/linklayerdevices.go, EthernetDeviceForBridge taking addrs[0] from an unsorted query, per D-139's "What forced this" section :7401-7409) -- substrate-independent. Bare metal runs the same juju version against the same bug; it transfers UNCHANGED. This is the non-obvious one: an operator could assume flattening the substrate also flattens this defect away. It does not -- juju, not the hypervisor, is the constraint.

Does NOT transfer (virtual-only artifacts, no bare-metal analog in the same shape):

• Rows 18/19, qemu+ssh dial + D-125 bridge-in module. Both exist ONLY because of nested libvirt (Model B); Roosevelt has no containment layer to dial into or bridge WAN through, so neither the surface nor its retirement has a bare-metal counterpart.
• Rows 5/6, the (a) control + SEC-010 successor. FINAL-PLAN Section 3 (:139-142) flags these explicitly as "artifacts of vcloud's single-hypervisor co-residency with no bare-metal analog in the same shape" -- a Roosevelt DC has its own physical NICs and switches, not a shared kernel with another DC's plane bridges.
• Row 1's power-key mitigation (DEC-15). Same reasoning: the blast-radius problem it mitigates is specifically "one vcloud libvirtd controls everything"; bare metal's power control is BMC/IPMI per physical host, already isolated by hardware.
• Row 17's simulated-ISP v4 NAT. D-101 consequence 3 (:2294-2301): "Roosevelt has FULL v4 AND v6 EDGE TRANSPORT... External IPv6 routing is deliberately NOT added this deployment; it arrives with the next full deployment." VR1's v4-only simulated-ISP hop is a REHEARSAL SIMPLIFICATION, not a Roosevelt requirement -- it does not transfer.
• Row 2/4's D-124 transit /30s. The transit-numbered-mesh SCHEME (region<->rack P2P addressing) is a virtualization-era answer to "how does an off-site controller reach an isolated rack"; whether it has a Roosevelt analog depends on Roosevelt's own physical topology, which is out of this pass's scope to assert.

Mesh triangle / netem (row 13's carrier, virbr5 + siblings): FINAL-PLAN's own L0 judgment (:135-136) already rules these "virtualization shims" that do NOT transfer; DEC-24's open carrier-attachment question is a VR1-internal problem with no Roosevelt equivalent to inherit an answer from.

4. (a) genuine unlocks vs (b) independent work -- the key honest framing

(a) Genuine unlocks the collapse creates (would not exist, or would not be answerable this way, under Model B):

1. Row 1 -- the MAAS power-dial reach path becomes structurally v6-answerable (still unverified live).
2. Rows 5/6 -- two BRAND NEW controls (the (a) isolation control, the SEC-010 successor) that exist only because flattening creates co-residency; both happen to be v6-capable by construction at zero extra cost.
3. Row 13's carrier-ATTACHMENT question (DEC-24) -- raised specifically because the flatten reassigns every other cross-DC/cross-site leg and left this one undefined; its FAMILY (already-v6) was settled by D-139 well before D-144 existed.
4. Rows 18/19 -- outright REMOVAL of two v4-only virtualization artifacts (not v6 work, but real simplification the collapse buys).

(b) v6 work that is INDEPENDENT of the collapse and must not be credited to it:

1. D-139's entire plane family matrix (rows 8-14) -- ruled 2026-07-31, over a week before D-144 (2026-08-10). None of it required, or was blocked by, the containment layer's existence.
2. The geneve-over-v6 rebuild fix (row 11) -- a build-mechanics defect (bracketed ovn-encap-ip) fixed independently of any topology change; the plane was already ruled v6-only under Model B. pass5-w2 Section 5b states its D-144 relationship as explicitly "NONE".
3. D-141's LXD-container dual-stack-authored/status-gated pattern (row 16) -- gated on a juju upstream defect that the collapse cannot touch, per the Roosevelt-delta section above and pass5-w2 Section 5a's explicit "NONE" verdict. This is the pattern the tasking's "do not overstate" caveat targets directly: D-144 flattens the containment VM, full stop; it does not, and cannot, unblock LP #1723240.
4. Row 3 (client-VM metal-admin leg) -- v6 arrives via a standing D-139 rule applied to a new object, not via a new decision the collapse forced.
5. Row 15 (PXE forced-v4) -- unaffected by topology; still forced under the flat shape exactly as it was under Model B.
6. Row 17 (uplink NAT) -- persists in family completely unchanged through D-144; only an indirection layer (row 19) is removed around it.

No v6 flip identified in this matrix conflicts with a standing ruling. The two UNRULED-GAP rows (2, 4 -- the D-124 transit family) are pre-existing gaps this pass surfaces, not proposed flips; per GA-R5 they are logged as candidate DEC material (a future DEC-14/DEC-16 ruling session should decide whether to close them, since both touch the same leg those DECs already govern) and are explicitly NOT resolved here.

5. Open items carried forward (not ruled, not built)

• The D-124 transit-overlay family gap (rows 2, 4) has no owning DEC row today. Flag it when DEC-14/DEC-16 are ruled (pass5-w1's own top risk #2) so it is not rediscovered from scratch.
• DEC-24's carrier-attachment question (row 13) is already an OWED open item in D-144's body (:8312-8317); pass5-w2 independently names it the single point where its plane-family work and the D-144 collapse genuinely intersect (Section 6).
• Row 7's MAAS-3.7 v6 RPC capability is UNVERIFIED either way in the repo; do not assert it in either direction until DEC-08 resolves (retirement likely moots it).
• Row 9/15's PXE-over-v6 platform capability is UNVERIFIED (pass5-w2's own explicit verdict) -- carried forward as a standing caveat, not something this pass or a future one should assert either way without a measured test.
• pass5-w1 and pass5-w2 both landed during this session and are fully reconciled into the matrix above (rows 1-7 from W1, rows 8-17 informed by W2, row-for-row, no contradiction found between W2's findings and this pass's earlier draft rows -- the earlier draft's PXE framing (row 15) and its D-125/uplink-NAT conflation (rows 17/19) were corrected against W2's more precise citations before this version was written).

Verification note

Direct reads this session: docs/audit/container-elim-pass/FINAL-PLAN.md (full), docs/audit/container-elim-pass/pass5-w1-mgmt-v6.md (full, rows 1-7 imported verbatim with original citations preserved), docs/audit/container-elim-pass/ pass5-w2-metal-data-v6.md (full, rows 8-17 informed by its precise findings), docs/design-decisions.md D-101 (:2243-2412, incl. the 2026-07-27 ruling-note correction), D-124 + amendments (:4978-5170, incl. the full D-125 bridge-in text), D-134 + all amendments incl. 2026-08-10 (:5885-6250), D-138 (:7091-7159), D-139 both rulings (:7280-7409), D-141 (:8003-8055), D-143 (:8110-8208), D-144 incl. DEC package (:8210-8330); docs/tool-index.md (header + teardown table); ls scripts/ | grep geneve confirmed geneve-encap-assert.sh and dc-dc-mtu-geneve-budget.sh exist on disk; ls docs/audit/ | grep geneve confirmed geneve-over-v6-rootcause-20260808.md exists on disk (cited by path, not memory); ls docs/audit/container-elim-pass/ | grep pass5 re-checked twice this session -- pass5-w1-mgmt-v6.md and pass5-w2-metal-data-v6.md both present at write time, fully reconciled into this document (Section 5). READ-ONLY throughout; no mutation; nothing executed against the cloud; no D-number ruled, amended, or proposed as a ruling by this pass (findings only, GA-R5).