Kapitel 11 IPv6 im Detail (Referenz)

Dieses Kapitel enthält die folgenden Referenzinformationen zur Implementierung von IPv6 in Oracle Solaris.

• Weiterführende IPv6-Adressierungsformate

• Format der IPv6-Paket-Header

• Dual-Stack-Protokolle

• Oracle Solaris 10 IPv6-Implementierung

• IPv6 Neighbor Discovery-Protokoll

• IPv6-Routing

• IPv6-Tunnel

• IPv6-Erweiterungen zu den Oracle Solaris-Namen-Services

• NFS und RPC IPv6-Unterstützung

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

Eine Übersicht der IPv6-Konzepte finden Sie in Kapitel 3Einführung in IPv6 (Überblick). Aufgaben zur Konfiguration eines IPv6-konformen Netzwerks finden Sie in Kapitel 7Konfigurieren eines IPv6-Netzwerks (Vorgehen).

Neuerungen in diesem Kapitel

Unter Solaris 10 7/07 wird die /etc/inet/ipnodes-Datei nicht mehr benötigt. Verwenden Sie /etc/inet/ipnodes nur für frühere Oracle Solaris 10-Versionen, wie es in den jeweiligen Verfahren beschrieben wird.

Weiterführende IPv6-Adressierungsformate

In Kapitel 3Einführung in IPv6 (Überblick) wurden die am häufigsten verwendeten IPv6-Adressierungsformate vorgestellt: Unicast-Standortadresse und Link-lokale Adresse. In diesem Abschnitt finden Sie detaillierte Erklärungen der in Kapitel 3Einführung in IPv6 (Überblick) nicht beschriebenen Adressierungsformate:

• Von 6to4 abgeleitete Adressen

• IPv6-Multicast-Adressen im Detail

Von 6to4 abgeleitete Adressen

Wenn Sie beabsichtigen, einen 6to4-Tunnel von einem Router- oder einem Host-Endpunkt zu konfigurieren, müssen Sie das 6to4-Standortpräfix in der /etc/inet/ndpd.conf-Datei auf dem System mit dem Endpunkt bekannt geben. Eine Einführung in die Konfiguration von 6to4-Tunneln und zugehörige Aufgaben finden Sie in unter So konfigurieren Sie einen 6to4-Tunnel.

Die nächste Abbildung zeigt die Komponenten eines 6to4-Standortpräfix.

Abbildung 11–1 Komponenten eines 6to4-Standortpräfix

Die nächste Abbildung zeigt die Komponenten eines Teilnetzpräfix für einen 6to4-Standort, die Sie in die ndpd.conf-Datei aufnehmen würden.

Abbildung 11–2 Komponenten eines 6to4-Teilnetzpräfix

In dieser Tabelle werden die Komponenten eines 6to4-Teilnetzpräfix erklärt, sowie deren Längen und Definitionen.

Von 6to4 abgeleitete Adressierung auf einem Host

Wenn ein IPv6-Host das von 6to4 abgeleitete Präfix über eine Router-Advertisement-Nachricht empfängt, konfiguriert der Host automatisch eine von 6to4 abgeleitete Adresse auf der Schnittstelle. Die Adresse hat das folgende Format:

prefix:IPv4-address:subnet-ID:interface-ID/64

Die Ausgabe des Befehls ifconfig -a auf einem Host mit einer 6to4-Schnittstelle ähnelt dem Folgenden:

qfe1:3: flags=2180841<UP,RUNNING,MULTICAST,ADDRCONF,ROUTER,IPv6>
 mtu 1500 index 7
        inet6 2002:8192:56bb:9258:a00:20ff:fea9:4521/64 

In dieser Ausgabe folgt die von 6to4 abgeleitete Adresse inet6.

In der folgenden Tabelle werden die Komponenten der von 6to4 abgeleiteten Adresse erklärt, sowie die Längen der Komponenten und die von den Komponenten bereitgestellten Informationen.

IPv6-Multicast-Adressen im Detail

Mit einer IPv6-Multicast-Adresse können identische Informationen oder Services an eine definierte Schnittstellengruppe, die so genannte Multicast-Gruppe, verteilt werden. In der Regel befinden sich die Schnittstellen einer Multicast-Gruppe auf verschiedenen Knoten. Eine Schnittstelle kann mehreren Multicast-Gruppen angehören. Pakete, die an die Multicast-Adresse gesendet werden, werden an alle Mitglieder der Multicast-Gruppe geleitet. Eine Verwendungsmöglichkeit von Multicast-Adressen ist das Broadcasten von Informationen, ähnlich den Funktionen der IPv4-Broadcast-Adresse.

In der folgenden Tabelle wird das Format der Multicast-Adresse vorgestellt.

Im Folgenden werden die Inhalte jedes Feldes beschrieben.

• 11111111 – Kennzeichnet die Adresse als Multicast.

• FLGS – Satz der vier Flags 0,0,P,T. Die ersten zwei Flags müssen 0 sein. Das Feld P nimmt einen der beiden folgenden Werte an:

  • 0 = Multicast-Adresse, die nicht auf dem Netzwerkpräfix basierend zugewiesen wurde

  • 1 = Multicast-Adresse, die basierend auf dem Netzwerkpräfix zugewiesen wurde

  Wenn P auf 1 gesetzt ist, muss T ebenfalls auf 1 gesetzt sein.

• Reserviert - Reserviert für den Wert null.

• Plen - Anzahl der Bit im Standortpräfix, die das Teilnetz für eine Multicast-Adresse identifizieren, die basierend auf einem Standortpräfix zugewiesen wurde.

• Gruppen-ID - Bezeichner für die Multicast-Gruppe, entweder permanent oder dynamisch.

Ausführliche Informationen zum Multicast-Format finden Sie in RFC 3306, „Unicast-Prefix-based IPv6 Multicast Addresses.

Einige IPv6-Multicast-Adressen sind permanent von der Internet Assigned Numbers Authority (IANA) zugewiesen. Beispiele dieser Adressen sind All Nodes Multicast Addresses und All Routers Multicast Addresses, die für alle IPv6-Hosts und -Routern erforderlich sind. IPv6-Multicast-Adressen können auch dynamisch zugewiesen werden. Weitere Informationen zur ordnungsgemäßen Verwendung von Multicast-Adressen und -Gruppen finden Sie in RFC 3307, „Allocation Guidelines for IPv6 Multicast Addresses.

Format der IPv6-Paket-Header

Das IPv6-Protokoll definiert eine Reihe von Headern, einschließlich dem einfachen IPv6-Header und dem IPv6-Extension-Header. In der folgenden Abbildung werden die Felder in einem IPv6-Header und die Reihenfolge dieser Felder gezeigt.

Abbildung 11–3 Format eines einfachen IPv6-Header

Die folgende Liste beschreibt die Funktionen jedes Header-Feldes.

• Version – 4-Bit-Versionsnummer des Internet-Protokolls = 6.

• Verkehrsklasse – Feld in der Länge 8 Bit für die Verkehrsklasse.

• Fluss-Label – Feld in der Länge 20 Bit.

• Nutzlastlänge – Vorzeichenloser, ganzzahliger Wert in der Länge 16 Bit; der Rest des Pakets, der dem IPv6-Header folgt, in Oktetten.

• Nächster Header – Selektor in der Länge 8 Bit. Gibt den Headertyp an, der dem IPv6-Header unmittelbar folgt. Verwendet die gleichen Werte wie das IPv4-Protokollfeld

• Hop-Grenzwert – Vorzeichenloser, ganzzahliger Wert in der Länge 8 Bit. Wird von jedem Knoten, der das Paket weiterleitet, um 1 verringert. Das Paket wird abgeworfen, wenn die Hop-Grenzwert auf null verringert wurde.

• Quelladresse – 128 Bit. Die Adresse des ursprünglichen Senders des Pakets.

• Zieladresse – 128 Bit. Die Adresse des geplanten Empfängers des Pakets. Der geplante Empfänger muss nicht unbedingt der Empfänger sein, wenn ein optionaler Routing-Header vorhanden ist.

IPv6-Extension-Header

IPv6-Optionen werden in separaten Extension-Headern platziert, die sich zwischen dem IPv6-Header und dem Transportschicht-Header in einem Paket befinden. Die meisten IPv6-Extension-Header werden von den Routern im Zustellungspfad eines Pakets weder geprüft noch verarbeitet, bis das Paket an seinem endgültigen Ziel eintrifft. Diese Funktion stellt für Pakete, die Optionen enthalten, eine wesentliche Verbesserung der Router-Performance dar. Bei IPv4 wird durch die Angabe einer Option erforderlich, dass der Router alle Optionen untersucht.

Im Gegensatz zu IPv4-Optionen können IPv6-Extension-Header eine beliebige Länge annehmen, und die Anzahl an Optionen, die ein Paket enthalten kann, ist nicht auf 40 Byte beschränkt. Diese Funktion (neben der Art und Weise, wie IPv6-Optionen verarbeitet werden), ermöglicht es, dass IPv6-Optionen für Funktionen verwendet werden, deren Umsetzung unter IPv4 nicht möglich wäre.

