13 Umstellung auf das neue Protokoll

Transkript

1 Umstellung auf das neue Protokoll Eine Umstellung auf ein neues Protokoll bedeutet für jeden Netzwerkverwalter eine Bedrohung. Die Notwendigkeit einer Netzabschaltung und die Gefahr von Störungen und Betriebsunterbrechungen während der Einführung neuer Techniken wirkt auf große Netze wie ein Horrorszenario. Bei der Einführung von IPv6 hat man sich deswegen sehr viele Gedanken über eine langsame Migration gemacht. Innerhalb der IETF wurde eine eigene Arbeitsgruppe (NGTRANS Next Generation Transit) mit der Aufgabe betraut, verschiedene Modelle für den Übergang und die Einführung auszuarbeiten und in ihren Vor- und Nachteilen darzustellen. Vorsichtige Migration NGTRANS 13.1 Grundsätzliches Vorgehen Von Anfang an war klar, dass beide Standards für viele Jahre parallel nebeneinander im Netz existieren werden. Es wurden dann Mittel und Wege gesucht, wie beide Welten nicht nur nebeneinander ohne gegenseitige Störung existieren, sondern auch miteinander erfolgreich kommunizieren können. Neben dem Abschotten des eigenen Netzes durch eine Firewall oder ein Gateway, das dann als einziger Punkt mit den neuen Protokollen in Berührung kommt, wurde im Rahmen der Standardisierung eine Reihe von Mechanismen und Verfahren diskutiert und festgelegt, mit denen der Übergang und das parallele Arbeiten ermöglicht werden soll: Die erste Variante schlägt vor, entsprechende Endgeräte mit beiden Versionen von IP gleichzeitig auszustatten. Als zweiter Ansatz gilt die Verwendung von Tunneln, mit denen IPv6 in IPv4 eingepackt und so über existierende Netze transportiert werden kann. Langfristiges Miteinander Übergang und paralleles Arbeiten

2 Umstellung auf das neue Protokoll Als Ergänzung dazu dient die Definition von umgekehrten Tunneln, bei denen IPv4-Pakete innerhalb von reinen IPv6-Strecken übertragen werden können. Zusätzlich wurde immer wieder die Verwendung von automatisch umsetzenden Gateways angesprochen, wobei lange Zeit deren Einsatzbereich stark umstritten war. Für die heute im Produktionsbetrieb befindlichen Netze lassen sich damit Sanfte Migration durch sanfte Wege zur Migration finden. Entstehende IPv6-Inseln können durch Tunnel Gateways in IPv4-Netze integriert werden. Zwischen den Inseln werden IPv4-Tunnel aufgebaut. Ein Beispiel hierfür ist der seit 1996 im IPv4- Internet integrierte 6Bone, ein erstes weltweit verteiltes IPv6-Testnetz. In späteren Phasen der Umstellung lassen sich dann noch vorhandene IPv4-Inseln über Tunnel in einem IPv6-Netz betreiben. Zu beachten ist hierbei, dass die Umstellung von IPv4 auf IPv6 nicht einfach nur die Umstellung eines einzelnen Protokolls bedeutet. Neben IPv6 erfordert Änderungen an vielen Stellen Protokolle und Anwendungsprogramme verändert werden. In vielen Fäl- dem Basisprotokoll müssen auch eine Vielzahl der darauf aufbauenden len erfordert die neue Länge der Adressen eine Änderung bis an die Benutzeroberfläche. Viele Anwender betreiben heute schon Netze oder Teile von Netzen Private Adressen mit so genannten "privaten Adressen". Es handelt sich hierbei um einzelne Bereiche des IPv4-Adressraums, die man für eine lokale Verwendung reserviert hat. Diese Adressen werden innerhalb des globalen Internets nicht transportiert und können daher auch nicht von außen erreicht werden. Um ein derartiges Netz anzuschließen, verwendete man bereits Gateways oder Einrichtungen mit der Bezeichnung "Network Address NAT Translator (NAT)", die es erlaubten, ein komplettes Netz mit privaten Adressen nach außen hin hinter einigen wenigen offiziellen Adressen zu verbergen. Gateways in dieser Funktion können auch mit Firewalls zum Abschotten des lokalen Netzes gegen Angriffe aus dem Internet kombiniert werden. Diese Technik hat einige Einschränkungen in ihrer Verwendbarkeit, ist aber in vielen Fällen ausreichend. Allerdings wird der Einsatz von NAT auf lange Sicht von großen Teilen der IETF als eine Einschränkung für zukünftige Entwicklungen gesehen. Da über den NAT- Rechner alle Kommunikation mit dem Internet erfolgt, kann er schnell zum Flaschenhals werden. Weiterhin haben Umsetzungen der Adressen immer dann Probleme, wenn Anwendungen ihre Adressen auch in den Nutzdaten transportieren. Hier muss für jede derartige Anwendung eine entsprechende Applikation auf dem Gateway installiert werden. Ein Gateway mit dieser Bauart lässt sich einfach auf IPv6 umrüsten. Nach innen werden dann weiterhin die gleichen privaten Adressen verwendet, nach außen zum Internet gelten die neuen IPv6-Adressen.

