# Pass 5 (W1) -- substrate/management-plane address-family surfaces under the flat
container-elim topology (D-144)

**Author:** W1 worker, follow-on to the container-elim pass (D-144, RULED 2026-08-10).
**Scope:** ONLY the substrate/management-plane surfaces the flat topology REDESIGNS --
where the collapse of `vcloud -> vvr1-dcN -> node VMs` to `vcloud -> node VMs` changes
what address family a path can carry. READ-ONLY; nothing built or executed.

**Session-measured inputs (per tasking, used as given, not re-derived here):** (1) the
MAAS node power-dial (`qemu+ssh`) from a region VM connects to **vcloud's sshd**, not to
a libvirt endpoint bound on a plane bridge; (2) vcloud's libvirt access control is
**group-based with fine-grained polkit actions available**. Both feed DEC-15 (the
power-key mitigation, OWED, `docs/design-decisions.md:8299-8304`).

**Governing posture (read before any family claim, per memory caveat):** D-101
(`docs/design-decisions.md:2243`) -- "IPv6 unless IPv4 is NECESSARY", v4 is a justified
exception, never a neutral default. D-139 Ruling A (`docs/design-decisions.md:7280`,
RULED 2026-07-31) -- per DC, `provider-public` and `metal-admin` are **dual-stack**
(v4 retained + v6), the other five planes are **IPv6-only**. Neither rules on the D-124
transit overlay or the MAAS power-dial reach path -- those are OUTSIDE the six
plane/space family matrix, which is exactly why this pass exists.

---

## Table

