Worauf IT-Spezialisten bei IPv6 achten sollten

Das Internet in der derzeitigen Nutzungsform stößt längst an seine Grenzen. Adressknappheit, Routing in der Default Zone, aber auch steigende Anforderungen an Mobilität sowie Broadcast und Multicast sind die derzeit am heftigsten diskutierten Stichworte. Unter Adressknappheit sind global geroutete IPv4-Adressen gemeint, die sich durch statische und dynamische Zuteilung unterscheiden.

An einem sicheren Fundament, das die Umstellung planbar macht, fehlt es bislang jedoch. Der Einsatz von Network Address Translation (NAT) brachte etwa bislang nur eine Teillösung für dieses komplexe Problem hervor. Als Treiber für die Adressknappheit wirkt vor allem die zunehmende Präsenz von Web 2.0-Plattformen und Technologien im Mitmachnetz. Innovative Produkte bewirken einen zusätzlichen Adressbedarf.

Infolgedessen lassen sich aus betrieblicher Sicht einzelne Subnetze nur noch schwer bzw. ineffizient routen und betreiben. Als Folgen der Adressknappheit sehen Experten eine schleichende Destabilisierung des Internets heraufziehen, mit einer damit verbundenen Ineffizienz und steigenden Kosten, bis hin zur wirtschaftlichen Untragbarkeit. Jedoch haben sich die großen Schreckenszenarien bislang nicht bewahrheitet, auch die angeblich ausgehende Adresslandschaft ist bislang kein schlagendes Argument. Allenfalls dürfte sich in den nächsten Jahren für begehrte Adressen eine Art "Graumarkt" bilden.

In Österreich widmet sich bei der Telekom Austria seit Jahren ein spezielles Expertenteam der komplexen Herausforderung. Für den wichtigsten heimischen Internet-Knotenpunkt, den Vienna Internet eXchange (VIX) vom zentralen Informatikdienst der Universität Wien, habe Telekom Austria bereits 2001 eine native IPv6-Anbindung realisiert, erläutert DI Helmut Leopold, Leiter Plattform- und Technologiemanagement Telekom Austria TA AG sowie Präsident der Österreichischen IPv6 Task Force.

Zum Beginn des Jahres 2005 setzten die Spezialisten für den VIX schließlich den Dualstack-Betrieb um, was bedeutet, dass auch die Verbindungsvereinbarungen für den IPv6-basierten Datenverkehr ebenso gültig sind wie für den Vorläufer IPv4. Grundsätzlich sei die Infrastruktur von Telekom Austria damit "IPv6-ready", bilanziert Leopold, denn alle Voraussetzungen für den Einsatz von IPv6 seien von Seiten der Telekom Austria damit realisiert.

Doch ist die Realisierung der technischen Rahmenbedingungen aus Sicht der Unternehmen und Endanwender nur die eine Seite der Medaille, das weiß auch Helmut Leopold. "Die IPv6-Thematik ist bei den Endkunden noch nicht angekommen", gibt der Experte zu bedenken. Im Privatkundenbereich tendiere die Nachfrage sogar nahezu gegen Null.

Im Klartext: Die IPv6-Implementationen in den gängigen Betriebsystemen und Webbrowsern ist zwar möglich. Woran es jedoch mangelt, sind die für Privatnutzer interessanten Applikationen, um dem Ganzen von der Nachfrageseite her eine stärkere Dynamik zu verleihen. Im Geschäftskundenbereich sieht es kaum besser aus. Das Interesse sei darauf fokussiert, bei anstehenden IT-Investitionen zunächst einmal "IPv6-sicher" zu sein, so Helmut Leopold weiter.

Vorteile müssen erst greifbar werden

In der Praxis scheuen nicht nur die IT-Spezialisten die aufwändige technische und organisatorische Abstimmung. So bedeutet etwa Routing in der Default Free Zone, dass für jedes IP-Paket auf jedem Router in einer Routing-Tabelle nachgesehen werden muss, an welchen Router dieses als nächstes weitergeleitet werden muss. Dadurch entsteht ein aufwändiger Routing-Prozess, den auch die Netzwerkspezialisten und Admins kaum überblicken können, nach der sie etwa die Beziehungsgrößen Router, Pakete und Größe der Routing-Tabelle sinnvoll kalkulieren können.

Eine weitere kritische Hürde liegt in dem Aspekt der Quality of Service (Qos) und dem Traffic Shaping. Der Versuch, die Eigenschaften von Telefonie-Netzen nachzubilden, kann misslingen, weil dieser mit dem grundlegenden Design des TCP/IP-Stacks nicht wirklich vereinbar und nicht skalierbar ist. Auch beim Traffic Shaping kann die reibungslose Integration in den TCP/IP-Stack scheitern, stellt aber dennoch einen pragmatischen Ansatz dar, der in vielen Fällen das gewünschte Ziel erreicht. Andererseits kann dieser jedoch bereits bei IPv4 verfügbar sein.

