# 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): | Class | Meaning | |---|---| | **ALREADY-v6** | Family ruled and, where checkable, already the standing state; applying it to a new object (e.g. the client VM) is mechanical, not a new decision. May still have v4 physically present in the live build (see ruled-vs-built note above). | | **DUAL-STACK-REQUIRED** | Ruled dual-stack; both families are load-bearing by explicit ruling, not a default. | | **FLIP-TO-v6-NOW-POSSIBLE** | The collapse structurally removes the v4 force; v6 becomes technically reachable, but the concrete mechanism/measurement is still OWED. | | **v6-CAPABLE-BY-DESIGN (new, collapse-created)** | A NEW control/surface the collapse itself creates, built on a family-agnostic mechanism (verified by precedent), so it costs nothing extra for v6 day one. | | **FORCED-v4** | A cited, ruled necessity for the specific sub-function. Distinguish the RULING ("v4-first") from an unmeasured universal capability claim -- see row 15. | | **UNRULED-GAP** | No D-number adjudicates the family; v4 today by convention/history, not by ruling. Logged, not flipped. | | **DUAL-AUTHORED-STATUS-GATED** | D-141's specific pattern: v4 `active`, v6 `reserved`, promotion gated on a named capability. | | **CONDITIONAL/OPEN** | Resolution depends on a separate, not-yet-ruled fork (here, DEC-08); no family answer is assertable until the fork resolves. | | **RETIRED / N/A** | The surface is eliminated by D-144 outright; no family question survives it. | | # | Surface | Class | Reason / governing D | Collapse-relation | |---|---|---|---|---| | 1 | MAAS node power-dial reach path (`vr1-dcN-maas-01` -> vcloud libvirtd) | **FLIP-TO-v6-NOW-POSSIBLE** | Flattening removes the old force (dialing a plane-bridge-bound libvirt address); the new target is vcloud's own sshd over a family-agnostic transport, from a source (`metal-admin`) that already has v6. Concrete reachable address is UNVERIFIED, live-gated on DEC-15. [pass5-w1 row 1, `docs/design-decisions.md:8299-8304`] | **(a) genuine unlock** -- did not exist as a question under Model B | | 2 | D-124 region<->rack transit overlay (`172.31.0.0/24`) | **UNRULED-GAP** | No D-number rules this leg's family. `mesh-link` (L2) and SSH (transport) both already support v6; a candidate v6 slot exists in the apex (`f00::/40` "Infrastructure / site-to-site links", D-115 `:3751-3753`) but nothing has carved it. This is a PRE-EXISTING gap (predates D-144), not created by the collapse. [pass5-w1 row 2] | **(b) independent** -- collapse only re-homes the leg's endpoint, does not touch family | | 3 | Client-VM `metal-admin` leg (`.8`, D-134 2026-08-10 amendment) | **ALREADY-v6** | `metal-admin` is D-139 Ruling-A dual-stack for every host on the plane; the client VM inherits it mechanically the moment it is placed there. No new v6 decision -- applying an existing rule to a new object. [pass5-w1 row 3; `docs/design-decisions.md:6240-6248`] | **(b) independent of collapse's v6 credit** -- the collapse creates the OBJECT, not the rule | | 4 | Client-VM transit leg (same `172.31.0.x/30` scheme) | **UNRULED-GAP** | Same open question as row 2; the D-144 ledger's "D-124 AMENDS -- Scheme-A addressing survives" (`:8279-8280`) preserves the ADDRESSING, not a family decision. Do not conflate with row 1 (MAAS's power-dial does not route through the client VM). [pass5-w1 row 4] | **(b) independent**, re-homed not re-familied | | 5 | (a) cross-DC host isolation control (OWED, DEC-14) | **v6-CAPABLE-BY-DESIGN** | Modeled on SEC-010's live `table inet sec010` artifact (`scripts/site-headend-install.sh:299`) -- nftables' `inet` family matches v4 AND v6 in one ruleset, scoped by interface not IP literal. Costs nothing extra for v6 day one. [pass5-w1 row 5] | **(a) genuine unlock** -- the control itself is NEW, created only because co-residency is new | | 6 | SEC-010 transit-drop successor (endpoints: client VM + voffice1, DEC-16) | **v6-CAPABLE-BY-DESIGN** | Same `table inet` precedent as row 5; the planned extraction carries the shape forward. Covers a v6 transit leg IF/WHEN row 2/4 is ever ruled onto v6. [pass5-w1 row 6] | **(a) genuine unlock** in mechanism; **(b)** the traffic it protects (row 2/4) is still v4 pending its own ruling | | 7 | MAAS region<->rack control path (retirement pending DEC-08) | **CONDITIONAL/OPEN** | Moot if DEC-08 ratifies rack-controller retirement (pass2's own recommendation); if rejected, whether MAAS 3.7's rack<->region RPC supports v6 is UNVERIFIED -- no repo or vendor citation found either way. [pass5-w1 row 7] | **(b) independent** of the collapse itself (D-132 already put region+rack co-located per DC) | | 8 | `provider-public` plane | **DUAL-STACK-REQUIRED** | D-139 Ruling A: FIPs against a still-v4 internet, external API VIPs, Octavia tenant LB VIPs, edge default route. [pass5-w2 Section 2; `docs/design-decisions.md:7310-7311,7326`] | **(b) independent** -- D-139-ruled 2026-07-31, predates D-144 | | 9 | `metal-admin` plane (base plane) | **DUAL-STACK-REQUIRED**, with an embedded **FORCED-v4** sub-function | Dual by ruling (D-139 `:7327`), but the PXE/DHCP sub-function inside it is v4-only **by design**, not merely v4-heavy: MAAS's own v6-static-only node-acquisition ruling (D-134 2026-07-27 amendment, `:6138-6144`) leaves `dhcpd6` deliberately OFF, and the rack itself measures zero global v6 (`ip -6 -o addr show scope global` empty, per pass5-w2 Section 1). **PXE-over-v6 platform CAPABILITY is UNVERIFIED** -- no test/capture/vendor citation on disk states whether MAAS 3.7 even supports v6-only commissioning; do not import outside knowledge. [pass5-w2 Section 1, full] | **(b) independent** | | 10 | `metal-internal` plane | **ALREADY-v6** (ruled IPv6-only) | D-139 Ruling A explicitly **SUPERSEDES** D-101's "datastore east-west v4-bound" clause (`:7334-7336`) -- "nothing forces v4 here... a JUDGEMENT, not a protocol requirement" reversed. **Build status: v4 still live, removed LAST after proof** (pass5-w2 Section 2). A reader citing D-101's stale text alone would mis-state this plane's CURRENT family -- cite D-139. | **(b) independent** -- ruled 2026-07-31 | | 11 | `data-tenant` plane (geneve overlay) | **ALREADY-v6** (ruled IPv6-only) | D-139 Ruling A. The 2026-08-09 geneve-over-v6 rebuild fix is recorded at `docs/audit/geneve-over-v6-rootcause-20260808.md` (confirmed present on disk) and is **orthogonal to D-144** per pass5-w2 Section 5b's explicit statement -- it fixes HOW v6 geneve works (a bracketed `ovn-encap-ip` OVS rejection), not WHETHER the plane is v6; do not credit the collapse for this. | **(b) independent, and independent of D-139 too** (a build-mechanics fix, not a family ruling) | | 12 | `storage` plane (Ceph public) | **ALREADY-v6** (ruled IPv6-only) | D-139 Ruling A. Build status: v4 still live, removed last. `ceph-mon`/`ceph-osd` are in `PREFER_IPV6_CHARMS` (`:7432`) -- converting this plane REOPENS the 2026-07-31 "prefer-ipv6 false on all seven" ruling note per-app, not yet re-ruled (pass5-w2 Section 6 risk note). | **(b) independent** | | 13 | `replication` plane (Ceph cluster incl. cross-DC leg) | **ALREADY-v6** (family settled) but **carrier path OPEN (DEC-24)** | D-139 Ruling A settles the FAMILY. Two open items compound on the SAME carrier: (i) the cross-DC leg has **no v6 route at all today** (D-139's own build-constraints bullet, `:7431`, pre-existing and OPEN); (ii) D-144's DEC-24 (`:8312-8317`) leaves the post-flatten `virbr5`/netem attachment for that same leg UNDEFINED. pass5-w2 Section 6 names this explicitly: **"the one point where the W2 family ruling and the D-144 collapse genuinely intersect -- an unresolved carrier for an unresolved route."** | **Mixed: (b) family independent; (a) the carrier-attachment QUESTION is collapse-raised** (DEC-24 exists because of the flatten) | | 14 | `lb-mgmt` plane (Octavia) | **ALREADY-v6**, but **two distinct objects, do not conflate (G18 warning)** | (1) the octavia charm's own live/consumed **ULA `fc00::/64`** (R8-ruled); (2) D-139's apex **GUA `f0X:80::/64`** carved as a MAAS-underlay plane with NO charm consumer, kept `reserved` per the G18 ruling (option b). Pointing octavia at object (2) would reopen R8. [pass5-w2 Sections 2 and 4] | **(b) independent** -- G18/D-141 governed, pre-dates D-144 | | 15 | MAAS PXE / node provisioning (sub-function of row 9) | **FORCED-v4** | D-101 (`:2307-2308`) and D-139 Ruling A both **rule** "PXE is v4-first" -- but this is a ruling, not a measured platform-capability ceiling. **Do not assert PXE-over-v6 is impossible**: no test, capture, or MAAS-source citation on disk measures whether MAAS 3.7 could commission v6-only (pass5-w2 Section 1, the "anchor question", explicit UNVERIFIED verdict). What IS settled: the ruling is unscoped to VR1 specifically and nothing in D-101/D-139 limits the v4-first posture to this deployment. | **(b) independent** -- and see Roosevelt-delta below | | 16 | LXD-container / API-charm VIPs (juju LP #1723240) | **DUAL-AUTHORED-STATUS-GATED** | D-141: v4 `active`, v6 `reserved`, promotion gated on the two-layer capability set (LP #1723240 + per-charm fixes, `docs/charm-ip-family-compatibility.md`). Carried risk (pass5-w2 Section 5a): on `metal-admin` (dual-stack), container addresses land on ONE family by unsorted mongo order (today v4) -- a detection gate ("every container's metal-admin leg is IPv4") is OWED, not built. **DISAMBIGUATION (do not overstate D-144's reach):** "container-elim" in this pass's title means the `vvr1-dcN` **containment VM** (D-122/D-123 Model B) -- it has nothing to do with juju's LXD-container control-plane units on the node VMs. D-144 eliminating the containment VM does **not** touch, unblock, or moot LP #1723240 in any way (pass5-w2 Section 5a: "D-144's relationship to this gap: NONE"). | **(b) fully independent** -- different container concept entirely | | 17 | Uplink/ISP NAT (`172.30.x/24`, `modules/site-wan`) | **FORCED-v4**, single-stack by construction | `opentofu/modules/site-wan/main.tf` takes ONE `var.cidr`, one `forward.mode="nat"`, one `ips` entry -- no v6 CIDR variable exists in the module at all (pass5-w2 Section 3). D-101's own rationale defers external v6 deliberately: NAT64/DNS64 was considered and REJECTED as a v6-egress simulant (`:2295-2299`); VR1's v4-only edge is a rehearsal simplification, not a capability gap. **D-144 persists this UNCHANGED in family** -- "edge WAN attaches directly to the per-DC `site-wan` NAT" (`:8256-8257`); only the WAN-bridge INDIRECTION (row 19, D-125's plumbing) is removed, not the NAT module or its family. | **(b) independent** -- do not conflate with row 19's retirement | | 18 | `qemu+ssh` provider dial (voffice1 -> `vvr1-dcN`, D-126 per-env keys) | **RETIRED / N/A** | D-144: "the qemu+ssh provider dial + its D-126 per-env keys (no successor)" (`:8254-8255`). The surface is DELETED, not flipped -- there is no family question left to classify. | **(a) genuine removal** (not a v6 unlock, a surface elimination) | | 19 | D-125 bridge-in `modules/wan-bridge` (WAN indirection only, NOT the uplink NAT) | **RETIRED / N/A** | D-125 header: "TERMINATED 2026-08-10 by D-144" (`:5091-5094`); the DC edge WAN attaches directly to row 17's `site-wan` NAT instead of bridging through the (now-eliminated) containment VM. Retiring the bridge module removes an indirection layer, not a family -- row 17's v4-only NAT survives this row's retirement unchanged. | **(a) genuine removal** | **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 `/30`s.** 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).