IPv6-Incident-Playbook: ND, RA und Dual-Stack-Edge-Cases

Ein sauberes IPv6-Incident-Playbook ist heute Pflicht, weil IPv6-Ausfälle selten „hart“ wirken: Oft ist nur ein Teil der Clients betroffen, nur bestimmte Subnetze verlieren Konnektivität, oder Anwendungen „flappen“ zwischen IPv4 und IPv6. Besonders häufig liegen die Ursachen nicht im Routing, sondern in den Mechanismen am Rand des Netzes: Neighbor Discovery (ND), Router Advertisements (RA) und typische Dual-Stack-Edge-Cases. Wenn RA-Flags falsch gesetzt sind, wenn ND-Caches überlaufen oder wenn ein Rogue-RA die Default-Route überschreibt, kann ein Segment innerhalb von Minuten scheinbar „isoliert“ sein – obwohl Switchports up sind und das Underlay stabil ist. Dieses Playbook führt Sie praxisnah durch die häufigsten IPv6-Incident-Muster: Wie Sie ND- und RA-Probleme sicher erkennen, wie Sie sie von Routing- oder Firewall-Themen abgrenzen, welche Checks im NOC in wenigen Minuten funktionieren und welche Mitigation-Schritte schnell stabilisieren, ohne neue Risiken zu erzeugen. Ziel ist eine reproduzierbare Vorgehensweise, die sowohl Einsteigern als auch erfahrenen Engineers im On-Call hilft, IPv6-Probleme evidenzbasiert zu lösen.

Grundlagen für das Incident-Handling: ND und RA als „L2/L3-Klebstoff“

In IPv4 erledigen ARP und DHCP (plus statische Gateways) viele Aufgaben, die in IPv6 auf mehrere Bausteine verteilt sind. Neighbor Discovery basiert auf ICMPv6 und ersetzt ARP, erweitert es aber: ND ist zuständig für Neighbor Resolution, Reachability Detection, Duplicate Address Detection (DAD) und Redirects. Router Advertisements sind ebenfalls ICMPv6 und liefern Clients Informationen über Default Router, Präfixe, MTU und Flags für SLAAC/DHCPv6. In vielen Netzen ist das die häufigste Fehlerquelle, weil schon kleine Abweichungen (falsche Flags, falsche RA-Quelle, falsche Filter) große Wirkung haben.

• ND (Neighbor Discovery): Adressauflösung und Nachbarschaftszustand (wie ARP, aber mit Zustandsmaschine).
• RA (Router Advertisement): Default Router + Präfixe + Parameter (wie „Gateway und Netz-Konfiguration“).
• Dual-Stack: IPv4 und IPv6 parallel; Clients wählen oft IPv6 bevorzugt, bis es instabil ist.

Für die Protokollbasis sind RFC 4861 (Neighbor Discovery) und RFC 4862 (SLAAC) die wichtigsten Referenzen. Für Client-Adresswahl und Dual-Stack-Verhalten ist RFC 6724 (Default Address Selection) relevant.

Incident-Symptome richtig lesen: Was typisch für ND/RA ist

IPv6-Probleme zeigen sich häufig „selektiv“. Das liegt daran, dass ND/RA clientseitig gecacht und zeitabhängig ist: Ein Teil der Clients hat noch gültige Neighbor- oder Router-Cache-Einträge, andere nicht. Außerdem reagieren Betriebssysteme unterschiedlich auf RA-Flags und auf das Fehlen von RA. Typische Muster:

• Nur neue Clients haben Probleme: Bestandsgeräte funktionieren, neue Verbindungen scheitern (Cache-Effekt).
• Nur IPv6 ist kaputt, IPv4 geht: Anwendung wirkt langsam oder „teilweise down“ (Happy Eyeballs/Failover).
• Nur ein VLAN/Segment betroffen: besonders bei RA-Leaks, Rogue-RA oder fehlenden RA auf einer SVI.
• Intermittierende Timeouts: ND-Reachability flappt, Neighbor-Entries wechseln in „stale/failed“.
• Default-Route verschwindet: Clients verlieren das Gateway, obwohl lokale Nachbarn erreichbar sind.
• Unerklärliche MTU-Probleme: RA kann MTU announcen; falsche MTU erzeugt Blackholes.