3 13.2 Aufbau von IPv6-Tunneln im IPv4-Netz Aufbau von IPv6-Tunneln im IPv4-Netz Wenn man heute existierende Netze mit Anschluss an das Internet betrachtet, so benutzen sie für den Transport ihrer Daten RoutingVerfahren aus dem Umfeld IPv4. Auf diesen Protokollen und den zugehörigen Geräten, die zu vielen Tausend überall im Internet im Einsatz sind, liegt die Hauptlast der Kommunikation. Auch wenn einige Hersteller für ihre Geräte die Umstellung auf IPv6 als reine Softwareänderung anbieten, erfordert der parallele Einsatz beider Protokolle in einem Router zumindest weiteren Speicher, in manchen Fällen wird auch die Grenze von Ausbau und Belastung der CPU erreicht. Es wird und kann daher nicht sinnvoll sein, sofort alle Geräte auf IPv6 umzustellen. Mit dem Aufbau von transparenten Tunneln im Rahmen von IPv4 ist man schon seit einigen Jahren in der Lage, auch andere Protokolle, wie zum Beispiel IPX, über ein reines IP-Netz zu übertragen. Diese Mechanismen nutzt man jetzt auch für die Übertragung von IPv6. Hierbei werden die IPv6-Daten transparent über eine IPv4-Verbindung übermittelt und nach außen hin werden auch nur die bei IPv4 üblichen und vorhandenen Mechanismen sichtbar. Man kann sich unterschiedliche Varianten für den Aufbau dieser Tunnel vorstellen: Tunnel für IPv6 Tunnelvarianten Zwischen zwei Routern Will man zwei IPv6-Netze miteinander verbinden, so kann man die dazwischen liegende Strecke über einen IPv4-Tunnel überbrücken. Der Tunnel wird zwischen den beiden Routern aufgebaut und verhält sich wie eine direkte transparente Datenverbindung. Vom Rechner zum Router Soll ein einzelner Rechner in einem IPv4-Netz mit der neuen Software ausgerüstet werden, so muss er weiterhin einen IPv4-Protokollstack behalten. Es ist dann möglich, die IPv6-Daten über einen IPv4-Tunnel zum nächsten erreichbaren Router mit IPv4 und IPv6 weiterzuleiten, um damit den Anschluss an ein IPv6-Netz herzustellen. Vom Router zum Rechner Die zuletzt genannte Variante lässt sich natürlich auch umdrehen, die Funktionen unterscheiden sich dabei nicht, lediglich die Reihenfolge beim Verbindungsaufbau. Von Rechner zu Rechner Ein direkter Tunnel zwischen zwei Rechnern ist gleichfalls denkbar, allerdings verliert dann der Einsatz von IPv6 viel von seinem Sinn. Diese Lösung wird wohl nur in reinen Testumgebungen oder in Ausnahmen eingesetzt werden. Die unterschiedlichen Verfahren zum Aufbau eines Tunnels werden auch noch nach der Methode unterschieden, mit der am Startpunkt des Tunnels die Zieladresse am anderen Ende ermittelt werden kann. In den ersten Automatische Tunnel

