Fork: 0
OpenStack / openstack-caracal-dc-dc
Transfer to URL with SHA Find file
Newer
Older
openstack-caracal-dc-dc / docs / audit / container-elim-pass / pass5-w1-mgmt-v6.md
@JANeumatrix JANeumatrix 2 hours ago 14 KB IPv6-unlock design note (pass5, read-only) -> recorded under D-144 owed items
Raw Blame History

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 /48s (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.