Zum Inhalt springen

IPv6/Autoconfiguration: Unterschied zwischen den Versionen

Aus Foxwiki
Versionsgeschichte interaktiv durchsuchen
← Zum vorherigen Versionsunterschied
Visuell
Keine Bearbeitungszusammenfassung
 
(209 dazwischenliegende Versionen desselben Benutzers werden nicht angezeigt)
Zeile 1: Zeile 1:
== Stateless Address Autoconfiguration ==
'''{{BASEPAGENAME}}''' - '''S'''tate'''l'''ess '''A'''ddress '''A'''utoconfiguration (Automatische Konfiguration von IPv6-Adressen)
===  Zweck ===
Die Stateless Address Autoconfiguration, kurz SLAAC, dient der automatischen Konfiguration von Adressen und Routen der Hosts am Link.
* Damit reduziert IPv6 als Protokoll die


Abhängigkeit von dritten Komponenten zur Organisation des Links.
== Beschreibung ==
* Die Nutzung von Stateless Address Autoconfiguration erfordert keine manuelle Konfiguration der Hosts und nur sehr wenige Konfigurationsschritte auf dem Router.
{| class="wikitable options col1center big"
* Damit einher geht der Verlust einer strengen Zuordnung von Adressen zu bestimmten Hosts.
|-
* In Umgebungen wo die Zuordnung von Adressen zu Hosts zentral gesteuert werden soll, ist dieser Ansatz nicht ausreichend.
! Aufgabe !! Beschreibung
* Dort würde man auf DHCPv6 zurückgreifen.
|-
* Aber auch ein simultaner Betrieb von DHCPv6 und Stateless Address Autoconfiguration wäre denkbar.
| 1 || Link-local Address generieren
|-
| 2 || Stateless Address Autoconfiguration
|-
| 3 || Duplicate Address Detection
|}


===  Autoconfiguration ===
; Reduziert von Abhängigkeiten
SLAAC ist Bestandteil der Autoconfiguration, die drei wesentliche Aufgaben hat:
Mit SLAAC reduziert IPv6 die Abhängigkeit von dritten Komponenten zur Organisation des Links
* Generieren einer Link-local Address
* Die Nutzung von Stateless Address Autoconfiguration erfordert keine manuelle Konfiguration der Hosts und nur sehr wenige Konfigurationsschritte auf dem Router
* Durchführen der Stateless Address Autoconfiguration
* Damit einher geht der Verlust einer strengen Zuordnung von Adressen zu bestimmten Hosts
* Sicherstellen der Eindeutigkeit der generierten Adressen (Duplicate Address Detection)


===  Prinzipieller Ablauf ===
; Aressverwaltung
: Abbildung 5.9 Prinzip von SLAAC
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


Den ersten Schritt macht der Host, indem er mittels Router Solicitation nach einem Router Advertisement fragt.
; Überblick
* Alternativ könnte er auch ein periodisches Router Advertisement abwarten, diese Geduld beobachtet man aber eher selten.
[[Datei:Prinzip SLAAC.png|mini|500px|Prinzip SLAAC]]
Der Router verschickt das angeforderte Router Advertisement, welches alle konfigurationsrelevanten Daten enthält (Wir gehen der Einfachheit halber von nur einem Router aus.)
# 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


Daraufhin führt der Host die Konfiguration des Interfaces durch und prüft die Eindeutigkeit der selbst erzeugten Adressen.
== Ablauf ==
* Erst wenn diese Eindeutigkeit angenommen werden kann, ist die Konfiguration des Interfaces vollständig und gilt als beendet.
; 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


===  Duplicate Address Detection ===
; Konfiguration des Interfaces
Hinter der Duplicate Address Detection verbergen sich eigentlich mehrere Neighbor Solicitations.
Daraufhin führt der Host die Konfiguration des Interfaces durch und prüft die Eindeutigkeit der selbst erzeugten Adressen
* 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.
* Erst wenn diese Eindeutigkeit angenommen werden kann, ist die Konfiguration des Interfaces vollständig und gilt als beendet
* Bleibt eine Antwort aus, benutzt offensichtlich kein anderer Node auf dem Link die überprüfte Adresse.
* Um Fehlschlüsse aufgrund von Paketverlusten zu vermeiden, sollen mehrere Neighbor Solicitations verschickt werden.
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).


