IPv6/ICMPv6/Fuktionen: Unterschied zwischen den Versionen

Aus Foxwiki
Versionsgeschichte interaktiv durchsuchen
← Zum vorherigen Versionsunterschied
VisuellWikitext
K Textersetzung - „Kurzbeschreibung“ durch „Beschreibung“
 
(18 dazwischenliegende Versionen desselben Benutzers werden nicht angezeigt)
Zeile 1: Zeile 1:
'''topic''' - Kurzbeschreibung
'''topic''' - Beschreibung
== Beschreibung ==
== Beschreibung ==
 
{| class="wikitable big options"
==  Autokonfiguration ==
 
Mittels Stateless Address Autoconfiguration (SLAAC, zustandslose Adressenautokonfiguration, spezifiziert in RFC 4862) kann ein Host vollautomatisch eine funktionsfähige Internetverbindung aufbauen.
 
Dazu kommuniziert er mit den für sein Netzwerksegment zuständigen Routern, um die notwendige Konfiguration zu ermitteln.
 
===  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 <tt>ff02::2</tt>, ü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.
 
===  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.
 
===  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.
 
==  Umnummerierung und Multihoming ==
 
Unter IPv4 ist die Umnummerierung (Änderung des IP-Adressbereichs) für Netze ab einer gewissen Größe problematisch, auch wenn Mechanismen wie DHCP dabei helfen.
 
==== Problem: Providerwechsel ====
 
Speziell der Übergang von einem Provider zum nächsten ohne ein „hartes“ Umschalten zu einem festen Zeitpunkt ist schwierig, da dies nur dann möglich ist, wenn das Netz für einen gewissen Zeitraum multihomed ist, also ein Netz gleichzeitig von mehr als einem Provider mit Internet-Anbindung und IP-Adressbereichen versorgt wird.
 
Die Umgehung des Umnummerierens unter IPv4 mittels Border Gateway Protocol (BGP) führt zur Fragmentierung des Adressraums. Es geraten also viele, vergleichsweise kleine Netze bis in die Routingtabellen im Kernbereich des Internets, und die Router dort müssen darauf ausgelegt werden.
 
==== Umnummerierung und IPv6 ====
 
Der Vorgang der Umnummerierung wurde beim Design von IPv6 hingegen berücksichtigt, er wird in RFC 4076 behandelt. Mechanismen wie die IPv6-Autokonfiguration helfen dabei.
 
Der parallele Betrieb mehrerer IP-Adressbereiche gestaltet sich unter IPv6 ebenfalls einfacher als unter IPv4, wie im Abschnitt Adressaufbau oben beschrieben.
 
In RFC 3484 wird festgelegt, wie die Auswahl der Quell- und Zieladressen bei der Kommunikation geschehen soll und wie sie beeinflusst werden kann, wenn nun jeweils mehrere zur Verfügung stehen.
 
Darüber hinaus darf diese Auswahl auch auf Anwendungsebene oder durch noch zu schaffende, z.&nbsp;B. die Verbindungsqualität einbeziehende Mechanismen getroffen werden.
 
==== Ausfallsicherheit ====
 
Das Ziel ist unter anderem, dem Betreiber eines Netzwerkes den unkomplizierten Wechsel zwischen Providern oder gar den dauerhaften Parallelbetrieb mehrerer Provider zu ermöglichen, um damit den Wettbewerb zu fördern, die Ausfallsicherheit zu erhöhen oder den Datenverkehr auf Leitungen mehrerer Anbieter zu verteilen.
 
==  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.
 
==  Header-Format ==
 
==== Feste Länge  ====
 
Bei IPv6 eine feste Länge von 40&nbsp;Byte (320&nbsp;Bit)* Im Gegensatz zu IPv4 hat der IP-Kopfdatenbereich (Header)
 
 
 
==== Extension Headers  ====
 
Optionale, seltener benutzte Informationen werden in so genannten Erweiterungs-Kopfdaten (engl.: Extension Headers) eingebettet * zwischen dem IPv6-Kopfdatenbereich und der eigentlichen Nutzlast (engl. Payload)
 
 
 
===  Header-Felder ===
 
[[Image:Form5.png]]
 
==== Kopfdatenbereich eines IPv6-Paketes laut RFC 2460: ====
 
 
{| class="wikitable sortable options"
|-
|-
! Feld !! Länge !! Inhalt
|-
|  | Version
|  | 4&nbsp;Bit
|  | IP-Versionsnummer (6)
|-
|  | Traffic&nbsp;Class
|  | 8&nbsp;Bit
|  | Für Quality of Service (QoS) verwendeter Wert. Eine Art Prioritätsvergabe.
|-
|  | Flow&nbsp;Label
|  | 20&nbsp;Bit
|  | Ebenfalls für QoS oder Echtzeitanwendungen verwendeter Wert. Pakete, die dasselbe Flow Label tragen, werden gleich behandelt.
|-
|  | Payload&nbsp;Length
|  | 16&nbsp;Bit
|  | Länge des IPv6-Paketinhaltes (ohne Kopfdatenbereich, aber inklusive der Erweiterungs-Kopfdaten) in Byte
|-
|  | Next&nbsp;Header
|  | 8&nbsp;Bit
|  | Identifiziert den Typ des nächsten Kopfdatenbereiches, dieser kann entweder einen Erweiterungs-Kopfdatenbereich (siehe nächste Tabelle) oder ein Protokoll höherer Schicht (engl.: Upper Layer Protocol) bezeichnen, wie z.&nbsp;B. TCP (Typ 6) oder UDP (Typ 17).
|-
|  | Hop&nbsp;Limit
|  | 8&nbsp;Bit
|  | Maximale Anzahl an Zwischenschritten über Router, die ein Paket zurücklegen darf; wird beim Durchlaufen eines Routers („Hops“) um eins verringert. Pakete mit null als Hop Limit werden verworfen. Es entspricht dem Feld Time to Live (TTL) bei IPv4.
|-
|  | Source&nbsp;Address
|  | 128&nbsp;Bit
|  | Adresse des Senders
|-
|  | Destination&nbsp;Address
|  | 128&nbsp;Bit
|  | Adresse des Empfängers
 
 
|-
|}
 
===  Extension Headers ===
 
Die meisten IPv6-Pakete sollten ohne Extension Headers auskommen. Extension Headers können bis auf den Destination Options Header nur einmal in jedem Paket vorkommen. Befindet sich ein Routing Extension Header im Paket, so darf davor ein weiterer Destination Options Header stehen.
 
Die Reihenfolge bei einer Verkettung ist bis auf die genannte Ausnahme die der Tabelle. Wie im Next Header Feld verwiesen sind einige Extension Headers und ein Platzhalter definiert:
 
 
{| class="wikitable sortable options"
|-
|-
|  | '''Name'''
|  | '''Typ'''
|  | '''Größe'''
|  | '''Beschreibung'''
|  | '''RFCs'''
|-
|  | Hop-By-Hop Options
|  | 0
|  | variabel
|  | Optionen* von allen IPv6-Geräten zu beachten
** wird z.B. für Jumbograms benutzt
 
 
|  | RFC 2460
 
RFC 2675
|-
|  | Routing
|  | 43
|  | variabel
|  | Hier kann der Weg des Paketes durch das Netzwerk beeinflusst werden* wird u.a. für Mobile IPv6 verwendet
 
 
|  | RFC 2460
 
RFC 6275
 
RFC 5095
|-
|  | Fragment
|  | 44
|  | 64&nbsp;Bit
|  | Parameter zur Fragmentierung
|  | RFC 2460
|-
|  | Authentication Header (AH)
|  | 51
|  | variabel
|  | Daten zur Vertraulichkeit (IPsec)
|  | RFC 4302
|-
|  | Encapsulating Security Payload (ESP)
|  | 50
|  | variabel
|  | Daten zur Verschlüsselung (IPsec)
|  | RFC 4303
|-
|  | Destination Options
|  | 60
|  | variabel
|  | Optionen* nur vom Zielrechner zu beachten
 
 
|  | RFC 2460
|-
|  | Mobility
|  | 135
|  | variabel
|  | Daten für Mobile IPv6
|  | RFC 6275
|-
|  | No Next Header
|  | 59
|  | leer
|  | Platzhalter* zeigt Ende eines Header-Stapels an
 
 
|  | RFC 2460
 
 
|-
|}
==== Next-Header ====
 
Alle Extension Headers enthalten ein Next-Header-Feld, in dem * der nächste Extension Header oder
* das Upper Layer Protocol genannt wird
 
 
 
Größen immer Vielfache von 64&nbsp;Bit* Speicherzugriffe im Router beschleunigen
* die meisten Felder der Kopfdatenbereiche sind auf 64-Bit-Grenzen ausgerichtet
 
 
 
==== Keine Prüfsummen ====
 
Es werden keine Prüfsummen über die IP-Kopfdaten berechnet* im Gegensatz zu IPv4
* Fehlerkorrektur auf Schichten 2 und 4
 
==  Maximum Transmission Unit ==
 
Die Maximum Transmission Unit (MTU) beschreibt die maximale Paketgröße eines Protokolls der Vermittlungsschicht (Schicht 3) des OSI-Modells, gemessen in Oktetten, welche ohne Fragmentierung in den Rahmen (engl. "Frames") eines Netzes der Sicherungsschicht (Schicht 2) übertragen werden kann.
 
Diese Paketgröße passt also in die Nutzlast (Payload) des Protokolls der Sicherungsschicht. Die maximale Größe der Nutzlast der Sicherungsschicht wird auch oft als MTU der Sicherungsschicht (engl. 'link MTU') bezeichnet.
 
Die maximale Größe eines Rahmens der Sicherungsschicht lässt sich so berechnen:
 
 
{|
|-
|  | Maximale&nbsp;Rahmengröße&nbsp;=
|  | Größte MTU aller benutzten Protokolle der Vermittlungsschicht + Größe der Sicherungsschichtheader
|-
|}
Die MTU wird durch Einstellungen im Rahmen der Möglichkeiten der verwendeten Hardware und Technik bestimmt.
 
Sie kann auf derselben Schnittstelle unterschiedliche Werte für unterschiedliche Protokolle der Vermittlungsschicht (z.&nbsp;B. IPv4 oder IPv6) annehmen.
 
Alle an einem Schicht-2-Netz beteiligten Schnittstellen, welche Protokolle höherer Schichten verarbeiten, müssen auf denselben Wert für die jeweiligen Schicht-3-Protokolle eingestellt werden.
 
Im OSI-Modell spricht man auf der Vermittlungsschicht von einem Paket (engl. 'packet'), während man auf der Sicherungsschicht von einem Rahmen (engl. 'frame') spricht.
 
Die Terminologie, welche das OSI-Modell für die Einheiten auf den verschiedenen OSI-Modellschichten verwendet, hat zu einiger Verwirrung um den Begriff der MTU geführt (siehe abweichende Verwendung bei wichtigen Herstellern).
 
Unter der „packet size“ (Paketgröße) wird fälschlicherweise teils die „frame size“ (Rahmengröße) verstanden, jedoch stellt die obige Definition (siehe RFC 1122 und RFC 791) dies eindeutig klar.
 
Ein Spezialfall liegt vor, wenn ein Schicht-2-Protokoll über ein anderes Schicht-2-Protokoll getunnelt wird, denn dann nennt man auch die Nutzlast selbst "Rahmen" (engl. 'frame').
 
====== Typische MTU-Größen ======
 
 
{|
|-
|  | '''Medium'''
|  | '''MTU in Bytes'''
|-
|  | Hyperchannel
|  | 65535
|-
|  | Token Ring(4)(802.5)
|  | 4464
|-
|  | Token Ring(16)
|  | 17914
|-
|  | FDDI
|  | 4352
|-
|  | Ethernet
|  | 1500
|-
|  | Gigabit Ethernetmit Jumboframes
|  | 9000
|-
|  | PPPoE (z.&nbsp;B. DSL)
|  | ≤ 1492
|-
|  | SLIP/PPP (low delay)
|  | 296
|-
|  | X.25
|  | 576
|-
|  | FibreChannel
|  | theoretisch unbegrenzt
|-
|  | ISDN
|  | 576
|-
|  | DQDB
|  |
|-
|  | HIPPI
|  |
|-
|  | ATM
|  | 4500, s.&nbsp;u.
|-
|  | ARCNET
|  |
|-
|  | 802.11
|  | 2312 (WiFi)
|-
|}
Die Path MTU (PMTU) beschreibt die maximale Paketgröße, die entlang der gesamten Wegstrecke übertragen werden kann, ohne einer Fragmentierung zu unterliegen.
 
Sie ist damit gleich der kleinsten MTU aller Schicht-2-Teilstücke im Pfad. Die PMTU kann automatisch durch PMTU Discovery (PMTUD) ermittelt werden.
 
====  Beispiel Brief ====
 
Das Konzept der MTU auf die Post adaptiert ist verständlicher.
 
Eine MTU 50&nbsp;g heißt, dass man max. 50&nbsp;g Inhalt (entspricht der Packet Size) in den Brief einpacken kann.
 
Der Brief insgesamt kann selbst aber schwerer als 50&nbsp;g sein, da im Normalfall noch ein Briefumschlag z.B. 4&nbsp;g und eine Briefmarke 0,3&nbsp;g hinzukommt.
 
Bezahlt und verschickt wird der ganze Brief von 54,3&nbsp;g Masse entsprechend der Frame Size.
 
====  Beispiel Ethernet ====
 
Ein Ethernetrahmen besteht aus zwei Teilen: dem „Header“, in dem Quell- und Zieladressen und andere wichtige Parameter für den Versand kodiert sind, und der Nutzlast, deren Größe durch die MTU bestimmt ist.
 
In diesem Versuch ist die Größe der MTU mit 1500 Byte vorgegeben.
 
Mit Hilfe des ping-Programmes wird ein „Frame“ erzeugt, der dann im Netzwerk über das Ethernet-Protokoll versendet wird.
 
Die Verwendung des Begriffes Nutzlast ist hier mehrdeutig, da im OSI-Modell die verschiedenen Protokolle ineinander eingepackt (gekapselt) werden.
 
Der im Versuch verwendete Linux-Befehl
 
<div >ping -s 1472 10.0.0.1 (Windows-Befehl ping -l 1472 10.0.0.1) </div>
 
sendet dann ein ICMP-Paket mit der Nutzlast von 1472 Bytes an die IP-Adresse 10.0.0.1.
 
<nowiki># ping -f -l 1472 10.0.0.1</nowiki>
          1472 bytes Nutzlast des ICMP-Protokolles (Transportschicht)
        +    8 bytes ICMP-Header (Transportschicht)
        +  20 bytes IPv4-Header (der Vermittlungsschicht)
      <nowiki>-------------</nowiki>
        <nowiki>= 1500 bytes (Nutzlast von Ethernet)</nowiki>
        +  14 bytes (Header der Sicherungsschicht)
        +    4 bytes (Frame Check Sequence)
      <nowiki>-------------</nowiki>
        <nowiki>= 1518 bytes (kompletter Ethernetrahmen)</nowiki>
 
Mit einem Sniffer wie z.&nbsp;B. Wireshark wird als Ethernet Header nur die Größe von 14 Byte angezeigt. Hierzu kommt noch die 4 Byte große Frame Check Sequence am Ende des Frames.
 
Falls VLANs verwendet werden, besteht der Header der Sicherungsschicht aus 18 Byte und der gesamte Ethernetrahmen kann eine Größe von bis zu 1522 Byte annehmen.
 
Würde IPv6 verwendet, änderte sich obige Berechnung dahingehend, dass der IPv6-Header der Vermittlungsschicht 40 statt 20 Byte beträgt und damit statt 1472 Byte ICMP-Nutzlast nur 1452 Byte möglich wären.
 
Oft ist es hilfreich dem ping-Programm vorzugeben das „don’t fragment (DF) bit“ für die Testpakete im IPv4-Header zu setzen,
 
für Linux z.&nbsp;B.
 
<div >ping -M do -s 1472 10.0.0.1</div>
 
für Windows
 
<div >ping -l 1472 -f 10.0.0.1</div>
 
denn dann erhält man eine Nachricht, falls die MTU überschritten wird. Leicht sichtbar machen lässt sich die Path MTU mit dem Programm tracepath für IPv4 bzw. tracepath6 für IPv6.
 
===  Einfluss auf andere Protokolle ===
 
Die MTU ist ein hardwareabhängiger Wert, der sämtliche Parameter oberhalb der Sicherungsschicht des OSI-Modells beeinflusst.
 
Am Beispiel Ethernet ist dies einfach erklärt: In diesem Netzwerk werden sämtliche Pakete der Schicht&nbsp;3, beispielsweise IP-Pakete, in „Ethernet-Frames“ übertragen.
 
Die Nutzdaten dieses Ethernet-Frames (d.&nbsp;h. die IP-Pakete) dürfen den MTU-Wert nicht übersteigen. Die Länge der TCP-Nutzdaten (Maximum Segment Size) wird daher aus der MTU direkt berechnet.
 
===  Andere Beispiele und Probleme ===
 
Jumbo Frames für Gigabit Ethernet können deutlich mehr als 1518 Oktette beinhalten und damit ist es möglich, größere Pakete unfragmentiert zu übertragen.
 
Positiv wiegt, dass der Protokoll-Overhead bei der Verwendung von Jumbo Frames reduziert werden kann und Router weniger Pakete behandeln müssen.
 
Allerdings ist die Terminologie bzgl. MTU derart uneinheitlich unter den Herstellern, dass es in der Praxis schwierig ist, von den Standardeinstellungen abzuweichen.
 
Des Weiteren sind Jumbo Frames nicht im IEEE-802.3-Standard spezifiziert, trotzdem unterstützen die meisten Hersteller von Gigabit Ethernet Switches und Routern MTUs bis 9000 Oktette.
 
So hat sich als Quasistandard eine Path MTU um ca. 1500 Byte im Internet eingebürgert, die durch das weit verbreitete Fast Ethernet sowieso meist nicht überschritten werden kann.
 
Mit dem Aufkommen von Internetzugängen, die auf Tunnelprotokollen basieren, zum Beispiel beim Verbindungsaufbau über das PPPoE-Protokoll hat die MTU an Bedeutung gewonnen.
 
Obwohl die PMTUD in diesem Fall dafür sorgen soll, dass die Kommunikation trotz der durch den Tunnel abgesenkten MTU möglich ist, gibt es immer wieder fehlkonfigurierte Firewalls, die durch Verwerfen von ICMP-Steuerpaketen die PMTUD stören.
 
Auch große Websites sind oft von diesem Konfigurationsfehler betroffen, sodass die Nutzer von getunnelten Zugängen die MTU ihrer Geräte verkleinern müssen, um auch mit diesen Sites kommunizieren zu können.
 
Über die optimale MTU gibt es viele Diskussionen.
 
Kurz zusammengefasst:* einfache Optimierung: so groß wie möglich, ohne dass Probleme auftreten
* komplexe Optimierung: so viel kleiner als o.&nbsp;g. Maximum, dass der Verschnitt der Transportzellen der unter der DSL-Schicht liegenden ATM-Transportschicht möglichst klein wird.
* oder einfach probieren
 
 
 
Die MTU bei ATM (4500) ist nicht zu verwechseln mit der Zellengröße (53 Bytes, 48 davon Nutzlast).
 
Bei der Übertragung über einen ATM-Link werden IP-Pakete in Stücke zu je 48 Bytes zerlegt und für die Übertragung auf mehrere ATM-Zellen verteilt. Der Router am anderen Ende des ATM-Links sammelt diese Zellen und setzt das ursprüngliche IP-Paket wieder zusammen.
 
Im Gegensatz dazu wird bei der IP-Fragmentierung das Paket nicht vom Router reassembliert, sondern erst von dem Host, für den das Paket bestimmt war.
 
Probleme, die durch einen falschen MTU-Wert auftreten können, sind Webseiten, die gar nicht oder nur teilweise angezeigt werden.
 
===  Abweichende Verwendung des Begriffs  ===
 
Die Routerhersteller Cisco und Juniper verwenden den Begriff MTU in ihrer Konfigurationssyntax als maximale Rahmen- bzw. Paketgröße der zu konfigurierenden Netzwerkschicht. Folgende Einstellungen entsprechen einander.
 
Bei beiden Herstellern bedeutet das erste Auftauchen des Begriffs die maximale Ethernet Rahmengröße und nicht die maximale Größe der Nutzlast und diese muss folglich einige Byte größer gewählt werden als die dann folgenden Einstellungen für die verschiedenen Schicht-3 Protokolle.
 
Cisco:
 
interface GigabitEthernet2/3
mtu 9192
ip address 192.168.0.1 255.255.255.252
ip mtu 9000
ipv6 address 2001:DB8::1/64
ipv6 mtu 8000
ipv6 router isis
clns mtu 1497
!
 
Juniper:
 
interfaces {
    ge-0/0/0 {
        mtu 9192;
        unit 0 {
            family inet {
                mtu 9000;
                address 192.168.0.2/30;
            }
            family inet6 {
                mtu 8000;
                address 2001:DB8::2/64;
            }
            family iso {
                mtu 1497;
            }
        }
    }
}
 
===  Paketgrößen ===
 
===== Jumbograms  =====
 
RFC 2675 stellt aber über eine Option des Hop-by-Hop Extension Headers die Möglichkeit zur Verfügung, Pakete mit Größen bis zu 4.294.967.335&nbsp;Byte, sogenannte Jumbograms zu erzeugen.
 
Dies erfordert allerdings Anpassungen in Protokollen höherer Schichten, wie z.&nbsp;B. TCP oder UDP, da diese oft auch nur 16&nbsp;Bit für Größenfelder definieren, außerdem muss bei jedem Paket, welches einen Jumbogram beinhaltet, im IPv6-Header die Payload-Length auf 0 gesetzt werden.
 
==  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 ===
 
 
{|
|-
| colspan="2" | '''ICMPv6 (Internet Control Message Protocol Version 6)'''
|-
|  | Familie:
|  | Internetprotokollfamilie
|-
|  | Einsatzgebiet:
|  | Obligatorischer Zusatz zu IPv6, Fehlermeldungen, Diagnose, Autoconfiguration, Routing
 
Internet-Protokolle im TCP/IP-Protokollstapel
 
 
{|
|-
|  | Internet
| colspan="5"  | ICMPv6
|-
| colspan="5" | IPv6
|-
|  | Netzzugang
|  | Ethernet
|  | TokenBus
|  | IEEE802.11a/b/g/n
|  | FDDI
|  | …
|-
|}
 
|-
| colspan="2" |
|-
|  | 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 ====
 
<div >''ICMPv6 Header''</div>
 
 
{|
|-
|  | '''+'''
|  | '''Bits 0–7'''
|  | '''Bits 8–15'''
|  | '''Bits 16–23'''
|  | '''Bits 24–31'''
|-
|  | '''0'''
|  | Type
|  | Code
| colspan="2"  | Prüfsumme
|-
|  | '''…'''
| colspan="4"  | 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 =====
 
<div >''Prüfsummen-Schema''</div>
 
 
{|
|-
|  | '''+'''
|  | '''Bits 0–7'''
|  | '''Bits 8–15'''
|  | '''Bits 16–23'''
|  | '''Bits 24–31'''
|-
|  | '''0'''
| colspan="4"  | IPv6-Absender-Adresse
|-
|| '''32'''
|-
|| '''64'''
|-
|| '''96'''
|-
|  | '''128'''
| colspan="4"  | IPv6-Ziel-Adresse
|-
|| '''160'''
|-
|| '''192'''
|-
|| '''224'''
|-
|  | '''256'''
| colspan="4"  | IPv6-Nutzlast-Größe
|-
|  | '''288'''
| colspan="3"  | 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 =====
 
<div >''Destination-Unreachable-Schema''</div>
 
 
{|
|-
|  | '''+'''
|  | '''Bits 0–7'''
|  | '''Bits 8–15'''
|  | '''Bits 16–23'''
|  | '''Bits 24–31'''
|-
|  | '''0'''
|  | Type
|  | Code
| colspan="2"  | Prüfsumme
|-
|  | '''32'''
| colspan="4"  | Unbenutzt
|-
|  | '''…'''
| colspan="4"  | 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 =====
 
<div >''Packet-Too-Big-Schema''</div>
 
 
{|
|-
|  | '''+'''
|  | '''Bits 0–7'''
|  | '''Bits 8–15'''
|  | '''Bits 16–23'''
|  | '''Bits 24–31'''
|-
|  | '''0'''
|  | Type
|  | Code
| colspan="2"  | Prüfsumme
|-
|  | '''32'''
| colspan="4"  | MTU
|-
|  | '''…'''
| colspan="4"  | 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 =====
 
<div >''Time-Exceeded-Schema''</div>
 
 
{|
|-
|  | '''+'''
|  | '''Bits 0–7'''
|  | '''Bits 8–15'''
|  | '''Bits 16–23'''
|  | '''Bits 24–31'''
|-
|  | '''0'''
|  | Type
|  | Code
| colspan="2"  | Prüfsumme
|-
|  | '''32'''
| colspan="4"  | Unbenutzt
|-
|  | '''…'''
| colspan="4"  | 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 =====
 
<div >''Parameter-Problem-Schema''</div>
 
 
{|
|-
|  | '''+'''
|  | '''Bits 0–7'''
|  | '''Bits 8–15'''
|  | '''Bits 16–23'''
|  | '''Bits 24–31'''
|-
|  | '''0'''
|  | Type
|  | Code
| colspan="2"  | Prüfsumme
|-
|  | '''32'''
| colspan="4"  | Pointer
|-
|  | '''…'''
| colspan="4"  | 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 =====
 
<div >''Echo-Request-Schema''</div>
 
 
{|
|-
|  | '''+'''
|  | '''Bits 0–7'''
|  | '''Bits 8–15'''
|  | '''Bits 16–23'''
|  | '''Bits 24–31'''
|-
|  | '''0'''
|  | Type
|  | Code
| colspan="2"  | Prüfsumme
|-
|  | '''32'''
| colspan="2"  | Identifikation
| colspan="2"  | Sequenznummer
|-
|  | '''…'''
| colspan="4"  | 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 =====
 
<div >''Echo-Reply-Schema''</div>
 
 
{|
|-
|  | '''+'''
|  | '''Bits 0–7'''
|  | '''Bits 8–15'''
|  | '''Bits 16–23'''
|  | '''Bits 24–31'''
|-
|  | '''0'''
|  | Type
|  | Code
| colspan="2"  | Prüfsumme
|-
|  | '''32'''
| colspan="2"  | Identifikation
| colspan="2"  | Sequenznummer
|-
|  | '''…'''
| colspan="4"  | 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
 
 
 
==  Address Resolution Protocol ==
 
 
{|
|-
| colspan="2" | '''ARP (Address Resolution Protocol)'''
|-
|  | '''Familie:'''
|  | Internetprotokollfamilie
|-
|  | '''Einsatzgebiet:'''
|  | Netzwerkadressenzuordnung
 
ARP im TCP/IP‑Protokollstapel:
 
 
{|
|-
|  | Anwendung
|  | HTTP
|  | IMAP
|  | SMTP
|  | DNS
|  | …
|-
|  | Transport
| colspan="3"  | TCP
| colspan="2"  | UDP
|-
|  | Internet
| colspan="5"  | IPv4
|-
|  | Netzzugang
| colspan="5"  | ARP
|-
|| Ethernet
|| TokenBus
|| TokenRing
|| FDDI
|| …
|-
|}
 
|-
| colspan="2" |
|-
|  | '''Standards:'''
|  | RFC 826 (1982)
|-
|}
Das Address Resolution Protocol (ARP) ist ein Netzwerkprotokoll, das zu einer Netzwerkadresse der Internetschicht die physikalische Adresse (Hardwareadresse) der Netzzugangsschicht ermittelt und diese Zuordnung gegebenenfalls in den so genannten ARP-Tabellen der beteiligten Rechner hinterlegt.
 
Es wird fast ausschließlich im Zusammenhang mit IPv4-Adressierung auf Ethernet-Netzen, also zur Ermittlung von MAC-Adressen zu gegebenen IP-Adressen verwendet, obwohl es nicht darauf beschränkt ist. Für IPv6 wird diese Funktionalität nicht von ARP, sondern durch das Neighbor Discovery Protocol (NDP) bereitgestellt.
 
===  Verwendungen ===
 
MAC-Adressen (Hardwareadressen) werden vom Hersteller einer Ethernet-Netzwerkkarte oder eines Ethernet-fähigen Gerätes vergeben. Die Adresse jeder Schnittstelle ist dabei theoretisch weltweit eindeutig.
 
Bei einigen Netzen, wie zum Beispiel Novell und DECnet, werden die Netzwerkadressen eindeutig auf die Ethernetadressen abgebildet, etwa, indem die MAC-Adresse um weitere Informationen ergänzt wird. Ein Sender kann dann die MAC-Adresse des Empfängers einfach aus der Netzwerkadresse ermitteln.
 
IP-Adressen werden von der IANA (Internet Assigned Numbers Authority) zugeteilt. Da IPv4-Adressen nur aus 32 Bits bestehen, sind sie nicht in der Lage, MAC-Adressen zu speichern.
 
Aus diesem Grund besteht keine feste Beziehung zwischen MAC-Adressen und IP-Adressen. Bevor ein Rechner in einem Ethernet an einen Rechner im selben Subnetz ein IP-Paket sendet, muss er die Information in einen Ethernetframe verpacken.
 
Dazu muss er die MAC-Adresse des Zielrechners kennen und im entsprechenden Feld des Ethernetframes einfügen. Ist ihm diese nicht bekannt, kann er das IP-Paket nicht zustellen. Stattdessen ermittelt er dann mit Hilfe des ARP zunächst die MAC-Adresse des Zielrechners.
 
===  Funktionsweise am Beispiel Ethernet ===
 
Es wird eine ARP-Anforderung (ARP Request) mit der MAC-Adresse und der IP-Adresse des anfragenden Computers als Senderadresse und der IP-Adresse des gesuchten Computers als Empfänger-IP-Adresse an alle Computer des lokalen Netzwerkes gesendet.
 
Als Empfänger-MAC-Adresse wird dazu die Broadcast-Adresse <tt>ff-ff-ff-ff-ff-ff16</tt> verwendet. Empfängt ein Computer ein solches Paket, sieht er nach, ob dieses Paket seine IP-Adresse als Empfänger-IP-Adresse enthält.
 
Wenn dies der Fall ist, antwortet er mit dem Zurücksenden seiner MAC-Adresse und IP-Adresse (ARP-Antwort oder ARP-Reply) an die MAC-Quelladresse des Anforderers. Dieser trägt nach Empfang der Antwort die empfangene Kombination von IP- und MAC-Adresse in seine ARP-Tabelle, den sogenannten ARP-Cache, ein. Für ARP-Request und ARP-Reply wird das gleiche Paket-Format verwendet.
 
Zusätzlich können die Empfänger des ARP-Requests ebenfalls die Kombination von IP-Adresse und MAC-Adresse des anfragenden Computers in ihre ARP-Tabelle eintragen bzw. einen bestehenden Eintrag aktualisieren.
 
Insbesondere der Rechner mit der im ARP-Request angefragten IP-Adresse sollte diese Eintragung vornehmen, da anzunehmen ist, dass der ARP-Request als Vorbereitung für weitere Kommunikation auf höherer Protokollebene dienen soll, wofür er dann für eventuelle Antworten ebenfalls die MAC-Adresse des Anfragenden benötigt.
 
Der ARP-Cache enthält eine vierspaltige Tabelle, die im Allgemeinen aus <Protokolltyp, Protokolladresse des Senders, Hardware-Adresse des Senders, Eintragszeitpunkt> besteht.
 
Das Zeitintervall, nachdem ein Eintrag aus dem ARP-Cache gelöscht wird, ist implementierungsabhängig. So verwerfen aktuelle Linux-Distributionen Einträge nach ca. 5 Minuten. Sobald ein Eintrag in der Tabelle genutzt wird, wird dessen Ablaufzeit verlängert.
 
Unter Unix und Windows kann der ARP-Cache mit <tt>arp</tt> beziehungsweise <tt>arp -a</tt> angezeigt und mit dem entsprechenden Programm auch manipuliert werden.
 
Mit dem Zusatzprogramm <tt>arping</tt> können manuell Anforderungen versendet werden.
 
===  ARP im globalen Zusammenhang ===
 
{{clear}}
[[Image:Bild2.png|center]]
 
Das ARP ist für die Auflösung der MAC-Adressen im lokalen Netzwerk zuständig. Sollen Daten über Netzwerkgrenzen hinweg gesendet werden, wird das Internet Protokoll (IP) verwendet.
 
IP-Implementierungen sind in der Lage, zu erkennen, dass ein Paket nicht für das lokale Subnetz bestimmt ist und senden es an einen lokalen Router, der sich um die Weiterleitung des Pakets kümmert.
 
Dieser Router hat wiederum eine lokale MAC-Adresse, die über ARP ermittelt werden kann.
 
Das Flussdiagramm stellt den Zusammenhang von IP-Routing mit ARP dar.
 
===  Paketformat ===
 
Das ARP-Paket schließt sich an den Ethernet-MAC-Header an. Das Typfeld im Ethernetframe wird auf 0x0806 (2054) gesetzt. Diese Nummer ist für das ARP-Protokoll reserviert.
 
Dadurch lassen sich ARP-Pakete von Paketen anderer Protokolle wie beispielsweise IP unterscheiden.
 
Da das Paket sehr kurz ist, müssen in der Regel im Ethernetframe zwischen ARP-Paket und CRC zusätzliche Bytes eingefügt werden (Padding), um die minimale Framelänge von 64 Bytes zu erreichen.
 
Obwohl ARP ursprünglich für IPv4 und MAC-Adressen entwickelt wurde, sind im Paket Adresstypen und Protokollgrößenfelder vorgesehen. Dadurch ist ARP auch für andere Protokolle geeignet.
 
Für IPv6 könnten die Protokolladressgröße statt auf 4 auf 16 Bytes gesetzt und die Adressfelder auf 128 Bits (=16 Byte) verlängert werden, jedoch wird ARP für IPv6 durch das Neighbor Discovery Protocol (NDP) ersetzt, welches auf ICMPv6 basiert.
 
 
{|
|-
|  | '''Bit 0–7'''
|  | '''Bit 8–15'''
|  | '''Bit 16–23'''
|  | '''Bit 24–31'''
|-
| colspan="2"  | Hardwareadresstyp (1)
| colspan="2"  | Protokolladresstyp (0x0800)
|-
|  | Hardwareadressgröße (6)
|  | Protokolladressgröße (4)
| colspan="2"  | Operation
|-
| colspan="4" | Quell-MAC-Adresse
|-
| colspan="2"  | Quell-MAC-Adresse
| colspan="2"  | Quell-IP-Adresse
|-
| colspan="2"  | Quell-IP-Adresse
| colspan="2"  | Ziel-MAC-Adresse
|-
| colspan="4" | Ziel-MAC-Adresse
|-
| colspan="4" | Ziel-IP-Adresse
|-
|}
<div >''ARP-Nachrichtenformat am Beispiel Ethernet-MAC-Adressen und IPv4-Adressen''</div>
 
 
Hardwareadresstyp (2 Byte) enthält den Typ der MAC-Adresse im Paket (für Ethernet: <tt>1</tt>).
 
Protokolladresstyp (2 Byte) enthält den Protokolltyp, der für die MAC-Adresse angefordert wird (für IPv4-Adressen: <tt>0x0800 (2048)</tt>).
 
Hardwareadressgröße (1 Byte) enthält die Größe der MAC-Adresse (für Ethernet: <tt>6</tt>).
 
Protokolladressgröße (1 Byte) enthält die Größe des Protokolls (für IPv4: <tt>4</tt>).
 
Operation (2 Byte) enthält den Wert, der angibt, welche Operation ausgeführt werden soll (<tt>1</tt> für ARP-Anforderung, <tt>2</tt> für ARP-Antwort).
 
Quell-MAC-Adresse (6 Byte) enthält in einer ARP-Anforderung die MAC-Adresse des Senders. In einer ARP-Antwort enthält es die MAC-Adresse des antwortenden Hosts oder Next-Hop-Routers.
 
Quell-IP-Adresse (4 Bytes bei IPv4) enthält bei einer ARP-Anforderung die IP-Adresse des anfragenden Hosts. In einer ARP-Antwort enthält es die IP-Adresse des antwortenden Hosts oder Next-Hop-Routers.
 
Ziel-MAC-Adresse (6 Byte) ist in einer ARP-Anforderung ein Broadcast (FF:FF:FF:FF:FF:FF). In einer ARP-Antwort enthält es die MAC-Adresse des anfragenden Hosts.
 
Ziel-IP-Adresse (4 Bytes bei IPv4) ist bei einer ARP-Anforderung die IP-Adresse des gesuchten Hosts. In einer ARP-Antwort enthält es die IP-Adresse des anfragenden Hosts.
 
===  Spezielle ARP-Nachrichten ===
 
====  Proxy ARP ====
 
Proxy ARP erlaubt einem Router, ARP-Anforderungen für Hosts zu beantworten.
 
Die Hosts befinden sich dabei in durch einen Router getrennten Netzen - verwenden untypischerweise jedoch den gleichen IP-Adressenbereich. Bei der Kommunikation ist für die Hosts der Router transparent, das heißt, er braucht nicht speziell angesprochen zu werden, sondern die Hosts können wie gewöhnlich Pakete über verschiedene Netze hinweg versenden.
 
Sendet Computer A eine ARP-Anforderung an Computer B, reagiert der dazwischen liegende Router anstelle des Computers B mit einer ARP-Antwort und der Hardwareadresse der Schnittstelle (MAC des Ports am Router), auf der die Anfrage empfangen wurde. Der anfragende Computer A sendet dann seine Daten an den Router, der sie dann an Computer B weiterleitet.
 
Proxy ARP kann man am ARP-Cache von Computer A erkennen. Falls für mehrere IP-Adressen dieselbe MAC-Adresse eingetragen ist, arbeitet der Router mit dieser MAC-Adresse als Proxy. Die Einträge können auch ein Hinweis auf einen Angriff durch ARP-Spoofing sein.
 
====  Gratuitous ARP ====
 
Gratuitous ARP (engl. „unaufgefordertes ARP“) bezeichnet eine spezielle Verwendung von ARP. Dabei sendet ein Host ein ARP-Anforderungs-Broadcast, bei dem er seine eigene IP-Adresse als Quell- und Ziel-IP-Adresse einträgt. Damit teilt er seine ggf. neue MAC-Adresse unaufgefordert mit. Das kann mehreren Zwecken dienen:# Normalerweise darf keine Antwort kommen, denn eine IP-Adresse muss in einem Netz eindeutig sein. Bekommt er trotzdem eine Antwort, ist das für den Administrator ein Hinweis darauf, dass ein Host nicht richtig konfiguriert ist.
# Jeder Host aktualisiert seinen ARP-Cache. Das ist beispielsweise dann nützlich, wenn die Netzwerkkarte eines Rechners ausgetauscht wurde und die anderen Hosts über die neue MAC-Adresse informiert werden sollen. Gratuitous ARP geschieht deshalb normalerweise beim Booten eines Computers.
# Wenn zwei Server aus Gründen der Ausfallsicherheit als Server und Ersatzserver aufgebaut sind und sich eine IP-Adresse teilen und der aktive Verkehr vom einen auf den anderen geschwenkt werden soll, ist die IP-Adresse jetzt über eine andere MAC-Adresse zu erreichen. Diese neue MAC-/IP-Adress-Zuordnung muss bekannt gemacht werden. Sonst bekommt niemand den Wechsel mit.
# In einem Mobile-IP-Szenario sendet der Home Agent einen Gratuitous ARP, wenn sich der Mobile Host aus dem Heimatnetz entfernt, um die Pakete stellvertretend für diesen zu empfangen. Analog sendet der Mobile Host einen Gratuitous ARP, sobald er sich wieder im Netz befindet.
 
 
 
====  RARP – Reverse-ARP ====
 
Das Reverse-ARP (RARP) funktioniert umgekehrt zu ARP. Es kann also MAC-Adressen zu IP-Adressen auflösen.
 
Dies ist für die Ermittlung der eigenen IP-Adresse bei Geräten nützlich, bei denen keine dauerhafte Speicherung oder Zuweisung einer Adresse vorgesehen ist.
 
Beide Protokolle besitzen das gleiche Paketformat. Die Anwendungsbereiche von RARP und ARP unterscheiden sich jedoch stark voneinander.
 
===  Probleme ===
 
ARP ist für den Benutzer unsichtbar, sodass das Vorhandensein dieses Protokolls meist nur bemerkt wird, wenn seltene Fehler auftreten.
 
Die Dauer der Gültigkeit eines ARP-Eintrags (normalerweise wenige Minuten) kann ein Problem darstellen, wenn falsche Einträge vorhanden sind. Solange ein fehlerhafter Eintrag existiert, kann mit dem betreffenden Host nicht kommuniziert werden. Die Fehlfunktion wird häufig nicht dem ARP-Protokoll zugeschrieben, sondern dem Netz oder einem Fehler in der Netzwerkimplementierung. Darüber hinaus ermöglicht nicht jedes Betriebssystem das Erzeugen eines korrigierten Eintrags oder einer Anforderung.
 
Gravierender ist das Eintragen von Daten in den ARP-Cache aus Paketen, für die keine Anforderung erzeugt wurde (blinder Glaube). Ein überlasteter Host, der eine alte IP-Adresse führt, antwortet mit großer Wahrscheinlichkeit als letzter auf eine ARP-Anforderung mit einer Antwort, die die falsche Adresse enthält. Dieses letzte Paket überschreibt die ARP-Tabelle aller Geräte im Netz, ein fehlerhafter Eintrag bleibt übrig.
 
====  ARP-Spoofing ====
 
Mit ARP-Spoofing ist es möglich, absichtlich eine falsche Hardwareadresse in einem Netz zu verteilen. Dadurch kann der Datenverkehr für einen Rechner auf einen anderen umgelenkt und eventuell von diesem sogar verändert werden (Man-In-The-Middle-Angriff). Das stellt ein Sicherheitsproblem dar.
 
ARP-Spoofing ist aufgrund der Architektur von ARP sehr einfach zu realisieren. Es müssen einfach ARP-Pakete mit den falschen MAC-/IP-Kombinationen versendet werden. Daraufhin wird keiner der Empfängerrechner irgendwelche Überprüfungen anstellen, sondern die Daten einfach in seinen Cache eintragen.
 
Moderne Implementierungen ändern die ARP-Tabelle nur für ARP-Antworten, für die vorher vom betreffenden Host eine Anforderung generiert wurde.
 
 
==  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.&nbsp;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.&nbsp;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
|-
|-
|  | '''…'''
! Funktion !! Beschreibung
| colspan="4"  | Optionen
|-
|-
|}
| Autokonfiguration || [[Stateless Address Autoconfiguration]]
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>
 
 
{|  
|-
|-
| | '''+'''
| Umnummerierung und Multihoming || [[IPv6/Multihoming]]
| | '''Bits 0–7'''
| colspan="3"  | '''Bits 8–15'''
|  | '''Bits 16–23'''
|  | '''Bits 24–31'''
|-
|-
| | '''0'''
| Mobile IPv6 || [[IPv6/Mobile IP]]
| | Type
| colspan="3"  | Code
| colspan="2"  | Prüfsumme
|-
|-
| | '''32'''
| Header-Format || [[IPv6/Header]]
|  | Hop-Limit
|  | M
|  | O
| | Reserviert
| colspan="2"  | Router-Lifetime
|-
|-
| | '''64'''
| Maximum Transmission Unit || [[Maximum Transmission Unit]]
| colspan="6"  | Erreichbarkeits-Timeout
|-
|-
| | '''96'''
| Address Resolution Protocol || [[Address Resolution Protocol]]
| colspan="6"  | Auflösungs-Timeout
|-
|  | '''…'''
| colspan="6"  | Optionen
|-
|-
| Neighbor Discovery Protocol || [[Neighbor Discovery Protocol]]
|}
|}
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
==  IPv6 und DNS ==
==== Bedeutung von DNS ====
Wegen der Länge der IP-Adressen, die an das menschliche Erinnerungsvermögen höhere Anforderungen stellt als IPv4-Adressen, ist IPv6 in besonderem Maße von einem funktionierenden Domain Name System (DNS) abhängig.
==== AAAA ====
RFC 3596 definiert den Resource Record (RR) Typ AAAA (sprich: Quad-A), der genau wie ein A Resource Record für IPv4 einen Namen in eine IPv6-Adresse auflöst.
Der Reverse Lookup, also die Auflösung einer IP-Adresse in einen Namen, funktioniert nach wie vor über den RR-Typ PTR, nur ist für IPv6 die Reverse Domain nicht mehr IN-ADDR.ARPA wie für IPv4, sondern IP6.ARPA und die Delegation von Subdomains darin geschieht nicht mehr an 8-Bit-, sondern an 4-Bit-Grenzen.
Ein IPv6-fähiger Rechner sucht in der Regel mittels DNS zu einem Namen zunächst nach dem RR-Typ AAAA, dann nach dem RR-Typ A. Laut der Default Policy Table in RFC 3484 wird die Kommunikation über IPv6 gegenüber IPv4 bevorzugt, falls festgestellt wird, dass für eine Verbindung beide Protokolle zur Verfügung stehen.
Die Anwendungsreihenfolge der Protokolle ist meistens aber auch im Betriebssystem und auf der Anwendungsebene, also z.&nbsp;B. im Browser, einstellbar.
==== Root-Nameserver  ====
Elf der dreizehn Root-Nameserver und mindestens zwei Nameserver der meisten Top-Level-Domains sind bereits über IPv6 erreichbar.
Das übertragende Protokoll ist unabhängig von den übertragenen Informationen. Insbesondere kann man über IPv4 einen Nameserver nach AAAA-RRs fragen.
Anbieter großer Portalseiten denken jedoch darüber nach, nur DNS-Anfragen, die über IPv6 gestellt werden, auch mit AAAA Resource Records zu beantworten, um Probleme mit fehlerhaft programmierter Software zu vermeiden.


<noinclude>
<noinclude>
Zeile 1.659: Zeile 25:
=== Siehe auch ===
=== Siehe auch ===
{{Special:PrefixIndex/{{BASEPAGENAME}}}}
{{Special:PrefixIndex/{{BASEPAGENAME}}}}
==== Dokumentation ====
==== Links ====
==== Links ====
===== Projekt =====
===== Weblinks =====
===== Weblinks =====
 
</noinclude>
[[Kategorie:IPv6/ICMP]]
[[Kategorie:IPv6/ICMP]]
</noinclude>

Aktuelle Version vom 19. Oktober 2024, 13:42 Uhr

topic - Beschreibung

Beschreibung

Funktion 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
Address Resolution Protocol Address Resolution Protocol
Neighbor Discovery Protocol Neighbor Discovery Protocol


Anhang

Siehe auch

Links

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