27.01.2011 | Redakteur: Andreas Donner
Auch wer sich bereits intensiv mit der IPv6-Einführung beschäftigt hat – und das sollten so langsam aber sicher alle IT-Verantwortlichen getan haben –, steht bei der praktischen IPv6-Einführung in der eigenen Umgebung oft vor individuellen Schwierigkeiten. Gezielte Informationen aus der Praxis können hier helfen.
Selbst wenn in der Theorie schon alles klar ist, treten bei der praktischen Umsetzung oft ungeahnte Probleme auf. Dies ist bei vielen IT-Projekten so, doch hinsichtlich des Umstiegs auf IPv6 muss das nicht sein. Denn der IPv6-Praxis-Tag der SearchNetworking-Akademie, den unser IPv6-Guru Benedikt Stockebrand am 18. Februar in Frankfurt am Main begleiten wird wartet mit praktischen Demonstrationen und einem intensiven Erfahrungsaustausch unter den Teilnehmern auf und gibt so Hilfe zur Selbsthilfe.
Bereits im Vorfeld zu dem hochinteressanten Praxistag hat SearchNetworking mit dem Referenten Benedikt Stockebrand gesprochen, um einige wichtige Migrationsfragen in Sachen IPv6 zu klären. Dazu zählen Fragen wie:
Stockebrand: Die Argumentation, dass man dank NAT kein IPv6 braucht, ist in mehrerer Hinsicht kurzsichtig. Sie unterstellt, dass auch in Zukunft Dienste, die man von externen Anbietern nutzt, per IPv4 zur Verfügung gestellt werden. Mindestens an der eigenen Schnittstelle zum Internet wird man sich also entweder selbst mit IPv6 beschäftigen oder seinen Internet Service Provider (ISP) oder sonstigen Dienstleister damit beauftragen müssen, eine entsprechende Umsetzung einzurichten.
Aber auch intern kann man nicht davon ausgehen, dass in Zukunft in allen Produkten, die man einsetzt, IPv4 unterstützt wird. Schon in Windows 7 gibt es mit Direct Access und Home Groups zwei Funktionalitäten, die IPv6 voraussetzen. Es ist also abzusehen, dass zukünftige Produkte ausschließlich IPv6 benutzen werden.
Schließlich sind die verschiedenen Tunnel-Mechanismen, insbesondere „Teredo“ und „6to4“, ein potenzielles Sicherheitsproblem, wenn man sich mit IPv6 nicht wenigstens bis zu dem Punkt beschäftigt hat, dass man weiß, wie man wirksam den Aufbau von unkontrollierten Tunneln verhindert.
Stockebrand: Für alle, die IPv6 im Rahmen ihrer Produkte anbieten, also Hard- und Software-Hersteller und vor allem ISPs. Einerseits ist hier Zeit durch nichts zu ersetzen, andererseits ist die Notlösung, in machen Bereichen eben doch zunächst noch IPv4 beizubehalten, in diesem Zusammenhang nicht anwendbar.
In „Benutzer“-Umgebungen, die ihre IT nicht als Produkt, sondern als Werkzeug ansehen, hängt es stark von der jeweiligen Umgebung ab. In Windows-orientierten Umgebungen kann man den Aufwand und die Dauer der IPv6-Einführung zumindest grob abschätzen, indem man sich an der letzten Einführung einer neuen Windows-Version orientiert – in beiden Fällen muss man seine gesamte Umgebung aber einmal daraufhin überprüfen, ob sie mit der neuen Technologie funktioniert. Wer für ein Windows-Upgrade einen Vorlauf von zwei Jahren braucht – was in großen Umgebungen nicht ungewöhnlich ist – sollte auch mit IPv6 schon 2009 angefangen haben.
Stockebrand: Das ist ein breites Spektrum, das stark von den jeweiligen Gesprächspartnern abhängt. Nicht- oder nur partiell technische Aspekte nehmen jedoch einen immer größeren Raum ein, angefangen von der Frage, welche Mitarbeiter wie weit geschult werden müssen – für mich naheliegenderweise ein wichtiges Thema – über Fragen zur Zeitplanung und Vorgehensweise bis hin zur Entscheidung, ob man Windows 7 vor, nach oder zusammen mit IPv6 einführen will.
Dazu kommt eine Fülle von Einzelfragen zur Netztopologie, welche Schritte einer Einführung man in welcher Reihenfolge macht und wie man mit mehr oder weniger einzelfallbezogenen Problemen am elegantesten umgeht.
Stockebrand: Das größte Problem ist, dass man relativ frühzeitig einige strategische Entscheidungen treffen muss, für die man eigentlich nicht die notwendige Erfahrung hat und die sich im Nachhinein nur aufwendig wieder rückgängig machen lassen.
Dazu kommen Lieferanten, die zwar IPv6-Fähigkeit zusagen, aber instabile Produkte oder unzuverlässige Dienstleistungen anbieten oder selbst mit ihren IPv6-Projekten in Verzug geraten.
Besonders problematisch wird es schließlich, wenn man sich aufgrund von Zeitdruck blind auf externe „Experten“ verlässt, deren Kompetenz man nicht zuverlässig einschätzen kann. Kombiniert man das noch mit akutem Zeitdruck, der es auch kompetenten Externen nicht mehr erlaubt, sich in die Besonderheiten einer Umgebung einzuarbeiten, wird IPv6 zu einem Glücksspiel.
»1 »2 »3 nächste Seite
Schöner Beitrag, wenn man mal aussläßt. das praltisch niemand IPv6 benutzt und es sich nicht...
lesen
Dieser Beitrag ist urheberrechtlich geschützt. Sie wollen ihn für Ihre Zwecke verwenden? Infos finden Sie unter www.mycontentfactory.de (ID: 2049403)
