Dual stack IPv6 migration across a production network

Draft. The technical narrative is accurate to the engagement type; the figures marked [ ] are placeholders awaiting real numbers. Replace or remove them before publication.

Project description

IPv4 address exhaustion stopped being a future problem some time ago. For an operator running a production network, however, the difficulty was never whether to move to IPv6 — it was how to do it without a maintenance window large enough to matter, and without a class of subscriber quietly losing service on a Tuesday afternoon.

Our client needed to introduce IPv6 across a live network while every existing IPv4 service continued to behave exactly as before. Dual stack was the chosen strategy: run both protocols in parallel, move traffic gradually, and keep a rollback path open at every step.

Outcomes and approach

We planned the migration backwards from the rollback. Each phase was designed so that it could be reversed independently, which constrained the sequencing more than any technical factor did — and is the reason the migration stayed boring.

Addressing plan before configuration. An IPv6 addressing plan is difficult to change once traffic depends on it. The plan was designed around the network's actual topology and growth expectations rather than translated mechanically from the existing IPv4 scheme.

Staged by blast radius. Infrastructure and management planes first, then internal services, then subscriber-facing traffic — smallest consequence first, so that each class of problem surfaced while it was still cheap.

Dual stack, not translation, wherever possible. Translation mechanisms introduce their own failure modes and their own debugging burden. Where native dual stack was achievable it was preferred, with translation reserved for the specific cases that genuinely needed it.

Monitoring before migration. Per-protocol visibility was in place before any traffic moved, so that "is this an IPv6 problem?" was answerable from a dashboard rather than from a packet capture.

Highlights of the solution

• IPv6 addressing plan and allocation policy
• Dual stack rollout across routing, DNS and subscriber-facing services
• Routing protocol configuration and policy for both address families
• Firewall and security policy parity across protocols
• Per-protocol monitoring and traffic visibility
• [N] phases delivered with [DOWNTIME] interruption to existing IPv4 service

Technologies

IPv6 · dual stack · BGP · OSPFv3 · DNS64 / NAT64 · routing policy · network monitoring