Die IPv6‑Migration ist kein einmaliges Technikprojekt, sondern ein Prozess, der Planung, Tests und klare Rückfallwege verlangt. Das Fokus‑Keyword IPv6‑Migration erscheint früh, weil viele Entscheider und Betreiber die Umstellung unterschätzen: Adresskonzepte, Provider‑Verhalten (z. B. Prefix Delegation), Firewall‑Regeln und VPN‑Konstellationen müssen synchronisiert werden, damit Betrieb und Sicherheit erhalten bleiben. Dieser Artikel führt Sie in fünf klaren Schritten durch den praktischen Ablauf, mit Prüfsequenzen, Beispielkonfigurationen und Troubleshooting‑Hinweisen.
Warum eine strukturierte IPv6‑Migration nötig ist
IPv6 löst die Adressknappheit und bringt Verbesserungen bei Routing und Autoconfiguration, gleichzeitig verändert es zentrale Betriebsannahmen. Viele Tools, Monitoring‑Pipelines und Firewalls erwarten IPv4‑Adressen; Protokolle wie Neighbor Discovery (ND) und SLAAC (Stateless Address Autoconfiguration) arbeiten anders als ARP und DHCPv4. Eine fehlerhafte Umstellung kann zu Erreichbarkeitsproblemen, unerwartetem IPv6‑Traffic oder Sicherheitslücken führen.
Überblick: Die fünf Schritte
- Schritt 1: Planung und Bestandsaufnahme
- Schritt 2: Dual‑Stack Grundlagen und Tests
- Schritt 3: Prefix‑Delegation (PD) beim Provider einrichten
- Schritt 4: Fallback‑ und Rollback‑Strategien
- Schritt 5: Betrieb, Monitoring und VPN‑Integration
Schritt 1 — Planung und Bestandsaufnahme
Gute Planung reduziert Überraschungen. Erfassen Sie Geräte, Software und Abhängigkeiten sowie die IPv6‑Fähigkeit der eingesetzten Komponenten.
Inventar und Kompatibilitätsprüfung
Erstellen Sie ein Inventar aller Router, Firewalls, Load‑Balancer, VPN‑Gateways, Server und relevanter Netzwerkdienste (DNS, DHCP, Monitoring). Prüfen Sie Firmware‑ und OS‑Versionen: Nicht alle älteren Geräte haben vollständige IPv6‑Unterstützung, oder sie haben Bugs in ND/RA‑Handling. Notieren Sie Anbieter, Modelle und die Versionen — diese sind die Basis für Upgrade‑ und Testentscheidungen.
Adressplan und PD‑Anforderungen
Klare Adresspläne sind wichtiger als bei IPv4: IPv6‑Präfixe sind hierarchisch gestaltet. Entscheiden Sie, ob Sie von Ihrem Provider ein /48, /56 oder /64 erwarten; die Vectoren heißen üblicherweise /48 für grössere B2B, /56 oder /60 für kleinere Sites. Prefix Delegation (PD) ist das Verfahren, mit dem der Provider ein Präfix an Ihre Router delegiert — dazu später mehr.
Sicherheits‑ und Compliance‑Abhängigkeiten
Inventarisieren Sie, welche Logs, IDS/IPS, SIEM‑Regeln oder Compliance‑Kontrollen IPv6 nicht unterstützen. Planen Sie Parallelbetrieb und definieren Sie, welche Security‑Policies angepasst werden müssen: Firewall‑Regeln, Netzsegmentierung, Access‑Lists und Monitoring‑Filter.
Prüfsequenz vor Produktivstart
Bevor Tests beginnen, definieren Sie Messgrößen: Erreichbarkeit (ICMPv6), DNS‑Auflösung über AAAA‑Records, Anwendungstests (HTTP/S über IPv6), MTU‑Verhalten und VPN‑Verbindungen. Legen Sie Testfenster, Verantwortlichkeiten und Metriken für Erfolg/Misserfolg fest.
Schritt 2 — Dual‑Stack einführen und testen
Dual‑Stack bedeutet, dass Hosts und Netzkomponenten sowohl IPv4 als auch IPv6 parallel sprechen. Das ist die empfohlene Übergangsmethode, weil Anwendungen und Pfade einzeln validiert werden können.
SLAAC vs. DHCPv6 — Auswahl treffen
SLAAC (StateLess Address AutoConfiguration) erzeugt Adressen automatisch aus Router‑Advertisements (RA). DHCPv6 bietet zentralisierte Zuteilung, vergleichbar mit DHCPv4. Wählen Sie SLAAC, wenn Sie einfache, autonom konfigurierte Subnetze wollen; wählen Sie DHCPv6 für zentrale Kontrolle, Reservierungen und detailliertere Optionen. Eine hybride Betriebsweise ist häufig sinnvoll: RA für Default‑Gateway + DHCPv6 für DNS und andere Optionen.
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 -TraceRouteDNS und AAAA‑Records
Stellen Sie sicher, dass DNS‑Zonen AAAA‑Records unterstützen und die TTL‑Strategie an die erwarteten Änderungen angepasst ist. Interne DNS‑Server sollten Dual‑Stack‑Anfragen korrekt beantworten; prüfen Sie Resolver‑Konfiguration (z. B. systemd‑resolve, Unbound oder BIND).
Schritt 3 — Prefix‑Delegation (PD) vom Provider
Prefix Delegation ist die Methode, mit der Ihr ISP Ihrem Kundenrouter ein Subnetz‑Präfix dynamisch zuweist, typischerweise via DHCPv6‑PD (DHCPv6 Prefix Delegation). Das ist wichtig für Standorte mit dynamischem WAN, wo das vom Provider zugeteilte Präfix wechseln kann.
Wie PD funktioniert und was schiefgeht
Bei DHCPv6‑PD fordert Ihr CPE‑Router ein Präfix vom ISP‑DHCPserver an. Der Router verwendet dieses Präfix lokal (z. B. als mehrere /64 für VLANs). Probleme entstehen, wenn der Provider Präfixe häufig ändert, Geräte PD nicht stabil halten oder RA/DHCPv6‑Konfigurationen in Konflikt geraten (z. B. wenn SLAAC lokale Adressen bildet, die außerhalb des delegierten Bereichs liegen).
Beispiel: ISC dhcpd6.conf für PD
Ein einfaches Beispiel für den DHCPv6‑Server (Provider‑Seite) oder zur Verdeutlichung der PD‑Zuteilung:
# /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 Rechenzentren oder bei eigenen DHCP‑Servern dient diese Konfiguration als Referenz. In der Praxis setzen Provider proprietäre Systeme ein; prüfen Sie die Provider‑Dokumentation und fordern Sie Stabilitätsgarantien (z. B. PD‑Leasedauer und Änderungsfrequenz).
Router‑Konfiguration: Delegiertes Präfix auf interne Interfaces anwenden
Der CPE‑Router muss das delegierte Präfix dynamisch auf internen VLANs/Subnetzen anwenden. Auf Linux‑Routern zum Beispiel kann ein Script das empfangene PD‑Präfix lesen und Interfaces konfigurieren. Prüfen Sie, wie Ihr Router mit PD‑Updates umgeht: Rebindings sollten nicht zu flapping interner Adressen führen.
IPv6‑Migration: Rollout‑Plan und Stakeholder‑Kommunikation
Eine technische Migration gelingt nur mit klaren Verantwortlichkeiten. Definieren Sie Rollen: Netzbetreiber, Security, Applikationsverantwortliche, Test‑ und Rollback‑Owner. Planen Sie Kommunikationspunkte: Ankündigung, Testende, Go/No‑Go‑Entscheidung, Post‑Rollout Review.
Typischer Zeitplan für einen Standort‑Rollout
Ein empfohlenes Mini‑Projektplan‑Gerüst pro Standort:
- Tag 0–7: Inventar, Firmware‑Check, Provider‑Klärung (PD / Lease‑Time)
- Tag 8–14: Lab Tests (Dual‑Stack, PD, VPN) und Firewall‑Vorlagen
- Tag 15–16: Pilot auf Non‑Critical VLAN, Monitoring aktiv
- Tag 17: Go/No‑Go‑Fenster, Produktivrollout
- Tag 18–30: Beobachtungsphase, Review und Stabilisierung
Akzeptanzkriterien
Definieren Sie messbare Kriterien: IPv6 Erreichbarkeit aller kritischen Dienste, keine Zunahme von Fehlerlogs, funktionierende VPN‑Tunnel über IPv6, keine signifikanten Performance‑Einbrüche (Latency/MTU).
Schritt 4 — Fallback und Rückrollstrategie
Ein klarer Fallback‑Plan ist unerlässlich. Dual‑Stack erleichtert dies: Bei Problemen können Sie IPv6 selektiv abschalten oder IPv6‑Routen zurückziehen, ohne IPv4 zu beeinflussen.
Schnelles Deaktivieren von IPv6
Linux (sysctl) zum temporären Abschalten aller IPv6 auf einem 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 --systemWindows (zum schnellen Test) per PowerShell: Deaktivieren einzelner IPv6‑Interfaces:
# Beispiel: IPv6 auf Interface 'Ethernet' deaktivieren
Set-NetAdapterBinding -Name 'Ethernet' -ComponentID ms_tcpip6 -Enabled $falseHinweis: Komplettes Abschalten von IPv6 auf Windows ist nicht empfohlen, weil einige Windows‑Features (z. B. Teredo, IPHTTPS) darauf angewiesen sind. Nutzt diese Maßnahme nur zur Fehlerisolation und nach Rücksprache mit Anwendungsteams.
Routing‑Fallback und Präferenzsteuerung
IPv6 hat keine direkte Äquivalenz zu „Policy‑Based Routing“ für Protokollpräferenzen; Betriebssysteme wählen oft IPv6 vor IPv4, wenn beide Adressen vorhanden sind. Sie können dies mit Source‑Address‑Policies oder RFC6724‑Policy (Adresspräferenz) steuern, etwa durch Policy Table Anpassungen auf Clients oder Load‑Balancer. Alternativ konfigurieren Sie DNS so, dass AAAA‑Records verzögert eingeführt werden, bis Pfade stabil sind.
Rollback‑Checkliste
- IPv6 abschalten (wenn notwendig) und Erreichbarkeit prüfen
- DNS AAAA‑Records zurückziehen oder TTL reduzieren
- Firewall‑und NAT‑Regeln auf IPv6 entfernen/neutralisieren
- Provider kontaktieren (PD/RA Änderungen) und Logs prüfen
- Rollback dokumentieren und Lessons Learned ins Review aufnehmen
Schritt 5 — Betrieb, Monitoring und VPN‑Spezifika
Nach erfolgreichem Rollout stabilisieren Sie Betrieb und erweitern Monitoring. Für VPNs (z. B. IPsec oder WireGuard) gelten besondere Regeln, weil Tunnelkonfigurationen oft IP‑basierte Policies verwenden.
Monitoring und Metriken
Ergänzen Sie Ihr Monitoring um IPv6‑Checks: ICMPv6‑Latenz, Neighbor Discovery Fehler, Tunnelstatus, Anzahl von IPv6‑Sessions (conntrack), AAAA‑Fehler in DNS, MTU‑Fehler (ICMPv6 Packet Too Big). Passen Sie SIEM‑Parsing an, damit Logs IPv6 Adressen korrekt indiziert und korreliert werden.
nftables Beispielregeln für IPv6
Ein minimalistisches Beispiel, das ICMPv6 für ND erlaubt und etablierte Verbindungen erlaubt:
# /etc/nftables.conf (Auszug für 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 ist kein „nur Ping“‑Protokoll, sondern Teil der Funktionalität (Neighbor Discovery). Blockieren Sie ICMPv6 nicht pauschal; erlauben Sie die notwendigen Typen.
VPN und IPv6 — konkrete Prüf- und Troubleshooting‑Schritte
IPsec: Prüfen Sie mit dem lokalen IPsec‑Toolset (z. B. strongSwan), ob Security Associations (SAs) für IPv6 aufgebaut sind. Achten Sie auf Traffic‑Selectors, denn diese legen fest, welche IPv6‑Präfixe über den Tunnel transportiert werden dürfen. WireGuard: Überprüfen Sie AllowedIPs und MTU; WireGuard routet alle spezifizierten Prefixe durch das Interface.
# strongSwan Status (Linux)
sudo ipsec statusall
# WireGuard Status
sudo wg show
# PMTU Test (IPv6) - sendet große Pakete, 'do' erzwingt kein Fragmentieren
sudo ping6 -c 3 -s 1400 -M do example.comFehlerbilder: Wenn Tunnel aufgebaut, aber keine End‑to‑End‑Konnektivität vorhanden ist, prüfen Sie zuerst MTU/ICMPv6 Packet Too Big; viele Tunnel (IPsec ESP) benötigen MTU‑Anpassung oder MSS‑Clamping. Sind nur einzelne Prefixe nicht erreichbar, kontrollieren Sie Traffic‑Selectors/AllowedIPs und Provider‑PD‑Routen.
Praktische Prüftools und Tests
Leistungs- und Pfadtests mit iperf3 über IPv6:
# Server starten (hört IPv6)
iperf3 -s -6
# Client auf entfernten Host testen
iperf3 -c 2001:db8::1 -6 -t 10Ein erfolgreiche iperf3 Messung bestätigt TCP/UDP‑Pfad und MTU‑Verhalten; fehlschlagende Tests deuten typischerweise auf Routing, Firewall oder MTU‑Probleme hin.
Automatisierung und Konfigurationsmanagement
Automatisierung reduziert menschliche Fehler bei Rollouts und Rollbacks. Nutzen Sie Configuration Management (Ansible, Salt, Puppet) für radvd, DHCPv6‑Client‑Hooks und nftables‑Templates. Achten Sie auf idempotente Tasks, um wiederholte Runs sicher zu machen.
# Beispiel: Ansible-Task zum Deployen eines radvd-Configs (Auszug)
- 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: yesVersionieren Sie Konfigurationen im Git und verwenden Sie Playbook‑Reviews als Change‑Control. Testen Sie Playbooks gegen eine laborähnliche Umgebung, bevor Sie produktiv ausrollen.
Praxisfälle, typische Stolperfallen und schnelle Prüfschritte
Hier eine komprimierte Liste wichtiger Fehlerquellen und wie Sie schnell testen:
- Kein IPv6 vom Provider: Prüfen Sie das WAN‑Interface mit
ip -6 addrund ob RA/PD tatsächlich ankommt. - DNS liefert AAAA, aber Verbindung bricht: Testen Sie mit iperf3 und prüfen Sie MTU/Firewall.
- Neighbor Discovery fehlschlägt: tcpdump auf ICMPv6‑ND prüfen.
- VPN bricht nach IPv6‑Aktivierung: Prüfen Sie AllowedIPs/TrafficSelectors und Firewall‑Policies.
- Hosts bevorzugen IPv6 und erreichen Dienste nicht: Prüfen Sie RFC6724‑Policy oder führen Sie AAAA schrittweise ein.
Checkliste für einen sicheren Rollout
- Inventar updaten und IPv6‑Support prüfen.
- Adressplan und PD‑Anforderungen mit Provider abklären.
- Lab‑Tests: Dual‑Stack in isoliertem VLAN validieren.
- Firewall‑ und IDS‑Regeln für IPv6 anlegen und testen (ICMPv6 berücksichtigen).
- VPN‑Testfälle definieren: IPsec, WireGuard, Client‑Zugänge.
- Monitoring anpassen: ICMPv6, ND, conntrack, DNS AAAA Checks.
- Rollback‑Prozedur dokumentieren und getestet bereitstellen.
Fazit
Eine erfolgreiche IPv6‑Migration ist planbar: Beginnen Sie mit einer belastbaren Bestandsaufnahme, führen Sie Dual‑Stack kontrolliert ein, nutzen Sie Provider‑Prefix‑Delegation (PD) korrekt und halten Sie eindeutige Fallback‑Mechanismen bereit. Im Betrieb gehören Monitoring und spezifische VPN‑Tests zum Alltag. Technische Tiefe, wie hier gezeigt, sorgt dafür, dass Änderungen berechenbar sind und der produktive Betrieb sicher bleibt. Legen Sie Wert auf kleine, messbare Schritte, Automatisierung und dokumentierte Rückfallwege — so minimieren Sie Risiko und schaffen die Voraussetzung für einen stabilen IPv6‑Betrieb.
Für dieses Thema sind auch Ra Slaac wichtig. Der Beitrag ordnet diese Aspekte verständlich ein und zeigt, worauf es im Alltag ankommt.