Seminararbeit zu IPv6 Migration

Christian Stadach

... < zurück ... [Linux und Netzwerke, Softwareentwicklung mit Eclipse] ... IPv6 Migrationstechniken ... vor >

Übersicht: IPv6 Migrationstechniken

Übersicht

In diesem Kapitel werden mögliche Migrationsmethoden vorgestellt, die einen Übergang von IPv4 zu IPv6 ermöglichen sollen.

Aufgrund der großen Anzahl von Geräten, die permanent über IPv4 miteinander vernetzt sind, ist dies kein triviales Vorhaben. Es muss mit einer Übergangszeit gerechnet werden, während der IPv4 und IPv6 parallel eingesetzt werden.

Dualstack Rechner

Ein Dual-Stack Rechner ist ein Netzwerkgerät, dessen Netzwerkstack sowohl das IPv4 als auch das IPv6 Protokoll implementiert und somit eine Datenverbindung auf Ebene beider Protokolle unterstützt. Sein Netzwerk Interface besitzt sowohl eine IPv4 als auch eine IPv6 Adresse. Beim Aufbau einer Datenverbindung wird die einer IPv6-Verbindung gegenüber einer IPv4-Verbindung bevorzugt.

Diese Technik ermöglicht es, dem Betriebssystem Datenverbindungen über beide Protokolle aufzubauen und ist somit ein zwingender Bestandteil einer Migration von IPv4 zu IPv6.

Abbildung 4: Die Protokollfamilien IPv4 und IPv6 (Aus [1], Seite 302)

Tunneling

Einleitung

Beim Tunneling wird dem IPv6 Datenpaket ein IPv4-Header vorangestellt. Im IPv4-Header wird im Protokoll-Feld die 41 (IPv6) als Folgeprotokoll angegeben.

Hierbei entsteht ein logischer Tunnel, der es der IPv6-Datenkommunikation ermöglicht das Protokollfremde Netz (IPv4) zu durchqueren.

Abbildung 5: IPv4 Paket mit IPv6 als Payload

Man unterscheidet zwischen automatischen und manuellen Tunneln. Beim manuellen Tunneling bedarf es einer Konfiguration des Tunnels und der Routen an beiden Seiten des Tunnels. Das heißt, dass für jede IPv6-Ende-zu-Ende-Verbindung die Adresse eines Tunnelanfangs und eines Tunnelendes definiert werden muss. Bei dem automatischen Tunneling wird dies durch eine Client-Software oder das Betriebssystem übernommen.

Adressaufbau

Liegen IPv4 kompatible Adressen (das heißt Adressen aus denen sich eine IPv4 Adresse berechnen lässt) vor (Siehe Abbildung 1), können diese am Anfang und am Ende des Tunnels jeweils durch den Router umgerechnet und in den IPv4-Header eingetragen werden.

Im Gegensatz dazu müssen bei reinen Global-Unicast-Adressen Zuordnungstabellen vorliegen, die einer Ziel-IPv6-Adresse eine Ziel IPv4-Adresse zuweisen.

Kommunikationsablauf

Abbildung 6: IPv6-in-IPv4 Tunnel

Es gibt unterschiedliche Szenarien mit unterschiedlichen Arten des Tunnelaufbaus.

Wenn sich der absendende Host in einem reinen IPv4-Netz befindet, muss dieser die Dualstack-Technologie implementieren. Um einen Tunnel aufzubauen, muss er direkt das IPv6-Paket mit einem IPv4 Header versehen und es an den entfernten Router (ebenfalls mit der Dualstack-Technologie versehen) schicken, der an der Grenze zwischen dem zu untertunnelnden IPv4- und dem Ziel IPv6-Netz liegt.

Wenn sich der absendende Host in einem IPv6-Netz befindet, ist er nicht verantwortlich den Tunnel aufzubauen. Diese Aufgabe übernimmt der Router, der zwischen das IPv6 und das IPv4-Netz geschaltet ist.

Die Szenarien am Ende des Tunnels entsprechen direkt denen, die zum Aufbau benutzt werden.

Wenn bei diesen Methoden keine IPv4-kompatiblen Adressen vorliegen, muss das Gerät, welches den Tunnel aufbaut, eine Zuordnungstabelle besitzen, die es Ihm ermöglicht herauszufinden welches IPv4-Interface angesteuert werden muss, um einen bestimmten entfernten IPv6-Host zu erreichen.

6to4 Tunneling

Einleitung

Das 6to4 Tunneling gehört zu den automatischen Tunnelverfahren. Die automatische Einstellung des Tunnels wird durch die IPv4 kompatible 6to4-Adressen (Siehe Abbildung 1) erreicht.