Um die Performance bei der Verarbeitung von nachfolgenden Option-Headern und dem darauf folgenden Transportprotokoll zu verbessern, sind IPv6-Optionen immer ein ganzzahliges Vielfaches mit einer Länge von 8 Oktetten. Das ganzzahlige Vielfache von 8 Oktetten behält die Gruppierung der nachfolgenden Header bei.

Folgende IPv6-Extension-Header sind derzeit definiert:

• Routing – Erweitertes Routing, z. B. lose IPv4-Quellroute

• Fragmentierung – Fragmentierung und Neuassemblierung

• Authentifizierung – Integrität und Authentifizierung und Sicherheit

• Einkapselung der Sicherheitsnutzlast – Vertraulichkeit

• Hop-by-Hop Optionen – Spezielle Optionen, die eine Hop-by-Hop-Verarbeitung erfordern

• Zieloptionen – Optionale Informationen, die vom Zielknoten untersucht werden

Dual-Stack-Protokolle

Der Begriff Dual-Stack bezieht sich in der Regel auf eine vollständige Duplikation aller Ebenen im Protokollstapel, von der Anwendungs- bis zur Netzwerkschicht. Ein Beispiel einer vollständigen Duplikation ist ein System, das sowohl OSI- als auch TCP/IP-Protokolle ausführt.

Oracle Solaris ist Dual-Stack-konform. Dies bedeutet, dass Oracle Solaris sowohl das IPv4- als auch das IPv6-Protokoll implementieren kann. Bei der Installation des Betriebssystems können Sie wählen, ob die IPv6-Protokolle auf der IP-Schicht oder ob nur die standardmäßigen IPv4-Protokolle aktiviert werden. Der übrige TCP/IP-Stapel ist identisch. Entsprechend können die gleichen Transportprotokolle, TCP, UDP und SCTP, sowohl über IPv4 als auch über IPv6 ausgeführt werden. Außerdem können die gleichen Anwendungen sowohl über IPv4 als auch über IPv6 ausgeführt werden. Abbildung 11–4 zeigt, wie die IPv4- und IPv6-Protokolle über die verschiedenen Ebenen der Internet-Protokollfamilie als Dual-Stack arbeiten.

Abbildung 11–4 Architektur eines Dual-Stack-Protokolls

Bei diesem Dual-Stack-Szenario werden Gruppen von Hosts und Routern neben der Unterstützung von IPv4 zur Unterstützung auf IPv6 aufgerüstet. Der Dual-Stack-Ansatz stellt sicher, dass die aufgerüsteten Knoten immer über IPv4 mit nur-IPv4-Knoten zusammenarbeiten können.

Oracle Solaris 10 IPv6-Implementierung

In diesem Abschnitt werden die Dateien, Befehle und Daemons beschrieben, mit denen IPv6 in Oracle Solaris implementiert wird.

IPv6-Konfigurationsdateien

In diesem Abschnitt werden die Konfigurationsdateien beschrieben, die Teil einer IPv6-Implementierung sind:

• ndpd.conf-Konfigurationsdatei

• IPv6-Schnittstellenkonfigurationsdatei

• /etc/inet/ipaddrsel.conf-Konfigurationsdatei

ndpd.conf-Konfigurationsdatei

Die /etc/inet/ndpd.conf-Datei dient zur Konfiguration von Optionen, die vom Neighbor Discovery-Daemon in.ndpd verwendet werden. Bei einem Router verwenden Sie ndpd.conf hauptsächlich zur Konfiguration des Standortpräfix, das auf dem Link bekannt gegeben wird. Bei einem Host verwenden Sie ndpd.conf zum Deaktivieren der automatischen Adresskonfiguration oder zur Konfiguration von temporären Adressen.

Die folgende Tabelle zeigt die Schlüsselwörter, die in der ndpd.conf-Datei verwendet werden.

In der ndpd.conf-Datei können Sie die Schlüsselwörter in der folgenden Tabelle mit bestimmten Router-Konfigurationsvariablen verwenden. Diese Variables werden ausführlich in RFC 2461, Neighbor Discovery for IP Version 6 (IPv6) definiert.

Die nächste Tabelle zeigt die Variablen zur Konfiguration einer Schnittstelle und definiert diese kurz.

Die nächste Tabelle zeigt die Variablen zur Konfiguration von IPv6-Präfixen.

Beispiel 11–1 /etc/inet/ndpd.conf-Datei

