DasInternet Control Message Protocol for the Internet Protocol Version 6 (ICMPv6) ist die mitIPv6 zusammen verwendete Version desInternet Control Message Protocol. Es dient, wie schon beiIPv4, inNetzwerken zum Austausch von Fehler- und Informationsmeldungen. Zusätzlich findet es aber noch imNeighbor Discovery Protocol, dem Ersatz desAddress Resolution Protocol, Verwendung.

Im Gegensatz zum ICMP bei IPv4 ist ICMPv6 zwingend für den Betrieb von IPv6 nötig. Ein generelles Blockieren von ICMPv6 auf der Firewall führt dazu, dass IPv6 nicht funktioniert (RFC 4890^[3]).

ICMPv6 dient als Hilfsprotokoll für IPv6, ist ebenfalls in derVermittlungsschicht (OSI-Schicht 3) angesiedelt und nutzt das IPv6-Protokoll zum Versand von ICMP-Nachrichten. AlsProtokoll-Nummer wird dabei 58 ins Next-Header-Feld des IPv6-Headers eingefügt.

Das FeldType gibt die Klasse der ICMP-Nachricht an, welche mit dem FeldCode genauer spezifiziert werden kann. Die Prüfsumme wird zur Verifizierung der Gültigkeit des ICMPv6-Pakets benutzt. 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.

Die Nachrichten-Typen werden in zwei Gruppen unterteilt. Die ersten 128 Typen (0–127) mit demhö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.

DiePrüfsumme (engl.checksum) eines ICMPv6-Pakets ist ein 16-Bit-Einerkomplement der Summe des Einerkomplements der gesamten ICMPv6-Nachricht. Zusätzlich zur Nachricht wird noch ein IPv6-Pseudoheader vorne angehängt. 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überICMP, wo die Prüfsumme nur über den ICMP-Header berechnet wurde.

Für die Verarbeitung von ICMPv6-Nachrichten gelten folgende Regeln:

• Unbekannte ICMPv6-Fehlernachrichten müssen an die darüberliegende Netzwerkschicht weitergereicht werden.
• 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.

Destination-Unreachable-Nachrichten sollten vomRouter erzeugt werden, wenn ein Paket nicht ausgeliefert werden konnte. Wenn das Paket wegen Überlastung fallen gelassen wurde, muss keineDestination 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 einUDP-Paket keinen Listener hat, sollte er einDestination Unreachable mit Code 4 versenden.

Wenn einDestination Unreachable empfangen wird, muss es der darüberliegenden Schicht weitergereicht werden.

EinePacket-Too-Big-Nachricht muss vom Router erzeugt werden, wenn ein Paket nicht weitergeleitet werden kann, weil es größer ist als die maximaleMTU des Links, über den es versendet werden soll.Packet-Too-Big-Nachrichten werden vomPath 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 einPacket Too Big empfangen wird, muss es dem darüberliegenden Layer weitergereicht werden.

Wenn ein Router ein Paket mit einemHop-Limit von 0 erhält, oder denTime-to-Live-Wert auf 0 reduziert, muss er das Paket verwerfen und einTime 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 einTime Exceeded mit Code 1 versendet werden.

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 eineParameter-Problem-Nachricht verschicken.

Mit dem Code wird dabei die Art des Problems genauer beschrieben.

Der Pointer zeigt dabei auf die Stelle im Paket, an der das Problem aufgetreten ist.

Mit einemEcho Request wird um eine Antwort gebeten. EinEcho Request ist nichts anderes als ein simplerPing. Das Datenfeld kann mit Daten vergrößert werden, um größere Pakete zu produzieren. So kann man zum Beispiel dieMTU ermitteln.

Jedes System muss gemäß RFC aufEcho Requests reagieren und mitEcho Replies antworten. Auch sollte jedes System eine Anwendung zum Versenden und Empfangen vonEcho Request/Replies besitzen. Hiervon wird in der Praxis jedoch oft abgewichen, so blockiert beispielsweise dieWindows-Firewall standardmäßig ICMPv6-Echo-Request-Anfragen.^[15]

EmpfangeneEcho Request können an Anwendungen weitergeleitet werden, die auf ICMP-Nachrichten horchen.

Auf eineEcho-Request-Nachricht muss mit einemEcho Reply geantwortet werden. Das Paket ist bis auf das Typenfeld dasselbe.Echo-Reply-Nachrichten sollen nur anUnicast-Adressen verschickt werden.

