Diskussion:IPv6/ICMP: Unterschied zwischen den Versionen
Die Seite wurde neu angelegt: „== 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 hi…“ |
K Dirkwagner verschob die Seite Diskussion:ICMPv6 nach Diskussion:IPv6/ICMP |
||
(Eine dazwischenliegende Version desselben Benutzers wird nicht angezeigt) | |||
Zeile 563: | Zeile 563: | ||
* IANA ICMP Parameters – vollständige Liste der ICMPv6-Typen und -Codes http://www.iana.org/assignments/icmpv6-parameters | * IANA ICMP Parameters – vollständige Liste der ICMPv6-Typen und -Codes http://www.iana.org/assignments/icmpv6-parameters | ||
* RFC 4890 – Recommendations for Filtering ICMPv6 Messages in Firewalls https://tools.ietf.org/html/rfc4890 | * RFC 4890 – Recommendations for Filtering ICMPv6 Messages in Firewalls https://tools.ietf.org/html/rfc4890 | ||
=== TMP === | |||
IPv6 | |||
ICMPv6 | |||
ICMPv6 - Bedeutung | |||
Internet Control Message Protocol for the Internet Protocol Version 6 (ICMPv6) | |||
* ist die mit IPv6 zusammen verwendete Version des Internet Control Message Protocol | |||
Meldungen | |||
* Es dient, wie ICMPv4 bei IPv4, in Netzwerken zum Austausch von Fehler- und | |||
Informationsmeldungen | |||
NDP | |||
* Zusätzlich findet es im Neighbor Discovery Protocol, dem Ersatz des Address Resolution Protocol | |||
Verwendung | |||
Bedeutung | |||
* 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) | |||
Transport | |||
* ICMPv6-Nachrichten werden vor dem Versenden in IPv6-Pakete eingepackt und so verschickt | |||
** Auch wenn ICMPv6 auf derselben Netzwerkschicht ist wie IPv6 | |||
Protokoll-Nummer | |||
* Als Protokoll-Nummer wird 58 ins Next-Header-Feld des IPv6-Headers eingefügt | |||
IPv6 - ICMPv6 Dirk Wagner Berlin 2 | |||
ICMPv6 im Protokollstapel | |||
IPv6 - ICMPv6 Dirk Wagner Berlin 3 | |||
Erweiterte ICMP-Funktionalität | |||
Unverzichtbar | |||
* ICMPv6 (Protokolltyp 58) stellt für das Funktionieren von IPv6 unverzichtbare Funktionen zur | |||
Verfügung | |||
Firewalls | |||
* 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 | |||
* NDP 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 IPv6-Autokonfiguration zur Verfügung | |||
* NDP kann auf die Möglichkeit weiterer Konfiguration durch DHCPv6 verweisen, welches UDP- | |||
Pakete benutzt | |||
IPv6 - ICMPv6 Dirk Wagner Berlin 4 | |||
Erweiterte ICMP-Funktionalität | |||
Fragmentierung | |||
* Fragmentierung überlanger IPv6-Pakete erfolgt nicht durch die Router | |||
** Anders als bei IPv4 | |||
* Absender werden mit Hilfe von ICMPv6-Nachrichten aufgefordert, kleinere Pakete zu schicken | |||
** unter Zuhilfenahme des Fragment Extension Headers | |||
Path MTU Discovery | |||
* Ein IPv6-Host, bzw. eine Anwendung sollte 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 | |||
IPv6 - ICMPv6 Dirk Wagner Berlin 5 | |||
ICMPv6-Header | |||
Type | |||
* Das Feld Type gibt die Klasse der ICMP-Nachricht an | |||
Code | |||
* welche mit dem Feld Code genauer spezifiziert werden kann | |||
Prüfsumme | |||
* Die Prüfsumme wird zum Prüfen der Gültigkeit des ICMPv6-Pakets benutzt | |||
Inhalt | |||
* 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 | |||
IPv6 - ICMPv6 Dirk Wagner Berlin 6 | |||
ICMPv6-Typen | |||
Nachrichten-Typen werden in zwei Gruppen unterteilt | |||
Fehlernachrichten | |||
* Die ersten 128 Typen (0–127) mit dem höchstwertigen Bit (engl. most significant bit) auf 0 | |||
Informationsnachrichten | |||
* Die zweiten 128 Typen (128–255), mit dem höchstwertigem Bit auf 1 | |||
IPv6 - ICMPv6 Dirk Wagner Berlin 7 | |||
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 | |||
IPv6 - ICMPv6 Dirk Wagner Berlin 8 | |||
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 | |||
IPv6 - ICMPv6 Dirk Wagner Berlin 9 | |||
Informationsnachrichten | |||
Type Beschreibung RFC | |||
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 RFC 4065 Seamoby | |||
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 | |||
IPv6 - ICMPv6 Dirk Wagner Berlin 10 | |||
Prüfsumme | |||
Die Prüfsumme (engl. checksum) eines ICMPv6-Pakets | |||
* ist ein 16-Bit-Einerkomplement der Summe des Einerkomplements der gesamten ICMPv6- | |||
Nachricht | |||
** 'Einerkomplement' ist eine arithmetische Operation, bei der alle Bit invertiert werden (arithmetische Nicht- | |||
Verknüpfung) | |||
** Aus 0 wird 1 und umgekehrt | |||
** Siehe: https://de.wikipedia.org/wiki/Einerkomplement | |||
Pseudoheader | |||
* Zusätzlich zur Nachricht wird noch ein IPv6-Pseudoheader angehängt | |||
** Neuerungen gegenüber ICMP, wo die Prüfsumme nur über den ICMP-Header berechnet wurde | |||
* Zur Berechnung der Prüfsumme wird das Prüfsummenfeld auf 0 gesetzt | |||
* Pseudoheader zur Berechnung der Prüfsumme: | |||
IPv6 - ICMPv6 Dirk Wagner Berlin 11 | |||
ICMPv6 - Verarbeitung | |||
Regeln für die Verarbeitung von ICMPv6-Nachrichten | |||
Unbekannte ICMPv6 - Fehlernachrichten | |||
* müssen an die darüber liegende 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 | |||
Protokollnummer zum Weiterreichen | |||
* von unbekannten Fehlernachrichten wird aus dem angehängten Originalpaket entnommen | |||
Pakete auf die keine Fehlernachrichten versandt werden | |||
* 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 | |||
IPv6 - ICMPv6 Dirk Wagner Berlin 12 | |||
ICMP-Standard-Typen | |||
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 | |||
Code 0 | |||
* fehlende Route | |||
Code 1 | |||
* administrativ verboten (Firewall) | |||
Code 3 | |||
* Router kann IPv6-Adresse nicht auflösen, oder Problem mit dem Link | |||
Code 4 | |||
* Zielhost hat für ein UDP-Paket keinen Listener | |||
Wenn ein Destination Unreachable empfangen wird, muss es der darüberliegenden | |||
Schicht weitergereicht werden | |||
IPv6 - ICMPv6 Dirk Wagner Berlin 13 | |||
ICMP-Standard-Typen | |||
Packet Too Big | |||
** Type 2 | |||
* 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 | |||
Code | |||
* sollte vom Sender auf 0 gesetzt und vom Empfänger ignoriert werden | |||
Wenn ein Packet Too Big empfangen wird, muss es dem darüber liegenden Layer | |||
weitergereicht werden | |||
IPv6 - ICMPv6 Dirk Wagner Berlin 14 | |||
ICMP-Standard-Typen | |||
Time Exceeded | |||
** Type 3 | |||
Code 0 | |||
* 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 | |||
Code 1 | |||
* 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 | |||
IPv6 - ICMPv6 Dirk Wagner Berlin 15 | |||
ICMP-Standard-Typen | |||
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 | |||
Code | |||
* 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 | |||
Pointer | |||
* Der Pointer zeigt dabei auf die Stelle im Paket, an der das Problem aufgetreten ist | |||
IPv6 - ICMPv6 Dirk Wagner Berlin 16 | |||
ICMP-Standard-Typen | |||
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 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 | |||
IPv6 - ICMPv6 Dirk Wagner Berlin 17 | |||
ICMP-Standard-Typen | |||
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 | |||
Identifikation und der Sequenznummer | |||
* 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 | |||
IPv6 - ICMPv6 Dirk Wagner Berlin 18 | |||
ICMP-Standard-Typen | |||
Multicast Listener Discovery | |||
** Type 130 | |||
MLD ist die Implementation von IGMP (IPv4) in IPv6 | |||
* Es wird genutzt um Multicast Abonnements zu verwalten | |||
MLDv1 IGMPv2 entsprechen MLDv2 IGMPv3 | |||
* Bei den jeweils neueren Versionen lässt sich bestimmen, welche Quell-Adressen für Multicast- | |||
Steams akzeptabel sind | |||
Unterstützung in Betriebsystemen | |||
* Linux unterstützt es seit 2003 (2.5.68), Windows seit 2006 (Vista), FreeBSD seit 2009 (8.0) | |||
IPv6 - ICMPv6 Dirk Wagner Berlin 19 | |||
Weblinks | |||
RFC 4861 | |||
** Neighbor Discovery for IP Version 6 (IPv6) | |||
* https://tools.ietf.org/html/rfc4861 | |||
RFC 4443 | |||
** Internet Control Message Protocol (ICMPv6) for the Internet Protocol | |||
Version 6 (IPv6) Specification | |||
* https://tools.ietf.org/html/rfc4443 | |||
RFC 3122 | |||
** Extensions to IPv6 Neighbor Discovery for Inverse Discovery | |||
Specification | |||
* https://tools.ietf.org/html/rfc3122 | |||
IANA ICMP Parameters | |||
** vollständige Liste der ICMPv6-Typen und -Codes | |||
* http://www.iana.org/assignments/icmpv6-parameters | |||
RFC 4890 | |||
** Recommendations for Filtering ICMPv6 Messages in Firewalls | |||
* https://tools.ietf.org/html/rfc4890 | |||
IPv6 - ICMPv6 Dirk Wagner Berlin 20 | |||
IPv6 | |||
Neighbor Discovery Protocol | |||
Neighbor Discovery Protocol (NDP) | |||
Neighbor Discovery Protocol (NDP) | |||
* Ersatz des Address Resolution Protocol (ARP) von IPv4 für IPv6 | |||
Verwendung | |||
NDP wird von den am IPv6-Netzwerk beteiligten Knoten benutzt | |||
* Link-Layer-Adresse von anderen Knoten ausfindig machen | |||
** die am selben Netzwerk angeschlossen sind | |||
* Aktualisieren zwischengespeicherter Adressen | |||
Router finden, der Pakete weiterleiten kann | |||
* Für alle nicht am selben Netzwerk hängenden Knoten | |||
IPv6 - ICMPv6 Dirk Wagner Berlin 22 | |||
Neighbor Discovery Protocol (NDP) | |||
Funktionsweise In der Default Router List | |||
* Für NDP muss der Knoten für jedes Interface * werden alle Router verwaltet, die für das | |||
folgende Informationen verwalten Interface bekannt sind. Die Einträge | |||
verweisen auf Einträge im Neighbor Cache | |||
Im Neighbor Cache * Zusätzlich haben sie ein Ablaufdatum | |||
* werden Adressen verwaltet, an die etwas gesendet sodass alte Router verschwinden und nur | |||
wurde und die sich im selben Netzwerk befinden. die erhalten bleiben, die ihre Anwesenheit | |||
Zu jedem Eintrag einer IPv6-Adresse steht ihre verkünden | |||
Link-Layer-Adresse | |||
* Auch weitere Informationen werden hier verwaltet, NDP ICMPv6-Typen | |||
wie zum Beispiel Pointer auf Pakete, die auf die | |||
Adressauflösung warten, Informationen für die * Die Informationen zum Erstellen dieser | |||
Erreichbarkeitsprüfung oder ob es ein Router ist. Listen werden per ICMPv6 (Internet Control | |||
Message Protocol V6) ausgetauscht. NDP | |||
Im Destination Cache definiert zu diesem Zweck fünf ICMPv6- | |||
* werden Adressen verwaltet, an die etwas gesendet Typen | |||
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 | |||
IPv6 - ICMPv6 Dirk Wagner Berlin 23 | |||
Neighbor Discovery Protocol (NDP) | |||
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 | |||
IPv6 - ICMPv6 Dirk Wagner Berlin 24 | |||
Neighbor Discovery Protocol (NDP) | |||
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 | |||
IPv6 - ICMPv6 Dirk Wagner Berlin 25 | |||
Neighbor Discovery Protocol (NDP) | |||
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 | |||
IPv6 - ICMPv6 Dirk Wagner Berlin 26 | |||
Neighbor Discovery Protocol (NDP) | |||
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 | |||
IPv6 - ICMPv6 Dirk Wagner Berlin 27 | |||
Neighbor Discovery Protocol (NDP) | |||
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 | |||
IPv6 - ICMPv6 Dirk Wagner Berlin 28 | |||
Neighbor Discovery Protocol (NDP) | |||
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 | |||
IPv6 - ICMPv6 Dirk Wagner Berlin 29 | |||
ICMPv6-Typen | |||
Router Solicitation | |||
** Type 133 | |||
* 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 | |||
IPv6 - ICMPv6 Dirk Wagner Berlin 30 | |||
ICMPv6-Typen | |||
Router Advertisement | |||
** Type 134 Das Erreichbarkeits-Timeout | |||
* ist ein 32-Bit-Integer, der angibt, wie viele | |||
Per Router Advertisement Millisekunden ein Eintrag im Neighbor Cache | |||
* verkünden Router ihre Anwesenheit im Netz nach dem Empfangen von Daten noch als | |||
* Entweder auf Anfrage per Router Solicitation oder erreichbar gelten soll | |||
periodisch, um nicht vergessen zu werden | |||
Das Auflösungs-Timeout | |||
Das Hop-Limit | |||
* ist ein 32-Bit-Integer, der angibt, nach wie | |||
* ist ein 8-Bit-Wert, der die vom Router vorgeschlagene | |||
Standard-Hop-Limits enthält. vielen Millisekunden erneut ein Neighbor | |||
Solicitation gesendet werden soll | |||
Ein gesetztes M-Bit | |||
* sagt dem Knoten, dass er neben Autokonfiguration für die Gültige Optionen | |||
IP-Adresse auch Stateful-Autokonfiguration verwenden * sind die Link-Layer-Adresse des Senders, die | |||
soll | |||
MTU des Routers und alle gültigen Präfixe | |||
Ein gesetztes O-Bit | |||
* sagt dem Knoten, dass er neben Autokonfiguration für Um problemfreie Protokoll-erweiterungen zu | |||
alle Nicht-IP-Adress-Informationen auch Stateful- ermöglichen, müssen alle unbekannten Optionen | |||
Autokonfiguration verwenden soll. ignoriert werden | |||
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 | |||
IPv6 - ICMPv6 Dirk Wagner Berlin 31 | |||
ICMPv6-Typen | |||
Router Advertisement | |||
** Type 134 | |||
IPv6 - ICMPv6 Dirk Wagner Berlin 32 | |||
ICMPv6-Typen | |||
Neighbor Solicitation | |||
** Type 135 | |||
Per Neighbor Solicitation | |||
* (Nachbar Anfrage) an die Link-Layer-Multicast- | |||
Adresse einer Ipv6-Adresse werden IPv6- | |||
Adressen zu Link-Layer-Adressen aufgelöst | |||
* Ebenfalls wird so die Erreichbarkeit eines | |||
Knotens geprüft | |||
Link-Layer-Multicast-Adresse | |||
Zieladresse | |||
* werden aus der Multicast-Adresse der | |||
betreffenden IPv6-Adresse mittels Adress- | |||
* IPv6-Adresse, die in eine Link-Layer- | |||
Mapping berechnet Adresse aufgelöst werden soll | |||
* Die letzten 3 Byte xx:yy:zz der Solicited-Node * Es darf keine Multicast-Adresse | |||
Multicast Adresse werden auf die letzten 3 Byte angegeben werden | |||
der Link-Layer Adresse 33:33:FF:xx:yy:zz | |||
gemappt | |||
Einzig mögliche Option | |||
Typ und Code * Link-Layer-Adresse des Senders | |||
* Type wird auf 135 gesetzt und der Code auf 0 | |||
Unbekannten Optionen müssen | |||
Reserviertes Feld ignoriert werden | |||
* muss vom Sender mit Nullen initialisiert und * Um bei Protokollerweiterungen keine | |||
vom Empfänger ignoriert werden Probleme zu bekommenv | |||
IPv6 - ICMPv6 Dirk Wagner Berlin 33 | |||
ICMPv6-Typen | |||
Neighbor Advertisement | |||
** Type 136 | |||
Mit einer Neighbor-Advertisement- | |||
Nachricht | |||
* wird auf Neighbor-Solicitation-Nachrichten | |||
geantwortet | |||
Typ und Code | |||
* Type wird auf 136 gesetzt und der Code auf 0 | |||
R-Bit Reserviertes Feld | |||
* wird gesetzt, wenn der Knoten ein Router ist * muss vom Sender mit Nullen initialisiert | |||
und vom Empfänger ignoriert werden | |||
S-Bit | |||
* wird gesetzt, wenn das Neighbor Zieladresse | |||
Advertisement aufgrund einer Unicast- * Link-Layer-Adresse, die erfragt wurde | |||
Neighbor-Solicitation-Nachricht gesendet wird | |||
O-Bit Option | |||
* bedeutet, dass der Eintrag im Neighbor Cache | |||
* ist die Link-Layer-Adresse des Senders | |||
aktualisiert werden muss * Unbekannten Optionen ignoriert werden | |||
um bei Protokollerweiterungen Probleme | |||
zu vermeiden | |||
IPv6 - ICMPv6 Dirk Wagner Berlin 34 | |||
ICMPv6-Typen | |||
Redirect | |||
** Type 137 | |||
Per Redirect-Nachricht | |||
* teilen Router mit, wenn es einen besseren ersten Hop für ein gewisses Ziel gibt | |||
Type und Code | |||
* 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 | |||
IPv6 - ICMPv6 Dirk Wagner Berlin 35 | |||
Implementierung in Betriebssystemen | |||
Alle IPv6-fähigen Betriebssysteme sind in der Lage mit NDP Adressen | |||
aufzulösen | |||
Unter Linux erhält man mit dem iproute2-Werkzeug Einsicht in den Neighbor Cache | |||
ip -6 neigh | |||
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 | |||
IPv6 - ICMPv6 Dirk Wagner Berlin 36 | |||
Implementierung in Betriebssystemen | |||
Alle IPv6-fähigen Betriebssysteme sind in der Lage mit NDP Adressen aufzulösen | |||
Auf BSD-basierten Systemen hilft hierbei das Werkzeug ndp | |||
* wobei die Optionen '-an' bedeuten, dass alle Hosts numerisch angezeigt werden sollen; hier bei FreeBSD 9 | |||
ndp -an | |||
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 | |||
# <-- Rechner mit Privacy Extensions | |||
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 | |||
# <-- Alias-Adresse | |||
fe80::2a10:7bff:fe65:58a%em0 28:10:7b:65:ab:cd em0 23h59m25s S R | |||
# <-- Router | |||
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 | |||
# <-- link-local address | |||
Hierbei ist insbesondere die Spalte Expire zu beachten | |||
* 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 | |||
IPv6 - ICMPv6 Dirk Wagner Berlin 37 | |||
Implementierung in Betriebssystemen | |||
Alle IPv6-fähigen Betriebssysteme sind in der Lage mit NDP Adressen | |||
aufzulösen | |||
Unter Windows lautet der Befehl | |||
netsh interface ipv6 show neighbors level=verbose | |||
IPv6 - ICMPv6 Dirk Wagner Berlin 38 | |||
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 | |||
IPv6 - ICMPv6 Dirk Wagner Berlin 39 | |||
IPv6 | |||
Autokonfiguration | |||
Autokonfiguration | |||
Stateless Address Autoconfiguration | |||
* (SLAAC, zustandslose Adressenautokonfiguration, spezifiziert in RFC 4862) | |||
Ein Host kann vollautomatisch eine funktionsfähige Internetverbindung aufbauen | |||
* Dazu kommuniziert er mit den für sein Netzwerksegment zuständigen Routern | |||
* um die notwendige Konfiguration zu ermitteln | |||
IPv6 - Einführung Dirk Wagner Berlin 41 | |||
IPv6 Autokonfiguration: Plug & Play | |||
IPv6 - ICMPv6 Dirk Wagner Berlin 42 | |||
Autokonfiguration | |||
Ablauf | |||
link-lokale Adresse | |||
* Zur initialen Kommunikation mit dem Router weist sich der Host eine link-lokale Adresse zu, die im Falle | |||
einer Ethernet-Schnittstelle etwa aus deren Hardware-Adresse berechnet werden kann | |||
Router Solicitation | |||
* Damit kann ein Gerät sich mittels des Neighbor Discovery Protocols (NDP, siehe auch ICMPv6- | |||
Funktionalität) auf die Suche nach den Routern in seinem Netzwerksegment machen | |||
* Dies geschieht durch eine Anfrage an die Multicast-Adresse ff02::2, über die alle Router eines Segments | |||
erreichbar sind (Router Solicitation) | |||
* Ein Router versendet auf eine solche Anfrage hin Information zu verfügbaren Präfixen, also Information | |||
über die Adressbereiche, aus denen ein Gerät sich selbst Unicast-Adressen zuweisen darf | |||
Router Advertisements | |||
* Die Pakete, die diese Informationen tragen, werden Router Advertisements genannt. Sie besitzen | |||
ICMPv6-Typ 134 (0x86) und besitzen Informationen über die Lifetime, die MTU und das Präfix des | |||
Netzwerks | |||
* An einen solchen Präfix hängt der Host den auch für die link-lokale Adresse verwendeten Interface- | |||
Identifier an | |||
Duplicate Address Detection | |||
* Um die doppelte Vergabe einer Adresse zu verhindern, ist der Mechanismus Duplicate Address Detection | |||
(DAD ** Erkennung doppelt vergebener Adressen) vorgesehen | |||
* Ein Gerät darf bei der Autokonfiguration nur unvergebene Adressen auswählen. Der DAD-Vorgang läuft | |||
ebenfalls ohne Benutzereingriff via NDP ab | |||
IPv6 - ICMPv6 Dirk Wagner Berlin 43 | |||
Autokonfiguration | |||
Gültigkeitsangaben | |||
Valid Lifetime und Preferred Lifetime | |||
* Router können bei der Vergabe von Adresspräfixen begrenzte Gültigkeitszeiten mitgeben: Valid | |||
Lifetime und Preferred Lifetime | |||
* Innerhalb der Valid Lifetime darf der angegebene Präfix zur Kommunikation verwendet werden | |||
* innerhalb der Preferred Lifetime soll dieser Präfix einem anderen, dessen Valid Lifetime schon | |||
abgelaufen ist, vorgezogen werden | |||
Router Advertisements | |||
* Router verschicken regelmäßig Router Advertisements an alle Hosts in einem Netzsegment, für | |||
das sie zuständig sind, mittels derer die Präfix-Gültigkeitszeiten aufgefrischt werden; durch | |||
Änderung der Advertisements können Hosts umnummeriert werden | |||
* Sind die Router Advertisements nicht über IPsec authentifiziert, ist die Herabsetzung der | |||
Gültigkeitszeit eines einem Host bereits bekannten Präfixes auf unter zwei Stunden jedoch nicht | |||
möglich | |||
IPv6 - ICMPv6 Dirk Wagner Berlin 44 | |||
IPv6 Autokonfiguration: Neighbor Discovery | |||
IPv6 - ICMPv6 Dirk Wagner Berlin 45 | |||
IPv6 | |||
Autokonfiguration | |||
Neuer Host konfiguriert lokale Adresse | |||
Lokale Adresse wird per Neighbor-Discovery-Protokoll verifiziert | |||
Host sendet dann Router Solicitation Message mit lokaler Adresse | |||
Router antwortet mit Router Advertisement Message: | |||
* Enthält Informationen zu Adreß-Präfix und globale Adresse des neuen Hosts | |||
(stateful autoconfiguration oder stateless autoconfiguration) | |||
Router Solicitation | |||
Router Advertisement | |||
Router Neuer Host | |||
IPv6 - ICMPv6 Dirk Wagner Berlin 46 | |||
IPv6 Autokonfiguration: Neighbor Discovery | |||
IPv6 - ICMPv6 Dirk Wagner Berlin 47 | |||
IPv6 Autokonfiguration: Neighbor Discovery | |||
IPv6 - ICMPv6 Dirk Wagner Berlin 48 | |||
IPv6 Autokonfiguration: Neighbor Discovery | |||
IPv6 - ICMPv6 Dirk Wagner Berlin 49 | |||
Autokonfiguration und DHCPv6 | |||
Stateful Address Configuration | |||
* Die IPv6-Autokonfiguration unterscheidet sich konzeptionell von DHCP beziehungsweise | |||
DHCPv6 | |||
** Bei der Adressvergabe durch DHCPv6 wird von „Stateful Address Configuration“ gesprochen sinngemäß: | |||
Adressvergabe, über die Buch geführt wird, etwa durch einen DHCP-Server | |||
** definiert in RFC 3315 | |||
* Autokonfiguration ist eine „Stateless Address (Auto)Configuration“ | |||
** Geräte weisen sich selbst eine Adresse zu | |||
** über diese Vergabe wird nicht Buch geführt | |||
Grenzen der Autokonfiguration | |||
* Mittels der Autokonfiguration können an Clients keine Informationen zu Host-, Domainnamen | |||
DNS, NTP-Server etc. mitgeteilt werden, sofern diese nicht spezifische Erweiterungen von NDP | |||
unterstützen | |||
Stateless DHCPv6 | |||
* Als Alternative hat sich der zusätzliche Einsatz eines DHCPv6-Servers etabliert | |||
* Dieser liefert die gewünschten Zusatzinformationen, kümmert sich dabei aber nicht um die | |||
Adressvergabe | |||
* Man spricht in diesem Fall von Stateless DHCPv6 (vgl. RFC 3736) | |||
* Dem Client kann mittels des Managed-Flags in der Antwort auf eine NDP-Router-Solicitation | |||
angezeigt werden, dass er eine DHCPv6-Anfrage stellen und somit die Zusatzinformationen | |||
beziehen soll | |||
IPv6 Autokonfiguration: DHCPv6 |
Aktuelle Version vom 9. November 2024, 11:24 Uhr
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
| |||||||||||||||||
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
+ | 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
+ | 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
+ | 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
+ | 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
+ | 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
+ | 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
+ | 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
- RFC 4861 – Neighbor Discovery for IP Version 6 (IPv6) https://tools.ietf.org/html/rfc4861
- RFC 4443 – Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification https://tools.ietf.org/html/rfc4443
- RFC 3122 – Extensions to IPv6 Neighbor Discovery for Inverse Discovery Specification https://tools.ietf.org/html/rfc3122
- IANA ICMP Parameters – vollständige Liste der ICMPv6-Typen und -Codes http://www.iana.org/assignments/icmpv6-parameters
- RFC 4890 – Recommendations for Filtering ICMPv6 Messages in Firewalls https://tools.ietf.org/html/rfc4890
TMP
IPv6 ICMPv6 ICMPv6 - Bedeutung
Internet Control Message Protocol for the Internet Protocol Version 6 (ICMPv6)
- ist die mit IPv6 zusammen verwendete Version des Internet Control Message Protocol
Meldungen
- Es dient, wie ICMPv4 bei IPv4, in Netzwerken zum Austausch von Fehler- und
Informationsmeldungen
NDP
- Zusätzlich findet es im Neighbor Discovery Protocol, dem Ersatz des Address Resolution Protocol
Verwendung
Bedeutung
- 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)
Transport
- ICMPv6-Nachrichten werden vor dem Versenden in IPv6-Pakete eingepackt und so verschickt
- Auch wenn ICMPv6 auf derselben Netzwerkschicht ist wie IPv6
Protokoll-Nummer
- Als Protokoll-Nummer wird 58 ins Next-Header-Feld des IPv6-Headers eingefügt
IPv6 - ICMPv6 Dirk Wagner Berlin 2 ICMPv6 im Protokollstapel
IPv6 - ICMPv6 Dirk Wagner Berlin 3 Erweiterte ICMP-Funktionalität
Unverzichtbar
- ICMPv6 (Protokolltyp 58) stellt für das Funktionieren von IPv6 unverzichtbare Funktionen zur
Verfügung
Firewalls
- 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
- NDP 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 IPv6-Autokonfiguration zur Verfügung
- NDP kann auf die Möglichkeit weiterer Konfiguration durch DHCPv6 verweisen, welches UDP-
Pakete benutzt
IPv6 - ICMPv6 Dirk Wagner Berlin 4 Erweiterte ICMP-Funktionalität
Fragmentierung
- Fragmentierung überlanger IPv6-Pakete erfolgt nicht durch die Router
- Anders als bei IPv4
- Absender werden mit Hilfe von ICMPv6-Nachrichten aufgefordert, kleinere Pakete zu schicken
- unter Zuhilfenahme des Fragment Extension Headers
Path MTU Discovery
- Ein IPv6-Host, bzw. eine Anwendung sollte 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
IPv6 - ICMPv6 Dirk Wagner Berlin 5 ICMPv6-Header
Type
- Das Feld Type gibt die Klasse der ICMP-Nachricht an
Code
- welche mit dem Feld Code genauer spezifiziert werden kann
Prüfsumme
- Die Prüfsumme wird zum Prüfen der Gültigkeit des ICMPv6-Pakets benutzt
Inhalt
- 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
IPv6 - ICMPv6 Dirk Wagner Berlin 6 ICMPv6-Typen
Nachrichten-Typen werden in zwei Gruppen unterteilt Fehlernachrichten
- Die ersten 128 Typen (0–127) mit dem höchstwertigen Bit (engl. most significant bit) auf 0
Informationsnachrichten
- Die zweiten 128 Typen (128–255), mit dem höchstwertigem Bit auf 1
IPv6 - ICMPv6 Dirk Wagner Berlin 7 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
IPv6 - ICMPv6 Dirk Wagner Berlin 8 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
IPv6 - ICMPv6 Dirk Wagner Berlin 9 Informationsnachrichten
Type Beschreibung RFC
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 RFC 4065 Seamoby 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
IPv6 - ICMPv6 Dirk Wagner Berlin 10 Prüfsumme
Die Prüfsumme (engl. checksum) eines ICMPv6-Pakets
- ist ein 16-Bit-Einerkomplement der Summe des Einerkomplements der gesamten ICMPv6-
Nachricht
- 'Einerkomplement' ist eine arithmetische Operation, bei der alle Bit invertiert werden (arithmetische Nicht-
Verknüpfung)
- Aus 0 wird 1 und umgekehrt
- Siehe: https://de.wikipedia.org/wiki/Einerkomplement
Pseudoheader
- Zusätzlich zur Nachricht wird noch ein IPv6-Pseudoheader angehängt
- Neuerungen gegenüber ICMP, wo die Prüfsumme nur über den ICMP-Header berechnet wurde
- Zur Berechnung der Prüfsumme wird das Prüfsummenfeld auf 0 gesetzt
- Pseudoheader zur Berechnung der Prüfsumme:
IPv6 - ICMPv6 Dirk Wagner Berlin 11 ICMPv6 - Verarbeitung
Regeln für die Verarbeitung von ICMPv6-Nachrichten Unbekannte ICMPv6 - Fehlernachrichten
- müssen an die darüber liegende 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
Protokollnummer zum Weiterreichen
- von unbekannten Fehlernachrichten wird aus dem angehängten Originalpaket entnommen
Pakete auf die keine Fehlernachrichten versandt werden
- 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
IPv6 - ICMPv6 Dirk Wagner Berlin 12 ICMP-Standard-Typen
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
Code 0
- fehlende Route
Code 1
- administrativ verboten (Firewall)
Code 3
- Router kann IPv6-Adresse nicht auflösen, oder Problem mit dem Link
Code 4
- Zielhost hat für ein UDP-Paket keinen Listener
Wenn ein Destination Unreachable empfangen wird, muss es der darüberliegenden Schicht weitergereicht werden IPv6 - ICMPv6 Dirk Wagner Berlin 13 ICMP-Standard-Typen
Packet Too Big
- Type 2
- 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
Code
- sollte vom Sender auf 0 gesetzt und vom Empfänger ignoriert werden
Wenn ein Packet Too Big empfangen wird, muss es dem darüber liegenden Layer weitergereicht werden
IPv6 - ICMPv6 Dirk Wagner Berlin 14 ICMP-Standard-Typen
Time Exceeded
- Type 3
Code 0
- 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
Code 1
- 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
IPv6 - ICMPv6 Dirk Wagner Berlin 15 ICMP-Standard-Typen
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
Code
- 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
Pointer
- Der Pointer zeigt dabei auf die Stelle im Paket, an der das Problem aufgetreten ist
IPv6 - ICMPv6 Dirk Wagner Berlin 16 ICMP-Standard-Typen
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 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
IPv6 - ICMPv6 Dirk Wagner Berlin 17 ICMP-Standard-Typen
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
Identifikation und der Sequenznummer
- 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
IPv6 - ICMPv6 Dirk Wagner Berlin 18 ICMP-Standard-Typen
Multicast Listener Discovery
- Type 130
MLD ist die Implementation von IGMP (IPv4) in IPv6
- Es wird genutzt um Multicast Abonnements zu verwalten
MLDv1 IGMPv2 entsprechen MLDv2 IGMPv3
- Bei den jeweils neueren Versionen lässt sich bestimmen, welche Quell-Adressen für Multicast-
Steams akzeptabel sind
Unterstützung in Betriebsystemen
- Linux unterstützt es seit 2003 (2.5.68), Windows seit 2006 (Vista), FreeBSD seit 2009 (8.0)
IPv6 - ICMPv6 Dirk Wagner Berlin 19 Weblinks
RFC 4861
- Neighbor Discovery for IP Version 6 (IPv6)
- https://tools.ietf.org/html/rfc4861
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
- http://www.iana.org/assignments/icmpv6-parameters
RFC 4890
- Recommendations for Filtering ICMPv6 Messages in Firewalls
- https://tools.ietf.org/html/rfc4890
IPv6 - ICMPv6 Dirk Wagner Berlin 20 IPv6 Neighbor Discovery Protocol Neighbor Discovery Protocol (NDP)
Neighbor Discovery Protocol (NDP)
- Ersatz des Address Resolution Protocol (ARP) von IPv4 für IPv6
Verwendung NDP wird von den am IPv6-Netzwerk beteiligten Knoten benutzt
- Link-Layer-Adresse von anderen Knoten ausfindig machen
- die am selben Netzwerk angeschlossen sind
- Aktualisieren zwischengespeicherter Adressen
Router finden, der Pakete weiterleiten kann
- Für alle nicht am selben Netzwerk hängenden Knoten
IPv6 - ICMPv6 Dirk Wagner Berlin 22 Neighbor Discovery Protocol (NDP)
Funktionsweise In der Default Router List
- Für NDP muss der Knoten für jedes Interface * werden alle Router verwaltet, die für das
folgende Informationen verwalten Interface bekannt sind. Die Einträge verweisen auf Einträge im Neighbor Cache Im Neighbor Cache * Zusätzlich haben sie ein Ablaufdatum
- werden Adressen verwaltet, an die etwas gesendet sodass alte Router verschwinden und nur
wurde und die sich im selben Netzwerk befinden. die erhalten bleiben, die ihre Anwesenheit Zu jedem Eintrag einer IPv6-Adresse steht ihre verkünden Link-Layer-Adresse
- Auch weitere Informationen werden hier verwaltet, NDP ICMPv6-Typen
wie zum Beispiel Pointer auf Pakete, die auf die Adressauflösung warten, Informationen für die * Die Informationen zum Erstellen dieser Erreichbarkeitsprüfung oder ob es ein Router ist. Listen werden per ICMPv6 (Internet Control Message Protocol V6) ausgetauscht. NDP Im Destination Cache definiert zu diesem Zweck fünf ICMPv6-
- werden Adressen verwaltet, an die etwas gesendet Typen
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
IPv6 - ICMPv6 Dirk Wagner Berlin 23 Neighbor Discovery Protocol (NDP)
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
IPv6 - ICMPv6 Dirk Wagner Berlin 24 Neighbor Discovery Protocol (NDP)
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
IPv6 - ICMPv6 Dirk Wagner Berlin 25 Neighbor Discovery Protocol (NDP)
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
IPv6 - ICMPv6 Dirk Wagner Berlin 26 Neighbor Discovery Protocol (NDP)
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
IPv6 - ICMPv6 Dirk Wagner Berlin 27 Neighbor Discovery Protocol (NDP)
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
IPv6 - ICMPv6 Dirk Wagner Berlin 28 Neighbor Discovery Protocol (NDP)
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
IPv6 - ICMPv6 Dirk Wagner Berlin 29 ICMPv6-Typen
Router Solicitation
- Type 133
- 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
IPv6 - ICMPv6 Dirk Wagner Berlin 30 ICMPv6-Typen
Router Advertisement
- Type 134 Das Erreichbarkeits-Timeout
- ist ein 32-Bit-Integer, der angibt, wie viele
Per Router Advertisement Millisekunden ein Eintrag im Neighbor Cache
- verkünden Router ihre Anwesenheit im Netz nach dem Empfangen von Daten noch als
- Entweder auf Anfrage per Router Solicitation oder erreichbar gelten soll
periodisch, um nicht vergessen zu werden Das Auflösungs-Timeout Das Hop-Limit
- ist ein 32-Bit-Integer, der angibt, nach wie
- ist ein 8-Bit-Wert, der die vom Router vorgeschlagene
Standard-Hop-Limits enthält. vielen Millisekunden erneut ein Neighbor Solicitation gesendet werden soll Ein gesetztes M-Bit
- sagt dem Knoten, dass er neben Autokonfiguration für die Gültige Optionen
IP-Adresse auch Stateful-Autokonfiguration verwenden * sind die Link-Layer-Adresse des Senders, die soll MTU des Routers und alle gültigen Präfixe Ein gesetztes O-Bit
- sagt dem Knoten, dass er neben Autokonfiguration für Um problemfreie Protokoll-erweiterungen zu
alle Nicht-IP-Adress-Informationen auch Stateful- ermöglichen, müssen alle unbekannten Optionen Autokonfiguration verwenden soll. ignoriert werden
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
IPv6 - ICMPv6 Dirk Wagner Berlin 31 ICMPv6-Typen
Router Advertisement
- Type 134
IPv6 - ICMPv6 Dirk Wagner Berlin 32 ICMPv6-Typen
Neighbor Solicitation
- Type 135
Per Neighbor Solicitation
- (Nachbar Anfrage) an die Link-Layer-Multicast-
Adresse einer Ipv6-Adresse werden IPv6- Adressen zu Link-Layer-Adressen aufgelöst
- Ebenfalls wird so die Erreichbarkeit eines
Knotens geprüft
Link-Layer-Multicast-Adresse Zieladresse
- werden aus der Multicast-Adresse der
betreffenden IPv6-Adresse mittels Adress-
- IPv6-Adresse, die in eine Link-Layer-
Mapping berechnet Adresse aufgelöst werden soll
- Die letzten 3 Byte xx:yy:zz der Solicited-Node * Es darf keine Multicast-Adresse
Multicast Adresse werden auf die letzten 3 Byte angegeben werden der Link-Layer Adresse 33:33:FF:xx:yy:zz gemappt Einzig mögliche Option Typ und Code * Link-Layer-Adresse des Senders
- Type wird auf 135 gesetzt und der Code auf 0
Unbekannten Optionen müssen Reserviertes Feld ignoriert werden
- muss vom Sender mit Nullen initialisiert und * Um bei Protokollerweiterungen keine
vom Empfänger ignoriert werden Probleme zu bekommenv IPv6 - ICMPv6 Dirk Wagner Berlin 33 ICMPv6-Typen
Neighbor Advertisement
- Type 136
Mit einer Neighbor-Advertisement- Nachricht
- wird auf Neighbor-Solicitation-Nachrichten
geantwortet
Typ und Code
- Type wird auf 136 gesetzt und der Code auf 0
R-Bit Reserviertes Feld
- wird gesetzt, wenn der Knoten ein Router ist * muss vom Sender mit Nullen initialisiert
und vom Empfänger ignoriert werden S-Bit
- wird gesetzt, wenn das Neighbor Zieladresse
Advertisement aufgrund einer Unicast- * Link-Layer-Adresse, die erfragt wurde Neighbor-Solicitation-Nachricht gesendet wird
O-Bit Option
- bedeutet, dass der Eintrag im Neighbor Cache
- ist die Link-Layer-Adresse des Senders
aktualisiert werden muss * Unbekannten Optionen ignoriert werden um bei Protokollerweiterungen Probleme zu vermeiden
IPv6 - ICMPv6 Dirk Wagner Berlin 34 ICMPv6-Typen
Redirect
- Type 137
Per Redirect-Nachricht
- teilen Router mit, wenn es einen besseren ersten Hop für ein gewisses Ziel gibt
Type und Code
- 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
IPv6 - ICMPv6 Dirk Wagner Berlin 35 Implementierung in Betriebssystemen
Alle IPv6-fähigen Betriebssysteme sind in der Lage mit NDP Adressen aufzulösen Unter Linux erhält man mit dem iproute2-Werkzeug Einsicht in den Neighbor Cache ip -6 neigh 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
IPv6 - ICMPv6 Dirk Wagner Berlin 36 Implementierung in Betriebssystemen
Alle IPv6-fähigen Betriebssysteme sind in der Lage mit NDP Adressen aufzulösen Auf BSD-basierten Systemen hilft hierbei das Werkzeug ndp
- wobei die Optionen '-an' bedeuten, dass alle Hosts numerisch angezeigt werden sollen; hier bei FreeBSD 9
ndp -an 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
- <-- Rechner mit Privacy Extensions
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
- <-- Alias-Adresse
fe80::2a10:7bff:fe65:58a%em0 28:10:7b:65:ab:cd em0 23h59m25s S R
- <-- Router
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
- <-- link-local address
Hierbei ist insbesondere die Spalte Expire zu beachten
- 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
IPv6 - ICMPv6 Dirk Wagner Berlin 37 Implementierung in Betriebssystemen
Alle IPv6-fähigen Betriebssysteme sind in der Lage mit NDP Adressen aufzulösen Unter Windows lautet der Befehl netsh interface ipv6 show neighbors level=verbose
IPv6 - ICMPv6 Dirk Wagner Berlin 38 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
IPv6 - ICMPv6 Dirk Wagner Berlin 39 IPv6 Autokonfiguration Autokonfiguration
Stateless Address Autoconfiguration
- (SLAAC, zustandslose Adressenautokonfiguration, spezifiziert in RFC 4862)
Ein Host kann vollautomatisch eine funktionsfähige Internetverbindung aufbauen
- Dazu kommuniziert er mit den für sein Netzwerksegment zuständigen Routern
- um die notwendige Konfiguration zu ermitteln
IPv6 - Einführung Dirk Wagner Berlin 41 IPv6 Autokonfiguration: Plug & Play
IPv6 - ICMPv6 Dirk Wagner Berlin 42 Autokonfiguration Ablauf
link-lokale Adresse
- Zur initialen Kommunikation mit dem Router weist sich der Host eine link-lokale Adresse zu, die im Falle
einer Ethernet-Schnittstelle etwa aus deren Hardware-Adresse berechnet werden kann
Router Solicitation
- Damit kann ein Gerät sich mittels des Neighbor Discovery Protocols (NDP, siehe auch ICMPv6-
Funktionalität) auf die Suche nach den Routern in seinem Netzwerksegment machen
- Dies geschieht durch eine Anfrage an die Multicast-Adresse ff02::2, über die alle Router eines Segments
erreichbar sind (Router Solicitation)
- Ein Router versendet auf eine solche Anfrage hin Information zu verfügbaren Präfixen, also Information
über die Adressbereiche, aus denen ein Gerät sich selbst Unicast-Adressen zuweisen darf
Router Advertisements
- Die Pakete, die diese Informationen tragen, werden Router Advertisements genannt. Sie besitzen
ICMPv6-Typ 134 (0x86) und besitzen Informationen über die Lifetime, die MTU und das Präfix des Netzwerks
- An einen solchen Präfix hängt der Host den auch für die link-lokale Adresse verwendeten Interface-
Identifier an
Duplicate Address Detection
- Um die doppelte Vergabe einer Adresse zu verhindern, ist der Mechanismus Duplicate Address Detection
(DAD ** Erkennung doppelt vergebener Adressen) vorgesehen
- Ein Gerät darf bei der Autokonfiguration nur unvergebene Adressen auswählen. Der DAD-Vorgang läuft
ebenfalls ohne Benutzereingriff via NDP ab
IPv6 - ICMPv6 Dirk Wagner Berlin 43 Autokonfiguration Gültigkeitsangaben
Valid Lifetime und Preferred Lifetime
- Router können bei der Vergabe von Adresspräfixen begrenzte Gültigkeitszeiten mitgeben: Valid
Lifetime und Preferred Lifetime
- Innerhalb der Valid Lifetime darf der angegebene Präfix zur Kommunikation verwendet werden
- innerhalb der Preferred Lifetime soll dieser Präfix einem anderen, dessen Valid Lifetime schon
abgelaufen ist, vorgezogen werden
Router Advertisements
- Router verschicken regelmäßig Router Advertisements an alle Hosts in einem Netzsegment, für
das sie zuständig sind, mittels derer die Präfix-Gültigkeitszeiten aufgefrischt werden; durch Änderung der Advertisements können Hosts umnummeriert werden
- Sind die Router Advertisements nicht über IPsec authentifiziert, ist die Herabsetzung der
Gültigkeitszeit eines einem Host bereits bekannten Präfixes auf unter zwei Stunden jedoch nicht möglich
IPv6 - ICMPv6 Dirk Wagner Berlin 44 IPv6 Autokonfiguration: Neighbor Discovery
IPv6 - ICMPv6 Dirk Wagner Berlin 45 IPv6 Autokonfiguration
Neuer Host konfiguriert lokale Adresse
Lokale Adresse wird per Neighbor-Discovery-Protokoll verifiziert
Host sendet dann Router Solicitation Message mit lokaler Adresse
Router antwortet mit Router Advertisement Message:
- Enthält Informationen zu Adreß-Präfix und globale Adresse des neuen Hosts
(stateful autoconfiguration oder stateless autoconfiguration)
Router Solicitation Router Advertisement Router Neuer Host
IPv6 - ICMPv6 Dirk Wagner Berlin 46 IPv6 Autokonfiguration: Neighbor Discovery
IPv6 - ICMPv6 Dirk Wagner Berlin 47 IPv6 Autokonfiguration: Neighbor Discovery
IPv6 - ICMPv6 Dirk Wagner Berlin 48 IPv6 Autokonfiguration: Neighbor Discovery
IPv6 - ICMPv6 Dirk Wagner Berlin 49 Autokonfiguration und DHCPv6
Stateful Address Configuration
- Die IPv6-Autokonfiguration unterscheidet sich konzeptionell von DHCP beziehungsweise
DHCPv6
- Bei der Adressvergabe durch DHCPv6 wird von „Stateful Address Configuration“ gesprochen sinngemäß:
Adressvergabe, über die Buch geführt wird, etwa durch einen DHCP-Server
- definiert in RFC 3315
- Autokonfiguration ist eine „Stateless Address (Auto)Configuration“
- Geräte weisen sich selbst eine Adresse zu
- über diese Vergabe wird nicht Buch geführt
Grenzen der Autokonfiguration
- Mittels der Autokonfiguration können an Clients keine Informationen zu Host-, Domainnamen
DNS, NTP-Server etc. mitgeteilt werden, sofern diese nicht spezifische Erweiterungen von NDP unterstützen
Stateless DHCPv6
- Als Alternative hat sich der zusätzliche Einsatz eines DHCPv6-Servers etabliert
- Dieser liefert die gewünschten Zusatzinformationen, kümmert sich dabei aber nicht um die
Adressvergabe
- Man spricht in diesem Fall von Stateless DHCPv6 (vgl. RFC 3736)
- Dem Client kann mittels des Managed-Flags in der Antwort auf eine NDP-Router-Solicitation
angezeigt werden, dass er eine DHCPv6-Anfrage stellen und somit die Zusatzinformationen beziehen soll
IPv6 Autokonfiguration: DHCPv6