Zukunftssicherheit spielt IPv6 in die Hände

Deshalb kommen die Entscheider im Unternehmen kaum darum herum, sich bereits jetzt mit den Untiefen von IPv6 zu befassen. Compliance und andere Regelungsnachweise bzw. gesetzliche Auflagen erfordern nämlich eine "wasserdichte und revisionssichere IT". Das bedeutet, der technische Treiber in Richtung einer kompletten Umstellung liegt in der Robustheit und Zukunftssicherheit der Infrastruktur.

Sprich: Der vereinfachte Aufbau erhöht prinzipiell die Robustheit in der Anwendungslandschaft. Doch auch hier gibt es einige klein gedruckte Punkte zu berücksichtigen. So könnten Tunnel-Mechanismen als neuer Angriffsvektor missbraucht werden, was das gesamte Risiko bei der Einführung deutlich erhöhen könnte. Nach wie vor bleibt also das Terrain aus technischer Sichtweise bei der Implementierung bzw. Migration - selbst bei einer schrittweisen Einführung - mit erheblichen Risiken und Nebenwirkungen behaftet.

Deshalb gilt es zunächst einmal, die spannenden Anwendungsgebiete und Business-Szenarien zu identifizieren und deren Lösungsbeitrag aus Sicht einer verbesserten IT-Infrastruktur heraus zu streichen. Bei den Unternehmen sind es in der Regel strategische Überlegungen, die eigene IT zukunftsfester zu machen. Oftmals treiben aber auch die Kunden in einem weltweit verzweigten Kommunikations- und Geschäftskonglomerat eine derartige Umstellung voran.

Folgende Fragen sind relevant: Welche eingesetzten Produkte müssen gegebenenfalls um IPv6 erweitert werden? Sind die eingesetzten Produkte überhaupt IPv6-fähig? Sind parallele Umgebungen oder eine Dual-Stack-Umgebung sinnvoll? Welche topologischen Änderungen ergeben sich dadurch im gesamten IT-System?

Ein pauschales Regelwerk für Unternehmen gibt es anhand dieser Fragen kaum. Viele grundsätzliche Fragen lassen sich nur im Einzelfall klären. Die drei grundlegenden Deployment-Varianten im Überblick - unter Deployment ist dabei die Bereitstellung von IPv6-Unterstützung unabhängig von IPv4 zu verstehen:

• IPv6 Only Deployment: Setzt uneingeschränkten IPv6-Support voraus; vermeidet von Anfang an Altlasten; als Projekt schwierig umzusetzen; in den allermeisten Fällen sogar unrealistisch.
• Dual-Stack-Deployment: Minimale Zusatzkosten bei Migration und späterem Betrieb; wenig Spielraum für Deployment-Team, um riskante Schritte zu vermeiden; relativ hohes Risiko, den parallelen IPv4-Betrieb zu stören; Risiko, dass System Altlasten aus der IPv4-Topologie nach IPv6 überträgt.
• Paralleles Deployment: Riskante Schritte betreffen weitgehend die IPv6-Seite; deutlich reduziertes Risiko, IPv4-Betrieb zu stören; erleichtert die Auflösung von IPv4-Altlasten; höhere Zusatzkosten bei der Migration und dem späteren Betrieb.

Ergänzend dazu unterscheidet die folgende Variante einer kompletten Migration zwei Varianten, eine "harte" und eine "sanfte" Migration.

• Harte Migration: Umstellung von IPv4-Only nach IPv6 Only ohne den Zeitweisen Parallelbetrieb; riskante Variante, da erhebliche Auswirkungen auf den Produktivbetrieb; im Allgemeinen nur für einzelne Schritte sinnvoll; für Detailschritte gelegentlich unvermeidbar.
• Sanfte Migration: Umstellung von IPv4-Only auf Parallelbetrieb auf IPv6-Only; deutlich risikoärmere Variante mit minimalen Auswirkungen auf Produktionsbetrieb möglich.

Empfehlung: Bei der Einführung in möglichst vielen kleinen Schritten vorgehen und einen zusätzlichen Hardware-Pool bereitstellen. Denn der latente Zeitdruck erhöht die Kosten und das Risiko eines Fehlschlags ganz enorm. Die Politik der kleinen aber feinen Schritte besteht also zunächst darin, parallel agierende Maschinen aus dem Hardware-Pool aufzubauen.

Ist der vorläufige IPv6-Betrieb eingerichtet, gilt es den Prozess durch ein fortlaufendes Monitoring zu ergänzen und dabei Funktions-, Stabilitäts- und Performance-Test durchzuführen, beziehungsweise erst bei einer erfolg versprechenden Gesamtperspektive auf "normalen" Hardwarebetrieb umzusatteln. Wenn machbar und sinnvoll, dann kann man IPv4 abschalten, ansonsten ist es besser, die Parallelinstallation beizubehalten.