SLAAC vs. DHCPv6: Adressvergabe im Telco-Netz richtig wählen

Die Entscheidung SLAAC vs. DHCPv6 ist im Telco-Netz keine reine Geschmacksfrage, sondern eine Architektur- und Betriebsentscheidung, die direkt auf Skalierung, Stabilität, Sicherheit und Supportaufwand wirkt. IPv6 bringt mehrere Mechanismen zur Adressvergabe mit: SLAAC (Stateless Address Autoconfiguration) setzt auf Router Advertisements (RA) und lässt Endgeräte ihre Adresse selbst bilden; DHCPv6 kann entweder „stateful“ (Adressvergabe durch Server) oder „stateless“ (nur Optionen, keine Adresse) arbeiten. In Provider-Umgebungen kommen zusätzlich Prefix Delegation (PD) für CPEs (FTTH, Fixed Wireless, mobile Router) und spezifische Anforderungen an Logging, Policy und Security hinzu. Der größte Fehler ist, IPv6-Adressvergabe wie IPv4 zu denken: Ein „DHCP-only“-Ansatz kann bei bestimmten Endgeräten oder OS-Stacks unerwartete Nebenwirkungen haben; ein „SLAAC-only“-Ansatz ohne sauberes DNS- und Governance-Modell führt oft zu Supportproblemen und unvollständiger Nachvollziehbarkeit. Die praxistaugliche Lösung ist meist ein bewusstes Kombinationsmodell: SLAAC dort, wo Endgeräte es erwarten (z. B. viele Client-OS), DHCPv6 dort, wo Sie State, Optionen oder Delegationen kontrollieren müssen – und beides eingebettet in klare RA-Profile, IPAM, Security-Defaults und Monitoring. Dieser Artikel zeigt, wie Sie im Telco-Umfeld richtig wählen, welche Best Practices sich bewährt haben und wie Sie typische Kundenausfälle vermeiden.

Begriffe klarziehen: SLAAC, DHCPv6 stateful, DHCPv6 stateless und Prefix Delegation

Für eine saubere Entscheidung muss klar sein, welche Mechanismen welche Aufgabe erfüllen. In IPv6 sind Adresse, Default Route und Optionen nicht zwangsläufig an denselben Mechanismus gekoppelt.

• SLAAC: Endgerät bildet seine IPv6-Adresse selbst aus einem per RA angekündigten Prefix (typisch /64). Default Route kommt ebenfalls über RA.
• DHCPv6 stateful: DHCPv6-Server vergibt IPv6-Adressen aktiv (ähnlich DHCPv4), zusätzlich Optionen (z. B. DNS).
• DHCPv6 stateless: Endgerät nutzt SLAAC für die Adresse, holt sich aber zusätzliche Optionen (insbesondere DNS) per DHCPv6.
• Prefix Delegation (DHCPv6-PD): DHCPv6 delegiert ein Prefix (z. B. /56 oder /60) an eine CPE/Router, damit diese intern mehrere /64 bereitstellen kann.

Warum Router Advertisements in jedem Fall relevant sind

Auch wenn Sie DHCPv6 stateful nutzen, bleibt RA oft erforderlich, weil viele Endgeräte RA für die Default Route und bestimmte IPv6-Funktionen erwarten. Ein Telco-Design ohne saubere RA-Profile ist daher selten stabil.

Wie Endgeräte entscheiden: Die Rolle der RA-Flags (M-Flag und O-Flag)

In der Praxis steuern Router Advertisements das Verhalten der Clients. Zwei Flags sind besonders wichtig:

• M-Flag (Managed): signalisiert, dass Adresskonfiguration via DHCPv6 (stateful) erfolgen soll.
• O-Flag (Other): signalisiert, dass „andere Informationen“ via DHCPv6 bezogen werden sollen (stateless), während die Adresse z. B. via SLAAC kommt.

Diese Flags wirken nur dann zuverlässig, wenn sie konsistent im Netz gesetzt sind. In Telco-Accessnetzen mit vielen Knoten ist Drift bei RA-Profilen eine häufige Ursache für „nur bei manchen Kunden geht IPv6“.

SLAAC: Stärken im Telco-Betrieb

SLAAC ist extrem skalierbar, weil es wenig Server-State benötigt und die Adressbildung auf den Endgeräten erfolgt. In großen Accessnetzen ist das ein operativer Vorteil: weniger zentrale Abhängigkeiten, weniger Lease-Management, weniger Renew-Stürme. SLAAC passt besonders gut zu klassischen Client-Netzen (Wohnanschlüsse, WLAN/LAN), sofern DNS sauber gelöst ist.