Die 5-Minuten-Triage: Schnelle Einordnung, bevor Sie „Routing“ debuggen

Ein gutes Playbook startet mit der Frage: Liegt das Problem an (A) Adressierung/Default Router (RA/SLAAC/DHCPv6), (B) Neighbor Resolution/Reachability (ND), (C) L3-Routing/Policy, oder (D) Dual-Stack-Interaktionen (Happy Eyeballs, DNS, Load Balancer)? Mit diesen Schritten kommen Sie schnell zu einer belastbaren Hypothese:

• 1) Scope definieren: Welche Clients/Netze? Nur ein VLAN, nur ein Standort, nur ein WLAN?
• 2) IPv6 vs. IPv4 abgrenzen: Funktioniert IPv4 parallel stabil? Gibt es nur AAAA-bezogene Fehler?
• 3) Default Router prüfen: Haben betroffene Clients eine Default-Route via IPv6? Hat sich der Router geändert?
• 4) Neighbor Resolution prüfen: Kann der Client das Gateway neighbor-resolven? Gibt es ND-Fails?
• 5) DNS/AAAA prüfen: Werden AAAA Records geliefert? Zeigt DNS auf falsche Ziele?
• 6) Edge-Device prüfen: RA-Quelle, ND-Table, ICMPv6-Filter, Guard-Features (RA Guard, ND Inspection).

ND-Playbook: Häufige ND-Fehlerbilder und wie Sie sie bestätigen

ND-Probleme sind besonders wahrscheinlich, wenn das Gateway erreichbar „sein sollte“, aber der Traffic nicht sauber fließt. In der Praxis treten ND-Issues häufig durch Table-Überläufe, fehlerhafte L2-Topologien, Security-Filter oder durch exotische Client-Patterns auf (z. B. Virtualisierung mit vielen VMs pro Port).

Neighbor Cache / ND-Table Exhaustion

Wenn ND-Tabellen (auf Router, Firewall, Leaf) voll laufen, können keine neuen Neighbors gelernt werden. Das wirkt wie ein Ausfall „nur für manche“, oft für neue Hosts oder neue Flows.

• Symptome: Neue Hosts im Segment bekommen keine Konnektivität; bestehende Hosts teilweise ok.
• Bestätigung: ND-Table-Auslastung hoch, Drops/Logs „neighbor table full“ oder „failed to resolve“.
• Ursachen: Zu kleine ND-Table, zu viele Hosts pro L2-Domain, Scans, VM-Sprawl, fehlerhafte ND-Timeouts.

DAD-Probleme: Duplicate Address Detection blockiert Adressen

Bei SLAAC führt DAD dazu, dass eine Adresse erst aktiv wird, wenn keine Duplikate erkannt werden. Bei Konflikten (z. B. geklonte VMs mit gleichen Interface-IDs) bleiben Adressen „tentative“ oder werden verworfen.

• Symptome: Host hat keine gültige IPv6-Adresse oder nur link-local; sporadische Adressänderungen.
• Bestätigung: DAD-Events im Host-Log; DAD Failures; ND-Nachrichten im Segment weisen Duplikate nach.
• Mitigation: Klon-/Template-Prozess korrigieren, stabile Interface-IDs, Privacy Extensions bewusst steuern.

Reachability Flaps: Neighbor-States kippen (stale/delay/probe/failed)

ND hat eine Zustandsmaschine für Nachbarn. Wenn Link- oder L2-Stabilität schlecht ist (Microdrops, MAC-Flapping, LACP-Issues), kippen Neighbors in „failed“. Das kann wie „Packet Loss“ aussehen, ist aber ursächlich ein L2/ND-Thema.

• Symptome: Ping zum Gateway geht manchmal, TCP bricht ab, kurze Timeouts.
• Bestätigung: Nachbarstatus wechselt häufig; NUD (Neighbor Unreachability Detection) sendet Probes.
• Mitigation: L2 stabilisieren (Errors, LACP, Flaps), ND-Parameter nicht „blind“ drehen, sondern Ursache beheben.

