JavaScript is required to for searching.
Navigationslinks �berspringen
Druckansicht beenden
Systemverwaltungshandbuch: IP Services
search filter icon
search icon

Dokument-Informationen

Vorwort

Teil I Einführung in die Systemverwaltung: IP Services

1.  Oracle Solaris TCP/IP-Protokollfamilie (Übersicht)

Teil II Administration von TCP/IP

2.  Planen Ihres TCP/IP-Netzwerks (Vorgehen)

3.  Einführung in IPv6 (Überblick)

4.  Planen eines IPv6-Netzwerks (Aufgaben)

5.  Konfiguration der TCP/IP-Netzwerkservices und IPv4-Adressierung (Aufgaben)

6.  Verwalten von Netzwerkschnittstellen (Aufgaben)

7.  Konfigurieren eines IPv6-Netzwerks (Vorgehen)

8.  Verwaltung eines TCP/IP-Netzwerks (Aufgaben)

9.  Fehlersuche bei Netzwerkproblemen (Aufgaben)

10.  TCP/IP und IPv4 im Detail (Referenz)

11.  IPv6 im Detail (Referenz)

Neuerungen in diesem Kapitel

Weiterführende IPv6-Adressierungsformate

Von 6to4 abgeleitete Adressen

Von 6to4 abgeleitete Adressierung auf einem Host

IPv6-Multicast-Adressen im Detail

Format der IPv6-Paket-Header

IPv6-Extension-Header

Dual-Stack-Protokolle

Implementierung von IPv6 unter Oracle Solaris

IPv6-Konfigurationsdateien

ndpd.conf-Konfigurationsdatei

IPv6-Schnittstellenkonfigurationsdatei

/etc/inet/ipaddrsel.conf-Konfigurationsdatei

IPv6-bezogene Befehle

ipaddrsel-Befehl

6to4relay-Befehl

ifconfig-Befehlserweiterungen zur Unterstützung von IPv6

Änderungen an einem netstat-Befehl zur Unterstützung von IPv6

Änderungen an einem snoop-Befehl zur Unterstützung von IPv6

Änderungen an einem route-Befehl zur Unterstützung von IPv6

Änderungen an einem ping-Befehl zur Unterstützung von IPv6

Änderungen an einem traceroute-Befehl zur Unterstützung von IPv6

IPv6-bezogene Daemons

in.ndpd-Daemon zur Neighbor Discovery

in.ripngd-Daemon, für das IPv6-Routing

inetd-Daemon und IPv6-Services

IPv6 Neighbor Discovery-Protokoll

ICMP-Nachrichten im Neighbor Discovery-Protokoll

Automatische Konfiguration

Beziehen einer Router Advertisement-Nachricht

Präfix-Konfigurationsvariablen

Einmaligkeit einer Adresse

Neighbor Solicitation und Unerreichbarkeit

Algorithmus zur Erkennung doppelt vorhandener Adressen

Proxy Advertisement-Nachrichten

Lastausgleich für eingehende Daten

Ändern einer Link-lokalen Adresse

Vergleich von Neighbor Discovery mit ARP und verwandten IPv4-Protokollen

IPv6-Routing

Router Advertisement-Nachrichten

Router Advertisement-Präfixe

Router Advertisement-Nachrichten

IPv6-Tunnel

Konfigurierte Tunnel

Automatische 6to4-Tunnel

Topologie eines 6to4-Tunnels

Paketfluss durch den 6to4-Tunnel

Sicherheitsbetrachtungen bei Tunneln zu einem 6to4-Relay-Router

IPv6-Erweiterungen zu den Oracle Solaris-Namen-Services

DNS-Erweiterungen für IPv6

Änderungen an der nsswitch.conf-Datei

Änderungen an den Namen-Service-Befehlen

NFS und RPC IPv6-Unterstützung

Unterstützung für IPv6-über-ATM

Teil III DHCP

12.  Einführung in DHCP (Übersicht)

13.  Planungen für den DHCP-Service (Aufgaben)

14.  Konfiguration des DHCP-Services (Aufgaben)

15.  Verwalten von DHCP (Aufgaben)

16.  Konfiguration und Verwaltung des DHCP-Clients

17.  DHCP-Fehlerbehebung (Referenz)

18.  DHCP - Befehle und Dateien (Referenz)

Teil IV IP-Sicherheit

19.  IP Security Architecture (Übersicht)

20.  Konfiguration von IPsec (Aufgaben)

21.  IP Security Architecture (Referenz)

22.  Internet Key Exchange (Übersicht)

23.  Konfiguration von IKE (Aufgaben)

24.  Internet Key Exchange (Referenz)

25.  IP Filter in Oracle Solaris (Übersicht)

26.  IP Filter (Aufgaben)

Teil V Mobile IP

