February 24, 2026

IPv6 Troubleshooting: SLAAC, DHCPv6 und Neighbor Discovery

IPv6 Troubleshooting wirkt auf viele Teams zunächst komplexer als IPv4, weil die Mechanismen zur Adressvergabe und Nachbarschaftsauflösung anders funktionieren: Statt ARP gibt es Neighbor Discovery (ND), statt „einfach DHCP“ gibt es SLAAC, DHCPv6 oder Mischformen, und statt Broadcast arbeitet IPv6 konsequent mit Multicast. Genau deshalb entstehen in Dual-Stack-Umgebungen typische Fehlerbilder: Clients haben zwar eine IPv6-Adresse, aber kein funktionierendes Default Gateway; DNS-Auflösung liefert AAAA-Records, doch Verbindungen timeouten; oder Geräte bekommen nur eine Link-Local-Adresse und wirken „halb online“. Besonders tückisch ist, dass viele Anwendungen IPv6 bevorzugen, sobald es verfügbar ist. Ein unvollständig konfiguriertes IPv6 führt dann zu sporadischen Timeouts und „langsamen“ Applikationen, obwohl IPv4 eigentlich funktionieren würde. Ziel dieses Leitfadens ist ein praxistauglicher, systematischer Ansatz: Sie lernen, wie SLAAC, DHCPv6 und Neighbor Discovery zusammenhängen, welche Rolle Router Advertisements (RA) spielen, wie Sie die häufigsten Ursachen schnell eingrenzen und welche Checks in der Praxis wirklich helfen – vom Client über Switch/WLAN bis zum Router und zur Firewall.

Table of Contents

Das mentale Modell: IPv6 hat andere „Grundpfeiler“ als IPv4

Viele IPv6-Fehler entstehen, weil man IPv4-Denkmuster 1:1 überträgt. Drei Grundpfeiler sollten Sie immer im Kopf behalten:

Keine Broadcasts: IPv6 nutzt Multicast (z. B. Neighbor Solicitation an solicited-node multicast). Das beeinflusst Filterregeln und Switch/WLAN-Verhalten.
Link-Local ist Pflicht: Jede IPv6-Schnittstelle hat (oder kann haben) eine Link-Local-Adresse (fe80::/10). Router und Nachbarn kommunizieren lokal darüber.
Default Gateway ist „ein Router“, nicht „eine IP-Konfig“: Ein Client lernt sein Gateway typischerweise über Router Advertisements (RA), nicht durch manuelle Gateway-Eingabe via DHCP wie bei IPv4.

IPv6 basiert auf zentralen Standards wie RFC 8200 (IPv6) und für Neighbor Discovery auf RFC 4861.

Adressierung im LAN: SLAAC, DHCPv6 und warum oft beides im Spiel ist

Für Clients im LAN gibt es drei gängige Modelle, um Adressen und Parameter zu erhalten:

SLAAC (Stateless Address Autoconfiguration): Der Client bildet seine Adresse selbst, basierend auf einem Prefix aus dem Router Advertisement. Optional holt er sich DNS-Infos separat.
DHCPv6 (Stateful): Der Client erhält eine Adresse vom DHCPv6-Server (ähnlich IPv4-DHCP), plus weitere Parameter.
Hybrid/Stateless DHCPv6: Adresse via SLAAC, aber „andere Infos“ (z. B. DNS-Server, Domain Search List) via DHCPv6.

Der Knackpunkt: Die Entscheidung, ob SLAAC und/oder DHCPv6 genutzt werden, wird über Router Advertisements gesteuert – insbesondere über die Flags M (Managed) und O (Other). Das macht RA zum zentralen Troubleshooting-Objekt in IPv6-LANs.

Router Advertisements: Die wichtigsten Inhalte und Fehlerquellen

Router Advertisements sind ICMPv6-Nachrichten, mit denen Router Clients mitteilen, welche Prefixe gelten, wie lange sie gültig sind, ob es einen Default Route gibt und welche Autokonfigurations-Optionen genutzt werden sollen. Wenn IPv6 „halb funktioniert“, ist RA sehr oft die Ursache.

Was ein RA typischerweise liefert

Prefix Information Option (PIO): Prefix, Prefix Length, Valid Lifetime, Preferred Lifetime, A-Flag (Autonomous) für SLAAC.
Router Lifetime: Wie lange der Router als Default Gateway gilt (Default Route).
M-Flag und O-Flag: Ob DHCPv6 für Adressen und/oder zusätzliche Optionen genutzt werden soll.
Optionen wie MTU: Kann die Layer-3-MTU beeinflussen (wichtig für PMTUD).
RDNSS/DNSSL (optional): DNS-Server und Search Domain per RA (wird nicht von allen Clients gleich unterstützt).

