IPv6/ICMP: Unterschied zwischen den Versionen

Version vom 15. Mai 2023, 13:42 Uhr

topic - Kurzbeschreibung

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.

Es dient, wie schon bei IPv4, in Netzwerken zum Austausch von Fehler- und Informationsmeldungen.
Zusätzlich findet es aber noch im Neighbor Discovery Protocol, dem Ersatz des Address 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 (vgl.
RFC 4890).

ICMPv6 dient als Hilfsprotokoll für IPv6, ist in derselben OSI-Schicht 3 wie dieses angesiedelt und nutzt das IPv6-Protokoll zum Versand von ICMP-Nachrichten.

Als Protokoll-Nummer wird dabei 58 ins Next-Header-Feld des IPv6-Headers eingefügt.

ICMPv6 (Internet Control Message Protocol Version 6)

Familie:

Internetprotokollfamilie

Einsatzgebiet:

Obligatorischer Zusatz zu IPv6, Fehlermeldungen, Diagnose, Autoconfiguration, Routing

**Internet-Protokolle im TCP/IP-Protokollstapel**
Internet	ICMPv6
	IPv6
Netzzugang	Ethernet	Token Bus	IEEE 802.11a/b/g/n	FDDI	…

Standards:

RFC 8200 (2017) RFC 4443 (2006)

Header

Das Feld Type gibt die Klasse der ICMP-Nachricht an, welche mit dem Feld Code 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.

ICMPv6 Header Vorlage:FrameHeader
0	Type								Code								Prüfsumme
…	ICMPv6-Nachricht …

Prüfsumme

Prüfsummen-Schema Vorlage:FrameHeader
32
0	IPv6-Absender-Adresse
64
96
128	IPv6-Ziel-Adresse
160
192
224
256	IPv6-Nutzlast-Größe
288	Checksumme 0	Next Header 58

Die Prü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über ICMP, wo die Prüfsumme nur über den ICMP-Header berechnet wurde.

Verarbeitung

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.

Nachrichten-Typen

Die Nachrichten-Typen werden in zwei Gruppen unterteilt.

Die ersten 128 Typen (0–127) mit dem 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.

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
100	Private experimentation
101	Private experimentation

Informationsnachrichten
Type	Beschreibung	RFC
128	Echo Request	RFC 4443
129	Echo Reply	RFC 4443
130	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	RFC 6550
200	Private experimentation
201	Private experimentation
255	Reserved for expansion of ICMPv6 informational messages

Destination Unreachable – Type 1

Destination-Unreachable-Schema Vorlage:FrameHeader
0	Type	Code	Prüfsumme
32	Unbenutzt
…	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

Packet-Too-Big-Schema Vorlage:FrameHeader
0	Type	Code	Prüfsumme
32	MTU
…	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 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

Time-Exceeded-Schema Vorlage:FrameHeader
0	Type	Code	Prüfsumme
32	Unbenutzt
…	Fehlerhaftes Paket

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 – Type 4

Parameter-Problem-Schema Vorlage:FrameHeader
0	Type	Code	Prüfsumme
32	Pointer
…	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.

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

Echo-Request-Schema Vorlage:FrameHeader
0	Type	Code	Prüfsumme
32	Identifikation		Sequenznummer
…	Daten

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 – Type 129

Echo-Reply-Schema Vorlage:FrameHeader
0	Type	Code	Prüfsumme
32	Identifikation		Sequenznummer
…	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 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)

Anhang

Siehe auch

Dokumentation

RFC

RFC 4861 – "Neighbor Discovery for IP Version 6 (IPv6)"
RFC 4443 – "Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6)" Specification
RFC 3122 – "Extensions to IPv6 Neighbor Discovery for Inverse Discovery Specification"
IANA ICMP Parameters – vollständige Liste der ICMPv6-Typen und -Codes
RFC 4890 – "Recommendations for Filtering ICMPv6 Messages in Firewalls"
RFC 7112 – "Implications of Oversized IPv6 Header Chains"
RFC 8200 – "Internet Protocol, Version 6 (IPv6) Specification" (löst RFC 2460 ab)
https://tools.ietf.org/html/rfc4604

Links

Projekt

Weblinks

@@ Zeile 2: / Zeile 2: @@
 == 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]]. Es dient, wie schon bei [[IPv4]], in [[Rechnernetz|Netzwerken]] zum Austausch von Fehler- und Informationsmeldungen. Zusätzlich findet es aber noch im [[Neighbor Discovery Protocol]], dem Ersatz des [[Address Resolution Protocol]], Verwendung.
+Das '''Internet Control Message Protocol for the Internet Protocol Version 6''' ('''ICMPv6''') ist die mit [[IPv6]] zusammen verwendete Version des [[Internet Control Message Protocol]].
+* Es dient, wie schon bei [[IPv4]], in [[Rechnernetz|Netzwerken]] zum Austausch von Fehler- und Informationsmeldungen.
+* Zusätzlich findet es aber noch im [[Neighbor Discovery Protocol]], dem Ersatz des [[Address 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 (vgl. RFC 4890).
+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 (vgl.
+* RFC 4890).
-ICMPv6 dient als Hilfsprotokoll für IPv6, ist in derselben OSI-Schicht 3 wie dieses angesiedelt und nutzt das IPv6-Protokoll zum Versand von ICMP-Nachrichten. Als [[Protokoll (IP)|Protokoll-Nummer]] wird dabei 58 ins Next-Header-Feld des IPv6-Headers eingefügt.
+ICMPv6 dient als Hilfsprotokoll für IPv6, ist in derselben OSI-Schicht 3 wie dieses angesiedelt und nutzt das IPv6-Protokoll zum Versand von ICMP-Nachrichten.
+* Als [[Protokoll (IP)|Protokoll-Nummer]] wird dabei 58 ins Next-Header-Feld des IPv6-Headers eingefügt.
 {| class="wikitable float-right"
@@ Zeile 42: / Zeile 47: @@
 == Header ==
-Das Feld ''Type'' gibt die Klasse der ICMP-Nachricht an, welche mit dem Feld ''Code'' 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.
+Das Feld ''Type'' gibt die Klasse der ICMP-Nachricht an, welche mit dem Feld ''Code'' 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.
 {| class="wikitable float-right" style="font-size:smaller;" cellpadding="2"
@@ Zeile 88: / Zeile 96: @@
 |}
-Die Prü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.
+Die Prü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über [[Internet Control Message Protocol|ICMP]], wo die Prüfsumme nur über den ICMP-Header berechnet wurde.
@@ Zeile 106: / Zeile 117: @@
 == Nachrichten-Typen ==
-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.
+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.
 {|
@@ Zeile 287: / Zeile 300: @@
 |}
-''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.
+''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 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.
@@ Zeile 335: / Zeile 352: @@
 |}
-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 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.
@@ Zeile 396: / Zeile 414: @@
 |}
-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.
+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.
+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.
@@ Zeile 421: / Zeile 444: @@
 |}
-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.
+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.
+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)
+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>