# 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.
