Migration zu IP Version 6

IPv6 - ein Y2K-Projekt?

7. Dezember 2011, 7:00 Uhr | Markus Nispel/wg, Chief Technology Strategist bei Enterasys,

Die Verknappung des freien IPv4-Addressbereichs wurde schon ausführlich diskutiert und der Tag prognostiziert, an dem die letzte Adresse vergeben sein würde. Die rasante Verbreitung IP-basierter Endgeräte wie Smartphones, Tablets und Co., aber auch die Konergenz zum All-IP-Netz treiben die Nutzung von Adressen ebenfalls nach oben. Es scheint, dass es Zeit ist für IPv6.Immer noch lässt sich der drohende Engpass effizient mit existierenden Workarounds wie Network Address Translation (NAT) und Classless Inter-Domain Routing (CIDR) in Verbindung mit privaten IPv4-Adressbereichen vermeiden. Nichtsdestoweniger haben IETF, RIPE NCC und IANA den Exodus für die zweite Jahreshälfe 2011 beziehungsweise für das Frühjahr 2012 vorhergesagt. Bei den Internet-Service-Providern kann man daher die IPv6-Migration und die parallele Bereitstellung von IPv4- und IPv6-Adressen als abgeschlossen ansehen. Was aber ist mit den Unternehmensnetzen? Hier ist die Anzahl der ganzflächigen IPv6-Netze gelinde gesagt "übersichtlich". Im Bereich der Forschung und Lehre sind sie zumindest punktuell vorhanden. Woran liegt dies? Es ist wohl eine Kombination aus Business- und Technikaspekten, die hier zum Tragen kommen.

Wo ist der Business-Case für IPv6 und kann dieser entsprechende Risiken auf der Technik- wie auf der Kostenseite rechtfertigen? Denn Kosten entstehen nicht nur durch die eventuell anstehenden Investitionen in Hardware, sondern auch durch Änderungen bei Software, Betriebssystemen, Verfahren, Betrieb und so weiter. IPv6 bringt neben dem massiv erweiterten Addressbereich folgende Vorteile:

einen neuen Mechanismus für das Discovery von Systemen wie Router im Netz,

vereinfachte und kleinere Routing-Tabellen,

Vereinfachung des IP Headers,

optimiertes Multicast-/Broadcast-Management,

vereinfachte Konfiguration des Endgeräts,

Mobility Support und

integrierte Sicherheit.

Der Adressbereich selbst erweitert sich von 32-Bit-IPv4-Adressen auf 128-Bit-IPv6-Adressen. Dies entspricht einer Erhöhung auf 3,40 × 1038 IPv6-Adressen verglichen mit 4,29 × 109 Adressen in IPv4.

Vom Business Case zur Umsetzung

Hat man einen entsprechenden Business Case gefunden, kann es losgehen. Aber wie? Zunächst einmal sollte man sich organisatorisch entsprechend aufstellen und ein Projektteam ins Leben rufen. Dies kümmert sich um die Projektsteuerung, Kommunikation, Awareness etc. Denn die Folgen sind weitreichend.

Zur technischen Migration ist zunächst eine Inventarisierung aller potenziell betroffenen Systeme zu erstellen - Y2K lässt grüßen. Dazu gehört natürlich die Planung des aktuellen und zukünftigen Bedarfs an Adressen, aber auch die Erfassung von Netzwerkkomponenten (Switches, Router), Sicherheitskomponenten (Firewall, IDS, URL-Filter), Netzwerk-Services (DHCP, DNS, Load Balancing), Netzwerk-Management (Event?, Performance?, Configuration-Management), Betriebsysteme, Applikationen (Datenbankstrukturen, User Interfaces) und alle sonstigen IP-Endgeräte wie VoIP Phones, IP Video, Drucker und andere mehr. Hier ist es nicht ohne Weiteres möglich, schnell und komplett auf IPv6 zu migrieren. Gerade bei selbstentwickelten Applikationen kann es zu einigem Aufwand kommen, wenn die Analyse der IPv6-Fähigkeit Probleme zeigt. Auch bei der Verwendung von Netzwerkprotokollen wie ICMP, FTP, SIP/H.323, DNS, Peer-to-Peer- und IM-Protokollen ist Vorsicht geboten, da diese Protokolle IP-Addressen auf der Applikationsebene verwenden und damit anfällig für NAT-Probleme sind.