Typische RA-Fehlerbilder

Clients bekommen nur Link-Local: Kein RA im Segment, RA wird gefiltert, falsches VLAN, WLAN-Policy blockt Multicast/ICMPv6.
Adresse vorhanden, aber kein Gateway: Prefix kommt, aber Router Lifetime = 0 oder RA kommt von falschem Gerät (z. B. Rogue RA), oder Router ist nicht erreichbar.
DNS-Probleme: SLAAC-Adresse ok, aber DNS-Server fehlen oder werden via RA nicht akzeptiert; O-Flag falsch oder DHCPv6-Optionen fehlen.
Instabilität/Wechsel: Mehrere Router senden RAs, Clients wählen wechselnde Default Routes (Suboptimal Routing, asymmetrische Pfade).

Neighbor Discovery: IPv6-„ARP“ mit mehr Funktionen

Neighbor Discovery (ND) ersetzt ARP und beinhaltet mehrere Mechanismen: Neighbor Solicitation/Advertisement (NS/NA), Router Solicitation/Advertisement (RS/RA), Duplicate Address Detection (DAD) und Redirects. ND ist damit sowohl für L2-Nachbarschaft als auch für Routerwahl und Adressvalidierung zuständig. Die Spezifikation ist in RFC 4861 und für DAD ergänzend in RFC 4862 beschrieben.

Warum ND-Probleme so oft wie „Firewall blockt alles“ aussehen

Wenn ICMPv6 gefiltert wird, bricht nicht nur „Ping“, sondern grundlegende IPv6-Funktionalität (Adressauflösung, Router Discovery, PMTUD).
Symptome sind dann Timeouts bei TCP/UDP, „sporadisch langsam“, oder „nur IPv6-Dienste kaputt“.

Praxisregel: ICMPv6 ist in IPv6 kein „nice to have“, sondern Teil der Basisfunktion. Pauschales Blocken von ICMPv6 führt fast immer zu schwer diagnostizierbaren Störungen.

Das häufigste Dual-Stack-Problem: IPv6 ist „da“, aber nicht „gut“

In Dual-Stack-Umgebungen bevorzugen viele Clients IPv6, wenn AAAA-Records existieren. Wenn IPv6 aber falsch geroutet ist, DNS fehlt oder ND/PMTUD nicht sauber funktioniert, entstehen Timeouts – und der Nutzer empfindet das als „das Internet ist langsam“.

Symptom: Webseiten laden verzögert, Apps brauchen lange, bevor sie „umfallen“ oder auf IPv4 zurückfallen.
Ursache: IPv6-Connectivity teilweise kaputt (Default Route, ND, Firewall, DNS, MTU).
Fix-Ansatz: IPv6 vollständig korrekt machen (bevorzugt) oder IPv6 bewusst und kontrolliert deaktivieren, statt „halb“ zu betreiben.

IPv6 Troubleshooting Runbook: Schritt-für-Schritt zur Fehlerquelle

Dieses Runbook ist so aufgebaut, dass Sie in wenigen Minuten feststellen, ob das Problem bei Adressvergabe (SLAAC/DHCPv6), Default Route/RA, Neighbor Discovery, DNS oder Routing/Firewall liegt.

Schritt: Client-Grundzustand prüfen

Hat der Client eine Link-Local (fe80::/10)? Wenn nein: Interface/Stack/Policy-Problem.
Hat der Client eine Global Unicast (z. B. 2000::/3) oder ULA (fc00::/7)?
Gibt es eine Default Route (::/0) via Router? Ohne Default Route geht „nach draußen“ nichts.
Sind DNS-Server und ggf. Search Domains gesetzt (RA RDNSS oder DHCPv6)?

Schritt: RA-Verfügbarkeit und Qualität verifizieren

Kommt ein RA an? (Wenn nicht: VLAN/WLAN/Filter/IGMP/Multicast/ICMPv6 prüfen.)
Ist Router Lifetime > 0 (Default Route wird angeboten)?
Ist das Prefix korrekt und plausibel (richtiger /64 für SLAAC, korrekte Lifetimes)?
Welche Flags sind gesetzt: M/O passend zum Design (SLAAC-only, stateless DHCPv6, stateful DHCPv6)?

