IPv6/Router/Solicitation: Unterschied zwischen den Versionen
Keine Bearbeitungszusammenfassung |
Keine Bearbeitungszusammenfassung |
||
| (3 dazwischenliegende Versionen desselben Benutzers werden nicht angezeigt) | |||
| Zeile 1: | Zeile 1: | ||
'''Router Solicitation''' | '''IPv6/Router/Solicitation''' - Router Solicitation | ||
= | == Beschreibung == | ||
[[File:ipv6NeighborSolicitation.png|mini| | [[File:ipv6NeighborSolicitation.png|mini|500px]] | ||
Hat der betroffene Node wie gewünscht geantwortet stoppen wir die Aufzeichnung und schauen uns die Ergebnisse in Wireshark an | Hat der betroffene Node wie gewünscht geantwortet stoppen wir die Aufzeichnung und schauen uns die Ergebnisse in Wireshark an | ||
* Das erste Paket von Interesse ist eine Neighbor Solicitation genannte Nachricht (siehe Abbildung) | * Das erste Paket von Interesse ist eine Neighbor Solicitation genannte Nachricht (siehe Abbildung) | ||
| Zeile 18: | Zeile 18: | ||
Aber wie konnte das Paket überhaupt beim richtigen Node am Link landen, wo wir doch seine Link-layer Address noch nicht kennen? Die Lösung ist im IPv6-Header des Paketes versteckt und lautet Solicited Node Multicast Address | Aber wie konnte das Paket überhaupt beim richtigen Node am Link landen, wo wir doch seine Link-layer Address noch nicht kennen? Die Lösung ist im IPv6-Header des Paketes versteckt und lautet Solicited Node Multicast Address | ||
* Sie wird wie in Abbildung 4.7 dargestellt berechnet | * Sie wird wie in Abbildung 4.7 dargestellt berechnet | ||
<noinclude> | |||
== Anhang == | |||
=== Siehe auch === | |||
{{Special:PrefixIndex/{{BASEPAGENAME}}}} | |||
==== Dokumentation ==== | |||
===== RFC ===== | |||
{| class="wikitable sortable options" | |||
|- | |||
! RFC !! Titel | |||
|- | |||
| [https://www.rfc-editor.org/rfc/0000 0000] || | |||
|} | |||
===== Weblinks ===== | |||
[[Kategorie:IPv6/ICMP]] | [[Kategorie:IPv6/ICMP]] | ||
</noinclude> | |||
Aktuelle Version vom 9. November 2024, 11:22 Uhr
IPv6/Router/Solicitation - Router Solicitation
Beschreibung
Hat der betroffene Node wie gewünscht geantwortet stoppen wir die Aufzeichnung und schauen uns die Ergebnisse in Wireshark an
- Das erste Paket von Interesse ist eine Neighbor Solicitation genannte Nachricht (siehe Abbildung)
Da das Neighbor Discovery Protocol ein in ICMPv6 eingebettetes Protokoll ist, fängt der spannende Teil mit einem ICMPv6-Header an
- Der Nachrichtentyp hat die Nummer 135 und den Code 0
- Neben der Checksum und reservierten Bytes existiert ein weiteres Feld, die Target Address
- Sie enthält die aufzulösende IPv6-Adresse und gehört zum Ziel unseres Echo Requests
- Danach folgt eine ICMPv6-Option namens Source Link-layer Address
- Dabei handelt es sich um zusätzliche Informationen, die der Absender im Paket unterbringen kann
- Hier hat router die Link-layer Address seines Interfaces freundlicherweise im Paket vermerkt
- Der Gegenseite liefert er damit wertvolle Informationen für ihren eigenen Neighbor Cache
- Ganz nebenbei ersparen solche Zusatzinformationen dem Link das ein oder andere Paket
Aber wie konnte das Paket überhaupt beim richtigen Node am Link landen, wo wir doch seine Link-layer Address noch nicht kennen? Die Lösung ist im IPv6-Header des Paketes versteckt und lautet Solicited Node Multicast Address
- Sie wird wie in Abbildung 4.7 dargestellt berechnet
Anhang
Siehe auch
Dokumentation
RFC
| RFC | Titel |
|---|---|
| 0000 |
Weblinks