Die nun nachfolgende Designphase für IPv6 sollte sicherstellen, dass entsprechende Parität in den Funktionen mit dem bestehenden IPv4-Netzwerk vorhanden sein wird. Auf die Verwendung von Standards ist hier zu achten. Bei der Erstellung des IPv6-Adressierungsplans zu berücksichtigen sind Aspekte wie die Anforderungen durch das Wachstum der Endgerätezahl, die Zahl neuer Netzwerkkomponenten und neue Lokationen. Die Zuweisung sollte dann in einer Art und Weise erfolgen, die ein effizientes Routing der Netze ermöglicht. Hier ist auch zu entscheiden, ob man ein Provider Independent (PI) oder ein Provider Aggregatable (PA) Prefix beantragen und nutzen soll und ob man eine zustandslose Endgerätekonfiguration (Stateless Address Auto Configuration, SLAAC) oder DHCP in Erwägung zieht. Heute kommt überwiegend DCHPv6 zum Einsatz, da dieses höhere Flexibilität und mehr Funktionen bietet. Die Routing- und ISP-Peering-Konfiguration will wie in einer IPv4-Umgebung geplant sein.

Migration von IPv4 auf IPv6

Die eigentliche Migration von einem IPv4- auf ein IPv6-Netz kann unterschiedliche Mechanismen erfolgen, die im Rahmen der Standardisierung von IPv6 beschrieben sind. Im Groben sind dies Translation, Tunneling und Dual-Stack, wobei heute in den meisten Unternehmensnetzwerken die Dual-Stack-Migration empfohlen wird. Tunneling sollte nur bei entsprechenden Herausforderungen durch größere IPv4-Inseln im Kern des Netzes Verwendung finden. Translation ist nicht vollständig standardisiert und bringt mit NAT genau die Komplexität zurück, die man durch IPv6 eliminieren wollte. Nach einer vollständigen IPv6-Migration ist NAT sowieso nicht mehr nötig. Ein Überblick über die NAT-Methoden:

NAT-PT (Historical Status, nicht weiter empfohlen),

NAPT-PT (Historical Status, nicht weiter empfohlen),

SIIT (RFC2765, bald obsolet durch draft-ietf-behave-v6v4-xlate-23) sowie

NAT64.

Hier gibt es immer noch viel Bewegung und damit keine klare und langfristig gesicherte Lösung für diese Art der Migration.

Tunneling kommt meist dann zum Einsatz, wenn IPv6-Netze über eine existierende IPv4-Infrastruktur zu verbinden sind. Der Tunnel Header sieht dann aus wie in Bild 1 dargestellt.

Folgende Einsatzszenarien für 6in4-Tunnel sind typisch:

Router-to-Router: Ein Router öffnet einen IPv4-Tunnel, um IPv6-Verkehr zwischen zwei IPv6-Inseln über einen existierenden IPv4-Backbone zu übertragen.

Host-to-Router: Ein Dual-Stack IPv6/IPv4-Host, der in einer IPv4-Insel angeschlossen ist, tunnelt den Verkehr zu einem Router, der die Verbindung in einer IPv6-Umgebung realisiert.

Host-to-Host: Zwei Dual-Stack-IPv6/IPv4-Hosts kommunizieren über eine IPv4-Infrastruktur mittels IPv6.

Router-to-Host: Umgekehrt zum Host-to-Router-Szenario kann ein Router über eine IPv4-Infrastruktur einen Dual-Stack-Host erreichen.

Die Konfiguration der Tunnel erfolgt typischerweise durch eine statische Konfiguration.

