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)
Weiterführende IPv6-Adressierungsformate
Von 6to4 abgeleitete Adressierung auf einem Host
IPv6-Multicast-Adressen im Detail
Implementierung von IPv6 unter Oracle Solaris
IPv6-Schnittstellenkonfigurationsdatei
/etc/inet/ipaddrsel.conf-Konfigurationsdatei
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
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
Beziehen einer Router Advertisement-Nachricht
Präfix-Konfigurationsvariablen
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
Router Advertisement-Nachrichten
Router Advertisement-Nachrichten
Paketfluss durch den 6to4-Tunnel
Sicherheitsbetrachtungen bei Tunneln zu einem 6to4-Relay-Router
IPv6-Erweiterungen zu den Oracle Solaris-Namen-Services
Ä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
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)
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)
28. Verwalten von Mobile IP (Aufgaben)
29. Mobile IP-Dateien und Befehle (Referenz)
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)
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:
Das Neighbor Discovery-Protokoll definiert fünf neue Internet Control Message Protocol (ICMP)-Nachrichten. Diese Nachrichten haben die folgenden Aufgaben:
Router Solicitation – Nachdem eine Schnittstelle aktiviert wurde, können Hosts so genannte Router Solicitation-Nachrichten senden. Die Solicitation-Nachrichten fordern Router auf, sofort und nicht erst zur nächsten geplanten Zeit Router Advertisement-Nachrichten zu erzeugen.
Router Advertisement – Router geben ihr Vorhandensein, verschiedene Link-Parameter und verschiedene Internet-Parameter bekannt. Sie senden diese Advertisement-Nachrichten entweder regelmäßig oder als Reaktion auf eine Router Solicitation-Nachricht. Router Advertisement-Nachrichten können Präfixe enthalten, die zur On-Link-Feststellung oder Adresskonfiguration, einem vorgeschlagenen Grenzwert für Hops usw. verwendet werden können.
Neighbor Solicitation – Knoten senden Neighbor Solicitation-Nachrichten, um die Sicherungsschichtadresse eines Nachbarknotens zu ermitteln. Neighbor Solicitation-Nachrichten dienen auch dazu, um festzustellen, ob ein Nachbarknoten noch immer über eine zwischengespeicherte Sicherungsschichtadresse erreichbar ist. Neighbor Solicitations-Nachrichten werden auch zur Erkennung doppelt vorhandener Adressen verwendet.
Neighbor Advertisement – Ein Knoten sendet Neighbor Advertisement-Nachrichten als Reaktion auf eine Neighbor Solicitation-Nachricht. Der Knoten kann auch unaufgeforderte Neighbor Advertisement-Nachrichten senden, um eine Änderung der Sicherungsschichtadresse bekannt zu geben.
Redirect – Router verwenden Redirect-Nachrichten, um Hosts über einen besseren ersten Hop zu einem Ziel zu informieren, oder darüber, dass sich das Ziel auf dem gleichen Link befindet.
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.
Einem Multicast-konforme Schnittstelle wird beispielsweise während des Systemstarts auf einem Knoten aktiviert.
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.
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.
Wird die vorgeschlagene Adresse bereits von einem anderen Knoten verwendet, gibt dieser Knoten eine Neighbor Advertisement-Nachricht aus, dass diese Adresse bereits verwendet wird.
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.
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.
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.
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“.
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.
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.
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.
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.
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.
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.
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.
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.
Die Router-Erkennung ist Teil des allgemeinen IPv6-Protokollsatzes. IPv6-Hosts benötigen keinen snoop-Befehl für die Routing-Protokolle, um einen Router zu finden. IPv4 verwendet ARP, ICMP Router-Erkennung und ICMP-Redirect zur Router-Erkennung.
IPv6-Router Advertisement-Nachrichten übertragen Link-lokale Adressen. Zum Auflösen der Link-lokalen Adresse des Routers müssen keine zusätzlichen Pakete ausgetauscht werden.
Router Advertisement-Nachrichten übertragen die Standortpräfixe eines Links. Zur Konfiguration der Netzmaske ist kein separater Mechanismus erforderlich, wie dies bei IPv4 der Fall ist.
Router Advertisement-Nachrichten ermöglichen eine automatische Addresskonfiguration. Die automatische Konfiguration ist in IPv4 nicht implementiert.
Das Neighbor Discovery-Protokoll ermöglicht es IPv6-Routern, eine für den Link geltende MTU für Hosts bekannt zu geben. Entsprechend verwenden alle Knoten den gleichen MTU-Wert auf Links, für die keine MTU definiert wurde. IPv4-Hosts im gleichen Netzwerk können unterschiedliche MTUs aufweisen.
Im Gegensatz zu IPv4-Broadcast-Adressen sind IPv6-Adressauflösung-Multicasts über 4 (2^32) Milliarden Multicast-Adressen verteilt, wodurch aufgrund der Adressauflösung auftretende Unterbrechungen auf Knoten, bei denen es sich nicht um das Ziel handelt, wesentlich reduziert werden. Darüber hinaus sollten nicht-IPv6-Computer überhaupt nicht unterbrochen werden.
IPv6-Redirects enthalten die Link-lokale Adresse des neuen ersten Hop. Eine separate Adressauflösung ist nach dem Empfang einer Umleitung (Redirect) nicht mehr erforderlich.
Einem IPv6-Netzwerk können mehrere Standortpräfixe zugewiesen werden. Standardmäßig lernen alle lokalen Standortpräfixe aus den Router Advertisement-Nachrichten. Router können jedoch auch so konfiguriert werden, dass einige oder alle Präfixe in Router Advertisement-Nachrichten weggelassen werden. In diesen Fällen nehmen Hosts an, dass sich die Ziele in Remote-Netzwerken befinden. Entsprechend senden sie den Datenverkehr an Router. Ein Router kann dann gegebenenfalls Umleitungen initiieren.
Im Gegensatz zu IPv4 geht der Empfänger einer IPv6-Redirect-Nachricht davon aus, dass sich der nächste Hop im lokalen Netzwerk befindet. Unter IPv4 ignoriert ein Host Redirect-Nachrichten, in denen angegeben wird, dass sich ein nächster Hop entsprechend der Netzwerkmaske nicht im lokalen Netzwerk befindet. Der IPv6-Redirect-Mechanismus ist analog der XRedirect-Funktion in IPv4. Der Redirect-Mechanismus eignet sich für nicht-Broadcast- und gemeinsam genutzte Media-Links. In diesen Netzwerken sollen Knoten nicht auf alle Präfixe für Ziele auf dem lokalen Link prüfen.
Die Neighbor Unreachability Detection unter IPv6 verbessert die Paketzustellung bei fehlerhaften Routern. Diese Funktion verbessert die Paketzustellung bei teilweise fehlerhaften oder partitionierten Links. Darüber hinaus verbessert diese Funktion die Paketzustellung über Knoten, deren Link-lokale Adressen geändert wurden. Beispielsweise können mobile Knoten aus dem lokalen Netzwerk verschoben worden sein, ohne dass sie aufgrund veralteter ARP-Caches die Konnektivität verlieren. IPv4 verfügt über keine entsprechende Methode zur Neighbor Unreachability Detection.
Im Gegensatz zu ARP erfasst das Neighbor Discovery-Protokoll Half-Link-Ausfälle mithilfe der Neighbor Unreachability Detection. Das Neighbor Discovery-Protokoll vermeidet das Senden von Datenverkehr an Nachbarknoten, wenn keine doppelseitige Konnektivität vorhanden ist.
IPv6-Hosts können die Router-Assoziationen mithilfe von Link-lokalen Adressen pflegen, um Router eindeutig zu identifizieren. Die Fähigkeit zur Identifizierung von Routern ist für Router Advertisement- und Redirect -Nachrichten erforderlich. Hosts müssen Router-Assoziationen pflegen, wenn globale Präfixe am Standort verwendet werden. IPv4 verfügt über keine vergleichbare Methode zur Identifizierung von Routern.
Da Neighbor Discovery-Nachrichten nach dem Empfang auf maximal 255 Hops beschränkt sind, ist das Protokoll immun gegenüber Spoofing-Angriffen, die von Knoten außerhalb des Links stammen. Im Gegensatz dazu können IPv4-Knoten außerhalb des Links ICMP-Redirect-Nachrichten senden. IPv4-Knoten außerhalb des Links können auch Router Advertisement-Nachrichten senden.
Durch Ausführen der Adressauflösung auf der ICMP-Schicht wird das Neighbor Discovery-Protokoll weniger von Medien abhängig als das ARP. Entsprechend können standardmäßige IP-Authentifizierungs- und Sicherheitsmechanismen verwendet werden.