=== Autoconfiguration mitschneiden ===
=== Multicast Listener Report ===
Wir werden versuchen eine komplette Autoconfiguration von lynx mit Wireshark aufzufangen.
; Multicast Listener Report ([[Solicited Node Multicast Address]])
* Vom Hochfahren des Interfaces bis zu seiner endgültigen Konfiguration.
[[File:SLAAC-Paket1.png|mini|400px|SLAAC-Paket 1]]
Dazu öffnen wir ein root-Terminal auf lynx und fahren das Interface eth0 herunter:
Das erste interessante Paket im Mitschnitt ist ein Multicast Listener Report und wurde von ''linux'' verschickt
root@lynx :~# ip link set down dev eth


Nun starten wir Wireshark und lassen ihn auf dem PseudoInterface any lauschen.
; Als Quelladresse hat ''linux'' die Unspecified Address gewählt
Danach fahren wir eth0 wieder hoch:
Das heißt, zum Zeitpunkt des Versendens stand keine passende, gültige Adresse zur Verfügung
root@lynx :~# ip link set up dev eth
* Die Zieladresse ist die Multicast Address für alle MLDv2-fähigen Router


In Wireshark können wir bereits Aktivität beobachten.  
; MLDv2 Messages
* Wir warten den Abschluss der Konfiguration ab, sie ist erfolgreich verlaufen wenn wir Adressen mit den Parametern scope global und dynamic sehen:
[[File:SLAAC-Paket1MulticastListenerReport.png|mini|400px|Multicast Listener Report]]
user@lynx :~ $ ip addr show dev eth
* typisches Hop Limit ist 1
2: eth : < BROADCAST , MULTICAST ,UP , LOWER_UP > mtu 15 qdisc pfifo_fast state UP qlen 1
* Hop-by-Hop Options Extension Headers
link / ether : : :6 : d :1 e brd ff : ff : ff : ff : ff : ff inet6 2 a 1 :198:2 :8 a23 :2 : ff : fe6 : d1e /64 scope global dynamic valid_lft 3578 sec preferred_lft 1778 sec inet6 fe8 ::2 : ff : fe6 : d1e /64 scope link valid_lft forever preferred_lft forever
* 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


Wireshark kann jetzt den Mitschnitt beenden.
; Bei der MLDv2-Message handelt es sich um einen ''Changed to Exclude''
* Von den vielen Paketen die wir mitgeschnitten haben sind nicht alle von Interesse.
* 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''


===  Multicast DNS ===
===  Gruppenbeitritt ===
Insbesondere die Pakete vom Typ Multicast DNS (mDNS) werden wir an dieser Stelle ignorieren.
; Zu diesem Zeitpunkt hat ''linux'' bereits einen Interface Identifier erzeugt
* Multicast DNS erlaubt die Auflösung von Namen der Domain .local zu Linklocal Addresses.
Der Beitritt zur entsprechenden Multicast Group gewährt ihm Zugang zu den Paketen dieser Gruppe
* Leider belastet es dazu den Link ungefragt mit allerlei Paketen.
* Da wir im Workshop keine lokale Namensauflösung auf Multicast-Basis nutzen, kümmern wir uns nicht weiter um dieses Protokoll.
* Mehr zu Multicast DNS und seinem Nutzen für kleine Netze findet sich auf der gemeinsamen Website der Beteiligten Interessensgruppen. (http://www.multicastdns.org/)


===  Multicast Listener Report (Solicited Node) ===
; So hat er die Chance, frühzeitig zu erfahren, ob sein Interface Identifier schon verwendet wird
Das erste interessante Paket im Mitschnitt ist ein Multicast Listener Report und wurde von lynx verschickt.
Würde ein anderer Node seinen Interface Identifier bereits verwenden, so wäre dieser Node ebenfalls Mitglied der Multicast Group
* Der IPv6-Header ist in Abbildung 5.10 zu sehen.
* Eine doppelt vorkommende Adresse würde dadurch schneller auffallen


: Abbildung 5.10 SLAAC Paket 1: IPv6-Header
====  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


Als Quelladresse hat lynx die Unspecified Address gewählt.
=== Duplicate Address Detection ===
Das heißt, zum Zeitpunkt des Versendens stand keine passende, gültige Adresse zur Verfügung.
; Feststellung der Eindeutigkeit einer IPv6-Adresse
* Die Zieladresse ist die Multicast Address für alle MLDv2-fähigen Router.
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
* Zu finden auch in der Tabelle 4.5 in Abschnitt 4.5 Multicast.
* Besteht aus mehreren [[Neighbor Solicitation]]s
* Uns fällt das für MLDv2 Messages typische Hop Limit von 1 auf.
* Bleibt eine Antwort aus, benutzt offensichtlich kein anderer Node die Adresse
* Bemerkenswert ist auch der Einsatz des Hop-by-Hop Options Extension Headers.
* Um Fehlschlüsse aufgrund von Paketverlusten zu vermeiden, sollen mehrere Neighbor Solicitations verschickt werden
* Neben der Padding Option, welche den Extension Header auf eine einheitliche Länge auffüllt, ist auch eine Router Alert Option vorhanden.
* Sie informiert Multicastfähige Router darüber, dass sich eine MLDv2 Message im Paket befindet.
* Interessierte Router werten die Nachricht dann aus und ziehen daraus Schlüsse für ihr Multicast Routing.
* Die MLDv2 Message kann in Abbildung 5.11 eingesehen werden.


Genaugenommen handelt sich um eine MLDv2 Message der Art Changed to Exclude.
; Eindeutigkeit
* Wir haben in Abschnitt 4.5 Multicast bereits besprochen wie dieser Typ zu interpretieren ist.
Ab wann eine Adresse als eindeutig gilt, hängt von den Parametern der jeweiligen Implementierung ab
* Hier wird die Multicast Address ff 2::1:ff6 :d1e für alle potentiellen Multicast-Quellen freigegeben.
* Jede Adresse hat anfangs den Status tentative (probeweise)
* Die Nachricht entspricht dem Beitritt zur Multicast Group ff 2::1:ff6 :d1e.
* 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)
* Es handelt sich dabei um die Solicited Node Multicast Address von Interface eth0 auf lynx.


