# IPv6 FEASIBILITY note (pass6) -- fresh, ruling-INDEPENDENT research **Date:** 2026-08-10. **Status:** FINDINGS ONLY (GA-R5 -- nothing ruled, nothing built). Records under **D-144**; **CORRECTS the pass5 note** (`ipv6-unlock-design-note-20260810.md`), which relied on prior rulings for the links that had them instead of assessing feasibility fresh. **Why this pass exists (operator, 2026-08-10):** "the object of this review was not to follow what was previously ruled but to take a fresh look at whether or not IPv6 was feasible on any of the links that had had previous rulings or decisions or testing attached to them." Pass5 did NOT do that for the ruled links -- it cited D-101/D-139 ("PXE is v4-first", "provider-public dual-stack because the internet is v4") as the answer, and explicitly punted the researchable question ("do not import outside knowledge"). This pass researches actual platform capability, against the DEPLOYED versions (MAAS 3.7.2, Juju 3.6.27, Caracal 2024.1, OVN 24.03.2, OPNsense 26.7, Ceph Reef-era), with real upstream citations. Per-link detail + URLs: `pass6-w1-maas-ipv6-feasibility.md`, `pass6-w2-openstack-ipv6- feasibility.md`, `pass6-w3-juju-charm-ceph-feasibility.md`. ## The honest answer: IPv6 is substantially MORE feasible than the prior rulings held The two "forced-v4 anchors" pass5/D-101/D-139 leaned on do NOT hold up as feasibility statements -- both were judgements or conflations, not measured infeasibility: | Link (had a prior ruling/decision) | FRESH verdict (ruling-independent) | Real blocker / work | vs the prior position | |---|---|---|---| | metal-admin: DHCPv6 commissioning | **FEASIBLE-WITH-WORK** | no MAAS-side blocker @3.7.2 (the 2 historical bugs closed 2017/3.1); owed a live test | **CHALLENGES** D-101 "PXE v4-first" | | metal-admin: UEFI HTTP boot over v6 | **FEASIBLE-WITH-WORK** | firmware supports it; boot path not doc-confirmed end-to-end | **CHALLENGES** | | metal-admin: legacy-BIOS PXE over v6 | **INFEASIBLE** | firmware (Intel Boot Agent / PXE-2.1 is v4-only) -- but applies ONLY to legacy-BIOS-mode nodes, NOT UEFI | **NARROWS** the ruling to a firmware-mode edge case (our VMs are UEFI by choice) | | MAAS rack<->region RPC over v6 | **FEASIBLE-NOW** | MAAS source prefers `AF_INET6`; the one bug (LP#2020142) fixed in 3.5.0, before 3.7.2 | **CHALLENGES** | | provider-public external over v6 | **FEASIBLE-NOW** | direct GUA routing, **no NAT, no floating IP** -- FIP is simply the wrong model for v6 | **CHALLENGES** D-139 "dual-stack because internet is v4" (a conflation -- see below) | | Octavia LB VIP over v6 | **FEASIBLE-NOW** | `vip_subnet_id` takes v6 natively (Caracal) | -- | | API VIP (hacluster) over v6 | **FEASIBLE-WITH-WORK** | ONE charm bug: hard-coded `ip_version: ipv4` in the corosync template (LP#2111852, fix committed, unreleased) -- not a corosync/platform limit | **NARROWS** D-141/pass5 "v6 stack not ready" | | container-hosted API-charm VIP over v6 | **INFEASIBLE (today)** | juju **LP#1723240** -- live-verified still `Triaged`/`Low`, unfixed in 3.6.27 and 4.0 | **CONFIRMS** D-141's core premise | | core charm IPv6 endpoint binding | **FEASIBLE-WITH-WORK** | v6-capable; gated by LP#1723240 + charm gates (ceph-osd LP#2109798 New; ceph-mon/hacluster fix-committed) | **MATCHES** the repo's existing table | | simulated-ISP uplink edge over v6/dual | **FEASIBLE-WITH-WORK** | OPNsense 26.7 needs zero work (native dual-stack); gap is repo-side (`site-wan` module is v4-only NAT); correct v6 model is **routed, not NAT66** | **CHALLENGES** "forced v4" (it's a build choice, not a capability limit) | | Ceph cross-DC replication over v6 (DEC-24 leg) | **FEASIBLE-WITH-WORK** | new constraint: Ceph binds **one family per daemon** (`ms_bind_ipv6`/`ms_bind_ipv4`), so v6 needs the WHOLE cluster single-family, not just the replication leg | NEW -- pass5/repo left this UNASSESSED | | OVN data-plane IPv6 (internal ref doc) | **FEASIBLE (already proven)** | the repo's OWN geneve-over-v6 audit (2026-08-09) proved VM->VM v6 geneve 8/8 0% loss | **STALE INTERNAL DOC:** `charm-ip-family-compatibility.md` still says "No" -- never reconciled | ## The three genuine, surviving blockers (what fresh research CONFIRMS is hard) 1. **Legacy-BIOS PXE over IPv6** -- a real firmware constraint, but avoidable: UEFI HTTP boot is the path, and we define the VMs, so choosing UEFI removes it. Not a reason metal-admin must be v4. 2. **juju LP#1723240** -- container-hosted API-charm VIPs genuinely cannot pick their address family (unsorted-query `addrs[0]`); still open in 3.6.27. D-141's v4-active/v6-reserved holds for THAT specific case. (Note: this is the LXD API-charm container layer -- unrelated to D-144's containment-VM elimination.) 3. **External IPv6 internet reachability** -- the actual upstream internet in the rehearsal is v4; a v6-native provider NETWORK is feasible now, but real external v6 transit is a separate, real-world item D-101 deliberately defers. This is the ONE place "because the internet is v4" is a true constraint -- but it constrains EXTERNAL REACHABILITY, not the provider network's family. ## The key conceptual correction **IPv6 does not use floating IPs at all** -- direct GUA routing is the *native* v6 model, not a lesser substitute. The prior "provider-public must be dual-stack because the internet is v4" conflated two different things: (a) the provider network's ADDRESS FAMILY (can be v6-native today) and (b) EXTERNAL v6 INTERNET reachability (genuinely deferred). (a) is feasible now; only (b) forces a v4 presence, and only for actual internet egress. ## What this means for D-144's owed work (surfaced for the operator, NOT ruled) - **metal-admin can plausibly be IPv6 for commissioning** if the fleet is UEFI + a DHCPv6/HTTP-boot path is built and LIVE-TESTED. This reopens whether D-101/D-139's "metal-admin dual-stack / PXE v4-first" should stand as-is for the redeploy -- a decision for the operator, backed now by capability evidence, not a ruling this pass makes. - **provider-public, Octavia, the uplink edge** are v6-feasible now / with modest repo-side work; the only true external-v4 need is real internet egress. - **DEC-24** gains a hard design constraint: v6 cross-DC replication requires whole-cluster single-family v6 (Ceph one-family-per-daemon). - **Two internal corrections owed** (DOCFIX candidates, not done here): reconcile `charm-ip-family-compatibility.md`'s OVN "No" row against the repo's own geneve proof; and soften D-101's absolute "PXE is v4-first" to the researched reality (legacy-BIOS-only firmware limit + owed UEFI-v6 test) so a future session does not inherit the overstatement. ## Honest scope note Every "FEASIBLE-NOW/WITH-WORK" here is a CAPABILITY finding cited to upstream docs/source/bug-trackers for the deployed versions -- NOT a live proof on this cloud. Where a live test is the last mile (DHCPv6 commissioning, UEFI-v6 boot), it is named as owed. This pass corrects the METHODOLOGY error of pass5 (citing rulings as feasibility); it does not itself execute or rule.