# IPv6-unlock design note -- what the container-layer collapse (D-144) does and does NOT open for IPv6 > **CORRECTED 2026-08-10 by `pass6-ipv6-feasibility-note-20260810.md`.** This note RELIED ON PRIOR > RULINGS for the links that had them (it called metal-admin/PXE and provider-public "forced-v4 by > ruling" and punted the researchable question), which was NOT the fresh feasibility review the > operator asked for. Pass6 did the actual capability research: metal-admin IPv6 commissioning is > FEASIBLE-WITH-WORK on UEFI (only legacy-BIOS PXE is a firmware blocker), MAAS rack<->region v6 is > FEASIBLE-NOW, provider-public v6 is FEASIBLE-NOW via direct GUA routing (no FIP). The "forced-v4" > framing below is SUPERSEDED for those links -- read pass6 for the ruling-independent verdicts. The > parts of this note about what the collapse STRUCTURALLY touches (management-plane redesign, the > (a)/SEC-010 controls, DEC-24) remain valid. **Date:** 2026-08-10. **Status:** DESIGN NOTE (findings only, GA-R5 -- nothing ruled, nothing built). Owed design input recorded under **D-144**. Read-only follow-on pass (pass5, 3 workers): full surface enumeration + classification matrix in `pass5-w1-mgmt-v6.md`, `pass5-w2-metal-data-v6.md`, `pass5-w3-reconciliation.md`. Governing posture: **D-101 -- "IPv6 unless IPv4 is NECESSARY"** (every v4 leg is a justified exception, never a neutral default). ## The honest headline **The collapse itself unlocks very little NEW IPv6.** Of a 19-row family matrix spanning every surface the flatten touches or is adjacent to, **exactly ONE row is a clean "the collapse newly makes this v6-possible" unlock** (the MAAS power-dial reach path) -- and even that is UNVERIFIED pending a live measurement (DEC-15). The near-empty FLIP-TO-v6 class IS the finding: most of the cloud's IPv6 story was already ruled by **D-139** (a week before D-144) and is independent of the containment layer; the rest is forced-v4 by ruling. No proposed v6 flip conflicts with any standing ruling. ## (a) Genuine unlocks the collapse creates -- the actionable design inputs 1. **The MAAS power-dial reach path can go v6 (DEC-15).** Flattening removes the old force (dialing a plane-bridge-bound libvirt address). The new target is vcloud's own sshd over `qemu+ssh` (a family-agnostic transport) from `metal-admin`, which is already dual-stack. **UNVERIFIED:** whether vcloud's sshd is v6-reachable from metal-admin at an address NOT on a plane bridge (the (a) control's own constraint) -- this is precisely what DEC-15's reach half must measure and decide. Design input: DEC-15 should prefer a v6 reach, consistent with D-101. 2. **The two NEW controls the collapse creates are v6-native by construction, at zero extra cost:** the (a) cross-DC isolation control (DEC-14) and the SEC-010 transit-drop successor (DEC-16). Both inherit SEC-010's live `table inet sec010` nftables pattern -- `inet` matches v4 AND v6 on one interface-scoped ruleset. No v6-specific work needed; just don't regress to an `ip`-family table. 3. **DEC-24 is the ONE place the plane-family ruling and the collapse genuinely intersect.** The `replication` plane is ruled IPv6-only (D-139) AND its cross-DC leg has **no v6 route today** (D-139 build-constraint, still OPEN) AND D-144's DEC-24 leaves that same leg's post-flatten `virbr5`/netem attachment UNDEFINED. So DEC-24's design must resolve BOTH the carrier attachment AND the v6 route for cross-DC Ceph replication -- they are the same leg. Fold the D-139 v6-route gap into DEC-24 so it is not solved twice. 4. **A pre-existing v6 GAP surfaced, now flag it to its owning DEC:** the **D-124 region<->rack transit overlay** (`172.31.0.0/24`, and the client VM's transit leg) has **no ruling on its family** -- it is v4 by convention/history, not by necessity. The tooling does not block v6 (mesh-link is bare L2; SSH is family-agnostic), and a candidate v6 home is already RESERVED in the apex model (`f00::/40` "Infrastructure / site-to-site links", D-115) but carved nowhere. This is a pre-existing gap (predates D-144), but DEC-14/DEC-16 already govern this same leg -- so it should be decided WITH them, not rediscovered later. Candidate DEC material; NOT resolved here (GA-R5). ## What stays FORCED-v4 (so the unlock is not oversold) - **metal-admin PXE / node commissioning** -- v4 by RULING (D-101/D-139 "PXE is v4-first"; `dhcpd6` deliberately OFF; v4 commissioning range; rack has zero global v6). IMPORTANT: this is a *ruling*, not a measured platform ceiling -- **whether MAAS 3.7 can commission v6-only is UNVERIFIED** (no test/capture/vendor citation on disk). Do not assert PXE-over-v6 is impossible; assert only that this repo built and ruled a v4-first path and never tested an alternative. - **The simulated-ISP uplink NAT** (`172.30.x`, `modules/site-wan`) -- single-stack v4 by module construction; a deliberate VR1 rehearsal simplification (D-101 rejected NAT64/DNS64, defers external v6 to the next full deployment). D-144 removes the WAN-bridge INDIRECTION (D-125) around it but leaves the NAT and its family unchanged. - **provider-public** and **metal-admin (base plane)** -- ruled DUAL-STACK (D-139): FIPs/API-VIPs against a still-v4 internet; PXE. Both families load-bearing by ruling. ## What is NOT unlocked by the collapse (different layers -- do not credit D-144) - **D-139's entire plane family matrix** (the six planes' v6-only/dual rulings, incl. the four east-west planes ruled v6-only but still dual-carved live -- v4 removed LAST "after each is proven", not yet done). Ruled 2026-07-31; independent of the containment layer. - **The geneve-over-v6 rebuild fix** (unbracket `ovn-encap-ip` + carve v6 on the containerized OVN chassis) -- an OVN/OVS build-mechanics fix on the NODE layer; gated by `scripts/geneve-encap-assert.sh`. Its relationship to D-144 is NONE. - **The LXD API-charm container v6 gap (juju LP #1723240 / D-141)** -- v4-active/v6-reserved, gated on a juju upstream defect (`EthernetDeviceForBridge` picking `addrs[0]` from an unsorted query) + per-charm fixes. **"container-elim" here means the `vvr1-dcN` CONTAINMENT VM (D-122/D-123), NOT juju's LXD control-plane containers on the node VMs.** D-144 does not touch, unblock, or moot LP #1723240 -- an operator might assume flattening the substrate flattens this defect away; it does not (juju, not the hypervisor, is the constraint). ## Roosevelt-delta Transfers to bare metal (v4 by protocol/juju-layer, not virtualization): the **PXE v4-first ruling** (though a v6-only capability remains unmeasured) and **LP #1723240** (juju-layer, substrate-independent). Does NOT transfer (virtual-only): the `qemu+ssh` dial + D-125 bridge-in (removed), the (a) control + SEC-010 successor + the power-key mitigation (artifacts of single-hypervisor co-residency -- bare metal has per-host BMC/IPMI + real NICs), and the simulated-ISP v4 NAT (a rehearsal simplification; Roosevelt gets full v4+v6 edge transport per D-101). The mesh/netem carrier (DEC-24's leg) is a virtualization shim with no bare-metal analog -- its answer must be found in VR1. ## Bottom line for D-144's owed work Fold three things into the already-owed DEC design: - **DEC-15:** prefer a v6 reach for the power dial (verify the vcloud-sshd address is v6-reachable off any plane bridge). - **DEC-14/DEC-16:** decide the D-124 transit-overlay family (v6 candidate `f00::/40` reserved) on the same leg these DECs already govern; keep the controls' nftables `inet`-family (v6-native) shape. - **DEC-24:** resolve the cross-DC replication carrier AND its v6 route together (same leg; D-139's open v6-route gap belongs here). Everything else in the IPv6 story is D-139/D-141 work, independent of the collapse.