27.  Mobile IP (Übersicht)

28.  Verwalten von Mobile IP (Aufgaben)

29.  Mobile IP-Dateien und Befehle (Referenz)

Teil VI IPMP

30.  Einführung in IPMP (Übersicht)

31.  Verwaltung von IPMP (Aufgaben)

Teil VII IP Quality of Service (IPQoS)

32.  Einführung in IPQoS (Übersicht)

33.  Planen eines IPQoS-konformen Netzwerks (Aufgaben)

34.  Erstellen der IPQoS-Konfigurationsdatei (Aufgaben)

35.  Starten und Verwalten des IPQoS (Aufgaben)

36.  Verwenden von Flow Accounting und Erfassen von Statistiken (Aufgaben)

37.  IPQoS im Detail (Referenz)

Glossar

Index

IPv6 Neighbor Discovery-Protokoll

IPv6 führt das Neighbor Discovery-Protokoll ein (siehe RFC 2461, Neighbor Discovery for IP Version 6 (IPv6)). Eine Übersicht der wichtigsten Funktionen des Neighbor Discovery-Protokolls finden Sie unter Einführung in das IPv6 Neighbor Discovery-Protokoll.

In diesem Abschnitt werden die folgenden Funktionen des Neighbor Discovery-Protokolls beschrieben:

ICMP-Nachrichten im Neighbor Discovery-Protokoll

Das Neighbor Discovery-Protokoll definiert fünf neue Internet Control Message Protocol (ICMP)-Nachrichten. Diese Nachrichten haben die folgenden Aufgaben:

Automatische Konfiguration

Dieser Abschnitt enthält eine Übersicht der Schritte, die normalerweise bei einer automatischen Konfiguration einer Schnittstelle ausgeführt werden. Die automatische Konfiguration wird nur bei Multicast-konformen Links durchgeführt.

  1. Einem Multicast-konforme Schnittstelle wird beispielsweise während des Systemstarts auf einem Knoten aktiviert.

  2. Der Knoten beginnt die automatische Konfiguration durch Erzeugen einer Link-lokalen Adresse für die Schnittstelle.

    Die Link-lokale Adresse wird aus der Media Access Control (MAC)-Adresse der Schnittstelle gebildet.

  3. Der Knoten sendet eine Neighbor Solicitation-Nachricht, die die vorläufige Link-lokale Adresse als Ziel enthält.

    Über diese Nachricht soll überprüft werden, ob die künftige Adresse nicht bereits von einem anderen Knoten in der Verknüpfung verwendet wird. Nach dieser Überprüfung kann die Link-lokale Adresse einer Schnittstelle zugewiesen werden.

    1. Wird die vorgeschlagene Adresse bereits von einem anderen Knoten verwendet, gibt dieser Knoten eine Neighbor Advertisement-Nachricht aus, dass diese Adresse bereits verwendet wird.

    2. Falls ein anderer Knoten ebenfalls versucht, diese Adresse zu verwenden, so sendet der Knoten eine Neighbor Solicitation-Nachricht für das Ziel.

      Die Anzahl der Neighbor Solicitation-Nachrichten oder -Neuübertragungen sowie die Verzögerung zwischen aufeinander folgenden Nachrichten sind Link-spezifisch. Sie können diese Parameter nach Bedarf einstellen.

  4. Wenn ein Knoten feststellt, dass die gewünschte Link-lokale Adresse nicht einmalig ist, wird die automatische Konfiguration angehalten. In diesem Fall müssen Sie die Link-lokale Adresse der Schnittstelle manuell konfigurieren.

    Um die Wiederherstellung zu vereinfachen, können Sie eine alternative Schnittstellen-ID angeben, mit der die Standardbezeichnung außer Kraft gesetzt wird. Dann kann die automatische Konfiguration mit der neuen, vermutlich einmaligen Schnittstellen-ID fortgesetzt werden.

  5. Stellt ein Knoten fest, dass die potentielle Link-lokale Adresse einmalig ist, weist er diese Adresse der Schnittstelle zu.

    Jetzt verfügt der Knoten über Konnektivität auf IP-Ebene mit den benachbarten Knoten. Die verbleibenden Schritte bei der automatischen Konfiguration werden nur von Hosts durchgeführt.

Beziehen einer Router Advertisement-Nachricht

Die nächste Phase bei der automatischen Konfiguration ist das Beziehen einer Router Advertisement-Nachricht, es sei denn, es wird festgestellt, dass keine Router vorhanden sind. Wenn Router vorhanden sind, senden diese Router Advertisement-Nachrichten mit Angaben, welche Art einer automatischen Konfiguration ein Host ausführen soll.

