IPv6 ACL konfigurieren: Sicherheit im IPv6-Netz

IPv6 ist in vielen Netzwerken längst Realität – oft schneller, als es dem Betrieb lieb ist. Denn selbst wenn ein Unternehmen „nur IPv4 nutzt“, sind auf Clients und Betriebssystemen IPv6-Funktionen häufig standardmäßig aktiv. Das kann zu einer unangenehmen Sicherheitslücke führen: IPv4 ist sauber segmentiert und mit ACLs geschützt, aber über IPv6 sind Geräte plötzlich erreichbar, weil keine passenden Filter existieren. Genau deshalb ist das Thema IPv6 ACL konfigurieren so wichtig, wenn Sie Sicherheit im IPv6-Netz ernst nehmen. IPv6 bringt nicht nur größere Adressräume, sondern auch neue Protokollmechanismen wie Neighbor Discovery (NDP), Router Advertisements (RA) und eine andere Denkweise bei Broadcast/Multicast. Das wirkt sich direkt auf Access Control Lists aus: Einige ICMPv6-Typen sind im Betrieb unverzichtbar, Link-Local-Adressen spielen eine besondere Rolle, und klassische IPv4-Gewohnheiten lassen sich nicht 1:1 übertragen. Dieser Leitfaden erklärt praxisnah, wie IPv6 ACLs in Cisco IOS/IOS XE funktionieren, wie Sie sie korrekt am Interface binden, welche Regeln für ein stabiles und sicheres IPv6-Design typischerweise nötig sind und wie Sie typische Fehler vermeiden (z. B. „IPv6 geht nicht mehr“, weil ICMPv6 zu hart geblockt wurde). Ziel ist eine ACL-Strategie, die restriktiv genug ist, um Angriffsfläche zu reduzieren, und zugleich betrieblich sinnvoll bleibt – damit Diagnose, Routing und essenzielle IPv6-Mechanismen weiterhin funktionieren.

Warum IPv6-ACLs nicht optional sind

In der Praxis gibt es drei häufige Gründe, warum IPv6 ACLs dringend benötigt werden:

• Dual-Stack-Lücken: IPv4 ist gefiltert, IPv6 nicht. Angreifer umgehen IPv4-Policies über IPv6.
• „Shadow IPv6“: Clients nutzen IPv6 intern, ohne dass es bewusst geplant wurde (z. B. Link-Local, SLAAC).
• IPv6-spezifische Angriffe: RA-/NDP-Manipulation, Neighbor Spoofing, Missbrauch von ICMPv6, Scanner auf globalen IPv6-Präfixen.

Best Practice ist deshalb: Wenn IPv6 im Netzwerk existiert oder auch nur „möglich“ ist, muss es genauso konsequent segmentiert und gefiltert werden wie IPv4. Die technischen Grundlagen zu IPv6 beschreibt der Anchor-Text RFC 8200 (IPv6). Für Neighbor Discovery ist der Anchor-Text RFC 4861 (Neighbor Discovery) hilfreich.

IPv6 ACL vs. IPv4 ACL: Die wichtigsten Unterschiede

Das Grundprinzip ist ähnlich: ACLs werden von oben nach unten ausgewertet, „First match wins“, und am Ende steht implizit ein „deny“, wenn nichts erlaubt ist. Dennoch gibt es Unterschiede, die Sie kennen sollten:

• Syntax: IPv6 ACLs werden typischerweise mit ipv6 access-list erstellt und mit ipv6 traffic-filter gebunden.
• ICMPv6 ist essenziell: Bestimmte ICMPv6-Typen sind für Betrieb und Routing zwingend notwendig (z. B. Neighbor Solicitation/Advertisement).
• Link-Local-Adressen: Viele Mechanismen (z. B. NDP) nutzen Link-Local-Adressen (fe80::/10) und Multicast.
• Keine NAT-Denke: IPv6 wird häufig ohne NAT betrieben, dadurch wird Segmentierung per ACL/Firewall noch wichtiger.
• Multicast statt Broadcast: Viele IPv6-Protokolle nutzen Multicast (z. B. ff02::/16), was bei zu restriktiven Regeln schnell zu Ausfällen führt.