Der Dual-Stack-Ansatz bedingt es, dass jeder Router und jeder Host sowohl eine IPv4- als auch eine IPv6-Adresse haben. Im Laufe der Zeit werden dann alle Dienste über IPv6 erreichbar sein und der IPv4-Stack kann abgeschaltet werden. Man ahnt schon, dass dies einige Jahre in Anspruch nehmen wird. Im Kern der Migration steht hier DNS. Die Adressen sind für IPv4-Hosts als "A Records" und als "AAAA Records" für IPv6-Hosts hinterlegt. Die Pointer Records (PTR Records) in der IN-ADDR.ARPA-Domain für IPv4-Hosts werden umgesetzt auf PTR Records in der IP6.ARPA-Domain für IPv6-Hosts. Die DNS-Infrastruktur ist entsprechend anzupassen - dies stellt einen sehr wichtigen Schritt in der Migration dar. Dadurch lässt sich jeder existierende IPv4-Host jederzeit auf IPv6 hochrüsten, unabhängig von allen anderen Hosts oder Routern im Netz. Sie können, falls erwünscht, auch weiterhin ihre IPv4-Adresse nutzen. Neue Hosts mit reinem IPv6-Support kann der Administrator dann ebenfalls jederzeit hinzufügen.

Typischerweise sind die ersten Komponenten, die man auf Dual-Stack migriert, die Backbone-Router und -Switches. Dann stehen die Server und Netzwerk-Services wie DHCPv6 und DNSv6 an, bevor man die Hosts damit ausstattet. Parallel dazu sind Anpassungen der Firewall-Konfiguration notwendig, eventuell auch weitere Schritte, um die Migration mit dem jeweiligen ISP zu realisieren.

Der Host an sich wird dann IPv4- oder IPv6-Protokolle abhängig von folgenden Faktoren nutzen:

IPv4 kommt zum Einsatz, wenn die Zieladresse, die von der Applikation genutzt wird, auch eine IPv4-Adresse ist.

IPv6 kommt zum Einsatz, wenn die Zieladresse, die von der Applikation genutzt wird, auch eine IPv6-Adresse ist.

Eine IPv6-Adresse kommt in einem IPv4-Tunnel zum Einsatz, wenn die Zieladresse, die von der Applikation genutzt wird, eine IPv6-Adresse mit einer integrierten IPv4-Adresse ist.

Die Dual-Stack-Implementierung im Betriebssystem ist fundamental für die Migration von IPv4 zu IPv6. Die IPv4- und IPv6-Protokoll-Stacks sind entweder unabhängig oder in einer Hybrid-Form implementiert. Diese ist heute meist in den Betriebssystemen umgesetzt. Dual-Stack Hosts sind beschrieben im IETF RFC 4213.

Es gibt heute eine Reihe von Betriebssystemen mit Dual-Stack Support: Windows XP SP1 und neuer, Windows Server 2003, Windows Vista, Windows Server 2008, Windows 7, Mac OS X 10.2 (Jaguar) und neuer, Linux Kernel 2.4 und neuer oder FreeBSD 4.5 und neuer. Eine komplette Liste findet sich unter en.wikipedia.org/wiki/Comparison_of_IPv6_support_in_operating_systems.

Fazit

Die vollständige Migration einer existierenden IPv4- zu einer IPv6-Infrastruktur ist eine der größten Herausforderungen für die IT-Organisation eines Unternehmens in den nächsten Jahren. Und dies hängt nicht mit der Komplexität der Technik selbst, sondern mit den weitreichenden Verbindungen des IP-Protokolls in der gesamten IT-Infrastruktur zusammen. Damit wird die Migration zu einem bereichsübergreifenden Projekt. Überall im Unternehmen kann ein Gerät von der Migration betroffen sein. Eine sehr sorgfältige Planung und eine phasenweise Implementierung ist immens wichtig.

Bild 6. Logischer Aufbau einer Dual-Stack-Konfiguration. Bild: Enterasys

Bild 5. Router-zu-Host-Tunneling. Bilder: Enterasys

Bild 4. Tunneling von Host-zu-Host-Verbindungen.

Bild 3. Tunneling von Host-zu-Router-Verbindungen.

Bild 2. Tunneling von Router-zu -Router-Verbindungen.

Bild 1. Kapselung von IPv6 in IPv4 (6in4 Encapsulation). Bild: Enterasys
LANline.

Lesen Sie mehr zum Thema


Jetzt kostenfreie Newsletter bestellen!

Weitere Artikel zu Inocent Kessler GmbH

Weitere Artikel zu NOKIA GmbH

Weitere Artikel zu LG Electronics Deutschland GmbH

Matchmaker+