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 / ipv6-unlock-design-note-20260810.md
@JANeumatrix JANeumatrix 1 hour ago 6 KB IPv6-unlock design note (pass5, read-only) -> recorded under D-144 owed items
Raw Blame History

IPv6-unlock design note -- what the container-layer collapse (D-144) does and does NOT open for IPv6

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.