Site icon bintorosoft.com

DHCPv6 & SLAAC absichern: Baseline für IPv6 im Provider-Netz

Red Snapper

Portrait of technical engineer of system administrator on the background of server room, IT technician.

Eine saubere Baseline, um DHCPv6 & SLAAC absichern zu können, ist im Provider- und Telco-Netz entscheidend, weil IPv6-Adressierung und Default-Gateway-Informationen direkt darüber bestimmen, wohin Endgeräte ihren Traffic senden – und welche DNS-Resolver, Präfixe und Policies sie überhaupt nutzen. Genau hier entstehen in der Praxis viele Sicherheits- und Betriebsprobleme: Rogue Router Advertisements (RA), „falsche“ DHCPv6-Server, manipulierte DNS-Optionen, ND-/RA-Stürme, unkontrollierte Prefix-Delegation oder schlicht Fehlkonfigurationen, die in großen Netzen sofort tausende Kunden betreffen. Eine Telco-Baseline muss deshalb zwei Dinge gleichzeitig erreichen: Sie muss die IPv6-Autokonfiguration (SLAAC) stabil und standardkonform ermöglichen, und sie muss DHCPv6 so betreiben, dass nur autorisierte Komponenten antworten und dass Missbrauch und Flooding die Infrastruktur nicht destabilisieren. Dazu gehören RA Guard, DHCPv6 Guard/Shielding, gezielte ACLs für ICMPv6 und DHCPv6, Control-Plane-Policing sowie ein klares Zonen- und Rollenmodell (Access/BNG, Aggregation, CPE, Telco Cloud). Dieser Artikel zeigt, wie Sie DHCPv6 und SLAAC im Provider-Netz als Baseline absichern – praxisnah, betriebssicher und ohne IPv6 „kaputt zu filtern“.

Warum IPv6-Adressierung im Provider-Netz eine Sicherheitsfunktion ist

Im IPv4-Umfeld war Adressvergabe oft „einfach“: DHCPv4 plus NAT, Default Gateway statisch oder via DHCP, und viele Netze haben auf NAT als Nebenprodukt eine gewisse Inbound-Reduktion bekommen. In IPv6 ist das anders: Endgeräte können sich per SLAAC selbst konfigurieren, Router Advertisements liefern Gateway und Präfix, DHCPv6 kann zusätzlich Adressen, DNS und weitere Optionen liefern, und Prefix Delegation (PD) verteilt ganze Präfixe an CPEs. Damit wird Adressierung zur Sicherheitsfunktion: Wer RA oder DHCPv6 kontrolliert, kann Traffic umleiten, DNS manipulieren oder Verfügbarkeit stören. Eine Baseline muss daher Adressierungsmechaniken wie kritische Control Plane behandeln.

SLAAC vs. DHCPv6: Rollen, Stärken und typische Telco-Modelle

Um „absichern“ zu können, müssen Sie zuerst entscheiden, welchen Adressierungsmodus Sie pro Segment wirklich wollen. SLAAC basiert auf Router Advertisements: Endgeräte bilden ihre Adresse aus dem Präfix, Router liefert Default Route und Flags. DHCPv6 kann stateless (nur Optionen wie DNS) oder stateful (Adressvergabe) betrieben werden. In Telco-Netzen sind mehrere Modelle üblich: SLAAC+stateless DHCPv6 (DNS via DHCPv6), stateful DHCPv6 für bestimmte Enterprise-/Access-Szenarien oder SLAAC im Access und DHCPv6/PD am CPE.

Baseline-Ziele: Was „absichern“ in diesem Kontext konkret heißt

Eine Provider-Baseline sollte nicht nur „Security Controls“ aufzählen, sondern klare Ziele definieren, die im Betrieb überprüfbar sind. Für DHCPv6/SLAAC sind die Kernziele: nur autorisierte RA/DHCPv6-Sender, stabile IPv6-Funktion (inklusive ICMPv6), Schutz vor Stürmen und Missbrauch, saubere Segmentierung und nachvollziehbare Änderungen.

RA Security Baseline: RA Guard, Routerrollen und sichere RA-Parameter

Die wichtigste SLAAC-Sicherheitsmaßnahme ist die Verhinderung von Rogue RAs. In L2-/Access-Segmenten ist RA Guard die Baseline: Nur Ports, die zu autorisierten Routern gehören, dürfen Router Advertisements senden. Zusätzlich sollte die Baseline definieren, welche RA-Parameter zulässig sind (z. B. Router Lifetime, Prefix Lifetime, Flags), damit Fehlkonfigurationen nicht zu langen, schwer rückbaubaren Effekten führen.

Baseline-Regel: RA Guard ist Zonenpflicht, nicht „optional“

Wo ein Segment potenziell Hosts/CPE enthält, ist RA Guard (oder ein gleichwertiger Mechanismus) Pflicht. In reinen Router-Router-P2P-Links ist RA Guard meist nicht erforderlich, weil dort keine Hostports existieren; dort greifen stattdessen Neighbor-Allowlisting und Control-Plane-Policies.

DHCPv6 Security Baseline: DHCPv6 Guard, Snooping und Relay-Disziplin

DHCPv6 lässt sich im Provider-Netz am besten absichern, wenn Sie die Rollen sauber trennen: Endgeräte/Clients, Relay (z. B. BNG/Access-Router) und DHCPv6-Server. Der häufigste Fehler ist „DHCPv6 von irgendwo“: Ein Rogue Server kann falsche DNS-Resolver oder Optionen ausliefern. Deshalb sollte die Baseline DHCPv6 Guard/Shielding vorschreiben: DHCPv6-Server-Antworten (Reply/Advertise) sind nur von trusted Ports/Interfaces erlaubt. Zusätzlich sind Rate Limits und Anomalieerkennung wichtig, weil DHCPv6-Floods Infrastruktur belasten können.

