|
|
| (257 dazwischenliegende Versionen desselben Benutzers werden nicht angezeigt) |
| Zeile 1: |
Zeile 1: |
| === Stateless Address Autoconfiguration ===
| | '''IPv6/Autoconfiguration''' - Stateless Address Autoconfiguration (SLACC) |
| ==== 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.
| | Automatische Konfiguration von IPv6-Adressen |
| * Damit einher geht der Verlust einer strengen Zuordnung von Adressen zu bestimmten Hosts.
| | * Stateless Address Autoconfiguration |
| * 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.
| |
|
| |
|
| ==== Autoconfiguration ====
| | ; Motivation |
| SLAAC ist Bestandteil der Autoconfiguration, die drei wesentliche Aufgaben hat: | | Reduzierung von Abhängigkeiten |
| * Generieren einer Link-local Address
| | * SLAAC reduziert IPv6 die Abhängigkeit von dritten Komponenten zur Organisation des Links |
| * Durchführen der Stateless Address Autoconfiguration | | * Die Nutzung von Stateless Address Autoconfiguration erfordert keine manuelle Konfiguration der Hosts und nur sehr wenige Konfigurationsschritte auf dem Router |
| * Sicherstellen der Eindeutigkeit der generierten Adressen (Duplicate Address Detection) | | * Damit einher geht der Verlust einer strengen Zuordnung von Adressen zu bestimmten Hosts |
|
| |
|
| ==== Prinzipieller Ablauf ==== | | ; Aufgaben |
| : Abbildung 5.9 Prinzip von SLAAC
| | {| class="wikitable options col1center " |
| | |- |
| | ! Aufgabe !! Beschreibung |
| | |- |
| | | 1 || [[Link-local Address]] generieren |
| | |- |
| | | 2 || Autokonfiguration durchführen |
| | |- |
| | | 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, diese Geduld beobachtet man aber eher selten. | | Umgebungen mit zentraler Adressverwaltung verwenden [[DHCPv6]] |
| Der Router verschickt das angeforderte Router Advertisement, welches alle konfigurationsrelevanten Daten enthält (Wir gehen der Einfachheit halber von nur einem Router aus.)
| | * Simultaner Betrieb von [[DHCPv6]] und Stateless Address Autoconfiguration ist möglich |
|
| |
|
| Daraufhin führt der Host die Konfiguration des Interfaces durch und prüft die Eindeutigkeit der selbst erzeugten Adressen.
| | ; Überblick |
| * Erst wenn diese Eindeutigkeit angenommen werden kann, ist die Konfiguration des Interfaces vollständig und gilt als beendet.
| | [[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 |
|
| |
|
| ==== Duplicate Address Detection ==== | | == Ablauf == |
| Hinter der Duplicate Address Detection verbergen sich eigentlich mehrere Neighbor Solicitations.
| | === Router Solicitation === |
| * 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 [[Router Solicitation]] ein [[Router Advertisement]] an |
| * Bleibt eine Antwort aus, benutzt offensichtlich kein anderer Node auf dem Link die überprüfte Adresse. | | * Router verschickt das angeforderte Router Advertisement |
| * Um Fehlschlüsse aufgrund von Paketverlusten zu vermeiden, sollen mehrere Neighbor Solicitations verschickt werden.
| | * enthält alle konfigurationsrelevanten Daten |
| 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 ====
| | ; Konfiguration des Interfaces |
| Wir werden versuchen eine komplette Autoconfiguration von lynx mit Wireshark aufzufangen.
| | Daraufhin führt der Host die Konfiguration des Interfaces durch |
| * Vom Hochfahren des Interfaces bis zu seiner endgültigen Konfiguration. | | * prüft die Eindeutigkeit der selbst erzeugten Adressen |
| Dazu öffnen wir ein root-Terminal auf lynx und fahren das Interface eth0 herunter:
| | Erst wenn diese Eindeutigkeit angenommen werden kann, ist die Konfiguration des Interfaces vollständig und gilt als beendet |
| root@lynx :~# ip link set down dev eth
| |
|
| |
|
| Nun starten wir Wireshark und lassen ihn auf dem PseudoInterface any lauschen.
| | ; Router Solicitation |
| Danach fahren wir eth0 wieder hoch:
| | [[File:SLAAC-Paket3RouterSolicitation.png|mini|400px|Router Solicitation]] |
| root@lynx :~# ip link set up dev eth
| | ; Adresse für den Global Scope |
| | Nachdem ''client'' 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 |
|
| |
|
| In Wireshark können wir bereits Aktivität beobachten.
| | Die Nachricht wird von der Link-local Address des Hosts gesendet |
| * Wir warten den Abschluss der Konfiguration ab, sie ist erfolgreich verlaufen wenn wir Adressen mit den Parametern scope global und dynamic sehen:
| | Hier von der Adresse |
| user@lynx :~ $ ip addr show dev eth
| | fe80::200:ff:fe6:d1e |
| 2: eth : < BROADCAST , MULTICAST ,UP , LOWER_UP > mtu 15 qdisc pfifo_fast state UP qlen 1
| | * Als Zieladresse wird die ''All Routers Multicast Address'' ff02::2 verwendet |
| 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 | | * Angehängt an die Router Solicitation ist, eine ICMPv6-Option mit der Link-layer Address des Absenders |
|
| |
|
| Wireshark kann jetzt den Mitschnitt beenden.
| | === Router Advertisement === |
| * Von den vielen Paketen die wir mitgeschnitten haben sind nicht alle von Interesse. | | 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 |
|
| |
|
| ==== Multicast DNS ====
| | Nach dem Erhalt des Router Advertisements erzeugt ''client'' eine Global Unicast Address |
| Insbesondere die Pakete vom Typ Multicast DNS (mDNS) werden wir an dieser Stelle ignorieren.
| | * Dazu verwendet er das von ''router'' verteilte Präfix und den bereits vorhandenen Interface Identifier |
| * 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. (http://www.multicastdns.org/)
| |
|
| |
|
| ==== Multicast Listener Report (Solicited Node) ==== | | === Duplicate Address Detection === |
| Das erste interessante Paket im Mitschnitt ist ein Multicast Listener Report und wurde von lynx verschickt.
| | ; Duplicate Address Detection (Global Unicast) |
| * Der IPv6-Header ist in Abbildung 5.10 zu sehen.
| | [[IPv6/Autoconfiguration/DuplicateAddressDetection]] |
|
| |
|
| : Abbildung 5.10 SLAAC Paket 1: IPv6-Header
| | === Test === |
| | Einem Test der Konnektivität von ''client'' steht nun nichts mehr im Wege |
|
| |
|
| Als Quelladresse hat lynx die Unspecified Address gewählt.
| | Dazu verschicken wir Echo Requests von ''client'' an den Tunnelendpunkt des Tunnelbrokers |
| Das heißt, zum Zeitpunkt des Versendens stand keine passende, gültige Adresse zur Verfügung.
| | <syntaxhighlight lang="bash" highlight="1" line copy> |
| * Die Zieladresse ist die Multicast Address für alle MLDv2-fähigen Router.
| | ping6 -c 3 2a01:198:200:a23::1 |
| * Zu finden auch in der Tabelle 4.5 in Abschnitt 4.5 Multicast.
| | </syntaxhighlight> |
| * 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.
| | ; Da Echo Replies eintreffen, können wir davon ausgehen dass das Routing funktioniert |
| * Wir haben in Abschnitt 4.5 Multicast bereits besprochen wie dieser Typ zu interpretieren ist.
| | Den Beweis können wir auch mit traceroute6 antreten: |
| * Hier wird die Multicast Address ff 2::1:ff6 :d1e für alle potentiellen Multicast-Quellen freigegeben.
| | <syntaxhighlight lang="bash" highlight="1" line copy> |
| * Die Nachricht entspricht dem Beitritt zur Multicast Group ff 2::1:ff6 :d1e.
| | traceroute6 -n 2a01:198:200:a23::1 |
| * Es handelt sich dabei um die Solicited Node Multicast Address von Interface eth0 auf lynx.
| | </syntaxhighlight> |
|
| |
|
| ==== Gruppenbeitritt ====
| | An erster Stelle steht der nächste Hop, in unserem Fall die Adresse des Interfaces eth1 von router |
| Zu diesem Zeitpunkt hat lynx also bereits einen Interface Identifier erzeugt.
| | * Schon in der zweiten Zeile ist das Ziel erreicht |
| * 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.
| | <noinclude> |
| * 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 ==== | | = Anhang = |
| Es wäre allerdings auch möglich, dass ein anderer Node eine ähnliche Adresse verwendet.
| | === Siehe auch === |
| * Beispielsweise eine Adresse bei der sich die letzten 24 Bits gleichen.
| | {{Special:PrefixIndex/{{BASEPAGENAME}}/}} |
| * Beide Nodes wären nun in derselben Gruppe, jene mit der gemeinsamen Solicited Node Multicast Address.
| | === Links === |
| * 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.
| | ==== Weblinks ==== |
| * 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) ====
| | [[Kategorie:IPv6/Autoconfiguration]] |
| 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
| | </noinclude> |
| | |
| 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 ====
| |
| Nachdem lynx 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 Router
| |
| | |
| : Abbildung 5.13: SLAAC Paket 3: Router Solicitation
| |
| | |
| Advertisement zukommen.
| |
| * Die Anforderung der Router Advertisements geschieht mit Hilfe einer Router Solicitation, die in Abbildung 5.13 zu sehen ist.
| |
| | |
| 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 ====
| |
| 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.
| |
| | |
| 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.
| |
| * Dazu verwendet er das von fuzzball verteilte Präfix und den bereits vorhandenen Interface Identifier.
| |
| | |
| ==== Multicast Listener Report (Solicited Node, Multicast-DNS) ====
| |
| 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 lynx 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
| |
| | |
| : Abbildung 5.15 SLAAC Paket 5: Multicast Listener Report
| |
| | |
| 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.
| |
| | |
| ==== Duplicate Address Detection (Global Unicast) ====
| |
| Der letzte Schritt ist die Durchführung der Duplicate Address Detection für die Global Unicast Address.
| |
| * 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.
| |
| * Das Interface eth0 ist nun fertig konfiguriert.
| |
| | |
| ==== Konnektivitätstest ====
| |
| Einem Test der Konnektivität von lynx steht nun nichts mehr im Wege.
| |
| * Dazu verschicken wir Echo Requests von lynx an den Tunnelendpunkt von SixXS:
| |
| | |
| user@lynx :~ $ 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
| |
| | |
| Da Echo Replies eintreffen, können wir davon ausgehen dass das Routing funktioniert.
| |
| * Den Beweis können wir auch mit traceroute6 antreten:
| |
| user@lynx :~ $ traceroute6 -n 2 a 1 :198:2 : a23 ::1
| |
| traceroute to 2 a 1 :198:2 : a23 ::1 (2 a 1 :198:2 : a23 ::1) , '
| |
| 3 hops max , 8 byte packets
| |
| 1 2 a 1 :198:2 :8 a23 ::1 2.2 4 ms
| |
| .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.
| |
| * Schon in der zweiten Zeile ist das Ziel erreicht.
| |
| | |
| ==== SLAAC unter Windows 8 ====
| |
| Nun werden wir die eben erworbenen Fähigkeiten zur Analyse einer Autoconfiguration auf felis anwenden.
| |
| * 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 8
| |
| C :\ Users \ user > netsh interface ipv6 set global randomizeidentifiers = enabled
| |
| Ok.
| |
| | |
| 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 ====
| |
| 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
| |
| | |
| [[Kategorie:IPv6]]
| |
