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

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.

• Rogue RA: Endgeräte nehmen falsche Gateways an und senden Traffic über Angreiferpfade oder ins Nirgendwo.
• Rogue DHCPv6: falsche DNS-Resolver oder Konfigurationsoptionen führen zu Hijacking, Phishing oder Ausfällen.
• Flooding/Stürme: ND/RA/DHCPv6-Noise kann Control Plane und Tables überlasten.
• Skalierung: Fehler wirken sofort auf viele Kunden (z. B. per Template-Rollout).
• Dual-Stack Drift: IPv4 ist gehärtet, IPv6-Adressierung bleibt „offen“ – ein klassischer Bypass.

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.

• SLAAC (rein): Gateway und Präfix via RA, DNS ggf. über RA (RDNSS) oder stateless DHCPv6.
• SLAAC + stateless DHCPv6: Adresse via SLAAC, DNS/Optionen via DHCPv6 (häufige Praxis).
• Stateful DHCPv6: Adresse und Optionen via DHCPv6, RA primär für Default Route/Flags.
• Prefix Delegation (PD): CPE erhält Präfix (z. B. /56 oder /60) und verteilt intern weiter.

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.

• Autorisierte Sender: RA und DHCPv6-Antworten dürfen nur von definierten Routern/Relay/Servern kommen.
• Stabilität: ND/RA/PMTUD (Packet Too Big) funktionieren zuverlässig, keine Blackhole-MTU-Probleme.
• Missbrauchsbegrenzung: Rate Limits, Guard-Mechanismen, Quarantäne bei Anomalien.
• Segmentierung: Access, Aggregation, CPE, Telco Cloud und Management getrennt, je Zone eigene Policies.
• Observability & Governance: Metriken, Logs, Change-ID, TTL für Ausnahmen, Rezertifizierung.

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.

• RA Guard auf Hostports: blockiert RA von CPE/Endgeräten; nur Routerports sind „trusted“.
• Trusted Router Ports: explizit inventarisiert und dokumentiert; keine impliziten Ausnahmen.
• RA-Parameter-Standards: konsistente Prefix Lifetimes, Router Lifetimes und Flags pro Serviceprofil.
• RDNSS-Strategie: wenn DNS über RA verteilt wird, dann nur von autorisierten Routern und mit klaren Resolver-Policies.

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.

• DHCPv6 Guard: blockiert Server-Antworten auf Hostports; nur definierte Server-/Relay-Pfade erlauben Replies.
• Relay statt „Server am Rand“: in großen Netzen ist Relay zentral steuerbar; reduziert Wildwuchs.
• Option-Hygiene: DNS-Optionen, Domain Search und andere Optionen werden zentral definiert und versioniert.
• Rate Limits: Solicit/Request-Floods begrenzen, um Control Plane und Server zu schützen.
• Logging: Rogue-Server-Versuche, ungewöhnliche Reply-Quellen, Spike-Detection.

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.

• SLAAC + O-Flag: häufige Baseline: Adresse via SLAAC, DNS via DHCPv6.
• M-Flag für stateful DHCPv6: nur dort, wo stateful wirklich gewollt ist (z. B. spezielle Enterprise-Umgebungen).
• RDNSS vs. DHCPv6 DNS: eine klare Strategie wählen; Mischbetrieb nur bewusst und getestet.
• Profilsegmentierung: Consumer vs. Enterprise vs. IoT mit unterschiedlichen Flags/Optionen.

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“.

• Standardisierte Präfixgrößen: pro Produktprofil festlegen (z. B. /56, /60), nicht ad hoc.
• Binding und Ownership: Delegation an Subscriber/Line-ID binden, nicht nur an MAC/IP.
• Anti-Spoofing: Upstream-Filter, dass aus dem Kundenport nur delegierte Präfixe als Source kommen.
• Lease/Lifetime Governance: Laufzeiten so wählen, dass Stabilität und Rückbau möglich sind.
• Observability: PD-Auslastung, neue Delegations, Anomalien (häufige Wechsel) überwachen.

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.

• ICMPv6 Allowlisting: Packet Too Big, ND (NS/NA), RS/RA, Time Exceeded, Unreachable – in passenden Segmenten.
• DHCPv6 Ports: UDP 546/547 nur in den erwarteten Richtungen (Client ↔ Relay/Server), nicht „any-any“.
• Multicast-Hygiene: nur notwendige Multicast-Gruppen im Segment; Missbrauch begrenzen.
• IPv6 Bogon Filtering am Edge: Link-Local, ULA, Loopback/unspecified, Dokumentationsprefixe nicht aus dem Internet akzeptieren.
• Infrastructure ACLs: Router-Loopbacks/Management-IPs vor Access-Traffic schützen.

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.