Für Cisco-spezifische ACL-Grundlagen ist der Anchor-Text Cisco ACL Grundlagen und Konfiguration hilfreich. Die genaue IOS/IOS XE-Syntax variiert je Plattform; dafür ist die Cisco IOS Command Reference die verlässlichste Quelle.

Grundlagen vor der ACL: IPv6-Adressierung und Interface-Setup

Bevor Sie ACLs schreiben, sollten Sie sicherstellen, dass Ihre IPv6-Interfaces sauber konfiguriert sind. Ein typisches SVI- oder Router-Interface-Setup sieht so aus:

configure terminal
interface vlan 10
ipv6 address 2001:db8:10::1/64
ipv6 enable
no shutdown
end

Hinweis: ipv6 enable sorgt dafür, dass das Interface eine Link-Local-Adresse erhält, auch wenn keine globale Adresse gesetzt ist. Für viele Funktionen ist Link-Local erforderlich. Wenn Sie IPv6 wirklich nicht nutzen möchten, sollten Sie es bewusst deaktivieren oder konsequent filtern. „Halb aktiv“ ist häufig die unsicherste Variante.

Wie IPv6 ACLs aufgebaut sind

Eine IPv6 ACL besteht aus permit und deny-Einträgen, die Quellen, Ziele und Protokolle matchen. Typische Protokolle sind tcp, udp, icmp bzw. icmpv6 (je nach IOS-Variante) sowie ipv6 als generischer Catch-All. Ports werden wie bei IPv4 über eq, range usw. definiert.

Beispiel: IPv6 ACL erstellen

configure terminal
ipv6 access-list VLAN10-IN
remark Beispiel: IPv6 Policy fuer VLAN10
permit tcp 2001:db8:10::/64 any eq 443
deny ipv6 any any
end

In der Praxis ist „deny ipv6 any any“ am Ende oft sinnvoll, wenn Sie eine klare Allow-List-Policy fahren. Dabei müssen Sie jedoch die notwendigen IPv6-Basisfunktionen explizit erlauben – insbesondere ICMPv6.

ICMPv6 richtig erlauben: Der wichtigste Erfolgsfaktor

Ein sehr häufiger Fehler ist, ICMPv6 pauschal zu blockieren, weil man ICMP aus IPv4-Kontext kennt („Ping sperren“). In IPv6 ist ICMPv6 jedoch funktionaler Bestandteil vieler Mechanismen. Wenn Sie ICMPv6 zu hart filtern, brechen grundlegende Funktionen: Neighbor Discovery, SLAAC, Router Discovery, Path MTU Discovery und oft auch Traceroute/Diagnose.

Welche ICMPv6-Typen sind typischerweise notwendig?

• Neighbor Solicitation / Neighbor Advertisement: essenziell für NDP (vergleichbar mit ARP in IPv4).
• Router Solicitation / Router Advertisement: essenziell für SLAAC und Router Discovery (je nach Design).
• Packet Too Big: wichtig für Path MTU Discovery (sonst brechen große Transfers/Tunnel).
• Time Exceeded und Destination Unreachable: hilfreich für Diagnose und korrektes Fehlerverhalten.
• Echo Request / Echo Reply: optional für Ping, oft sinnvoll für Betrieb/Monitoring.

Protokollhintergrund zu ICMPv6: RFC 4443 (ICMPv6).

Beispiel: ICMPv6-Basis erlauben (Client-VLAN inbound)

Je nach IOS/IOS XE kann die Schreibweise für ICMPv6-Typen variieren. Ein verbreitetes Muster ist, ICMPv6 selektiv zu erlauben und danach die gewünschten TCP/UDP-Services zu definieren.

configure terminal
ipv6 access-list VLAN10-IN
remark ICMPv6 Basis fuer NDP und PMTUD
permit icmp any any nd-na
permit icmp any any nd-ns
permit icmp any any packet-too-big
permit icmp any any time-exceeded
permit icmp any any unreachable
remark Optional: Ping fuer Monitoring
permit icmp any any echo-request
permit icmp any any echo-reply
remark Danach Applikations-Policy
permit tcp 2001:db8:10::/64 any eq 443
deny ipv6 any any
end

