Operator: 'The dual stack was only a safety net instead of jumping straight into
a ipv6 only deployment but it appears that more items were not configured with
IPv6 like they should have been.' So IPv6 is the target and v4 the fallback,
matching D-101's own 'v6 wherever possible, v4 only where forced'. A systematic
dc0 sweep was run rather than fixing the container layer alone.

BUILT on v6: node statics (54 links), the six v6 plane subnets, juju's per-plane
host bridges (all six carry global v6), spaces in both families, the dual-family
VIPs, Octavia PKI v6 IP SANs.

ABSENT on v6, all measured:
 (i)   ALL SIX v6 plane subnets carry ZERO ip ranges, against every v4 plane
       holding its D-134 reserved bands and metal-admin also holding dynamic
       .201-.254. Uniform, not a metal-admin quirk.
 (ii)  THE RACK HAS NO GLOBAL v6 AT ALL -- so the mirror, the node-DNS forwarder
       and the MAAS rack agent are v4-only by construction. F2 from 2026-07-30,
       now measured as the whole rack rather than one plane.
 (iii) The mirror does not answer over v6 (000), following from (ii).
 (iv)  Nodes have no v6 default route -- no RA, no gateway.

CONSEQUENCE: completing IPv6 to the charm layer is a PROJECT, not a fix. A range
alone would give containers v6 addresses with no v6 default route and no
v6-reachable services, so prefer-ipv6 would still not produce a working cloud.
The safety net is doing what it was put there for.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01HvCyrwvYTTcDYnRErfMsNf