|
|
(120 dazwischenliegende Versionen desselben Benutzers werden nicht angezeigt) |
Zeile 1: |
Zeile 1: |
| '''{{BASEPAGENAME}}''' - '''S'''tate'''l'''ess '''A'''ddress '''A'''utoconfiguration (Automatische Konfiguration von IPv6-Adressen) | | '''IPv6/Autoconfiguration''' - Stateless Address Autoconfiguration (SLACC) |
|
| |
|
| == Beschreibung == | | == Beschreibung == |
| == Ablauf ==
| | Automatische Konfiguration von IPv6-Adressen |
| [[Datei:Prinzip SLAAC.png|mini|500px|Prinzip SLAAC]]
| | * Stateless Address Autoconfiguration |
| {| class="wikitable options col1center" | | |
| | ; Motivation |
| | Reduzierung von Abhängigkeiten |
| | * 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 |
| | |
| | ; Aufgaben |
| | {| class="wikitable options col1center " |
| |- | | |- |
| ! Aufgabe !! Beschreibung | | ! Aufgabe !! Beschreibung |
| |- | | |- |
| | 1 || Link-local Address generieren | | | 1 || [[Link-local Address]] generieren |
| |- | | |- |
| | 2 || Stateless Address Autoconfiguration | | | 2 || Autokonfiguration durchführen |
| |- | | |- |
| | 3 || Duplicate Address Detection | | | 3 || Duplicate Address Detection |
| |} | | |} |
|
| |
|
| # Den ersten Schritt macht der Host, indem er mittels Router Solicitation nach einem Router Advertisement fragt
| | ; Aressverwaltung |
| #* Alternativ könnte er auch ein periodisches Router Advertisement abwarten
| | Umgebungen mit zentraler Adressverwaltung verwenden [[DHCPv6]] |
| #* diese Geduld beobachtet man aber eher selten
| | * Simultaner Betrieb von [[DHCPv6]] und Stateless Address Autoconfiguration ist möglich |
| # Der Router verschickt das angeforderte Router Advertisement,welches alle konfigurationsrelevanten Daten enthält
| |
| # Daraufhin führt der Host die Konfiguration des Interfaces durch und 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
| |
|
| |
|
| == Duplicate Address Detection ==
| | ; Überblick |
| '''Duplicate Address Detection besteht aus mehrere [[Neighbor Solicitation]]s'''
| | [[Datei:Prinzip SLAAC.png|mini|500px|Prinzip SLAAC]] |
| * 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
| | # Host fragt mit einer [[Router Solicitation]] nach einem [[Router Advertisement]] |
| * Bleibt eine Antwort aus, benutzt offensichtlich kein anderer Node auf dem Link die überprüfte Adresse
| | # Router verschickt das angeforderte Router Advertisement mit den relevanten Daten |
| * Um Fehlschlüsse aufgrund von Paketverlusten zu vermeiden, sollen mehrere Neighbor Solicitations verschickt werden
| | # Host konfiguriert sein Interface |
| | | # Host prüft die Eindeutigkeit der selbst erzeugten Adressen |
| Ab wann eine Adresse als eindeutig gilt, hängt von den Parametern der jeweiligen Implementierung ab
| | <br clear=all> |
| * Jede Adresse hat anfangs den Status tentative (probeweise)
| | Wenn diese Eindeutigkeit angenommen werden kann, ist die Konfiguration des Interfaces vollständig und gilt als beendet |
| * 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)
| |
| | |
| == 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
| |
| | |
| == Autoconfiguration ==
| |
| ; SLAAC ist Bestandteil der Autoconfiguration, die drei wesentliche Aufgaben hat:
| |
| * Generieren einer Link-local Address
| |
| * Durchführen der Stateless Address Autoconfiguration
| |
| * Sicherstellen der Eindeutigkeit der generierten Adressen (Duplicate Address Detection)
| |
| * Damit reduziert IPv6 als Protokoll 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
| |
| * 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
| |
| * Aber auch ein simultaner Betrieb von DHCPv6 und Stateless Address Autoconfiguration wäre denkbar
| |
|
| |
|
| == Ablauf == | | == Ablauf == |
| [[Datei:Prinzip SLAAC.png|mini|400px|Prinzip SLAAC]] | | === Router Solicitation === |
| ; Den ersten Schritt macht der Host, indem er mittels Router Solicitation nach einem Router Advertisement fragt
| | Host fragt mit [[Router Solicitation]] ein [[Router Advertisement]] an |
| * Alternativ könnte er auch ein periodisches Router Advertisement abwarten, diese Geduld beobachtet man aber eher selten
| | * Router verschickt das angeforderte Router Advertisement |
| * Der Router verschickt das angeforderte Router Advertisement, welches alle konfigurationsrelevanten Daten enthält | | * enthält alle konfigurationsrelevanten Daten |
| ** 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
| |
| * Erst wenn diese Eindeutigkeit angenommen werden kann, ist die Konfiguration des Interfaces vollständig und gilt als beendet
| |
| | |
| === Duplicate Address Detection ===
| |
| ; Hinter der Duplicate Address Detection verbergen sich mehrere Neighbor Solicitations
| |
| * 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
| |
| * 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 ===
| |
| ; Mitschnitt einer komplette Autoconfiguration von ''linux'' mit Wireshark
| |
| * Vom Hochfahren des Interfaces bis zu seiner endgültigen Konfiguration
| |
| Dazu öffnen wir ein root-Terminal auf ''linux'' und fahren das Interface eth0 herunter:
| |
| root@linux:~# ip link set down dev eth
| |
| | |
| ; Nun starten wir Wireshark und lassen ihn auf dem PseudoInterface any lauschen
| |
| Danach fahren wir eth0 wieder hoch:
| |
| root@linux:~# ip link set up dev eth
| |
| | |
| ; 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:
| |
| user@linux:~ $ ip addr show dev eth
| |
| | |
| Wireshark kann jetzt den Mitschnitt beenden
| |
| * Von den vielen Paketen, die wir mitgeschnitten haben, sind nicht alle von Interesse
| |
| | |
| ; Multicast DNS
| |
| Insbesondere die Pakete vom Typ Multicast DNS (mDNS) werden wir an dieser Stelle ignorieren
| |
| * Multicast DNS erlaubt die Auflösung von Namen der Domain .local zu Linklocal Addresses
| |
| * 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. (https://www.multicastdns.org/)
| |
| | |
| === Multicast Listener Report (Solicited Node) ===
| |
| ; Das erste interessante Paket im Mitschnitt ist ein Multicast Listener Report und wurde von ''linux'' verschickt
| |
| * Der IPv6-Header ist in Abbildung 5.10 zu sehen
| |
| | |
| : Abbildung 5.10 SLAAC Paket 1: IPv6-Header
| |
| | |
| ; 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
| |
| * Zu finden auch in der Tabelle 4.5 in Abschnitt 4.5 Multicast
| |
| * Uns fällt das für MLDv2 Messages typische Hop Limit von 1 auf
| |
| * Bemerkenswert ist auch der Einsatz des Hop-by-Hop Options Extension Headers
| |
| * 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
| |
| * Wir haben in Abschnitt 4.5 Multicast bereits besprochen wie dieser Typ zu interpretieren ist
| |
| * Hier wird die Multicast Address ff 2::1:ff6 :d1e für alle potentiellen Multicast-Quellen freigegeben
| |
| * Die Nachricht entspricht dem Beitritt zur Multicast Group ff 2::1:ff6 :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
| |
| | |
| : Abbildung 5.11 SLAAC Paket 1:Multicast Listener Report
| |
| | |
| ; 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 wäre allerdings auch möglich, dass ein anderer Node eine ähnliche Adresse verwendet
| |
| * 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 ''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 (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
| |
| | |
| : Abbildung 5.12: SLAAC Paket 2: Neighbor Solicitation
| |
| | |
| ; 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 (siehe Abbildung 5.12)
| |
|
| |
|
| ; Als Quelladresse wählt er wieder die Unspecified Address, da die Link-local Address noch nicht als eindeutig gilt | | ; Konfiguration des Interfaces |
| * Die Neighbor Solicitation geht an die Solicited Node Multicast Address der zu überprüfenden Link-local Address | | Daraufhin führt der Host die Konfiguration des Interfaces durch |
| * Im Feld Target Address taucht die gewünschte Adresse fe8 ::2 :ff:fe6 :d1e schließlich auf
| | * 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 |
|
| |
|
| ; Das Ausbleiben eines Neighbor Advertisements wertet der Node als Anzeichen für die Eindeutigkeit seiner Adresse auf dem Link | | ; Router Solicitation |
| * Sie wird dann dem Interface zugewiesen und gilt fortan als valid
| | [[File:SLAAC-Paket3RouterSolicitation.png|mini|400px|Router Solicitation]] |
| | | ; Adresse für den Global Scope |
| === Router Solicitation ===
| | Nachdem ''client'' nun eine gültige Link-local Address hat, versucht er auch eine gültige Adresse für den Global Scope zu erhalten |
| ; 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 Router Solicitation, die in Abbildung 5.13 zu sehen ist | | * 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 |
| | |
| ; 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'' ff 2::2 verwendet, die wir schon in der Tabelle 4.5 in Abschnitt 4.5 Multicast gesehen haben | | * 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 |
|
| |
|
| === 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 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 |
|
| |
|
| ; Wir werden es hier nicht genauer besprechen, denn das haben wir in Abschnitt 5.1 Ein Präfix für den Link schon getan
| | Nach dem Erhalt des Router Advertisements erzeugt ''client'' eine Global Unicast Address |
| * 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 ''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 |
|
| |
|
| === Multicast Listener Report (Solicited Node, Multicast-DNS) === | | === Duplicate Address Detection === |
| ; Auch für diese Adresse muss eine Duplicate Address Detection durchgeführt werden
| | ; Duplicate Address Detection (Global Unicast) |
| * Die beginnt wieder mit dem Beitritt zu der passenden Multicast Group
| | [[IPv6/Autoconfiguration/DuplicateAddressDetection]] |
| * 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, siehe auch Abbildung 5.14
| |
| | |
| ; Anstatt der Unspecified Address kommt diesmal die Link-local Address zum Einsatz
| |
| * Der Rest des Paketes ist in Abbildung 5.15 dargestellt
| |
| | |
| ; 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 ff 2::fb
| |
| * Dies ist die Multicast DNS Address für die Verwendung mit IPv6, und für unser Netz nicht weiter wichtig
| |
| | |
| : Abbildung 5.15 SLAAC Paket 5: Multicast Listener Report
| |
| | |
| === Duplicate Address Detection (Global Unicast) === | |
| ; Der letzte Schritt ist die Durchführung der Duplicate Address Detection für die Global Unicast Address
| |
| * Dazu sendet ''linux'' wieder eine Neighbor Solicitation, zu sehen in Abbildung 5.16, aus
| |
| | |
| ; Mit dem Ausbleiben einer Antwort ist die Stateless Address Autoconfiguration abgeschlossen
| |
| * Das Interface eth0 ist nun fertig konfiguriert
| |
|
| |
|
| === Konnektivitätstest === | | === Test === |
| ; Einem Test der Konnektivität von ''linux'' steht nun nichts mehr im Wege
| | Einem Test der Konnektivität von ''client'' steht nun nichts mehr im Wege |
| Dazu verschicken wir Echo Requests von ''linux'' an den Tunnelendpunkt des Tunnelbrokers:
| |
| user@linux:~ $ ping6 -c 3 2 a 1 :198:2 : a23 ::1
| |
| PING 2 a 1 :198:2 : a23 ::1 (2 a 1 :198:2 : a23 ::1) 56 data 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 | | Dazu verschicken wir Echo Requests von ''client'' an den Tunnelendpunkt des Tunnelbrokers |
| | <syntaxhighlight lang="bash" highlight="1" line copy> |
| | ping6 -c 3 2a01:198:200:a23::1 |
| | </syntaxhighlight> |
|
| |
|
| ; 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 2 a 1 :198:2 : a23 ::1
| | <syntaxhighlight lang="bash" highlight="1" line copy> |
| traceroute to 2 a 1 :198:2 : a23 ::1 (2 a 1 :198:2 : a23 ::1) 3 hops max , 8 byte packets
| | traceroute6 -n 2a01:198:200:a23::1 |
| 1 2 a 1 :198:2 :8 a23 ::1 2.2 4 ms 162 ms 193 ms
| | </syntaxhighlight> |
| 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 router
| | 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 ===
| |
| ; 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 das die Privacy Extensions aktiviert sind
| |
| * Nach dem Betätigen der Tastenkombination Windowstaste+X erscheint ein Menü in dem wir den Punkt Command Prompt (Admin) auswählen:
| |
|
| |
| : Abbildung 5.17 SLAAC unter Windows
| |
| C:\Users\user> '''netsh interface ipv6 set global randomizeidentifiers = enabled'''
| |
| Ok
| |
|
| |
| ; 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 felis 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 felis und aktivieren sie anschließend wieder
| |
| * Bei einer Beobachtung von ''router'' 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 ===
| |
| ; 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
| |
|
| |
| '''Stateless Address Autoconfiguration''' (SLAAC) - Automatische Konfiguration von IPv6-Adressen
| |
|
| |
| == Autoconfiguration ==
| |
| ; SLAAC ist Bestandteil der Autoconfiguration, die drei wesentliche Aufgaben hat
| |
| # Generieren einer Link-local Address
| |
| # Durchführen der Stateless Address Autoconfiguration
| |
| # Sicherstellen der Eindeutigkeit der generierten Adressen (Duplicate Address Detection)
| |
|
| |
| === Ablauf ===
| |
| [[Datei:Prinzip SLAAC.png|mini|500px|Prinzip SLAAC]]
| |
| # Den ersten Schritt macht der Host, indem er mittels Router Solicitation nach einem Router Advertisement fragt
| |
| ## 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
| |
| # Daraufhin führt der Host die Konfiguration des Interfaces durch und 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
| |
|
| |
| == Duplicate Address Detection ==
| |
| ; Duplicate Address Detection besteht aus mehrere Neighbor Solicitations
| |
| * 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
| |
| * 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)
| |
|
| |
| === Ablaufverfolgung ===
| |
| ; Ziel
| |
| * Komplette Aufzeichnung der 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
| |
|
| |
| $ ssh -X root@localhost
| |
| root@localhost's password:
| |
|
| |
| # wireshark&
| |
|
| |
| === 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
| |
|
| |
| == Automatische Konfiguration ==
| |
|
| |
| === Stateless Auto-Konfiguration (out-of-the-box) ===
| |
| Wird unterstützt und kann bei der zugewiesenen link-lokalen Adressen beobachtet werden, sobald ein IPv6 fähiges Interface aktiv ist
| |
|
| |
| Beispiel:
| |
|
| |
|
| |
| === Stateless Auto-Konfiguration unter Verwendung des Router Advertisement Daemon (radvd) ===
| |
| Mehr Infos hierzu in späteren Versionen. Siehe unten im Abschnitt radvd daemon autoconfiguration
| |
|
| |
| === Dynamic Host Configuration Protocol v6 (DHCPv6) ===
| |
| Nach einer langen Zeit der Diskussion wurde <nowiki>RFC 3315</nowiki> / Dynamic Host Configuration Protocol for IPv6 (DHCPv6) verabschiedet. Momentan (10/2005) existieren 2 Implementierungen:
| |
|
| |
| * Dibbler von Tomasz Mrugalski <thomson at klub dot com dot pl>(Tipps zur Konfiguration)
| |
| * dhcpv6 (Tipps zur Konfiguration)
| |
| * ISC DHCP (Tipps zur Konfiguration)
| |
|
| |
|
| <noinclude> | | <noinclude> |
Zeile 366: |
Zeile 97: |
| ==== Weblinks ==== | | ==== Weblinks ==== |
|
| |
|
| [[Kategorie:IPv6/Adresse]] | | [[Kategorie:IPv6/Autoconfiguration]] |
| [[Kategorie:IPv6/Link]]
| | |
| </noinclude> | | </noinclude> |