IPv6/Autoconfiguration - Stateless Address Autoconfiguration

Beschreibung

Automatische Konfiguration von IPv6-Adressen

Stateless Address Autoconfiguration

Aufgabe	Beschreibung
1	Link-local Address generieren
2	Stateless Address Autoconfiguration
3	Duplicate Address Detection

Reduziert von Abhängigkeiten

Mit SLAAC reduziert IPv6 die Abhängigkeit von dritten Komponenten zur Organisation des Links

Die Nutzung von Stateless Address Autoconfiguration erfordert keine manuelle Konfiguration der Hosts und nur sehr wenige Konfigurationsschritte auf dem Router
Damit einher geht der Verlust einer strengen Zuordnung von Adressen zu bestimmten Hosts

Aressverwaltung

In Umgebungen wo die Zuordnung von Adressen zu Hosts zentral gesteuert werden soll, ist dieser Ansatz nicht ausreichend

Dort würde man auf DHCPv6 zurückgreifen
Auch ein simultaner Betrieb von DHCPv6 und Stateless Address Autoconfiguration ist möglich

Überblick

Host fragt mit einer Router Solicitation nach einem Router Advertisement
Router verschickt das angeforderte Router Advertisement mit den relevanten Daten
Host konfiguriert sein Interface
Host prüft die Eindeutigkeit der selbst erzeugten Adressen

Wenn diese Eindeutigkeit angenommen werden kann, ist die Konfiguration des Interfaces vollständig und gilt als beendet

Ablauf

Router Solicitation

Zunächst fraft der Host mit einer Router Solicitation nach einem Router Advertisement

Alternativ könnte er auch ein periodisches Router Advertisement abwarten, diese Geduld beobachtet man aber eher selten
Der Router verschickt das angeforderte Router Advertisement, welches alle konfigurationsrelevanten Daten enthält
- Wir gehen hier der Einfachheit halber von nur einem Router aus

Konfiguration des Interfaces

Daraufhin führt der Host die Konfiguration des Interfaces durch und prüft die Eindeutigkeit der selbst erzeugten Adressen

Erst wenn diese Eindeutigkeit angenommen werden kann, ist die Konfiguration des Interfaces vollständig und gilt als beendet

Multicast Listener Report

Multicast Listener Report (Solicited Node Multicast Address)

Das erste interessante Paket im Mitschnitt ist ein Multicast Listener Report und wurde von linux verschickt

Als Quelladresse hat linux die Unspecified Address gewählt

Das heißt, zum Zeitpunkt des Versendens stand keine passende, gültige Adresse zur Verfügung

Die Zieladresse ist die Multicast Address für alle MLDv2-fähigen Router

MLDv2 Messages

typisches Hop Limit ist 1
Hop-by-Hop Options Extension Headers
Padding Option, welche den Extension Header auf eine einheitliche Länge auffüllt
Router Alert Option
- Informiert Multicastfähige Router, dass sich eine MLDv2 Message im Paket befindet
- Interessierte Router werten die Nachricht aus und ziehen daraus Schlüsse für ihr Multicast Routing

Bei der MLDv2-Message handelt es sich um einen Changed to Exclude

In IPv6/Host/Multicast ist beschrieben, wie dieser Typ zu interpretieren ist
Hier wird die Multicast Adresse ff02::1:ff60:d1e für alle potentiellen Multicast-Quellen freigegeben
Die Nachricht entspricht dem Beitritt zur Multicast Group ff02::1:ff60:d1e
Es handelt sich dabei um die Solicited Node Multicast Address von Interface eth0 auf linux

Gruppenbeitritt

Zu diesem Zeitpunkt hat linux bereits einen Interface Identifier erzeugt

Der Beitritt zur entsprechenden Multicast Group gewährt ihm Zugang zu den Paketen dieser Gruppe

So hat er die Chance, frühzeitig zu erfahren, ob sein Interface Identifier schon verwendet wird

Würde ein anderer Node seinen Interface Identifier bereits verwenden, so wäre dieser Node ebenfalls Mitglied der Multicast Group

Eine doppelt vorkommende Adresse würde dadurch schneller auffallen

Gruppen mit mehreren Mitgliedern

Es ist möglich, dass ein anderer Node eine ähnliche Adresse verwendet

Etwa eine Adresse bei der sich die letzten 24 Bit gleichen

Beide Nodes wären nun in derselben Gruppe, jene mit der gemeinsamen Solicited Node Multicast Address
Beide Nodes würden Pakete empfangen, die nicht für sie bestimmt wären
- Die aufgrund der Ähnlichkeit der Adresse aber an die gemeinsame Gruppe geschickt wurden
Jeder Node muss deshalb prüfen, ob ein Paket, welches an die Gruppe adressiert wurde, auch wirklich für ihn von Belang ist
Auch linux könnte Pakete empfangen, nach der Prüfung des Inhaltes aber feststellen, dass der eigene Interface Identifier davon nicht betroffen ist

Vorlage:;IPv6/Autoconfiguration/DuplicateAddressDetection

Router Solicitation

Adresse für den Global Scope

Nachdem linux nun eine gültige Link-local Address hat, versucht er auch eine gültige Adresse für den Global Scope zu erhalten

Dazu lässt er sich von jedem Router am Link ein RouterAdvertisement zukommen
Die Anforderung der Router Advertisements geschieht mit Hilfe einer Router Solicitation

Die Nachricht wird von der Link-local Address des Hosts gesendet

Hier von der Adresse

fe80::200:ff:fe6:d1e

Als Zieladresse wird die All Routers Multicast Address ff02::2 verwendet
Angehängt an die Router Solicitation ist, eine ICMPv6-Option mit der Link-layer Address des Absenders