4 Umstellung auf das neue Protokoll Zielpunkt des Tunnels beiden Fällen reicht der Tunnel bis zu einem Router, der den Eingang in das eigentliche Netz darstellt. Vom Endpunkt des Tunnels aus werden die Pakete mit normalen IPv6-Routing-Verfahren weitervermittelt. Die Zieladresse des Tunnels hat mit der Zieladresse der IPv6-Pakete keine feste innere Verbindung. Die IPv4-Zieladresse für den Tunnel kann vom Ausgangspunkt durch manuell eingestellte oder automatisch errechnete Informationen zur Topologie ermittelt werden. Ist der Endpunkt des Tunnels gleichzeitig Ziel der Pakete, wie in den letzten beiden Fällen, so kann die Adresse des Tunnels meist direkt aus der Adresse der Pakete ermittelt werden. Wird als Zieladresse im IPv6- Paket eine IPv4-kompatible Adresse verwendet, so kann die IPv4-Adresse direkt den unteren 32 Bit entnommen werden. Da in diesem Fall keine manuelle Konfiguration notwendig ist, spricht man auch vom automatischen Tunnelaufbau. In allen weiteren Eigenschaften unterscheiden sich die verschiedenen Modelle von Tunneln nicht mehr. Ablauf der Übertragung im Tunnel Die Eingangsknoten verpacken das komplette IPv6-Paket mit allen seinen Headern in ein IPv4-Paket und senden es zum Ende des Tunnels. Die Ausgangsknoten nehmen die IPv4-Pakete entgegen, verarbeiten den IPv4-Header und fördern das IPv6-Paket wieder zu Tage. Der IPv6-Header wird nach den normalen Regeln weiterverarbeitet und das Paket seinem Ziel zugeleitet. Dabei wird das Hop- Limit immer genau um den Wert eins vermindert, gleichgültig wie lange die vom Tunnel zurückgelegte Strecke war Lokal im eigenen Netz Umstellung im eigenen lokalen Netz Der Aufbau und Einsatz von IPv4-Tunneln zum Transport von Paketen im neuen Format durch Bereiche des eigenen Netzes, die nur IPv4 verstehen, kann vom Netzbetreiber ganz nach Bedarf gestaltet werden. Er kann damit einzelne IPv6-Inseln als Test aufbauen und miteinander verbinden. Über die Tunnel arbeiten die IPv6-Teilnehmer wie in einem eigenen, in sich abgeschlossenen Netz. Solange keiner der beteiligten Rechner in beiden Netzen aktiv ist, indem er einen doppelten Stack zur Verfügung stellt, besteht allerdings zwischen den beiden Netzen keine Verbindung. Ein Aufbau in dieser Form kann sicher nur der allererste Schritt zur Migration in ein IPv6-Umfeld darstellen. Sobald die ersten Tests erfolgreich abgeschlossen sind, wird man den Hauptteil des Netzes auf IPv6 umstellen und hat dann eher das Problem mit umgekehrten Tunneln, wie sie in Kapitel 13.3 beschrieben werden.

