IPv6-Migration (Teil 3)

Dies ist der 3. und vorerst letzte Teil meines Artikels über Migrations-Verfahren IPv4 zu IPv6. Ausgehend von der Studienarbeit von Tobias Brunner aus dem Jahr 2008, habe ich im ersten Teil über meine Motivation, dieses Thema zu beschreiben, geschrieben. Auch gab es eine Ausführung zum Thema Dual-Stack. In Teil 2 wurden verschiedene Tunneling-Verfahren vorgestellt. In diesem Artikel werden Translation-Verfahren den Schwerpunkt bilden. Danach möchte ich noch kurz einen Ausblick geben, wie es mit dem Thema IPv6 in diesem Blog weitergeht.

Translation-Verfahren

Basis Transition-Mechanismen IPv4 zu IPv6 und umgekehrt sind im RFC 4213 definiert.

• SIIT – Stateless IP/ICMP Translation Algorithm

[1] SIIT wird verwendet, um zwischen IPv4-only und IPv6-only Bereichen und zwischen ICMPv4 und ICMPv6 zu übersetzen. SIIT ist im RFC 2765 definiert und ersetzt NAT-PT (Networt Address Translation – Protocol Translation). [Anm.] Der RFC 2765 wurde 2011 vom RFC 6145 ersetzt. Die Übersetzung mit SIIT erfolgt zustandslos, d.h. unabhängig vom Zustand der Session.

[2] Die SIIT-Methode definiert eine Klasse von IPv6-Adressen, die IPv4-translated [IPv4-mapped] Adressen genannt werden. Das Präfix dieser Adressen ist ::ffff:0:0:0/96. Die Spezifikation ist ein Ergebnis der NGTRANS IETF working group.

• DNS64

[2] DNS64 beschreibt einen DNS-Server, der bei der Anfrage eines AAAA-Records nur einen A-Record findet, diesen in einen AAAA-Record umwandelt. DNS64 ist im RFC 6147 definiert.

• NAT-PT – Network Address Translation – Protocol Translation

[3] NAT-PT (RFC 2766) gilt mittlerweile als veraltet und wurde durch SIIT ersetzt.

Bei NAT-PT wird die Übersetzung durch einen dedizierten Rechner durchgeführt. Ein IPv6-Rechner adressiert einen IPv4-Rechner mittels Präfix::w.x.y.z. Alle Adressen mit diesem Präfix werden zur NAT-PT-Instanz (Translator) gesandt und dort bearbeitet. Gleichzeitig bedeutet dies, dass die Adresstranslation für jedes Paket gemacht werden muss. Dadurch kann es zu einer starken Belastung des Proxys kommen. Um hier Abhilfe zu schaffen, kann Load-Balancing zum Einsatz kommen.

Eine ausführliche Darstellung von NAT-PT ist bei Tomicky.net zu finden.

• Weitere Methoden

[1] Es existieren weitere Möglichkeiten, die jedoch nicht weit verbreitet sind bzw. auch schon wieder veraltet sind.

• 6over4 (RFC 2529): Wurde durch ISATAP ersetzt.
• TRT (Transport Relay Translation; RFC 3142), wurde in Zusammenhang mit NAT-PT eingesetzt
• ALG (Application Layer Gateway, RFC 2663)
• BItS (Bump in the Stack, RFC 2767); Hierbei erfolgt die Translation im Netzwerk-Stack
• SOCKS64 (RFC 3089); Eine Methode zur Übersetzung auf TCP-Ebene
• [2] 6rd -IPv6 rapid deployment– ist im RFC 5969 definiert.
• NAT64

Im Anschluss an die Aufzählung folgt ab S. 41 in der Studienarbeit von Tobias Brunner ein Vergleich der verschiedenen Migrationsmethoden. Hierbei wurden folgende Kriterien angesetzt:

• Zusammenspiel mit NAT
• Switch zu nativ IPv6
• Skalierbarkeit
• Unterstützung
• Ausfallsicherheit
• Arten der IPv6 Adressen

Am Ende der Arbeit gibt es noch eine Linksammlung und eine Übersicht über die RFCs.

Ausblick

Hiermit endet mein Bericht über meinen ersten Kontakt mit IPv6. Der Bericht ist zunächst einmal aus privatem Interesse entstanden, beruflich kann ich mich derzeit nur sporadisch weiter damit beschäftigen. Berufliche Erkenntnisse werde ich hier im Rahmen der Möglichkeiten mit einfließen lassen.

Teil 1 beschäftigt sich mit Dual-Stack.
Teil 2 beschäftigt sich mit Tunneling-Verfahren.

Quellen:

[1] Migration IPv4 auf IPv6, Studienarbeit von Tobias Brunner, 2008

[2] Wikipedia en IPv6 transition mechanism

[3] Proseminar: Next Generation Internet (IPv6), Migration IPv4 nach IPv6, Mateusz Podgórski, Uni Erlangen-Nürnberg 2003

[4] IT Administrator, IPv6-Übergangstechniken

[5] Computerpartner, Friedliche Koexistenz von IPv6 und IPv4

[6] Heise Netze: Teredo bohrt IPv6 Tunnel durch Firewalls

[7] crn.de: IPv6: Das Problem mit der Kompatibilität zu IPv4

IPv6-Migration (Teil 2)

Dies ist Teil 2 meines Artikels über Migrations-Verfahren IPv4 zu IPv6. Ausgehend von der Studienarbeit von Tobias Brunner aus dem Jahr 2008, habe ich im ersten Teil über meine Motivation, dieses Thema zu beschreiben, geschrieben. Den Start in das Thema bildeten Ausführungen zum Thema Dual Stack. In diesem Artikel werden Tunneling-Verfahren den Schwerpunkt bilden.

Tunneling-Verfahren

Es wurden verschiedene Tunnel-Verfahren entwickelt. Einige allerdings sind bereits schon nicht mehr aktuell bzw. haben keinen ausreichenden RFC-Status erreicht.

• ISATAP

[1] ISATAP (Intra-Site Automatic Tunnel Addressing Protocol; Wiki-Link) ist ein Tunneling-Verfahren welches eingesetzt wird, um die Kommunikation zwischen einem Dual-Stack-Host in einem IPv4-Netz und einem IPv6-Host (in einem IPv6-Netzwerk) sicher zu stellen. Hierzu wird ein IPv6-inIPv4-Tunnel zwischem dem DS-Host und einem ISATAP-Router aufgebaut. Auch hier werden spezielle IPv6-Adressen, so genannte ISATAP-Adressen, verwendet. Hinter diesem speziellen Präfix wird die jeweilige IPv4-Adresse angehängt.

Interessant ist, dass eine ISATAP Installation nicht zwingend eine IPv6 Infrastruktur benötigt. Damit können auch zwei DS-fähige Hosts über ein IPv4-Netzwerk end-to-end über eine IPv6-Adresse kommunizieren. Benötigt wird aber mindestens ein ISATAP-Router, der den Subnetz-Präfix zur automatischen Konfiguration der ISATAP-Adresse verteilt.

• Teredo

[1] Teredo wurde nach dem Schiffsbohrwurm, lat. Teredo Navalis, benannt. Es wird eingesetzt, um DS-fähige Hosts über das IPv4-Internet an das IPv6-Internet anzubinden. Hierbei können eine oder auch mehrere NAT-Instanzen überwunden werden. Dieses Verfahren ist nur als Übergangslösung während der IPv6-Migration gedacht.

Teredo ermöglicht einen automatischen IPv6-in-IPv4-Tunnel zwischen Hosts. Dabei wird der IPv6-Payload als IPv4 UDP Datagram verschickt. Auch hier kommt ein spezieller Präfix zum Einsatz, 2001::/32. Die Definition erfolgt im RFC 4380.