Abbildung 7: Sitevernetzung über IPv4-Transitnetze (Beispiel)

Verwendet wird das 6to4-Tunneling vor allem bei der Vernetzung von IPv6-Sites untereinander. Hierbei muss eine Site jeweils einen 6to4 Router (Dualstack fähig) enthalten, der über ein IPv4-Netz die Ziel-IPv6-Site erreichen kann.

Adressaufbau

Der 6to4-Router generiert aus seiner IPv4-Adresse das 6to4-Netz-Präfix für die IPv6-Sites und teilt den jeweiligen 6to4-Hosts per DHCPv6 (Router-Advertisement/Router-Solicitation via ICMPv6) ihre 6to4 Adresse mit.

Die Adresse ergibt sich aus:

Abbildung 8: Aufbau der 6to4 IPv6-Adressen

Kommunikationsablauf

Wenn ein Host in einer IPv6-Site ein Datenpaket an einen sich in einer anderen IPv6-Site befindlichen Host schicken will, schickt er das Datenpaket an den 6to4 Router. Dieser erkennt die 6to4 Zieladresse, erstellt einen passenden IPv4 Header, bei dem die Zieladresse die des 6to4 Routers am Tunnelende ist und leitet das Paket über das IPv4 Netz weiter. Der 6to4 Router am Tunnelende erkennt an dem Wert im Protokoll-Feld des IPv4-Headers (41), dass es sich um eine 6to4 Kommunikation handelt, entfernt den IPv4 Header und leitet das Paket an den Ziel Host weiter.

Probleme

Beim Einsatz von NAT funktioniert das 6to4-Tunneling nicht, da hierbei die IPv4 Adresse, die sich im IPv6 Präfix der 6to4-Hosts befindet eine private Adresse wäre, die in einem öffentlichen IPv4 Netz nicht weitergeleitet wird. So erreicht ein Datenpaket vielleicht sein Ziel, der Zielhost hat nun aber keine Möglichkeit mehr zu Antworten.

Teredo Tunneling

Einleitung

Beim Teredo Tunnel handelt es sich ebenfalls, um ein automatisches Tunnel-Verfahren. Der Tunnel wird zwischen einem lokal auf dem Quell-Host laufenden Teredo-Client und einem Teredo-Server beziehungsweise Teredo-Relay aufgebaut

Der Nachteil anderer Tunneling Verfahren ist meist, dass sie nicht funktionieren, sobald die IP-Kommunikation durch ein NAT-System hindurch geht. Bei der Teredo Technik wird das NAT-System gezielt "durchbohrt", um eine direkte Kommunikation zu ermöglichen.

Abbildung 9: Konzept von Teredo

Adressaufbau

Die Teredo Technik ermöglicht die Zuteilung von IPv6-Adressen sowie den automatischen Aufbau eines IPv6-in-IPv4-Tunnels.
Kern dieser Technik ist wiederum der Aufbau der IPv6-Adresse.

Abbildung 10: Teredo IPv6 Adressaufbau

Die Adresse ergibt sich aus:

NAT-Verfahren

Um das Teredo-Verfahren zu verstehen ist eine kurze Übersicht zu Network-Adress-Translation-Techniken nötig. Network-Adress-Translation steht grundsätzlich für eine Adressumsetzung an der Schnittstelle zwischen zwei Netzen.

Man unterscheidet zwischen drei unterschiedlichen Methoden der Network-Adress-Translation (NAT). Dem Cone-NAT, dem restricted Cone-NAT und dem symetric-NAT.

Beim Cone-NAT Verfahren werden interne Adressen (meist nur privat nutzbare Adressen2) auf eine externe öffentliche IP-Adresse und einen öffentlichen Port umgesetzt. Es wird externen Hosts ebenfalls eine direkte Kommunikation über die Prozessadresse (IP-Adresse + Port-Adresse bilden die Adresse eines Prozesses) ermöglicht. Hierbei ist es irrelevant, von welcher Adresse die externen Hosts die Antwort schicken.

Das restricted Cone-NAT funktioniert genau so, wie das Cone-NAT. Hier wird jedoch zusätzlich zu der Umsetztung der internen Prozess-Adresse sich ebenfalls der Host gemerkt, an den das Datenpaket geschickt wird. Nur diesem Host wird die Möglichkeit gewährt auf das Datenpaket auch zu antworten.

Beim symetric-NAT-Verfahren wird jeder Datenverbindung, bei der zwar die interne Prozess-Adresse gleich ist, der externe Host mit dem der Prozess aber kommunizieren möchte unterschiedlich ist, eine neue externe Prozess-Adresse (gleiche IP-Adresse aber der Port wechselt) zugewiesen.

