Viele Wege führen zur Version 6 des Internet Protokolls und keiner ist einfach Von IPv4 zu IPv6 – das kann komplex werden, müsste aber einfach sein

Es gibt verschiedene Arten der Migration von IPv4 zu IPv6. Nur zwei Dinge stehen fest: Erstens wird es noch lange IPv4-Netze geben und zweitens vertragen sich die Protokolle nicht automatisch. Deshalb ist Migration ein Thema, das sich auch damit beschäftigt, wie sich Netze mit unterschiedlichen Adressräumen miteinander verbinden lassen.

Anbieter zum Thema

ICP Deutschland GmbH

BT (Germany) GmbH & Co. oHG

Während das Internet-Protokoll Version 4 (IPv4) mit seiner 32-bittige Adressecodierung 2 hoch 32, also rund 4,3 Milliarden Adressen bereitstellt, sind es beim 128-bittigen IPv6 mehr als 340 sextillionen – eine Sextillion ist eine 1 mit 36 Nullen vor dem Komma. Schon das allein macht deutlich, warum sich Notationen und Adressformate der beiden Internet-Protokolle unterscheiden müssen, obwohl beide Standards für die Netzwerkschicht des OSI-Modells gedacht sind und die Adressierung und das Routing von Datenpaketen durch ein Netzwerk regeln.

Somit betreffen die Änderungen vornehmlich das Routing auf der Netzwerkschicht, doch nicht nur. „Die Änderungen wirken bis in die Applikationen, die diese IP-Adressen anzeigen“, heißt es etwa im Whitepaper „IPv4-to-IPv6 Transition Strategies“ von BT Diamond IP. (siehe: Link). Somit muss sich fast jedes Unternehmen mit der Migration zu IPv6 auseinandersetzen.

Im Wesentlichen lassen sich drei Ansätze unterscheiden: Dual Stack – die Netzwerkgeräte unterstützen sowohl IPv4 als auch IPv6, Tunneling – ein IPv6-Packet wird so gekapselt, dass es über ein IPv4-Netz transportiert werden kann, und Translation – ein Gateway oder Übersetzungsprogramm wandelt die Adressen und Ports in TCP/IP-Code des Host oder Router.

Verdoppeln des Netzwerk-Layer

Ideal wäre es, wenn beim Dual-Stack-Ansatz (siehe: Abbildung 1) lediglich die Netzwerkschicht zweifach existierte, so dass die Applikations-, die Transport und die Link-Schicht identisch bleiben. Das jüngste Microsoft-Betriebssystem Windows Vista verfügt über eine solche Implementierung. Das Vorgängersystem Windows XP hingegen besitzt zwei Transport- und Netzwerk-Schichten, so dass in einigen Fällen Administratoren Konfigurationen redundant auslegen müssen.

Doppelung aller Schichten

Andere Hersteller gehen mit ihrer Implementation jeweils über den gesamten Stack bis hinunter auf die physikalische Schicht. Das erfordert separate Netzwerk-Schnittstellen für IPv4 und IPv6 und widerspricht eigentlich dem Gedanken, Protokolle aufeinander schichten zu können.

Trotzdem, so das BT-Diamond-Papier, gibt es durchaus Fälle, in denen such ein solcher Aufbau gerechtfertigt ist, etwa wenn der Netzwerk-Server viele Applikationen und Services bereitstellt, die jeweils nur eines der Internet-Protokolle bedienen. So versteht etwa das Ethernet und alle Schicht-2-Techniken entweder IPv4 oder IPv6.

Das aber hat deutliche Folgen für die Planung von Netzen. So sind etwa die Auswirkungen auf die Domain Names Services (DNS) gravierend. Schließlich stellen diese die Verbindung zwischen User-Bezeichnungen und IP-Adressen her.

Dual-Stack-Implementation bedeutet für das Dynamic Host Configuration Protocol (DHCP), dass jeder Stack seine eigne DHCP-Version braucht: DHCPv4 oder DHCPv6. Doch ganz so einfach ist das dennoch nicht. Denn es werden zusätzliche Konfigurationsinformationen benötigt, zum Beispiel welcher DNS oder NTP-Server (NTP = Network Time Protocol) benutzt werden soll. Je nachdem, wie diese Informationen auf den Servern zusammengemixt werden, kann es zu inkorrektem Verhalten auf den Clients kommen – ein bekanntes Problem.

Aufbau von Tunneln

Ein weiterer Ansatz ist das Tunneling. Das ist sowohl in Richtung IPv4 über IPv6 möglich als auch umgekehrt (siehe Abbildung 2 und 3). Die jeweiligen Pakete bekommen dabei Header, die die Informationen gleichermaßen kapseln. Dabei müssen unterschiedliche Parameter wie die maximale Übertragungsdauer und die maximale Paketgröße berücksichtigt werden.

Prinzipiell kann das Tunneling automatisch, und vorübergehend generiert oder fix definiert werden. Außerdem sind neben der vermutlich häufigsten Art des Tunneling von Router-zu-Router auch Host-zu-Router-, Router-zu-Host- und Host-zu-Host-Verfahren möglich.