| # | Surface | Current family + cite | Flat-design option | What forces v4 | Tooling-support status | Governing D |
|---|---|---|---|---|---|---|
| 1 | **MAAS node power-dial reach path** (`vr1-dcN-maas-01` -> target libvirtd, `qemu+ssh`) | **v4 only, both forms.** `VIRSH_POWER_ADDRESS_FROM_OFFICE1="qemu+ssh://jessea123@172.31.0.2/system"` (`scripts/lib-hosts.sh:212`, dc0; `:246`, dc1 `172.31.0.6`) and `VIRSH_POWER_ADDRESS_FROM_DCREGION="qemu+ssh://jessea123@10.12.8.2/system"` (`:213`, dc0; `:250`, dc1 `10.12.68.2`) -- both dial the (soon-eliminated) rack/containment VM's libvirtd on a plane-bridge address. | **v6-possible, genuinely structural.** Under D-144 the target is no longer a plane-bridge libvirt endpoint at all -- it becomes vcloud's own sshd (session-measured fact above), and `vr1-dcN-maas-01` already holds a v6 address on `metal-admin` (dual-stack, D-139 Ruling A; `lib-hosts.sh:199,233` carve the region VM 2-plane, no br-ex, per `:95-100`). SSH transport is family-agnostic; `qemu+ssh://` accepts a bracketed IPv6 literal or an AAAA-resolving hostname (OpenSSH + libvirt vendor capability, not repo-specific). | **Nothing structural any more.** The historical force was "dial the address the target libvirtd is bound to on a plane bridge" -- removed by flattening (there is no more plane-bridge libvirt host to dial; vcloud's libvirtd is not itself plane-bound). | **UNVERIFIED (live).** Whether vcloud's sshd is actually reachable from the `metal-admin` plane over v6 -- and at what address, since the (a) control forbids a host address ON a plane bridge -- is exactly what DEC-15 is GATED on: *"GATED on vcloud's live polkit/libvirt config"* (`docs/design-decisions.md:8302`); pass2 states directly *"a read of vcloud's LIVE polkit/libvirt config is delivery work, not asserted here"* (`pass2-admin-report.md:166`). The qemu+ssh/OpenSSH v6-literal mechanism itself is vendor-verified; the concrete reachable address is not. | **DEC-15** (D-144 body, `docs/design-decisions.md:8299-8304`) -- "must decide REACH ... AND authorization together." |
| 2 | **D-124 region<->rack TRANSIT overlay** (`172.31.0.0/24`, carved supernet) | **v4 only.** Dedicated management/transit supernet `172.31.0.0/24`, NOT under Cloud, ratified 2026-07-16 (`docs/design-decisions.md:5044-5054`); dc0 `/30` = `172.31.0.0/30`, dc1 = a sibling `/30` per the same pattern. Carried by `opentofu/modules/mesh-link` (the D-100 dark-fiber triangle). | **v6-possible, but an OPEN/UNRULED question, not a tooling gap.** `modules/mesh-link` is a bare L2 segment with NO address family baked in (`opentofu/modules/mesh-link/main.tf`, `variables.tf` -- only `link_name`/`mtu`; addressing is entirely the consumer's, i.e. D-124's). The IPv6 IPAM apex already reserves the conceptually-matching slot: `X00::/48` = **"Infrastructure / site-to-site links"**, VR1's is `f00::/40` -> per-DC `/48`s (`docs/design-decisions.md:3751-3753`) -- structurally the right home for a transit link, but **no `f00::...` allocation has actually been carved or cited anywhere in the repo** (grep for `f00::` returns only the table definition, `docs/design-decisions.md:3753`). Under D-144 this leg's consumer moves to the client VM (D-124 AMENDS, `docs/design-decisions.md:8279-8280`); the amendment says addressing "survives" unchanged, not that family was reconsidered. | **Nothing cited.** No D-NNN states PXE, DHCP, or any protocol on this leg requires v4; it was carved v4 by convention (mirroring the v4 Edge role, D-115) at a time (2026-07-16) that predates D-139's v6-only-east-west posture. Its live traffic (per FINAL-PLAN concern-(ii), `FINAL-PLAN.md:132-147`) is operator `ssh -J` + Office1-originated flows -- SSH, again family-agnostic. | **UNVERIFIED (design), not tooling-blocked.** mesh-link (L2) and SSH (transport) both support v6 today; what's missing is a ruling to carve a v6 prefix for the `transit` NetBox role and amend D-124 to dual-stack or v6-only. Not part of any current DEC row -- a genuine NEW gap this pass surfaces. | **D-124 AMENDS** (D-144 ledger, `docs/design-decisions.md:8279-8280`); no DEC row currently owns the family question. |
| 3 | **Client-VM metal-admin leg** | **Dual-stack already, structurally.** The client VM lands on utility-band `.8` on `metal-admin` (D-134 AMENDMENT 2026-08-10, `docs/design-decisions.md:6240-6248`: `10.13.8.8` dc0 / `10.13.68.8` dc1) -- `metal-admin` is D-139 Ruling-A dual-stack (v4 retained + v6) for EVERY host on that plane, the client VM included; no plane-level exception is named for it. | **Already v6 (no flip needed).** This is not an "unlock" from the collapse -- it is inherited automatically from the standing D-139 plane-family ruling the moment the client VM is placed on `metal-admin`. | PXE/commissioning-class forces that keep `metal-admin` dual-stack (not v6-only) are plane-wide (D-139 Ruling A rationale: MAAS region API, node-DNS forwarder, the v4-only D-134 utility band, no rack with v6-only reachability) -- they justify the plane staying dual-stack, they do not force the client VM specifically off v6. | **Verified (ruled).** D-139 Ruling A is an ADOPTED, RULED family assignment for the whole plane -- no live measurement owed for the family itself (carve mechanics at build time are a separate, ordinary Stage-3/4 concern). | **D-139 Ruling A**; **D-134 AMENDMENT 2026-08-10** (octet). |
| 4 | **Client-VM transit leg + how MAAS reaches/powers via it** | v4, same `172.31.0.x/30` scheme as row 2 (D-124 AMENDS: "Scheme-A addressing survives on the client VM," `docs/design-decisions.md:8279-8280`). | Same as row 2 (v6-possible, unruled) -- **BUT do not conflate this leg with row 1.** The client VM's transit leg carries operator `ssh -J` / Office1-originated flows and is the concern-(ii) SEC-010-successor endpoint (`FINAL-PLAN.md:132-147`); **MAAS's own power-dial (row 1) does NOT route through the client VM at all** in the pass's design -- `vr1-dcN-maas-01` and vcloud's libvirtd are both flat vcloud-resident objects, so DEC-15's reach question is `maas-01 -> vcloud`, never `maas-01 -> client-VM -> vcloud`. Treating the client VM as if it sits in the power-dial path would misattribute a DEC-15 finding to the wrong surface. | Same as row 2. | Same as row 2 (design-open, not tooling-blocked). | **D-124 AMENDS**; concern-(ii) endpoint disposition is **DEC-16** (D-144 body). |
| 5 | **(a) cross-DC host isolation control** (vcloud-level nftables, OWED, DEC-14) | N/A -- not yet built. Modeled on the EXISTING SEC-010 mechanism (below), which is already family-agnostic. | **v6-native by construction, VERIFIED via precedent.** SEC-010's live artifact uses `table inet sec010` (`scripts/site-headend-install.sh:299`, confirmed `nft list table inet sec010` check at `:221`) -- nftables' `inet` family is a SINGLE ruleset that matches BOTH IPv4 and IPv6 traffic, and the rule matches by `oifname`/`iifname` (interface), never by IP literal or family. Building the (a) control on the same `table inet` pattern gets v4+v6 coverage for free, with no new capability needed. | Nothing -- this is a forwarding/interface-scoped control, not an address-family-scoped one. | **Verified (repo precedent, mechanism-identical).** The `table inet` fact is a direct read of the live SEC-010 artifact; the (a) control's own concrete ruleset is still OWED (DEC-14), but the FAMILY question is answered by the pattern it will reuse. | **DEC-14** (D-144 body, `docs/design-decisions.md:8305-8308`). |
| 6 | **SEC-010 transit-drop successor** (endpoints: client VM + voffice1, OWED, DEC-16) | v4-and-v6-agnostic already -- see row 5; SEC-010's CURRENT closed artifact (`docs/security-ledger.md:21`) is `table inet sec010`, i.e. already dual-family on its existing (v4-only-addressed) interface. | **v6-native by construction, same evidence as row 5.** The planned extraction (pulling the writer out of `site-headend-install.sh`'s `node_host_setup()` into a role-agnostic subcommand installing both ends, `pass2-admin-report.md:142-147`) carries the `table inet` shape forward -- no redesign needed for the successor to cover a v6 transit leg IF/WHEN row 2/4's transit ever carries v6 traffic. | Nothing -- same interface-scoped reasoning as row 5. | **Verified (repo precedent).** Same citation as row 5. | **DEC-16** (D-144 body). |
| 7 | **MAAS region<->rack control path in the flat topology** | **Conditionally MOOT, pending DEC-08.** `vr1-dcN-maas-01` already runs COMBINED region+rack (pass2 adversarial check 2, `pass2-admin-report.md:26-46`, confirmed by direct read of both DC changelogs); D-131's own text independently states *"Co-located region+rack controllers are immune"* to the MAAS 3.7 rack-only-agent DNS defect (`docs/design-decisions.md:5705`), corroborating that region+rack already run as ONE co-located service, not two ends of a network hop. Standalone rack-controller RETIREMENT is pass2's recommendation (`pass2-admin-report.md:267-277`) but is **GATED, not yet ratified** -- DEC-08 (D-144 body) needs a current-day live re-measure of `primary_rack`/rackd state at both DCs first. | **If DEC-08 ratifies retirement: the question dissolves** -- no separate rack agent, no network link, so no address-family question to answer for VR1. **If retirement is REJECTED** (a standalone rack persists somewhere): whether **MAAS 3.7 supports a v6-only or dual-stack region<->rack RPC link** is a genuinely open, UNVERIFIED question. | N/A pending the DEC-08 branch. | **UNVERIFIED, no repo citation found either way.** Grepped `docs/design-decisions.md` + `docs/CURRENT-STATE.md` for MAAS-3.7-and-IPv6: three unrelated 3.7 facts turned up (LXD >=6.7 incompatibility, `site-headend-install.sh:60`; the rack-only-agent DNS SERVFAIL bug, D-131 / `dc-rack-net.sh:26,134`; MAAS auto-reserving `::1`-`::ffff:ffff` on every v6 `/64`, `docs/design-decisions.md:7421`) -- NONE address rack<->region transport family. **To confirm:** Canonical's MAAS 3.7 release/architecture docs (rack-registration protocol), or a live test enrolling a rack-only agent against a v6-only region address, before this branch is ever exercised. | **DEC-08** (D-144 body, `docs/design-decisions.md:8309-8311`). |