• Separate Policers: ND/RA, DHCPv6, ICMPv6 Errors, ICMPv6 Diagnostics getrennt.
• Budgets nach Rolle: Access/BNG andere Limits als Core oder Peering.
• Drop-Visibility: policer hits pro Klasse überwachen, sonst wird Tuning blind.

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.

• Rogue RA Alerts: RA von nicht autorisierten Ports als Security Event behandeln.
• DHCPv6 Reply Source Monitoring: Replies nur von erlaubten Servern/Relays; Abweichungen alarmieren.
• ND/RA Rate Anomalien: Spike-Detection, Top talkers, Quarantänepfade (z. B. Port drosseln).
• Prefix-Churn: ungewöhnlich häufige Präfixwechsel als Hinweis auf Missbrauch/Fehlkonfig.

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.

• Inventory Pflicht: welche Ports dürfen RA senden, welche Ports dürfen DHCPv6 Replies tragen?
• Canary Rollout: zuerst wenige PoPs/Access-Cluster, dann breiter.
• Testkatalog: SLAAC, DHCPv6 (stateless/stateful), PD, DNS, PMTUD, typische Kundengeräteprofile.
• TTL für Ausnahmen: jede Ausnahme läuft ab und wird rezertifiziert.
• Rollback-Runbooks: klare Rückbauwege, wenn Endgeräte unerwartet reagieren.

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

• ICMPv6 blocken: bricht ND/PMTUD und erzeugt schwer debuggbares Verhalten.
• Kein RA Guard: Rogue RA bleibt möglich und kann ganze Segmente umleiten.
• DHCPv6 überall erlauben: Rogue DHCPv6-Server können DNS/Optionen manipulieren.
• Keine Rate Limits: ND/RA/DHCPv6-Stürme überlasten Control Plane und Tabellen.
• Keine Profilsegmentierung: Consumer, Enterprise, IoT und CPE-PD brauchen unterschiedliche Policies.
• Ausnahmen ohne Ablauf: Interop-Workarounds werden dauerhaft und untergraben die Baseline.

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

• RA Guard Pflicht in Host-Segmenten: nur autorisierte Routerports dürfen RA senden; Hostports blocken RA.
• DHCPv6 Guard/Shielding: DHCPv6 Replies nur von trusted Ports/Relays/Servern; Rogue Replies alarmieren.
• Klare Adressierungsprofile: SLAAC-only, SLAAC+stateless DHCPv6 oder stateful DHCPv6 pro Serviceprofil definiert.
• Prefix Delegation Governance: standardisierte Präfixgrößen, Binding/Ownership, Anti-Spoofing für delegierte Präfixe.
• ICMPv6 typenspezifisch: ND/RA/RS/NS/NA und Packet Too Big zulassen; Diagnostics kontrolliert, alles rate-limited.
• ACLs/Filter nach Zonen: Access, Aggregation, Core, Management getrennt; Infrastructure ACLs verpflichtend.
• CoPP/CPPr Pflicht: ND/RA/DHCPv6 als eigene Klassen mit Budgets, Monitoring der Drops.
• Observability: Rogue RA/DHCPv6 Detection, ND/RA Rates, PD Churn, Alarme bei Spikes.
• Operationalisierung: Inventory, Canary Rollout, Testkatalog, Runbooks, TTL für Ausnahmen und Rezertifizierung.

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

• Switching: VLANs, Trunking (802.1Q), Port-Zuweisung, STP-Basics (PortFast/BPDU Guard wo sinnvoll)

• Routing: Default/Static Routing oder OSPF, Inter-VLAN Routing (Router-on-a-Stick)

• Services: DHCP (Pools/Scopes), NAT/PAT für Internet-Simulation

• Optional Security: Basic ACLs und SSH-Hardening

• Test & Verifikation: Ping/Traceroute + wichtige Show-Commands (mit erwarteten Ergebnissen)

Sie erhalten

• ✅ Packet Tracer .pkt Datei

• ✅ Saubere Konfigurations-Notizen pro Gerät

• ✅ Verifikations-Checkliste + erwartete Outputs

• ✅ Kurze Dokumentation (wie die Topologie funktioniert)

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.