Router senden die Router Advertisement-Nachrichten in regelmäßigen Abständen. Dennoch ist die Verzögerung zwischen aufeinander folgenden Advertisement-Nachrichten im Allgemeinen länger als ein Host, der eine automatische Konfiguration durchführt, warten kann. Um eine Advertisement-Nachricht schnell zu beziehen, sendet ein Host mindestens eine Router Solicitation-Nachricht an die Multicast-Gruppe „Alle-Router“.

Präfix-Konfigurationsvariablen

Neben anderen Informationen enthalten Router Advertisement-Nachrichten Präfixvariablen mit Daten, die von der statusfreien automatischen Adresskonfiguration zum Erzeugen von Präfixen verwendet werden. Das Feld „Stateless Address Autoconfiguration“ in Router Advertisement-Nachrichten wird unabhängig verarbeitet. Ein Optionsfeld mit Präfix-Daten, das Flag „Address Autoconfiguration“, gibt an, ob die Option auch für die statusfreie automatische Konfiguration gilt. Wird das Optionsfeld übernommen, können zusätzliche Optionsfelder ein Teilnetzpräfix mit Werten für die Lebensdauer enthalten. Diese Werte geben die Zeit an, über die Adressen, die aus dem Präfix erstellt wurden, priorisi Priorität genießen und gültig bleiben.

Da Router regelmäßig Router Advertisement-Nachrichten erzeugen, empfangen Hosts ständig neue Advertisements. IPv6-konforme Hosts verarbeiten die Informationen, die in den Advertisement-Nachrichten enthalten sind. Diese Informationen werden von den Hosts hinzugefügt. Darüber hinaus aktualisieren sie Informationen, die sie in vorherigen Advertisement-Nachrichten empfangen haben.

Einmaligkeit einer Adresse

Aus Sicherheitsgründen müssen alle Adressen auf Einmaligkeit geprüft werden, bevor sie einer Schnittstelle zugewiesen werden. Bei Adressen, die über die statusfreie automatische Konfiguration erzeugt wurden, ist die Situation anders. Die Einmaligkeit einer Adresse wird vielmehr durch die Komponente der Adresse ermittelt, die aus der Schnittstellen-ID gebildet wird. Wenn also ein Knoten die Einmaligkeit einer Link-lokale Adresse bereits geprüft hat, müssen zusätzliche Adressen nicht mehr einzeln überprüft werden. Die Adressen müssen aus der gleichen Schnittstellen-ID erstellt werden. Im Gegensatz dazu müssen alle manuell bezogenen Adressen einzeln auf Einmaligkeit geprüft werden. Einige Systemadministratoren sind der Meinung, dass der zusätzliche Aufwand für die Erkennung doppelt vorhandener Adressen die Vorteile nicht aufwiegt. An diesen Standorten kann die Erkennung doppelt vorhandener Adressen deaktiviert werden, indem ein Konfiguration-Flag für jede Schnittstelle eingerichtet wird.

Um die automatische Konfiguration zu beschleunigen, kann ein Host seine Link-lokale Adresse selbst erzeugen und die Einmaligkeit sicherstellen, während der Host auf eine Router Advertisement-Nachricht wartet. Ein Router kann eine Antwort auf eine Router Solicitation-Nachricht um wenige Sekunden verzögern. Entsprechend kann die gesamte Zeit bis zum Abschluss einer automatischen Konfiguration länger sein, wenn die zwei Schritte nacheinander ausgeführt werden.

Neighbor Solicitation und Unerreichbarkeit

Das Neighbor Discovery verwendet Neighbor Solicitation-Nachrichten, um festzustellen, ob mehreren Knoten die gleiche Unicast-Adresse zugewiesen wurde. Die Neighbor Unreachability Detection stellt den Ausfall eines Nachbarknotens oder den Ausfall eines Weiterleitungspfads zu einem Nachbarknoten fest. Sie fordert eine positive Bestätigung, dass Pakete, die an einen Nachbarn gesendet wurden, auch tatsächlich empfangen wurde. Darüber hinaus stellt die Neighbor Unreachability Detection fest, ob Datenpakete von der IP-Schicht des Nachbarknotens ordnungsgemäß verarbeitet wurden.

Die Neighbor Unreachability Detection verwendet Bestätigungen aus zwei Quellen: Protokollen der oberen Schichten und Neighbor Solicitation-Nachrichten. Wenn möglich, bestätigen die Protokolle der oberen Schichten, dass Datenpakete über eine Verbindung weitergeleitet werden. Wenn beispielsweise neue TCP-Bestätigungen empfangen wurden, wird bestätigt, dass die zuvor gesendeten Daten korrekt empfangen wurden.

Empfängt ein Knoten keine positive Bestätigung von den Protokollen der oberen Schichten, sendet er unicast Neighbor Solicitation-Nachrichten. Diese Nachrichten fordern Neighbor Advertisement-Nachrichten zur Bestätigung der Erreichbarkeit vom nächsten Hop. Um unnötigen Netzwerkverkehrs zu verhindern, werden diese Sondierungsnachrichten nur an Nachbarknoten gesendet, an die der Knoten aktiv Pakete sendet.

