Cisco 200-301: IPv6-Adressierung und IPv6-Routing — Lernleitfaden

By Laurynas Brazys · 14 August 2026 · #cisco #200-301 #certification #exam-prep #study-guide

Teil des Cisco CCNA 200-301 — Lernleitfaden. Üben Sie mit verifizierten Antworten im Cisco-Prüfungscenter, oder absolvieren Sie zeitlich begrenzte Übungstests auf ExamRoll.io.

Überblick

IPv6 ersetzt die IPv4-Adressierung, deren Adressraum zur Neige geht, durch einen wesentlich größeren, strukturierten Adressraum und Kontrollebenenprotokolle, die für den Betrieb ohne Broadcasts konzipiert sind. Dieser Abschnitt erläutert die Konzepte der IPv6-Adressierung und des Routings, einschließlich der Konfigurationspunkte und der operativen Überlegungen, die den Designentscheidungen zugrunde liegen. Der Schwerpunkt liegt auf Ausfallszenarien, der Sicherheit am ersten Hop und einem praktischen Workflow zur Fehlerbehebung.

Grundlagen der IPv6-Adressierung

Notation, Komprimierung und Erweiterung:

• IPv6-Adressen sind 128-Bit-Werte, die in acht 16-Bit-Hextetten in hexadezimaler Schreibweise, getrennt durch Doppelpunkte, geschrieben werden (zum Beispiel 2001:0db8:0000:0000:0500:000a:400f:583b).
• Führende Nullen innerhalb eines Hextetts können weggelassen werden. Eine zusammenhängende Folge von Hextetten, die nur aus Nullen bestehen, darf einmalig durch :: komprimiert werden. Beispiel für die Komprimierung: 2001:db8::500:a:400f:583b.
• Die Erweiterung kehrt diesen Prozess um, indem die weggelassenen Nullen und Hextette wiederhergestellt werden.

Adresstypen:

• Global Unicast (GUA): 2000::/3. Öffentlich routbar; analog zu öffentlichen IPv4-Adressen. Wird für die domänenübergreifende Kommunikation verwendet.
• Unique Local (ULA): fc00::/7 (üblicherweise fd00::/8 für lokal zugewiesene). Innerhalb eines Standorts oder über VPN-verbundene Standorte erreichbar, aber nicht für das öffentliche Internet-Routing vorgesehen. Nützlich für interne Stabilität und Labor-/Testumgebungen.
• Link-Local: fe80::/10. Auf jedem IPv6-Interface erforderlich; wird für die Kommunikation auf dem gleichen Link (z. B. NDP) und als Next Hops für das Routing verwendet. Wird niemals vom Link weitergeroutet.
• Multicast: ff00::/8. Ersetzt Broadcast. Scopes definieren die Reichweite (z. B. ist ff02::/16 der Link-Local-Scope).
• Anycast: Eine Unicast-Adresse, die auf mehreren Interfaces konfiguriert ist; das Routing stellt die Pakete dem topologisch nächstgelegenen Interface zu. Wird oft für Dienste wie DNS oder als Standard-Gateway in Leaf-Spine-Designs verwendet. Anycast hat kein spezielles Bitmuster; es ist eine betriebliche Praxis.

Präfixe, Interface-Identifier und Subnetzplanung:

• Die gebräuchlichste Präfixlänge im LAN ist /64. Ein /64 ist für SLAAC erforderlich. Interface-Identifier (IIDs) sind 64 Bit lang.
• IID-Bildung:
  • EUI-64 leitet den IID von der MAC-Adresse des Interfaces ab, indem fffe in der Mitte eingefügt und das Universal/Local-Bit (Bit 7) invertiert wird. Beispiel auf Cisco IOS: ipv6 address 2001:DB8:5:112::/64 eui-64.
  • Privacy IIDs (temporäre Adressen) verwenden einen zufälligen IID, um das Tracking von Hosts zu erschweren; RFC 7217 definiert stabile, aber zufällige IIDs pro Präfix.