Best Practice: Wenn Sie Router Advertisements im Client-VLAN zulassen müssen (SLAAC), prüfen Sie zusätzlich, ob Sie RA-Guard auf Switchports nutzen, um Rogue RAs zu verhindern. RA-Guard ist ein Switch-Security-Feature und ergänzt ACLs im Access-Layer.

IPv6 ACL am Interface anwenden

IPv6 ACLs werden typischerweise mit ipv6 traffic-filter an ein Interface gebunden, inbound oder outbound. Beispiel: inbound am VLAN-SVI, um Client-Traffic früh zu filtern.

configure terminal
interface vlan 10
ipv6 traffic-filter VLAN10-IN in
end

Best Practice: Extended/IPv6-ACLs möglichst nahe an der Quelle platzieren (z. B. inbound am Client-SVI), um unerwünschten Traffic gar nicht erst durchs Netz zu schicken. Standard-ACL-Logik wie „nah am Ziel“ gilt hier nicht, weil IPv6 ACLs ohnehin granular sind.

Praxisbeispiel: Client-VLAN darf nur DNS, NTP und Web

Ein betriebstaugliches und häufiges Muster ist eine Baseline-Policy: Clients dürfen DNS nur zu internen Resolvern, NTP nur zu Zeitservern und Web (HTTP/HTTPS) ins Internet. Zusätzlich erlauben Sie notwendiges ICMPv6. Beispielannahmen:

• Client-VLAN10: 2001:db8:10::/64
• DNS-Resolver: 2001:db8:53::10 und 2001:db8:53::11
• NTP-Server: 2001:db8:123::20 und 2001:db8:123::21

configure terminal
ipv6 access-list VLAN10-BASELINE
remark ICMPv6 Basis
permit icmp any any nd-ns
permit icmp any any nd-na
permit icmp any any packet-too-big
permit icmp any any time-exceeded
permit icmp any any unreachable
remark DNS zu internen Resolvern (UDP/TCP 53)
permit udp 2001:db8:10::/64 host 2001:db8:53::10 eq 53
permit udp 2001:db8:10::/64 host 2001:db8:53::11 eq 53
permit tcp 2001:db8:10::/64 host 2001:db8:53::10 eq 53
permit tcp 2001:db8:10::/64 host 2001:db8:53::11 eq 53
remark NTP zu Zeitservern (UDP 123)
permit udp 2001:db8:10::/64 host 2001:db8:123::20 eq 123
permit udp 2001:db8:10::/64 host 2001:db8:123::21 eq 123
remark Web ins Internet
permit tcp 2001:db8:10::/64 any eq 80
permit tcp 2001:db8:10::/64 any eq 443
deny ipv6 any any
end

Dann binden Sie die ACL inbound am VLAN10-Interface:

configure terminal
interface vlan 10
ipv6 traffic-filter VLAN10-BASELINE in
end

Dieses Muster ist betrieblich sinnvoll, weil DNS/NTP klar definiert sind und ICMPv6 die IPv6-Funktionalität stabil hält, ohne das Segment unnötig zu öffnen.

Management in IPv6 absichern: Die häufigste Dual-Stack-Lücke

Viele Teams sichern IPv4-Management (SSH) mit VTY ACLs, vergessen aber IPv6. Wenn das Gerät eine globale IPv6-Adresse auf dem Managementinterface hat, kann es über IPv6 erreichbar sein – auch wenn IPv4 gesperrt ist. Best Practice:

• SSH-only erzwingen (kein Telnet).
• Managementzugriffe auf definierte Adminpräfixe begrenzen – sowohl für IPv4 als auch IPv6.
• AAA nutzen (TACACS+/RADIUS) und lokale Break-Glass-Option behalten.

Die konkrete IPv6-VTY-Filterung ist plattformabhängig; wenn Sie IPv6-Management aktiv nutzen, prüfen Sie in der Cisco IOS Command Reference, welche Befehle für Ihre IOS/IOS XE-Version vorgesehen sind. Unabhängig davon können Sie Management auf Interface-Ebene filtern, indem Sie eine IPv6 ACL auf dem Managementinterface inbound anwenden und nur Adminpräfixe zulassen.

