In diesem Abschnitt werden die Fehler und Probleme beschrieben, die bei der Planung und Bereitstellung von IPv6 an Ihrem Standort auftreten könnten. Eine Liste der Planungsaufgaben finden Sie in Kapitel 4Planen eines IPv6-Netzwerks (Aufgaben).
Falls Ihre bestehende Ausrüstung nicht aufgerüstet werden kann, müssen Sie eventuell eine IPv6-konforme Ausrüstung erwerben. Suchen Sie in der Dokumentation des Herstellers nach Verfahren, die Sie zur Unterstützung von IPv6 ausführen müssen.
Bestimmte IPv4-Router können nicht zur Unterstützung von IPv6 aufgerüstet werden. Falls dies auf Ihre Topologie zutrifft, verbinden Sie einen IPv6-Router mit einem IPv4-Router. Dann können Sie einen Tunnel vom IPv6-Router über den IPv4-Router konfigurieren. Informationen zu den Aufgaben beim Konfigurieren von Tunneln finden Sie unter Aufgaben bei der Konfiguration von Tunneln zur Unterstützung von IPv6 (Übersicht der Schritte).
Bei der Vorbereitung von Services zur Unterstützung von IPv6 tritt eventuell Folgendes auf:
Einige Anwendungen aktivieren standardmäßig keine IPv6-Unterstützung, auch dann nicht, nachdem sie zu IPv6 portiert wurden. Eventuell müssen Sie diese Anwendungen konfigurieren, um IPv6 zu aktivieren.
Auf einem Server, der mehrere Services ausführt, von denen einige ausschließlich IPv4-konform sind, andere sowohl IPv4 als auch IPv6 unterstützen, könnten Probleme auftreten. Einige Clients müssen beide Servicetypen unterstützen, was zu Fehlern auf dem Server führen kann.
Wenn Sie IPv6 bereitstellen möchten, Ihr aktueller ISP jedoch keine IPv6-Adressierung anbietet, sind neben dem ISP-Wechsel folgende Alternativen möglich:
Beauftragen Sie einen ISP, eine zweite Leitung für IPv6-Kommunikationen von Ihrem Standort bereitzustellen. Diese Lösung ist kostenintensiv.
Konfigurieren Sie einen virtuellen ISP. Ein virtueller ISP bietet Ihrem Standort IPv6-Konnektivität ohne einen Link. Stattdessen erstellen Sie einen Tunnel von Ihrem Standort über Ihren IPv4-ISP zum virtuellen ISP.
Verwenden Sie einen 6to4-Tunnel über Ihren ISP zu anderen IPv6-Standorten. Bei der Adresse verwenden Sie die registrierte IPv4-Adresse des 6to4-Routers als öffentliche Topologiekomponente der IPv6-Adresse.
Grundsätzlich ist ein Tunnel zwischen einem 6to4-Router und einem 6to4-Relay-Router unsicher. Sicherheitsprobleme wie die Folgenden tauchen bei Tunneln immer auf:
Obwohl 6to4-Relay-Router Pakete einkapseln und entkapseln, prüfen dem Router keine der in den Paketen enthaltenen Daten.
Adressen-Spoofing ist ein wesentliches Problem bei Tunneln zu einem 6to4-Relay-Router. Bei eingehenden Verkehr ist der 6to4-Router nicht in der Lage, die IPv4-Adresse des Relay-Routers mit der IPv6-Adresse der Quelle in Einklang zu bringen. Aus diesem Grund kann für die Adresse des IPv6-Hosts leicht ein Spoofing durchgeführt werden. Auch die Adresse des 6to4-Relay-Routers bietet ein Spoofing-Ziel.
Standardmäßig existieren keine Vertrauensmechanismen zwischen 6to4-Routern und 6to4-Relay-Routern. Aus diesem Grund kann ein 6to4-Router nicht feststellen, ob der 6to4-Relay-Router vertrauenswürdig ist und ob es sich überhaupt um einen legitimen 6to4-Relay-Router handelt. Es muss eine vertrauenswürdige Beziehung zwischen 6to4-Standort und IPv6-Ziel bestehen, oder beide Standorte sind möglichen Angriffen offen ausgesetzt.
Diese und andere Sicherheitsprobleme im Zusammenhang mit 6to4-Relay-Routern sind im Internet Draft, Security Considerations for 6to4 beschrieben. Allgemein sollten Sie die Unterstützung für 6to4-Relay-Router nur aus den folgenden Gründen aktivieren:
Jeder 6to4-Standort muss mit einem privaten, vertrauenswürdigen IPv6-Netzwerk kommunizieren. Beispielsweise können Sie die Unterstützung eines 6to4-Relay-Routers in einem Universitätsnetzwerk aktivieren, das aus isolierten 6to4-Standorten und nativen IPv6-Standorten besteht.
Ihr 6to4-Standort muss aus zwingenden geschäftlichen Gründen mit bestimmten nativen IPv6-Hosts kommunizieren.
Sie haben die Prüfungs- und Vertrauensmodelle implementiert, die in der Internet Draft Security Considerations for 6to4 vorgeschlagen werden.
Die folgenden bekannten Programmfehler wirken sich auf die 6to4-Konfiguration aus:
4709338 – RIPng-Implementierung erforderlich, die statische Routen erkennt
4152864 – Konfiguration zweier Tunnel mit dem gleichen tsrc/tdst-Paar ist möglich
Das folgende Problem tritt bei 6to4-Standorten mit Routern auf, die sich innerhalb des 6to4-Grenzrouters befinden. Wenn Sie die 6to4-Pseudoschnittstelle konfigurieren, wird die statische Route 2002::/16 automatisch zur Routing-Tabelle auf dem 6to4-Router hinzugefügt. Bug 4709338 beschreibt eine Einschränkung des Oracle Solaris RIPng-Routing-Protokolls, das verhindert, dass diese statische Route am 6to4-Standort bekannt gegeben wird.
Eine der folgenden Problemumgehungen ist für Bug 4709338 möglich.
Fügen Sie die statische Route 2002::/16 den Routing-Tabellen aller Intrasite-Router am 6to4-Standort hinzu.
Verwenden Sie ein anderes Protokoll als RIPng auf dem internen Router des 6to4-Standorts.
Bug-ID 4152864 beschreibt Probleme, die auftreten, wenn zwei Tunnel mit der gleichen Tunnel-Quelladresse konfiguriert wurden. Dies ist ein schwerwiegendes Problem bei 6to4-Tunneln.
Konfigurieren Sie einen 6to4-Tunnel und einen automatischen Tunnel (atun) nicht mit der gleichen Tunnel-Quelladresse. Informationen zu automatischen Tunneln und dem Befehl atun finden Sie in der Manpage tun(7M).