# Pass 6 (W3) -- FRESH IPv6 feasibility check: juju/charm + Ceph links (independent of prior ruling) **Author:** W3 worker. **Scope:** a feasibility assessment, from scratch, of the three named links (juju container v6 addressing / LP #1723240, OpenStack-charms IPv6 binding in the 2024.1 channel, Ceph cross-DC replication over IPv6) -- run WITHOUT treating D-141 or `docs/charm-ip-family-compatibility.md` as settled truth. Both are cross-checked (read, not trusted) and re-derived from live web sources against the DEPLOYED versions: **Juju 3.6.27**, OpenStack charms **2024.1**, **Ceph Reef-era (Caracal)**, MAAS 3.7. Web research (WebSearch + WebFetch) SUCCEEDED for all three links; every verdict below is cited to a fetched or searched primary source, not general knowledge. READ-ONLY -- nothing built, nothing ruled, no D-number touched. **Repo cross-check performed first (as required):** `docs/design-decisions.md` D-141 (`:8003-8055`) and `docs/charm-ip-family-compatibility.md` (full) were read before any web research, to know what the repo currently claims and where a fresh finding would disagree with it. --- ## Verdict table | # | Link | Verdict | Work / blocker | Citation | Disagrees with prior ruling? | |---|---|---|---|---|---| | 1 | Juju LP #1723240 (container v6 addressing) | **INFEASIBLE (today, as-is)** | Juju's MAAS/LXD provider assigns a container ONE address per NIC, family-blind, from the requested space; a dual-stack space still yields v4-only. No juju-native fix exists. | bugs.launchpad.net/juju/+bug/1723240, fetched live 2026-08-10: **Status = Triaged, Importance = Low, Milestone = none**, reported 2017, importance auto-downgraded 2022 for inactivity, "no fix has been committed or released as of the latest update." Confirmed NOT fixed in Juju 3.6 LTS (deployed: 3.6.27) or 4.0. | **NO -- CONFIRMS the repo's premise, does not overturn it.** D-141's characterization is accurate as of today, not stale. | | 2 | OpenStack-charms IPv6 binding (2024.1 channel) | **FEASIBLE-WITH-WORK** (named work below; NOT a clean yes) | Most core API charms (charms.openstack / charmhelpers family: keystone, glance, nova-cloud-controller, cinder, barbican, designate, magnum, neutron-api, octavia, placement, openstack-dashboard) bind v6 correctly and are blocked ONLY by link 1. Three named per-charm defects still gate the rest even if link 1 were solved: **hacluster** (LP #2111852) is `Fix Committed` (merged 2025-06-24) but **not yet released** to any published channel -- 2024.1/stable still ships the broken `ip_version: ipv4` corosync template; **ceph-osd** (LP #2109798) is still `New`/unfixed -- `inet_aton`+DNS-A-only lookup crashes the mon-relation hook on v6, workaround is to force v4 CIDRs (defeats the purpose); **mysql-innodb-cluster/mysql-router**'s bare-URI defect has no independently located LP in this pass's search (not found on bugs.launchpad.net/charm-mysql-innodb-cluster) -- carried forward as repo-asserted, not web-confirmed this pass. | LP #2111852 (bugs.launchpad.net/charm-hacluster) fetched live: `Fix Committed`, trunk commit `41a75ed`, no 2024.1-channel release indicated. LP #2109798 (bugs.launchpad.net/charm-ceph-osd) fetched live: `New`, unassigned, `inet_aton`/DNS-A-only failure confirmed as described. LP #2061836 (bugs.launchpad.net/charm-ceph-mon) fetched live: `Fix Committed`, merged 2024-06-14, "allow static ipv6 addresses & binding check" -- ceph-mon verdict of `Partial` also confirmed current, not stale. keystone `prefer-ipv6` option confirmed live on charmhub.io/keystone/configurations and github.com/openstack/charm-keystone config.yaml. | **PARTIAL, ONE MAJOR DISAGREEMENT (see below on the OVN row).** The hacluster/ceph-osd/ceph-mon LP statuses all match the repo's existing table exactly -- no staleness there. | | 3 | Ceph cross-DC replication over IPv6 (rbd-mirror / radosgw multisite) | **FEASIBLE-WITH-WORK** (named work below) | Ceph daemons bind ONE family per daemon via `ms_bind_ipv4`/`ms_bind_ipv6` (not simultaneous dual-stack per-socket); Reef fixed a bug where `ms_bind_ipv4` was not auto-disabled when `ms_bind_ipv6` was set (tracker #61714-area). No rbd-mirror- or radosgw-multisite-specific IPv6 blocker was found in this pass's search of tracker.ceph.com or bugzilla -- the general dual-stack caveat is that a mixed v4/v6 cluster is awkward (some daemons v4, some v6, no single daemon serving both), but a **cluster committed to pure v6** (`ms_bind_ipv4=false`, `ms_bind_ipv6=true` cluster-wide, both DCs) is Ceph-documented as supported, and rbd-mirror/radosgw are ordinary msgr2 clients riding on that. Named work: commit the WHOLE cluster (both DC0 and DC1 Ceph clusters, not just the replication link) to a single address family -- this is a bigger lift than "just make the replication leg v6", since Ceph does not support per-daemon-pair dual family cleanly. | docs.ceph.com/en/reef/rados/configuration/network-config-ref/ fetched live: confirms `ms_bind_ipv4`(default true)/`ms_bind_ipv6`(default false) as the binding controls, "instead of" framing implies exclusive-family-per-daemon, not simultaneous dual-stack. Ceph Reef release notes / PR search: a fix "disable ms_bind_ipv4 if ms_bind_ipv6 will be enabled" landed in Reef. GitHub ceph-ansible issue #5385 and Proxmox/RH community threads corroborate: "Ceph is not able to run dual stack" per-daemon; a uniform single-family cluster is the supported shape. No rbd-mirror- or radosgw-multisite-specific v6 defect found. | **NO strong disagreement -- this fills a gap the repo's own table leaves open** (`ceph-rbd-mirror` and `ceph-radosgw` are both marked **NOT ASSESSED** in `docs/charm-ip-family-compatibility.md`; this pass gives them a first verdict: feasible, but only under a whole-cluster v6 commitment, not a v4-cluster-with-v6-replication-leg design). | --- ## THE LOUD DISAGREEMENT: the repo's own OVN "No (data plane)" verdict is STALE `docs/charm-ip-family-compatibility.md` currently reads (rows `ovn-central`/`ovn-chassis`, IPv6 column): **"No (data plane)"**, evidenced by *"OVN documents the encap column as 'The IPv4 address of the encapsulation tunnel endpoint' (`ovn-sb.xml:565`); every `ovn-encap-ip` in OVN 24.03's test suite is IPv4"* -- and flags itself *"Reported from capture, not independently re-verified."* **That verdict is now contradicted by this SAME repo's own live-measured evidence, one day older than the table's last edit.** `docs/audit/geneve-over-v6-rootcause-20260808.md` records (2026-08-09, section "LIVE-CONFIRMED"): a real VM-to-VM ping across two metal compute chassis over geneve-over-IPv6, **8/8 received, 0% loss, rtt ~3ms**, on the exact deployed stack (OVS 3.3.0 / OVN 24.03.2 / kernel 5.15.0-186). The root cause of the EARLIER "IPv4-only" appearance was NOT an OVN/kernel capability limit -- it was the `ovn-chassis` 24.03 charm delivering the v6 `ovn-encap-ip` to OVS **bracketed** (`"[2602:...::120]"`), which OVS's geneve `remote_ip` parser rejects (`ofport -1`, `"bad geneve 'remote_ip'"`). Delivered unbracketed, the tunnel instantiates and forwards real traffic. External corroboration found this pass: geneve-over-IPv6 is a long-supported OVS capability (v6 tunnel endpoints since OVS 2.6/2016) and is production-exercised elsewhere (e.g. ovn-kubernetes single-stack v6); the OVN `ovn-sb.xml` doc line and IPv4-only test-suite bias the table cites are stale documentation/test-coverage artifacts, not a real capability denial -- exactly the "NOT independently re-verified" caveat the table itself flagged, now resolved by a live test. **Net effect on this pass's charm-IPv6 verdict:** the OVN data-plane blocker should be treated as **NOT a capability blocker** (contrary to the current table row), but the `ovn-chassis` charm's bracket-format bug (no fixed charm revision confirmed by this pass's LP search -- LP #1968355 was checked and is a DIFFERENT issue, "Won't Fix") IS still a real, open, un-pinned charm defect requiring a workaround (persistent post-deploy `ovs-vsctl set open_vswitch . external_ids:ovn-encap-ip=` override) until a fixed revision ships. **Recommendation (finding, not executed):** `docs/charm-ip-family-compatibility.md`'s `ovn-central`/`ovn-chassis` row should be updated from **"No (data plane)"** to **"Partial"** (data plane IS v6-capable; the live blocker is the charm's bracket delivery bug, not OVN/OVS), citing `geneve-over-v6-rootcause-20260808.md` in place of the stale man-page/test-suite citation. This is a table-maintenance finding for the maintenance rule at the bottom of that doc ("update a row only from a MEASURED source"); it is NOT executed here (read-only pass). --- ## Bottom line - **Link 1 (LP #1723240):** confirmed still Triaged/Low/unfixed in Juju 3.6.27 -- the repo's characterization holds, no staleness. - **Link 2 (charm IPv6 binding):** mostly holds (hacluster/ceph-osd/ceph-mon LP statuses all match), EXCEPT the OVN data-plane row, which is stale and should read "Partial," not "No" -- the repo's own audit already proved this a day before the compatibility table's current text, and the table was never reconciled against it. - **Link 3 (Ceph v6 replication):** feasible under a whole-cluster single-family (v6) commitment; fills a previously NOT-ASSESSED gap, does not contradict anything ruled. - **Overall:** even correcting the OVN row, the cloud-wide container-VIP-over-v6 picture is unchanged in its bottom line -- link 1 (juju addressing) is still the universal blocker for EVERY container-hosted VIP regardless of charm, and it is still unfixed. D-141's operative conclusion (v4-active/v6-reserved for container VIPs) stands on fresh evidence. The disagreement that DOES surface (OVN data plane) affects the compatibility table's per-charm accuracy, not D-141's VIP ruling, since D-141 was never gated on the OVN data-plane row in the first place (D-141 gates on LP #1723240 + per-charm VIP defects; OVN geneve is a separate, already-D-139-owned surface). ## Maintenance note Per `docs/charm-ip-family-compatibility.md`'s own maintenance rule, its OVN row should be updated by whoever next touches that doc, citing this pass and `geneve-over-v6-rootcause-20260808.md`. Not done here -- this pass is READ-ONLY per tasking (a FRESH assessment to surface findings, not a doc edit).