Bei der Verwendung von NAT-Verfahren ist es nur schwer möglich für einen externen Prozess eine direkte Datenkommunikation zu initiieren. Dies ist einer der Haupt-Kritikpunkte gegen NAT und das große Hindernis eines funktionierenden Tunnelaufbaus zwischen Teredo-Client und Teredo-Server.

Initialisierungsprozess

Um das Port-IP-Mapping des NAT-Systems herauszufinden, wird in der Teredo-Technik ein spezieller Initialisierungsprozess definiert.

Abbildung 11: Teredo-Initialisierung 1. Schritt

Anfangs ist der Teredo-Client-Software nur die IP-Adresse des Teredo-Servers bekannt. Um die weiteren nötigen Informationen zum Aufbau einer Teredo IPv6-Adresse zu erhalten bedient sich der Teredo-Client dem DHCPv6 und bereitet eine Router-Solicitation per ICMPv6 vor. Dieses Datenpaket wird nun durch die Client-Software als UDP-Datenpaket per IPv4 an den Server geschickt.

Da dem Teredo-Client seine vollständige Teredo-Adresse noch nicht bekannt ist, werden bei der Absendeadresse im IPv6-Header nur die bekannten Teile eingetragen, alle anderen Felder werden einfach auf 0 gesetzt.

Anfänglich wird davon ausgegangen, dass es sich bei der Umsetzung der NAT-Technologie um einen Cone-NAT handelt, also wird das Cone-Flag im Flag-Bereich der Teredo-Adresse bei der ersten Router-Solicitation auf eins gesetzt.

Abbildung 12: Teredo-Initialisierung 2. Schritt

Der Teredo-Server empfängt das Router-Advertisement-Paket, speichert sich die IPv4-Adresse und die Port-Nummer die sich im IPv4- und UDP-Header befinden, verschlüsselt diese mit einer XOR-Operation mit dem Wert 0xFFFF (Port-Nummer) und 0xFFFFFFFF (IPv4-Adresse) und trägt diese Werte in die für den Teredo-Clienten bestimmten IPv6-Adresse ein. Die Verschlüsselung der Prozessadressparameter ist nötig, um einer eventuellen Umsetzung dieser Werte durch das NAT-Systems des Teredo-Clients zu verhindern.

Diese Adresse wird nun in einem Router-Advertisement-Paket (wiederum ICMPv6) verpackt und per UDP über IPv4 verschickt. Hierbei wird nun aber eine andere IPv4-Absendeadresse verwendet. Dies geschieht, damit sichergestellt ist, dass das benutzte NAT-Verfahren wirklich Cone-NAT ist.

Kommt dieses Paket beim Teredo-Client an, liegt ein reiner Cone-NAT vor und die Initialisierung ist abgeschlossen. Kommt das Router-Advertisement nicht an, schickt der Teredo-Client nach verstreichen einer festgesetzten Wartezeit erneut eine DHCPv6-Anfrage (Router-Solicitation), auf dem gleichen Wege wie oben bereits beschrieben, ab. Da nun bekannt ist, dass kein Cone-NAT verwendet wird, wird das Cone-Flag im Flag-Bereich der Teredo-Client-IPv6-Adresse nicht gesetzt.

Abbildung 13: Teredo-Initialisierung 3. Schritt

Der Teredo-Server antwortet ebenfalls auf dem gleichen Wege wie oben bereits beschrieben, nur benutzt er diesmal die gleiche IPv4-Absendeadresse auf der er die Router-Solicitation empfangen hat. Da sowohl die Absende-Adresse als auch die Empfangs-Prozess-Adresse dem Port-IP-Mapping im NAT entsprechen, sollte das Paket den Teredo-Client auch erreichen. Geschieht dies nicht, ist eine Teredo-Datenkommunikation nicht möglich.

Der Teredo-Client ist nun im Besitz einer validen Teredo-IPv6-Adresse. Um zu testen, ob es sich bei dem NAT-Verfahren wirklich, um das restricted Cone-NAT-Verfahren handelt, wird erneut eine Router-Solicitation (Cone-Flag nicht gesetzt) über die gleiche Port-Adresskombination an einen anderen Teredo-Server geschickt. Erhält der Client hier drauf eine Antwort, und ist die Port-Nummer in der nun erhaltenen Teredo-IPv6-Adresse mit der vorherig erhaltenen identisch, liegt wirklich ein restricted Cone-NAT vor. Sollte ein Unterschied vorliegen, handelt es sich weder um ein Cone-NAT-Verfahren noch um ein restricted Cone-NAT-Verfahren, eine Teredo-Datenkommunikation ist in diesem Falle nicht möglich.

