TCP/IP-Grundlagen für Microsoft Windows
Kapitel 15 – IPv6-Übergangstechnologien
Zusammenfassung In diesem Kapitel werden die Mechanismen, die den Übergang von Internet Protocol, Version 4, (IPv4) zu Internet Protocol, Version 6 (IPv6) unterstützen, sowie die IPv6-Übergangstechnologien beschrieben, die in Microsoft® Windows Server™ 2003 und Windows® XP enthalten sind. Da nicht zu erwarten ist, dass reine IPv4-Umgebungen in nächster Zukunft durch reine IPv6-Umgebungen ersetzt werden, müssen Netzwerkadministratoren die Übergangstechnologien verstehen, die die gleichzeitige Verwendung von IPv6 und IPv4 in einer gemischten Umgebung ermöglichen. Auf dieser Seite
ZielsetzungNach dem Lesen dieses Kapitels werden Sie zu Folgendem in der Lage sein:
EinführungProtokollübergänge erfolgen in der Regel durch Installation und Konfiguration des neuen Protokolls auf allen Knoten im Netzwerk, und indem überprüft wird, ob alle Knoten- und Routervorgänge einwandfrei ausgeführt werden. Während diese Umstellung in kleinen oder mittleren Organisationen eventuell möglich ist, stellt ein rascher Protokollübergang in großen Organisationen eine große Herausforderung dar. Angesichts des Umfangs des Internets ist ein schneller Protokollübergang zudem ein Ding der Unmöglichkeit. Die Entwickler von IPv6 erkannten, dass der Übergang von IPv4 zu IPv6 Jahre dauern würde und dass es Organisationen oder Hosts innerhalb von Organisationen gibt, die IPv4 auf unbestimmte Zeit weiterverwenden werden. Die Migration ist daher zwar ein langfristiges Ziel, jedoch ist der vorläufigen Koexistenz von IPv4- und IPv6-Knoten gleiche Beachtung zu schenken. RFC 2893 definiert die folgenden Knotentypen:
Damit die Koexistenz möglich ist, können alle Knoten (IPv4- oder IPv6-Knoten) über eine IPv4-Infrastruktur, eine IPv6-Infrastruktur oder über eine kombinierte IPv4- und IPv6-Infrastruktur kommunizieren. Die echte Migration ist erreicht, wenn alle IPv4-Knoten in reine IPv6-Knoten konvertiert wurden. In absehbarer Zeit ist jedoch die Migration praktisch vollzogen, wenn so viele reine IPv4-Knoten wie möglich in reine IPv6-Knoten konvertiert sind. Reine IPv4-Knoten können mit reinen IPv6-Knoten über einen IPv4-zu-IPv6-Proxy oder ein Übersetzungsgateway kommunizieren. IPv6-ÜbergangsmechanismenFür die Koexistenz mit einer IPv4-Infrastruktur und für einen späteren Übergang zu einer reinen IPv6-Infrastruktur werden die folgenden Mechanismen verwendet:
Architekturen mit doppeltem Stack oder doppelter IP-SchichtIPv6/IPv4-Hosts können auf einer Architektur mit doppeltem Stack oder doppelter IP-Schicht beruhen. In beiden Architekturen sind die folgenden Arten von Verkehr möglich:
Die Architektur mit doppeltem Stack ist in Abbildung 15-1 dargestellt.  Abbildung 15-1: Die Architektur mit doppeltem Stack Das IPv6-Protokoll für Windows Server 2003 und Windows XP verwendet die Architektur mit doppeltem Stack. Der IPv6-Treiber von Windows Server 2003 und Windows XP, Tcpip6.sys, enthält eine separate Implementierung von TCP und UDP. Eine doppelte IP-Schicht enthält eine einzelne Implementierung von Protokollen der Transportschicht wie TCP und UDP. Abbildung 2 zeigt eine Architektur mit doppelter IP-Schicht.  Abbildung 15-2: Die Architektur mit doppelter IP-Schicht Die Architektur mit doppeltem Stapel und die Architektur mit doppelter IP-Schicht bieten beide die gleichen Funktionen für den Übergang zu IPv6. DNS-InfrastrukturFür eine erfolgreiche Koexistenz wird eine DNS-Infrastruktur benötigt, da für den Verweis auf Netzwerkressourcen vorwiegend Namen anstelle von Adressen verwendet werden. Zur Aktualisierung der DNS-Infrastruktur werden die DNS-Server mit Datensätzen gefüllt, damit die IPv6-Auflösung von Namen in Adressen und die Auflösung von Adressen in Namen unterstützt wird. Bei der Auflösung von Namen in Adressen muss die DNS-Infrastruktur AAAA-Einträge für IPv6-Knoten speichern können, die entweder manuell oder dynamisch gefüllt werden. Bei der Auflösung von Adressen in Namen (umgekehrte Abfragen) muss die DNS-Infrastruktur AAAA-Einträge für IPv6-Knoten speichern können, die entweder manuell oder dynamisch gefüllt werden. Regeln für die AdressenauswahlNachdem der abfragende Knoten die dem Namen entsprechenden Adressen erhalten hat, muss er bei der Auflösung von Namen in Adressen die Adressen festlegen, die als Quelle und Ziel für ausgehende Pakete verwendet werden sollen. In den heutigen überwiegend reinen IPv4-Umgebungen stellt dies kein Problem dar. In einer Umgebung, in der IPv4 und IPv6 nebeneinander existieren, werden bei einer DNS-Abfrage jedoch möglicherweise sowohl IPv4- als auch IPv6-Adressen zurückgegeben. Der typische abfragende IPv6/IPv4-Host ist mit mindestens einer IPv4-Adresse und mehreren IPv6-Adressen konfiguriert. Die Festlegung des Adresstyps (IPv4 oder IPv6) und bei IPv6-Adressen die Festlegung einer Quelle und einer in Bezug auf Bereich und Zweck entsprechenden Zieladresse ist keine einfache Aufgabe. Weitere Informationen finden Sie unter Auswahl von Quell- und Zieladressen bei IPv6. Standardregeln für die Auswahl von Adressen sind in RFC 3484 definiert. Die Standardregeln für die Auswahl von Adressen für IPv6 unter Windows Server 2003 und Windows XP sind in der Tabelle mit den Präfixrichtlinien gespeichert, die Sie mit dem Befehl netsh interface ipv6 show prefixpolicy anzeigen können. Die Einträge in der Tabelle mit den Präfixrichtlinien können mit den Befehlen netsh interface ipv6 add|set|delete prefixpolicy geändert werden. IPv6-Adressen in Antworten auf DNS-Abfragen werden gegenüber IPv4-Adressen standardmäßig bevorzugt. IPv6-über-IPv4-TunnelingIPv6-über-IPv4-Tunneling ist die Kapselung von IPv6-Paketen mit einem IPv4-Header, so dass IPv6-Pakete über eine IPv4-Infrastruktur gesendet werden können. Innerhalb des IPv4-Headers:
Abbildung 15-3 zeigt das IPv6-über-IPv4-Tunneling
TunnelingkonfigurationenIn RFC 2893 sind die folgenden Tunnelingkonfigurationen definiert, mit denen der IPv6-Verkehr zwischen IPv6/IPv4-Knoten über eine IPv4-Infrastruktur getunnelt wird:
Auf jedem IPv6/IPv4-Knoten wird eine Schnittstelle erstellt, die den IPv6-über-IPv4-Tunnel darstellt. IPv6-Routen, die die Tunnelschnittstelle verwenden, werden hinzugefügt. Je nach der sendenden Tunnelschnittstelle, der Route und der Zieladresse tunnelt der sendende Knoten den IPv6-Verkehr zum nächsten Hop oder zum Ziel. Die IPv4-Adresse des Tunnelendpunkts kann manuell konfiguriert oder anhand der Adresse des nächsten Hops für das Ziel und die Tunnelschnittstelle automatisch festgelegt werden. TunneltypenIn RFC 2893 werden die folgenden Tunneltypen definiert:
Das IPv6-Protokoll für Windows Server 2003 und Windows XP unterstützt die folgenden automatischen Tunnelingverfahren:
Das IPv6-Protokoll für Windows Server 2003 und Windows XP unterstützt außerdem das automatische Tunneling über IPv6-kompatible Adressen und IPv6-über-IPv4. Weitere Informationen finden Sie unter IPv6-Übergangstechnologien (in englischer Sprache). ISATAPISATAP ist ein Adresszuordnungs- und ein automatisches Host-zu-Host-, Host-zu-Router- und Router-zu-Host-Tunnelingverfahren, mit dem IPv6-Unicastverbindungen zwischen IPv6-Hosts über ein IPv4-Intranet bereitgestellt werden. ISATAP wird in RFC 4214 beschrieben. ISATAP-Hosts müssen nicht manuell konfiguriert werden und erstellen ISATAP-Adressen mithilfe standardmäßiger Mechanismen für die automatische Adresskonfiguration. ISATAP kann für die Kommunikation zwischen IPv6/IPv4-Knoten in einem IPv4-Intranet verwendet werden. ISATAP-Adressen verwenden die lokal verwaltete Schnittstellenkennung ::0:5EFE:w.x.y.z. Bei w.x.y.z handelt sich um eine öffentliche oder private IPv4-Unicastadresse. Ein Beispiel für eine Link-Local-ISATAP-Adresse ist FE80::5EFE:131.107.4.92. Die ISATAP-Schnittstellenkennung kann mit jedem 64-Bit-Subnetzpräfix kombiniert werden, das für IPv6-Unicastadressen gültig ist, einschließlich globaler, Site-Local- und lokaler Präfixe. Für jede IPv4-Adresse, die dem Knoten zugeordnet ist, konfiguriert IPv6 für Windows Server 2003 und Windows XP in der Standardeinstellung die Link-Local-ISATAP-Adresse FE80::5EFE:w.x.y.z automatisch auf der Pseudoschnittstelle für automatisches Tunneling (der ISATAP-Schnittstelle mit dem Schnittstellenindex 2). Diese Link-Local-ISATAP-Adresse ermöglicht zwei Hosts die Kommunikation über ein IPv4-Netzwerk, indem jeder Host die Link-Local-ISATAP-Adresse des anderen Hosts verwendet. Angenommen, Host A ist mit der IPv4-Adresse 10.40.1.29 konfiguriert und Host B mit der IPv4-Adresse 192.168.41.30. Wenn IPv6 für Windows XP und Windows Server 2003 gestartet wird, konfiguriert Host A automatisch die ISATAP-Adresse FE80::5EFE:10.40.1.29 und Host B automatisch die ISATAP-Adresse FE80::5EFE:192.168.41.30. Diese Beispielkonfiguration ist in Abbildung 15-4 dargestellt. Wenn Host A über die Link-Local-ISATAP-Adresse von Host B IPv6-Verkehr an Host B sendet, entsprechen die Quell- und die Zieladresse für den IPv6- und IPv4-Header den Angaben in Tabelle 15-1.
Zum Testen der Verbindung kann ein Benutzer auf Host A den folgenden Ping-Befehl an die Link-Local-ISATAP-Adresse von Host B senden: ping FE80::5EFE:192.168.41.30%2 Da es sich bei dem Ziel des Ping-Befehls um eine Link-Local-Adresse handelt, muss im Abschnitt "%Zonenkennung" des Befehls der Schnittstellenindex der Schnittstelle angegeben werden, von der der Verkehr gesendet wird. In diesem Fall wird mit "%2" die Schnittstelle 2 angegeben; hierbei handelt es sich um den Schnittstellenindex, der der Pseudoschnittstelle für automatisches Tunneling auf Host A zugeordnet ist. Die ISATAP-Schnittstelle verwendet die letzten 32 Bits der IPv6-Zieladresse als IPv4-Zieladresse und die lokal zugeordnete IPv4-Adresse als IPv4-Quelladresse. Verwenden eines ISATAP-RoutersDie Verwendung von Link-Local-ISATAP-Adressen ermöglicht IPv6/IPv4-Hosts im gleichen logischen ISATAP-Subnetz, miteinander zu kommunizieren. Link-Local-Adressen werden jedoch nicht in DNS registriert und können nicht für die Kommunikation mit anderen IPv6-Hosts in anderen Subnetzen verwendet werden. Sollen ISATAP-Hosts zusätzliche Subnetzpräfixe erhalten, müssen sie die Routersuche und die automatische Adresskonfiguration über einen ISATAP-Router durchführen. Für die Kommunikation über das logische Subnetz hinaus, bei der keine Link-Local-ISATAP-Adressen verwendet werden, müssen ISATAP-Hosts ihre Pakete zu einem ISATAP-Router tunneln. Abbildung 15-5 zeigt einen ISATAP-Router. Bei einem ISATAP-Router handelt es sich um einen IPv6/IPv4-Router, der Folgendes leistet:
Wenn ein ISATAP-Host von einem ISATAP-Router eine Routerankündigung empfängt, führt er die automatische Adresskonfiguration aus und konfiguriert zusätzliche IPv6-Adressen auf der ISATAP-Schnittstelle mit der Schnittstellenkennung ::5EFE:w.x.y.z. Wenn der ISATAP-Router sich selbst als Standardrouter bekannt gibt, fügt der ISATAP-Host mithilfe der ISATAP-Schnittstelle eine Standardroute (::/0) hinzu, wobei die Adresse für den nächsten Hop auf die Link-Local-ISATAP-Adresse des ISATAP-Routers festgelegt wird. Wenn ein ISATAP-Host Pakete an Ziele außerhalb des logischen ISATAP-Subnetzes sendet, werden sie zur IPv4-Adresse des ISATAP-Routers getunnelt. Das IPv6-Paket wird anschließend vom ISATAP-Router weitergeleitet. IPv6 für Windows Server 2003 und Windows XP bezieht die IPv4-Adresse des ISATAP-Routers über einen der folgenden Schritte:
Auflösen des ISATAP-NamensBeim Start von IPv6 für Windows Server 2003 und Windows XP wird versucht, den Namen "ISATAP" in eine IPv4-Adresse aufzulösen. Dabei werden die folgenden TCP/IP-Verfahren zur Auflösung von Namen verwendet:
Bei Erfolg sendet der Host an den ISATAP-Router eine IPv4-gekapselte Routeranfragenachricht. Der ISATAP-Router antwortet mit einer IPv4-gekapselten Routerankündigungsnachricht, die Subnetzpräfixe enthält, die für die automatische Konfiguration von ISATAP-Adressen verwendet werden, und in der er sich selbst als Standardrouter bekannt gibt. Wenn Sie sicherstellen möchten, dass mindestens einer dieser Versuche erfolgreich ist, können Sie je nach Bedarf einen oder mehrere der folgenden Schritte ausführen:
Verwenden des Befehls "netsh interface ipv6 isatap set router"Zwar ist die automatische Auflösung des ISATAP-Namens die empfohlene Methode zur Konfiguration der IPv4-Adresse des ISATAP-Routers, doch können Sie den Namen oder die IPv4-Adresse des ISATAP-Routers mit dem Befehl netsh interface ipv6 isatap set router auch manuell konfigurieren. Dieser Befehl hat folgende Syntax: netsh interface ipv6 isatap set router Adresse_oder_Name Bei Adresse_oder_Name handelt es sich um den Namen oder die IPv4-Adresse der Intranetschnittstelle des ISATAP-Routers. Wenn die IPv4-Adresse des ISATAP-Routers z. B. 192.168.39.1 lautet, so lautet der Befehl: netsh interface ipv6 isatap set router 192.168.39.1 Einrichten eines ISATAP-RoutersEin Computer unter Windows Server 2003 oder Windows XP kann als ISATAP-Router konfiguriert werden. Angenommen, der Router ist bereits für die Weiterleitung von IPv6-Verkehr über seine LAN-Schnittstellen konfiguriert und verfügt über eine Standardroute, die veröffentlicht wird, müssen auf dem Router die folgenden zusätzlichen Befehle eingegeben werden: netsh interface ipv6 set interface "Pseudoschnittstelle für automatisches Tunneling" forwarding=enabled advertise=enabled netsh interface ipv6 add routeSubnetzpräfix/Präfixlänge "Pseudoschnittstelle für automatisches Tunneling" publish=yes Mit dem ersten Befehl wird die Weiterleitung und Ankündigung über die Pseudoschnittstelle für automatisches Tunneling (die ISATAP-Schnittstelle) aktiviert. Mit dem zweiten Befehl wird die Ankündigung eines bestimmten Subnetzpräfix (Subnetzpräfix/Präfixlänge) über die Pseudoschnittstelle für automatisches Tunneling aktiviert. Verwenden Sie diesen Befehl ein Mal oder mehrere Male, um die erforderliche Anzahl an Subnetzpräfixen bekannt zu geben. Alle mit diesem Befehl konfigurierten Subnetzpräfixe sind in der Routerankündigungsnachricht enthalten, die an den ISATAP-Host zurückgesendet wird. Wenn der Router nicht den Namen ISATAP hat oder der Name ISATAP nicht in die IPv4-Adresse der Intranetschnittstelle des Routers aufgelöst wird, müssen Sie auf dem Router zusätzlich den folgenden Befehl eingeben: netsh interface ipv6 isatap set router Adresse_oder_Name IPv6-zu-IPv4IPv6-zu-IPv4 ist ein Adresszuordnungs- und ein automatisches Router-zu-Router-Tunnelingverfahren, mit dem IPv6-Unicastverbindungen zwischen IPv6-Standorten und -Hosts über das IPv4-Internet bereitgestellt werden. IPv6-zu-IPv4 verwendet das globale Adresspräfix 2002:WWXX:YYZZ::/48. WWXX:YYZZ ist die hexadezimale Darstellung mit Doppelpunkt einer öffentlichen IPv4-Adresse (w.x.y.z), die einem Standort oder Host zugeordnet ist. Die vollständige IPv6-zu-IPv4-Adresse lautet: 2002:WWXX:YYZZ:Subnetzkennung:Schnittstellenkennung IPv6-zu-IPv4 ist in RFC 3056 beschrieben, wo die folgenden Begriffe definiert werden:
In Abbildung 15-6 werden IPv6-zu-IPv4-Komponenten dargestellt. Innerhalb eines Standorts geben lokale IPv6-Router 2002:WWXX:YYZZ:Subnetzkennung::/64-Subnetzpräfixe bekannt, damit die Hosts IPv6-zu-IPv4-Adressen automatisch konfigurieren können. IPv6-Router innerhalb des Standorts übertragen den Verkehr zwischen den IPv6-zu-IPv4-Hosts. Hosts in einzelnen Subnetzen werden automatisch mit einer 64-Bit-Subnetzroute für die direkte Übermittlung an Nachbarn und einer Standardroute mit der Adresse für den nächsten Hop des bekannt gebenden Routers konfiguriert. IPv6-Verkehr, dessen Subnetzpräfixe nicht den innerhalb des Standorts verwendeten Präfixen entsprechen, wird an einen IPv6-zu-IPv4-Router am Rand des Standorts weitergeleitet. Der IPv6-zu-IPv4-Router am Standortrand verfügt über eine 2002::/16-Route, über die Verkehr an andere IPv6-zu-IPv4-Standorte weitergeleitet wird, sowie über eine Standardroute (::/0), über die Verkehr an einen IPv6-zu-IPv4-Relay-Router weitergeleitet wird. Im Beispielnetzwerk der Abbildung 15-6 können Host A und Host B miteinander kommunizieren, da es eine Standardroute gibt, die die Adresse für den nächsten Hop des IPv6-zu-IPv4-Routers an Standort 1 verwendet. Wenn Host A mit dem an einem anderen Standort befindlichen Host C kommuniziert, sendet Host A den Verkehr an den IPv6-zu-IPv4-Router an Standort 1 in Form von IPv6-Paketen. Der IPv6-zu-IPv4-Router an Standort 1, der die Route 2002::/16 in seiner Routingtabelle und die IPv6-zu-IPv4-Tunnelschnittstelle verwendet, kapselt den Verkehr mit einem IPv4-Header und sendet ihn über einen Tunnel zum IPv6-zu-IPv4-Router an Standort 2. Der IPv6-zu-IPv4-Router an Standort 2 empfängt den getunnelten Verkehr, entfernt den IPv4-Header und leitet das IPv6-Paket unter Verwendung der Subnetzpräfixroute in seiner Routingtabelle an Host C weiter. Beispiel: Host A befindet sich im Subnetz 1 von Standort 1 mit der öffentlichen IPv4-Adresse 157.60.91.123. Host C befindet sich im Subnetz 2 von Standort 2 mit der öffentlichen IPv4-Adresse 131.107.210.49. In Tabelle 2 sind die Adressen im IPv4- und im IPv6-Header aufgeführt, die verwendet werden, wenn der IPv6-zu-IPv4-Router an Standort 1 das IPv4-gekapselte IPv6-Paket an den IPv6-zu-IPv4-Router an Standort 2 sendet.
Wenn Sie IPv6-zu-IPv4-Hosts, eine IPv6-Routinginfrastruktur innerhalb eines Standorts, einen IPv6-zu-IPv4-Router an der Standortgrenze und einen IPv6-zu-IPv4-Relay-Router verwenden, sind die folgenden Kommunikationsarten möglich:
Alle diese Kommunikationsarten beruhen auf IPv6-Verkehr, wobei es nicht es notwendig ist, eine direkte Verbindung mit dem IPv6-Internet herzustellen oder ein globales Adresspräfix von einem Internetdienstanbieter (Internet Service Provider, ISP) zu beziehen. IPv6-zu-IPv4-Unterstützung in Windows Server 2003 und Windows XPDie IPv6-zu-IPv4-Komponente von IPv6 für Windows Server 2003 und Windows XP unterstützt das IPv6-zu-IPv4-Tunneling. Wenn einer Schnittstelle auf dem Host eine öffentliche IPv4-Adresse zugeordnet ist und in einer Routerankündigung kein globales Präfix empfangen wird, werden von der IPv6-zu-IPv4-Komponente folgende Schritte ausgeführt:
Die Ergebnisse der automatischen Konfiguration der IPv6-zu-IPv4-Komponente variieren je nach der Konfiguration des Hosts. Abbildung 15-7 zeigt, wie IPv6-zu-IPv4 für verschiedene Hosts unter Windows Server 2003 oder Windows XP (bis auf IPv6-Host D) konfiguriert wird. Bei einem Host, dem eine private IPv4-Adresse zugeordnet wird oder der eine Routerankündigung für ein globales Präfix empfängt, werden der Pseudoschnittstelle für IPv6-zu-IPv4-Tunneling keine IPv6-zu-IPv4-Adressen zugeordnet. Die Adressen und Routen werden automatisch entsprechend der empfangenen Routerankündigung konfiguriert. Diese Konfiguration entspricht Host A, Host B und Host C in Abbildung 15-7. Ein Host, dem eine öffentliche IPv4-Adresse zugeordnet wird und der keine Routerankündigung für ein globales Präfix empfängt, konfiguriert automatisch eine IPv6-zu-IPv4-Adresse der Form 2002:WWXX:YYZZ::WWXX:YYZZ auf der Pseudoschnittstelle für IPv6-zu-IPv4-Tunneling. Der Host fügt mithilfe der Pseudoschnittstelle für IPv6-zu-IPv4-Tunneling eine 2002::/16-Route hinzu, und wenn die DNS-Abfrage für den IPv6-zu-IPv4-Relay-Router erfolgreich ist, fügt er mithilfe der IPv6-zu-IPv4-Adresse des IPv6-zu-IPv4-Relay-Routers als nächstem Hop eine Standardroute hinzu. Bei diesem Hosttyp handelt es sich um einen IPv6-zu-IPv4-Host, der ebenso wie ein IPv6-zu-IPv4-Router das Tunneling selbst ausführt. Diese Konfiguration entspricht dem IPv6-zu-IPv4-Host/-Router E in Abbildung 15-7, einem Host, der direkt mit dem IPv4-Internet verbunden ist. Ein Computer unter Windows Server 2003 oder Windows XP kann sich selbst mittels der Konfiguration der Funktion zur gemeinsamen Nutzung der Interverbindung automatisch als IPv6-zu-IPv4-Router konfigurieren. Diese Konfiguration entspricht dem IPv6-zu-IPv4-Router 1 in Abbildung 15-7. Wenn die gemeinsame Nutzung der Internetverbindung auf einer Schnittstelle aktiviert ist, der eine öffentliche IPv4-Adresse zugeordnet ist, führt die IPv6-zu-IPv4-Komponente automatisch folgende Schritte aus:
Für einen Computer mit gemeinsam genutzter Internetverbindung, der die öffentliche IPv4-Adresse 131.107.23.89 und 5 als Schnittstellenindex der privaten Schnittstelle verwendet, würde das bekannt gegebene Präfix beispielsweise 2002:836B:1759:5::/64 lauten. Private Hosts, die diese Routerankündigung empfangen, würden globale Adressen mittels normaler automatischer Adresskonfiguration erstellen und die Route 2002:836B:1759:5::/64 für das lokale Subnetz sowie eine Standardroute mit einer Adresse für den nächsten Hop erstellen, die der Link-Local-Adresse der privaten Schnittstelle des Computers mit gemeinsam genutzter Internetverbindung entspricht. Private Hosts können über die Route 2002:836B:1759:5::/64 im gleichen Subnetz miteinander kommunizieren. Für alle übrigen Ziele zu anderen IPv6-zu-IPv4-Standorten oder zum IPv6-Internet leiten die IPv6-zu-IPv4-Hosts die IPv6-Pakete über die Standardroute zum Computer mit gemeinsam genutzter Internetverbindung. Für den Verkehr zu anderen IPv6-zu-IPv4-Standorten verwendet der Computer mit gemeinsam genutzter Internetverbindung die Route 2002::/16, kapselt den IPv6-Verkehr mit einem IPv4-Header und sendet ihn über das IPv4-Internet zu einem anderen IPv6-zu-IPv4-Router. Für den gesamten übrigen IPv6-Verkehr verwendet der Computer mit gemeinsam genutzter Internetverbindung die Standardroute, kapselt den IPv6-Verkehr mit einem IPv4-Header und sendet ihn über das IPv4-Internet zu einem IPv6-zu-IPv4-Relay-Router. Gehen Sie folgendermaßen vor, um einen Computer unter Windows Server 2003 oder Windows XP manuell als IPv6-zu-IPv4-Router zu konfigurieren:
Beispiel: Ein Computer verfügt über drei LAN-Schnittstellen mit der folgenden Konfiguration:
Führen Sie die folgenden Befehle aus, um diesen Computer als IPv6-zu-IPv4-Router zu konfigurieren:
In diesem Beispiel wird das Subnetzpräfix 2002:836b:1:5::/64 über LAN-Verbindung 2 und das Subnetzpräfix 2002_836b:1:6::/64 über LAN-Verbindung 3 bekannt gegeben (836b:1 ist die Hexadezimalnotation mit Doppelpunkt für die öffentliche IPv4-Adresse 131.107.0.1). Entsprechend der Konvention wird die Subnetzkennung auf den Schnittstellenindex der Schnittstelle eingestellt, über die das Präfix bekannt gegeben wird. Sie können eine beliebige Subnetzkennung (von 0 bis 0xffff) angeben. TeredoTeredo, auch bekannt unter der Bezeichnung IPv4-NAT-T (Network Address Translator Traversal) für IPv6, bietet Adresszuordnung und automatisches Host-zu-Host-Tunneling für IPv6-Unicastkonnektivität über das IPv4-Internet, wenn sich hinter einem oder mehreren IPv4-NATs IPv6/IPv4-Hosts befinden. Teredo ist in RFC 4380 definiert. Für das Durchqueren von IPv4-NATs werden IPv6-Pakete als IPv4-basierte UDP (User Datagram Protocol)-Nachrichten gesendet. IPv6-zu-IPv4 stellt eine ähnliche Funktion wie Teredo zur Verfügung. Allerdings muss das Edge-Gerät, das mit dem Internet verbunden ist, IPv6-zu-IPv4-Router unterstützen. Die Funktionen von IPv6-zu-IPv4-Routern werden von IPv4-NATs häufig nicht unterstützt. Selbst wenn der Edge-NAT IPv6-zu-IPv4 unterstützte, würde IPv6-zu-IPv4 bei Konfigurationen mit mehreren NATs zwischen einem Standort und dem Internet dennoch nicht funktionieren. Mit Teredo werden die Probleme fehlender IPv6-zu-IPv4-Funktionen in modernen NATs oder mehrschichtigen NAT-Konfigurationen dadurch gelöst, dass IPv6-Pakete zwischen den Hosts innerhalb der Standorte getunnelt werden. Im Gegensatz dazu erfolgt bei IPv6-zu-IPv4 das Tunneling ab dem Edge-Gerät. Das Tunneling ab den Hosts stellt für NATs ein weiteres Problem dar: Beim Senden IPv4-gekapselter IPv6-Pakete ist das Protokollfeld im IPv4-Header auf 41 festgelegt. Die meisten NATs übersetzen nur TCP- oder UDP-Verkehr und müssen entweder manuell konfiguriert werden, damit andere Protokolle übersetzt werden, oder müssen über einen installierten NAT-Editor verfügen, der die Übersetzung übernimmt. Da die Übersetzung von Protokoll 41 bei NATs nicht sehr verbreitet ist, wird IPv4-gekapselter IPv6-Verkehr nicht über typische NATs geleitet. Das IPv6-Paket wird daher als eine IPv4-UDP-Nachricht gekapselt, die sowohl IPv4- als auch UDP-Header enthält. UDP-Nachrichten werden von den meisten NATs übersetzt und können mehrere Schichten von NATs durchqueren. Teredo ist eine als letztes Mittel vorgesehene Übergangstechnologie für IPv6-Konnektivität. Wenn zwischen den kommunizierenden Knoten systemeigene IPv6, IPv6-zu-IPv4- oder ISATAP-Verbindungen bestehen, wird Teredo nicht verwendet. Je mehr IPv4-NATs aufgerüstet werden und IPv6-zu-IPv4 unterstützen und je weiter verbreitet IPv6-Verbindungen werden, desto weniger wird Teredo verwendet, bis es schließlich ganz eingestellt wird. Teredo in Windows Server 2003 Service Pack 1, Windows XP SP2 und Windows XP SP1 mit dem erweiterten Netzwerkpaket für Windows XP funktioniert nur bei Cone-NATs und eingeschränkten NATs.
Es gibt einen weiteren NAT-Typ, den so genannten symmetrischen NAT. Dieser ordnet je nach der externen Zieladresse (für ausgehenden Verkehr) eine interne Adresse und Portnummer verschiedenen externen Adressen und Ports zu. Symmetrische NATs werden von Teredo in Windows Server 2003 und Windows XP nicht unterstützt. Teredo-KomponentenAbbildung 15-8 zeigt die Komponenten für die Teredo-Konnektivität Teredo enthält die folgenden Komponenten:
Die Funktionalität für Teredo-Clients und hostspezifische Teredo-Relays ist in Windows Server 2003 mit Service Pack 1, Windows XP mit SP2 und Windows XP mit SP1 und im erweiterten Netzwerkpaket für Windows XP enthalten. Die Funktionen für hostspezifische Teredo-Relays werden automatisch aktiviert, wenn eine globale IPv6-Adresse zugeordnet wurde. Eine globale Adresse kann durch eine Routerankündigungsnachricht zugeordnet werden, die über einen systemeigenen IPv6-Router, einen ISATAP-Router oder einen IPv6-zu-IPv4-Router empfangen wird. Wird keine globale Adresse konfiguriert, wird der Teredo-Client aktiviert. Teredo-AdressenTeredo-Adressen haben das in Abbildung 15-9 dargestellte Format. Eine Teredo-Adresse besteht aus folgenden Elementen:
Funktionsweise von TeredoBei zwei Windows-basierten Teredo-Clients sind vor allem diejenigen Teredo-Prozesse entscheidend, die für die anfängliche Konfiguration und Kommunikation mit einem Peer an einem anderen Standort verwendet werden. Anfängliche KonfigurationFür die anfängliche Konfiguration senden Teredo-Clients an mehrere Teredo-Server eine Reihe von Routeranfragenachrichten. Windows-basierte Teredo-Clients beziehen die IPv4-Adressen von Teredo-Servern im IPv4-Internet, indem sie eine DNS-Abfrage für den Namen teredo.ipv6.microsoft.com ausführen. Mit dem Befehl netsh interface ipv6 set teredo servername= Adresse_oder_Name können Sie den abzufragenden DNS-Namen angeben. Der Teredo-Client leitet mithilfe der Routerankündigungen eine Teredo-Adresse ab und stellt fest, ob sich der Client hinter einem Cone-, einem eingeschränkten oder einem symmetrischen NAT befindet. Der vom Teredo-Client entdeckte NAT-Typ wird angezeigt, wenn Sie den Befehl netsh interface ipv6 show teredo eingeben. Entsprechend den empfangenen Routerankündigungsnachrichten wird die Teredo-Adresse des Teredo-Clients folgendermaßen erzeugt:
Die externe IPv4-Adresse und die UDP-Portnummer für Teredo-Verkehr sind in den von den Teredo-Servern gesendeten Routerankündigungen in einem zusätzlichen Teredo-Header enthalten. Anfängliche Kommunikation zwischen zwei Teredo-Clients an verschiedenen StandortenWelche Pakete während der ersten Kommunikation zwischen Teredo-Clients an verschiedenen Standorten gesendet werden, hängt davon ab, ob sich die Teredo-Clients hinter Cone-NATs oder eingeschränkten NATs befinden. Wenn sich ein Teredo-Client hinter einem Cone-NAT befindet, lassen die NAT-Übersetzungstabelleneinträge für Teredo-Verkehr des Teredo-Clients Verkehr von jeder IP-Quelladresse bzw. jedem UDP-Quellport zu. Ein Teredo-Client kann daher Pakete direkt an einen anderen Teredo-Client hinter einem Cone-NAT senden, ohne weitere Pakete senden zu müssen. Wenn sich ein Teredo-Client hinter einem eingeschränkten NAT befindet, lassen die NAT-Übersetzungstabelleneinträge für Teredo-Verkehr des Teredo-Clients Verkehr nur von bestimmten IPv4-Adressen bzw. bestimmten UDP-Portnummern zu. Wenn sich ein Teredo-Client also hinter einem eingeschränkten NAT befindet, muss der initiierende Teredo-Client vor dem Senden des ersten Kommunikationspakets Pakete senden, um eine quellspezifische NAT-Zuordnung zu erstellen, die es ermöglicht, dass der Verkehr des initiierenden Teredo-Clients den eingeschränkten NAT durchqueren kann. Abbildung 15-10 zeigt den ersten Kommunikationsprozess zwischen Teredo-Clients an verschiedenen Standorten, wenn an beiden Standorten eingeschränkte NATs verwendet werden.  Abbildung 15-10: Prozess beim Senden eines ersten Pakets, wenn sich zwei Teredo-Clients hinter einem eingeschränkten NAT befinden Abbildung vergrößern Das Senden eines ersten Kommunikationspakets von Teredo-Client A zu Teredo-Client B läuft folgendermaßen ab:
Dieser Prozess ist für die Benutzer auf Teredo-Client A und Teredo-Client B nicht wahrnehmbar. Weitere erste Kommunikationsprozesse finden statt, wenn sich das Ziel für das erste Paket auf derselben Verbindung, im IPv6-Internet oder bei einem hostspezifischen Teredo-Relay befindet. Weitere Informationen finden Sie unter Überblick zu Teredo. Migration zu IPv6Die Migration von IPv4 zu IPv6 ist ein langer Prozess. Bei der Migration von IPv4 zu IPv6 müssen Sie grundsätzlich die folgenden Schritte ausführen:
KapitelzusammenfassungDieses Kapitel enthält die folgenden Schlüsselinformationen:
Kapitelglossar_ISATAP-Name – Siehe ISATAP-Name. IPv6-zu-IPv4 – Eine IPv6-Übergangstechnologie, die IPv6-Unicastverbindungen zwischen IPv6-Standorten über das IPv4-Internet ermöglicht. IPv6-zu-IPv4 verwendet für die Konstruktion eines globalen IPv6-Adresspräfix eine öffentliche IPv4-Adresse. IPv6-zu-IPv4-Adresse – Eine Adresse des Typs 2002:WWXX:YYZZ:Subnetzkennung:Schnittstellenkennung. Dabei ist WWXX:YYZZ die Hexadezimaldarstellung mit Doppelpunkt für w.x.y.z (eine öffentliche IPv4-Adresse). Mit einer IPv6-zu-IPv4-Adresse wird ein Knoten für die IPv6-zu-IPv4-Übergangstechnologie dargestellt. IPv6-zu-IPv4-Host – Ein IPv6-Host, der mit mindestens einer IPv6-zu-IPv4-Adresse (einer globalen Adresse mit dem Präfix 2002::/16) konfiguriert ist. IPv6-zu-IPv4-Hosts müssen nicht manuell konfiguriert werden und erstellen 6to4-Adressen mithilfe standardmäßiger Mechanismen für die automatische Adresskonfiguration. IPv6-zu-IPv4-Relay-Router – Ein IPv6/IPv4-Router, der Verkehr mit IPv6-zu-IPv4-Adressen zwischen IPv6-zu-IPv4-Routern im IPv4-Internet und Hosts im IPv6-Internet weiterleitet. IPv6-zu-IPv4-Router – Ein IPv6/IPv4-Router, der die Verwendung einer IPv6-zu-IPv4-Tunnelschnittstelle unterstützt und in der Regel zur Weiterleitung von Verkehr mit IPv6-zu-IPv4-Adressen zwischen den IPv6-zu-IPv4-Hosts eines Standorts und anderen IPv6-zu-IPv4-Routern im IPv4-Internet verwendet wird. Automatischer Tunnel – Ein IPv6-über-IPv4-Tunnel, dessen Endpunkte durch die Verwendung logischer Tunnelschnittstellen und Routen bestimmt werden. Konfigurierter Tunnel – Ein IPv6-über-IPv4-Tunnel, dessen Endpunkte manuell konfiguriert werden. Architektur mit doppelter IP-Schicht – Die Architektur eines IPv6/IPv4-Knotens, bei der eine einzige Implementierung von Protokollen der Transportschicht wie z. B. TCP und UDP über separaten Implementierungen von IPv4 und IPv6 arbeitet. Architektur mit doppeltem Stapel – Die Architektur eines IPv6/IPv4-Knotens, die zwei separate Protokollstapel umfasst, einen für IPv4 und einen für IPv6, wobei jeder Stapel über seine eigene Implementierung der Transportschichtprotokolle (TCP und UDP) verfügt. Host-zu-Host-Tunneling – IPv6-über-IPv4-Tunneling mit zwei Hosts als Tunnelendpunkten. Beispiel: Ein IPv6/IPv4-Knoten, der sich innerhalb einer IPv4-Infrastruktur befindet, erstellt einen IPv6-über-IPv4-Tunnel, um einen anderen Host innerhalb derselben IPv4-Infrastruktur zu erreichen. Host-zu-Router-Tunneling – IPv6-über-IPv4-Tunneling, bei dem der Tunnel am sendenden Host beginnt und an einem IPv6/IPv4-Router endet. Beispiel: Ein IPv6/IPv4-Knoten, der sich innerhalb einer IPv4-Infrastruktur befindet, erstellt einen IPv6-über-IPv4-Tunnel, um einen IPv6/IPv4-Router zu erreichen. Intra-site Automatic Tunnel Addressing Protocol (ISATAP) – Eine IPv6-Übergangstechnologie, die IPv6-Unicastkonnektivität zwischen IPv6-Hosts in einem IPv4-Intranet bereitstellt. ISATAP leitet die Schnittstellenkennung aus einer (öffentlichen oder privaten) IPv4-Adresse ab, die einem Host zugeordnet ist. IPv6 in IPv4 – Siehe IPv6-über-IPv4-Tunneling. IPv6-über-IPv4-Tunneling – Die Kapselung von IPv6-Paketen mit einem IPv4-Header, so dass IPv6-Verkehr über eine IPv4-Infrastruktur gesendet werden kann. Im IPv4-Header ist das Protokollfeld auf 41 festgelegt. IPv6/IPv4-Knoten – Ein Knoten, der sowohl IPv4 als auch IPv6 verwendet. Reiner IPv6-Knoten – Ein Knoten, der nur IPv6 verwendet und dem nur IPv6-Adressen zugeordnet werden. ISATAP – Siehe Intra-site Automatic Tunnel Addressing Protocol (ISATAP). ISATAP-Adresse – Eine Adresse des Typs Unicastadresspräfix:0:5EFE:w.x.y.z. Dabei steht w.x.y.z für eine öffentliche oder private IPv4-Adresse, die einem ISATAP-Host zugeordnet ist. ISATAP-Host – Ein Host, dem eine ISATAP-Adresse zugeordnet ist. ISATAP-Name – Der Name, der standardmäßig von Computern unter Windows XP mit Service Pack 1, Windows XP mit Service Pack 2 oder Windows Server 2003 aufgelöst wird, um die IPv4-Adresse des ISATAP-Routers automatisch zu entdecken. Computer, auf denen Windows XP ohne Service Packs ausgeführt wird, versuchen standardmäßig, den Namen "_ISATAP" aufzulösen. ISATAP-Router – Ein IPv6/IPv4-Router, der auf getunnelte Routeranfragen von ISATAP-Hosts antwortet und Verkehr zwischen ISATAP-Hosts und Knoten in anderen IPv6-Subnetzen weiterleitet. Router-zu-Host-Tunneling – IPv6-über-IPv4-Tunneling, bei dem der Tunnel an einem weiterleitenden Router beginnt und an einem IPv6/IPv4-Host endet. Beispiel: Ein IPv6/IPv4-Router erstellt einen IPv6-über-IPv4-Tunnel, um einen IPv6/IPv4-Host zu erreichen, der sich innerhalb einer IPv4-Infrastruktur befindet. Router-zu-Router-Tunneling – IPv6-über-IPv4-Tunneling, bei dem der Tunnel an einem weiterleitenden Router beginnt und an einem IPv6/IPv4-Router endet. Beispiel: Ein IPv6/IPv4-Router, der sich am Rand eines IPv6-Netzwerks befindet, erstellt einen IPv6-über-IPv4-Tunnel, um einen anderen IPv6/IPv4-Router zu erreichen.
|
In diesem Beitrag
| ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