---

## Summary -- genuine unlocks vs needs-verification

**Genuine, evidence-backed unlocks (structural, caused by the collapse or by an
already-ruled ADOPTED decision -- not guesses):**
- **Row 3 -- client-VM metal-admin leg is dual-stack today**, inherited automatically
  from D-139 Ruling A; nothing to build or verify for the family itself.
- **Rows 5/6 -- the (a) control and the SEC-010 successor are v6-native by construction**,
  verified by direct citation of the LIVE SEC-010 artifact's `table inet` shape
  (`site-headend-install.sh:299`). Building them on the same pattern costs nothing extra
  for v6 coverage.
- **Row 1 -- the MAAS power-dial reach path structurally CAN become v6**, because
  flattening removes the old force (dialing a plane-bridge-bound libvirt address) and
  replaces it with an SSH dial to vcloud itself, over a transport (OpenSSH/qemu+ssh) that
  is vendor-verified family-agnostic, from a source (`metal-admin`) that already has v6.

**Needs live/design verification before being called real (do not build against these
yet):**
- **Row 1's concrete answer** -- whether vcloud's sshd is v6-reachable from `metal-admin`
  at an address that is NOT itself on a plane bridge (satisfying the (a) control) -- is
  explicitly what DEC-15 is gated on; this pass did not and could not resolve it
  read-only.