RA-Playbook: Router Advertisements als häufigster „Tenant-Isolated“-Trigger

RA-Probleme sind oft binär: Entweder Clients haben eine Default-Route und ein korrektes Präfix, oder sie laufen ins Leere. Gleichzeitig können RA-Probleme sehr dynamisch sein: Ein Rogue-RA kann innerhalb von Sekunden die Default-Route eines ganzen Segments ändern. Deshalb sind RA-Checks im NOC besonders wertvoll.

Fehlende RA: Clients bekommen kein Gateway

• Symptome: Clients haben IPv6-Adresse, aber keine Default-Route; nur Link-Local funktioniert.
• Bestätigung: Kein RA im Segment; RA-Rate 0; RA vom erwarteten Router fehlt.
• Ursachen: RA auf Interface deaktiviert, ICMPv6 gefiltert, falsche VLAN-Zuordnung, SVI down, RA Guard falsch.

Rogue RA: Falscher Default Router überschreibt den richtigen

Ein Rogue-RA ist ein kritischer Incident, weil er ganze Segmente umleiten oder isolieren kann. Typische Quellen: falsch konfigurierte Router, Bridging-Fehler, virtuelle Router in Testumgebungen, oder unbeabsichtigte RA-Funktion auf Hosts.

• Symptome: Default-Route ändert sich plötzlich; nur manche Clients betroffen (je nach Timing); Traffic geht in falsche Richtung.
• Bestätigung: Mehr als eine RA-Quelle im Segment; unbekannte Router-Lifetime/Präfixe; neue Router-Adresse in Client-Route.
• Mitigation: Rogue-Port isolieren, RA Guard aktivieren/korrigieren, ICMPv6 gezielt erlauben und schützen.

Falsche RA-Flags: SLAAC vs. DHCPv6 bricht

RA trägt Flags, die Clients sagen, ob sie SLAAC nutzen sollen und ob zusätzlich DHCPv6 für Adressierung oder nur für „Other Config“ (z. B. DNS) genutzt wird. Wenn Flags nicht zum DHCPv6-Setup passen, entsteht ein schleichender Ausfall: Einige Clients konfigurieren sich „halb“, andere gar nicht.

• Symptome: IPv6-Adresse vorhanden, aber DNS fehlt; oder keine Adresse, obwohl erwartet.
• Bestätigung: RA zeigt M-Flag/O-Flag unpassend; DHCPv6-Logs zeigen keine Requests oder nur Info-Requests.
• Mitigation: Flags konsistent zu Design setzen; DHCPv6-Relay/Server prüfen; DNS-Distribution validieren.

Dual-Stack-Edge-Cases: Wenn IPv6 „halb kaputt“ ist und alles dadurch schlechter wird

Viele der nervigsten Incidents sind Dual-Stack-Probleme: IPv6 ist nicht komplett down, sondern instabil oder falsch geroutet. Clients versuchen IPv6 zuerst (je nach Policy), scheitern, fallen auf IPv4 zurück – und dadurch entstehen Latenzen, Retries und scheinbar „langsame“ Anwendungen. Die Fehlerwirkung ist dann größer als ein klarer IPv6-Ausfall, weil sie die User Experience massiv verschlechtert.

• Happy Eyeballs Maskierung: IPv6-Probleme werden kaschiert, aber verursachen Verzögerungen pro Verbindung.
• AAAA/IPv6 bevorzugt: Anwendungen treffen zuerst auf den kaputten Pfad, IPv4 rettet nur teilweise.
• Split-Horizon DNS: Intern/extern unterschiedliche AAAA Records; nur bestimmte Netze betroffen.
• Load Balancer Asymmetrie: IPv6-Frontend ok, IPv6-Backend-Path kaputt (oder umgekehrt).

Diagnose-Shortcut: AAAA vs. A und der „erste fehlerhafte Hop“

