IPv6/ICMPv6/Fuktionen

Aus Foxwiki

topic - Kurzbeschreibung

Beschreibung

Autokonfiguration

Stateless Address Autoconfiguration

Umnummerierung und Multihoming

IPv6/Multihoming

Mobile IPv6

IPv6/Mobile IP

Header-Format

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

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

Abgerufen von „https://wiki.foxtom.de/index.php?title=IPv6/ICMPv6/Fuktionen&oldid=89438“