Zu Beginn der Kommunikation muss der Teredo-Client (DS-Host) sich mit dem Teredo-Server verbinden. Es wird der Adresspräfix festgestellt und auch die Art des NATs. Sobald die Teredo-Verbindung aufgebaut wurde, muss durch den regelmäßigen Austausch von Paketen (Teredo Bubble Pakete) sichergestellt werden, dass die dazwischenliegende Firewall die Portzuordnung nicht wieder löscht. Die Kommunikation zum IPv6-Internet erfolgt über das Teredo Relay. Die Komponenten Teredo Server und Teredo Relay befinden sich zwischen dem IPv4-Internet und dem IPv6-Internet.

[6] Beispiele zur Einrichtung von Teredo auf Windows, Linux, BSD und OS X sind in einem Artikel von Heise Netze „Teredo bohrt IPv6-Tunnel durch Firewalls“ (2009) zu finden.

[6] Microsoft bezeichnet seine Tunneltechnik selbst als letzten Ausweg, da Teredo-Verbindungen im Netzwerk viel Aufwand verursachen, sind vergleichsweise uneffektiv und nicht besonders stabil. Eine ausführliche Darstellung Teredos von Microsoft ist im Technet (2004) zu finden. Bis Windows XP konnten Teredo-Clients nicht mit jedem symmetrischen NAT umgehen, bei neueren Windows-Systemen ist dieses Problem beseitigt. Somit kann Teredo mittlerweile in allen NAT-Umgebungen eingesetzt werden.

Teredo benutzt den UDP-Port 3544. Um daher Teredo auf einem Rechner zu blockieren, genügt es, diesen Port einfach zu sperren.

• IPv6-in-IPv4 Tunnel

[1] IPv6-in-IPv4 Tunnel werden auch als 6in4 bezeichnet. Hierbei unterscheidet man zwischen manuellen [konfigurierten] und automatischen Tunneln. [3] Beim automatischen Tunneln werden im IPv6 IPv4-kompatible Adressen verwendet. Hierbei werden die ersten 12 Bytes der IPv4-Adresse vorangestellt und mit Nullen aufgefüllt.

[1] Wird das IPv6 Paket direkt hinter dem IPv4-Header angehängt, so muss der IPv4 Header im Protokoll den Wert 41 (IPv6) enthalten. Diese Tunnels werden auch „protocoll 41-“ oder „proto-41-“ Tunnel genannt. Wichtig, dies müssen alle Router auf dem Weg zwischen den Endpunkten verstehen. Da dies nicht in allen Komponenten integriert ist, wurden weitere Methoden entwickelt. Eine Methode lautet z.B. AYIYA (Anything in Anything), hierbei wird das IPv6-Paket erst hinter dem UDP-Header angehängt. AYIYA ist keine Methode sondern ein Protokoll, RFC 4891, welches sich im Status „Informational“ befindet.

 

• 6to4

[1] Diese Methode wird bei der Vernetzung von IPv6-Sites über ein IPv4-Transitnetz verwendet. Hierbei kommen spezielle IPv6 Adressen zum Einsatz. Der 6to4-Router generiert einen IPv6-Präfix, der die IPv4-Adresse beinhaltet. Dieser Präfix wird nun an die Hosts propagiert. Die Hosts ihrerseits hängen an diesen Präfix noch ihre MAC-Adresse an. Dieses Verfahren ist nicht NAT-fähig.

• IPv4-mapped IPv6 Address

[1] Diese Adressen sind im RFC 2373 definiert. Hierbei wird nur ein IP-Socket verwendet. Allerdings ist diese Methode nicht in allen Sockets implementiert und kann auch nicht flächendeckend eingesetzt werden.

• DSTM (Dual-Stack Transition Mechanism)