Wenn Sie vermuten, dass nur IPv6 betroffen ist, prüfen Sie getrennt: DNS-Auflösung (AAAA), Pfad (Traceroute/TCP-Connect), und Erreichbarkeit der ersten L3-Hop-Adresse (Default Router). Viele Dual-Stack-Probleme lassen sich auf eine falsche Default-Route (RA), eine falsche Firewall-Policy für ICMPv6, oder einen fehlerhaften IPv6-Uplink am Edge zurückführen.

ICMPv6-Filter: Der häufigste „selbst verursachte“ IPv6-Ausfall

IPv6 ist stärker auf ICMP angewiesen als IPv4. Wenn ICMPv6 zu aggressiv gefiltert wird, bricht ND (Neighbor Solicitation/Advertisement), RA, PMTUD und Error Signaling. Der Klassiker: „Wir blocken ICMP aus Sicherheitsgründen“ – und erzeugen dadurch schwer erklärbare Timeouts.

• ND benötigt ICMPv6: ohne NS/NA keine Neighbor Resolution.
• RA benötigt ICMPv6: ohne RA kein Default Router/Prefix für SLAAC.
• PMTUD benötigt ICMPv6: ohne Packet Too Big entstehen MTU-Blackholes.

Für PMTUD in IPv6 ist RFC 8201 eine sinnvolle Referenz. Für IPv6-Grundlagen und Header-Mechanik ist RFC 8200 relevant.

Mitigation-Strategien: Stabilisieren ohne langfristige Nebenwirkungen

Im Incident zählt Geschwindigkeit, aber jede Mitigation muss Sicherheits- und Stabilitätsrisiken berücksichtigen. ND/RA-Probleme verleiten dazu, „groß“ zu schalten (z. B. RA überall erlauben). Besser ist, gezielt zu stabilisieren.

• Rogue RA eindämmen: betroffenen Port isolieren, RA Guard korrekt aktivieren, nur autorisierte RA-Quellen zulassen.
• RA wiederherstellen: RA auf dem richtigen Interface aktivieren, VLAN-/SVI-Zuordnung prüfen, ICMPv6 gezielt freigeben.
• ND-Table entlasten: Segmentierung, ND-Limits/Thresholds prüfen, Top-Talker identifizieren, Scans begrenzen.
• Timeouts bewusst anpassen: nur wenn Evidence dafür spricht; Änderungen dokumentieren und später zurückführen.
• Dual-Stack temporär steuern: Wenn IPv6 instabil ist, AAAA kurzfristig entfernen oder IPv6-Routing gezielt drosseln (nur als Notmaßnahme, kontrolliert und dokumentiert).

Rate-Limit und RA-Guard: Warum „zu streng“ genauso gefährlich ist

Viele Switches/Edges bieten RA Guard und ND Inspection. Falsch konfiguriert kann das legitime RA/ND blocken und einen Incident auslösen, der wie „mystischer IPv6-Ausfall“ wirkt. Ein Playbook sollte deshalb immer prüfen: Wurden Guard-Policies kürzlich geändert? Gibt es Drops für ICMPv6-Typen 133–136 (RS/RA/NS/NA)?

Mess- und Alerting-KPIs für IPv6-Incidents: Was sich wirklich lohnt

Damit IPv6-Probleme früh auffallen, helfen KPIs, die direkt ND/RA abbilden. Klassische Link- oder BGP-Checks sind oft zu grob.

• RA-Rate pro VLAN: erwartete RA-Quelle(n), Anzahl RAs pro Zeit, Router-Lifetime-Änderungen.
• ND-Failures: „neighbor resolution failed“, „incomplete entries“, „NUD probes“ pro Interface.
• ND-Table-Auslastung: Prozent der Kapazität, Growth Rate, High-Watermarks.
• IPv6 PMTUD Errors: Packet Too Big Events, Drops aufgrund MTU.
• Dual-Stack Experience: Erfolgsrate IPv6 vs. IPv4, Connect-Latenz, Retry-Rate nach AAAA.

ND-Table-Wachstum als Frühwarnsignal (MathML)

$\mathrm{GrowthRate}=\frac{\mathrm{ND\_t2}–\mathrm{ND\_t1}}{\mathrm{t2}–\mathrm{t1}}$