• Skalierung: keine zentrale Adressvergabe pro Client nötig, weniger State-Last im Core.
• Robustheit: funktioniert zuverlässig, wenn RAs stabil sind und /64 korrekt angekündigt wird.
• Performance: schnelle Autokonfiguration nach Link-Up, besonders in großen Broadcast-Domänen.
• Einfachheit für Clients: viele Betriebssysteme sind für SLAAC „optimiert“ und verhalten sich erwartbar.

SLAAC: typische Schwächen und wie Provider sie abfedern

Die häufigste SLAAC-Schwäche im Telco-Umfeld ist nicht die Adresse, sondern die Optionsebene – insbesondere DNS. Ohne DNS-Optionen wirkt IPv6 „kaputt“, obwohl die Adressierung korrekt ist. Zusätzlich ist Nachvollziehbarkeit bei reiner SLAAC-Adressbildung schwieriger, wenn Sie keine ergänzenden Identitäts- und Sessiondaten korrelieren.

• DNS-Verteilung: wenn Clients keine DNS-Server per IPv6 erhalten, brechen viele Anwendungen.
• Logging/Korrelation: reine SLAAC-Adressen entstehen clientseitig; Provider braucht trotzdem Session-/Access-Identitäten.
• Rogue RA Risiko: unautorisierte RAs im Access können Clients falsch konfigurieren.
• Privacy Extensions: viele Clients nutzen wechselnde Interface-IDs; das ist gut für Privacy, erschwert aber Identifizierung ohne Sessiondaten.

Best Practice: SLAAC plus „Optionen sauber“

In vielen Telco-Designs ist SLAAC + DHCPv6 stateless der pragmatische Standard: SLAAC liefert Adresse und Default Route, DHCPv6 liefert DNS und weitere Optionen, die zentral kontrolliert werden sollen. Damit erhalten Sie Skalierung und betriebliche Steuerbarkeit.

DHCPv6 stateful: Stärken im Telco-Betrieb

DHCPv6 stateful ist attraktiv, wenn Sie die Adressvergabe zentral kontrollieren, Zuweisungen protokollieren und ggf. „stabile“ Adressen pro Endgerät erzwingen möchten. Außerdem passt DHCPv6 stateful in Designs, in denen DHCP ohnehin stark in Policy-/Subscriber-Management integriert ist. In der Praxis ist stateful DHCPv6 im Telco-Access aber oft selektiv sinnvoll – etwa in bestimmten Business-Segmenten oder in Plattformnetzen – weniger als globaler Default.

• Zentrale Kontrolle: klare Lease-Logs, definierte Zuteilungslogik, vereinheitlichte Optionen.
• Stabilität (wenn gewünscht): leichter, konsistente Adressen/Leases pro Client zu erreichen.
• Integration: kann gut mit AAA/Policy-Systemen zusammenspielen, wenn das Setup darauf ausgelegt ist.
• Adressmanagement: besseres Gefühl für „wer hat was“, sofern die Korrelation sauber ist.

DHCPv6 stateful: typische Risiken und Stolperfallen

Stateful DHCPv6 bringt zentrale Abhängigkeiten und potenziell mehr Control-Plane-Last, insbesondere bei großen Clientzahlen und kurzen Leases. Zudem ist das Clientverhalten nicht immer identisch zwischen Betriebssystemen, besonders wenn RA-Profile inkonsistent sind oder Default-Gateway-Logik missverstanden wird.

• Server-State und Renew-Last: Leases erzeugen Renew-Traffic; Peak-Events können DHCPv6-Lastspitzen auslösen.
• RA bleibt relevant: ohne korrekte RA-Defaults kann Default Routing brechen, selbst wenn Adressen per DHCPv6 vergeben werden.
• Interoperabilität: unterschiedliche Client-Stacks interpretieren Flags/Optionen teils unterschiedlich.
• Fehlersuche: mehr bewegliche Teile (Relay, Server-HA, Lease-State), mehr mögliche Fehlerquellen.

Prefix Delegation als Sonderfall: Warum PD fast immer DHCPv6 erfordert

In FTTH und bei mobilen Routern ist Prefix Delegation der Schlüssel, damit Kundenrouter mehrere /64 bereitstellen können. PD ist praktisch immer DHCPv6-basiert. Selbst wenn Sie in den Endgerätenetzn der Clients SLAAC nutzen, bleibt DHCPv6-PD für die CPE oft Pflicht, weil der Provider die delegierte Prefixgröße, Poolzuordnung und ggf. Sticky-Policy steuern muss.

