IPv6/ICMPv6/Nachrichten: Unterschied zwischen den Versionen
Die Seite wurde neu angelegt: „== Fehlernachrichten == {| class="wikitable big options col1center" ! class="hintergrundfarbe6"| Type ! class="hintergrundfarbe6"| Beschreibung ! class="hintergrundfarbe6"| RFC |- |1 || Destination Unreachable ||[https://www.rfc-editor.org/rfc/4443 RFC 4443] |- |2 || Packet Too Big ||[https://www.rfc-editor.org/rfc/4443 RFC 4443] |- |3 || Time Exceeded ||[https://www.rfc-editor.org/rfc/44…“ |
Keine Bearbeitungszusammenfassung |
||
Zeile 122: | Zeile 122: | ||
Der Pointer zeigt dabei auf die Stelle im Paket, an der das Problem aufgetreten ist | Der Pointer zeigt dabei auf die Stelle im Paket, an der das Problem aufgetreten ist | ||
== Informationsnachrichten == | |||
{| class="wikitable big options" | |||
! class="hintergrundfarbe6"| Type | |||
! class="hintergrundfarbe6"| Beschreibung | |||
! class="hintergrundfarbe6"| RFC | |||
|- | |||
|128 || [[#Echo Request|Echo Request]] || [https://www.rfc-editor.org/rfc/4443 RFC 4443] | |||
|- | |||
|129 || [[#|Echo Reply|Echo Reply]] ||[https://www.rfc-editor.org/rfc/4443|RFC 4443] | |||
|- | |||
|130 || [[#Multicast Listener Query|Multicast Listener Query]] ||RFC 2710 und RFC 3810 | |||
|- | |||
|131 || Version 1 Multicast Listener Report |RFC 2710 | |||
|- | |||
|132 || Multicast Listener Done ||RFC 2710 | |||
|- | |||
|133 || Router Solicitation || RFC 4861 | |||
|- | |||
|134 || Router Advertisement || RFC 4861 | |||
|- | |||
|135 || |Neighbor Solicitation ||RFC 4861 | |||
|- | |||
|136 || Neighbor Advertisement ||RFC 4861 | |||
|- | |||
|137 || Redirect || RFC 4861 | |||
|- | |||
|138 | |||
|Router Renumbering | |||
|RFC 2894 | |||
|- | |||
|139 | |||
|ICMP Node Information Query | |||
|RFC 4620 | |||
|- | |||
|140 | |||
|ICMP Node Information Response | |||
|RFC 4620 | |||
|- | |||
|141 | |||
|Inverse Neighbor Discovery Solicitation Message | |||
|RFC 3122 | |||
|- | |||
|142 | |||
|Inverse Neighbor Discovery Advertisement Message | |||
|RFC 3122 | |||
|- | |||
|143 | |||
|Version 2 Multicast Listener Report | |||
|RFC 3810 | |||
|- | |||
|144 | |||
|Home Agent Address Discovery Request Message | |||
|RFC 3775 | |||
|- | |||
|145 | |||
|Home Agent Address Discovery Reply Message | |||
|RFC 3775 | |||
|- | |||
|146 | |||
|Mobile Prefix Solicitation | |||
|RFC 3775 | |||
|- | |||
|147 | |||
|Mobile Prefix Advertisement | |||
|RFC 3775 | |||
|- | |||
|148 | |||
|Certification Path Solicitation Message | |||
|RFC 3971 | |||
|- | |||
|149 | |||
|Certification Path Advertisement Message | |||
|RFC 3971 | |||
|- | |||
|150 | |||
|ICMP messages utilized by experimental mobility protocols such as Seamoby | |||
|RFC 4065 | |||
|- | |||
|151 | |||
|Multicast Router Advertisement | |||
|RFC 4286 | |||
|- | |||
|152 | |||
|Multicast Router Solicitation | |||
|RFC 4286 | |||
|- | |||
|153 | |||
|Multicast Router Termination | |||
|RFC 4286 | |||
|- | |||
|155 | |||
|RPL Control Message | |||
|[https://www.rfc-editor.org/rfc/rfc6550.html RFC 6550] | |||
|- | |||
|200 | |||
|Private experimentation | |||
| | |||
|- | |||
|201 | |||
|Private experimentation | |||
| | |||
|- | |||
|255 | |||
|Reserved for expansion of ICMPv6 informational messages | |||
| | |||
|} | |||
==== Echo Request ==== | |||
{| class="wikitable float small" | |||
|+ Echo-Request-Schema | |||
|- align="center" | |||
! class="hintergrundfarbe6" colspan="1"| 0 | |||
| colspan="8" | Type | |||
| colspan="8" | Code | |||
| colspan="16" | Prüfsumme | |||
|- align="center" | |||
! class="hintergrundfarbe6" colspan="1"| 32 | |||
| colspan="16" | Identifikation | |||
| colspan="16" | Sequenznummer | |||
|- align="center" | |||
! class="hintergrundfarbe6" colspan="1"| … | |||
| colspan="32" | Daten | |||
|} | |||
; Echo Request - Type 128 | |||
Mit einem ''Echo Request'' wird um eine Antwort gebeten | |||
* Ein ''Echo Request'' ist nichts anderes als ein simpler [[Ping (Datenübertragung)|Ping]] | |||
* Das Datenfeld kann mit Daten vergrößert werden, um größere Pakete zu produzieren | |||
* So kann man zum Beispiel die [[Maximum Transmission Unit|MTU]] ermitteln | |||
Jedes System muss gemäß RFC auf ''Echo Request''s reagieren und mit ''Echo Replies'' antworten | |||
* Auch sollte jedes System eine Anwendung zum Versenden und Empfangen von ''Echo Request/Replies'' besitzen | |||
* Hiervon wird in der Praxis jedoch oft abgewichen, so blockiert beispielsweise die Windows-Firewall standardmäßig ICMPv6-Echo-Request-Anfragen | |||
Empfangene ''Echo Request'' können an Anwendungen weitergeleitet werden, die auf ICMP-Nachrichten horchen | |||
==== Echo Reply ==== | |||
{| class="wikitable float small" | |||
|+ Echo-Reply-Schema | |||
|- align="center" | |||
! class="hintergrundfarbe6" colspan="1"| 0 | |||
| colspan="8" | Type | |||
| colspan="8" | Code | |||
| colspan="16" | Prüfsumme | |||
|- align="center" | |||
! class="hintergrundfarbe6" colspan="1"| 32 | |||
| colspan="16" | Identifikation | |||
| colspan="16" | Sequenznummer | |||
|- align="center" | |||
! class="hintergrundfarbe6" colspan="1"| … | |||
| colspan="32" | Daten | |||
|} | |||
; Echo Reply - Type 129 | |||
Auf eine ''Echo-Request''-Nachricht muss mit einem ''Echo Reply'' geantwortet werden | |||
* Das Paket ist bis auf das Typenfeld dasselbe. ''Echo-Reply''-Nachrichten sollen nur an Unicast-Adressen verschickt werden | |||
Anhand der Identifikation und der Sequenznummer wird der Empfänger die Antworten zu seinen Anfragen zuordnen können | |||
Empfangene ''Echo-Reply''-Nachrichten müssen an die Anwendung weitergereicht werden, die den zugehörigen ''Echo Request'' versendet hat | |||
* An die restlichen auf ICMP horchende Anwendungen kann es weitergereicht werden | |||
==== Multicast Listener Discovery ==== | |||
; Multicast Listener Discovery - Type 130 | |||
MLD ist die Implementation von [[Internet Group Management Protocol|IGMP]] (IPv4) in IPv6 | |||
* Es wird also genutzt, um [[Multicast]]-Abonnements zu verwalten | |||
* Dabei entspricht '''MLDv1 IGMPv2''' und '''MLDv2 IGMPv3''' | |||
* Bei den jeweils neueren Versionen lässt sich bestimmen, welche Quell-Adressen für Multicast-Streams akzeptabel sind.), Windows seit 2006 (Vista), FreeBSD seit 2009 (8.0) | |||
<noinclude> |
Version vom 21. April 2025, 12:55 Uhr
Fehlernachrichten
Type | Beschreibung | RFC |
---|---|---|
1 | Destination Unreachable | RFC 4443 |
2 | Packet Too Big | RFC 4443 |
3 | Time Exceeded | RFC 4443 |
4 | Parameter Problem | RFC 4443 |
Destination Unreachable
0 | Type | Code | Prüfsumme | |||||||||||||||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
32 | Unbenutzt | |||||||||||||||||||||||||||||||
… | Fehlerhaftes Paket |
- Destination Unreachable - Type 1
Destination-Unreachable-Nachrichten sollten vom Router erzeugt werden, wenn ein Paket nicht ausgeliefert werden konnte
- Wenn das Paket wegen Überlastung fallen gelassen wurde, muss keine Destination Unreachable versandt werden
Wenn das Paket wegen fehlender Routen nicht ausgeliefert wurde, wird der Code 0 gesetzt
- Ist das Ausliefern administrativ verboten (Firewall), wird der Code 1 gesetzt
- Wenn der Router die IPv6-Adresse nicht auflösen kann, oder ein Problem mit dem Link hat, wird der Code 3 gesetzt
- Wenn ein Zielhost für ein UDP-Paket keinen Listener hat, sollte er ein Destination Unreachable mit Code 4 versenden
Wenn ein Destination Unreachable empfangen wird, muss es der darüberliegenden Schicht weitergereicht werden
Packet Too Big
0 | Type | Code | Prüfsumme | |||||||||||||||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
32 | MTU | |||||||||||||||||||||||||||||||
… | Fehlerhaftes Paket |
- Packet Too Big - Type 2
Eine Packet-Too-Big-Nachricht muss vom Router erzeugt werden, wenn ein Paket nicht weitergeleitet werden kann, weil es größer ist als die maximale MTU des Links, über den es versendet werden soll. Packet-Too-Big-Nachrichten werden vom Path MTU Discovery gebraucht, um die pfadabhängige MTU zu ermitteln
Der Code sollte vom Sender auf 0 gesetzt und vom Empfänger ignoriert werden
Wenn ein Packet Too Big empfangen wird, muss es dem darüberliegenden Layer weitergereicht werden
Time Exceeded
0 | Type | Code | Prüfsumme | |||||||||||||||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
32 | Unbenutzt | |||||||||||||||||||||||||||||||
… | Fehlerhaftes Paket |
- Time Exceeded - Type 3
Wenn ein Router ein Paket mit einem Hop-Limit von 0 erhält, oder den Time-to-Live-Wert auf 0 reduziert, muss er das Paket verwerfen und ein Time Exceeded mit Code 0 an den Absender versenden
- Das zeigt entweder eine Endlosschleife im Routing an oder ein zu kleines anfängliches Hop-Limit
Wenn von einer fragmentierten Nachricht nicht alle Fragmente innerhalb einer gewissen Zeit ankommen, wird das Paket verworfen und es muss ein Time Exceeded mit Code 1 versendet werden
Parameter Problem
0 | Type | Code | Prüfsumme | |||||||||||||||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
32 | Pointer | |||||||||||||||||||||||||||||||
… | Fehlerhaftes Paket |
- Parameter Problem - Type 4
Wenn ein Host beim Verarbeiten eines IPv6-Pakets ein Problem in einem Feld feststellt und nicht mit der Verarbeitung weiterfahren kann, muss er das Paket verwerfen und eine Parameter-Problem-Nachricht verschicken
Mit dem Code wird dabei die Art des Problems genauer beschrieben
0 | Fehlerhaftes Header-Feld gefunden |
1 | Unbekannter Next-Header-Typ gefunden |
2 | Unbekannte IPv6-Option |
3 | Unvollständiger IPv6 Header Chain im ersten IPv6 Fragment |
Der Pointer zeigt dabei auf die Stelle im Paket, an der das Problem aufgetreten ist
Informationsnachrichten
Type | Beschreibung | RFC |
---|---|---|
128 | Echo Request | RFC 4443 |
129 | Echo Reply|Echo Reply | RFC 4443] |
130 | Multicast Listener Query | RFC 2710 und RFC 3810 |
131 | RFC 2710 | |
132 | Multicast Listener Done | RFC 2710 |
133 | Router Solicitation | RFC 4861 |
134 | Router Advertisement | RFC 4861 |
135 | Neighbor Solicitation | RFC 4861 |
136 | Neighbor Advertisement | RFC 4861 |
137 | Redirect | RFC 4861 |
138 | Router Renumbering | RFC 2894 |
139 | ICMP Node Information Query | RFC 4620 |
140 | ICMP Node Information Response | RFC 4620 |
141 | Inverse Neighbor Discovery Solicitation Message | RFC 3122 |
142 | Inverse Neighbor Discovery Advertisement Message | RFC 3122 |
143 | Version 2 Multicast Listener Report | RFC 3810 |
144 | Home Agent Address Discovery Request Message | RFC 3775 |
145 | Home Agent Address Discovery Reply Message | RFC 3775 |
146 | Mobile Prefix Solicitation | RFC 3775 |
147 | Mobile Prefix Advertisement | RFC 3775 |
148 | Certification Path Solicitation Message | RFC 3971 |
149 | Certification Path Advertisement Message | RFC 3971 |
150 | ICMP messages utilized by experimental mobility protocols such as Seamoby | RFC 4065 |
151 | Multicast Router Advertisement | RFC 4286 |
152 | Multicast Router Solicitation | RFC 4286 |
153 | Multicast Router Termination | RFC 4286 |
155 | RPL Control Message | RFC 6550 |
200 | Private experimentation | |
201 | Private experimentation | |
255 | Reserved for expansion of ICMPv6 informational messages |
Echo Request
0 | Type | Code | Prüfsumme | |||||||||||||||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
32 | Identifikation | Sequenznummer | ||||||||||||||||||||||||||||||
… | Daten |
- Echo Request - Type 128
Mit einem Echo Request wird um eine Antwort gebeten
- Ein Echo Request ist nichts anderes als ein simpler Ping
- Das Datenfeld kann mit Daten vergrößert werden, um größere Pakete zu produzieren
- So kann man zum Beispiel die MTU ermitteln
Jedes System muss gemäß RFC auf Echo Requests reagieren und mit Echo Replies antworten
- Auch sollte jedes System eine Anwendung zum Versenden und Empfangen von Echo Request/Replies besitzen
- Hiervon wird in der Praxis jedoch oft abgewichen, so blockiert beispielsweise die Windows-Firewall standardmäßig ICMPv6-Echo-Request-Anfragen
Empfangene Echo Request können an Anwendungen weitergeleitet werden, die auf ICMP-Nachrichten horchen
Echo Reply
0 | Type | Code | Prüfsumme | |||||||||||||||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
32 | Identifikation | Sequenznummer | ||||||||||||||||||||||||||||||
… | Daten |
- Echo Reply - Type 129
Auf eine Echo-Request-Nachricht muss mit einem Echo Reply geantwortet werden
- Das Paket ist bis auf das Typenfeld dasselbe. Echo-Reply-Nachrichten sollen nur an Unicast-Adressen verschickt werden
Anhand der Identifikation und der Sequenznummer wird der Empfänger die Antworten zu seinen Anfragen zuordnen können
Empfangene Echo-Reply-Nachrichten müssen an die Anwendung weitergereicht werden, die den zugehörigen Echo Request versendet hat
- An die restlichen auf ICMP horchende Anwendungen kann es weitergereicht werden
Multicast Listener Discovery
- Multicast Listener Discovery - Type 130
MLD ist die Implementation von IGMP (IPv4) in IPv6
- Es wird also genutzt, um Multicast-Abonnements zu verwalten
- Dabei entspricht MLDv1 IGMPv2 und MLDv2 IGMPv3
- Bei den jeweils neueren Versionen lässt sich bestimmen, welche Quell-Adressen für Multicast-Streams akzeptabel sind.), Windows seit 2006 (Vista), FreeBSD seit 2009 (8.0)