D-141 ADOPTED: IPAM allocations are dual-stack, status-distinguished
...
Operator ruling, exact utterance: "Yes, but you should expand on the record. It
should be noted that when creating future ipam allocations the IPv4 and IPv6
blocks must follow this same structure."
Immediate: the 26 GUA v6 VIP addresses D-139 step 6 created stay in the apex at
status reserved (already their measured state, no NetBox mutation) and are not
promoted to active until the v6 VIPs are live and verified.
Standing rule (the architectural half, hence a D-number under GA-R3 A1):
every IPAM allocation is authored dual-stack and the STATUS field carries the
truth -- v4 active (live), GUA v6 reserved (planned/collision-protected),
superseded ULA deprecated (history). The apex records current reality AND future
plan in one place, legible from status alone: apex driving deploy, not
back-filled to it. Four binding rules: author both families together; status
bears truth never prose; promotion gated on a NAMED capability; never delete a
reserved future-family block (it is the conversion input).
Adjacent to G18 but does not answer it -- D-141 governs allocation STRUCTURE, G18
is the separate lb-mgmt-prefix ruling still deferred-until-live. The promotion
gate for the API-charm v6 VIPs is docs/charm-ip-family-compatibility.md (juju
LP#1723240 + the per-charm fixes), which now cites D-141 as its governing
decision. Roosevelt analog: every DC's IPAM authored dual-stack from day one, v6
reserved until capable, so no DC ever needs a v4->v6 re-carve -- only a status
promotion.
CURRENT-STATE updated same commit (GA-R1 C1); next-free D 141 -> 142.
repo-lint 0 fail.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01HvCyrwvYTTcDYnRErfMsNf