5 13.3 Aufbau von Tunneln im neuen Netz Bone das Testnetz Bei der Definition von IPv6 hat man sich schon sehr früh Gedanken für eine lange Testphase gemacht. Eine Gruppe von interessierten Teilnehmern aus dem Umfeld der Entwickler von Routern und Software sowie eine große Zahl von Universitäten und Forschungszentren haben sich deswegen in der IETF zu einer eigenen Gruppe zusammengefunden, deren Ziel der Aufbau eines die Welt umspannenden Testnetzes war. Bereits 1996 waren in diesem Verbund fast 100 Standorte in der ganzen Welt über das traditionelle Internet mit fest konfigurierten IPv4- Tunneln erreichbar. Der Ausbau im Laufe des Jahres 1997 fügte weitere Stationen hinzu, die an diesem Test teilnehmen. Dieses Netz wird nach Einführung von IPv6-Transportdiensten bei regulären Anbietern von Backbones im Internet seine Bedeutung verlieren, war aber eine ausgezeichnete Umgebung, um Hardware und Software auf ihre Funktionen und Tauglichkeit zu testen. Testnetz Betrieb des 6Bone 13.3 Aufbau von Tunneln im neuen Netz IPv6 hat durch seinen modularen Aufbau von Anfang an die Fähigkeit, neben verschiedenen höheren Protokollen auch Funktion eines Tunnels Protokolle auf der gleichen Ebene als Nutzlast zu transportieren. Zwischen zwei IPv6-Knoten lassen sich Verbindungen mit IPv6 aufbauen, durch die dann zum Beispiel Datenpakete mit IPX- oder IPv4-Headern transportiert werden. Mit diesem Aufbau lassen sich einzelne Rechner oder ganze Gruppen von Rechnern miteinander problemlos in einem IPv6-Netz verbinden, auch wenn diese Abb Aufbau eines Tunnels A IPv4 B IPv6 C IPv6 D IPv4 E die neue IP-Version noch nicht unterstützen. Tunnel Bei dem hier gezeigten Beispiel werden Daten von einem reinem IPv4- Rechner (A) an den ersten Router (B) übergeben. Dieser Router liegt am Rande des IPv6-Netzes und kann daher nur Pakete im IPv6-Format zum Netz versenden. Um die IPv4-Pakete zu ihrem Ziel zu bringen, wird ein Tunnel benutzt. Der Tunnel wird zu dem Router aufgebaut, der seinerseits wieder am Rand des IPv4-Netzes liegt (D). Der Router innerhalb des IPv6-Netzes (C) sieht die Pakete als normalen IPv6-Datenstrom ohne