Schritt: Neighbor Discovery prüfen

Kann der Client den Router über dessen Link-Local erreichen (z. B. ICMPv6 zum fe80:: des Routers, falls bekannt)?
Stimmt die Neighbor Table (Router-MAC/Neighbor-Einträge stabil, kein ständiges Flapping)?
Gibt es DAD-Probleme (Adresse bleibt „tentative“ oder wird verworfen)?

Schritt: DNS gezielt testen

Löst der Client AAAA-Records korrekt auf?
Wenn Name nicht geht, aber IPv6-IP geht: DNS/Resolver-Policy ist das Problem.
Wenn AAAA aufgelöst wird, aber Verbindung hängt: IPv6-Pfad/Routing/Firewall/PMTUD prüfen.

Schritt: Routing und Firewall-Policies prüfen

Ist IPv6-Routing für das Prefix korrekt (SVI, Router, Upstream)?
Gibt es eine Rückroute für Client-Prefixe (besonders bei ULA/standortübergreifenden Netzen)?
Blockt eine Firewall ICMPv6 oder ND/RA? (Das ist ein häufiger „alles kaputt“-Grund.)

SLAAC Troubleshooting: Wenn Clients Adressen haben, aber irgendwas fehlt

SLAAC funktioniert nur, wenn der Router ein geeignetes Prefix mit A-Flag (Autonomous) anbietet. In der Praxis treten diese Probleme häufig auf:

Prefix-Länge falsch: SLAAC erwartet in der Praxis meist /64. Abweichungen können zu inkonsistentem Verhalten führen.
Lifetimes ungünstig: Sehr kurze Preferred Lifetimes führen zu häufigen Deprecations und Adresswechseln.
Privacy Extensions: Clients erzeugen temporäre Adressen; das ist normal, kann aber Logging und ACLs erschweren.
DNS fehlt: SLAAC vergibt Adresse, aber DNS-Server kommen nicht an (fehlendes RDNSS oder O-Flag/DHCPv6-Options).

Für SLAAC und DAD ist RFC 4862 eine gute Grundlage.

DHCPv6 Troubleshooting: Managed vs. Other und typische Stolpersteine

DHCPv6 wird oft missverstanden, weil es nicht automatisch das Default Gateway liefert. Das Default Gateway kommt weiterhin aus RA. DHCPv6 liefert je nach Modus Adressen (stateful) oder Zusatzinformationen (stateless).

Typische DHCPv6-Probleme

Client fragt DHCPv6 nicht an: M/O-Flags im RA passen nicht (z. B. M=0, O=0, aber Sie erwarten DHCPv6).
DHCPv6 antwortet nicht: Server/Relay fehlt, Firewall blockt UDP/546/547, oder Relay in falschem VLAN.
Adresse kommt, aber keine Verbindung: Default Route fehlt (RA/Rtr Lifetime), oder Routing/Rückweg stimmt nicht.
DNS-Optionen fehlen: Stateless DHCPv6 soll DNS liefern, aber Option ist nicht konfiguriert oder wird clientseitig nicht genutzt.

DHCPv6 Relay und Security-Filter

In vielen Netzen sitzt der DHCPv6-Server nicht im VLAN. Dann brauchen Sie DHCPv6 Relay. Security-Policies müssen UDP/546 (Client) und UDP/547 (Server/Relay) erlauben. Zusätzlich ist zu berücksichtigen, dass ND/RA parallel funktionieren muss, weil Default Gateway aus RA kommt.

Neighbor Discovery Probleme: DAD, Redirects und „tentative addresses“

ND-Probleme erzeugen oft sehr spezifische Symptome:

DAD schlägt fehl: Der Client erkennt eine doppelte Adresse (z. B. durch falsch geklonte VMs oder statische Adressduplikate) und verwirft sie. Ergebnis: Keine globale IPv6, nur Link-Local.
Neighbor Cache Issues: Instabile Neighbor-Einträge führen zu sporadischen Timeouts im LAN, besonders bei hoher Last oder bei L2-Problemen.
Rogue RA: Ein falsches Gerät sendet Router Advertisements; Clients lernen ein falsches Gateway oder ein falsches Prefix. Ergebnis: „IPv6 geht, aber ins Leere“.

Gegen Rogue RAs helfen in Campus-Netzen Funktionen wie RA Guard (auf Switchports), kombiniert mit sauberer Segmentierung und NAC.

ICMPv6 und PMTUD: Wenn große Pakete hängen