• Planungshinweise:
  • Verwenden Sie hierarchische Aggregation (z. B. ein /48 pro Standort, /56 pro Gebäude, /64 pro VLAN).
  • Punkt-zu-Punkt-Verbindungen können /127 verwenden, um Subnet-Router-Anycast zu eliminieren und bestimmte Scan-/ND-Erschöpfungsangriffe zu verhindern. Wenn SLAAC auf solchen Verbindungen verwendet wird, behalten Sie /64 bei.
  • Reservieren Sie GUAs für über das Internet erreichbare Netzwerke; ziehen Sie ULAs für rein interne Segmente in Betracht, um die interne Adressierung von den Zuweisungen des ISP zu entkoppeln. Vermeiden Sie NAT66; wenn eine Übersetzung aus Richtlinien- oder Provider-Unabhängigkeitsgründen erforderlich ist, bevorzugen Sie die NPTv6-Präfix-Übersetzung unter sorgfältiger Beachtung der Symmetrie.

IPv6-Autokonfiguration, Neighbor Discovery und Multicast

Router Advertisements (RAs) und Adresszuweisung:

• RAs übermitteln On-Link-Präfixe, die Lebensdauer des Standard-Gateways und Flags, die das Verhalten der Hosts steuern:
  • SLAAC: Hosts erstellen IIDs (EUI-64 oder Privacy) unter Verwendung der Prefix Information Options (PIOs) aus dem RA.
  • Zustandsloses DHCPv6: Das „Other Configuration“-Flag im RA ist gesetzt; Hosts verwenden DHCPv6 für DNS und andere Parameter, aber nicht für Adressen.
  • Zustandsbehaftetes DHCPv6: Das „Managed“-Flag im RA ist gesetzt; Hosts beziehen Adressen und Parameter von DHCPv6. Das RA kann weiterhin ein Standard-Gateway bereitstellen.
• Hinweis zu Cisco: RAs werden von L3-Interfaces gesendet, wenn ipv6 unicast-routing aktiviert ist und ein Link-Präfix vorhanden ist. Die Feinabstimmung über ipv6 nd-Befehle steuert Intervalle und Flags.
• Beispiel, um zustandsloses DHCPv6 auf einem SVI zu signalisieren:
  • interface Vlan10 ipv6 address 2001:db8:10:10::1/64 ipv6 nd other-config-flag

Neighbor Discovery Protocol (NDP) und ICMPv6:

• ICMPv6 ist die Grundlage der IPv6-Steuerung: Router Solicitation (RS), Router Advertisement (RA), Neighbor Solicitation (NS), Neighbor Advertisement (NA) und Redirect.
• Duplicate Address Detection (DAD) verwendet eine NS an die Solicited-Node-Multicast-Adresse der vorläufigen Adresse; wenn eine Antwort (NA) empfangen wird, wird die Adresse nicht zugewiesen.
• Die Auswahl des Standard-Routers wird von RAs abgeleitet; Nachbarn und Standard-Router werden im Neighbor Cache (ähnlich der ARP-Tabelle) zwischengespeichert. Betriebliche Probleme entstehen oft durch veraltete oder unvollständige Einträge im Neighbor Cache.

Multicast-Verhalten und Solicited-Node-Multicast:

• IPv6 hat keinen Broadcast. Multicast-Gruppen zielen auf spezifische Funktionen ab:
  • ff02::1 alle Knoten (jedes Interface tritt bei, wenn IPv6 aktiviert ist).
  • ff02::2 alle Router (Router-Interfaces treten bei; Hosts nicht).
  • ff02::1:ffXX:XXXX Solicited-Node-Multicast; jede zugewiesene Unicast-/Anycast-Adresse wird unter Verwendung der niederwertigsten 24 Bits der Adresse auf eine Solicited-Node-Gruppe abgebildet. Wird von NDP verwendet, um L2-Adressen effizient aufzulösen.
• Die Layer-2-Abbildung für IPv6-Multicast verwendet die MAC-Adresse 33:33:xx:xx:xx:xx. Ethernet-Multicast-Filterung und MLD-Snooping auf Switches verhindern übermäßiges Flooding.

