IPv6 migration in five steps: Planning, Dual-Stack, Prefix Delegation and Fallback

The IPv6 migration is not a one-off technical project but a process that requires planning, testing and clear rollback paths. The focus keyword IPv6 migration appears early because many decision-makers and operators underestimate the transition: addressing schemes, provider behavior (e.g., Prefix Delegation), firewall rules and VPN constellations must be synchronized so that operations and security are preserved. This article guides you through the practical process in five clear steps, with test sequences, example configurations and troubleshooting notes.

Why a structured IPv6 migration is necessary

IPv6 resolves address scarcity and brings improvements in routing and autoconfiguration, while at the same time it changes core operational assumptions. Many tools, monitoring pipelines and firewalls expect IPv4 addresses; protocols like Neighbor Discovery (ND) and SLAAC (Stateless Address Autoconfiguration) operate differently than ARP and DHCPv4. A faulty transition can lead to reachability problems, unexpected IPv6 traffic or security vulnerabilities.

Overview: The five steps

• Step 1: Planning and inventory
• Step 2: Dual-Stack basics and tests
• Step 3: Set up Prefix Delegation (PD) with the provider
• Step 4: Fallback and rollback strategies
• Step 5: Operations, monitoring and VPN integration

Step 1 — Planning and inventory

Good planning reduces surprises. Document devices, software and dependencies as well as the IPv6 capability of the deployed components.

Inventory and compatibility check

Create an inventory of all routers, firewalls, load balancers, VPN gateways, servers and relevant network services (DNS, DHCP, monitoring). Check firmware and OS versions: not all older devices have full IPv6 support, or they may have bugs in ND/RA handling. Note vendors, models and versions — these form the basis for upgrade and test decisions.

Address plan and PD requirements

Clear address plans are more important than with IPv4: IPv6 prefixes are hierarchically organized. Decide whether you will request a /48, /56 or /64 from your provider; allocations are commonly /48 for larger B2B, /56 or /60 for smaller sites. Prefix Delegation (PD) is the mechanism by which the provider delegates a prefix to your routers — more on that later.

Security and compliance dependencies

Inventory which logs, IDS/IPS, SIEM rules or compliance controls do not support IPv6. Plan for parallel operation and define which security policies must be adjusted: firewall rules, network segmentation, access lists and monitoring filters.

Test sequence before production start

Before tests begin, define metrics: reachability (ICMPv6), DNS resolution via AAAA records, application tests (HTTP/S over IPv6), MTU behavior and VPN connections. Set test windows, responsibilities and metrics for success/failure.

Step 2 — Introduce and test Dual-Stack

Dual-Stack means hosts and network components speak both IPv4 and IPv6 in parallel. This is the recommended transition method because applications and paths can be validated individually.

Choosing between SLAAC and DHCPv6

SLAAC (Stateless Address Autoconfiguration) generates addresses automatically from Router Advertisements (RA). DHCPv6 provides centralized allocation, comparable to DHCPv4. Choose SLAAC if you want simple, autonomously configured subnets; choose DHCPv6 for centralized control, reservations and more detailed options. A hybrid operation is often sensible: RA for the default gateway + DHCPv6 for DNS and other options.

Router‑Advertisements (radvd) Beispiel

Ein einfaches radvd‑Snippet (Router‑Advertisement Daemon) für ein /64‑Subnetz:

# /etc/radvd.conf
interface eth1
{
    AdvSendAdvert on;
    prefix 2001:db8:1:0::/64
    {
        AdvOnLink on;
        Adv autonomous on;   # aktiviert SLAAC
    };
};

Diese Konfiguration bewirkt, dass Hosts im Subnetz eine SLAAC‑Adresse aus dem angegebenen Präfix bilden. Wenn Sie DHCPv6 nutzen, setzen Sie „Adv autonomous off“ und verteilen Adressen per DHCPv6.

Prüfen von IPv6‑Erreichbarkeit

Beispiele für Prüfungen auf Linux und Windows:

# Linux: Prüfen ob eine Route und RA empfangen werden
ip -6 route show
rdisc6 eth1  # zeigt Router Advertisements (Teil von ndisc6-Tools)

# Windows: IPv6 Konfiguration prüfen
Get-NetIPAddress -AddressFamily IPv6
Test-NetConnection -ComputerName example.com -InformationLevel Detailed -TraceRoute

DNS und AAAA‑Records

Ensure that DNS zones support AAAA records and that the TTL strategy is aligned with the expected changes. Internal DNS servers should answer dual‑stack queries correctly; check resolver configuration (e.g. systemd-resolve, Unbound or BIND).

Schritt 3 — Prefix‑Delegation (PD) vom Provider

Prefix Delegation is the method by which your ISP dynamically assigns a subnet prefix to your customer router, typically via DHCPv6‑PD (DHCPv6 Prefix Delegation). This is important for sites with a dynamic WAN where the prefix assigned by the provider may change.