• So basiert das automatische 6zu4-Tunneling auf den Informationen, die im IPv6-Paket stecken, etwa die Quell- und Ziel-Adresse (siehe: Abbildung 3).
• Das automatische Router-zu-Router-Tunneling setzt ein spezielles global gültiges Prefix sowie eine immanente IPv4-Adresse voraus.
• ISATAP, also das automatische Tunneling von Host zu Router oder von Router zum Host oder auch von Host zu Hoats basiert auf einem speziellen IPv6-Adressenformat, das die IPv4-Adresse einschließt.
• 6over4 gibt es im Host-zu-Host-Tunneling indem IPv4-Mulicasting zum Einstaz kommt.
• Auch Tunneling-Broker lassen sich in der Host-zu-Host-Kommunikation verwenden. Hierbei agiert ein Server als Tunnel-Broker und weist Tunnel-Gateway-Ressourcen zu.
• Teredo – ist das Tunneling durch NAT Firewalls über IPv4-Netze.

Transformation

Die in Frage kommenden Übersetzungstechniken, die IPv4- in IPv6-Formate übertragen oder umgekehrt, setzen entweder auf der Netzwerk-, der Transport- oder der Applikationsschicht auf. Anders als beim Tunneling, bei dem die Datenpakete lediglich gekapselt werden, werden sie hierbei umgemodelt.

Nach Einschätzung von BT Diamond IP empfiehlt sich diese Vorgehensweise insbesondere dann, wenn ein Knoten, der nur IPv4 spricht, mit einem kommunizieren muss, der ausschließlich IPv6 versteht. Auch dabei gibt es verschiedene Vorgehensmöglichkeiten.

Stateless IP/ICMP Translation (SIIT) übersetzt Header von Paketen, die zwischen IPv4 und IPv6 ausgetauscht werden. Das zustandslose Übersetzen von IPv4/IPv6- und ICMPv4/ICMPv6-Paketen setzt eine dynamische Allokation von IPv4-Adressen voraus. Routing-header werden nicht übersetzt, es gibt aber Hop-by-Hop- und Destination-Optionen.

Dann gibt es noch Bump-in-the-Stack (BIS). Diese Technik erlaubt es einem Host, eine IPv4-Applikation zu nutzen, um über IPv6 zu kommunizieren. BIS horcht quasi den Datenfluss zwischen dem TCP/IPv4-Modul und den Link-Layer-Device ab, zum Beispiel einer Network-Interface-Karte (NIC).

Die nächste Möglichkeit wird mit Bump-in-the-API (BIA) bezeichnet. Die Technik modifiziert nicht die Header, sondern übersetzt zwischen den verschiedenen Application Programming Interface (APIs). So wird es ebenfalls möglich, IPv4-Applikatonen zu nutzen, die jedoch über IPv6 kommunizieren.

Eine vierte Alternative soll Network Address Translation mit Protocol Translation, kurz: (NAT-PT) bieten. Denn noch ist es nicht soweit. Das Verfahren, das IPv4- in IPv6-Adressen konvertiert, befindet sich noch im Experimentierstadium. Am ehesten vergleichbar sind die angestrebten Vorgänge mit den bekannten, unter Network Address Translation (NAT) zusammengefassten (siehe: Abbildung 4) Verfahren. Der Vollständigkeit halber sei hier noch das SOCKs IPv6/IPv4-Gateway sowie der Transport Relay Translator (TRT) erwähnt, die zwischen unabhängigen verbindungen vermitteln.

Anwendungsmigration

Die eigentliche Programmierschnittstelle für TCP/IP ist das „sockets“-Interface, das ursprünglich im BSD-Unix implementiert war. Dieses definiert Programmaufrufe für Applikationen, die per TCP/IP Schicht über IP-Netze kommunizieren müssen. Das „Winsock“-Interface von Microsoft fußt ebenfalls hierauf.

IPv6 verlangt nun Änderungen in beiden APIs, um die längeren Adressen aber auch zusätzliche Features handhaben zu können. Zu finden sind die Anpassungen etwa bei Microsoft XP SP1, Server 2003, Solaris 8, Linux-Kernel 2.4, MAC OS X.10.2, AIX 4.3 und HP-UX 11i. Die Erweiterungen beziehen sich jeweils auch auf alle nachfolgenden Releases.

Migrations-Szenarien

Nach Darstellung des BT-Diamond-IP-Whitepaper gibt es viele Wege für die Migration. Doch im Wesentlichen ergeben sich vier Alternativen (siehe: Abbildung 5).

Im ersten Fall wird das Backbone auf IPv6 umgestellt. Dazu sind Upgrades bei allen Routern notwendig. Für die Kommunikation im Kern müssen die Version 6 des Internet Protokolls unterstützen, zur Kommunikation in andere Netze außerdem IPv4.

Die lokal begrenzte, Server-seitige Migration erfordert hingegen Upgrades auf den Servern und Applikationen, die mit beiden Protokoll-Versionen kommunizieren können. Allerdings sind ausführliche Tests ratsam, etwa inwieweit die Upgrades die Clients betreffen. Außerdem könnte die Kommunikation mit IPv4-Netzen betroffen sein, die außerhalb der eigenen Organisation liegen.

Die Client-seitige Migration erfordert die Ausstattung mit IPv6-Applikationen, mit entsprechenden API- und TCP/IP-Stacks. Doch vielleicht setzt sich die Client- und Server-Migration durch, obwohl diese nicht die einfachste Art und Weise sein dürfte. Denn hier sind sowohl Dual-Stacks notwendig als auch Anpassungen in den Applikationen. „Ideal wäre, wenn beide Protokoll-Versionen unterstützt würden“, erläutert das Whitepaper, „doch das ist kaum praktikabel.“

(ID:2006513)