Häufige Ausfallszenarien und Kompromisse:

• Fehlende oder gefilterte RAs führen dazu, dass Hosts sich nur Link-Local-Adressen selbst konfigurieren; die Konnektivität ist dann scheinbar nur lokal.
• Falsch gesetzte RA-Flags verursachen eine unbeabsichtigte Abhängigkeit von DHCPv6 oder fehlende DNS-Einstellungen.
• EUI-64 legt OUI-abgeleitete Identifier offen; Privacy IIDs erschweren das Tracking, gehen aber zu Lasten der betrieblichen Stabilität für ACLs.
• DAD-Fehler treten bei Anycast-ähnlichen, doppelten Adressen auf demselben Link auf; das Design der Gateway-Redundanz muss entsprechend koordiniert werden.

IPv6-Routing und -Migration

Statische Routen und Standardrouten:

• Standardroute: ::/0. Beispiel:
  • ipv6 route ::/0 GigabitEthernet0/0 fe80::1
  • Bei Verwendung eines Link-Local-Next-Hops muss die Ausgangsschnittstelle angegeben werden, um den Geltungsbereich (Scope) eindeutig zu machen.
• Beispiele für Netzwerkrouten:
  • ipv6 route 2001:db8:20::/48 2001:db8:10:1::2
  • ipv6 route 2001:db8:30::/48 GigabitEthernet0/1 fe80::2
• Betriebliche Hinweise:
  • Die rekursive Auflösung des nächsten Hops erfordert einen Neighbor-Eintrag; ND-Fehler erscheinen als unaufgelöste Adjacencies in CEF.
  • Administrative Distanz und Metrik bestimmen die Routenpräferenz unter den Kandidaten; die Weiterleitung verwendet den Longest Prefix Match.

Suche in der Routing-Tabelle:

• Der Longest Prefix Match wählt die spezifischste Route aus; bei Gleichheit berücksichtigt die Routenauswahl die Protokollpräferenz und die Metrik. Verbundene (Connected) und lokale Routen werden am meisten bevorzugt und liefern direkt angebundene Next Hops.

Dual-Stack, Tunneling und Migration:

• Dual-Stack: Paralleler Betrieb von IPv4 und IPv6. Am einfachsten zu debuggen und bietet native Leistung; verdoppelt jedoch den Aufwand für die Control-Plane und Sicherheitsrichtlinien.
• Tunneling (IPv6-in-IPv4): Manuelle oder dynamische Tunnel, GRE und 6RD transportieren IPv6 über IPv4-Cores. Nützlich, wenn der Provider kein natives IPv6 anbietet; MTU- und PMTUD-Überlegungen sind entscheidend. Tunnel verursachen zusätzlichen Kapselungs-Overhead und betriebliche Komplexität.
• Translation (Übersetzung): NAT64/DNS64 ermöglicht es reinen IPv6-Clients, reine IPv4-Server zu erreichen. Führt Zustandsbehaftung (State), Protokoll-Sonderfälle (eingebettete IPs, Literale) und Komplexität beim Debugging ein. NPTv6 bietet eine zustandslose Präfix-Übersetzung für Provider-Unabhängigkeit mit symmetrischen Pfaden.
• Design-Abwägungen:
  • Bevorzugen Sie nativen Dual-Stack zuerst an den Edges, dann im Core.
  • Verwenden Sie Tunnel als Übergangslösung mit expliziten Plänen zur Außerbetriebnahme.
  • Planen Sie für reine IPv6-Segmente die Anwendungsbereitschaft und die Platzierung von NAT64.

IPv6-Sicherheitskonzepte für den ersten Hop:

• RA Guard: Blockiert nicht autorisierte RAs an nicht vertrauenswürdigen Access-Ports; verhindert Rogue Gateways.
• DHCPv6 Guard: Blockiert nicht autorisierte DHCPv6-Server-Nachrichten.
• IPv6 Snooping und Binding Table: Lernt Bindungen von IPv6-zu-MAC-zu-Port, um Durchsetzungsfunktionen (Enforcement Features) zu versorgen.
• IPv6 Source Guard und ND Inspection: Erzwingt die Gültigkeit der Quelladresse und validiert NDP-Nachrichten anhand der Binding Table, um Spoofing zu unterbinden.
• SeND (Secure NDP) existiert, wird aber aufgrund der PKI-Komplexität selten eingesetzt.
• MLD Snooping: Beschränkt Multicast auf interessierte Empfänger; reduziert Flooding.

Workflow für Verifizierung und Fehlerbehebung

Grundlegende Prüfungen:

• Sicherstellen, dass globales IPv6 aktiviert ist:

undefined

.

• Schnittstellenstatus und Adressierung:

undefined

;

undefined

, um Link-Local, RA-Einstellungen und ND-Parameter zu bestätigen.

• Überprüfen der von Hosts gelernten RAs und Standard-Router:

undefined

und auf den Hosts die Standardroute und den SLAAC/DHCPv6-Status inspizieren.

Neighbor Discovery und Pfadauflösung:

• Neighbor-Cache prüfen:

undefined

;

undefined

, wenn Einträge veraltet sind.

• ping und traceroute mit IPv6 verwenden; sowohl Link-Local- (mit Angabe der ausgehenden Schnittstelle) als auch globale Adressen testen, um On-Link- von Off-Link-Problemen zu isolieren.

Routing:

• Routing-Tabelle inspizieren:

undefined

; die spezifischste Übereinstimmung (Longest Match) für das Ziel bestätigen.

• Statische Routen und die Erreichbarkeit des Next-Hop validieren; bei Link-Local-Next-Hops bestätigen, dass die angegebene Ausgangsschnittstelle den Nachbarn im Zustand REACH oder STALE hat.
• CEF und Adjacency:

undefined

, um die aufgelöste Adjacency zu sehen; „unresolved“ deutet auf einen Fehler bei ND oder einen ARP-ähnlichen Fehler hin.

Zustand der Control-Plane:

• ICMPv6-Zähler:

undefined

, um das Volumen und die verworfenen Pakete von NS/NA/RA/RS zu beobachten.

• Auf Switches die First-Hop-Sicherheitsrichtlinien und den MLD-Snooping-Status überprüfen, um sicherzustellen, dass legitimer Steuerungsverkehr nicht blockiert wird.

Häufige Fehlerquellen:

• Das Vergessen von

undefined

auf Routern verhindert RAs und Routing.

• Falsch konfigurierte Präfixlängen führen dazu, dass Hosts Ziele fälschlicherweise als On-Link oder Off-Link behandeln; Symptome sind unter anderem NDP-Anfragen für Off-Link-Präfixe oder fehlende Standardrouten.
• MTU/Fragmentierung über Tunnel hinweg beeinträchtigt PMTUD; auf die Handhabung von übergroßen ICMPv6 „Packet Too Big“-Nachrichten achten.

Praktisches Problemszenario

Northwind Textiles führt IPv6 auf seinem Hauptcampus ein, während sein MPLS-WAN für sechs Monate nur IPv4-fähig bleibt. Die Herausforderung: Dual-Stack-Dienste für Benutzer-VLANs, nativen IPv6-Internetzugang und sicheres First-Hop-Verhalten bereitzustellen, während der IPv4-MPLS-Core genutzt wird, um IPv6 zwischen den Gebäuden zu transportieren.

Vorgehensweise:

1. IPv6 aktivieren und Adressierungsplan erstellen

undefined

auf Campus-Routern und SVIs konfigurieren. Eine /48 GUA vom ISP als

undefined

zuweisen und diese in /64s pro Benutzer-VLAN und /127s auf gerouteten Punkt-zu-Punkt-Verbindungen aufteilen. Begründung: /64s unterstützen SLAAC; /127s auf P2P-Verbindungen reduzieren die Angriffsfläche und eliminieren Subnet-Router-Anycast.