Wie PD funktioniert und was schiefgeht

With DHCPv6‑PD, your CPE‑router requests a prefix from the ISP DHCP server. The router uses this prefix locally (e.g. as multiple /64s for VLANs). Problems occur when the provider changes prefixes frequently, devices do not maintain PD stably, or RA/DHCPv6 configurations conflict (e.g. when SLAAC generates local addresses that lie outside the delegated range).

Beispiel: ISC dhcpd6.conf für PD

An uncomplicated example for the DHCPv6 server (provider side) or for illustrating PD allocation:

# /etc/dhcp/dhcpd6.conf (Provider/Server-Seite Beispiel)
subnet6 2001:db8:100::/48 {
    range6 2001:db8:100:1:: 2001:db8:100:ffff:ffff::;
}
# Delegation: weist /56 an anfragenden Client mit duid "client-duid"
pd 2001:db8:200::/56 {
    prefix6 2001:db8:200::/56;
    pool6 2001:db8:200::/56;
}
host client-router {
    host-identifier option dhcp6.client-id 00:01:00:01:...
    fixed-address6 2001:db8:100:1::1;
    pd 2001:db8:200::/56;
}

In data centers or when operating your own DHCP servers, this configuration serves as a reference. In practice, providers use proprietary systems; check the provider documentation and request stability guarantees (e.g. PD lease time and frequency of changes).

Router‑Konfiguration: Delegiertes Präfix auf interne Interfaces anwenden

The CPE router must apply the delegated prefix dynamically to internal VLANs/subnets. On Linux routers, for example, a script can read the received PD prefix and configure interfaces. Verify how your router handles PD updates: rebindings should not cause flapping of internal addresses.

IPv6 migration: rollout plan and stakeholder communication

A technical migration succeeds only with clear responsibilities. Define roles: network operator, security, application owners, test and rollback owners. Plan communication points: announcement, end of testing, go/no‑go decision, post‑rollout review.

Typical schedule for a site rollout

A recommended mini project-plan framework per site:

• Day 0–7: inventory, firmware check, provider clarification (PD / lease time)
• Day 8–14: lab tests (dual-stack, PD, VPN) and firewall templates
• Day 15–16: pilot on non-critical VLAN, monitoring active
• Day 17: go/no‑go window, production rollout
• Day 18–30: observation phase, review and stabilization

Acceptance criteria

Define measurable criteria: IPv6 reachability of all critical services, no increase in error logs, functioning VPN tunnels over IPv6, no significant performance regressions (latency/MTU).

Step 4 — fallback and rollback strategy

A clear fallback plan is essential. Dual‑stack facilitates this: in case of problems you can selectively disable IPv6 or withdraw IPv6 routes without affecting IPv4.

Quick disabling of IPv6

Linux (sysctl) for temporarily disabling all IPv6 on a host:

# Temporär: für diese Sitzung
sudo sysctl -w net.ipv6.conf.all.disable_ipv6=1
sudo sysctl -w net.ipv6.conf.default.disable_ipv6=1
# Permanent: /etc/sysctl.d/99-disable-ipv6.conf
echo 'net.ipv6.conf.all.disable_ipv6=1' | sudo tee /etc/sysctl.d/99-disable-ipv6.conf
sudo sysctl --system

Windows (for quick testing) via PowerShell: disabling individual IPv6 interfaces:

# Beispiel: IPv6 auf Interface 'Ethernet' deaktivieren
Set-NetAdapterBinding -Name 'Ethernet' -ComponentID ms_tcpip6 -Enabled $false

Note: Completely disabling IPv6 on Windows is not recommended because some Windows features (e.g. Teredo, IPHTTPS) depend on it. Use this measure only for fault isolation and after consultation with application teams.

Routing fallback and preference control

IPv6 does not have a direct equivalent to „Policy‑Based Routing“ for protocol preferences; operating systems often prefer IPv6 over IPv4 when both addresses are present. You can control this with source-address policies or an RFC6724 policy (address preference), for example by adjusting policy tables on clients or load balancers. Alternatively, configure DNS so that AAAA records are introduced with delay until paths are stable.

Rollback checklist

• Disable IPv6 (if necessary) and check reachability
• Withdraw DNS AAAA records or reduce TTL
• Remove/neutralize firewall and NAT rules for IPv6
• Contact provider (PD/RA changes) and check logs
• Document rollback and include lessons learned in the review

Step 5 — operations, monitoring and VPN specifics

After a successful rollout, stabilize operations and expand monitoring. VPNs (e.g. IPsec or WireGuard) require special rules because tunnel configurations often use IP-based policies.

Monitoring and metrics

Add IPv6 checks to your monitoring: ICMPv6 latency, Neighbor Discovery errors, tunnel status, number of IPv6 sessions (conntrack), AAAA errors in DNS, MTU errors (ICMPv6 Packet Too Big). Adjust SIEM parsing so logs index and correlate IPv6 addresses correctly.

