Eine IPv6 Security Baseline für Telcos ist heute kein „Nice-to-have“ mehr, sondern eine betriebliche Notwendigkeit. In modernen Mobilfunk- und Provider-Netzen ist IPv6 längst produktiv: im Core, an Access-Kanten, in Telco Clouds, bei Anycast-Diensten und zunehmend bis zum Endgerät. Gleichzeitig unterscheidet sich IPv6 in einigen sicherheitsrelevanten Punkten deutlich von IPv4: zentrale Funktionen wie Neighbor Discovery (ND) und Router Advertisements (RA) basieren auf ICMPv6, Adressierung ist dynamischer, und klassische IPv4-Denkmuster wie „ICMP blocken“ oder „NAT schützt“ greifen nicht. Genau deshalb sind RA Guard, saubere ACLs und zielgerichtete Filter als Baseline so wichtig: Sie verhindern Rogue-Router-Szenarien, begrenzen Spoofing und Missbrauch, schützen die Control Plane vor ND/RA-Stürmen und stellen sicher, dass IPv6 nicht zur „Shadow-Network“-Flanke wird, während IPv4 sauber gehärtet ist. Dieser Artikel zeigt eine praxistaugliche Baseline für Telco-Umgebungen: wo RA Guard sinnvoll ist, welche ICMPv6-Typen erlaubt sein müssen, welche IPv6-ACLs an Edge und Core gehören, wie man Bogon- und uRPF-Konzepte auf IPv6 überträgt und welche Anti-Patterns Sie unbedingt vermeiden sollten.
Warum IPv6-Security in Telco-Netzen anders ist als IPv4-Security
Viele Sicherheitskonzepte aus IPv4 lassen sich nicht 1:1 übertragen. IPv6 ist nicht einfach „IPv4 mit größeren Adressen“, sondern bringt andere Betriebsmechaniken: Stateless Address Autoconfiguration (SLAAC), Neighbor Discovery statt ARP und oft eine geringere Abhängigkeit von NAT. Daraus folgt eine zentrale Baseline-Regel: IPv6 muss als eigenständige Domäne mit eigenen Controls betrieben werden, nicht als Nebenprodukt. Besonders gefährlich ist ein „Dual-Stack-Drift“: IPv4 ist streng gefiltert, IPv6 bleibt offen – und Angreifer nutzen den schwächeren Pfad.
- ICMPv6 ist kritisch: ND/RA/RS/NS/NA und PMTUD (Packet Too Big) sind für Stabilität notwendig.
- Rogue RA ist ein echter Angriffsvektor: falsche Router Advertisements können Traffic umleiten oder DoS verursachen.
- NAT als „Pseudo-Schutz“ fehlt oft: IPv6 erfordert echte Policy-Controls, nicht zufällige Inbound-Blockaden durch NAT.
- Adressraum ist groß: Scanning wird anders, aber nicht „unmöglich“; Logik und Telemetrie sind wichtiger als Hoffnung.
- Multi-Domain-Realität: Telco Clouds, Edge-PoPs, Roaming, Interconnects – IPv6 zieht sich durch viele Zonen.
Baseline-Ziele: Was IPv6-Security in Telco-Umgebungen leisten muss
Eine Baseline muss sowohl Sicherheitsziele als auch Betriebsziele abdecken. Denn IPv6-Security, die ND/RA kaputtfiltert, ist keine Security, sondern ein Ausfallrisiko. Umgekehrt ist ein „IPv6 läuft irgendwie“-Ansatz ein Compliance- und Incident-Risiko. Eine robuste Baseline definiert daher Mindeststandards für: (1) L2-nahe Schutzmechanismen (RA Guard, ND-Hygiene), (2) L3/L4-Filter und Anti-Spoofing (ACLs, uRPF), (3) Control-Plane Protection (CoPP), (4) Observability und Governance.
- Rogue RA verhindern: nur autorisierte Router dürfen Router Advertisements senden.
- ND/ICMPv6 stabil halten: notwendige ICMPv6-Typen zulassen, aber rate-limited.
- Spoofing reduzieren: Source Validation, uRPF/Ingress-Filter, Bogon Filtering für IPv6.
- Edge-Härtung: Infrastruktur-IPs, Managementpfade und Services vor IPv6-Exposure schützen.
- Nachweisbarkeit: Logs/Metriken, Alarme, Rezertifizierung und Drift-Detection.
RA Guard als Baseline: Wann es Pflicht ist und wann nicht
RA Guard ist ein L2-/Switch-Feature (oder in manchen Plattformen ein L2-Edge-Feature), das Router Advertisements auf nicht autorisierten Ports blockiert. In Telco-Netzen ist das besonders relevant in Bereichen, in denen Endgeräte oder CPEs an L2-Segmente angeschlossen sind oder in denen Multi-Tenant-L2-Umgebungen existieren (z. B. Access-Aggregation, bestimmte Edge/Metro-Designs, Campus-/Office-Anteile, Telco-Cloud-L2-Segmente). Wo hingegen reine L3-P2P-Links oder streng kontrollierte Router-Router-Interconnects existieren, ist RA Guard oft weniger relevant, weil dort keine unkontrollierten Hosts RA senden sollten.
- RA Guard Pflicht: Access- und Aggregationssegmente mit potenziellen Hostports (CPE/UE-nahe Bereiche, WiFi/VoWiFi-Edges, Enterprise-L2-Services).
- RA Guard sinnvoll: Telco-Cloud-L2-Netze mit vielen Workloads, wenn Rogue RA durch Fehlkonfiguration möglich ist.
- RA Guard meist nicht nötig: reine Router-Router-P2P-L3-Links, wenn L2 nicht „shared“ ist.
- Baseline-Hinweis: RA Guard ersetzt keine L3-ACLs; es schützt vor einem spezifischen, aber kritischen Vektor.
Baseline-Regel: Nur explizit autorisierte Ports dürfen RA senden
Eine praxistaugliche Baseline definiert eine einfache Logik: In einem Segment gibt es „Router Ports“ (autorisierte RA-Sender) und „Host Ports“ (keine RA-Sender). RA Guard wird auf Hostports aktiviert und auf Routerports bewusst deaktiviert oder in eine „Permit“-Rolle gesetzt. Das klingt trivial, verhindert aber einen Großteil der realen Rogue-RA-Fehlerbilder.
ICMPv6-Filtering: Was unbedingt erlaubt sein muss
IPv6 funktioniert nicht stabil, wenn ICMPv6 pauschal blockiert wird. Eine Telco-Baseline muss daher ICMPv6 nicht als „Risk-Protokoll“, sondern als notwendige Betriebsfunktion behandeln – jedoch mit klaren Typ-Policies und Rate Limits. Besonders wichtig sind ND (Neighbor Solicitation/Advertisement), Router Solicitation/Advertisement und „Packet Too Big“ für PMTUD. Gleichzeitig sollten Sie ICMPv6 auf Infrastruktur-IPs nicht „unlimited“ erlauben, sondern über CoPP/Policer begrenzen.
- Packet Too Big: Pflicht für IPv6-PMTUD, sonst drohen Blackhole-MTU-Probleme.
- Neighbor Solicitation/Advertisement: Basis für Neighbor Discovery, essenziell in L2/L3-Grenzen.
- Router Solicitation/Advertisement: erforderlich für SLAAC und korrekte Router-Discovery in passenden Segmenten.
- Time Exceeded: wichtig für Diagnose (Traceroute), kontrolliert zulassen.
- Destination Unreachable: unterstützt korrektes Fehlerverhalten, kontrolliert zulassen.
IPv6 ACLs als Baseline: Infrastruktur schützen, ohne IPv6 zu „brechen“
IPv6-ACLs sollten in Telco-Netzen nicht nach dem Muster „alles dicht“ gestaltet werden, sondern nach dem Muster „Infrastruktur- und Managementschutz plus policybasierte Erlaubnisse“. Wichtig ist dabei die Zonierung: Peering/IXP-Edges benötigen andere Regeln als Access oder interne Service-Zonen. Eine Baseline sollte daher mindestens drei ACL-Profile definieren: (1) Internet/Peering Edge, (2) Customer/Access Edge, (3) Core/Interconnect intern.
Baseline für Internet/Peering Edge (IPv6)
- Block von IPv6 Bogons als Source: z. B. fe80::/10, fc00::/7, ::/128, ::1/128, 2001:db8::/32, ff00::/8.
- Infrastruktur-ACL: Router-Loopbacks und Management-IPs gegen unnötigen Inbound-Traffic schützen.
- BGP nur zu definierten Peers: falls BGP auf dem Interface terminiert, nur die Peer-IPs zulassen.
- ICMPv6 selektiv: notwendige Typen zulassen, Echo/Diagnostics strikt rate-limited.
Baseline für Customer/Access Edge (IPv6)
- Anti-Spoofing: Quellenvalidierung (uRPF/Ingress-Filter) passend zum Topologiemodell.
- Infrastructure Protection: Provider-IPs in der Access-/BNG-Umgebung nicht frei erreichbar.
- ND/RA kontrolliert: dort zulassen, wo SLAAC/ND nötig ist, aber Storms begrenzen.
- Service-Policies: wenn bestimmte Dienste (DNS/DoT/DoH) vorgeschrieben sind, entsprechende Regeln klar definieren.
Baseline für Core/Interne Zonen (IPv6)
- Neighbor-Allowlisting: Routing-Protokolle und Management nur zwischen definierten Nachbarn.
- Minimaler ICMPv6-Satz: PMTUD und notwendige Fehlertypen, aber sehr konservativ.
- Keine Laterale Management-Exposure: Admin-Ports nur über Management-VRF/OOB.
uRPF und Source Validation in IPv6: Baseline gegen Spoofing
IPv6-Spoofing ist genauso relevant wie IPv4-Spoofing. Eine Baseline sollte uRPF/Source Validation für IPv6 ausdrücklich enthalten – allerdings topologieabhängig. Strict uRPF ist ideal an klaren, single-homed Access-Kanten; feasible oder loose können in asymmetrischen Bereichen sinnvoll sein. Entscheidend ist, dass uRPF im richtigen Kontext (VRF/Interface) prüft und dass Ausnahmen nicht dauerhaft zu „offenem Spoofing“ führen.
- Strict uRPF: an klaren Access-Kanten, wenn Rückwege symmetrisch sind.
- Feasible/Loose: bei Multi-Homing, ECMP oder asymmetrischem Routing, aber bewusst und getestet.
- IPv6 Bogon Filtering ergänzen: stoppt offensichtlich falsche Quellen zusätzlich.
- Observability: uRPF-Drops und Top Offenders überwachen, um False Positives schnell zu erkennen.
Control Plane Protection: CoPP/CPPr als Pflicht für IPv6-Noise
IPv6 bringt zusätzliche Control-Plane-Last durch ND/RA/MLD. Ohne Rate Limits können ND-Stürme oder ICMPv6-Floods CPU und Neighbor-Tabellen belasten. Eine Telco-Baseline sollte deshalb CoPP/CPPr als Pflicht definieren und IPv6-relevante Klassen explizit berücksichtigen: ND/RA als eigene Klasse, PMTUD/Errors als eigene Klasse, Diagnostics separat.
- Separate CoPP-Klassen: ND/RA/ICMPv6-Errors/Diagnostics getrennt, damit Echo-Floods PMTUD nicht verdrängen.
- Budgets nach Routerrolle: Access/Edge andere Limits als Core.
- Monitoring: policer hits, drops, CPU und Neighbor-Table-Health.
Filter und „Hygiene“: IPv6 Bogons, Martians und Special-Use Prefixes
Wie bei IPv4 sollte es auch für IPv6 eine klare Baseline geben, welche Special-Use-Bereiche am Internet-Edge niemals als Source auftauchen dürfen. Das reduziert Spoofing und erhöht die Signalqualität in Telemetrie. Wichtig ist die Zonierung: In Management- oder Service-VRFs können ULA oder Link-Local innerhalb eines Segments legitim sein; am Internet-Edge sind sie es nicht.
- Internet-Edge Drop: fe80::/10, fc00::/7, ::/128, ::1/128, ff00::/8, 2001:db8::/32 als Source.
- Zusätzlich in vielen Baselines: weitere Special-Use-Bereiche je nach Policy, aber nur mit gepflegtem Feed und klarer Dokumentation.
- Keine „globalen Filter“ in VRFs: sonst brechen interne Designs, die ULA verwenden.
Operationalisierung: Wie Sie RA Guard und IPv6-Filter sicher ausrollen
IPv6-Security scheitert oft nicht an der Idee, sondern am Rollout: falsche Switchport-Klassifikation, fehlende Tests für SLAAC, unzureichende Telemetrie oder ein zu schneller „Hardening“-Schritt ohne Canary. Eine Telco-Baseline sollte deshalb einen Rollout-Standard definieren: segmentweise, messbar, mit klaren Runbooks.
- Inventory zuerst: welche Ports sind Routerports, welche Hostports, wo ist SLAAC erlaubt?
- Canary Rollout: RA Guard/ACLs zuerst in ausgewählten PoPs/Access-Cluster, dann ausrollen.
- Testkatalog: IPv6 Addressing (SLAAC/DHCPv6), ND/RA, PMTUD, typische Kundenpfade, VoLTE/VoWiFi-Pfade (falls relevant).
- Runbooks: „Rogue RA erkannt“, „IPv6 Clients bekommen keine Adresse“, „PMTUD Blackhole“.
- TTL für Ausnahmen: temporäre Freigaben laufen ab und werden rezertifiziert.
Typische Anti-Patterns: Was eine IPv6 Telco-Baseline verhindern sollte
- ICMPv6 blocken: führt zu instabilem IPv6, PMTUD-Problemen und schwerer Diagnose.
- IPv6 unfiltered lassen: IPv4 ist gehärtet, IPv6 wird zum „Bypass“ für Angreifer.
- RA Guard falsch platziert: RA auf Routerports blockiert führt zu massiven Ausfällen; fehlender Schutz auf Hostports ermöglicht Rogue RA.
- Keine CoPP für IPv6: ND/RA-Noise kann die Control Plane destabilisieren.
- Keine Zonierung: gleiche ACLs für Edge, Core und Management brechen entweder Betrieb oder Security.
Baseline-Checkliste: IPv6 Security für Telcos mit RA Guard, ACLs und Filtern
- RA Guard Pflicht in Host-Segmenten: nur autorisierte Routerports dürfen RA senden; Hostports blocken RA.
- ICMPv6 typenspezifisch: Packet Too Big, ND/RA/RS/NS/NA, Time Exceeded und Unreachables zulassen – aber rate-limited.
- IPv6 ACL-Profile nach Zonen: Peering/Edge, Access, Core, Management getrennt, Infrastruktur-IPs geschützt.
- IPv6 Bogon Filtering am Internet-Edge: fe80::/10, fc00::/7, ::/128, ::1/128, ff00::/8, 2001:db8::/32 als Source droppen.
- uRPF/Source Validation: strict an klaren Access-Kanten, feasible/loose in asymmetrischen Bereichen – dokumentiert und getestet.
- CoPP/CPPr Pflicht: ND/RA und ICMPv6 in eigenen Klassen mit Budgets; Monitoring der Drops.
- Operationalisierung: Canary Rollout, Testkatalog (SLAAC/ND/PMTUD), Runbooks, TTL für Ausnahmen.
- Observability: RA-Events, ND-Rate, ACL/CoPP-Hits, uRPF-Drops und Alarme bei Spikes.
Mit dieser Baseline wird IPv6 in Telco-Netzen nicht zur „zweiten, unsicheren Realität“, sondern zu einem kontrollierten, auditierbaren Betriebsstandard: RA Guard verhindert Rogue Router, ICMPv6 bleibt funktional und gleichzeitig begrenzt, ACLs schützen Infrastruktur und Zonenübergänge, und Filter sowie CoPP sorgen dafür, dass Spoofing, ND-Stürme und Missbrauch nicht die Stabilität des Netzes gefährden.
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.