- **Rows 2/4 -- the D-124 transit overlay's family is an open ruling, not a tooling
  gap.** mesh-link (L2) and SSH (transport) both already support v6; what's missing is a
  NetBox carve (candidate slot: VR1's `f00::/40` "Infrastructure / site-to-site links",
  currently unassigned anywhere in the repo) and a D-124 amendment. This is a NEW gap this
  pass surfaces -- it is not currently owned by any DEC row in the D-144 body.
- **Row 7 -- moot if DEC-08 ratifies rack retirement (the likely outcome per pass2's own
  recommendation), otherwise genuinely UNVERIFIED against MAAS 3.7's own capabilities**,
  with no repo or vendor citation found either way.

**Top risks carried forward:**
1. Do not let DEC-15 get ruled assuming v6 reach "just works" because SSH is
   family-agnostic -- the actual blocker is vcloud's live reachable address, unmeasured.
2. Do not let the D-124/transit v6 question get silently dropped because it isn't a DEC
   row today -- flag it explicitly when DEC-14/DEC-16 (which touch the same leg) are
   ruled, so a future session doesn't have to rediscover the `f00::/40` slot from scratch.
3. Row 7's MAAS-3.7-v6 claim must never be asserted from this document alone -- it is
   UNVERIFIED by design; the DEC-08 retirement path is the one this pass recommends
   relying on instead.

**Verification note.** Direct reads this session: `docs/audit/container-elim-pass/FINAL-PLAN.md`
(full), `pass2-admin-report.md` (full), `scripts/lib-net.sh` (full), `scripts/lib-hosts.sh`
(full), `docs/tool-index.md` (full); `docs/design-decisions.md` D-144 (`:8210-8330`), D-124
(`:4978-5070`), D-101 (`:2243-2340`), D-139 (`:7280-7340`), D-134 amendment 2026-08-10
(`:6240-6248`), D-128 (`:5353-5397`, incl. its D-144 amendment header), D-115 (`:3723-3810`),
D-126 (`:5172-5250`), D-131 co-location note (`:5700-5710`); `docs/security-ledger.md` SEC-010
row (`:21`); `scripts/site-headend-install.sh` (`nft`/`inet` greps, `:219-314`);
`opentofu/modules/mesh-link/*.tf` (full); repo-wide greps for `f00::`, `MAAS 3.7`+ipv6,
`region+rack`, `polkit`, `vcloud.*ssh`. READ-ONLY; no mutation; nothing executed against the
cloud.