IPv6/SLAAC: Unterschied zwischen den Versionen
K Textersetzung - „fuzzball“ durch „router“ |
|||
(107 dazwischenliegende Versionen desselben Benutzers werden nicht angezeigt) | |||
Zeile 1: | Zeile 1: | ||
'''SLAAC''' - | '''S'''tate'''l'''ess '''A'''ddress '''A'''utoconfiguration ('''SLAAC''') - Automatische Konfiguration von IPv6-Adressen | ||
== Beschreibung == | |||
== Ablauf == | |||
[[Datei:Prinzip SLAAC.png|mini|400px|Prinzip SLAAC]] | |||
{| class="wikitable options col1center" | |||
|- | |||
! Aufgabe !! Beschreibung | |||
|- | |||
| 1 || Link-local Address generieren | |||
|- | |||
| 2 || Stateless Address Autoconfiguration | |||
|- | |||
| 3 || Duplicate Address Detection | |||
|} | |||
=== Autoconfiguration | # 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 Solicitation]]s''' | |||
* 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 == | |||
'''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: | ; SLAAC ist Bestandteil der Autoconfiguration, die drei wesentliche Aufgaben hat: | ||
* Generieren einer Link-local Address | * Generieren einer Link-local Address | ||
* Durchführen der Stateless Address Autoconfiguration | * Durchführen der Stateless Address Autoconfiguration | ||
* Sicherstellen der Eindeutigkeit der generierten Adressen (Duplicate Address Detection) | * 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 == | ||
: | [[Datei:Prinzip SLAAC.png|mini|400px|Prinzip SLAAC]] | ||
; Den ersten Schritt macht der Host, indem er mittels Router Solicitation nach einem Router Advertisement fragt | |||
; 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 | ||
* 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 | ||
; Daraufhin führt der Host die Konfiguration des Interfaces durch und prüft die Eindeutigkeit der selbst erzeugten Adressen | ; 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 | ||
=== Duplicate Address Detection === | === Duplicate Address Detection === | ||
; Hinter der Duplicate Address Detection verbergen sich | ; 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 | * 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 | * 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 | * 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 | ; Ab wann eine Adresse als eindeutig gilt, hängt von den Parametern der jeweiligen Implementierung ab | ||
* Jede Adresse hat anfangs den Status tentative (probeweise) | * 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) | * 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 === | === Autoconfiguration mitschneiden === | ||
; | ; Mitschnitt einer komplette Autoconfiguration von ''linux'' mit Wireshark | ||
* Vom Hochfahren des Interfaces bis zu seiner endgültigen Konfiguration | * Vom Hochfahren des Interfaces bis zu seiner endgültigen Konfiguration | ||
Dazu öffnen wir ein root-Terminal auf | Dazu öffnen wir ein root-Terminal auf ''linux'' und fahren das Interface eth0 herunter: | ||
root@ | root@linux:~# ip link set down dev eth | ||
Nun starten wir Wireshark und lassen ihn auf dem PseudoInterface any lauschen | ; Nun starten wir Wireshark und lassen ihn auf dem PseudoInterface any lauschen | ||
Danach fahren wir eth0 wieder hoch: | Danach fahren wir eth0 wieder hoch: | ||
root@ | root@linux:~# ip link set up dev eth | ||
In Wireshark können wir bereits 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: | |||
user@ | user@linux:~ $ ip addr show dev eth | ||
2: eth : < BROADCAST , MULTICAST ,UP , LOWER_UP > mtu 15 qdisc pfifo_fast state UP qlen 1 | 2: eth : < BROADCAST , MULTICAST ,UP , LOWER_UP > mtu 15 qdisc pfifo_fast state UP qlen 1 | ||
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 | 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 | ||
Wireshark kann jetzt den Mitschnitt beenden | Wireshark kann jetzt den Mitschnitt beenden | ||
* Von den vielen Paketen die wir mitgeschnitten haben sind nicht alle von Interesse | * 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 | * Multicast DNS erlaubt die Auflösung von Namen der Domain .local zu Linklocal Addresses | ||
* Leider belastet es dazu den Link ungefragt mit allerlei Paketen | * 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 | * 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/) | * 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) === | === Multicast Listener Report (Solicited Node) === | ||
; Das erste interessante Paket im Mitschnitt ist ein Multicast Listener Report und wurde von | ; 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 | * Der IPv6-Header ist in Abbildung 5.10 zu sehen | ||
: Abbildung 5.10 SLAAC Paket 1: IPv6-Header | : Abbildung 5.10 SLAAC Paket 1: IPv6-Header | ||
; Als Quelladresse hat | ; 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 | ||
* Zu finden auch in der Tabelle 4.5 in Abschnitt 4.5 Multicast | * 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 | * 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 | * 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 | * 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 | * 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 | * 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 | * Die MLDv2 Message kann in Abbildung 5.11 eingesehen werden | ||
; Genaugenommen handelt sich um eine MLDv2 Message der Art Changed to Exclude | ; 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 | * 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 | * 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 | * 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 | * Es handelt sich dabei um die Solicited Node Multicast Address von Interface eth0 auf ''linux'' | ||
=== Gruppenbeitritt === | === Gruppenbeitritt === | ||
; Zu diesem Zeitpunkt hat | ; 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 | * Der Beitritt zur entsprechenden Multicast Group gewährt ihm Zugang zu den Paketen dieser Gruppe | ||
: Abbildung 5.11 SLAAC Paket 1:Multicast Listener Report | : 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 | ; 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 | * 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 wäre allerdings auch möglich, dass ein anderer Node eine ähnliche Adresse verwendet | ; 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 | * 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ä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 | * 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 | * Jeder Node muss deshalb prüfen, ob ein Paket, welches an die Gruppe adressiert wurde, auch wirklich für ihn von Belang ist | ||
* Auch | * 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) === | === Duplicate Address Detection (Link-local) === | ||
; Möchte | ; 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 | * 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 | : Abbildung 5.12: SLAAC Paket 2: Neighbor Solicitation | ||
; 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 | * 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 | ; 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 fe8 ::2 :ff:fe6 :d1e schließlich auf | * 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 | ; 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 | ; 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, die in Abbildung 5.13 zu sehen ist | ||
: Abbildung 5.13: SLAAC Paket 3: 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 | ||
* 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 | Hier von der Adresse | ||
* Angehängt an die Router Solicitation ist, eine ICMPv6-Option mit der Link-layer Address des Absenders | 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 | |||
* 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 | * 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 | ; 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 | * Ein auffrischender Blick in das Paket wird aber sicher nicht schaden | ||
: Abbildung 5.14: SLAAC Paket 5: IPv6-Header | : Abbildung 5.14: SLAAC Paket 5: IPv6-Header | ||
; Nach dem Erhalt des Router Advertisements erzeugt | ; Nach dem Erhalt des Router Advertisements erzeugt ''linux'' eine Global Unicast Address | ||
* Dazu verwendet er das von | * Dazu verwendet er das von ''router'' verteilte Präfix und den bereits vorhandenen Interface Identifier | ||
=== Multicast Listener Report (Solicited Node, Multicast-DNS) === | === Multicast Listener Report (Solicited Node, Multicast-DNS) === | ||
; 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 | * 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 | * 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 | ; Anstatt der Unspecified Address kommt diesmal die Link-local Address zum Einsatz | ||
* Der Rest des Paketes ist in Abbildung 5.15 dargestellt | * 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 | ; 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 | * 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 | * 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 | : Abbildung 5.15 SLAAC Paket 5: Multicast Listener Report | ||
=== Duplicate Address Detection (Global Unicast) === | === Duplicate Address Detection (Global Unicast) === | ||
; Der letzte Schritt ist die Durchführung der Duplicate Address Detection für die Global Unicast Address | ; Der letzte Schritt ist die Durchführung der Duplicate Address Detection für die Global Unicast Address | ||
* Dazu sendet | * 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 | ; Mit dem Ausbleiben einer Antwort ist die Stateless Address Autoconfiguration abgeschlossen | ||
* Das Interface eth0 ist nun fertig konfiguriert | * Das Interface eth0 ist nun fertig konfiguriert | ||
=== Konnektivitätstest === | === Konnektivitätstest === | ||
; Einem Test der Konnektivität von | ; Einem Test der Konnektivität von ''linux'' steht nun nichts mehr im Wege | ||
Dazu verschicken wir Echo Requests von | Dazu verschicken wir Echo Requests von ''linux'' an den Tunnelendpunkt des Tunnelbrokers: | ||
user@linux:~ $ ping6 -c 3 2 a 1 :198:2 : a23 ::1 | |||
user@ | PING 2 a 1 :198:2 : a23 ::1 (2 a 1 :198:2 : a23 ::1) 56 data bytes | ||
PING 2 a 1 :198:2 : a23 ::1 (2 a 1 :198:2 : a23 ::1) 56 data | 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 | |||
64 bytes from 2 a 1 :198:2 : a23 ::1: icmp_seq =1 ttl =63 | |||
3 packets transmitted , 3 received , % packet loss , time | |||
: Abbildung 5.16: SLAAC Paket 6: Neighbor Solicitation | : Abbildung 5.16: SLAAC Paket 6: Neighbor Solicitation | ||
; 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: | |||
user@ | user@linux:~ $ 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) | 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 | |||
1 2 a 1 :198:2 :8 a23 ::1 2.2 4 ms | |||
2 2 a 1 :198:2 : a23 ::1 13.255 ms 13.412 ms 19.135 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 | ; 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 | === SLAAC unter Windows === | ||
; Analyse einer Autoconfiguration unter Windows | |||
* Bei dieser Gelegenheit werden wir auch Unterschiede entdecken, die durch Aktivierung von Privacy Extensions auftreten | * 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 | * 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: | * 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 | : Abbildung 5.17 SLAAC unter Windows | ||
C :\ Users \ user > netsh interface ipv6 set global randomizeidentifiers = enabled | C:\Users\user> '''netsh interface ipv6 set global randomizeidentifiers = enabled''' | ||
Ok | Ok | ||
Leider kommt es unter Windows | ; Leider kommt es unter Windows beim Betrieb von Wireshark manchmal zu Problemen | ||
* Der benötigte Treiber zum Mitschnitt von Daten heißt Windows Packet Capture (WinPcap), je nach Update-Stand von felis kann er funktionieren oder auch nicht | * 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 | * 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 | Sobald Wireshark bereit ist, deaktivieren wir die LAN-Verbindung auf felis und aktivieren sie anschließend wieder | ||
* Bei einer Beobachtung von | * 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 | * In beiden Fällen ergibt sich ein Mitschnitt, der dem aus Abbildung 5.17 ähnlich sieht | ||
=== Eigene Untersuchungen === | === 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 | * Sie können sich dabei auf ICMPv6 beschränken und auch die Teile von MLDv2, die sich um Multicast DNS drehen, ignorieren | ||
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? | |||
: Abbildung 5.18: Interner Link mit DNS-Server | : 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> | |||
= Anhang = | |||
=== Siehe auch === | |||
{{Special:PrefixIndex/{{BASEPAGENAME}}}} | |||
==== Links ==== | |||
===== Weblinks ===== | |||
[[Kategorie:IPv6/Adresse]] | |||
[[Kategorie:IPv6/Link]] | [[Kategorie:IPv6/Link]] | ||
</noinclude> |
Aktuelle Version vom 22. Januar 2024, 14:44 Uhr
Stateless Address Autoconfiguration (SLAAC) - Automatische Konfiguration von IPv6-Adressen
Beschreibung
Ablauf
Aufgabe | Beschreibung |
---|---|
1 | Link-local Address generieren |
2 | Stateless Address Autoconfiguration |
3 | Duplicate Address Detection |
- 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
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
- 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
- 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 2: eth : < BROADCAST , MULTICAST ,UP , LOWER_UP > mtu 15 qdisc pfifo_fast state UP qlen 1 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
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. (http://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
- 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 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 in Abbildung 5.13 zu sehen ist
- Abbildung 5.13: SLAAC Paket 3: 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 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 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 linux eine Global Unicast Address
- Dazu verwendet er das von router 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 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
- 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 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@linux:~ $ 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 router
- Schon in der zweiten Zeile ist das Ziel erreicht
SLAAC unter Windows
- Analyse einer Autoconfiguration unter Windows
- Bei dieser Gelegenheit werden wir auch Unterschiede entdecken, die durch Aktivierung von Privacy Extensions auftreten
- Dazu öffnen wir als Administrator ein Terminal und stellen sicher 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
- 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 RFC 3315 / 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)