# D-101 IPv6 family-matrix charm research (2026-07-09/10) Basis for `overlays/dc-dc-ipv6-family-matrix.yaml` (tooling gap register item #13). Researched directly against real charm source/config via WebFetch/ WebSearch -- not inferred from training-data memory of charm behavior, which this repo's own discipline treats as a real risk class (the OpenTofu module work earlier this session found a real syntax bug from exactly that mistake). ## Method Fetched actual `config.yaml` files and, where a config option's semantics were ambiguous from prose alone, actual charm source/commits, from the `openstack/charm-*` and `openstack-charmers/charm-layer-ovn` repositories (GitHub mirrors of the OpenDev-hosted canonical source) and `bugs.launchpad.net`. Every claim below is labeled CONFIRMED (read the actual file/commit) or INFERRED-BY-PATTERN (not independently checked, reasoned from a shared framework) -- do not treat the two as equal confidence. ## Findings ### 1. `prefer-ipv6` is a real, shared charms.openstack-family config option **CONFIRMED** directly in `charm-keystone/config.yaml`: a boolean, default `False`, enabling IPv6 support. **CONFIRMED** via `charm-nova-cloud-controller`'s actual "Dual Stack VIPs" commit (`1fa5f7a673006bc6faaf9d377e791448a5ed661b`): setting `prefer-ipv6: true` causes the charm's HAProxy config template to add `bind :::{{ports[0]}}` ALONGSIDE the existing `bind *:{{ports[0]}}` -- i.e. this is a genuinely ADDITIVE dual-stack switch (HAProxy listens on both address families simultaneously), not an either/or toggle. The commit message states this explicitly: "HAProxy always listens on both IPv4 and IPv6 allowing connectivity on either protocol." **INFERRED-BY-PATTERN, NOT independently confirmed per-charm:** glance, neutron-api, placement, cinder, barbican, magnum, openstack-dashboard, ceph-radosgw all build on the same charms.openstack base classes as keystone/nova-cloud-controller, so the same `prefer-ipv6` option and additive-dual-stack HAProxy behavior is EXPECTED -- but each charm's real `config.yaml` was not individually fetched this session. Confirm via `juju config ` once any of these charms is actually deployed, before trusting the overlay is complete for all eleven. ### 2. The existing `vip:` option takes additional v6 addresses, appended **CONFIRMED**: `charm-keystone/config.yaml`'s `vip` option description: "Virtual IP(s) to use to front API services in HA configuration. If multiple networks are being used, a VIP should be provided for each network, separated by spaces." This repo's `bundle.yaml` already uses this exact mechanism today (D-020's triple-VIP pattern -- e.g. `keystone`'s `vip: "10.12.4.50 10.12.8.50 10.12.12.50"`, one address per Juju-space binding). Adding v6/GUA addresses to the SAME space-separated list, once `prefer-ipv6: true` makes HAProxy listen on both families, is the mechanism -- confirmed consistent with finding #1's dual-stack commit, though the EXACT mapping of "which list position pairs with which network" inside the charm's own context-building code was not traced line-by-line this session. Treat the overlay's VIP ordering (existing v4 entries first, then the new v6/GUA entries appended) as the reasonable, but not byte-for-byte charm-source-confirmed, convention. ### 3. `ceph-mon` has a real, separate `prefer-ipv6` + network-CIDR mechanism **CONFIRMED** directly in `charm-ceph-mon/config.yaml`: - `prefer-ipv6` (bool, default False) -- per the charm's OWN description, "If set to False (default) IPv4 is expected," reading as a straight EITHER/OR switch for THIS charm specifically (unlike the additive HAProxy behavior in finding #1) -- which is actually the correct shape for D-101's ULA-ONLY storage/replication planes (no v4 needed at all, so a clean switch to v6-only is exactly right, not a limitation). - `ceph-public-network` / `ceph-cluster-network` (string, space-delimited CIDR list) -- these map directly to D-101's own cited mechanism name, `ms_bind_ipv6` (the underlying Ceph daemon config the charm sets when `prefer-ipv6` is enabled). - A real caveat quoted from the charm's own docs: "these charms do not currently support IPv6 privacy extension. In order for this charm to function correctly, the privacy extension must be disabled and a non-temporary address must be configured/available on your network interface." This is a real host/OS-level prerequisite for every ceph-mon unit's storage/replication interface -- not something an overlay file can set, needs to be part of Phase-0/node-prep discipline. ### 4. OVN has NO explicit IPv6/encapsulation charm-config option **CONFIRMED**: fetched the FULL `charm-layer-ovn/config.yaml` (the shared base for `ovn-central`/`ovn-chassis`) -- 25 options total, none related to IPv6, address binding, or encapsulation IP. geneve-over-v6 for the data-tenant plane is therefore not a charm-config concern at all; it follows whichever IP family the unit's bound interface on that plane actually has. Since data-tenant is ULA-only (no v4 present) per D-101, this needs no overlay entry -- the absence of an entry IS the correct configuration, not an oversight. ### 5. Vault's cert-issuance code has no IPv4/IPv6 distinction **CONFIRMED**: fetched `charm-vault/src/lib/charm/vault_pki.py`'s actual `sort_sans()` function -- it splits SANs into "IP SANs" vs. "name SANs" using `charmhelpers.contrib.network.ip.is_ip()`, with NO further IPv4/IPv6 differentiation anywhere in the function or its caller (`generate_certificate()`, which just joins whatever IP SANs it's given into a comma-separated string). D-109's "Vault issues v4+IPv6-SAN certs" requirement is technically supported by the charm's own code path, not merely assumed. ### 6. A real, open upstream risk for Octavia's lb-mgmt-net over IPv6 **CONFIRMED** (real, still-referenced Launchpad bug reports, not speculation): #1911788 ("IPv6 mgmt network not working, octavia can't talk to amphora," OpenStack Octavia Charm) and #1913409 ("octavia_amp_network does not support IPv6," kolla-ansible, describing the same underlying Octavia limitation from a different deployment tool). #1911788's root cause traces to an OVN/LXD/MAAS hostname-resolution mismatch (Neutron's `binding_host_id` carrying a short hostname while OVN's controller expects the FQDN) -- it was marked a duplicate of #1896630, "managing /etc/hosts for containers." That is the SAME CLASS of problem this repo's own D-008 bootstrap order (static /etc/hosts bootstrap -> os-public-hostname -> vault certs -> Designate, reactivated by D-106 for VR1) already exists to harden against -- so this is NOT necessarily a fatal blocker here, but it IS a real, open, documented upstream risk for exactly the kind of network (Octavia's amphora management network) D-101 wants to put on ULA-only IPv6. `overlays/dc-dc-ipv6-family-matrix.yaml` deliberately does NOT attempt an Octavia lb-mgmt-net IPv6 change for this reason -- that needs its own explicit decision (accept the risk and test for real once DC1 exists, or keep Octavia's lb-mgmt-net dual-stack/v4 as a deliberate, logged D-101 exception), presented here rather than silently forced through. ## What this closes vs. what remains open CLOSES (mechanism): the "no overlay file exists, charm option names unconfirmed" half of gap #13 -- a real, sourced overlay now exists at `overlays/dc-dc-ipv6-family-matrix.yaml`, covering 9 of Octavia's 11 sibling dual-stack API charms directly plus ceph-mon's ULA-only switch, with OVN correctly requiring no entry. STAYS OPEN: (a) the 8 INFERRED-BY-PATTERN charms' `prefer-ipv6` option needs live `juju config` confirmation once any of them is actually deployed; (b) the exact VIP-list-position-to-network mapping inside each charm's context-building code was not traced to source; (c) Octavia's lb-mgmt-net IPv6 question is a real, open decision, not resolved by this research; (d) none of this has been applied or tested against a live model -- UNVALIDATED, same posture as every other OpenTofu/overlay artifact built this session.