• Residential FTTH: typischerweise DHCPv6-PD (z. B. /56 oder /60) für die CPE, intern SLAAC für Endgeräte.
• Mobile Router/FWA: PD je nach Produkt; wichtig bei Router-Use-Cases, weniger bei Smartphones.
• Stabilität: Sticky PD kann Kundenerlebnis verbessern, erfordert aber Governance (IPAM, Quarantäne, Failover-Plan).

Die Entscheidungsfrage im Telco-Netz: Wo endet „Client“, wo beginnt „Router“?

Viele Missverständnisse entstehen, weil man „Kunden“ als homogene Gruppe betrachtet. Für die Wahl SLAAC vs. DHCPv6 ist entscheidend, ob das Gerät ein Endgerät (Client) oder ein Router (CPE) ist.

• Endgeräte (Clients): profitieren häufig von SLAAC, weil es robust, skalierbar und clientfreundlich ist.
• Router/CPE: brauchen häufig DHCPv6-PD, damit sie interne Netze korrekt adressieren können.
• Business-Szenarien: können stärker DHCPv6 stateful verlangen, wenn zentrale Kontrolle und feste Adressierung relevant ist.

DNS-Design: Der entscheidende Faktor für „IPv6 funktioniert“

Ob SLAAC oder DHCPv6: Wenn DNS nicht sauber verteilt wird, wirken IPv6-Anschlüsse defekt. Im Providerbetrieb sollten Sie deshalb DNS explizit als Designobjekt behandeln – inklusive Fallbacks, Monitoring und klarer Option-Strategie.

• Resolver-Erreichbarkeit: DNS-Resolver müssen über IPv4 und IPv6 erreichbar sein.
• Optionen konsistent: DNS-Optionen entweder via DHCPv6 (stateless) oder via RA (RDNSS), abhängig von Ihrem Standard.
• Happy Eyeballs Realität: instabiles IPv6 führt zu gefühlter Langsamkeit, nicht nur zu harten Ausfällen.
• Monitoring: DNS-Latenz und Erfolgsraten getrennt für IPv4 und IPv6 messen.

Security und Stabilität: RA-Guard, DHCPv6-Guard und ICMPv6

IPv6 benötigt bestimmte Protokollelemente, die im IPv4-Denken oft „weggefiltert“ werden. Besonders ICMPv6 ist funktional wichtig. Gleichzeitig müssen Sie in Accessnetzen Rogue RAs/DHCPv6-Server verhindern. Das Design muss beides zusammenbringen: funktional korrekte Freigaben und klare Trust Boundaries.

• ICMPv6 funktional zulassen: Path MTU, Neighbor Discovery – pauschales Blocken erzeugt Geisterprobleme.
• RA-Guard: unautorisierte Router Advertisements auf untrusted Ports blocken (plattformabhängig).
• DHCPv6-Guard: DHCPv6-Serverantworten nur von trusted Ports akzeptieren.
• Segmentierung: Management/OAM strikt von Kundensegmenten trennen, um Angriffsflächen zu reduzieren.

Operationalisierung: Monitoring, IPAM und Runbooks als Entscheidungskriterium

„Richtig wählen“ bedeutet auch, das Betriebsmodell zu berücksichtigen. SLAAC reduziert Server-State, erhöht aber die Bedeutung von RA-Disziplin und Session-Korrelation. DHCPv6 stateful erhöht Server-State und verlangt HA-Design sowie Capacity Planning. In beiden Fällen ist IPAM/Source of Truth wichtig, damit Prefixe, PD-Pools und VRFs konsistent bleiben.

• SLAAC-Betrieb: Monitoring für RA-Drift, Rogue RA, IPv6-Erreichbarkeit, DNS-Optionen.
• DHCPv6-Betrieb: Monitoring für Lease-Raten, Renew-Spikes, Relay-Errors, Server-HA-Status.
• IPAM: Prefix-Container, PD-Pools, VRF-Zuordnungen, Lifecycle und Quarantäne zentral pflegen.
• Runbooks: standardisierte Checks: RA vorhanden? Flags korrekt? DHCPv6 erreichbar? DNS ok? MTU ok?

Empfohlene Standardmuster für Telcos

In der Praxis setzen viele Provider auf wenige, robuste Standardmuster statt auf eine einzige globale Lösung. Diese Muster sind besonders verbreitet, weil sie mit heterogenen Endgeräten und großen Netzen gut funktionieren.