Logging, Zähler und Verifikation: So prüfen Sie IPv6 ACLs im Betrieb

IPv6 ACLs müssen genauso verifiziert werden wie IPv4-Regeln. Die wichtigsten Befehle im Alltag:

• show ipv6 access-list (Einträge und Trefferzähler)
• show running-config interface <IF> (ist ipv6 traffic-filter korrekt gebunden?)
• show ipv6 interface <IF> (IPv6 Status, Adressen, ND/RA Infos)
• show ipv6 neighbors (NDP Nachbartabelle, hilfreich bei Connectivity-Problemen)
• show logging (falls Sie gezielt loggen)

Best Practice: Nutzen Sie zunächst Trefferzähler, bevor Sie Logging aktivieren. ACL-Logging kann bei stark frequentierten Regeln schnell zu Logflut führen. Wenn Sie Logging einsetzen, dann nur auf eng matchenden Denies (z. B. ein bestimmter Port zu einem kritischen Ziel) und idealerweise temporär für Troubleshooting.

Typische Fehler bei IPv6 ACLs und wie Sie sie vermeiden

• ICMPv6 zu hart blockiert: NDP/SLAAC/PMTUD brechen, „IPv6 geht nicht“. Lösung: notwendige ICMPv6-Typen explizit erlauben.
• Dual-Stack vergessen: IPv4 ist geschützt, IPv6 bleibt offen. Lösung: IPv6-Management und IPv6-Filter konsequent mitdenken.
• Falsche Platzierung: ACL am falschen Interface oder in falscher Richtung. Lösung: Datenfluss prüfen und Bindings verifizieren.
• Zu breite Any-Regeln: „permit ipv6 any any“ macht die Policy wirkungslos. Lösung: Allow-List-Ansatz, Services gezielt definieren.
• Link-Local/Multicast ignoriert: NDP nutzt link-local und Multicast; ohne passende Regeln kann Nachbarschaftsauflösung scheitern. Lösung: Basis-ICMPv6-Regeln und Access-Layer-Schutz (z. B. RA Guard) einplanen.

Best Practices für Sicherheit im IPv6-Netz

• ICMPv6 ist Teil des Designs: Selektiv erlauben statt pauschal blockieren.
• DNS und NTP zu festen Servern: Clients nicht „any“, sondern nur zu Resolvern/Zeitservern.
• Segmentierung konsequent: IPv6-ACLs pro VLAN/Zone, ähnlich wie IPv4, aber mit IPv6-spezifischen Basisregeln.
• Dual-Stack durchgängig: Management, Monitoring und Policies müssen IPv4 und IPv6 abdecken.
• Dokumentation: remark-Zeilen, klare Namen, Owner und Change-Prozess.
• Access-Layer ergänzen: Features wie RA Guard/ND Inspection (plattformabhängig) gegen Rogue RA/NDP-Angriffe prüfen.

Für übergreifende Sicherheits- und Betriebsprinzipien (Least Privilege, Change-Disziplin, Logging) eignet sich der Anchor-Text CIS Controls. Für IPv6-Grundlagen und Neighbor Discovery sind RFC 8200 und RFC 4861 empfehlenswert.

Praxis-Checkliste: IPv6 ACL konfigurieren

• Ist klar, ob das Netz dual-stack ist und ob Geräte über IPv6 erreichbar sind?
• Sind ICMPv6-Basisfunktionen berücksichtigt (NDP, PMTUD, Diagnose)?
• Sind DNS und NTP zu definierten Servern erlaubt (nicht zu „any“)?
• Ist die ACL am richtigen Interface und in der richtigen Richtung gebunden (ipv6 traffic-filter ... in/out)?
• Wurden Hit Counter geprüft (show ipv6 access-list) und Tests durchgeführt (Ping, DNS, Applikation)?
• Ist Management über IPv6 genauso geschützt wie über IPv4?
• Gibt es einen Rollback-/Notfallzugang für Änderungen (insbesondere bei Management-Policies)?

copy running-config startup-config

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.