Anhand der Identifikation und derSequenznummer wird der Empfänger die Antworten zu seinen Anfragen zuordnen können.

EmpfangeneEcho-Reply-Nachrichten müssen an die Anwendung weitergereicht werden, die den zugehörigenEcho Request versendet hat. An die restlichen auf ICMP horchende Anwendungen kann es weitergereicht werden.

MLD ist die Implementation vonIGMP (IPv4) in IPv6. Es wird also genutzt, umMulticast-Abonnements zu verwalten. Dabei entsprichtMLDv1 IGMPv2 undMLDv2 IGMPv3. Bei den jeweils neueren Versionen lässt sich bestimmen, welche Quell-Adressen für Multicast-Streams akzeptabel sind.^[16]Linux unterstützt es seit 2003 (2.5.68),Windows seit 2006 (Vista),FreeBSD seit 2009 (8.0).^[17][18][19]

• RFC:4861 –Neighbor Discovery for IP Version 6 (IPv6). September 2007 (englisch).
• RFC:4443 –Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6). März 2006 (Specification, englisch).
• RFC:3122 –Extensions to IPv6 Neighbor Discovery for Inverse Discovery Specification. Juni 2001 (englisch).
• IANA ICMP Parameters – vollständige Liste der ICMPv6-Typen und -Codes (englisch).
• RFC:4890 –Recommendations for Filtering ICMPv6 Messages in Firewalls. Mai 2007 (englisch).
• RFC:7112 –Implications of Oversized IPv6 Header Chains. Januar 2014 (englisch).
• RFC:8200 –Internet Protocol, Version 6 (IPv6) Specification. Juli 2017 (löstRFC 2460 ab, englisch).

1. ↑RFC:8200 –Internet Protocol, Version 6 (IPv6) Specification. Juli 2017 (löstRFC 2460 ab, englisch).
2. ↑^abcdefgRFC:4443 –Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6). März 2006 (Specification, englisch).
3. ↑RFC:4890 –Recommendations for Filtering ICMPv6 Messages in Firewalls. Mai 2007 (englisch).
4. ↑^abcRFC:2710 –Multicast Listener Discovery (MLD) for IPv6. Oktober 1999 (englisch).
5. ↑^abRFC:3810 –Multicast Listener Discovery Version 2 (MLDv2) for IPv6. Juni 2004 (englisch).
6. ↑^abcdeRFC:4861 –Neighbor Discovery for IP Version 6 (IPv6). September 2007 (englisch).
7. ↑RFC:2894 –Router Renumbering for IPv6. Juni 2000 (englisch).
8. ↑^abRFC:4620 –IPv6 Node Information Queries. August 2006 (englisch).
9. ↑^abRFC:3122 –Extensions to IPv6 Neighbor Discovery for Inverse Discovery Specification. Juni 2001 (englisch).
10. ↑^abcdRFC:3775 –Mobility Support in IPv6. Juni 2004 (englisch).
11. ↑^abRFC:3971 –SEcure Neighbor Discovery (SEND). März 2005 (englisch).
12. ↑RFC:4065 –Instructions for Seamoby and Experimental Mobility Protocol IANA Allocations. Juli 2005 (englisch).
13. ↑^abcRFC:4286 –Multicast Router Discovery. Dezember 2005 (englisch).
14. ↑RFC:6550 –RPL: IPv6 Routing Protocol for Low-Power and Lossy Networks. März 2012 (englisch).
15. ↑How to allow Pings (ICMP Echo requests) through Windows Firewall. In: thewindowsclub.com. Abgerufen am 10. Januar 2025 (englisch). 
16. ↑RFC:4604 –Using Internet Group Management Protocol Version 3 (IGMPv3) and Multicast Listener Discovery Proto for Source-Specific Multicast. August 2006 (englisch).
17. ↑Linus Torvalds: Linux 2.5.68. In: lwn.net. 19. April 2003, abgerufen am 2. August 2014 (englisch). 
18. ↑Steven White et al.: MLD and IGMP Using Windows Sockets. In: learn.microsoft.com. Microsoft, 7. Januar 2021, abgerufen am 10. Januar 2025 (englisch). 
19. ↑mld(4) – FreeBSD Kernel InterfacesManual

• Internet Protocol
• Netzwerkprotokoll (Vermittlungsschicht)