Router Advertisement

Alle Router am Link antworten auf die Router Solicitation mit einem Router Advertisement

Da wir nur einen Router am Link haben, nämlich router, erhalten wir auch nur ein Router Advertisement

Nach dem Erhalt des Router Advertisements erzeugt linux eine Global Unicast Address

Dazu verwendet er das von router verteilte Präfix und den bereits vorhandenen Interface Identifier

Solicited Node

Multicast Listener Report (Solicited Node)

Auch für diese Adresse muss eine Duplicate Address Detection durchgeführt werden

Die beginnt wieder mit dem Beitritt zu der passenden Multicast Group
Obwohl sich die Solicited Node Multicast Address für die Global Unicast Address nicht von der für die Link-local Address unterscheidet, versendet linux einen neuen Multicast Listener Report
Der wesentliche Unterschied ist die Quelladresse des Paketes

Anstatt der Unspecified Address kommt diesmal die Link-local Address zum Einsatz

Unverändert geblieben ist der Beitritt zur Solicited Node Multicast Group, der erneut mithilfe von Changed to Exclude erreicht wurde

Und einen weiteren Gruppenbeitritt können wir im Paket entdecken, der Beitritt zur Gruppe ff02::fb
Dies ist die Multicast DNS Address für die Verwendung mit IPv6, und für unser Netz nicht weiter wichtig

Duplicate Address Detection (Global Unicast)

IPv6/Autoconfiguration/DuplicateAddressDetection

Test

Einem Test der Konnektivität von linux steht nun nichts mehr im Wege

Dazu verschicken wir Echo Requests von linux an den Tunnelendpunkt des Tunnelbrokers

ping6 -c 3 2a01:198:200:a23::1

Da Echo Replies eintreffen, können wir davon ausgehen dass das Routing funktioniert

Den Beweis können wir auch mit traceroute6 antreten:

traceroute6 -n 2a01:198:200:a23::1

An erster Stelle steht der nächste Hop, in unserem Fall die Adresse des Interfaces eth1 von router

Schon in der zweiten Zeile ist das Ziel erreicht

SLAAC unter Windows

Analyse einer Autoconfiguration unter Windows

Bei dieser Gelegenheit werden wir auch Unterschiede entdecken, die durch Aktivierung von Privacy Extensions auftreten

Dazu öffnen wir als Administrator ein Terminal und stellen sicher, dass die Privacy Extensions aktiviert sind

C:\Users\user> netsh interface ipv6 set global randomizeidentifiers = enabled
Ok

Wireshark unter Windows

Leider kommt es unter Windows beim Betrieb von Wireshark manchmal zu Problemen

Der benötigte Treiber zum Mitschnitt von Daten heißt Windows Packet Capture (WinPcap), je nach Update-Stand von Windows kann er funktionieren oder auch nicht
Als Lösung bietet es sich an, den Verkehr von eth1 auf router mitzuschreiben, auch dort kommen die Pakete vorbei

Sobald Wireshark bereit ist, deaktivieren wir die LAN-Verbindung auf Windows und aktivieren sie anschließend wieder

Bei einer Beobachtung von router aus, können wir alternativ auch einen Neustart von Windows durchführen

Eigene Untersuchungen

Untersuchen Sie die einzelnen Pakete und finden Sie heraus, zu welchem Zweck jedes einzelne versendet wurde

Sie können sich dabei auf ICMPv6 beschränken und auch die Teile von MLDv2, die sich um Multicast DNS drehen, ignorieren
Erkennen Sie anhand der Informationen in den Paketen, ob diese sich auf einen zufälligen (Privacy Extensions) oder auf einen EUI-64-basierten Interface Identifier beziehen?

Ablaufverfolgung

Aufzeichnung einer Autoconfiguration mit Wireshark

Vom Hochfahren des Interfaces bis zu seiner endgültigen Konfiguration

Interface herunterfahren

# ip link set down dev enp2s0
2: enp2s0: <BROADCAST,MULTICAST> mtu 1500 qdisc pfifo_fast state DOWN group default qlen 1000
   link/ether 74:27:ea:e1:b2:b4 brd ff:ff:ff:ff:ff:ff
   inet 192.168.1.106/24 brd 192.168.1.255 scope global dynamic noprefixroute enp2s0
      valid_lft 4826sec preferred_lft 4826sec

Wireshark starten

auf PseudoInterface any lauschen

Interface starten

# ip link set up dev enp2s0
enp2s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
   link/ether 74:27:ea:e1:b2:b4 brd ff:ff:ff:ff:ff:ff
   inet6 2001::a44d:a161:1a33:c64d/64 scope global dynamic noprefixroute
      valid_lft 86399sec preferred_lft 14399sec
   inet6 fe80::99d7:66e5:331d:9449/64 scope link noprefixroute
      valid_lft forever preferred_lft forever

Aktivität beobachten

In Wireshark können wir bereits Aktivität beobachten. Wir warten den Abschluss der Konfiguration ab, sie ist erfolgreich verlaufen wenn wir Adressen mit den Parametern scope global und dynamic sehen:

# ip addr show dev enp1s0
2: enp1s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
   link/ether 50:3e:aa:1f:63:81 brd ff:ff:ff:ff:ff:ff
   inet 10.30.1.1/24 brd 10.30.1.255 scope global enp1s0
      valid_lft forever preferred_lft forever
   inet6 fe80::523e:aaff:fe1f:6381/64 scope link
      valid_lft forever preferred_lft forever

Anhang

Siehe auch

Links

Weblinks