Ein besonders häufiger Fehler in Security- oder Tunnel-Setups ist das Blocken von ICMPv6. Dadurch bricht Path MTU Discovery (PMTUD) und große Pakete hängen, während kleine noch durchgehen. Das wirkt wie „TLS/HTTPS kaputt“ oder „nur manche Webseiten laden“.

Symptom: Kleine Requests funktionieren, große Downloads oder TLS-Handshakes hängen; viele Retransmissions.
Ursache: ICMPv6 Packet Too Big wird geblockt; MTU falsch; Tunnel-Overhead nicht berücksichtigt.
Fix: ICMPv6 gezielt erlauben (insbesondere Packet Too Big), MTU/MSS sauber planen.

Ein praxisnaher Einstieg in PMTUD für IPv6 findet sich in RFC 8201 (Path MTU Discovery for IPv6).

IPv6 in Unternehmensnetzen: Häufige „Design-Fallen“, die Troubleshooting teuer machen

Unklare Strategie (SLAAC vs. DHCPv6): Mischbetrieb ohne klare Flags/Policies führt zu inkonsistenten Clientzuständen.
DNS-Policy nicht IPv6-ready: AAAA-Records werden ausgeliefert, aber Routing/Firewall ist nicht vollständig.
Zu harte ICMPv6-Filter: ND/RA/PMTUD leiden. Das verursacht schwer zu findende Timeouts.
Kein Schutz gegen Rogue RA: Besonders in Gäste-/BYOD-/IoT-Segmenten riskant.
Fehlende Sichtbarkeit: Keine Logs/Telemetry für RA, ND, DHCPv6 Relay – dadurch bleibt nur „es geht nicht“.

Best Practices: IPv6 so betreiben, dass Troubleshooting leicht wird

Entscheidung festlegen: Pro Segment klar definieren: SLAAC-only, SLAAC + stateless DHCPv6, oder stateful DHCPv6.
RA-Standardisierung: Router Lifetime, Prefix-Lifetimes, M/O-Flags, RDNSS/DNSSL konsistent.
ICMPv6 bewusst erlauben: ND/RA/PMTUD gehören zur Grundfunktion; Filter nur gezielt und nachvollziehbar.
Rogue-RA-Schutz: RA Guard/Port-Policies, NAC für untrusted Ports, Segmentierung für Gäste/IoT.
Monitoring: Alarm auf Router Advertisement Changes, Neighbor Table Anomalien, DHCPv6 Failures, PMTUD-Errors.
Dokumentation: Prefix-Plan, Gateway-/Querier-Rollen, DHCPv6-Relays, DNS-Resolver-Design, Firewall-Ruleset.

Outbound-Links zur Vertiefung

Checkliste: IPv6 Troubleshooting für SLAAC, DHCPv6 und Neighbor Discovery

Clientstatus prüfen: Link-Local vorhanden? Global/ULA vorhanden? Default Route (::/0) vorhanden? DNS-Server gesetzt?
RA prüfen: Kommt RA an? Prefix korrekt (/64 für SLAAC)? Router Lifetime > 0? M/O-Flags passend? RDNSS/DNSSL vorhanden?
SLAAC prüfen: A-Flag gesetzt? Lifetimes plausibel? DAD ok (keine „tentative“ Dauerzustände)? Privacy Extensions berücksichtigt?
DHCPv6 prüfen: Wird DHCPv6 überhaupt getriggert (M/O)? Erreichbarkeit UDP/546/547? Relay korrekt? DNS-Optionen korrekt?
ND prüfen: Neighbor Table stabil? Router per Link-Local erreichbar? Keine Rogue RAs? Keine auffälligen NA/NS-Fluten?
DNS trennen: Hostname vs. IPv6-IP testen; AAAA-Auflösung korrekt? Resolver-Pfad (VPN/DoH) berücksichtigen.
Routing prüfen: Prefix-Routen und Rückwege vorhanden, besonders bei ULA oder standortübergreifenden Netzen.
Firewall/ICMPv6 prüfen: ND/RA/PMTUD nicht pauschal blocken; „Packet Too Big“ muss funktionieren.
WLAN/Switch prüfen: Multicast/ICMPv6 nicht durch Policies bremsen; RA Guard korrekt, ohne legitime RAs zu blocken.
Fix verifizieren: Gleicher Testfall nach Änderung (Adresse, Gateway, DNS, Connectivity, große Pakete), Ergebnisse dokumentieren und in Templates übernehmen.

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.