|
|
| Zeile 588: |
Zeile 588: |
|
| |
|
| == Neighbor Discovery Protocol == | | == Neighbor Discovery Protocol == |
| | | [[Neighbor Discovery Protocol]] |
| Neighbor Discovery Protocol (NDP) ist der Ersatz des Address Resolution Protocol (ARP) von IPv4 für IPv6. Es wird unter anderem dazu benutzt, IPv6-Adressen in Link-Layer-Adressen aufzulösen. | |
| | |
| === Verwendung ===
| |
| | |
| NDP wird von den am IPv6-Netzwerk beteiligten Knoten benutzt, um die Link-Layer-Adresse von anderen am selben Netzwerk hängenden Knoten ausfindig zu machen und zum Aktualisieren der gecachten Adressen.
| |
| | |
| Für alle nicht am selben Netzwerk hängenden Knoten wird NDP benutzt, um einen/den Router zu finden, der die Pakete weiterleiten kann.
| |
| | |
| === Funktionsweise ===
| |
| | |
| Für NDP muss der Knoten für jedes Interface folgende Informationen verwalten:
| |
| | |
| Im Neighbor Cache werden Adressen verwaltet, an die etwas gesendet wurde und die sich im selben Netzwerk befinden. Zu jedem Eintrag einer IPv6-Adresse steht ihre Link-Layer-Adresse.
| |
| | |
| Auch weitere Informationen werden hier verwaltet, wie zum Beispiel Pointer auf Pakete, die auf die Adressauflösung warten, Informationen für die Erreichbarkeitsprüfung oder ob es ein Router ist.
| |
| | |
| Im Destination Cache werden Adressen verwaltet, an die etwas gesendet wurde. Für jeden Eintrag wird, per Link auf den Neighbor Cache, gespeichert, welches der nächste Hop ist, den ein Paket nehmen soll.
| |
| | |
| In der Prefix List werden die Präfixe verwaltet, die auf demselben Netz gültig sind. Jeder Eintrag, außer der zur link-lokalen Adresse, hat ein Ablaufdatum. Somit bleiben nur Netze in der Liste, die von einem Router verkündet werden.
| |
| | |
| In der Default Router List werden alle Router verwaltet, die für das Interface bekannt sind. Die Einträge verweisen auf Einträge im Neighbor Cache.
| |
| | |
| Zusätzlich haben sie ein Ablaufdatum, sodass alte Router verschwinden und nur die erhalten bleiben, die ihre Anwesenheit verkünden.
| |
| | |
| Die Informationen zum Erstellen dieser Listen werden per ICMPv6 (Internet Control Message Protocol V6) ausgetauscht. NDP definiert zu diesem Zweck fünf ICMPv6-Typen.
| |
| | |
| ==== Router- und Präfix-Ermittlung ====
| |
| | |
| Router versenden in gewissen Zeitabständen Router-Advertisement-Nachrichten per Multicast. Die Informationen in diesen Nachrichten werden verwendet, um die Default Router List und die Prefix List zu erstellen.
| |
| | |
| Nach Ablauf der angegebenen Lebenszeit werden die Einträge wieder aus den Listen gelöscht. Dadurch bleiben nur Router eingetragen, die aktiv sind und ihre Anwesenheit periodisch kundtun.
| |
| | |
| Um nicht auf das nächste geplante Router Advertisement warten zu müssen, kann ein Knoten per Router-Solicitation-Nachricht an die Router-Multicast-Adresse ein Router Advertisement erzwingen.
| |
| | |
| Dies ist besonders beim Aktivieren eines neuen Interfaces von Vorteil, um mit der Konfiguration nicht warten zu müssen.
| |
| | |
| ==== Parameterermittlung ====
| |
| | |
| Mit diesem Mechanismus ermitteln Knoten relevante Parameter für den Link (z. B. die für den Link verwendete MTU), an dem sie angeschlossen sind, oder Internet Parameter (wie zum Beispiel den Wert für den Hop Limit), die für ausgehende Pakete verwendet werden müssen.
| |
| | |
| ==== Adress-Autokonfiguration ====
| |
| | |
| Mit diesem Verfahren konfigurieren Netzknoten IPv6-Adressen für ihre Interfaces ohne einen DHCP-Dienst zu nutzen.
| |
| | |
| ==== Bestimmung des nächsten Hops ====
| |
| | |
| Wenn ein Paket versendet werden soll, wird im Destination Cache nachgeschaut, ob für dieses Ziel schon ein Eintrag vorhanden ist. Wenn kein Eintrag existiert, wird anhand der Prefix List und der Default Router List der nächste Hop für das Paket ermittelt.
| |
| | |
| Diese Information wird dann im Destination Cache gespeichert, um dies nicht jedes Mal ermitteln zu müssen.
| |
| | |
| Wenn der neue Eintrag auf einen nichtvorhandenen Eintrag im Neighbor Cache zeigt, wird dieser ebenfalls erzeugt, als unfertig markiert und die Adressauflösung (engl. Address resolution) angestoßen. Das Paket wird in die Queue gestellt und im Neighbor Cache ein Pointer darauf gesetzt.
| |
| | |
| ==== Adressauflösung ====
| |
| | |
| Um die Link-Layer-Adresse eines Knotens zu ermitteln, wird eine Neighbor-Solicitation-Nachricht per IPv6-Multicast an die sog. Solicited Nodes-Adresse des Ziels versendet. Anzumerken ist, dass auf Link-Layer-Ebene ebenfalls Multicast genutzt wird – jeder IPv6-Knoten muss also auf Link-Layer-Ebene nicht nur auf seine originäre feste Adresse (z. B. Ethernet) hören, sondern auch auf eine, auf seiner IPv6-Adresse beruhende, spezifische Multicast-Adresse.
| |
| | |
| Im Neighbor-Solicitation-Paket ist dann die vollständige gesuchte IPv6-Adresse in den Nutzdaten enthalten, und nur der Knoten mit der gleichen Adresse antwortet darauf.
| |
| | |
| Er verschickt eine Neighbor-Advertisement-Nachricht. Die darin enthaltenen Informationen werden im Neighbor Cache gespeichert. Wenn ein Eintrag noch unfertig war, kann er nun als erreichbar markiert werden und die Pakete, auf die er verweist, können ausgelöst werden.
| |
| | |
| Beispiel: Ein IPv6-Host in einem Ethernet-Netzwerk mit einer link-lokalen IPv6-Adresse fe80::021d:e0ff:fe2a:4242 hört auf der Link-Layer-Ebene nicht nur auf die Adresse 00:1d:e0:2a:42:42, sondern auch auf die Ethernet-Multicast-Adresse 33:33:ff:2a:42:42. 33:33 ist dabei der Teil, der ein IPv6 Multicast-Paket kennzeichnet, ff:2a:42:42 identifiziert die eigentliche Gruppe.
| |
| | |
| Das Multicast-Ziel für ein Neighbor-Solicitation-Paket auf IPv6-Ebene ist dann ff02::1:ff2a:4242.
| |
| | |
| ==== Erkennung der Nichterreichbarkeit des Nachbarn ====
| |
| | |
| Um den Neighbor Cache aktuell zu halten, wird versucht herauszufinden, ob die Einträge darin noch aktuell sind. Es gibt dabei verschiedene Wege festzustellen, ob ein Knoten nicht aktiv ist.
| |
| | |
| Solange man TCP-Daten oder TCP-Empfangsbestätigungen erhält, weiß man, dass der Knoten noch erreichbar ist.
| |
| | |
| Wenn ein Eintrag seine Lebenszeit überschreitet, ohne durch Verkehr bestätigt zu werden, wird er als veraltet markiert. Sobald ein Paket versendet werden will, wird der Eintrag als verzögert markiert und für kurze Zeit versucht, ihn durch Verkehr zu bestätigen.
| |
| | |
| Wenn dies nicht passiert, wird erneut eine Neighbor-Solicitation-Nachricht gesendet, um den Knoten aktiv zu testen. Wenn er nicht antwortet, wird er aus dem Neighbor Cache gelöscht.
| |
| | |
| ==== Erkennung doppelter Adressen ====
| |
| | |
| Mit diesem Verfahren ermitteln Netzknoten, ob die Adresse, die sie sich bei der Autokonfiguration gegeben haben, eindeutig ist.
| |
| | |
| ==== Umleitung ====
| |
| | |
| Redirect-Nachrichten werden vom Router verschickt, um andere Knoten über einen besseren ersten Hop für eine Zieladresse zu informieren. Beim Empfangen einer solchen Nachricht wird der Destination Cache aktualisiert. Wenn kein passender Eintrag im Destination Cache gefunden wird, wird ein neuer erstellt.
| |
| | |
| === ICMPv6-Typen ===
| |
| | |
| ==== Router Solicitation – Type 133 ====
| |
| | |
| <div >''Router-Solicitation-Schema''</div>
| |
| | |
| | |
| {|
| |
| |-
| |
| | | '''+'''
| |
| | | '''Bits 0–7'''
| |
| | | '''Bits 8–15'''
| |
| | | '''Bits 16–23'''
| |
| | | '''Bits 24–31'''
| |
| |-
| |
| | | '''0'''
| |
| | | Type
| |
| | | Code
| |
| | colspan="2" | Prüfsumme
| |
| |-
| |
| | | '''32'''
| |
| | colspan="4" | Reserviert
| |
| |-
| |
| | | '''…'''
| |
| | colspan="4" | Optionen
| |
| |-
| |
| |}
| |
| Per Router Solicitation an die Router-Multicast-Adresse werden alle Router im selben Netz aufgefordert, sich zu melden.
| |
| | |
| Der Code dieser Nachricht ist immer 0. Das Feld „Reserviert“ muss vom Sender mit Nullen initialisiert werden und der Empfänger muss es ignorieren.
| |
| | |
| Die einzig mögliche Option ist die Link-Layer-Adresse des Senders. Um bei Protokollerweiterungen keine Probleme zu bekommen, müssen alle unbekannten Optionen ignoriert werden.
| |
| | |
| ==== Router Advertisement – Type 134 ====
| |
| | |
| <div >''Router-Advertisement-Schema''</div>
| |
| | |
| | |
| {|
| |
| |-
| |
| | | '''+'''
| |
| | | '''Bits 0–7'''
| |
| | colspan="3" | '''Bits 8–15'''
| |
| | | '''Bits 16–23'''
| |
| | | '''Bits 24–31'''
| |
| |-
| |
| | | '''0'''
| |
| | | Type
| |
| | colspan="3" | Code
| |
| | colspan="2" | Prüfsumme
| |
| |-
| |
| | | '''32'''
| |
| | | Hop-Limit
| |
| | | M
| |
| | | O
| |
| | | Reserviert
| |
| | colspan="2" | Router-Lifetime
| |
| |-
| |
| | | '''64'''
| |
| | colspan="6" | Erreichbarkeits-Timeout
| |
| |-
| |
| | | '''96'''
| |
| | colspan="6" | Auflösungs-Timeout
| |
| |-
| |
| | | '''…'''
| |
| | colspan="6" | Optionen
| |
| |-
| |
| |}
| |
| Per Router Advertisement verkünden Router ihre Anwesenheit im Netz. Entweder auf Anfrage per Router Solicitation oder periodisch, um nicht vergessen zu werden.
| |
| | |
| Das Hop-Limit ist ein 8-Bit-Wert, der die vom Router vorgeschlagene Standard-Hop-Limits enthält. Ein gesetztes M-Bit sagt dem Knoten, dass er neben Autokonfiguration für die IP-Adresse auch Stateful-Autokonfiguration verwenden soll. Ein gesetztes O-Bit sagt dem Knoten, dass er neben Autokonfiguration für alle Nicht-IP-Adress-Informationen auch Stateful-Autokonfiguration verwenden soll.
| |
| | |
| Die Router-Lifetime ist ein 16-Bit-Integer, der angibt, wie viele Sekunden ein Router in der Default Router List bleiben soll. Das Maximum sind 18,2 Stunden. Ein Wert von 0 besagt, dass der Router kein Default Router ist und nicht in die Default Router List eingetragen werden soll.
| |
| | |
| Das Erreichbarkeits-Timeout ist ein 32-Bit-Integer, der angibt, wie viele Millisekunden ein Eintrag im Neighbor Cache nach dem Empfangen von Daten noch als erreichbar gelten soll. Das Auflösungs-Timeout ist ein 32-Bit-Integer, der angibt, nach wie vielen Millisekunden erneut ein Neighbor Solicitation gesendet werden soll.
| |
| | |
| Gültige Optionen sind die Link-Layer-Adresse des Senders, die MTU des Routers und alle gültigen Präfixe. Um problemfreie Protokollerweiterungen zu ermöglichen, müssen alle unbekannten Optionen ignoriert werden.
| |
| | |
| ==== Neighbor Solicitation – Type 135 ====
| |
| | |
| <div >''Neighbor-Solicitation-Schema''</div>
| |
| | |
| | |
| {|
| |
| |-
| |
| | | '''+'''
| |
| | | '''Bits 0–7'''
| |
| | | '''Bits 8–15'''
| |
| | | '''Bits 16–23'''
| |
| | | '''Bits 24–31'''
| |
| |-
| |
| | | '''0'''
| |
| | | Type
| |
| | | Code
| |
| | colspan="2" | Prüfsumme
| |
| |-
| |
| | | '''32'''
| |
| | colspan="4" | Reserviert
| |
| |-
| |
| | | '''64'''
| |
| | colspan="4" | Zieladresse
| |
| |-
| |
| || '''96'''
| |
| |-
| |
| || '''128'''
| |
| |-
| |
| || '''160'''
| |
| |-
| |
| | | '''…'''
| |
| | colspan="4" | Optionen
| |
| |-
| |
| |}
| |
| Per Neighbor Solicitation (soviel wie Nachbar Anfrage) an die Link-Layer-Multicast-Adresse einer IPv6-Adresse, die aus der Multicast-Adresse der betreffenden IPv6-Adresse mittels Adress-Mapping der letzten 3 Byte xx:yy:zz der Solicited-Node Multicast Adresse auf die letzten 3 Byte der Link-Layer Adresse 33:33:FF:xx:yy:zz berechnet wird, werden IPv6-Adressen zu Link-Layer-Adressen aufgelöst. Ebenfalls wird so die Erreichbarkeit eines Knotens geprüft.
| |
| | |
| Der Typ wird auf 135 gesetzt und der Code auf 0. Das reservierte Feld muss vom Sender mit Nullen initialisiert und vom Empfänger ignoriert werden. Die Zieladresse ist die IPv6-Adresse, die in eine Link-Layer-Adresse aufgelöst werden soll. Es darf keine Multicast-Adresse angegeben werden.
| |
| | |
| Die einzig mögliche Option ist die Link-Layer-Adresse des Senders. Um bei Protokollerweiterungen keine Probleme zu bekommen, müssen alle unbekannten Optionen ignoriert werden.
| |
| | |
| ==== Neighbor Advertisement – Type 136 ====
| |
| | |
| <div >''Neighbor-Advertisement-Schema''</div>
| |
| | |
| | |
| {|
| |
| |-
| |
| | | '''+'''
| |
| | colspan="4" | '''Bits 0–7'''
| |
| | | '''Bits 8–15'''
| |
| | | '''Bits 16–23'''
| |
| | | '''Bits 24–31'''
| |
| |-
| |
| | | '''0'''
| |
| | colspan="4" | Type
| |
| | | Code
| |
| | colspan="2" | Prüfsumme
| |
| |-
| |
| | | '''32'''
| |
| | | R
| |
| | | S
| |
| | | O
| |
| | | Reserviert
| |
| | colspan="3" | Reserviert
| |
| |-
| |
| | | '''64'''
| |
| | colspan="7" | Zieladresse
| |
| |-
| |
| || '''96'''
| |
| |-
| |
| || '''128'''
| |
| |-
| |
| || '''160'''
| |
| |-
| |
| | | '''…'''
| |
| | colspan="7" | Optionen
| |
| |-
| |
| |}
| |
| Mit einer Neighbor-Advertisement-Nachricht wird auf Neighbor-Solicitation-Nachrichten geantwortet.
| |
| | |
| Der Typ wird auf 136 gesetzt und der Code auf 0. Das R-Bit wird gesetzt, wenn der Knoten ein Router ist. Das S-Bit wird gesetzt, wenn das Neighbor Advertisement aufgrund einer Unicast-Neighbor-Solicitation-Nachricht gesendet wird.
| |
| | |
| Ein gesetztes O-Bit bedeutet, dass der Eintrag im Neighbor Cache aktualisiert werden muss. Das reservierte Feld muss vom Sender mit Nullen initialisiert werden und vom Empfänger ignoriert werden. Als Zieladresse wird die Link-Layer-Adresse angegeben, nach der gefragt wurde.
| |
| | |
| Die einzig mögliche Option ist die Link-Layer-Adresse des Senders. Um bei Protokollerweiterungen keine Probleme zu bekommen, müssen alle unbekannten Optionen ignoriert werden.
| |
| | |
| ==== Redirect – Type 137 ====
| |
| | |
| <div >''Redirect-Schema''</div>
| |
| | |
| | |
| {|
| |
| |-
| |
| | | '''+'''
| |
| | | '''Bits 0–7'''
| |
| | | '''Bits 8–15'''
| |
| | | '''Bits 16–23'''
| |
| | | '''Bits 24–31'''
| |
| |-
| |
| | | '''0'''
| |
| | | Type
| |
| | | Code
| |
| | colspan="2" | Prüfsumme
| |
| |-
| |
| | | '''32'''
| |
| | colspan="4" | Reserviert
| |
| |-
| |
| | | '''64'''
| |
| | colspan="4" | Hop-Adresse
| |
| |-
| |
| || '''96'''
| |
| |-
| |
| || '''128'''
| |
| |-
| |
| || '''160'''
| |
| |-
| |
| | | '''192'''
| |
| | colspan="4" | Zieladresse
| |
| |-
| |
| || '''224'''
| |
| |-
| |
| || '''256'''
| |
| |-
| |
| || '''288'''
| |
| |-
| |
| | | '''…'''
| |
| | colspan="4" | Optionen
| |
| |-
| |
| |}
| |
| Per Redirect-Nachricht teilen Router mit, wenn es einen besseren ersten Hop für ein gewisses Ziel gibt.
| |
| | |
| Der Typ wird auf 137 gesetzt und der Code auf 0. Das reservierte Feld muss vom Sender mit Nullen initialisiert werden und vom Empfänger ignoriert werden. Die Hop-Adresse ist der zu bevorzugende Router für die Adresse. Die Zieladresse ist die Adresse für die es einen besseren First-Hop gibt.
| |
| | |
| Die einzigen möglichen Optionen sind die Link-Layer-Adresse des Senders und der Header des auslösenden Paketes. Um bei Protokollerweiterungen keine Probleme zu bekommen, müssen alle unbekannten Optionen ignoriert werden.
| |
| | |
| === Implementierung in Betriebssystemen ===
| |
| | |
| Alle IPv6-fähigen Betriebssysteme, die in Ethernet-basierten Netzwerken betrieben werden, sind in der Lage, mittels NDP Adressen aufzulösen.
| |
| | |
| Unter den meisten Linux-Distributionen erhält man mit dem iproute2-Werkzeug Einsicht in den Neighbor Cache:
| |
| | |
| <nowiki># ip -6 neigh</nowiki>
| |
| 2001:470:1f0b:2f2:5cad:a77f:aaff:849 dev wlan0 lladdr 00:11:25:32:10:ab REACHABLE
| |
| fe80::2a10:7bff:fe65:58a dev wlan0 lladdr 28:10:7b:65:ab:cd router REACHABLE
| |
| 2001:470:1f0b:2f2::cafe dev wlan0 lladdr 00:11:25:32:10:ab REACHABLE
| |
| | |
| Auf vielen BSD-basierten Systemen wie FreeBSD und OpenBSD hilft hierbei das Werkzeug ndp, wobei die Optionen '-an' bedeuten, dass alle Hosts numerisch angezeigt werden sollen; hier bei FreeBSD 9 (die Kommentare rechts wurden selbstverständlich nachträglich eingefügt):
| |
| | |
| <nowiki># ndp -an</nowiki>
| |
| Neighbor Linklayer Address Netif Expire S Flags
| |
| 2001:475:abcd:2f2:3189:67c1:b550:9400 c6:ab:27:56:b5:30 em0 14s R R <nowiki># <-- Ein anderer Rechner im Netzwerk, mit Privacy Extensions</nowiki>
| |
| 2001:475:abcd:2f2:211:25ff:fe32:10ab 00:11:25:32:10:ab em0 permanent R
| |
| fe80::211:25ff:fe32:10ab%em0 00:11:25:32:10:ab em0 permanent R
| |
| 2001:475:abcd:2f2::cafe 00:11:25:32:10:ab em0 permanent R <nowiki># <-- Alias-Adresse</nowiki>
| |
| fe80::2a10:7bff:fe65:58a%em0 28:10:7b:65:ab:cd em0 23h59m25s S R <nowiki># <-- Das ist der Router</nowiki>
| |
| 2001:475:abcd:2f2:5cad:a77f:aaff:849 00:11:25:32:10:ab em0 permanent R
| |
| fe80::c6ab:27ff:fe56:b530%em0 c6:ab:27:56:b5:30 em0 24s R R <nowiki># <-- Derselbe Rechner wie in der ersten Zeile mit seiner link-local address</nowiki>
| |
| | |
| Hierbei ist insbesondere die Spalte Expire zu beachten. Sie legt fest, wann ein Namenseintrag als veraltet einzustufen ist. Die Adressen des Rechners selbst sind dabei permanent, der Router liegt hier bei fast 24 Stunden und die Nachbargeräte im Netzwerk liegen zumeist bei unter einer Minute, bis der Eintrag wieder aufgefrischt wird.
| |
| | |
| Unter Windows lautet der Befehl:
| |
| | |
| <nowiki># netsh interface ipv6 show neighbors level=verbose</nowiki>
| |
| | |
| === Weblinks ===
| |
| | |
| * RFC 4861 – Neighbor Discovery for IP Version 6 (IPv6) https://tools.ietf.org/html/rfc4861
| |
| * RFC 3122 – Extensions to IPv6 Neighbor Discovery for Inverse Discovery Specification https://tools.ietf.org/html/rfc3122
| |
topic - Kurzbeschreibung
Beschreibung
Autokonfiguration
Stateless Address Autoconfiguration
Umnummerierung und Multihoming
IPv6/Multihoming
Mobile IPv6
Mobile IP wurde als Erweiterung des IPv6-Standards unter dem Namen „Mobile IPv6“ (RFC 6275) in IPv6 integriert.
Überall unter der gleichen IP-Adresse erreichbar
Die Kommunikation erfolgt dabei virtuell immer unabhängig von der aktuellen Position der Knotenpunkte.
Somit erlaubt Mobile IP Endgeräten, überall unter der gleichen IP-Adresse erreichbar zu sein, beispielsweise im heimischen Netzwerk und auf einer Konferenz.
Home Agent
Normalerweise müssten dazu aufwändig Routing-Tabellen geändert werden. Mobile IPv6 benutzt stattdessen einen Schatten-Rechner („Home Agent“), der das Mobilgerät in seinem Heimnetz vertritt.
Eingehende Pakete werden durch diesen Schattenrechner an die momentane Adresse („Care-of-Address“) des Mobilgeräts getunnelt.
Binding Updates
Der Home Agent bekommt die aktuelle Care-of-Address des Mobilgerätes durch „Binding Updates“ mitgeteilt, die das Gerät an den Home Agent sendet, sobald es eine neue Adresse im besuchten Fremdnetz erhalten hat.
IPv4
Mobile IP ist auch für IPv4 spezifiziert.
Im Gegensatz zu dieser Spezifikation benötigt Mobile IPv6 jedoch keinen Foreign Agent, der im Fremdnetz die Anwesenheit von Mobilgeräten registriert.
Mobilität eines Knotens (Node Mobility)
Die Unterstützung für IPv6-Mobilität in Linux kann durch die Installation der MIPL2-Implementierung aktviert werden, welche hier zu finden ist: http://www.mobile-ipv6.org/
Diese Implementierung ist konform zur RFC 3775. Sie besteht aus einem Kernel-Patch und einen Mobilitäts-Daemon (genannt mip6d). Die Version 2.0.1 passt für Linux kernel 2.6.15.
Installation und Setup sind im Linux Mobile IPv6 HOWTO beschrieben.
Netzwerk-Mobililtät
Zusätzlich existiert die Implementierung der Netzwerk-Mobilität für Linux, genannt NEPL, und basiert auf MIPL. Diese steht auch zur Verfügung unter: http://www.mobile-ipv6.org/.
Folgendes HOWTO Dokument beschreibt Setup und Konfiguration: http://www.nautilus6.org/doc/nepl-howto/.
IPv6/Header
Maximum Transmission Unit
Maximum Transmission Unit
Erweiterte ICMP-Funktionalität
Unverzichtbar
ICMPv6 (Protokolltyp 58) stellt für das Funktionieren von IPv6 unverzichtbare Funktionen zur Verfügung.
Das Verbieten aller ICMPv6-Pakete in einem IPv6-Netzwerk durch Filter ist daher im Normalfall nicht durchführbar.
ARP und NDP
Insbesondere wird das Address Resolution Protocol (ARP) durch das Neighbor Discovery Protocol (NDP) ersetzt, welches auf ICMPv6 basiert. * macht hierbei intensiv Gebrauch von Link-Local-Unicast-Adressen und Multicast
- das von jedem Host beherrscht werden muss
Default-Routen
Im Rahmen des NDP werden auch die automatische Adressvergabe und die automatische Zuordnung einer oder mehrerer Default-Routen über ICMPv6 abgewickelt, so stellt es die meisten Funktionen zur Verfügung, die oben unter IPv6-Autokonfiguration erklärt wurden.
NDP kann auf die Möglichkeit weiterer Konfiguration durch DHCPv6 verweisen, welches UDP-Pakete benutzt.
Fragmentierung
- Fragmentierung überlanger IPv6-Pakete erfolgt nicht mehr durch die Router
- Absender wird mit Hilfe von ICMPv6-Nachrichten aufgefordert, kleinere Pakete zu schicken
- auch unter Zuhilfenahme des Fragment Extension Headers
- Path MTU Discovery
Idealerweise sollte ein IPv6-Host, bzw. eine Anwendung vor dem Versenden einer großen Anzahl von IPv6-Paketen eine Path MTU Discovery gemäß RFC 1981 durchführen, um Pakete mit maximal möglicher Größe verschicken zu können.
ICMPv6
| ICMPv6 (Internet Control Message Protocol Version 6)
|
| Familie:
|
Internetprotokolle
|
| Einsatzgebiet:
|
Obligatorischer Zusatz zu IPv6, Fehlermeldungen, Diagnose, Autoconfiguration, Routing
Internet-Protokolle im TCP/IP-Protokollstapel
| Internet
|
ICMPv6
|
| IPv6
|
| Netzzugang
|
Ethernet
|
TokenBus
|
IEEE802.11a/b/g/n
|
FDDI
|
…
|
|
|
|
| Standards:
|
RFC 4443 (2006)
|
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).
Auch wenn ICMPv6 auf derselben Netzwerkschicht ist wie IPv6, werden die ICMPv6-Nachrichten vor dem Versenden in IPv6-Pakete eingepackt und so verschickt.
Als Protokoll-Nummer wird 58 ins Next-Header-Feld des IPv6-Headers eingefügt.
ICMPv6 Header
| +
|
Bits 0–7
|
Bits 8–15
|
Bits 16–23
|
Bits 24–31
|
| 0
|
Type
|
Code
|
Prüfsumme
|
| …
|
ICMPv6-Nachricht …
|
Das Feld Type gibt die Klasse der ICMP-Nachricht an, welche mit dem Feld Code genauer spezifiziert werden kann. Die Prüfsumme wird zum Prüfen der Gültigkeit des ICMPv6-Pakets benutzt.
Der restliche Inhalt der ICMP-Nachricht wird durch den jeweiligen Typ bestimmt.
Dei Fehlernachrichten wird nach den möglichen zusätzlichen Feldern immer noch so viel wie möglich vom fehlerverursachenden Paket angehängt.
ICMPv6-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öchstwertigem 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
|
|
| 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
|
| 200
|
Private experimentation
|
|
| 201
|
Private experimentation
|
|
| 255
|
Reserved for expansion of ICMPv6 informational messages
|
|
Prüfsumme
Prüfsummen-Schema
| +
|
Bits 0–7
|
Bits 8–15
|
Bits 16–23
|
Bits 24–31
|
| 0
|
IPv6-Absender-Adresse
|
| 32
|
| 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.
ICMPv6-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 kommentarlos 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.
ICMP-Standard-Typen
Destination Unreachable – Type 1
Destination-Unreachable-Schema
| +
|
Bits 0–7
|
Bits 8–15
|
Bits 16–23
|
Bits 24–31
|
| 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
| +
|
Bits 0–7
|
Bits 8–15
|
Bits 16–23
|
Bits 24–31
|
| 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 dazu 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
| +
|
Bits 0–7
|
Bits 8–15
|
Bits 16–23
|
Bits 24–31
|
| 0
|
Type
|
Code
|
Prüfsumme
|
| 32
|
Unbenutzt
|
| …
|
Fehlerhaftes Paket
|
Wenn ein Router ein Paket mit einem Hop-Limit von 0 erhält, oder sie auf 0 verkleinert, muss er das Paket verwerfen und ein Time Exceeded mit Code 0 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
| +
|
Bits 0–7
|
Bits 8–15
|
Bits 16–23
|
Bits 24–31
|
| 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
|
Der Pointer zeigt dabei auf die Stelle im Paket, an der das Problem aufgetreten ist.
Echo Request – Type 128
Echo-Request-Schema
| +
|
Bits 0–7
|
Bits 8–15
|
Bits 16–23
|
Bits 24–31
|
| 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 auf Echo Requests reagieren und mit Echo Replies antworten. Auch sollte jedes System eine Anwendung zum Versenden und Empfangen von Echo Request/Replies besitzen.
Empfangene Echo Request können an Anwendungen weitergeleitet werden, die auf ICMP-Nachrichten horchen.
Echo Reply – Type 129
Echo-Reply-Schema
| +
|
Bits 0–7
|
Bits 8–15
|
Bits 16–23
|
Bits 24–31
|
| 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-Steams akzeptabel sind. Linux unterstützt es seit 2003 (2.5.68), Windows seit 2006 (Vista), FreeBSD seit 2009 (8.0)
Weblinks
Address Resolution Protocol
Address Resolution Protocol
Neighbor Discovery Protocol
Neighbor Discovery Protocol