===  Gruppenbeitritt ===
; Duplicate Address Detection (Link-local)
Zu diesem Zeitpunkt hat lynx also bereits einen Interface Identifier erzeugt.  
[[File:SLAAC-Paket2-NeighborSolicitation.png|mini|400px|Neighbor Solicitation]]
* Der Beitritt zur entsprechenden Multicast Group gewährt ihm Zugang zu den Paketen dieser Gruppe.
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


: Abbildung 5.11 SLAAC Paket 1:Multicast Listener Report
; 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


So hat er die Chance, frühzeitig zu erfahren, ob sein Interface Identifier schon verwendet wird.
; Quelladresse
* Würde ein anderer Node seinen Interface Identifier bereits verwenden, so wäre dieser Node ebenfalls Mitglied der Multicast Group.
Als Quelladresse wählt er wieder die Unspecified Address, da die Link-local Address noch nicht als eindeutig gilt
* Eine doppelt vorkommende Adresse würde dadurch schneller auffallen.
* 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


===  Gruppen mit mehreren Mitgliedern ===
Das Ausbleiben eines Neighbor Advertisements wertet der Node als Anzeichen für die Eindeutigkeit seiner Adresse auf dem Link
Es wäre allerdings auch möglich, dass ein anderer Node eine ähnliche Adresse verwendet.
* Sie wird dann dem Interface zugewiesen und gilt fortan als valid
* Beispielsweise eine Adresse bei der sich die letzten 24 Bits gleichen.
* Beide Nodes wären nun in derselben Gruppe, jene mit der gemeinsamen Solicited Node Multicast Address.
* Beide Nodes würden auch 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 lynx könnte Pakete empfangen, nach der Prüfung des Inhaltes aber feststellen, dass der eigene Interface Identifier davon nicht betroffen ist.
 
===  Duplicate Address Detection (Link-local) ===
Möchte lynx 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 lynx gewählte Adresse sehr wahrscheinlich
 
: Abbildung 5.12: SLAAC Paket 2: Neighbor Solicitation
 
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 lynx eine Neighbor Solicitation für die selbst erzeugte Adresse aus (siehe Abbildung 5.12).
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 fe8 ::2 :ff:fe6 :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 ===
===  Router Solicitation ===
Nachdem lynx 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]]
* Dazu lässt er sich von jedem Router am Link ein Router
; 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


: Abbildung 5.13: SLAAC Paket 3: Router Solicitation
; Die Nachricht wird von der Link-local Address des Hosts gesendet
 