6 Umstellung auf das neue Protokoll Tunnel sind unidirektional Adressen der Tunnelendpunkte Header wird durch Tunnel länger - Platz für Nutzdaten wird kleiner Keine Fragmentierung auf der Strecke bei IPv6 weitere Besonderheiten. Erst der Router am Ende des Tunnels (D) muss die ineinander geschachtelten Pakete wieder auspacken und als normale IPv4-Pakete dem endgültigen Ziel (E) zuleiten. Besonders zu beachten bleibt bei den Tunneln von IPv6 noch, dass sie immer nur in einer Richtung definiert sind. Will man Daten in beide Richtungen versenden, so müssen zwei gegenläufige Tunnel definiert und aufgebaut werden. Für die Pakete auf der IPv4-Ebene stellt sich das IPv6-Netz als eine transparente Verbindungsstrecke dar. Ganz gleich, wie viele Router zwischen den beiden Tunnelendpunkten liegen, zählt diese Strecke als ein Hop. Das TTL-Feld im IPv4-Header wird immer für den Tunneldurchgang nur genau um den Wert 1 verringert. Die Startadresse des geschachtelten Pakets ist der Beginn des Tunnels. Als Zieladresse wird im IPv6-Header das Ende des Tunnels eingetragen. Bei Bedarf kann ein IPv6-Routing-Header eingesetzt werden. Selbstverständlich sind auch Header für Authentisierung und Verschlüsselung möglich. Die ursprünglichen Adressen des Absenders und des Empfängers bleiben im IPv4-Paket erhalten. Der Einsatz dieser Tunnel beschränkt sich nicht nur auf den Transport von Protokollen älteren Datums, es ist genauso möglich, auch IPv6-Daten auf diese Weise zu transportieren. Dies kann in bestimmten Konfigurationen aus Sicherheitsgründen notwendig und sinnvoll sein. Da durch die Verwendung zusätzlicher Header beim Eintritt in den Tunnel das Paket länger wird, kann es vorkommen, dass die maximale zulässige Paketgröße überschritten und damit eine Fragmentierung erzwungen wird. Bei IPv6 wurde jedoch definiert, dass Router oder andere Knoten auf dem Wege keine Fragmentierung vornehmen dürfen. Um diesen Konflikt zu lösen, definiert man einfach den Beginn eines Tunnels als Beginn eines Kommunikationspfades. Und genau an dieser Stelle erlaubt IPv6 nicht nur Fragmentierung, sondern schreibt sie für den Absender eines Pakets direkt vor. Es ist also legal und richtig, wenn ein Knoten beim Verpacken eines Pakets in einen Tunnel dies bei Bedarf in entsprechend kleinere Einheiten aufteilt, so dass diese zusammen mit den Headern wieder transportierbar sind. Knoten, die auf dem Wege eines Tunnels liegen, dürfen keine Fragmentierung vornehmen. Wie bei IPv6 üblich, melden diese Knoten die aufgetretenen Probleme mit der Größe per ICMP zum Absender, in diesem Fall zum Startpunkt des Tunnels. Kommen fragmentierte Pakete am Ende eines Tunnels an, so werden die Header strikt in ihrer Reihenfolge von links nach rechts ausgewertet. Der Knoten wird also zuerst die fragmentierten Teile zusammensetzen und dann anschließend das eingepackte Paket weiterverarbeiten.

7 13.3 Aufbau von Tunneln im neuen Netz 215 Für die Fragmentierung am Tunneleingang gelten einige spezielle Regeln: Ist das Originalpaket im IPv6-Format empfangen worden und hat es eine Länge von mehr als 576 Bytes, so muss es verworfen werden und per ICMP eine entsprechende Meldung (Paket zu groß) an den Absender übermittelt werden. Hat das Paket im IPv6-Format nur 576 oder weniger Bytes und wird mit dem für den Tunnel notwendigen Headern dennoch die zulässige maximale Transportgröße des Tunnels überschritten, so muss der Eingangsknoten die Nachricht fragmentieren. Wurde das Paket für den Tunnel im IPv4-Format empfangen und ist darin das Bit zum Verbot der Fragmentierung gesetzt (DF = 1), so ist es zu verwerfen und es muss per ICMP eine entsprechende Meldung (Datagramm zu groß) an den Absender übermittelt werden. Wurde ein Datenblock mit IPv4 empfangen, der die Fragmentierung zulässt, so wird dieses Paket zuerst vollständig in das IPv6- Paket für den Tunnel verpackt und dann anschließend gemäß den oben eingeführten Regeln fragmentiert. Fragmentierung am Tunneleingang unter bestimmten Bedingungen erlaubt Rekursive Tunnel Der Aufbau von Tunneln bei IPv6 kann rekursiv erfolgen. Es ist möglich und zulässig, das Schachteln des Protokolls mehrmals hintereinander vorzunehmen. Eine derartige Schachtelung kann zum Beispiel dann sinnvoll sein, wenn mehrere Tunnel an einem Punkt zusammentreffen und von dort aus gemeinsam über ein externes Netz transportiert werden sollen. Als "innerer Tunnel" wird hierbei der zusätzliche Abschnitt des Tunnels bezeichnet. Der ursprüngliche Tunnel wird "äußerer Tunnel" genannt. In diesem Beispiel bestehen zwei Tunnel von B nach E und von H nach I. Tunnel können geschachtelt werden Abb Rekursive Tunnel A IPv4 IPv6 IPv6 IPv6 IPv4 B C D E F innerer G H I J Tunnel äußerer Tunnel