nftables example rules for IPv6

A minimal example that allows ICMPv6 for ND and permits established connections:

# /etc/nftables.conf (excerpt for IPv6)
table inet filter {
    chain input {
        type filter hook input priority 0;
        policy drop;

        # Allow loopback
        iif lo accept;

        # Allow established/related
        ct state established,related accept;

        # Neighbor Discovery / ICMPv6
        ip6 nexthdr icmpv6 icmpv6 type { destination-unreachable, packet-too-big, time-exceeded, parameter-problem, echo-request, echo-reply, nd-router-advert, nd-router-solicit, nd-neighbor-solicit, nd-neighbor-advert } accept;

        # SSH for admins (example)
        tcp dport 22 accept;
    }
}

ICMPv6 is not a ‚ping-only‘ protocol but part of the functionality (Neighbor Discovery). Do not blanket-block ICMPv6; allow the necessary types.

VPN and IPv6 — concrete verification and troubleshooting steps

IPsec: Check with the local IPsec toolset (e.g. strongSwan) whether Security Associations (SAs) for IPv6 are established. Pay attention to traffic selectors, as they determine which IPv6 prefixes may be carried over the tunnel. WireGuard: Check AllowedIPs and MTU; WireGuard routes all specified prefixes through the interface.

# strongSwan status (Linux)
sudo ipsec statusall

# WireGuard status
sudo wg show

# PMTU test (IPv6) - sends large packets; 'do' forces no fragmentation
sudo ping6 -c 3 -s 1400 -M do example.com

Failure scenarios: If the tunnel is established but there is no end-to-end connectivity, first check MTU/ICMPv6 Packet Too Big; many tunnels (IPsec ESP) require MTU adjustment or MSS clamping. If only individual prefixes are unreachable, check traffic selectors/AllowedIPs and provider PD routes.

Practical testing tools and tests

Performance and path tests with iperf3 over IPv6:

# Start server (listens on IPv6)
iperf3 -s -6
# Test client from remote host
iperf3 -c 2001:db8::1 -6 -t 10

A successful iperf3 measurement confirms TCP/UDP path and MTU behavior; failing tests typically indicate routing, firewall, or MTU issues.

Automation and configuration management

Automation reduces human error during rollouts and rollbacks. Use configuration management (Ansible, Salt, Puppet) for radvd, DHCPv6 client hooks and nftables templates. Ensure tasks are idempotent to make repeated runs safe.

# Example: Ansible task to deploy a radvd config (excerpt)
- name: Deploy radvd configuration
  ansible.builtin.copy:
    dest: /etc/radvd.conf
    content: |
      interface eth1
      {
          AdvSendAdvert on;
          prefix 2001:db8:1:0::/64
          {
              AdvOnLink on;
              Adv autonomous on;
          };
      };
  notify: RESTart radvd

- name: RESTart radvd
  ansible.builtin.service:
    name: radvd
    state: RESTarted
    enabled: yes

Version configurations in Git and use playbook reviews as change control. Test playbooks against a lab-like environment before rolling out to production.

Practical scenarios, common pitfalls and quick verification steps

Here is a compact list of key error sources and how to test quickly:

• No IPv6 from the provider: Check the WAN interface with ip -6 addr and whether RA/PD is actually received.
• DNS returns AAAA but connection breaks: Test with iperf3 and check MTU/firewall.
• Neighbor Discovery fails: Check tcpdump for ICMPv6‑ND.
• VPN breaks after IPv6 activation: Check AllowedIPs/TrafficSelectors and firewall policies.
• Hosts prefer IPv6 and cannot reach services: Check the RFC6724 policy or introduce AAAA records incrementally.

Checklist for a secure rollout

1. Update inventory and verify IPv6 support.
2. Agree address plan and PD requirements with the provider.
3. Lab tests: validate Dual‑Stack in an isolated VLAN.
4. Create and test firewall and IDS rules for IPv6 (consider ICMPv6).
5. Define VPN test cases: IPsec, WireGuard, client access.
6. Adapt monitoring: ICMPv6, ND, conntrack, DNS AAAA checks.
7. Document and verify a rollback procedure ready for use.

Conclusion

A successful IPv6 migration is predictable and can be planned: begin with a robust inventory, introduce Dual‑Stack in a controlled manner, use Provider‑Prefix‑Delegation (PD) correctly and maintain explicit fallback mechanisms. In operation, monitoring and specific VPN tests become routine. Technical depth, as demonstrated here, ensures changes are predictable and production operation remains secure. Emphasize small, measurable steps, automation and documented rollback paths — this minimizes risk and establishes the prerequisites for stable IPv6 operation.

RA and SLAAC are also important for this topic. This article contextualizes these aspects clearly and shows what matters in day-to-day operations.