|   |   | 
| (205 dazwischenliegende Versionen desselben Benutzers werden nicht angezeigt) | 
| Zeile 1: | Zeile 1: | 
|  | '''topic''' -Kurzbeschreibung |  | '''IPv6/ICMPv6''' - ICMPv6 ([[Internet Control Message Protocol]] in [[IPv6-Netzwerk]]en | 
|  | 
 |  | 
 | 
|  | == Beschreibung == |  | == Beschreibung == | 
|  | Das '''Internet Control Message Protocol for the Internet Protocol Version 6''' ('''ICMPv6''') ist die mit [[IPv6]] zusammen verwendete Version des [[Internet Control Message Protocol]].
 |  | <div class="float"> | 
|  | * Es dient, wie schon bei [[IPv4]], in [[Rechnernetz|Netzwerken]] zum Austausch von Fehler- und Informationsmeldungen.
 |  | {{:IPv6/ICMPv6/Diagramm}} | 
|  | * Zusätzlich findet es aber noch im [[Neighbor Discovery Protocol]], dem Ersatz des [[Address Resolution Protocol]], Verwendung.
 |  | </div> | 
|  | 
 |  | 
 | 
|  | Im Gegensatz zum ICMP bei IPv4 ist ICMPv6 zwingend für den Betrieb von IPv6 nötig.
 |  | ; Fehlererkennung und -meldung | 
|  | * Ein generelles Blockieren von ICMPv6 auf der Firewall führt dazu, dass IPv6 nicht funktioniert (vgl.
 |  | Fehleranalyse | 
|  | * RFC 4890). |  | * Echo-Request und Echo-Reply für Ping-Operationen | 
|  | 
 |  | 
 | 
|  | ICMPv6 dient als Hilfsprotokoll für IPv6, ist in derselben OSI-Schicht 3wie dieses angesiedelt und nutzt das IPv6-Protokoll zum Versand von ICMP-Nachrichten.
 |  | ; Hilfsprotokoll für IPv6 | 
|  | * Als [[Protokoll (IP)|Protokoll-Nummer]]wird dabei 58ins Next-Header-Feld des IPv6-Headers eingefügt. |  | OSI-Schicht 3 | 
|  |  | * nutzt das IPv6-Protokoll zum Versand von ICMP-Nachrichten | 
|  |  | * [[Protokoll (IP)|Protokoll-Nummer]] ''58'' im [[Next-Header]]-Feld des [[IPv6-Header]]s | 
|  | 
 |  | 
 | 
|  | {| class="wikitable float-right"
 |  | ; Austausch von Fehler- und Informationsmeldungen in [[IPv6]]-[[Rechnernetz|Netzwerken]] | 
|  | |-----
 |  | [[Neighbor Discovery Protocol]] | 
|  | ! style="background:#C0C0FF;" colspan="2"| ICMPv6 (Internet Control Message Protocol Version 6)
 |  | * Nachfolger des [[Address Resolution Protocol]] mit [[IPv4]] | 
|  | |-----
 |  | 
|  | | align="left" | '''Familie:'''
 |  | 
|  | | align="left" | [[Internetprotokollfamilie]]
 |  | 
|  | |-----
 |  | 
|  | | align="left" | '''Einsatzgebiet:'''
 |  | 
|  | | align="left" style="width:210px;"| Obligatorischer Zusatz zu [[IPv6]], Fehlermeldungen, Diagnose, Autoconfiguration, Routing
 |  | 
|  | |-----
 |  | 
|  | | align="center" colspan="2" |
 |  | 
|  | {| border="0" cellspacing="3"
 |  | 
|  | |+ '''Internet-Protokolle im [[TCP/IP-Referenzmodell|TCP/IP-Protokollstapel]]'''
 |  | 
|  | |-----
 |  | 
|  | | rowspan="2" align="center" bgcolor="#FFCC99" | '''Internet'''
 |  | 
|  | | colspan="5" align="center" bgcolor="#9999FF" | '''ICMPv6'''
 |  | 
|  | |-----
 |  | 
|  | | colspan="5" align="center" bgcolor="#EEEEFF" | [[IPv6]]
 |  | 
|  | |-----
 |  | 
|  | | rowspan="2" align="center" bgcolor="#FFEEBB" | ''Netzzugang''
 |  | 
|  | | rowspan="2" align="center" bgcolor="#EEEEEE" | [[Ethernet]]
 |  | 
|  | | rowspan="2" align="center" bgcolor="#EEEEEE" | [[Token Bus|Token<br />Bus]]
 |  | 
|  | | rowspan="2" align="center" bgcolor="#EEEEEE" | [[IEEE 802.11|IEEE<br />802.11a/b/g/n]]
 |  | 
|  | | rowspan="2" align="center" bgcolor="#EEEEEE" | [[Fiber Distributed Data Interface|FDDI]]
 |  | 
|  | | rowspan="2" align="center" bgcolor="#EEEEEE" | …
 |  | 
|  | |}
 |  | 
|  | |-----
 |  | 
|  | | align="left" | '''Standards:'''
 |  | 
|  | | align="left" |
 |  | 
|  | [https://www.rfc-editor.org/rfc/rfc8200.html RFC 8200] (2017)
 |  | 
|  | [https://www.rfc-editor.org/rfc/rfc4443 RFC 4443] (2006)
 |  | 
|  | |}
 |  | 
|  | 
 |  | 
 | 
|  | == Header ==
 |  | ; Aufgaben | 
|  | ; Das Feld ''Type'' gibt die Klasse der ICMP-Nachricht an, welche mit dem Feld ''Code'' genauer spezifiziert werden kann. |  | * [[Adressauflösung]] | 
|  | * Die Prüfsumme wird zur Verifizierung der Gültigkeit des ICMPv6-Pakets benutzt. |  | * [[Reichweiten-Ermittlung]] | 
|  | * Der restliche Inhalt der ICMP-Nachricht wird durch den jeweiligen Typ bestimmt. |  | 
|  | * Bei Fehlernachrichten wird nach den möglichen zusätzlichen Feldern immer noch so viel wie möglich vom fehlerverursachenden Paket angehängt.
 |  | 
|  | 
 |  | 
 | 
|  | {| class="wikitable float-right" style="font-size:smaller;" cellpadding="2"
 |  | ; Bedeutung von ICMPv6 | 
|  | |+ ICMPv6Header
 |  | ICMPv6 oft erforderlich | 
|  | {{FrameHeader}}
 |  | * Im Gegensatz zum ICMP bei IPv4 ist ICMPv6 zwingend für den Betrieb von IPv6 erforderlich | 
|  | |- align="center"
 |  | * Ein generelles Blockieren von ICMPv6 auf der Firewall führt dazu, dass IPv6 nicht funktioniert (vgl. RFC 4890) | 
|  | ! class="hintergrundfarbe6" colspan="1"| 0
 |  | 
|  | | colspan="8" | Type
 |  | 
|  | | colspan="8" | Code
 |  | 
|  | | colspan="16" | Prüfsumme
 |  | 
|  | |- align="center"
 |  | 
|  | ! class="hintergrundfarbe6" colspan="1"| …
 |  | 
|  | | colspan="32" | ICMPv6-Nachricht …
 |  | 
|  | |}
 |  | 
|  | 
 |  | 
 | 
|  | === Prüfsumme === |  | == Verarbeitung == | 
|  | {| class="wikitable float-right" style="font-size:smaller;text-align:center;" cellpadding="2" |  | ; Regeln für die Verarbeitung von ICMPv6-Nachrichten | 
|  | |+ Prüfsummen-Schema
 |  | {| class="wikitable options big" | 
|  | {{FrameHeader}}
 |  | 
|  | |- |  | |- | 
|  | ! class="hintergrundfarbe6" colspan="1"| 0 |  | ! Nachricht !! Beschreibung | 
|  | | colspan="32" rowspan="4" | IPv6-Absender-Adresse
 |  | 
|  | |- |  | |- | 
|  | ! class="hintergrundfarbe6" colspan="1"|32
 |  | | Unbekannte ICMPv6-Fehlernachrichten || müssen an die darüberliegende Netzwerkschicht weitergereicht werden | 
|  | |- |  | |- | 
|  | ! class="hintergrundfarbe6" colspan="1"|64
 |  | | Unbekannte ICMPv6-Informationsnachrichten || müssen ohne Benachrichtigung des Absenders verworfen werden | 
|  | |- |  | |- | 
|  | ! class="hintergrundfarbe6" colspan="1"|96
 |  | | Fehlerverursachendes Paket || Jeder Fehlernachricht wird am Ende so viel wie möglich des fehlerverursachenden Pakets angehängt | 
|  | |- |  | |- | 
|  | ! class="hintergrundfarbe6" colspan="1"|128
 |  | | Protokollnummer || Die Protokollnummer zum Weiterreichen von unbekannten Fehlernachrichten wird aus dem angehängten Originalpaket entnommen | 
|  | | colspan="32" rowspan="4" |IPv6-Ziel-Adresse |  | 
|  | |-
 |  | 
|  | ! class="hintergrundfarbe6" colspan="1"| 160
 |  | 
|  | |-
 |  | 
|  | ! class="hintergrundfarbe6" colspan="1"| 192
 |  | 
|  | |-
 |  | 
|  | ! class="hintergrundfarbe6" colspan="1"| 224
 |  | 
|  | |-
 |  | 
|  | ! class="hintergrundfarbe6" colspan="1"| 256
 |  | 
|  | | colspan="32" | IPv6-Nutzlast-Größe
 |  | 
|  | |-
 |  | 
|  | ! class="hintergrundfarbe6" colspan="1"| 288
 |  | 
|  | | colspan="24" | Checksumme 0
 |  | 
|  | | colspan="8" | Next Header 58
 |  | 
|  | |} |  | |} | 
|  | 
 |  | 
 | 
|  | Die Prüfsumme (engl. ''checksum'') eines ICMPv6-Pakets ist ein 16-Bit-[[Einerkomplement]] der Summe des Einerkomplements der gesamten ICMPv6-Nachricht.
 |  | ; Keine Antworten auf | 
|  | * Zusätzlich zur Nachricht wird noch ein IPv6-Pseudoheader vorne angehängt.
 |  | Netz darf nicht mit ICMPv6-Fehlernachrichten geflutet werden | 
|  | * Zur Berechnung der Prüfsumme wird das Prüfsummenfeld auf 0 gesetzt.
 |  | 
|  | * Der zur Berechnung der Prüfsumme verwendete Pseudoheader sieht wie im Schema nebenan aus.
 |  | 
|  | 
 |  | 
 | 
|  | Dies ist eine der Neuerungen von ICMPv6 gegenüber [[Internet Control Message Protocol|ICMP]],wo die Prüfsumme nur über den ICMP-Header berechnet wurde.
 |  | Auf folgende Pakete werden keine Fehlernachrichten versandt | 
|  |  | * Fehlernachrichten | 
|  |  | * Pakete an Multicast-, Link-Level-Multicast- oder Link-Level-Broadcast-Adressen mit folgenden  | 
|  | 
 |  | 
 | 
|  | == Verarbeitung ==
 |  | Ausnahmen | 
|  | ; Für die Verarbeitung von ICMPv6-Nachrichten gelten folgende Regeln
 |  | * Packet-Too-Big-Nachrichten | 
|  | * Unbekannte ICMPv6-Fehlernachrichten müssen an die darüberliegende Netzwerkschicht weitergereicht werden.
 |  | * Parameter-Problem-Nachrichten mit Code 2 - unbekannte IPv6-Option | 
|  | * Unbekannte ICMPv6-Informationsnachrichten müssen ohne Benachrichtigung des Absenders verworfen werden.
 |  | 
|  | * Jeder Fehlernachricht wird am Ende so viel wie möglich des fehlerverursachenden Pakets angehängt.
 |  | 
|  | * Die Protokollnummer zum Weiterreichen von unbekannten Fehlernachrichten wird aus dem angehängten Originalpaket entnommen.
 |  | 
|  | * Auf folgende Pakete werden keine Fehlernachrichten versandt:
 |  | 
|  | ** Fehlernachrichten
 |  | 
|  | ** Pakete an Multicast-, Link-Level-Multicast- oder Link-Level-Broadcast-Adressen mit folgenden Ausnahmen:
 |  | 
|  | *** Packet-Too-Big-Nachrichten
 |  | 
|  | *** Parameter-Problem-Nachrichten mit Code 2– unbekannte IPv6-Option
 |  | 
|  | * Das Netz darf nicht mit ICMPv6-Fehlernachrichten geflutet werden.
 |  | 
|  | 
 |  | 
 | 
|  | == Nachrichten-Typen ==
 |  | <noinclude> | 
|  | ; Die Nachrichten-Typen werden in zwei Gruppen unterteilt
 |  | 
|  | * Die ersten 128 Typen (0–127) mit dem [[Bitwertigkeit|höchstwertigen Bit]] (engl. ''most significant bit'') auf 0, sind Fehlernachrichten.
 |  | 
|  | * Die zweiten 128 Typen (128–255), mit dem höchstwertigen Bit auf 1, sind Informationsnachrichten.
 |  | 
|  | 
 |  | 
 | 
|  | {|
 |  | == Anhang == | 
|  | | style="vertical-align:top;" |
 |  | ==== RFC ==== | 
|  | {| class="wikitable" |  | {| class="wikitable options big col1center" | 
|  | |+ Fehlernachrichten
 |  | 
|  | ! class="hintergrundfarbe6"| Type
 |  | 
|  | ! class="hintergrundfarbe6"| Beschreibung
 |  | 
|  | ! class="hintergrundfarbe6"| RFC
 |  | 
|  | |-
 |  | 
|  | |1
 |  | 
|  | |Destination Unreachable
 |  | 
|  | |RFC 4443
 |  | 
|  | |-
 |  | 
|  | |2
 |  | 
|  | |Packet Too Big
 |  | 
|  | |RFC 4443
 |  | 
|  | |-
 |  | 
|  | |3
 |  | 
|  | |Time Exceeded
 |  | 
|  | |RFC 4443
 |  | 
|  | |- |  | |- | 
|  | |4
 |  | ! RFC !! Titel !! Jahr !! Status | 
|  | |Parameter Problem
 |  | 
|  | |RFC4443
 |  | 
|  | |- |  | |- | 
|  | |100 |  | | [https://www.rfc-editor.org/info/rfc2460 2460] || Internet Protocol, Version 6 (IPv6) Specification || 1998 || Ersetzt durch: [[RFC/8200]] | 
|  | |Private experimentation |  | 
|  | | |  | 
|  | |- |  | |- | 
|  | |101 |  | | [https://www.rfc-editor.org/info/rfc3122 3122] || Extensions to IPv6 Neighbor Discovery for Inverse Discovery Specification || ||   | 
|  | |Private experimentation |  | 
|  | | |  | 
|  | |} |  | 
|  | | |  | 
|  | {|class="wikitable"
 |  | 
|  | |+ Informationsnachrichten |  | 
|  | ! class="hintergrundfarbe6"| Type
 |  | 
|  | ! class="hintergrundfarbe6"| Beschreibung
 |  | 
|  | ! class="hintergrundfarbe6"| RFC
 |  | 
|  | |- |  | |- | 
|  | |128 |  | | [https://www.rfc-editor.org/info/rfc4443 4443] || Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification || ||   | 
|  | |Echo Request |  | 
|  | |RFC 4443 |  | 
|  | |- |  | |- | 
|  | |129 |  | | [https://www.rfc-editor.org/info/rfc4604 4604] || Using Internet Group Management Protocol Version 3 (IGMPv3) and Multicast Listener Discovery Protocol Version 2 (MLDv2) for Source-Specific Multicast || 2006 || Proposed Standard | 
|  | |Echo Reply |  | 
|  | |RFC 4443 |  | 
|  | |- |  | |- | 
|  | |130 |  | | [https://www.rfc-editor.org/info/rfc4861 4861] || Neighbor Discovery for IP Version 6 (IPv6) || ||   | 
|  | |Multicast Listener Query |  | 
|  | |RFC 2710 und RFC 3810 |  | 
|  | |- |  | |- | 
|  | |131 |  | |- [https://www.rfc-editor.org/info/rfc4890 4890] || Recommendations for Filtering ICMPv6 Messages in Firewalls || ||   | 
|  | |Version 1 Multicast Listener Report |  | 
|  | |RFC 2710 |  | 
|  | |- |  | |- | 
|  | |132 |  | | [https://www.rfc-editor.org/info/rfc7112 7112] || Implications of Oversized IPv6 Header Chains || ||   | 
|  | |Multicast Listener Done |  | 
|  | |RFC 2710 |  | 
|  | |- |  | |- | 
|  | |133 |  | | [https://www.rfc-editor.org/info/rfc8200 8200] || Internet Protocol, Version 6 (IPv6) Specification  || || löst [https://www.rfc-editor.org/info/rfc2460 2460] ab | 
|  | |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
 |  | 
|  | |
 |  | 
|  | |}
 |  | 
|  | |} |  | |} | 
|  | 
 |  | 
 | 
|  | === Destination Unreachable – Type 1 ===
 |  | 
|  | 
 |  | 
|  | {| class="wikitable float-right" style="font-size:smaller;" cellpadding="2"
 |  | 
|  | |+ Destination-Unreachable-Schema
 |  | 
|  | {{FrameHeader}}
 |  | 
|  | |- 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="32" | Unbenutzt
 |  | 
|  | |- align="center"
 |  | 
|  | ! class="hintergrundfarbe6" colspan="1"| …
 |  | 
|  | | colspan="32" | Fehlerhaftes Paket
 |  | 
|  | |}
 |  | 
|  | 
 |  | 
|  | ''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 – Type 2 ===
 |  | 
|  | 
 |  | 
|  | {| class="wikitable float-right" style="font-size:smaller;" cellpadding="2"
 |  | 
|  | |+ Packet-Too-Big-Schema
 |  | 
|  | {{FrameHeader}}
 |  | 
|  | |- 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="32" | MTU
 |  | 
|  | |- align="center"
 |  | 
|  | ! class="hintergrundfarbe6" colspan="1"| …
 |  | 
|  | | colspan="32" | Fehlerhaftes Paket
 |  | 
|  | |}
 |  | 
|  | 
 |  | 
|  | 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 [[Maximum Transmission Unit|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 – Type 3 ===
 |  | 
|  | 
 |  | 
|  | {| class="wikitable float-right" style="font-size:smaller;" cellpadding="2"
 |  | 
|  | |+ Time-Exceeded-Schema
 |  | 
|  | {{FrameHeader}}
 |  | 
|  | |- 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="32" | Unbenutzt
 |  | 
|  | |- align="center"
 |  | 
|  | ! class="hintergrundfarbe6" colspan="1"| …
 |  | 
|  | | colspan="32" | Fehlerhaftes Paket
 |  | 
|  | |}
 |  | 
|  | 
 |  | 
|  | Wenn ein Router ein Paket mit einem [[Hop (Netzwerktechnologie)|Hop]]-Limit von 0 erhält, oder den [[Time to Live|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 – Type 4 ===
 |  | 
|  | 
 |  | 
|  | {| class="wikitable float-right" style="font-size:smaller;" cellpadding="2"
 |  | 
|  | |+ Parameter-Problem-Schema
 |  | 
|  | {{FrameHeader}}
 |  | 
|  | |- 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="32" | Pointer
 |  | 
|  | |- align="center"
 |  | 
|  | ! class="hintergrundfarbe6" colspan="1"| …
 |  | 
|  | | colspan="32" | Fehlerhaftes Paket
 |  | 
|  | |}
 |  | 
|  | 
 |  | 
|  | 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.
 |  | 
|  | 
 |  | 
|  | {| class="wikitable"
 |  | 
|  | | 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.
 |  | 
|  | 
 |  | 
|  | === Echo Request – Type 128 ===
 |  | 
|  | 
 |  | 
|  | {| class="wikitable float-right" style="font-size:smaller;" cellpadding="2"
 |  | 
|  | |+ Echo-Request-Schema
 |  | 
|  | {{FrameHeader}}
 |  | 
|  | |- 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
 |  | 
|  | |}
 |  | 
|  | 
 |  | 
|  | 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 – Type 129 ===
 |  | 
|  | 
 |  | 
|  | {| class="wikitable float-right" style="font-size:smaller;" cellpadding="2"
 |  | 
|  | |+ Echo-Reply-Schema
 |  | 
|  | {{FrameHeader}}
 |  | 
|  | |- 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
 |  | 
|  | |}
 |  | 
|  | 
 |  | 
|  | 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 – 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>
 |  | 
|  | 
 |  | 
|  | == Anhang ==
 |  | 
|  | === Siehe auch === |  | === Siehe auch === | 
|  | {{Special:PrefixIndex/IPv6}} |  | {{Special:PrefixIndex/IPv6/ICMPv6}} | 
|  | ==== Dokumentation ====
 |  | 
|  | ===== RFC =====
 |  | 
|  | # [https://www.rfc-editor.org/rfc/rfc4861.html RFC 4861] – "Neighbor Discovery for IP Version 6 (IPv6)"
 |  | 
|  | # [https://www.rfc-editor.org/rfc/rfc4443.html RFC 4443] – "Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6)" Specification
 |  | 
|  | # [https://www.rfc-editor.org/rfc/rfc3122.html RFC 3122] – "Extensions to IPv6 Neighbor Discovery for Inverse Discovery Specification"
 |  | 
|  | # [https://www.iana.org/assignments/icmpv6-parameters IANA ICMP Parameters] – vollständige Liste der ICMPv6-Typen und -Codes
 |  | 
|  | # [https://www.rfc-editor.org/rfc/rfc4890.html RFC 4890] – "Recommendations for Filtering ICMPv6 Messages in Firewalls"
 |  | 
|  | # [https://www.rfc-editor.org/rfc/rfc7112.html RFC 7112] – "Implications of Oversized IPv6 Header Chains"
 |  | 
|  | # [https://www.rfc-editor.org/rfc/rfc8200.html RFC 8200] – "Internet Protocol, Version 6 (IPv6) Specification" (löst [https://www.rfc-editor.org/rfc/rfc2460.html RFC 2460] ab)
 |  | 
|  | # https://tools.ietf.org/html/rfc4604
 |  | 
|  | 
 |  | 
 | 
|  | ==== Links====
 |  | === Links === | 
|  | ===== Projekt =====
 |  | ==== Weblinks ==== | 
|  | ===== Weblinks=====
 |  | 
|  | # https://de.wikipedia.org/wiki/ICMPv6 |  | # https://de.wikipedia.org/wiki/ICMPv6 | 
|  | # https://lwn.net/Articles/29489/ |  | # [https://www.iana.org/assignments/icmpv6-parameters IANA ICMP Parameters] - Vollständige Liste der ICMPv6-Typen und -Codes | 
|  | 
 |  | 
 | 
|  | [[Kategorie:ICMPv6]] |  | [[Kategorie:IPv6/ICMPv6]] | 
|  | </noinclude> |  | </noinclude> |