Algorithmus zur Erkennung doppelt vorhandener Adressen

Um sicherzustellen, dass alle konfigurierten Adressen auf einer bestimmten Verknüpfung einmalig sind, wird ein Algorithmus zur Erkennung doppelt vorhandener Adressen an den Adressen ausgeführt. Die Knoten müssen den Algorithmus anwenden, bevor die Adressen einer Schnittstelle zugewiesen werden. Der Algorithmus zur Erkennung doppelt vorhandener Adressen wird an allen Adressen angewendet.

Die in diesem Abschnitt beschriebene automatische Konfiguration gilt nur für Hosts und nicht für Router. Da die automatische Hostkonfiguration Daten verwendet, die von Routern bekannt gegeben werden, müssen Router auf andere Weise konfiguriert werden. Router erzeugen Link-lokale Adressen mithilfe eines Mechanismus, auf den in diesem Kapitel noch näher eingegangen wird. Darüber hinaus wird von Routern erwartet, dass sie den Algorithmus zur Erkennung doppelt vorhandener Adressen erfolgreich abschließen, bevor sie eine Adresse einer Schnittstelle zuweisen.

Proxy Advertisement-Nachrichten

Ein Router, der im Auftrag einer Zieladresse Pakete akzeptiert, kann nicht-überschreibende Neighbor Advertisement-Nachrichten ausgeben. Der Router kann Pakete für eine Zieladresse annehmen, die nicht in der Lage ist, selbst auf Neighbor Solicitation-Nachrichten zu reagieren. Derzeit ist die Verwendung eines Proxy nicht vorgegeben. Proxy-Advertisement-Nachrichten können jedoch verwendet werden, wenn mobile Knoten nicht mit der Verknüpfung verbunden sind. Beachten Sie, dass die Verwendung eines Proxy nicht als allgemeiner Mechanismus zur Arbeit mit Knoten vorgesehen ist, die dieses Protokoll nicht implementieren.

Lastausgleich für eingehende Daten

Knoten mit replizierten Schnittstellen müssen eventuell einen Lastausgleich beim Empfang eingehender Datenpakete über mehrere Netzwerkschnittstellen auf dem gleichen Link durchführen. Solche Knoten verfügen über Link-lokale Adressen, die der gleichen Schnittstelle zugeordnet sind. Beispielsweise kann ein einzelner Netzwerktreiber mehrere Netzwerkschnittstellenkarten als eine einzelne logische Schnittstelle mit mehreren Link-lokalen Adressen darstellen.

Der Lastausgleich erfolgt, indem Router die Link-lokale Quelladresse aus den Router Advertisement-Paketen weglassen. Folglich müssen Nachbarknoten Neighbor Solicitation-Nachrichten verwenden, um die Link-lokalen Adressen der Router zu lernen. Zurückgelieferte Neighbor Advertisement-Meldungen können dann Link-lokale Adressen enthalten, die je nachdem, wer die Solicitation veranlasst hat, unterschiedlich sind.

Ändern einer Link-lokalen Adresse

Ein Knoten, der sich der Änderung seiner Link-lokalen Adresse bewusst ist, kann unaufgefordert Multicast Neighbor Advertisement-Pakete senden. Der Knoten kann Multicast-Pakete an alle Knoten senden, um die ungültig gewordenen Link-lokalen Adressen in den Cache-Speichern zu aktualisieren. Das Senden unaufgeforderter Advertisement-Nachrichten dient ausschließlich zur Leistungsverbesserung. Der Algorithmus zur Neighbor Unreachability-Erkennung stellt sicher, dass alle Knoten die neue Adresse zuverlässig erkennen, obwohl die Verzögerung etwas größer sein könnte.

Vergleich von Neighbor Discovery mit ARP und verwandten IPv4-Protokollen

Die Funktionen des IPv6-Neighbor Discovery-Protokolls entsprechen einer Kombination der folgenden IPv4-Protokolle: Address Resolution Protocol (ARP), Internet Control Message Protocol (ICMP) Router Discovery und ICMP Redirect. IPv4 verfügt jedoch nicht über ein allgemein anerkanntes Protokoll oder einen Mechanismus zur Neighbor Unreachability-Erkennung. Die Host-Anforderungen geben jedoch einige mögliche Algorithmen zur Dead Gateway-Erkennung vor. Die Dead Gateway-Erkennung ist Teil der Probleme, die mit der Neighbor Unreachability-Erkennung gelöst werden.

In der folgenden Liste wird das Neighbor Discovery-Protokoll mit dem entsprechenden Satz an IPv4-Protokollen verglichen.