SLAAC und DHCPv6 kombinieren: Baseline für Flags und konsistente Client-Experience

In vielen Telco-Designs ist die Kombination aus SLAAC und stateless DHCPv6 der beste Kompromiss: SLAAC liefert Adressen und Default Route, DHCPv6 liefert DNS und Zusatzoptionen. Damit das stabil funktioniert, müssen RA-Flags korrekt gesetzt werden. Eine Baseline sollte pro Serviceprofil definieren, ob Clients DHCPv6 nutzen sollen (M-Flag für managed, O-Flag für other configuration) und welche Option-Pfade unterstützt werden. Das verhindert, dass Endgeräte „mal SLAAC, mal DHCPv6“ machen und dadurch Supportfälle entstehen.

Prefix Delegation absichern: Baseline für CPE und Downstream-Netze

Prefix Delegation ist in Provider-Netzen besonders relevant (z. B. FTTx, Fixed Wireless Access, Business Access), weil das CPE ein ganzes Präfix erhält und intern weiter verteilt. Ohne Baseline entstehen hier gleich mehrere Risiken: unkontrollierte Präfixgrößen, Prefix-Exhaustion, Missbrauch durch falsche Delegation, oder inkonsistente Policies, die im Upstream zu Routing- und Filterproblemen führen. Eine Baseline sollte daher PD als kontrollierten Service behandeln, nicht als „DHCPv6-Feature“.

ACLs und Filter: Welche IPv6-Regeln in die Baseline gehören

Eine Telco-Baseline für DHCPv6/SLAAC ist ohne ACLs unvollständig. Dabei geht es nicht darum, IPv6 „zu blocken“, sondern darum, autorisierte Kommunikationspfade zu erzwingen: ICMPv6-Typen, DHCPv6-Ports/Multicast, Infrastructure Protection und Bogon Filtering. Besonders wichtig: ICMPv6 muss typenspezifisch erlaubt sein, sonst brechen ND und PMTUD.

Control-Plane Protection: ND/RA/DHCPv6 als CoPP-Klassen behandeln

In großen Netzen ist nicht die Existenz von ND/RA/DHCPv6 das Problem, sondern unkontrolliertes Volumen. Deshalb muss eine Baseline CoPP/CPPr explizit für IPv6-Adressierungsmechaniken definieren: ND/RA als eigene Klasse, DHCPv6 als eigene Klasse, PMTUD/Errors getrennt von Echo/Diagnostics. So verhindern Sie, dass Echo-Floods oder ND-Stürme die Control Plane überfahren.

Detection und Betrieb: Rogue RA/DHCPv6 erkennen und sauber reagieren

Selbst mit Guard-Mechanismen brauchen Sie Observability: Rogue RA kann aus Fehlkonfigurationen entstehen (z. B. ein falsch gebrücktes Segment), DHCPv6-Server können versehentlich in falschen VLANs aktiv sein, und Floods können durch fehlerhafte Endgeräte ausgelöst werden. Eine Baseline sollte deshalb nicht nur „blocken“, sondern auch detektieren: Alarme auf RA-Quellen, ungewöhnliche DHCPv6 Replies, ND-Spikes und plötzlich wechselnde Präfixe.

Rollout und Governance: Baseline ohne Betriebsrisiko einführen

DHCPv6- und SLAAC-Härtung scheitert oft an zu schnellem, ungetestetem Rollout. Eine Telco-Baseline sollte daher ein stufenweises Vorgehen erzwingen: erst Inventarisierung (Routerports/Hostports), dann Canary, dann Ausrollen. Ausnahmen müssen TTL haben, damit temporäre „Interop“-Workarounds nicht dauerhaft werden. Zusätzlich sollte „Policy as Code“ bevorzugt werden, damit RA-/DHCPv6-Profile versioniert und reviewbar sind.

Typische Anti-Patterns: Was eine Provider-Baseline ausdrücklich vermeiden muss

Baseline-Checkliste: DHCPv6 & SLAAC absichern im Provider-Netz

Mit dieser Baseline werden DHCPv6 und SLAAC im Provider-Netz zu kontrollierten, stabilen Bausteinen: Endgeräte erhalten zuverlässig ihre IPv6-Konfiguration, Rogue Router und Rogue DHCPv6-Server werden blockiert, ND/RA/DHCPv6-Stürme werden durch Guard-Mechanismen und CoPP eingehegt, und Policies bleiben durch Zonierung, Observability und Governance langfristig sauber – genau die Kombination, die Telcos für skalierbare IPv6-Services benötigen.

Konfiguriere Cisco Router & Switches und liefere ein Packet-Tracer-Lab (CCNA)

Hallo! Ich bin ein CCNA-Network Engineer und unterstütze Sie bei Cisco Router- und Switch-Konfigurationen – inklusive eines vollständigen Cisco Packet-Tracer-Labs (.pkt). Ideal für Lern-/Übungsszenarien, Validierung oder eine saubere Demo-Topologie.

Was ich (je nach Paket) umsetze

Sie erhalten

Bitte schreiben Sie mir vor der Bestellung, damit wir Scope, Packet-Tracer-Version, Geräteanzahl und Deadline klären.

Konfiguriere Cisco Router & Switches | Cisco Packet-Tracer-Labs. Finden Sie mich auf Fiverr.

Exit mobile version