GitBucket
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=<unbracketed> 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).