• FTTH Residential: DHCPv6-PD für die CPE + SLAAC für Client-LANs + DHCPv6 stateless für DNS (oder sauberer RA-DNS-Standard).
• Mobile Endgeräte: häufig SLAAC-basierte Client-Adressierung; PD gezielt nur für Router-/FWA-Produkte.
• Business: je nach SLA und Kundenanforderung: SLAAC+stateless DHCPv6 oder DHCPv6 stateful, plus /48 oder größere Delegation für Standortrouter.
• Interne Plattformnetze: oft DHCPv6 stateful sinnvoll, wenn zentrale Kontrolle und feste Zuweisungen relevant sind.

Typische Fehlerbilder und schnelle Diagnose

• IPv6-Adresse vorhanden, aber kein Internet: RA-Default Route fehlt/inkonsistent, DNS fehlt, oder ICMPv6/PMTUD geblockt.
• Nur manche Clients betroffen: unterschiedliche OS-Interpretation, RA-Flags inkonsistent, Rogue RA im Segment.
• PD funktioniert nicht: DHCPv6-PD-Policy fehlt, Relay/VRF falsch, Guard blockt, Server unreachable.
• Prefix wechselt häufig: Sticky-PD fehlt, Identität instabil (DUID/Access-ID), Failover inkonsistent.
• Performance-Probleme: Happy Eyeballs maskiert instabile IPv6-Pfade; DNS/MTU/Policy prüfen.

Praxis-Checkliste: SLAAC vs. DHCPv6 im Telco-Netz richtig wählen

• Use Case trennen: Endgeräte (Clients) vs. Router/CPE; PD separat betrachten.
• RA-Profile standardisieren: M-Flag/O-Flag konsistent, keine Drift zwischen PoPs/BNGs.
• DNS-Strategie festlegen: DHCPv6 stateless oder RA-DNS (RDNSS) als Standard – und Monitoring dazu.
• PD-Policy definieren: Delegationsgröße (/56, /60, /48), Sticky vs. dynamisch, Pool-Scope nach Cluster.
• Security-Parität erzwingen: IPv6-Firewall/ACLs wie IPv4, ICMPv6 funktional zulassen, RA-/DHCPv6-Guards nutzen.
• Capacity Planning: bei DHCPv6 (stateful/PD) Renew-Last und Peak-Events berücksichtigen; bei SLAAC RA-Stabilität absichern.
• IPAM verpflichtend: Prefix-Container, PD-Pools, VRFs, Lifecycle und Quarantäne zentral führen.
• Runbooks bereitstellen: RA/DHCPv6/DNS/MTU Checks in fester Reihenfolge, damit Supportfälle schnell gelöst werden.

Konfiguriere Cisco Router & Switches und liefere ein Packet-Tracer-Lab/GNS3

Ich biete professionelle Unterstützung im Bereich Netzwerkkonfiguration und Network Automation für private Anforderungen, Studienprojekte, Lernlabore, kleine Unternehmen sowie technische Projekte. Ich unterstütze Sie bei der Konfiguration von Routern und Switches, der Erstellung praxisnaher Topologien in Cisco Packet Tracer, dem Aufbau und Troubleshooting von GNS3- und EVE-NG-Labs sowie bei der Automatisierung von Netzwerkaufgaben mit Netmiko, Paramiko, NAPALM und Ansible. Kontaktieren Sie mich jetzt – klicken Sie hier.

Meine Leistungen umfassen:

• Professionelle Konfiguration von Routern und Switches

• Einrichtung von VLANs, Trunks, Routing, DHCP, NAT, ACLs und weiteren Netzwerkfunktionen

• Erstellung von Topologien und Simulationen in Cisco Packet Tracer

• Aufbau, Analyse und Fehlerbehebung von Netzwerk-Labs in GNS3 und EVE-NG

• Automatisierung von Netzwerkkonfigurationen mit Python, Netmiko, Paramiko, NAPALM und Ansible

• Erstellung von Skripten für wiederkehrende Netzwerkaufgaben

• Dokumentation der Konfigurationen und Bereitstellung nachvollziehbarer Lösungswege

• Konfigurations-Backups, Optimierung bestehender Setups und technisches Troubleshooting

Benötigen Sie Unterstützung bei Ihrem Netzwerkprojekt, Ihrer Simulation oder Ihrer Network-Automation-Lösung? Kontaktieren Sie mich jetzt – klicken Sie hier.