ADR-023 IPv6 numberplan and cluster scale strategy

Context and Problem Statement

adr-007-ip-addressing-2026 is accepted for 1H2026 RFC1918 delivery, but it does not define the forward IPv6 strategy for government category usage and large-scale cluster growth.

This ADR defines the long-term model for category-aligned IPv6 allocation, overlap governance, and cluster scale profiles.

Decision Drivers

• Keep routed defaults identity-preserving and NAT-minimized.
• Align public-sector addressing with the Logius IPv6 framework where in scope.
• Scale from tens to hundreds of clusters without ad-hoc renumbering.
• Keep overlap handling explicit, auditable, and exception-based.
• Keep forward policy compatible with EVPN VRF controls and OpenShift CUDN or UDN architecture.

Considered Options

1. Keep RFC1918-only strategy as the long-term model.
2. Adopt dual-track strategy: preserve ADR-007 phase baseline and define IPv6-forward model with unique routed defaults plus overlap exceptions.
3. Use overlap-heavy VRF-lite as common default for tenant design.

Decision Outcome

Decision remains draft. Working direction is Option 2.

Working direction policy:

• ADR-007 remains valid for 1H2026 phase delivery baseline.
• Forward model adopts IPv6-first planning for long-term scale and government interconnect alignment.
• For government-facing allocations, use Logius-managed ranges and NC usage semantics with mandatory mappings for NC1 (internet) and NC2 (Diginetwerk); treat NC3 as reserved for shared-government scenarios under additional agreements and NC5 as internal-use recommendation.
• CUDN-first routed domains use unique prefixes by default; overlap is exception-only in isolated VRF domains.
• Route leaking is used only for unique-prefix reachability policy.
• Overlap handling policy is operational and explicit:
• do not leak overlapping prefixes into shared routed domains,
• expose shared dependencies through controlled boundary endpoints,
• apply translation only at that boundary with identity-impact evidence.
• Internal scale planning from one /46 pool follows profile-based allocation:
• /56 per cluster for high cluster count,
• /54 per cluster as balanced default,
• /53 per cluster for high-density clusters.
• Worked density math and caveats are maintained in topic-network-ip-addressing-scale-and-vrf-model and are treated as capacity math, not product support claims.

Next Decision Trigger

• Decision owner: Network Architecture with Platform Architecture review.
• Promote to accepted when all acceptance criteria are met on the in-scope target lane:
• NetBox allocation profiles (/56, /54, /53) implemented.
• CI duplicate-prefix leak prevention checks implemented and passing.
• Overlap exception boundary tests implemented and passing.
• Support-envelope evidence captured for sizing-related change requests (capacity math, product support reference, local policy cap).

Pros and Cons of the Options

Option 1 - RFC1918-only long-term strategy

• Good: Keeps immediate implementation simple.
• Bad: Weak long-term scale model.
• Bad: Does not align government-facing IPv6 policy clearly.

Option 2 - Dual-track phase-plus-forward model (working direction)

• Good: Preserves 1H2026 baseline while adding a clear forward model.
• Good: Improves scale planning and reduces renumbering risk.
• Good: Keeps overlap handling explicit and exception-governed.
• Bad: Requires additional intent-model and validation logic.

Option 3 - Overlap-heavy VRF-lite default

• Good: Reduces near-term pressure on unique prefix assignment.
• Bad: Reintroduces translation complexity at service boundaries.
• Bad: Weakens end-to-end source identity and troubleshooting clarity.