Hier von der Adresse
Advertisement zukommen.
fe80::200:ff:fe6:d1e
* Die Anforderung der Router Advertisements geschieht mit Hilfe einer Router Solicitation, die in Abbildung 5.13 zu sehen ist.
* 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
Die Nachricht wird von der Link-local Address des Hosts gesendet, hier von der Adresse fe8 ::2 :ff:fe6 :d1e.
* Als Zieladresse wird die All Routers Multicast Address ff 2::2 verwendet, die wir schon in der Tabelle 4.5 in Abschnitt 4.5 Multicast gesehen haben.
* Angehängt an die Router Solicitation ist, eine ICMPv6-Option mit der Link-layer Address des Absenders.


===  Router Advertisement ===
===  Router Advertisement ===
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 fuzzball, 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
 
Wir werden es hier nicht genauer besprechen, denn das haben wir in Abschnitt 5.1 Ein Präfix für den Link schon getan.
* Ein auffrischender Blick in das Paket wird aber sicher nicht schaden.
 
: Abbildung 5.14: SLAAC Paket 5: IPv6-Header


Nach dem Erhalt des Router Advertisements erzeugt lynx eine Global Unicast Address.
; Nach dem Erhalt des Router Advertisements erzeugt ''linux'' eine Global Unicast Address
* Dazu verwendet er das von fuzzball verteilte Präfix und den bereits vorhandenen Interface Identifier.
* Dazu verwendet er das von ''router'' verteilte Präfix und den bereits vorhandenen Interface Identifier


=== Multicast Listener Report (Solicited Node, Multicast-DNS) ===
=== Solicited Node ===
Auch für diese Adresse muss eine Duplicate Address Detection durchgeführt werden.
; Multicast Listener Report (Solicited Node)
* Die beginnt wieder mit dem Beitritt zu der passenden Multicast Group.
[[File:SLAAC-Paket5-IPv6-Header.png|mini|400px]]
* Obwohl sich die Solicited Node Multicast Address für die Global Unicast Address nicht von der für die Link-local Address unterscheidet, versendet lynx einen neuen Multicast Listener Report.
; Auch für diese Adresse muss eine Duplicate Address Detection durchgeführt werden
* Der wesentliche Unterschied ist die Quelladresse des Paketes, siehe auch Abbildung 5.14.
* 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.
[[File:SLAAC-Paket5MulticastListenerReport.png|mini|400px]]
* Der Rest des Paketes ist in Abbildung 5.15 dargestellt.
; 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


Unverändert geblieben ist der Beitritt zur Solicited Node Multicast Group, der erneut mithilfe von Changed to Exclude erreicht wurde.
=== Duplicate Address Detection (Global Unicast) ===
* Und einen weiteren Gruppenbeitritt können wir
[[IPv6/Autoconfiguration/DuplicateAddressDetection]]


: Abbildung 5.15 SLAAC Paket 5: Multicast Listener Report
=== 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


im Paket entdecken, der Beitritt zur Gruppe ff 2::fb.
; Da Echo Replies eintreffen, können wir davon ausgehen dass das Routing funktioniert
* Dies ist die Multicast DNS Address für die Verwendung mit IPv6, und für unser Netz nicht weiter wichtig.
Den Beweis können wir auch mit traceroute6 antreten:
user@linux:~ $ traceroute6 -n 2a01:198:200:a23::1


===  Duplicate Address Detection (Global Unicast) ===
An erster Stelle steht der nächste Hop, in unserem Fall die Adresse des Interfaces eth1 von router
Der letzte Schritt ist die Durchführung der Duplicate Address Detection für die Global Unicast Address.
* Schon in der zweiten Zeile ist das Ziel erreicht
* Dazu sendet lynx wieder eine Neighbor Solicitation, zu sehen in Abbildung 5.16, aus.


Mit dem Ausbleiben einer Antwort ist die Stateless Address Autoconfiguration abgeschlossen.
==  SLAAC unter Windows ==
* Das Interface eth0 ist nun fertig konfiguriert.
[[IPv6/Autoconfiguration/Windows]]


===  Konnektivitätstest ===
==  Eigene Untersuchungen ==
Einem Test der Konnektivität von lynx steht nun nichts mehr im Wege.
; Untersuchen Sie die einzelnen Pakete und finden Sie heraus, zu welchem Zweck jedes einzelne versendet wurde
* Dazu verschicken wir Echo Requests von lynx an den Tunnelendpunkt von SixXS:
* 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?


user@lynx :~ $ ping6 -c 3 2 a 1 :198:2 : a23 ::1
=== Ablaufverfolgung ===
PING 2 a 1 :198:2 : a23 ::1 (2 a 1 :198:2 : a23 ::1) 56 data '
'''Aufzeichnung einer Autoconfiguration mit Wireshark'''
bytes
64 bytes from 2 a 1 :198:2 : a23 ::1: icmp_seq =1 ttl =63 '
time =8. 2 ms
3 packets transmitted , 3 received , % packet loss , time '
2 3 ms