2. SLAAC mit stateless DHCPv6 für DNS bereitstellen

• Auf SVIs

undefined

und

undefined

konfigurieren. Einen DHCPv6-Server für die RDNSS-Option einrichten oder stateless DHCPv6 verwenden, um DNS-Server bereitzustellen. Begründung: SLAAC minimiert den Konfigurationsaufwand für Clients; stateless DHCPv6 liefert kritische Parameter, die keine Adressen sind, ohne zusätzlichen Adresszustand hinzuzufügen.

3. IPv6-in-IPv4-GRE-Tunnel über den MPLS-Core aufbauen

• Punkt-zu-Punkt-GRE-Tunnel zwischen den Gebäude-Routern mit Keepalives erstellen; ein IPv6-IGP betreiben oder statische IPv6-Routen über die Tunnel legen. Begründung: GRE kapselt IPv6 über den reinen IPv4-Provider mit vorhersehbaren Pfaden; Keepalives erkennen einen Pfadausfall. Die MTU wird angepasst, um Fragmentierung zu vermeiden (

undefined

oder

undefined

).

4. Die Standardroute vom Internet-Edge aus bekannt geben

• Am Internet-Edge

undefined

in Richtung des ISP installieren und die Standardroute in das Campus-IGP bekannt geben. Begründung: Ein zentralisierter Ausgangspunkt (Egress) stellt symmetrische Datenflüsse und eine konsistente Richtlinienkontrolle sicher; die Verteilung einer Standardroute vereinfacht das Campus-Routing.

5. Den ersten Hop auf Access-Switches absichern

• RA Guard und DHCPv6 Guard auf benutzerseitigen Ports aktivieren; IPv6 Snooping aktivieren, um die Binding-Tabelle zu füllen und IPv6 Source Guard durchzusetzen. Begründung: Verhindert nicht autorisierte (rogue) RAs und nicht autorisierte DHCPv6-Server; die Quellvalidierung unterbindet Spoofing und Neighbor-Cache-Poisoning.

6. IIDs und Datenschutz standardisieren

• Für Infrastruktur-Schnittstellen stabile IIDs (manuell

undefined

,

undefined

) oder gegebenenfalls EUI-64 verwenden; für Benutzer Privacy Extensions zulassen. Begründung: Vorhersehbare Infrastrukturadressen vereinfachen den Betrieb; Privacy-IIDs schützen Benutzer vor Tracking, ohne den Gateway-Betrieb zu beeinträchtigen.

7. Verifizierung und Überwachung

• RAs mit

undefined

und

undefined

validieren; Neighbor-Tabellen und Tunnel-Adjacencies mit

undefined

und

undefined

bestätigen. Eine Baseline mit

undefined

und, wo verfügbar, mit NetFlow/IPFIX erstellen. Begründung: Frühe Baselines ermöglichen die schnelle Erkennung von Abweichungen; der Zustand von ND und Tunneln wirkt sich direkt auf die Weiterleitung aus.

8. Notfallplan für reine IPv6-Dienste

• Falls ein reines IPv6-Pilotsegment erforderlich ist, NAT64/DNS64 am Campus-Edge für den Zugriff auf reine IPv4-Sites platzieren. Begründung: NAT64 ermöglicht eine schrittweise Einführung von IPv6 und vermeidet gleichzeitig Dual-Stack auf gezielten, modernen Endgeräten; eine bereichsbezogene Nutzung begrenzt die Komplexität der Übersetzung.

Dieser Plan ermöglicht die Inbetriebnahme von IPv6 mit minimaler Unterbrechung, beherrscht die Risiken am ersten Hop und überbrückt die temporäre Lücke beim Provider mit kontrolliertem Tunneling, bis natives IPv6 durchgängig verfügbar ist.

← IPv4-Adressierung · Alle Domänen · Dynamisches Routing und IP-Konnektivität →

Diese Fragen üben → · Zeitlich begrenzte Übung auf ExamRoll.io →