IPv6/Autoconfiguration: Unterschied zwischen den Versionen
K Textersetzung - „http://“ durch „https://“ |
|||
| (80 dazwischenliegende Versionen desselben Benutzers werden nicht angezeigt) | |||
| Zeile 1: | Zeile 1: | ||
'''S'''tate'''l'''ess '''A'''ddress '''A'''utoconfiguration ( | '''{{BASEPAGENAME}}''' - '''S'''tate'''l'''ess '''A'''ddress '''A'''utoconfiguration (Automatische Konfiguration von IPv6-Adressen) | ||
== Beschreibung == | == Beschreibung == | ||
{| class="wikitable options col1center big" | |||
{| class="wikitable options col1center" | |||
|- | |- | ||
! Aufgabe !! Beschreibung | ! Aufgabe !! Beschreibung | ||
| Zeile 15: | Zeile 13: | ||
|} | |} | ||
; 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 | * 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 | * 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 | * Dort würde man auf DHCPv6 zurückgreifen | ||
* | * Auch ein simultaner Betrieb von [[DHCPv6]] und Stateless Address Autoconfiguration ist möglich | ||
; Überblick | |||
[[Datei:Prinzip SLAAC.png|mini|500px|Prinzip SLAAC]] | |||
# 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 | |||
<br clear=all> | |||
Wenn diese Eindeutigkeit angenommen werden kann, ist die Konfiguration des Interfaces vollständig und gilt als beendet | |||
== Ablauf == | == 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 | * 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 | * Der Router verschickt das angeforderte Router Advertisement, welches alle konfigurationsrelevanten Daten enthält | ||
** Wir gehen hier der Einfachheit halber von nur einem Router aus | ** Wir gehen hier der Einfachheit halber von nur einem Router aus | ||
; Daraufhin führt der Host die Konfiguration des Interfaces durch und prüft die Eindeutigkeit der selbst erzeugten Adressen | ; 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 | * 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]]) | ||
[[File:SLAAC-Paket1.png|mini|400px|SLAAC-Paket 1]] | |||
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 | ; 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 | 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 | * Die Zieladresse ist die Multicast Address für alle MLDv2-fähigen Router | ||
; | ; MLDv2 Messages | ||
* | [[File:SLAAC-Paket1MulticastListenerReport.png|mini|400px|Multicast Listener Report]] | ||
* Hier wird die Multicast Address | * typisches Hop Limit ist 1 | ||
* Die Nachricht entspricht dem Beitritt zur Multicast Group | * 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 [[IPv6/Multicast/Address|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'' | * Es handelt sich dabei um die Solicited Node Multicast Address von Interface eth0 auf ''linux'' | ||
=== Gruppenbeitritt === | === Gruppenbeitritt === | ||
; Zu diesem Zeitpunkt hat ''linux'' bereits einen Interface Identifier erzeugt | ; 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 | ; 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 | * Eine doppelt vorkommende Adresse würde dadurch schneller auffallen | ||
=== Gruppen mit mehreren Mitgliedern === | ==== Gruppen mit mehreren Mitgliedern ==== | ||
; Es | ; 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ären nun in derselben Gruppe, jene mit der gemeinsamen [[Solicited Node Multicast Address]] | ||
* Beide Nodes würden | * 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 | * 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 | * Auch ''linux'' könnte Pakete empfangen, nach der Prüfung des Inhaltes aber feststellen, dass der eigene Interface Identifier davon nicht betroffen ist | ||
=== | === Duplicate Address Detection === | ||
; Feststellung der Eindeutigkeit einer IPv6-Adresse | |||
Wenn ein Node feststellen möchte, ob eine Adresse schon von einem anderen Node genutzt wird, dann versucht er die zugehörige Linklayer Address aufzulösen | |||
* Besteht aus mehreren [[Neighbor Solicitation]]s | |||
* Bleibt eine Antwort aus, benutzt offensichtlich kein anderer Node die Adresse | |||
* Um Fehlschlüsse aufgrund von Paketverlusten zu vermeiden, sollen mehrere Neighbor Solicitations verschickt werden | |||
; Eindeutigkeit | |||
Ab wann eine Adresse als eindeutig gilt, hängt von den Parametern der jeweiligen Implementierung ab | |||
* Jede Adresse hat anfangs den Status tentative (probeweise) | |||
* Erst, wenn die Duplicate Address Detection vollständig durchlaufen wurde und keine Anzeichen darauf schließen lassen, dass die Adresse bereits in Benutzung ist, wird die Adresse valid (gültig) | |||
; Duplicate Address Detection (Link-local) | |||
[[File:SLAAC-Paket2-NeighborSolicitation.png|mini|400px|Neighbor Solicitation]] | |||
Möchte ''linux'' nun feststellen, ob die von ihm gewählte Adresse nicht nur vielleicht eindeutig ist, dann ist eine Duplicate Address Detection erfolgsversprechender | |||
* Wenn sie fehlschlägt, dann ist die von ''linux'' gewählte Adresse sehr wahrscheinlich auf dem Link noch nicht vergeben | * Wenn sie fehlschlägt, dann ist die von ''linux'' gewählte Adresse sehr wahrscheinlich auf dem Link noch nicht vergeben | ||
; Eine endgültige Gewissheit ist mit der Duplicate Address Detection nicht zu erreichen | ; Eine endgültige Gewissheit ist mit der Duplicate Address Detection nicht zu erreichen | ||
* Im ungünstigsten Fall gehen genau jene Pakete verloren, die auf eine doppelte Adresse hinweisen würden | * Im ungünstigsten Fall gehen genau jene Pakete verloren, die auf eine doppelte Adresse hinweisen würden | ||
* Dazu sendet ''linux'' eine Neighbor Solicitation für die selbst erzeugte Adresse aus | * Dazu sendet ''linux'' eine Neighbor Solicitation für die selbst erzeugte Adresse aus | ||
; Als Quelladresse wählt er wieder die Unspecified Address, da die Link-local Address noch nicht als eindeutig gilt | ; Quelladresse | ||
Als Quelladresse wählt er wieder die Unspecified Address, da die Link-local Address noch nicht als eindeutig gilt | |||
* Die Neighbor Solicitation geht an die Solicited Node Multicast Address der zu überprüfenden Link-local Address | * Die Neighbor Solicitation geht an die Solicited Node Multicast Address der zu überprüfenden Link-local Address | ||
* Im Feld Target Address taucht die gewünschte Adresse | * Im Feld Target Address taucht die gewünschte Adresse ''fe80::200:ff:fe60:d1e'' schließlich auf | ||
Das Ausbleiben eines Neighbor Advertisements wertet der Node als Anzeichen für die Eindeutigkeit seiner Adresse auf dem Link | |||
* Sie wird dann dem Interface zugewiesen und gilt fortan als valid | * Sie wird dann dem Interface zugewiesen und gilt fortan als valid | ||
=== Router Solicitation === | === Router Solicitation === | ||
; Nachdem ''linux'' nun eine gültige Link-local Address hat, versucht er auch eine gültige Adresse für den Global Scope zu erhalten | [[File:SLAAC-Paket3RouterSolicitation.png|mini|400px|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 | * Dazu lässt er sich von jedem Router am Link ein RouterAdvertisement zukommen | ||
* Die Anforderung der Router Advertisements geschieht mit Hilfe einer | * Die Anforderung der Router Advertisements geschieht mit Hilfe einer Router Solicitation | ||
; Die Nachricht wird von der Link-local Address des Hosts gesendet | ; Die Nachricht wird von der Link-local Address des Hosts gesendet | ||
Hier von der Adresse | Hier von der Adresse | ||
fe80::200:ff:fe6:d1e | fe80::200:ff:fe6:d1e | ||
* Als Zieladresse wird die ''All Routers Multicast Address'' | * 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 | * Angehängt an die Router Solicitation ist, eine ICMPv6-Option mit der Link-layer Address des Absenders | ||
| Zeile 200: | Zeile 129: | ||
; Alle Router am Link antworten auf die Router Solicitation mit einem 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 | * 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 | ; 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 | * Dazu verwendet er das von ''router'' verteilte Präfix und den bereits vorhandenen Interface Identifier | ||
=== | === Solicited Node === | ||
; Multicast Listener Report (Solicited Node) | |||
[[File:SLAAC-Paket5-IPv6-Header.png|mini|400px]] | |||
; Auch für diese Adresse muss eine Duplicate Address Detection durchgeführt werden | ; Auch für diese Adresse muss eine Duplicate Address Detection durchgeführt werden | ||
* Die beginnt wieder mit dem Beitritt zu der passenden Multicast Group | * 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 | * 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 | * Der wesentliche Unterschied ist die Quelladresse des Paketes | ||
[[File:SLAAC-Paket5MulticastListenerReport.png|mini|400px]] | |||
; Anstatt der Unspecified Address kommt diesmal die Link-local Address zum Einsatz | ; 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'' | |||
* Und einen weiteren Gruppenbeitritt können wir im Paket entdecken, der Beitritt zur Gruppe | |||
* Dies ist die Multicast DNS Address für die Verwendung mit IPv6, und für unser Netz nicht weiter wichtig | * 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 | ; 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: | Dazu verschicken wir Echo Requests von ''linux'' an den Tunnelendpunkt des Tunnelbrokers: | ||
user@linux:~ $ ping6 -c 3 | user@linux:~ $ ping6 -c 3 2a01:198:200:a23::1 | ||
; Da Echo Replies eintreffen, können wir davon ausgehen dass das Routing funktioniert | ; Da Echo Replies eintreffen, können wir davon ausgehen dass das Routing funktioniert | ||
Den Beweis können wir auch mit traceroute6 antreten: | Den Beweis können wir auch mit traceroute6 antreten: | ||
user@linux:~ $ traceroute6 -n | user@linux:~ $ 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 | * Schon in der zweiten Zeile ist das Ziel erreicht | ||
== SLAAC unter Windows == | |||
[[IPv6/Autoconfiguration/Windows]] | |||
== Eigene Untersuchungen == | |||
; Untersuchen Sie die einzelnen Pakete und finden Sie heraus, zu welchem Zweck jedes einzelne versendet wurde | ; 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 | * 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? | * 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=== | ==== Interface herunterfahren ==== | ||
# '''ip link set down dev enp2s0''' | # '''ip link set down dev enp2s0''' | ||
2: enp2s0: <BROADCAST,MULTICAST> mtu 1500 qdisc pfifo_fast state '''DOWN''' group default qlen 1000 | 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 | link/ether 74:27:ea:e1:b2:b4 brd ff:ff:ff:ff:ff:ff | ||
| Zeile 315: | Zeile 182: | ||
valid_lft 4826sec preferred_lft 4826sec | valid_lft 4826sec preferred_lft 4826sec | ||
=== Wireshark starten === | ==== Wireshark starten ==== | ||
Wireshark starten | [[Wireshark]] starten | ||
* auf PseudoInterface ''any'' lauschen | * auf PseudoInterface ''any'' lauschen | ||
==== Interface starten ==== | |||
=== Interface starten === | |||
# '''ip link set up dev enp2s0''' | # '''ip link set up dev enp2s0''' | ||
enp2s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state '''UP''' group default qlen 1000 | enp2s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state '''UP''' group default qlen 1000 | ||
| Zeile 333: | Zeile 195: | ||
valid_lft forever preferred_lft forever | valid_lft forever preferred_lft forever | ||
=== Aktivität beobachten === | ==== 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: | 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''' | # '''ip addr show dev enp1s0''' | ||
| Zeile 343: | Zeile 205: | ||
valid_lft forever preferred_lft forever | valid_lft forever preferred_lft forever | ||
<noinclude> | <noinclude> | ||
Aktuelle Version vom 7. Juni 2025, 11:26 Uhr
IPv6/Autoconfiguration - Stateless Address Autoconfiguration (Automatische Konfiguration von IPv6-Adressen)
Beschreibung
| 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
Duplicate Address Detection
- Feststellung der Eindeutigkeit einer IPv6-Adresse
Wenn ein Node feststellen möchte, ob eine Adresse schon von einem anderen Node genutzt wird, dann versucht er die zugehörige Linklayer Address aufzulösen
- Besteht aus mehreren Neighbor Solicitations
- Bleibt eine Antwort aus, benutzt offensichtlich kein anderer Node die Adresse
- Um Fehlschlüsse aufgrund von Paketverlusten zu vermeiden, sollen mehrere Neighbor Solicitations verschickt werden
- Eindeutigkeit
Ab wann eine Adresse als eindeutig gilt, hängt von den Parametern der jeweiligen Implementierung ab
- Jede Adresse hat anfangs den Status tentative (probeweise)
- Erst, wenn die Duplicate Address Detection vollständig durchlaufen wurde und keine Anzeichen darauf schließen lassen, dass die Adresse bereits in Benutzung ist, wird die Adresse valid (gültig)
- Duplicate Address Detection (Link-local)
Möchte linux nun feststellen, ob die von ihm gewählte Adresse nicht nur vielleicht eindeutig ist, dann ist eine Duplicate Address Detection erfolgsversprechender
- Wenn sie fehlschlägt, dann ist die von linux gewählte Adresse sehr wahrscheinlich auf dem Link noch nicht vergeben
- Eine endgültige Gewissheit ist mit der Duplicate Address Detection nicht zu erreichen
- Im ungünstigsten Fall gehen genau jene Pakete verloren, die auf eine doppelte Adresse hinweisen würden
- Dazu sendet linux eine Neighbor Solicitation für die selbst erzeugte Adresse aus
- Quelladresse
Als Quelladresse wählt er wieder die Unspecified Address, da die Link-local Address noch nicht als eindeutig gilt
- Die Neighbor Solicitation geht an die Solicited Node Multicast Address der zu überprüfenden Link-local Address
- Im Feld Target Address taucht die gewünschte Adresse fe80::200:ff:fe60:d1e schließlich auf
Das Ausbleiben eines Neighbor Advertisements wertet der Node als Anzeichen für die Eindeutigkeit seiner Adresse auf dem Link
- Sie wird dann dem Interface zugewiesen und gilt fortan als valid
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:
user@linux:~ $ 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:
user@linux:~ $ 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
IPv6/Autoconfiguration/Windows
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
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