: Abbildung 5.16: SLAAC Paket 6: Neighbor Solicitation
Vom Hochfahren des Interfaces bis zu seiner endgültigen Konfiguration


Da Echo Replies eintreffen, können wir davon ausgehen dass das Routing funktioniert.
==== Interface herunterfahren ====
* Den Beweis können wir auch mit traceroute6 antreten:
# '''ip link set down dev enp2s0'''
  user@lynx :~ $ traceroute6 -n 2 a 1 :198:2 : a23 ::1
  2: enp2s0: <BROADCAST,MULTICAST> mtu 1500 qdisc pfifo_fast state '''DOWN''' group default qlen 1000
traceroute to 2 a 1 :198:2 : a23 ::1 (2 a 1 :198:2 : a23 ::1) , '
    link/ether 74:27:ea:e1:b2:b4 brd ff:ff:ff:ff:ff:ff
3 hops max , 8 byte packets
    inet 192.168.1.106/24 brd 192.168.1.255 scope global dynamic noprefixroute enp2s0
1 2 a 1 :198:2 :8 a23 ::1 2.2 4 ms
      valid_lft 4826sec preferred_lft 4826sec
.162 ms
.193 ms
2 2 a 1 :198:2 : a23 ::1 13.255 ms 13.412 ms 19.135 ms


An erster Stelle steht der nächste Hop, in unserem Fall die Adresse des Interfaces eth1 von fuzzball.
==== Wireshark starten  ====
* Schon in der zweiten Zeile ist das Ziel erreicht.
[[Wireshark]] starten
* auf PseudoInterface ''any'' lauschen


=== SLAAC unter Windows 8 ===
==== Interface starten ====
Nun werden wir die eben erworbenen Fähigkeiten zur Analyse einer Autoconfiguration auf felis anwenden.
# '''ip link set up dev enp2s0'''
* Bei dieser Gelegenheit werden wir auch Unterschiede entdecken, die durch Aktivierung von Privacy Extensions auftreten.
enp2s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state '''UP''' group default qlen 1000
* Dazu öffnen wir als Administrator ein Terminal und stellen sicher das die Privacy Extensions aktiviert sind.
    link/ether 74:27:ea:e1:b2:b4 brd ff:ff:ff:ff:ff:ff
* Nach dem Betätigen der Tastenkombination Windowstaste+X erscheint ein Menü in dem wir den Punkt Command Prompt (Admin) auswählen:
    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


: Abbildung 5.17 SLAAC unter Windows 8
==== Aktivität beobachten ====
  C :\ Users \ user > netsh interface ipv6 set global randomizeidentifiers = enabled
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:
Ok.
  # '''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


Leider kommt es unter Windows 8 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 felis kann er funktionieren oder auch nicht.
* Als Lösung bietet es sich an, den Verkehr von eth1 auf fuzzball mitzuschreiben, auch dort kommen die Pakete vorbei.
Sobald Wireshark bereit ist, deaktivieren wir die LAN-Verbindung auf felis und aktivieren sie anschließend wieder.
* Bei einer Beobachtung von fuzzball aus, können wir alternativ auch einen Neustart von felis durchführen.
* In beiden Fällen ergibt sich ein Mitschnitt, der dem aus Abbildung 5.17 ähnlich sieht.


===  Eigene Untersuchungen ===
<noinclude>
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?


: Abbildung 5.18: Interner Link mit DNS-Server
= Anhang =
=== Siehe auch ===
{{Special:PrefixIndex/{{BASEPAGENAME}}/}}
=== Links ===
==== Weblinks ====


[[Kategorie:IPv6/Adresse]]
[[Kategorie:IPv6/Link]]
[[Kategorie:IPv6/Link]]
</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
Prinzip SLAAC
  1. Host fragt mit einer Router Solicitation nach einem Router Advertisement
  2. Router verschickt das angeforderte Router Advertisement mit den relevanten Daten
  3. Host konfiguriert sein Interface
  4. 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)
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

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
Multicast Listener Report
  • 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)
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
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

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



Anhang

Siehe auch

Links

Weblinks

Abgerufen von „https://wiki.foxtom.de/index.php?title=IPv6/Autoconfiguration&oldid=146071“