Probleme

Teredo ist eine Microsoft Entwicklung und ist daher vor allem auf dem Windows Betriebssystemen XP SP2, Vista und den Server Versionen 2003 und 2008 vertreten. Für andere Betriebssysteme gibt es zur Zeit keine Unterstützung durch den Kernel, sondern nur in Form eines Daemons, welcher zusätzlich installiert werden muss.

Da ein NAT-System das Adress- und Port Mapping (je nach NAT-Verfahren) nach einer festgelegten Zeit wieder verwirft, müssen in regelmäßigen Abständen Datenpakete an den Teredo-Server geschickt werden. Dies führt zu einem erhöhten Datenauskommen, welches durch einen Verzicht auf NAT verhindert werden könnte.

Im Zuge der IPv6 Migration wird Teredo nur als Übergangslösung verwendet und sollte nach und nach verschwinden, bis es zuletzt nicht mehr benötigt wird 1

Dual Stack Transition Mechanism

Einleitung

DSTM (Dual-Stack Transition Mechanism) wird für die IPv4 Kommunikation im IPv6-Netz eingesetzt. Die IPv4 Pakete werden als Nutzlast in ein IPv6 Paket eingebettet. Man sagt zu diesem Konzept auch 4in6 oder IPv4-in-IPv6-Tunnel.

Abbildung 14: Konzept von DSTM

Diese Technik ist für einen Zeitpunkt gedacht, an dem der Großteil des Datenverkehrs im Internet auf Basis des IPv6 geschieht, und nur noch einzelne Applikationen aufgrund von Rückwärts-Kompatibilität oder veralteter Implementationen eine IPv4-Datenverbindung voraussetzten.

Kommunikationsablauf

Sobald eine Applikation eine IPv4-Verbindung aufbauen muss, wird von einem DSTM-Server (dieser kann zum Beispiel innerhalb eines DHCPv6-Servers realisiert werden) temporär eine IPv4-Adresse sowie eine IPv6-Adresse des benötigten Tunnelendpunktes angefordert.

Die Verwaltungsinstanz für IPv4-Adressen (der DSTM-Server) ist nötig, da davon auszugehen ist, dass zu der Zeit in der diese Technik eingesetzt wird, die Anzahl von Hosts im Internet die Anzahl der zur Verfügung stehenden IPv4-Adressen übersteigen wird.

Das IPv4-Datenpaket kann nun als Payload eines IPv6-Datenpaketes an den Tunnelendpunkt geschickt werden. Dieser Erkennt anhand des Next-Header-Feldes im IPv6-Header des Datenpaketes (Wert ist 4), dass es sich um einen 4in6-Paket handelt und leitet es dementsprechend weiter.

IP-Kommunikation durch Translation

Einleitung

Die Datenkommunikation zwischen den Rechnern eines IPv4-Netzes und denen eines IPv6-Netzes kann auch mithilfe einer Übersetzung der einzelnen Paket-Header geschehen.

Abbildung 15: SIIT Konzept

Eines dieser Verfahren nennt sich SIIT (Stateless IP/ICMP Translation Algorithm)

Kommunikationsaufbau/ablauf

Diese Methode beschreibt eine zustandslose Übersetzung der Datenpakete. Hierbei wird jedes Paket ohne Berücksichtigung des Zustands der Datenübertragungs-Session übersetzt.

Das SIIT umfasst wie ein IPv4 Header interpretiert wird und daraus ein IPv6 Header erstellt wird und umgekehrt.

Dabei werden die Informationen, die ähnlich beziehungsweise gleich sind, in den jeweils anderen Header eingetragen und das Paket wird weitergeleitet.

Aufgrund der großen Unterschiede in der Adressierung von IPv4- und IPv6-Hosts müssen Adressen eingesetzt werden, die entweder umrechenbar sind oder dem jeweiligen IPv6-Host muss eine IPv4-Adresse zugewiesen werden (ähnlich wie beim DSTM), die es Ihm ermöglicht eine Verbindung mit dem IPv4-Service aufzunehmen.

Probleme

Da die Übersetztung Paket für Paket einen starken Aufwand für den Router bedeutet und es keinen besonderen Vorteil gegenüber der Tunneling-Verfahren gibt, gibt es bisher nur wenige bekannte Implementationen für aktuelle Betriebssysteme.

  1. Vgl. RFC 4380, Kapitel 3.2, http://www.rfc-editor.org/rfc/rfc4380.txt, Abruf: 29.11.2008
  2. Vgl. RFC 1918, Kapitel 3, http://www.faqs.org/rfcs/rfc1918.html, Abruf: 29.11.2008