Das folgende Beispiel zeigt, wie die Schlüsselwörter und Konfigurationsvariablen in der Datei ndpd.conf verwendet werden. Löschen Sie die Kommentarzeichen (#), um die Variable zu aktivieren.

# ifdefault      [variable-value ]*
# prefixdefault [variable-value ]*
# if ifname   [variable-value ]*
# prefix prefix/length ifname
#
#  Per interface configuration variables
#
#DupAddrDetectTransmits
#AdvSendAdvertisements
#MaxRtrAdvInterval
#MinRtrAdvInterval
#AdvManagedFlag
#AdvOtherConfigFlag
#AdvLinkMTU
#AdvReachableTime
#AdvRetransTimer
#AdvCurHopLimit
#AdvDefaultLifetime
#
# Per Prefix:  AdvPrefixList configuration variables
#
#
#AdvValidLifetime
#AdvOnLinkFlag
#AdvPreferredLifetime
#AdvAutonomousFlag
#AdvValidExpiration
#AdvPreferredExpiration

ifdefault AdvReachableTime 30000 AdvRetransTimer 2000
prefixdefault AdvValidLifetime 240m AdvPreferredLifetime 120m

if qe0 AdvSendAdvertisements 1
prefix 2:0:0:56::/64 qe0
prefix fec0:0:0:56::/64 qe0

if qe1 AdvSendAdvertisements 1
prefix 2:0:0:55::/64 qe1
prefix fec0:0:0:56::/64 qe1

if hme1 AdvSendAdvertisements 1
prefix  2002:8192:56bb:1::/64 qfe0 

if hme1 AdvSendAdvertisements 1
prefix  2002:8192:56bb:2::/64 hme1

IPv6-Schnittstellenkonfigurationsdatei

IPv6 verwendet die /etc/hostname6.Schnittstelle-Datei beim Booten, um die logischen IPv6-Schnittstellen automatisch zu definieren. Wenn Sie während der Oracle Solaris-Installation die Option ?IPv6-konform“ ausgewählt haben, erstellt das Installationsprogramm neben der /etc/hostname.-Schnittstellendateieine /etc/hostname6.-Schnittstellendatei für die primäre Netzwerkschnittstelle.

Erfasst das Installationsprogramm weitere physikalische Schnittstellen, werden Sie aufgefordert, auch diese Schnittstellen zu konfigurieren. Für jede zusätzliche Schnittstelle, die Sie auswählen, erstellt das Installationsprogramm Konfigurationsdateien für physikalische IPv4-Schnittstellen und für logische IPv6-Schnittstellen.

Wie IPv4-Schnittstellen können Sie auch IPv6-Schnittstellen nach der Oracle Solaris-Installation manuell konfigurieren. In diesem Fall liegen Sie /etc/hostname6.Schnittstelle-Dateien für die neuen Schnittstellen an. Anweisungen zur manuellen Konfiguration von Schnittstellen finden Sie unter Verwalten der Schnittstellen in Solaris 10 3/05 oderKapitel 6Verwalten von Netzwerkschnittstellen (Aufgaben).

Eine Konfigurationsdatei für eine Netzwerkschnittstelle muss die folgende Syntax aufweisen:

hostname.interface
hostname6.interface

Die Variable Schnittstelle hat die folgende Syntax:

dev[.module[.module ...]]PPA

Gerät

Gibt ein Netzwerkschnittstellengerät an. Bei diesem Gerät kann es sich um eine physikalische Schnittstelle, z. B. eri oder qfe, oder um eine logische Schnittstelle, zum Beispiel einen Tunnel handeln. Weitere Informationen hierzu finden Sie unter IPv6-Schnittstellenkonfigurationsdatei.

Modul

Führt mindestens ein STREAMS-Modul auf, das dem Gerät beim Plumben (Aktivieren) zugewiesen wird.

PPA

Gibt den physikalischen Anschlusspunkt an.

Die Syntax [.[.]] ist ebenfalls zulässig.

Beispiel 11–2 IPv6-Schnittstellenkonfigurationsdateien

Im Folgenden sind Beispiele für gültige Namen einer IPv6-Konfigurationsdatei aufgeführt:

hostname6.qfe0
hostname.ip.tun0
hostname.ip6.tun0
hostname6.ip6to4tun0
hostname6.ip.tun0
hostname6.ip6.tun0

/etc/inet/ipaddrsel.conf-Konfigurationsdatei

Die Datei /etc/inet/ipaddrsel.conf enthält die Richtliniendatei für eine standardmäßige IPv6-Adressauswahl. Wenn Sie Oracle Solaris so installieren, dass IPv6 aktiviert ist, hat diese Datei den in Tabelle 11–5 gezeigten Inhalt.

Der Inhalt von /etc/inet/ipaddrsel.conf kann geändert werden. In den meisten Fällen wird jedoch von der Bearbeitung dieser Datei abgeraten. Falls eine Bearbeitung erforderlich wird, verwenden Sie das unter So verwalten Sie die Richtlinientabelle zur IPv6-Adressauswahl beschriebene Verfahren. Weitere Informationen zur ippaddrsel.conf-Datei finden Sie unter Gründe zur Bearbeitung der Richtlinientabelle für die IPv6-Adressauswahl und in der Manpage ipaddrsel.conf(4).

IPv6-bezogene Befehle

In diesem Abschnitt werden die Befehle beschrieben, die mit der IPv6-Implementierung zu Oracle Solaris hinzugefügt werden. Hier werden auch die Modifikationen an vorhandenen Befehlen beschrieben, um IPv6 zu unterstützen.

ipaddrsel-Befehl

Mit dem Befehl ipaddrsel können Sie die Richtlinientabelle für die IPv6-Standard-Adressauswahl bearbeiten.

Der Oracle Solaris-Kernel verwendet die Richtlinientabelle für die IPv6-Standard-Adressauswahl, um die Zieladressen in eine Reihenfolge zu bringen und die Quelladresse eines IPv6-Paket-Headers auszuwählen. Die Richtlinientabelle ist in der /etc/inet/ipaddrsel.conf-Datei enthalten.

Die folgenden Tabelle enthält die Standard-Adressformate und deren Prioritäten für die Richtlinientabelle. Ausführliche technische Informationen zur IPv6-Adressenauswahl finden Sie in der Manpage inet6(7P).

In dieser Tabelle haben die IPv6-Präfixe (::1/128 und ::/0) Vorrang vor den 6to4-Adressen (2002::/16) und den IPv4-Adressen (::/96 und ::ffff:0:0/96). Aus diesem Grund wählt der Kernel standardmäßig die globale IPv6-Adresse der Schnittstelle für Pakete, die für ein anderes IPv6-Ziel bestimmt sind. Die IPv4-Adresse der Schnittstelle hat eine geringere Priorität, insbesondere für Pakete, die an einen IPv6-Ziel gerichtet sind. Bei der ausgewählten IPv6-Quelladresse verwendet der Kernel darüber hinaus das IPv6-Format für die Zieladresse.

Gründe zur Bearbeitung der Richtlinientabelle für die IPv6-Adressauswahl

In den meisten Fällen müssen Sie die Richtlinientabelle für die IPv6-Standard-Adressauswahl nicht ändern. Wenn Sie die Richtlinientabelle bearbeiten müssen, verwenden Sie den Befehl ipaddrsel.

In den folgenden Fällen können Sie die Richtliniendatei ändern:

• Wenn das System über eine Schnittstelle verfügt, die für ein 6to4-Tunnel verwendet wird, können Sie den 6to4-Adressen eine höhere Priorität zuweisen.

• Wenn Sie möchten, dass eine bestimmte Quelladresse nur bei einem Datenaustausch mit einer bestimmten Zieladresse verwendet wird, können Sie diese Adressen zur Richtliniendatei hinzufügen. Dann priorisieren Sie diese Adressen mit dem Befehl ifconfig.

• Wenn Sie möchten, dass IPv4-Adressen eine höhere Prioritätsstufe als IPv6-Adressen einnehmen, können Sie die Priorität ::ffff:0:0/96 zu einem höheren Wert ändern.

• Möchten Sie veralteten Adressen eine höhere Priorität zuweisen, fügen Sie die veraltete Adresse der Richtliniendatei hinzu. Beispielsweise sind Standort-lokale Adressen in IPv6 jetzt veraltet. Diese Adressen haben das Präfix fec0::/10. Sie können die Richtlinientabelle jedoch so ändern, dass Standort-lokale Adressen eine höhere Priorität erhalten.

Weitere Informationen zum Befehl ipaddrsel finden Sie in der Manpage ipaddrsel(1M).

6to4relay-Befehl

6to4-Tunneling ermöglicht die Kommunikation zwischen isolierten 6to4-Standorten. Um jedoch Pakete an einen nativen, nicht-6to4 IPv6-Standort zu übertragen, muss der 6to4-Router einen Tunnel zu einem 6to4-Relay-Router einrichten. Der 6to4-Relay-Router leitet die 6to4-Pakete an das IPv6-Netzwerk und schließlich an den nativen IPv6-Standort. Wenn Ihr 6to4-konformer Standort Daten mit einem nativen IPv6-Standort austauschen muss, können Sie den entsprechenden Tunnel mit dem Befehl 6to4relay einrichten.

Da die Verwendung von Relais-Routern nicht sicher ist, wird das Tunneling zu einem Relay-Router in Oracle Solaris standardmäßig deaktiviert. Berücksichtigen Sie diese Aspekte beim Erstellen eines Tunnels zu einem 6to4-Relay-Router, bevor Sie dieses Szenario umsetzen. Ausführliche Informationen zu 6to4-Relay-Routern finden Sie unter Sicherheitsbetrachtungen bei Tunneln zu einem 6to4-Relay-Router. Wenn Sie sich entschließen, die Unterstützung für 6to4-Relay-Router zu implementieren, finden Sie die zugehörigen Verfahren unter So konfigurieren Sie einen 6to4-Tunnel.

Syntax von 6to4relay

Der Befehl 6to4relay weist die folgende Syntax auf:

6to4relay -e [-a IPv4-address] -d -h

-e

Unterstützt Tunnel zwischen dem 6to4-Router und einem Anycast 6to4-Relay-Router. Die Endpunktadresse des Tunnels wird dann auf 192.88.99.1 gesetzt, die Standardadresse für die Anycast-Gruppe der 6to4-Relay-Router.

-a IPv4-Adresse

Unterstützt Tunnel zwischen dem 6to4-Router und einem 6to4-Relay-Router mit der angegebenen IPv4-Adresse.

-d

Deaktiviert die Unterstützung für das Tunneling zu einem 6to4-Relay-Router, die Standardeinstellung für Oracle Solaris.

-h

Zeigt die Hilfe für 6to4relay an.

Weitere Informationen finden Sie in der Manpage 6to4relay(1M).

Beispiel 11–3 Standardmäßige Statusanzeige der Unterstützung für 6to4-Relay-Router

Der Befehl 6to4relay ohne Argumente zeigt den aktuellen Status der Unterstützung für 6to4-Relay-Router an. Das folgende Beispiel zeigt die Standardeinstellung für die Oracle Solaris-Implementierung von IPv6 an.

# /usr/sbin/6to4relay
6to4relay:6to4 Relay Router communication support is disabled

Beispiel 11–4 Statusanzeige bei aktivierter Unterstützung für 6to4-Relay-Router

Wenn die Relay-Router-Unterstützung aktiviert ist, liefert der Befehl 6to4relay die folgende Ausgabe:

# /usr/sbin/6to4relay
6to4relay:6to4 Relay Router communication support is enabled
IPv4 destination address of Relay Router=192.88.99.1

Beispiel 11–5 Statusanzeige bei angegebenem 6to4-Relay-Router

Wenn Sie die Option -a und eine IPv4-Adresse mit dem Befehl 6to4relay angeben, wird die mit -a angegebene IPv4-Adresse anstelle von 192.88.99.1 angezeigt.

6to4relay meldet die erfolgreiche Ausführung der Optionen -d, -e und-a IPv4-Adresse nicht. Jedoch zeigt 6to4relay bei der Ausführung dieser Optionen eventuell generierte Fehlermeldungen an.

ifconfig-Befehlserweiterungen zur Unterstützung von IPv6

Mit dem Befehl ifconfig können Sie IPv6-Schnittstellen aktivieren und das Tunneling-Modul plumben. ifconfig verwendet einen erweiterten Satz ioctls, um sowohl IPv4- als auch IPv6-Netzwerkschnittstellen zu konfigurieren. Im Folgenden werden die ifconfig-Optionen für die Unterstützung von IPv6-Vorgängen aufgeführt. Unter Überwachen der Schnittstellenkonfiguration mit dem Befehl ifconfig finden Sie die IPv4- und IPv6-Aufgaben, die ifconfig einbeziehen.

index

Richtet den Schnittstellenindex ein.

tsrc/tdst

Richtet die Tunnelquelle oder das -ziel ein.

addif

Erstellt die nächste verfügbare logische Schnittstelle.

removeif

Löscht die logische Schnittstelle mit der angegebenen IP-Adresse.

destination

Richtet eine Point-to-Point-Zieladresse für eine Schnittstelle ein.

set

Richtet eine Adresse, Netzmaske oder beides für eine Schnittstelle ein.

subnet

Richtet die Teilnetzadresse einer Schnittstelle ein.

xmit/-xmit

Aktiviert oder deaktiviert die Paketübertragung auf einer Schnittstelle.

Kapitel 7Konfigurieren eines IPv6-Netzwerks (Vorgehen) enthält Verfahren zur IPv6-Konfiguration.

Beispiel 11–6 Hinzufügen einer logischen IPv6-Schnittstelle mit der Option -addif des Befehls ifconfig

Die folgende Syntax des Befehls ifconfig erstellt die logische Schnittstelle hme0:3:

# ifconfig hme0 inet6 addif up
Created new logical interface hme0:3

Diese Syntax des Befehls ifconfig überprüft, ob die neue Schnittstelle korrekt erstellt wurde:

# ifconfig hme0:3 inet6
hme0:3: flags=2000841<UP,RUNNING,MULTICAST,IPv6> mtu 1500 index 2
		inet6  inet6 fe80::203:baff:fe11:b321/10

Beispiel 11–7 Entfernen einer logischen IPv6-Schnittstelle mit der Option -removeif des Befehls ifconfig

Die folgende Syntax des Befehls ifconfig löscht die logische Schnittstelle hme0:3.

# ifconfig hme0:3 inet6 down

# ifconfig hme0 inet6 removeif 1234::5678

Beispiel 11–8 Verwenden des Befehls ifconfig zur Konfiguration einer IPv6-Tunnelquelle

# ifconfig ip.tun0 inet6 plumb index 13

Öffnet einen Tunnel, der dem Namen der physikalischen Schnittstelle zugeordnet wird.

# ifconfig ip.tun0 inet6
ip.tun0: flags=2200850<POINTOPOINT,RUNNING,MULTICAST,NONUD,
#IPv6> mtu 1480 index 13
		inet tunnel src 0.0.0.0 
		inet6 fe80::/10 --> :: 

Konfiguriert die Datenströme, die für TCP/IP erforderlich sind, um das Tunnelgerät zu verwenden und den Gerätestatus zu melden.

# ifconfig ip.tun0 inet6 tsrc 120.46.86.158 tdst 120.46.86.122

Konfiguriert die Quell- und Zieladresse des Tunnels.

# ifconfig ip.tun0 inet6
ip.tun0: flags=2200850<POINTOPOINT,RUNNING,MULTICAST,NONUD,
IPv6> mtu 1480 index 13
		inet tunnel src 120.46.86.158  tunnel dst 120.46.86.122
		inet6 fe80::8192:569e/10 --> fe80::8192:567a

Meldet dem neuen Gerätestatus nach der Konfiguration.

Beispiel 11–9 Konfiguration eines 6to4-Tunnels mithilfe des Befehls ifconfig (ausführlich)

Dieses Beispiel für die Konfiguration einer 6to4-Pseudoschnittstelle verwendet die Teilnetz-ID 1 und gibt die Host-ID in hexadezimaler Form an:

# ifconfig ip.6to4tun0 inet6 plumb
# ifconfig ip.6to4tun0 inet tsrc 129.146.86.187 \
2002:8192:56bb:1::8192:56bb/64 up

# ifconfig ip.6to4tun0 inet6
ip.6to4tun0: flags=2200041<UP,RUNNING,NONUD,IPv6>mtu 1480 index 11
        inet tunnel src 129.146.86.187 
        tunnel hop limit 60 
        inet6 2002:8192:56bb:1::8192:56bb/64 

Beispiel 11–10 Konfiguration eines 6to4-Tunnels mithilfe des Befehls ifconfig (Kurzform)

Das folgende Beispiel zeigt die Kurzform für die Konfiguration eines 6to4-Tunnels:

# ifconfig ip.6to4tun0 inet6 plumb
# ifconfig ip.6to4tun0 inet tsrc 129.146.86.187 up

# ifconfig ip.6to4tun0 inet6
ip.6to4tun0: flags=2200041<UP,RUNNING,NONUD,IPv6>mtu 1480 index 11
        inet tunnel src 129.146.86.187 
        tunnel hop limit 60 
        inet6 2002:8192:56bb::1/64 

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

Der Befehl netstat zeigt sowohl den IPv4- als auch den IPv6-Netzwerkstatus an. Setzen Sie den Wert DEFAULT_IP in der Datei /etc/default/inet_type, um auszuwählen, welche Protokollinformationen angezeigt werden. Alternativ können Sie hierzu die Befehlszeilenoption -f verwenden. Mit einer permanenten Einstellung von DEFAULT_IP können Sie sicherstellen, dass netstat nur IPv4-Informationen anzeigt. Diese Einstellung können Sie durch die Option -f außer Kraft setzen. Weitere Informationen zur inet_type-Datei finden Sie in der Manpage inet_type(4).

Mit der Option -p des Befehls netstat zeigen Sie die net-to-media-Tabelle an, die ARP-Tabelle für IPv4 und den Neighbor-Cache für IPv6. Weitere Informationen finden Sie in der Manpage netstat(1M) Unter So zeigen Sie den Status der Sockets an finden Sie Beschreibungen von Verfahren, die diesen Befehl verwenden.

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

Mit dem Befehl snoop können Sie sowohl IPv4- als auch IPv6-Pakete erfassen. Dieser Befehl kann IPv6-Header, IPv6-Extension-Header, ICMPv6-Header und Neighbor Discovery-Protokolldaten anzeigen. Standardmäßig zeigt der Befehl snoop sowohl IPv4- als auch IPv6-Pakete an. Wenn Sie das Protokollschlüsselwort ip oder ip6 angeben, zeigt der Befehl snoop nur IPv4- bzw. IPv6-Pakete an. Mit der IPv6-Filteroptionen können Sie alle Pakete (sowohl IPv4 als auch IPv6) filtern, um nur IPv6-Pakete anzuzeigen. Weitere Informationen finden Sie in der Manpage snoop(1M) Unter So überwachen Sie den IPv6-Netzwerkverkehr finden Sie Verfahren, die den snoop-Befehl verwenden.

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

Der Befehl route kann sowohl an IPv4- als auch an IPv6-Routen angewendet werden; IPv4-Routen sind dabei die Standardeinstellung. Wenn Sie die Option -inet6 direkt hinter dem Befehl route in die Befehlszeile eingegeben, werden die Vorgänge an IPv6-Routen durchgeführt. Weitere Informationen finden Sie in der Manpage route(1M).

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

Mit dem Befehl ping können sowohl IPv4- als auch IPv6-Protokolle zum Sondieren von Zielhosts verwendet werden. Die Protokollauswahl hängt von den Adressen ab, die vom Namensserver für den angegebenen Zielhost zurückgegeben werden. Standardmäßig verwendet der Befehl ping das IPv6-Protokoll, wenn der Namensserver eine IPv6-Adresse für den Zielhost zurückgibt. Gibt der Server nur eine IPv4-Adresse zurück, verwendet ping das IPv4-Protokoll. Sie können diese Option mit der Befehlszeilenoption -A außer Kraft setzen, indem Sie angeben, welches Protokoll verwendet werden soll.

Ausführliche Informationen finden Sie in der Manpage ping(1M) Verfahren, die den Befehl ping verwenden, finden Sie unter Ermitteln des Status von Remote-Hosts mit dem Befehl ping.

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

Mit dem Befehl traceroute können Sie sowohl IPv4- als auch IPv6-Routen zu einem bestimmten Host verfolgen. Aus Sicht des Protokolls verwendet traceroute den gleichen Algorithmus wie ping. Verwenden Sie die Befehlszeilenoption -A, um diese Auswahl außer Kraft zu setzen. Mit der Befehlszeilenoption -a können Sie jede einzelne Route an jede Adresse eines Multihomed-Host verfolgen.

Ausführliche Informationen finden Sie in der Manpage traceroute(1M) Verfahren, die den Befehl traceroute verwenden, finden Sie unter Anzeigen von Routing-Informationen mit dem Befehl traceroute.

IPv6-bezogene Daemons

In diesem Abschnitt werden IPv4-bezogene Daemons beschrieben.

in.ndpd-Daemon zur Neighbor Discovery

Der in.ndpd-in Daemon implementiert das IPv6-Neighbor Discovery-Protokoll und die Router-Erkennung. Darüber hinaus setzt der Daemon die automatische Adresskonfiguration für IPv6 um. Im Folgenden sind die unterstützten Optionen des in.ndpd-Daemons aufgeführt.

-d

Aktiviert das Debugging.

-D

Aktiviert das Debugging für bestimmte Ereignisse.

-f

Gibt eine Datei an, die anstelle der Standard-Datei /etc/inet/ndpd.conf zum Einlesen von Konfigurationsdaten verwendet wird.

-I

Druckt Informationen zu jeder Schnittstelle.

-n

Führt kein Loopback für Router Advertisement-Nachrichten aus.

-r

Ignoriert empfangene Pakete.

-v

Aktiviert den ausführlichen Modus und zeigt verschiedene Diagnosemeldungen an.

-t

Aktiviert die Paketverfolgung.

Der in.ndpd-Daemon wird neben den Parametern, die in der Konfigurationsdatei /etc/inet/ndpd.conf eingerichtet werden, durch die entsprechenden Parameter in der Startdatei /var/inet/ndpd_state.Schnittstelle gesteuert.

Wenn die Datei /etc/inet/ndpd.conf vorhanden ist, wird sie geparst und zur Konfiguration eines Knotens als Router verwendet. Tabelle 11–2 enthält eine Liste der gültigen Schlüsselwörter, die in dieser Datei enthalten sein können. Wenn ein Host bootet, stehen die Router eventuell nicht sofort zur Verfügung. Vom Router gesendete Pakete werden eventuell abgeworfen. Eventuell erreichen gesendete Pakete den Host nicht.

Die /var/inet/ndpd_state.Schnittstelle-Datei ist eine Statusdatei. Diese Datei wird regelmäßig von jedem Knoten aktualisiert. Wenn ein Knoten ausfällt und neu gestartet wird, kann der Knoten seine Schnittstellen auch bei Abwesenheit von Routern konfigurieren. Diese Datei enthält die Schnittstellenadresse, das Datum der letzten Aktualisierung der Datei und den Gültigkeitszeitraum der Datei. Darüber hinaus enthält diese Datei weitere Parameter, die bei früheren Router Advertisement-Nachrichten „gelernt“ wurden.

Sie müssen die Inhalte von Statusdateien nicht ändern. Statusdateien werden automatisch vom in.ndpd-Daemon gepflegt.

Eine Liste der Konfigurationsvariablen sowie der zulässigen Werte finden Sie in den Manpages in.ndpd(1M)und ndpd.conf(4).

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

Der in.ripngd-Daemon implementiert das Routing Information Protocol der nächsten Generation für IPv6-Router (RIPng). RIPng ist das IPv6-Äquivalent von RIP. Wenn Sie einen IPv6-Router mit dem Befehl routeadm konfigurieren und das IPv6-Routing aktivieren, implementiert der in.ripngd-Daemon RIPng auf dem Router.

Im Folgenden sind die von RIPng unterstützten Optionen aufgeführt.

-p n

n gibt den alternativen Port an, der zum Senden und Empfangen von RIPnG-Paketen verwendet wird.

-q

Unterdrückt Routing-Informationen.

-s

Erzwingt Routing-Informationen auch dann, wenn der Daemon als Router fungiert.

-P

Unterdrückt die Verwendung von Poison Reverse.

-S

Wenn in.ripngd nicht als Router fungiert, gibt der Daemon nur eine Standard-Route für jeden Router ein.

inetd-Daemon und IPv6-Services

Eine IPv6-konforme Serveranwendung kann sowohl IPv4- als auch IPv6-Anforderungen oder nur IPv6-Anforderungen verarbeiten. Der Server verarbeitet Anforderungen immer über einen IPv6-Socket. Darüber hinaus verwendet der Server das gleiche Protokoll wie der entsprechende Client. Um einen Service für IPv6 hinzuzufügen oder zu modifizieren, verwenden Sie die Befehle der Service Management Facility (SMF).

• Weitere Informationen zu den SMF-Befehlen finden Sie im SMF Command-Line Administrative Utilities in System Administration Guide: Basic Administration.

• Eine Beispielaufgabe, die SMF zur Konfiguration eines IPv4-Servicemanifestes verwendet, das über SCTP ausgeführt wird, finden Sie unter So fügen Sie Services hinzu, die das SCTP-Protokoll verwenden.

Bei der Konfiguration eines IPv6-Services müssen Sie sicherstellen, dass der Feldwert proto im Profil inetadm den entsprechenden Wert für diesen Service enthält:

• Bei einem Service, der sowohl IPv4- als auch IPv6-Anforderungen verarbeitet, wählen Sie tcp6, udp6 oder sctp. Ein proto-Wert von tcp6, udp6 oder sctp6 führt dazu, dass inetd einen IPv6-Socket an den Server übergibt. Der Server enthält eine IPv4-zugeordnete Adresse, falls ein IPv4-Client eine Anforderung stellt.

• Bei einem Service, der ausschließlich IPv6-Anforderungen verarbeitet, wählen Sie tcp6only oder udp6only. Wenn einer dieser Werte für proto eingerichtet wurde, übergibt inetd einen IPv6-Socket an den Server.

Wenn Sie einen Oracle Solaris-Befehl durch eine andere Implementierung ersetzen, müssen Sie sicherstellen, dass die Implementierung dieses Service IPv6 unterstützt. Andernfalls müssen Sie tcp, udp oder sctp als proto-Wert angeben

Im Folgenden finden Sie ein Profil, das aus der Ausführung von inetadm für ein echo-Servicemanifest resultiert, das sowohl IPv4 als auch IPv6 unterstützt und über SCTP ausgeführt wird:

# inetadm -l svc:/network/echo:sctp_stream
	SCOPE    NAME=VALUE	  name="echo"
	         endpoint_type="stream"
	         proto="sctp6"
	         isrpc=FALSE
	         wait=FALSE
	         exec="/usr/lib/inet/in.echod -s"
	         user="root"
	default  bind_addr=""
	default  bind_fail_max=-1
	default  bind_fail_interval=-1
	default  max_con_rate=-1
	default  max_copies=-1
	default  con_rate_offline=-1
	default  failrate_cnt=40
	default  failrate_interval=60
	default  inherit_env=TRUE
	default  tcp_trace=FALSE
	default  tcp_wrappers=FALSE

Um den Wert des Feldes proto zu ändern, verwenden Sie die folgende Syntax:

# inetadm -m FMRI proto="transport-protocols"

Alle Server, auf denen die Oracle Solaris-Software installiert ist, benötigen nur einen Profileintrag, der proto als tcp6, udp6 oder sctp6 einrichtet. Der Remote Shell Server (shell) und der Remote Execution Server (exec) bestehen jetzt jedoch aus einer Service-Instanz, die einen proto-Wert benötigt, für den die beiden Werte tcp und tcp6only erforderlich sind. Um beispielsweise den Wert proto für shell einzurichten, geben Sie den folgenden Befehl ein:

# inetadm -m network/shell:default proto="tcp,tcp6only"

Weitere Informationen zum Schreiben von IPv4-konformen Servern, die Sockets verwenden, finden Sie in den IPv6-Erweiterungen zur Socket API im Programming Interfaces Guide .

Überlegungen bei der Konfiguration eines Services für IPv6

Wenn Sie einen Service für IPv6 hinzufügen oder modifizieren, müssen Sie Folgendes berücksichtigen:

• Sie müssen den proto-Wert als tcp6, sctp6 oder udp6 angeben, um sowohl IPv4- als auch IPv6-Verbindungen zu ermöglichen. Wenn Sie den Wert für proto mit tcp, sctp oder udp angeben, verwendet der Service ausschließlich IPv4.

• Obwohl Sie eine Service-Instanz hinzufügen können, die 1:n-SCTP-Sockets für inetd verwendet, wird diese Vorgehensweise nicht empfohlen. inetd arbeitet nicht mit 1:n-SCTP-Sockets.

• Wenn ein Service zwei Einträge erfordert, da seine wait-status- oder exec-Eigenschaften abweichen, müssen Sie zwei Instanzen/Services aus dem ursprünglichen Service erstellen.

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

• Automatische Konfiguration

• Neighbor Solicitation und Unerreichbarkeit

• Algorithmus zur Erkennung doppelt vorhandener Adressen

• Vergleich von Neighbor Discovery mit ARP und verwandten IPv4-Protokollen

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:

• 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.

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 gegebenenfalls 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.

• 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.

IPv6-Routing

Routing unter IPv6 ist nahezu identisch mit dem IPv4-Routing unter Classless Inter-Domain Routing (CIDR). Der einzige Unterschied besteht darin, dass es sich bei den Adressen um 128-Bit-IPv6-Adressen anstelle von 32-Bit-IPv4-Adressen handelt. Bei sehr einfachen Erweiterungen können alle IPv4-Routing-Algorithmen, z. B. OSPF, RIP, IDRP und IS-IS, zum Routen von IPv6 verwendet werden.

Darüber hinaus bietet IPv6 einfache Routing-Erweiterungen, die mächtige neue Routing-Funktionen unterstützen. Die neuen Routing-Funktionen sind in der folgenden Liste aufgeführt:

• Provider-Auswahl basierend auf Richtlinie, Leistung, Kosten usw.

• Host-Mobilität, Route zum aktuellen Standort

• Automatische Neuadressierung, Route zur neuen Adresse

Sie beziehen die neuen Routing-Funktionen, indem Sie Sequenzen von IPv6-Adressen erstellen, die eine IPv6-Routing-Option verwenden. Eine IPv6-Quelle verwendet die Routing-Option, um einen oder mehrere Zwischenknoten oder topologische Gruppen auf dem Pfad zum Datenpaketziel aufzulisten. Diese Funktion ähnelt der IPv4-Option „Loose Source and Record Route“ (LSRR).

Um Adresssequenzen in eine allgemeine Funktion umzuwandeln, müssen IPv6-Hosts in den meisten Fällen die Routen in einem vom Host empfangenen Paket umkehren. Das Paket muss mithilfe des IPv6-Authentifizierung-Header erfolgreich authentifiziert worden sein. Das Paket muss Adresssequenzen enthalten, damit es an den Absender zurückgesendet werden kann. Diese Technik macht es erforderlich, dass IPv6-Host-Implementierungen die Verarbeitung und Umkehrung von Quellrouten unterstützen. Verarbeitung und Umkehrung von Quellrouten ermöglichen es einem Provider, mit Hosts zu arbeiten, die neue IPv6-Funktionen wie Provider-Auswahl und erweiterte Adressen verwenden.

Router Advertisement-Nachrichten

Bei Multicast-fähigen Links und Point-to-Point-Links sendet jeder Router in regelmäßigen Abständen ein Router Advertisement-Paket an die Multicast-Gruppe, in der er seine Verfügbarkeit bekannt gibt. Ein Host empfängt Router Advertisement-Nachrichten von allen Routern und erstellt so eine Liste der Standard-Router. Router erzeugen diese Router Advertisement-Nachrichten so häufig, dass Hosts innerhalb weniger Minuten über das Vorhandensein von Routern informiert sind. Dennoch erfolgen diese Nachrichten nicht häufig genug, um den Ausfall eines Routers am Ausbleiben der Advertisement-Nachrichten zu erkennen. Eine zuverlässige Ausfallerkennung erfolgt über einen separaten Algorithmus, der die Unerreichbarkeit eines Nachbarknotens feststellt.

Router Advertisement-Präfixe

Router Advertisement-Nachrichten enthalten eine Liste der Teilnetzpräfixe, mit der festgestellt wird, ob sich ein Host auf dem gleichen Link (on-Link) wie der Router befindet. Die Präfixliste dient auch zur autonomen Adresskonfiguration. Präfixen zugeordnete Flags kennzeichnen, dass ein bestimmtes Präfix absichtlich verwendet wird. Hosts erstellen und verwalten anhand der bekannt gegebenen on-Link-Präfixe eine Liste mit Angaben, ob sich das Ziel eines Datenpakets on-Link oder hinter einem Router befindet. Ein Ziel kann auch dann on-Link sein, wenn es in keinem bekannt gegebenen on-Link-Präfix enthalten ist. In diesen Fällen kann ein Router eine Redirect-Nachricht senden. Die Redirect-Nachricht informiert den Absender, dass es sich bei dem Ziel um einen Nachbarknoten handelt.

Mit Router Advertisement-Nachrichten und Flags für jedes Präfix können Router Hosts darüber zu informieren, wie eine statusfreie automatische Adresskonfiguration durchgeführt wird.

Router Advertisement-Nachrichten

Router Advertisement-Nachrichten enthalten auch Internet-Parameter, z. B. einen Grenzwert für die Hops, den Hosts in abgehenden Paketen verwenden sollen. Optional enthalten Router Advertisement-Nachrichten auch Link-Parameter, z. B. die Link-MTU. Diese Funktion ermöglicht eine zentralisierte Verwaltung kritischer Parameter. Die Parameter können auf Routern eingerichtet und automatisch an alle angeschlossenen Hosts gesendet werden.

Knoten führen die Adressauflösung durch, indem eine Neighbor Solicitation-Nachricht an die Multicast-Gruppe gesendet wird. Sie fordert einen Zielknoten auf, seine Sicherungsschichtadresse zurückzusenden. Multicast Neighbor Solicitation-Nachrichten werden an die Solicited Node-Multicast-Adresse der Zieladresse gesendet. Das Ziel gibt seine Sicherungsschichtadresse als Unicast Neighbor Advertisement-Nachricht zurück. Ein einzelnes Anforderung/Antwort-Paketpaar reicht für den Initiator und das Ziel aus, die Sicherungsschichtadresse des jeweils anderen aufzulösen. Der Initiator sendet seine Sicherungsschichtadresse in der Neighbor Solicitation-Nachricht.

IPv6-Tunnel

Um die Abhängigkeiten an einem Dual-Stack IPv4/IPv6-Standort zu minimieren, müssen die Router im Pfad zwischen zwei IPv6-Knoten kein IPv6 unterstützen. Der Mechanismus, der eine solche Netzwerkkonfiguration unterstützt, wird als Tunneling bezeichnet. Im Grunde genommen werden IPv6-Pakete in IPv4-Pakete verpackt und dann über die IPv4-Router geleitet. Die folgende Abbildung verdeutlicht den Tunneling-Mechanismus über die IPv4-Router, die in der Abbildung durch „R“ gekennzeichnet sind

Abbildung 11–5 IPv6-Tunneling-Mechanismus

Die Oracle Solaris IPv6-Implementierung verwendet zwei Arten von Tunneling-Mechanismen:

• Zwischen zwei Routern konfigurierte Tunnel (siehe Abbildung 11–5)

• Automatische Tunnel, die an den Endpunkt-Hosts terminiert sind

Ein konfigurierter Tunnel wird derzeit für verschiedene Zwecke im Internet verwendet, z. B. auf dem MBONE, dem IPv4-Multicast-Backbone. Im Prinzip besteht der Tunnel aus zwei Routern, die mit einer virtuellen Point-to-Point-Verbindung zwischen zwei Routern über das IPv4-Netzwerk konfiguriert sind. Diese Art Tunnel wird wahrscheinlich in naher Zukunft in einigen Bereichen des Internet verwendet werden.

Automatische Tunnel erfordern IPv4-kompatible Adressen. Automatische Tunnel können zum Verbinden von IPv6-Knoten verwendet werden, wenn keine IPv6-Router zur Verfügung stehen. Diese Tunnel beginnen entweder an einem Dual-Stack-Host oder einem Dual-Stack-Router, indem eine automatische Tunneling-Netzwerkschnittstelle konfiguriert wird. Die Tunnel enden immer bei dem Dual-Stack-Host. Diese Tunnel stellen die IPv4-Zieladresse (den Endpunkt des Tunnels) dynamisch fest, indem sie die Adresse aus der IPv4-kompatiblen Zieladresse extrahieren.

Konfigurierte Tunnel

Tunneling-Schnittstellen weisen das folgende Format auf:

ip.tun ppa

ppa ist der physikalische Anschlusspunkt.

Beim Systemstart wird das Tunneling-Modul (tun) vom ifconfig-Befehl an den Anfang des IP gebracht, um eine virtuelle Schnittstelle zu erstellen. Dieser Vorgang wird durch das Erstellen der entsprechenden hostname6.*-Datei begleitet.

Angenommen, Sie erstellen einen Tunnel zum Einkapseln von IPv6-Paketen über ein IPv4-Netzwerk (IPv6-über-IPv4), so erstellen Sie eine Datei mit dem folgenden Namen:

/etc/hostname6.ip.tun0

Der Inhalt dieser Datei wird an den Befehl ifconfig übergeben, nachdem die Schnittstellen geplumbt (aktiviert) wurden. Der Inhalt wird zu den Parametern, die zur Konfiguration eines Point-to-Point-Tunnels erforderlich sind.

Beispiel 11–11 hostname6.ip.tun0-Datei für einen IPv6-über-IPv4-Tunnel

Im Folgenden finden Sie ein Beispiel für die Einträge in der hostname6.ip.tun0-Datei:

tsrc 10.10.10.23 tdst 172.16.7.19 up
addif 2001:db8:3b4c:1:5678:5678::2 up

In diesem Beispiel werden die IPv4-Quell- und Zieladressen als Token verwendet, um Link-lokale IPv6-Adressen automatisch zu konfigurieren. Diese Adressen sind Quelle und Ziel der Schnittstelle ip.tun0. Es sind zwei Schnittstellen konfiguriert. Die Schnittstelle ip.tun0 sind konfiguriert. Eine logische Schnittstelle, ip.tun0:1, wurde ebenfalls konfiguriert. Die logische Schnittstelle besitzt die Quelle- und IPv6-Zieladressen, die durch den Befehl addif angegeben werden.

Wird das System im Multiuser-Modus gestartet, kann der Inhalt dieser Konfigurationsdateien ohne Änderungen an den Befehlifconfig übergeben werden. Die Einträge in Beispiel 11–11 entsprechen Folgendem:

# ifconfig ip.tun0 inet6 plumb
# ifconfig ip.tun0 inet6 tsrc 10.0.0.23 tdst 172.16.7.19 up
# ifconfig ip.tun0 inet6 addif 2001:db8:3b4c:1:5678:5678::2 up

Das Folgende zeigt die Ausgabe des Befehls ifconfig -a für diesen Tunnel.

ip.tun0: flags=2200850<UP,POINTOPOINT,RUNNING,MULTICAST,
  NONUD,IPv6> mtu 1480 index 6
        inet tunnel src 10.0.0.23  tunnel dst 172.16.7.19
        inet6 fe80::c0a8:6417/10 --> fe80::c0a8:713
ip.tun0:1: flags=2200850<UP,POINTOPOINT,RUNNING,MULTICAST,NONUD,IPv6> mtu 1480 
  index 5
        inet6 2001:db8:3b4c:1:5678:5678::2 

Sie können weitere logische Schnittstellen konfigurieren, in dem Sie der Konfigurationsdatei unter Beachtung der folgenden Syntax weitere Zeilen hinzufügen:

addif IPv6-source IPv6-destination up

Wenn es sich bei einem der Tunnelenden um einen IPv6-Router handelt, der mindestens ein Präfix über den Tunnel bekannt gibt, sind keine addif-Befehle in den Tunnelkonfigurationsdateien erforderlich. Nur tsrc und tdst sind eventuell erforderlich, da alle anderen Adressen automatisch konfiguriert wurden.

In einigen Fällen müssen bestimmte Quellen- und Zieladressen auf dem lokalen Link für einen bestimmten Tunnel manuell konfiguriert werden. Ändern Sie die erste Zeile der Konfigurationsdatei, um diese Link-lokalen Adressen aufzunehmen. Die folgende Zeile ist ein Beispiel:

tsrc 10.0.0.23 tdst 172.16.7.19 fe80::1/10 fe80::2 up

Bitte beachten Sie, das die Link-lokale Quellenadresse die·Präfixlänge 10 besitzt. In diesem Beispiel ähnelt die Schnittstelle ip.tun0 Folgendem:

ip.tun0: flags=2200850<UP,POINTOPOINT,RUNNING,MULTICAST,NONUD,IPv6> mtu 1480 
index 6
        inet tunnel src 10.0.0.23  tunnel dst 172.16.7.19
        inet6 fe80::1/10 --> fe80::2

Um einen Tunnel zum Einkapseln von IPv6-Paketen über ein IPv6-Netzwerk (IPv6-über-IPv6) zu erstellen, legen Sie die folgende Datei an:

/etc/hostname6.ip6.tun0

Beispiel 11–12 hostname6.ip6.tun0-Datei für einen IPv6-über-IPv6-Tunnel

Das Folgende ist ein Beispiel für die Einträge in der hostname6.ip6.tun0-Datei zur IPv6-Einkapselung über ein IPv6-Netzwerk:

tsrc 2001:db8:3b4c:114:a00:20ff:fe72:668c 
        tdst 2001:db8:15fa:25:a00:20ff:fe9b:a1c3
fe80::4 fe80::61 up

Um einen Tunnel zum Einkapseln von IPv4-Paketen über ein IPv6-Netzwerk (IPv4-über-IPv6) zu erstellen, legen Sie die folgende Datei an:

/etc/hostname.ip6.tun0

Beispiel 11–13 hostname.ip6.tun0-Datei für einen IPv4-über-IPv6-Tunnel

Das Folgende ist ein Beispiel für die Einträge in der hostname.ip6.tun0-Datei zur IPv4-Einkapselung über ein IPv6-Netzwerk:

tsrc 2001:db8:3b4c:114:a00:20ff:fe72:668c 
         tdst 2001:db8:15fa:25:a00:20ff:fe9b:a1c3
10.0.0.4 10.0.0.61 up

Um einen Tunnel zum Einkapseln von IPv4-Paketen über ein IPv4-Netzwerk (IPv4-über-IPv4) zu erstellen, legen Sie die folgende Datei an:

/etc/hostname.ip.tun0

Beispiel 11–14 hostname.ip.tun0-Datei für einen IPv4-über-IPv4-Tunnel

Das Folgende ist ein Beispiel für die Einträge in der hostname.ip.tun0-Datei zur IPv4-Einkapselung über ein IPv4-Netzwerk:

tsrc 172.16.86.158 tdst 192.168.86.122
10.0.0.4 10.0.0.61 up

Weitere Informationen zu tun finden Sie in der Manpage tun(7M). Eine allgemeine Beschreibung der Tunneling-Konzepte während des Übergangs zu IPv6 finden Sie unter Einführung in IPv6-Tunnel. Eine Beschreibung der Verfahren zur Konfiguration von Tunneln finden Sie unter Aufgaben bei der Konfiguration von Tunneln zur Unterstützung von IPv6 (Übersicht der Schritte).

Automatische 6to4-Tunnel

Oracle Solaris bietet 6to4-Tunnel als bevorzugte Zwischenlösung für den Übergang von der IPv4- zur IPv6-Adressierung. Mit 6to4-Tunneln können isolierte IPv6-Standorte durch einen automatischen Tunnel über ein IPv4-Netzwerk, das IPv6 nicht unterstützt, miteinander kommunizieren. Zum Verwenden von 6to4-Tunneln müssen Sie einen Grenzrouter in Ihrem IPv6-Netzwerk als einen Endpunkt eines automatischen 6to4-Tunnels konfigurieren. Dann kann der 6to4-Router an einem Tunnel zu einem anderen IPv6-Standort, oder, falls erforderlich, mit einem nativen IPv6-, nicht-6to4-Standort teilnehmen.

In diesem Abschnitt finden Sie Referenzen zu den folgenden 6to4-bezogenen Themen:

• Topologie eines 6to4-Tunnels

• 6to4-Adressierung, einschließlich Format der Advertisement-Nachricht

• Beschreibung des Paketflusses durch einen 6to4-Tunnel

• Topologie eines Tunnels zwischen einem 6to4-Router und einem 6to4-Relay-Router

• Vor der Konfiguration einer 6to4-Relay-Router-Unterstützung zu berücksichtigende Aspekte

In der folgenden Tabelle sind zusätzliche Aufgaben zum Konfigurieren von 6to4-Tunneln aufgeführt, sowie Ressourcen zur Beschaffung weiterer hilfreicher Informationen.

Topologie eines 6to4-Tunnels

Ein 6to4-Tunnel bietet IPv6-Konnektivität zu allen 6to4-Standorten weltweit. Entsprechend funktioniert der Tunnel auch als eine Verbindung zu allen IPv6-Standorten (einschließlich dem nativen IPv6-Internet), vorausgesetzt, der Tunnel ist zum Weiterleiten an einen Relay-Router konfiguriert. Die folgende Abbildung zeigt, wie ein 6to4-Tunnel diese Konnektivität zwischen zwei 6to4-Standorten bereitstellt.

Abbildung 11–6 Tunnel zwischen zwei 6to4-Standorten

Die Abbildung zeigt zwei voneinander isolierte 6to4-Netzwerke, Standort A und Standort B. Jeder Standort ist mit einem Router konfiguriert, der über eine externe Verbindung zu einem IPv4-Netzwerk verfügt. Ein 6to4-Tunnel durch das IPv4-Netzwerk stellt eine Verbindung zu 6to4-Standorten bereit.

Bevor ein IPv6-Standort zu einem 6to4-Standort werden kann, muss mindestens eine Router-Schnittstelle zur Unterstützung von 6to4 konfiguriert werden. Diese Schnittstelle muss die externe Verbindung mit dem IPv4-Netzwerk bieten. Die Adresse, die Sie auf qfe0 konfigurieren, muss global einmalig sein. In dieser Abbildung stellt die Schnittstelle qfe0 des Grenzrouters A die Verbindung von Standort A mit dem IPv4-Netzwerk her. Die Schnittstelle qfe0 muss bereits mit einer IPv4-Adresse konfiguriert worden sein, bevor Sie qfe0 als eine 6to4-Pseudoschnittstelle konfigurieren.

In der Abbildung besteht der 6to4-Standort A aus zwei Teilnetzen, die über die Schnittstellen hme0 und hme1 auf Router A verbunden sind. Alle IPv6-Hosts in einem der Teilnetze von Standort A werden nach dem Empfang der Advertisement-Nachricht von Router A automatisch mit 6to4-abgeleiteten Adressen neu konfiguriert.

Standort B ist ein weiterer isolierter 6to4-Standort. Um Datenverkehr korrekt von Standort A zu empfangen, muss ein Grenzrouter an Standort B zur 6to4-Unterstützung konfiguriert sein. Andernfalls werden die Pakete, die der Router von Standort A empfängt, nicht erkannt und abgeworfen.

Paketfluss durch den 6to4-Tunnel

In diesem Abschnitt wird der Paketfluss von einem Host an einem 6to4-Standort zu einem Host an einem remoten 6to4-Standort beschrieben. Das Szenario verwendet die in Abbildung 11–6 gezeigte Topologie. Darüber hinaus wird bei diesem Szenario davon ausgegangen, dass die 6to4-Router und die -Hosts bereits konfiguriert sind.

1. Ein Host im Teilnetz 1 des 6to4-Standorts A sendet eine Übertragung mit einem Host am 6to4-Standort B als Ziel. Jeder Paket-Header enthält eine 6to4-abgeleitete Quelladresse und eine 6to4-abgeleitete Zieladresse.

2. Der Router an Standort A kapselt jedes 6to4-Datenpaket in einen IPv4-Header ein. In diesem Prozess stellt der Router die IPv4-Zieladresse des eingekapselten Headers auf die Routeradresse von Standort B ein. Bei jedem IPv6-Paket, das durch die Tunnelschnittstelle fließt, enthält die IPv6-Zieladresse des Pakets auch die IPv4-Zieladresse. Daher kann der Router die IPv4-Zieladresse feststellen, die im einkapselnden Header eingestellt ist. Dann verwendet der Router standardmäßige IPv4-Routing-Verfahren, um das Paket über das IPv4-Netzwerk weiterzuleiten.

3. Alle IPv4-Router, die die Pakete durchlaufen, verwenden die IPv4-Zieladresse des Pakets zur Weiterleitung. Diese Adresse ist die global einmalige IPv4-Adresse der Schnittstelle auf Router B, die auch als 6to4-Pseudoschnittstelle dient.

4. Pakete von Standort A treffen bei Router B ein, der die IPv6-Pakete aus den IPv4-Headern entkapselt.

5. Router B verwendet dann die Zieladresse im IPv6-Paket, um die Pakete an den Empfangshost an Standort B weiterzuleiten.

Sicherheitsbetrachtungen bei Tunneln zu einem 6to4-Relay-Router

6to4-Relay-Router fungieren als Tunnelendpunkte von 6to4-Routern, die mit nativen IPv6-, nicht-6to4-Netzwerken kommunizieren müssen. Relay-Router sind im Wesentlichen Brücken zwischen einem 6to4-Standort und nativen IPv6-Standorten. Da diese Lösung extrem unsicher ist, aktiviert Oracle Solaris standardmäßig keine Unterstützung für 6to4-Relay-Router. Falls für Ihren Standort ein solcher Tunnel erforderlich ist, können Sie den Befehl 6to4relay verwenden, um das folgende Tunneling-Szenario zu verwirklichen.

Abbildung 11–7 Tunnel von einem 6to4-Standort zu einem 6to4-Relay-Router

In Abbildung 11–7 muss der 6to4-Standort A mit einem Knoten am nativen IPv6-Standort B kommunizieren. Die Abbildung zeigt den Pfad des Datenverkehrs von Standort A über einen 6to4-Tunnel durch ein IPv4-Netzwerk. Der Tunnel hat den 6to4-Router A und einen 6to4-Relay-Router als Endpunkte. Hinter dem 6to4-Relay-Router befindet sich das IPv6-Netzwerk, mit dem IPv6-Standort B verbunden ist.

Paketfluss zwischen einem 6to4-Standort und einem nativen IPv6-Standort

In diesem Abschnitt wird der Paketfluss von einem 6to4-Standort zu einem nativen IPv6-Standort beschrieben. Das Szenario verwendet die in Abbildung 11–7 gezeigte Topologie.

1. Der Host am 6to4-Standort A sendet eine Übertragung, die einen Host am nativen IPv6-Standort B als Ziel angibt. Jeder Paket-Header weist eine 6to4-abgeleitete Adresse als Quelladresse auf. Die Zieladresse ist eine standardmäßige IPv6-Adresse.

2. Der 6to4-Router an Standort A kapselt jedes Paket in einen IPv4-Header ein, der die IPv4-Adresse des 6to4-Relay-Routers als Ziel angibt. Der 6to4-Router verwendet standardmäßige IPv4-Routing-Verfahren, um das Paket über das IPv4-Netzwerk weiterzuleiten. Alle IPv4-Router, die die Pakete durchlaufen, leiten die Pakete an den 6to4-Relay-Router weiter.

3. Der nächste Anycast 6to4-Relay-Router zu Standort A empfängt die Pakete für die Anycast-Gruppe 192.88.99.1.

   ---

   Hinweis –

   6to4-Relay-Router sind Teil der 6to4-Relay-Router Anycast-Gruppe mit der IP-Adresse 192.88.99.1 . Diese Anycast-Adresse ist die Standardadresse für 6to4-Relay-Router. Wenn Sie einen bestimmten 6to4-Relay-Router verwenden müssen, können Sie die Standardeinstellung überschreiben und die IPv4-Adresse des Routers angeben.

   ---

4. Der Relay-Router entkapselt den IPv4-Header von den 6to4-Paketen und legt dabei die native IPv6-Zieladresse frei.

5. Dann sendet der Relay-Router die IPv6-Pakete (jetzt nur IPv6) an das IPv6 Netzwerk weiter, in dem die Pakete letztlich von einem Router an Standort B empfangen werden. Der Router leitet die Pakete dann an den IPv6-Zielknoten weiter.

IPv6-Erweiterungen zu den Oracle Solaris-Namen-Services

In diesem Abschnitt werden die Änderungen bei Benennungen beschrieben, die durch die Umsetzung von IPv6 eingeführt wurden. Sie können IPv6-Adressen in einem beliebigen Oracle Solaris-Namen-Service speichern: NIS, LDAP, DNS und Dateien. Alternativ können Sie NIS over IPv6 RPC-Transporte verwenden, um NIS-Daten abzurufen.

DNS-Erweiterungen für IPv6

Ein IPv6-spezifischer Ressourcendatensatz, der Ressourcendatensatz AAAA, wurde in der RFC 1886 DNS Extensions to Support IP Version 6 festgelegt. Dieser AAAA-Datensatz wandelt einen Hostnamen in eine 128-Bit-IPv6-Adresse um. Der PTR-Datensatz wird noch immer für IPv6 verwendet, um IP-Adressen in Hostnamen umzuwandeln. Die 32 vier-Bit-Nibbel der 128-Bit-Adresse werden für eine IPv6-Adresse umgekehrt. Jedes Nibble wird in den entsprechenden hexadezimalen ASCII-Wert umgewandelt. Dann wird ip6.int angehängt.

Änderungen an der nsswitch.conf-Datei

Für Solaris 10 11/06 und früheren Releases wurde neben der Fähigkeit zum Nachschlagen von IPv6-Adressen über die Datei /etc/inet/ipnodes eine IPv6-Unterstützung für die Namen-Services NIS, LDAP und DNS hinzugefügt. Entsprechend wurde die nsswitch.conf-Datei modifiziert, um IPv6-Abfragen zu unterstützen.

hosts:  files dns nisplus [NOTFOUND=return]
ipnodes: files dns nisplus [NOTFOUND=return]

Bevor Änderungen an der /etc/nsswitch.conf-Datei vorgenommen werden, um ipnodes in mehreren Namen-Services zu durchsuchen, füllen Sie diese ipnodes-Datenbanken mit IPv4- und IPv6-Adressen auf. Andernfalls stellen sich unnötige Verzögerungen bei der Auflösung von Hostadressen ein, eventuell sogar Verzögerungen beim Booten.

Das folgende Diagramm zeigt die neue Beziehung zwischen der nsswitch.conf-Datei und den neuen Namen-Service-Datenbanken für Anwendungen, die die Befehle gethostbyname und getipnodebyname verwenden. Kursiv geschriebene Begriffe sind neu. Der Befehl gethostbyname prüfte nur, ob IPv4-Adressen in der /etc/inet/hosts-Datei gespeichert sind. Unter Solaris 10 11/06 und früheren Releases fragte der Befehl getipnodebyname die Datenbank ab, die im Eintrag ipnodes in der Datei nsswitch.conf angegeben war. Erbrachte diese Suche kein Ergebnis, prüfte der Befehl die Datenbank, die im Eintrag hosts in der Dateinsswitch.conf angegeben war.

Abbildung 11–8 Beziehung zwischen der Datei nsswitch.conf und Namen-Services

Weitere Informationen zu Namen-Services finden Sie im System Administration Guide: Naming and Directory Services (DNS, NIS, and LDAP) .

Änderungen an den Namen-Service-Befehlen

Zur Unterstützung von IPv6 können Sie IPv6-Adressen mit vorhandenen Namen-Service-Befehlen nachschlagen. Beispielsweise arbeitet der Befehl ypmatch mit den neuen NIS-Maps. Der Befehl nslookup kann die neuen AAAA-Datensätze im DNS nachschlagen.

NFS und RPC IPv6-Unterstützung

NFS-Software und die Remote Procedure Call (RPC)-Software unterstützen IPv6 nahtlos. Vorhandene Befehle für die NFS-Services wurden nicht geändert. Die meisten RPC-Anwendungen führen IPv6 ebenfalls ohne Änderungen aus. Für einige neuere RPC-Anwendungen mit Transportkenntnissen sind eventuell Aktualisierungen erforderlich.

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

Oracle Solaris unterstützt IPv6-über-ATM, Permanent Virtual Circuits (PVC) sowie statische Switched Virtual Circuits (SVC).