Ein starker Anstieg der ND-Entries in kurzer Zeit ist ein typisches Signal für Scan-Events, VM-Sprawl oder ein Segment, das zu groß geworden ist. Kombiniert mit „incomplete“-Zuständen lässt sich ND-Exhaustion oft erkennen, bevor Nutzer Tickets schreiben.

Dokumentation und Übergabe: Was in ein IPv6-Incident-Ticket gehört

IPv6-Incidents eskalieren häufig an andere Teams (DC/Backbone/Security), weil die Ursache in Guard-Policies, Templates oder Routing-Design liegt. Damit die Übergabe ohne Schleifen gelingt, sollte Ihr Ticket standardisiert sein.

• Scope: betroffene VLANs/VRFs/Sites, betroffene Clientgruppen, Startzeitpunkt und Verlauf.
• Symptomprofil: nur IPv6 oder auch IPv4, nur neue Sessions oder auch bestehende, nur bestimmte Ziele/Ports.
• RA-Fakten: erwartete RA-Quelle, beobachtete RA-Quellen, Router-Lifetime, Präfix(e), Flags (M/O), MTU-Option.
• ND-Fakten: ND-Table-Auslastung, incomplete/failed counts, Neighbor-States, Top-Talker falls verfügbar.
• ICMPv6-Policy: relevante Firewall-/ACL-Änderungen, Drops für RA/ND/Packet Too Big.
• Mitigation: welche Schritte wurden gemacht, wann, und wie hat sich die Erfolgsrate geändert.
• Change-Korrelation: letzte Änderungen an RA Guard, DHCPv6, VLAN/VRF, Templates, Edge-Routing.

Outbound-Links für Standards und vertiefende Referenzen

• RFC 4861 (Neighbor Discovery for IPv6) für ND-Nachrichten, Zustände und Mechanik.
• RFC 4862 (IPv6 Stateless Address Autoconfiguration) für SLAAC, DAD und adressbezogene Edge-Cases.
• RFC 6724 (Default Address Selection) für Client-Verhalten in Dual-Stack-Umgebungen.
• RFC 8200 (IPv6 Specification) als Protokollbasis, Header und allgemeine Verhaltensregeln.
• RFC 8201 (Path MTU Discovery for IPv6) für MTU-Blackholes und die Rolle von ICMPv6 „Packet Too Big“.

Cisco Netzwerkdesign, CCNA Support & Packet Tracer Projekte

Cisco Networking • CCNA • Packet Tracer • Network Configuration

Ich biete professionelle Unterstützung im Bereich Cisco Computer Networking, einschließlich CCNA-relevanter Konfigurationen, Netzwerkdesign und komplexer Packet-Tracer-Projekte. Die Lösungen werden praxisnah, strukturiert und nach aktuellen Netzwerkstandards umgesetzt.

Diese Dienstleistung eignet sich für Unternehmen, IT-Teams, Studierende sowie angehende CCNA-Kandidaten, die fundierte Netzwerkstrukturen planen oder bestehende Infrastrukturen optimieren möchten. Finden Sie mich auf Fiverr.

Leistungsumfang:

• Netzwerkdesign & Topologie-Planung

• Router- & Switch-Konfiguration (Cisco IOS)

• VLAN, Inter-VLAN Routing

• OSPF, RIP, EIGRP (Grundlagen & Implementierung)

• NAT, ACL, DHCP, DNS-Konfiguration

• Troubleshooting & Netzwerkoptimierung

• Packet Tracer Projektentwicklung & Dokumentation

• CCNA Lern- & Praxisunterstützung

Lieferumfang:

• Konfigurationsdateien

• Packet-Tracer-Dateien (.pkt)

• Netzwerkdokumentation

• Schritt-für-Schritt-Erklärungen (auf Wunsch)

Arbeitsweise:Strukturiert • Praxisorientiert • Zuverlässig • Technisch fundiert

CTA:
Benötigen Sie professionelle Unterstützung im Cisco Networking oder für ein CCNA-Projekt?
Kontaktieren Sie mich gerne für eine Projektanfrage oder ein unverbindliches Gespräch. Finden Sie mich auf Fiverr.