[1] DSTM wird für die IPv4-Kommunikation in einem IPv6-Netzwerk verwendet. Hierbei werden IPv4-Pakete als Payload in ein IPv6-Paket eingebettet. Daher wird dieses Verfahren auch als 4in6 oder IPv4-in-IPv6-Tunnel bezeichnet. Für die Kommunikation ist noch ein DSTM-Server notwendig. Möchte ein IPv6-Host mit einem IPv4-Host kommunizieren, so muss er beim DSTM-Server zuvor eine temporäre IPv4-Adresse anfordern. Derzeit existiert kein RFC hierzu.

• DS Lite

[7] Dual-Stack Lite (DS-Lite) ist ein weiterer Tunnelmechanismus, der in der Übergangsphase IPv4 zu IPv6 eingesetzt werden kann. Hierbei wird ein spezielles Home-Gateway benötigt. Die IPv4-Pakete werden dann über einen IPv6-Tunnel zum NAT-Translator des ISP übermittelt und weiter über den IPv6-Backbone transportiert.

• Tunnel Broker (TB)

[1] Dies ist ein Verfahren, um einen Host über das IPv4-Internet an das IPv6-Internet anzubinden. Der Host muss hierbei Dual-Stack-fähig sein.

Teil 1 beschäftigt sich mit Dual-Stack.
Teil 3 beschäftigt sich mit Translation-Verfahren.

Quellen:

[1] Migration IPv4 auf IPv6, Studienarbeit von Tobias Brunner, 2008

[2] Wikipedia en IPv6 transition mechanism

[3] Proseminar: Next Generation Internet (IPv6), Migration IPv4 nach IPv6, Mateusz Podgórski, Uni Erlangen-Nürnberg 2003

[4] IT Administrator, IPv6-Übergangstechniken

[5] Computerpartner, Friedliche Koexistenz von IPv6 und IPv4

[6] Heise Netze: Teredo bohrt IPv6 Tunnel durch Firewalls

[7] crn.de: IPv6: Das Problem mit der Kompatibilität zu IPv4

IPv6-Migration (Teil 1)

In den vergangenen Wochen habe ich mich beruflich mit dem Thema IPv6 (Wiki-Link Deutsch und Englisch) und Migrationsstrategien auseinandersetzen dürfen. Zuerst stand daher die Recherche im Internet an, die aufgrund der Vielzahl an vorhandenen Links sicherlich nicht vollständig ist.

Bei der Recherche habe ich eine Studienarbeit von Tobias Brunner aus dem Jahr 2008 gefunden. Da diese mir gut gefallen hat, möchte ich ausgehend hiervon diesen Artikel aufbauen und mit anderen Quellen ergänzen. Hierbei möchte ich mich auf die Migration auf IPv6 konzentrieren und die vorhandenen Methoden hierzu kurz darstellen.

Da die ganze Thematik einen zu langen Blog-Eintrag zur Folge hätte, habe ich mich entschieden, diesen in drei Teile aufzuteilen. Im ersten Teil möchte ich einleitend das Thema Dual-Stack darstellen.

Auf eine Darstellung des grundlegenden Aufbaus von IPv6-Adressen, die verschiedenen Typen und den allgemeinen Protokollaufbau an sich möchte ich hier verzichten. Hierzu gibt es viele gute Quellen, u.a. auch die bereits erwähnte Studienarbeit.

Einleitung

Bei einer Migration von IPv4 nach IPv6 müssen drei grundlegende Verfahren betrachtet werden:

• Dual-Stack (DS)
• Tunneling-Verfahren
• Translation-Verfahren

[4] Die nachfolgend dargestellten Verfahren sind Übergangstechnologien.  Dies ist sowohl zeitlich, als auch im Sinne von Übersetzen zu sehen.

[5] IPv6 ist nicht abwärts-kompatibel zu IPv4. Es werden daher beide Netzwerk-Standards über einen längeren Zeitraum parallel existieren müssen. Keiner der nachfolgenden zur Migration zur Verfügung stehenden Möglichkeiten ist perfekt. Dies bedeutet auch, dass die Migration vorab in einem Testszenario ausführlich geprüft werden muss. Die technischen Grundlagen für die Migrationskonzepte wurden im RFC 4213 (Basic Transition Mechanisms for IPv6 Hosts und Routers) beschrieben.

[1] Neben den Übergangstechnologien erfordert ein Umstieg auf IPv6 die Anpassung der DNS-Struktur. Es ist wichtig, dass für beide Protokolle IPv4 und IPv6 die entsprechenden Einträge gemacht sind. Welches Protokoll, IPv4 oder IPv6, verwendet wird, wird durch das jeweilige Betriebssystem entschieden. Die entsprechenden Regeln sind im RFC 3484 definiert. Windows z.B. bevorzugt die IPv6-Kommunikation.

Dual-Stack

[5] Dual-Stack wird von vielen Herstellern unterstützt. Hierbei werden zwei IP-Stacks parallel auf einem Gerät betrieben. Die bevorzugte Adresse ist die IPv6-Adresse. Probleme können sich daraus ergeben, dass noch ältere Netzwerk-Hardware in Betrieb ist, die kein IPv6 unterstützen. Eine Lösungsmöglichkeit ist ein Dual-Stack-Application-Level-Gateway (DS-ALG). Dieses Gateway wird als Proxy genutzt und übersetzt in das jeweils andere Protokoll. Nachteilig ist hier, dass dies nur für bestimmte Anwendungen funktioniert und außerdem verlangsamen Proxys i.d.R. den Datenfluss.

Teil 2 beschäftigt sich mit Tunneling-Verfahren.
Teil 3 beschäftigt sich mit Translation-Verfahren.

 

Quellen:

[1] Migration IPv4 auf IPv6, Studienarbeit von Tobias Brunner, 2008

[2] Wikipedia en IPv6 transition mechanism

[3] Proseminar: Next Generation Internet (IPv6), Migration IPv4 nach IPv6, Mateusz Podgórski, Uni Erlangen-Nürnberg 2003

[4] IT Administrator, IPv6-Übergangstechniken

[5] Computerpartner, Friedliche Koexistenz von IPv6 und IPv4

[6] Heise Netze: Teredo bohrt IPv6 Tunnel durch Firewalls

[7] crn.de: IPv6: Das Problem mit der Kompatibilität zu IPv4

IPv6 im Google-Intranet

Diese Woche gab es bei Heise.de einen spannenden Bericht über die Einführung von IPv6 bei Google in deren eigenem Firmennetzwerk. Es wird hier über die Vorgehensweise, die entstandenen Lösungen und die dabei entstandenen Probleme berichtet.

Neben diversen technischen Herausforderungen liegt das größte Problem in den Layer 7-9, Ressourcen, die Lieferantenbeziehung und „organizational buy-in“ (Was ist das?). Dabei zeigt sich, dass nicht immer etwas unterstützt wird, nur weil erklärt wird, dass es unterstützt wird. Aus diesem Grund musste jedes noch so kleinste Detail getestet werden, um die Funktion zu gewährleisten.

Es ist daher naiv zu denken, dass derzeit IPv6 bereits ein Selbstläufer ist. Hier ist man immer noch in der Testphase. Das Know-How für eine Migration von IPv4 und IPv6 ist auch nicht weit verbreitet. Um daher eine Migration durchzuführen, sollte auch Zeit mitgebracht werden.

Hier noch der Link zur passenden Präsentation von Kiran Kumar Chittimaneni (Senior Network Engineer bei Google).

Und ein weiterer Artikel zum gleichen Thema bei Tech The Future, mit einen zwar kleinen, aber nicht minder beindruckendem Schaubild über die durchgeführten Rollout Test-Cases.