IPv6 Das neue Internetprotokoll

Transkript

1 IPv6 Das neue Internetprotokoll Seminararbeit im Seminar Neue Technologien in Internet und WWW Wintersemester 2003/04 Universität Jena vorgelegt von Stefan Scheidewig Januar 2004

2 Abstract Dieser Artikel soll dem Leser einen Überblick über das Internetprotokoll der nächsten Generation namens IPv6 geben. Einleitend wird die Geschichte des bisherigen Protokolls IPv4, sowie einige wichtige Mechanismen wie zum Beispiel Fragmentierung kurz erläutert. Anschließend wird der neue Aufbau und die Funktionsweise von IPv6 beschrieben, wobei auch auf das neue Adressierungsschema näher eingegangen wird und dabei die Adresstypen Unicast, Anycast und Multicast vorgestellt werden. Dem Leser werden die zwei grundsätzlichen Transitionsansätze Dual-Stack sowie Tunneling grob erklärt, welche den Übergang des alten auf das neue Protokoll ermöglichen sollen. Abschließend gibt es eine kurze Übersicht über den aktuellen Entwicklungsstand des Internet Protokolls der nächsten Generation. 1

3 Inhaltsverzeichnis 1 Einleitung 3 2 Motivation 4 3 Erläuterungen zu IPv Historisches Das TCP/IP-Referenzmodell Der IPv4-Header Fragmentierung und Reassemblierung Umgang mit der Adressproblematik IPv Der Basisheader Die Erweiterungsheader Der Hop-by-Hop Options Header Der Routing Header Der Fragment Header Der Destination Options Header Die Adressierung mit IPv Die Unicast-Adressen Die Multicast-Adressen Die Anycast-Adressen Die statuslose Autokonfiguration Das Mobile IPv Migration Dual Stack Tunneling Zusammenfassung und Ausblick 32 A Glossar 34 B Wichtige Internetadressen 39 C Abkürzungen und Akronyme 39 Literaturverzeichnis 41 Index 42 2

4 1 Einleitung Stellen Sie sich vor Sie sind Bürgermeister einer Kleinstadt und Ihnen wird nur eine begrenzte Anzahl von Hausnummern zur Verfügung gestellt, die sie den Häusern ihrer Stadt vergeben können. Vergrößert sich nun ihre Stadt, können Sie den Häusern keine Adressen mehr geben. Dies ist zwar ein äußerst unrealistisches Szenario, aber in einem ganz anderem Sachverhalt wird es früher oder später eintreten: dem Internet wurde das INTERNET Program ins Leben gerufen unter der Leitung von Vinton Cerf und Robert Kahn, welche als Aufgabe hatten, Netzwerke verschiedener Art (damals unter anderem das ARPANET und das über Rundfunk kommunizierende PRNET) miteinander zu verbinden und Kommunikation zwischen diesen zu ermöglichen. Zuerst entwickelten Sie dafür das Transmission Control Protocol (TCP), welches einen reibungslosen Paketaustausch gewährleisten sollte. Dabei übernahm dieses Protokoll unter anderem die Adressierung und das Routing wurde der Aufgabenbereich des TCP geteilt und sie entwarfen schließlich ein zusätzliches Protokoll mit dem Namen Internet Protocol (IP), das diese Aufgaben übernahm. Das Design dieses Protokolls war so gut, daß es bis heute überlebt hat. Doch 1990 erkannte die IETF (Internet Engineering Task Force), daß mit dem stark anwachsenden Interesse an dem Netz der Netze und dem sich ändernden Anforderungen eine Menge Probleme auf dieses Protokoll zukommen würden. Eines der großen Probleme ist der Adreßraum, welcher dem Protokoll 1980 mitgegeben wurde. Für die damaligen Verhältnisse war der 32 Bit Adreßraum für lange Zeiten ausreichend, aber nicht zuletzt die Entwicklung des World Wide Web (WWW) und die anschließende Freigabe für die Öffentlichkeit 1993, führten dazu, daß sich das Internet exponentiell ausbreitete. Ein weiterer Grund für ein neues Protokoll, ist die starke Anforderungsänderung. Wo noch in der Anfangszeit des Internets der Gebrauch überwiegend wissenschaftlicher Natur war, wird es heutzutage von der breiten Masse genutzt, die mit vielfältigsten multimedialen Anwendungen arbeitet. Vor allen Dingen aber das Video-on-Demand und die Internettelefonie setzen eine reibungslose Bildübertragung voraus. Damit dies funktioniert, ist es wichtig, daß es neben der best-effort 2 Übertragung der IP Datagramme auch eine Übertragungart gibt, die das häufige Wechseln der Route verhindert. Eine solche Dienstart kann zwar in dem heutigen Protokoll IPv4 gefordert werden, aber nicht für multimediale Daten. Dem Projektaufruf IPnG - IP next Generation 3 der IETF 1990 (RFC ) folgten 22 zum Teil unvollständige Vorschläge. Im Dezember des Jahres 1992 lagen 4 durchdachte Vorschläge vor. Kurze Zeit später kamen noch 3 weite- 1 Entscheidungsalgorithmen, zur Weiterleitung von Paketen 2 Die IP-Datagramme werden einfach losgeschickt und können dabei unterschiedliche Wege zum Ziel passieren, ohne daß irgendwelche Garantien übernommen werden 3 Der Name IP - The next Generation wurde in Anlehnung an die allseits beliebte Star- Trek Serie vergeben 4 RFC entspricht Request for Comments und das bedeutet soviel wie Aufforderung zu Kommentaren. RFCs sind die gängigen Arbeitspapiere der IETF 3

5 re Vorschläge hinzu. In der folgenden Arbeitsphase folgten Zusammenschlüsse der Projektgruppen untereinander und verschiedene Umbenennungen. Letztendlich setzte sich 1994 der Vorschlag der Projektgruppe Simple Internet Protocol Plus (SIPP) durch unter der Leitung von Steve Deering 5 und Robert Hinden 6. Da die ng -Bezeichnung mittlerweile von mehreren Projekten kopiert wurde und man sich von den anderen Projekten abheben wollte, entschloss man sich für einen Versionsnamen. Die Wahl fiel auf IPv6, da im Versionsfeld des aktuellen Protokolls die 4 steht und IPv5 schon vergeben war an ein experimentelles Protokoll mit dem Namen Streaming Protocol, welches keinen Zuspruch fand und sich in der Industrie nicht durchsetzen konnte 7. Im Dezember 1995 veröffentlichte die Projektgruppe das RFC 1883, welches das neue Protokoll erstmals spezifizierte. Drei Jahre später, im Dezember 1998, folgte eine weitere Spezifikation (RFC 2460), in der verschiedene Änderungen vorgenommen wurden 8. Mein Anliegen ist es, den Leser mit dem neuen Internetprotokoll vertraut zu machen. Dabei will ich nicht nur über die Neuerungen und die Funktionsweise schreiben (Kapitel 4 - IPv6), sondern zudem auch weitere Begründungen liefern, weshalb dringender Handlungsbedarf besteht (Kapitel 2 - Motivation) und wie das jetzige Internetprotokoll funktioniert (Kapitel 3 - Erläuterungen zu IPv4). Weiter will ich versuchen, die 2 gängigsten Migrationsmöglichkeiten vorzustellen (Kapitel 5 - Migration), mit deren Hilfe man eine sanfte und kostengünstige Transition von IPv4 auf IPv6 ermöglichen will. Schließlich versuche ich in Kapitel 6 eine Erklärung abzugeben, weshalb die Entwicklungszeit schon so lange andauert und IPv6 immer noch nicht allgemeinen Einsatz findet sowie einen Überblick über den aktuellen Fortschrittszustand. 2 Motivation Die Frage, die man sich stellen muß, ist: Warum brauchen wir ein neues Protokoll auf der Internetebene? Das alte Protokoll funktioniert doch gut. Das ist auch korrekt. IPv4 und seiner Erweiterbarkeit ist es zu verdanken, daß Millionen von Anwendern heutzutage im und mit dem Internet arbeiten können. Jedoch gibt es bei IPv4 viele Aspekte, die für ein neues Protokoll sprechen. Wie eingangs erwähnt, ist der Hauptgrund, der mit 32 Bit zu gering bemessene Adreßraum. Aber die 32 Bit würden noch für lange Zeit reichen, wenn die zur Verfügung stehenden Adressen nicht so ungleichmäßig verteilt wären. Der Großteil der Adressen ist für amerikanische Großunternehmen und Einrichtungen reserviert. Doch nicht nur die Europäer und Amerikaner sind mittlerweile im Internet vertreten. Der asiatische Markt boomt gewaltig allein mit China und Japan. Hinzu kommt, daß die Menschen immer mobiler werden. Neue Technologien wie UMTS 9, bei dem Übertragungsraten bis zu 4 Mbps möglich sind, Vor allem weil man dafür noch keine Notwendigkeit sah 8 Unter anderem wurden Feldgrößen verändert 9 Universal Mobile Telecommunication Standard 4

6 erobern den Markt. Um dieses heterogene Netz ins Internet einzubinden, bedarf es einem Protokoll, welches mehr Adreßraum besitzt als das jetzige IPv4. Doch nicht nur das Wachstum und neue Technologien sind ausschlaggebend für einen Wechsel. Lange Zeit war es üblich, daß ein Dienst von einem Server angeboten wurde und die Teilnehmer im Netz diesen Dienst dann abgerufen haben. Diesen Ansatz nennt man das Client-Server-Prinzip. Aber mit dem Aufkommen von immer leistungsfähigeren Heimrechnern und der starken Nachfrage am Internet, sind die dienstanbietenden Server immer häufiger überlastet. Deswegen gibt es in jüngster Zeit einen Wechsel vom Client-Server-Prinzip hin zum Peer-to-Peer-Prinzip. Dieser Ansatz basiert darauf, daß jeder Rechner, der im Internet eingebunden ist, nicht nur einen Dienst als Client abruft, sondern auch gleichzeitig einen Dienst anbietet. Das bedeutet nicht, daß der Client-Server-Ansatz völlig ausstirbt. Das neue Paradigma ist lediglich als Entlastung anzusehen und einige Peer-to-Peer-Netze benutzten sogar das Client-Server-Prinzip. Damit aber ein reibungsloser Ablauf bei Peer-to-Peer-Netzwerken gewährleistet ist, bedarf es einer global eindeutigen Adresse eines jeden Teilnehmers, unter der dieser ansprechbar ist (wo wir also wieder bei der Adressknappheit angekommen wären). Doch nicht nur Computer und Telefone sind prädestiniert zur Einbindung in das Netz der Netze. In Zukunft werden auch Autos, Fernseher, Mikrowellen, Kühlschränke, ja ganze Häuser im Internet erreichbar sein. Doch neben dem Adressproblem haben die Designer von IPv6 auch viele andere mit der Zeit aufgekommene Probleme mitzulösen. Viele Geschäftsleute können, wenn sie mit ihrem Laptop unterwegs online gehen, nur mit Mühe 10 unter ihrer globalen Adresse erreicht werden. Das neue Protokoll hat eine Lösung für dieses Dilemma implementiert. Wenn ein Geschäftsmann mit seinem IPv6- Laptop in einem fremden Gebiet online geht, braucht er nicht mehr aufwendige Konfigurationen zu tätigen, um unter seiner festen IP-Adresse ansprechbar zu sein. Somit haben die Designer des neuen Protokolls auch viel Wert auf Vereinfachung gelegt. Da IPv4 so viel Erfolg hatte, wurde bei der Entwicklung von IPv6 grundsätzlich viel Wert darauf gelegt, daß man die schlechten Eigenschaften des Protokolls entfernt und neue bessere hinzunimmt. So wurde der Arbeitsaufwand der Router 11 minimiert und Multimediafähigkeit mit implementiert. Ein weiterer zu betrachtender Aspekt ist, daß bei Subnetzen, welche viele Rechner vereinigen ein riesiger Aufwand beim Administrieren entsteht. Dies wurde bei IPv4 mit diversen Zusatzprotokollen erledigt. Deswegen haben die Designer von IPv6 Automatismen ins Protokoll genommen, welche den Administrationsaufwand minimieren und dem Anwender die Konfiguration des Internetzugangs erleichtern sollen gemäß dem Motto: Plug-And-Surf. Doch auch an das Thema Sicherheit haben die Entwickler gedacht. IPv4- Datagramme 12 haben den Mangel, daß die Daten unverschlüsselt verschickt werden und ein Dritter die Daten leicht lesen kann. Für dieses Problem gibt 10 z.b. unter Zuhilfenahme von Mobilen Agenten 11 Router sind Stationen, die Packete weiterleiten 12 Werden die Pakete genannt, die auf der Internetebene abgeschickt und empfangen werden 5

7 es mehrere Lösungen auf anderen Ebenen des Protokollstapels, aber es werden immer wieder Sicherheitslücken bei diesen Ansätzen entdeckt. Dies wurde von der Entwicklergruppe erkannt und die Antwort war IPsec 13. Aber während die IPv6-Entwicklergruppe bei der Modellierung war, erkannten Sie, das die Sicherheit nicht nur für das neue Protokoll, sondern auch für das alte Protokoll wichtig war. So kam es schließlich, daß eine extra Arbeitsgruppe IPsec von der IETF ins Leben gerufen wurde, die sich ausschließlich um dieses Protokoll kümmern sollte. Da die IPsec-Implementierung nicht Thema dieses Papiers ist, möchte ich nur kurz erläutern, was das Protokoll leisten kann. Neben der Verschlüsselung der Daten, wird zusätzlich die Integrität der Pakete gewährleistet, das heißt ob die Pakete auf ihrer Reise verändert beziehungsweise gelesen wurden. Aber nicht nur die Pakete selbst sondern auch der Absender kann authentisiert werden. Zudem wurde eine Schlüsselverwaltung implementiert. All dies macht Virtuelle Private Netzwerke 14 sicher. In diesem Kapitel wurden Begriffe erwähnt, die unter Umständen unklar sind. Ich will daher im nächsten Kapitel versuchen, die Funktionsweise des alten Protokollstapels TCP/IP(v4) zu erläutern, um einen groben Überblick zu geben, wie der Datenverkehr mit IPv4 funktioniert. 3 Erläuterungen zu IPv4 3.1 Historisches Im damaligen ARPANET und dem heutigen Internet wird das TCP/IP-Referenzmodell eingesetzt. Diese Architektur wurde nach den Protokollen benannt, die hauptsächlich an der Kommunikation beteiligt sind: den bereits erwähnten TCP-Protokoll und dem IP-Protokoll. Notwendig wurde ein neues Referenzmodell, als das schon existierende ARPANET nunmehr noch mit Satellitenund Funknetzen kommunizieren mußte. Mit den damals benutzten Protokollen war dies nicht möglich und so mußte ein neuer Ansatz her. Die Entwicklung dieses Referenzmodells ist im Grunde eine Folge des Kalten Krieges. Der Geldgeber der Entwickler war das amerikanische Verteidigungsministerium. Da ein Atomschlag zu diesen Zeiten wie ein Damoklesschwert über den Köpfen der Amerikaner schwebte, wollte das Militär ein Rechnernetz, welches bei Ausfall einzelner Rechner weiter funktionsfähig gewesen wäre. 3.2 Das TCP/IP-Referenzmodell Aus diesem Grund haben die Entwickler sich dazu entschieden, das abgeschickte Pakete den Weg nehmen, der möglich und am schnellsten ist (best effort), wovon der Sender und der Empfänger nichts mitbekommen sollten (Transparenz). Unter diesen Umständen hätte es aber vorkommen können, daß einzelne abgeschickte Pakete unterschiedliche Wege durch das Netz genommen hätten 13 IP Security 14 Virtuelle Private Netze bedeutet grob gesagt ein Aneinanderkoppeln zweier entfernter lokaler Netze zu einem Virtuellen, wobei öffentliche Netzwerke mitbenutzt werden 6

8 und so in völliger Unordnung beim Empfänger angekommen wären. Damit diese Pakete aber auf dem Zielrechner in die richtige Reihenfolge gebracht werden konnten, sollte das TCP-Protokoll für einen Verbindungsaufbau und den ordnungsgemäßen, fehlerfreien Transport der Pakete sorgen. Deswegen spricht man auch bei TCP/IP-Verbindungen von verbindungsorientierten und paketvermittelnden Diensten. Damit aber auch Nachrichten geschickt werden konnten, ohne daß der Sender mit den Empfängern eine Verbindung aufnehmen müsste (da das zu zeitaufwendig wäre und die Nachrichten aktuell sein mussten), fügten die Entwickler das UDP 15 -Protokoll zum TCP/IP-Stapel 16 in die Transportschicht ein, welches verbindungslos arbeitet. Bei UDP/IP- Diensten spricht man daher auch von verbindungslosen, paketvermittelten Diensten. Aber wie kann man sich das vorstellen? Was passiert, wenn wir zum Beispiel eine abschicken wollen? Ich will versuchen Ihnen einen groben, dafür aber einfachen Ablauf zu schildern. In Wirklichkeit ist dieser Vorgang weitaus komplexer. Auf dem Sender- Rechner wird die zuerst in einer Anwendung verfasst. Diese verfasste wird abgeschickt und die Anwendung gibt die Daten an die Anwendungsschicht des Protokollstapels weiter, in diesem Fall das SMTP 17 -Protokoll. In dieser Ebene werden nun für das SMTP-Protokoll der Anwendungsschicht des Empfängers diverse Informationen an die heruntergereichten Daten angehängt, obwohl der Sender noch gar nicht weiss, ob der Empfänger in der Lage ist das SMTP-Protokoll zu verstehen. Diese Daten werden nun weitergegeben an die Transportschicht des Senders und somit an das TCP-Protokoll, da dies ein verbindungsorientierter Dienst ist. In dieser Ebene wird jetzt erst eine Verbindung zwischen Sender und Empfänger hergestellt. Das TCP-Protokoll ist außerdem für die Flußkontrolle zuständig, welche dafür da ist, daß der langsame Empfänger nicht überflutet wird von den Paketen des schnelleren Senders. Auch das TCP-Protokoll setzt einen sogenannten Header, also ein zusätzliches Informationsfeld für das TCP-Protokoll des Empfängers, an die Daten, die aus der Anwendungsschicht heruntergereicht wurden. Das TCP-Protokoll interessiert es nicht, was diese heruntergereichten Daten bedeuten. Es soll lediglich diese Daten zur Übertragung bereitstellen. Dieses Prinzip nennt man Kapselung (siehe Abb. 1). Wenn das TCP-Protokoll seinen Informationsheader angefügt hat, gibt es diese Daten an das eine Ebene tiefer gelegene IP 18 -Protokoll weiter. Dieses Protokoll ist dafür zuständig, das die Daten, welche von der Transportschicht heruntergereicht wurden, an den Empfänger richtig zugestellt werden. Dabei übernimmt das Protokoll das Routing, was ein anderes Wort für Wegwahl ist. So gesehen ist das IP-Protokoll entscheidend für die Geschwindigkeit einer Sendung, da es sich auch um Überlastungen kümmert. Das IP-Protokoll ist das Protokoll, welches auf jeden Internet-Router vorhanden sein muss. Diese Daten werden jetzt wiederum mit Zusatzinformation für das Empfän- 15 User Datagram Protocol 16 So werden Referenzmodelle auch genannt 17 Simple Mail Transfer Protocol 18 Internet Protocol 7

9 Abbildung 1: Kapselung ger-ip-protokoll versehen und an die Bitübertragungsschicht heruntergereicht. Bei der Bitübertragungsschicht klafft eine große Definitionslücke. Die Protokolle, die auf dieser Schicht eingesetzt werden, sind im Standard nicht definiert. Lediglich die einheitliche Schnittstelle soll unveränderlich sein. Auf dieser Ebene kommen die Protokolle der jeweiligen Netzwerkarchitektur zum Zuge. So kommt es bei einigen Netzwerkprotokollen vor, daß Funktionen, die schon durch das TCP-Protokoll bereitgestellt werden, doppelt zum Einsatz kommen. Auch hier werden die heruntergereichten Daten wieder verpackt und letztendlich an den Empfänger abgeschickt, da diese Schicht für die tatsächliche Übertragung der einzelnen Bits verantwortlich ist. Abbildung 2: Vergleich zwischen ISO/OSI- und TCP/IP-Referenzmodell An dem ersten Router angekommen werden die Daten Schritt für Schritt wieder entpackt und bis zur Internet-Ebene an das IP-Protokoll weitergereicht, welches unter anderem mit Hilfe von Routing-Tabellen entscheidet, welcher Weg zum Ziel als nächstes eingeschlagen wird. Sind die Daten beim Empfänger einmal angekommen, werden bei jeder Protokollebene die Header des Senders ausgewertet und entsprechend an die nächsthöhere Protokollebene weitergegeben, bis sie schließlich in der jeweiligen Anwendung (wahrscheinlich ein Programm) angekommen sind. 8

10 Diesem Prinzip der voneinander unabhängigen Protokollebenen ist es zu verdanken, das im Laufe der Zeit die einzelnen Protokolle immer weiter verbessert wurden. Dieses Prinzip des Protokollstapels, griff die ISO 19 auf und verfeinerte es. Es kamen weitere Protokollebenen hinzu und 1983 wurde dieser Standard unter dem Namen ISO/OSI 20 -Referenzmodell verabschiedet. Aber den Erfolg, den das TCP/IP-Referenzmodell hatte, hatte das ISO/OSI-Modell nie. 3.3 Der IPv4-Header Wie sieht der IP-Header aus, der an die Daten von der Transportschicht angehängt wird? Betrachten sie dafür Abbildung 3. Abbildung 3: Der IPv4-Header Wir sehen viele 32 Bit lange Zeilen. Tatsächlich aber wird der Header nicht als Block sondern als sequentielle Bitfolge an den Datenblock oder auch Nutzdaten angehängt. Hierbei bedeuten die Felder folgendes: Version: Beinhaltet eine binäre Zahl, welche dem Router Auskunft darüber gibt, mit welchem IP-Protokoll er es zu tun hat (in diesem Fall also die binäre 4). Mit diesem Feld ist die Erprobung neuer Protokolle möglich, ohne den Netzbetrieb zu stören. Länge (Internet Header Length): Beinhaltet die Länge des Headers in 32 Bit Wörtern. Dieses Feld ist deswegen notwendig, da das Optionsfeld eine variable Länge hat (muss mindestens die binäre 5 stehen, da der Header nicht kürzer sein kann). Dienstart (Type of Service): Gibt die Dringlichkeitsart und die Übertragungsart an (3 Bit für die Priorität, 3 Bit für die Übertragung und 2 Bit sind reserviert). Länge des gesamten Paketes (Total Length): Enthält die Gesamtlänge des Datagramms (Header und Nutzdaten) in 32 Bit Wörtern. Da das Feld 16 Bit lang ist, sind Datagramme der Größe von Byte möglich. 19 International Organization for Standardization 20 Open Sysstems Interconnection 9

11 Identifikation (Identification): In diesem Feld steht eine binäre Kennzahl, welche den Empfänger eines Paketes befähigt, das Fragment, welches durch einen Engpass auf dem Sendeweg entstanden ist, wieder dem richtigen Datagramm zuzuordnen. Flags: Dieses 3 Bit lange Feld beinhaltet Informationen darüber, ob das Datagramm fragmentiert werden darf oder nicht. Dabei ist das erste Bit mit dem Wert 0 reserviert. Fragment-Offset: Dieses Feld beinhaltet eine relative Adresse, die dem Empfänger dazu dient, ankommende Fragmente wieder in der richtigen Reihenfolge des Ursprungdatagramms zusammenzusetzen. Time to Live: Dieses 8 Bit lange Feld beinhaltet einen Wert der gewährleistet, daß ein Paket nicht über einen Zeitraum hinweg auf Reisen ist. Die maximale Zahl ist 255. Wenn das Paket bei einer Zwischenstation ankommt, dekrementiert der Router den Wert um 1. Wird der Wert von einem Router auf 0 herabgesetzt, ist die Lebenszeit des Paketes abgelaufen und der Router verwirft dieses Paket mit der Aufforderung an den Sender dieses nochmal abzuschicken. Doch nicht nur bei jedem Zwischenschritt wird der Wert dekrementiert, sondern auch bei Auftreten eines Staus. (Standardmäßig wird dieses Feld auf 32 gesetzt (RFC 1060)). Protokoll (Protocol): In diesem 8 Bit Feld steht die eindeutige Protokoll-Identifikationsnummer 21 des Protokolls, welches in der nächsthöheren Schicht folgt (Bei TCP die binäre 6, bei UDP die binäre 17 und bei ICMP 22 die binäre 1). Header Prüfsumme (IP Header Checksum): Dieses Feld dient dazu den IP Header auf Fehler während der Übertragung zu prüfen. Da aber schon das TCP-Protokoll schon für eine Korrektur des gesamten Paketes sorgt und diese Prüfsumme keine Fehler in den Nutzdaten korrigiert, erachten viele dieses Feld als überflüssig. Zudem wird bei jedem Router mindestens das Time-to-Live-Feld verändert und demzufolge muß bei jedem Schritt die Prüfsumme neu berechnet werden. Absenderadresse (IP-Source-Address): In diesem Feld befindet sich die IP-Adresse des Absenders. Uns allen bekannt ist die Darstellung jedes einzelnen Oktetts 23 dieser Adresse als durch Punkte getrennte Dezimaldarstellung. Zieladresse (IP-Destination-Address): Dieses Feld beinhaltet die IP- Adresse des Empfängers. Die Absender- und Zieladresse müssen nicht global eindeutig sein (dafür aber eindeutig), da das Protokoll auch in Intranets 24 eingesetzt werden kann. 21 Werden in den Assigned Internet Protocol Numbers veröffentlicht 22 Internet Control Message Protocol 23 Ein Oktett bedeutet in der Netzwerktechnik 8 Bit 24 Ein Intranet ist ein Netz, welches keine Anbindung an das Internet hat bzw. durch eine Firewall vom Internet abgekoppelt arbeitet 10

12 Optionen (Options): Dieses Feld hat eine variable Länge und enthält verschiedene Optionen für die Router und den Empfänger. Unter anderem können die IP-Adressen der einzelnen Zwischenstationen aufgenommen werden sowie vordefinierte IP-Adressen als Wegbezeichnung angegeben werden. Padding: dieses Feld ist das sogenannte Auffüllfeld. Wenn die Optionen die Länge des IP-Headers nicht ganz ausfüllen, werden einfach Nullen angehängt, damit der IP-Header das gewünschte 32 Bit Format erhält. 3.4 Fragmentierung und Reassemblierung Wenn nun ein Paket auf die Reise geht, kann es vorkommen, daß es auf ein Netzwerk stößt, dessen maximal zulässige Paketlänge (MTU 25 ) kleiner ist als die Länge des Pakets. Dies kann daran liegen, daß entweder die Netzwerktechnik in der Länge oder Breite der maximalen Übertragungszeit beschränkt ist, das Netzwerkprotokoll nur eine begrenzte Anzahl von Bits per Paket zuläßt, die Puffer-Größe der Software zu gering ist oder einfach nur durch eine Norm begrenzt ist. Tritt dieser Fall ein, so ist es Aufgabe des IP-Protokolls das Paket entsprechend der MTU des Netzes aufzuteilen. Betrachten wir als Beispiel die folgende Abbildung 4: Abbildung 4: Eine Strecke mit unterschiedlichen MTUs In diesem Fall schickt der Rechner A ein Paket ab, das 1500 Bytes groß ist und mit seiner Netzwerktechnik übertragen werden kann. Der Router empfängt das Paket und merkt, das das Paket zu groß ist, um es in einem Stück an den Rechner B zu schicken. In diesem Fall bestimmt der Router, daß die maximal mögliche Paketlänge des Netzes von Rechner B nur 1000 Bytes groß ist und zerlegt das Paket in 2 kleinere Fragmente, welche einen vollständigen IP- Header mit einer Fragment-Adresse, gesetzten Fragment-Bits und einer eindeutigen Fragment-Identifikationsnummer erhalten (siehe Abb. 5). Abbildung 5: Fragmentierung des Pakets Das Time-to-Live-Feld der Fragmente wird um 1 dekrementiert und die Prüfsumme wird neu berechnet. Diese kleineren Pakete können nun ordentlich 25 Maximum Transmission Unit 11

13 zum Empfänger übertragen werden. Falls der Empfänger nicht wie in unserem Beispiel in einem Hop 26 erreicht werden kann, so behandeln die nachfolgenden Router die einzelnen Pakete wie normale Datagramme und schicken diese nach best-effort-methode zum Ziel. Dadurch kann es passieren, daß die Fragmente in unterschiedlicher Reihenfolge beim Empfänger eintreffen. Wenn das der Fall ist, reassembliert der Empfänger unter Zuhilfenahme der Identifikationsnummer der Fragmente, der Fragment-Adresse und des Fragment-Bits das Datagramm in der richtigen Reihenfolge. 3.5 Umgang mit der Adressproblematik Wir haben uns soweit einführend mit IPv4 beschäftigt. Nun wurde die Frage aufgeworfen, weshalb wir so dringend ein neues Protokoll brauchen. Als Antwort steht vordergründig der Mangel an Adressen. Dazu muß gesagt werden, daß früher oder später die Adressen bei der stetigen Nachfrage definitiv ausgehen werden. Eine weitere Ursache ist jedoch auch in der schlechten Aufteilung des Adreßraums zu finden. Der Adreßraum des IPv4-Protokolls, wurde eingeteilt in 5 Klassen, wobei jede Adressklasse einen Netzwerkanteil und einen Hostanteil besitzt (siehe Abb. 6). Abbildung 6: Die Adressklassen von IPv4 Die ersten 4 Bit einer IP-Adresse bestimmen die Adressklasse und somit den Bereich der Adresse, der das Netzwerk, sowie die einzelnen Rechner identifiziert. Eine Klasse-A-Adresse beginnt mit einer binären 0, wobei das erste Bit der Klassen B, C, D und E eine binäre 1 ist. Liegt nun eine Klasse-A-Adresse vor, so bezeichnen die ersten 8 Bit die Netzwerkadresse und die restlichen 24 Bit den Anteil der Einzelrechner. Das heißt, daß solch eine Adresse an lediglich 126 Netzwerke vergeben werden kann (Adressen, deren erste Dezimalzahl im Bereich von liegt; 0 27 und reserviert), welche maximal Rechner 26 Ausdruck für einen Schritt zwischen benachbarten Rechnern 27 Hat zwei unterschiedliche Bedeutungen: 1. mit konnte man früher Rundmeldungen machen an alle Rechner (Broadcasts); heute wird mit der eigene Rechner im lokalen Netz bezeichnet 2. mit z.b spricht man den Rechner dieses Netzes an, in dem man sich selber befindet (This) 28 Dient zum Test, ob die TCP/IP Software richtig funktioniert auf dem lokalen Rechner. 12

14 umfassen können. Das ein Netzwerk so viele Einzelrechner benötigt ist sehr unwahrscheinlich und daher ist diese Vergabe sehr ineffizient. Eigentümer dieser Adressen sind zum größten Teil amerikanische Institute und Großunternehmen. Klasse-B-Netze identifizieren sich dadurch, daß das zweite signifikante Bit eine 0 ist. Bei diesen Netzen beläuft sich der Netzwerkanteil auf 16 Bit, wobei die ersten 2 Bit 10 beinhalten, und dadurch sind Netzwerke mit je Rechnern adressierbar (Die erste Dezimalzahl dieser Adressen liegt im Bereich von ). Wenn die ersten 3 Bits einer Adresse 110 sind, handelt es sich um eine Klasse-C-Adresse, bei der sich der Netzwerkanteil auf 24 Bit beläuft. Dies bedeutet eine Gesamtzahl von Netzwerken, die 254 Einzelrechner umfassen können (Die erste Dezimahlzahl dieses Adresstyps liegt im Bereich von ). Eine Gemeinsamkeit der ersten drei Adressklassen ist, daß deren Hostanteil nur aus binären Einsen bestehen kann (oder dezimal ausgedrückt 255). Dies dient dazu Rundmeldungen (Broadcasts) durchzuführen, was bedeutet, daß jeder Rechner im jeweiligen Netz die abgeschickte Nachricht erhält. Die Klasse-D-Adressen sind sogenannte Multicast -Adressen. Sind die ersten 4 Bit 1110, so handelt es sich um eine solche Adresse (oder auch Adressen, deren erste Dezimalzahl im Bereich von liegt). Zum Beispiel handelt es sich bei der Adresse um alle Rechner innerhalb des eigenen Subnetzes oder bei Installation des NTP 29 -Protokolls ist man Teilnehmer der Multicast-- Gruppe , und man erhält stets die genaue Zeit. Einen reservierten Status haben Klasse-D-Netze, deren erste 4 Bits mit 1111 beginnen (erste dezimale Zahl im Bereich von 240 bis 255). Reguliert wird die Adressvergabe momentan von der ICANN 30, welche den einzelnen regionalen Behörden vorsteht. In Europa ist dies die RIPE 31. Aus den Gründen, daß diese Behörden immer mehr damit zu tun hatten, Anfragen der Großunternehmen nach Adressen zu befriedigen und durch die Klasseneinteilung viele IP-Adressen brach lagen, überlegte sich die IETF mit CIDR 32 eine effizientere Adresszuweisung, als die der statischen Klasseneinteilung. Dabei kann mit einem Präfix die Länge des Netzwerkanteils dynamisch gewählt werden und so IP-Adressen nach Bedarf vergeben werden. Zum Beispiel entspricht die CIDR-Adresse /20 dem Netzwerk, deren erste 20 Bit den Netzwerkanteil darstellen und der Rest den Hostanteil. Durch dieses Verfahren erhöht sich die Effizienz der Adressvergabe erheblich. Der Nachteil von CI- DR allerdings ist, daß für jedes neue Klasse-C-Netz ein eigener Eintrag in den Routing-Tabellen der Router notwendig ist und so die Größe der Tabellen stark wächst. Für CIDR vorgesehen sind die Klasse-C-Adressen. Dabei sind für jeden Kontinent 32 Millionen Adressen reserviert (siehe Abb. 7). Doch dies sind nicht die einzigsten Maßnahmen, die getroffen wurden, um mit der Adressverknappung zu leben. Unternehmen, die Privatpersonen eine Dabei schickt der Rechner an sich selber Pakete (loop). Testet nicht den Netzwerkcontroller! 29 Network Time Protocol 30 Internet Corporation for Assigned Names and Numbers 31 Réseaux IP Européens 32 Classles Inter-Domain Routing 13

15 Abbildung 7: Zuteilung der CIDR Adressräume global eindeutige IP-Adresse vergeben - sogenannte Internet Service Provider (ISP) -, haben für diesen Zweck vordefinierte Adressblöcke. Wenn sich eine Privatperson bei diesem Anbieter einwählt, vergibt dieser dynamisch eine Adresse seines Kontingents. Die Privatperson ist nun unter dieser Adresse ansprechbar, bis sie sich wieder beim Anbieter auswählt. Die vergebene Adresse kann nun an einen anderen Kunden weitergegeben werden. Diesen Vorgang nennt man dynamische Adressierung. Doch der Nachteil dieses Vorgangs ist, daß bei erhöhter Nachfrage eine Situation entstehen kann, bei der jede Adresse des Kontingents vergeben ist. In dieser Situation scheitern die restlichen Kunden beim Einwahlvorgang. Eine weitere Maßnahme besteht darin, daß mehrere Rechner eines Teilnetzes einen Internetzugang gemeinsam nutzen. Hat ein Unternehmen eine feste IP- Adresse und will nicht mehr Geld für weitere Adressen investieren, so kann es dennoch die Angestellten die eine Adresse gemeinsam nutzen lassen, indem der Mechanismus des Network Address Translation (NAT) zum tragen kommt (siehe Abb. 8). In diesem Beispiel soll die Funktionsweise veranschaulicht werden. Ein kleines Unternehmen, bestehend aus einem Router und zwei Rechnern, möchte mit einer IP-Adresse beide Rechner an das Internet anbinden. Dabei sprechen Rechner1 und Rechner2 den Router über die Adresse an, wobei der Router die beiden Rechner mit beziehungsweise ansprechen kann. Der Router benötigt eine zweite seperate Schnittstelle, die die global eindeutige Adresse besitzt (Adresse entweder vom Anbieter zugewiesen oder fest). Den Rechnern muß bekannt sein, daß die Adresse des Routers die Schnittstelle mit der Außenwelt darstellt. Kommt nun eine Anfrage einer der Rechner, so empfängt der Router diese Pakete, setzt in das Absenderfeld des IP-Headers seine eigene global eindeutige Internetadresse, die Prüfsumme wird neu berechnet und das Paket wird abgeschickt. Kommt nun ein Antwortpaket von außen zum Router, so setzt der Router die Zieladresse des Rechners ein, welcher die Anforderung an dieses Paket gestellt hatte. Diesen Vorgang wird Mapping genannt. Doch dieser Mechanismus bringt viele Probleme mit sich. Zum einen wird die 14

16 Abbildung 8: Network Address Translation Bandbreite, die die Netzwerktechnik gewährleistet, bei starken Verkehr durch die Anzahl der Teilnehmer dividiert und der Zugang wirkt als Flaschenhals. Desweiteren ist dies für Peer-to-Peer-Anwendungen ein Problem, da diese auf Rechnern laufen müssen, die eine globale IP-Adresse besitzen. überhaupt entspricht dieser Mechanismus nicht der Idee des Internet, welches, wie der Name schon sagt, ein Netz sein soll. Damit dies aber funktionieren kann, ist die Einführung eines neuen Protokolls auf der Internetschicht nötig: 4 IPv6 4.1 Der Basisheader Eines der Designziele des neuen Protokolls war es, die Router noch mehr zu entlasten. Diese sollten nur noch die Informationen auswerten müssen, die sie zum weiterleiten benötigen. So geschah es, daß das Modulprinzip auch für IPv6 genutzt wurde. IPv6 umfaßt jetzt neben dem Basisheader (siehe Abb. 9), der anders als bei IPv4, eine feste Größe aufweist, mehrere modulare Header, die sogenannten Extension Header oder auch Erweiterungsheader. Die feste Größe des Basisheaders ist ein Plus an Geschwindigkeit, da nicht erst an ein bestimmtes Längenfeld gesprungen werden muß, um das Ende des Headers zu ermitteln. Aber nicht nur die feste Größe ist eine Neuerung. Bei der Entwicklung hat man sich die negativen, wie positiven Eigenschaften des alten Protokolls stets vor Augen gehalten und so entstand ein neuer und schlanker Header, der aber durch den Adreßraum größer ist als der alte Header. Dabei haben die einzelnen Felder folgende Bedeutung: Version: Auch hier wurde ein 4-Bit-Feld mit der binären Versionsnummer des Protokolls vorgesehen, zum einen um neue experimentelle Protokolle zuzulassen, zum anderen um einen reibungslosen Übergang von IPv4 zu IPv6 zu gewährleisten. 15

17 Abbildung 9: Der Basisheader von IPv6 Übertragungsart (Traffic Class): Dieses 8 Bit lange Feld dient den weiterleitenden Routern dazu, das Paket gesondert zu behandeln. Der Wert in diesem Feld soll dem Router eine Prioritätsunterscheidung geben. Jedoch ist dieses Feld noch nicht standardisiert und noch in der Entwicklung. Die Arbeitsgruppe DIFFSERV der IETF kümmert sich um die Standardisierung. Datenflußfeld (Flow Label): Auch dieses Feld ist noch nicht standardisiert. In diesem 20-Bit-Feld soll eine Kennziffer stehen, die eine Zufallszahl ist und den Routern bei der Verarbeitung von eventuellen Videooder Audiodaten als Hashcode dient. Die Datagramme sollen dann auf einem vordefinierten Pfad befördert werden. Rechner oder Router, die diese Dienstunterscheidung nicht anbieten, sollen das Feld auf 0 setzen, wenn sie das Paket passiert oder ignorieren, wenn sie der Empfänger sind. Nutzdatenlänge (Payload Length): Hier steht die Anzahl der Oktette beziehungsweise Bytes, die nach dem Basisheader folgen (inklusive allen eventuellen Erweiterungsheadern). Mit 16 Bit sind demnach Byte als Nutzdatenlänge möglich. (Mit einem sogenannten Jumbogramm sind noch größere Nutzdaten realisierbar). Nächster Header (Next Header): In diesem 8-Bit-Feld steht die standardisierte Kennziffer des Protokolls, welches sich dem Basisheader anschließt. Dabei kann das auch ein Erweiterungsheader sein oder das Protokoll der nächsthöheren Schicht, falls keine Erweiterungsheader folgen. Hop Limit: Dies ist eine Eigenschaft, die man vom alten Protokoll übernommen hat. Das Hop-Limit-Feld ist das Pendant zum Time-to-Live-Feld von IPv4 und wird bei jeden Routerschritt um 1 dekrementiert und ganz verworfen wenn es 0 enthält. Dabei kann in dem 8-Bit-Feld ein maximaler Wert von 255 stehen und die gleiche Anzahl an Routern überstehen. Absenderadresse (Source Address): Die wichtigste Neuerung des 16

18 neuen Protokolls ist eindeutig der 128-Bit-Adreßraum. Hier steht die Adresse des Senders. Zieladresse (Destination Address): Hier kommt entweder die 128-Bit- Adresse des Empfängers oder, falls ein Routing Header folgt, die Adresse des ersten Routers auf dem vorbestimmten Pfad hinein. 4.2 Die Erweiterungsheader Wie eingangs erwähnt dienen die Erweiterungsheader dazu, überflüssige Informationen, die der Dienst nicht benötigt, aus dem Header herauszunehmen. Doch wurde dieses Prinzip auch eingeführt, da es weitsichtig ist und man bei eventuellen technologischen Neuerungen neue Erweiterungsheader hinzufügen kann. Außer dem Destination-Options-Header kann jeder dieser Zusatzheader höchstens einmal in der Abarbeitung auftauchen. Diese Header sind optional und müssen nicht unbedingt verwendet werden. In diesem Fall ist der Wert im Nächster Header -Feld der vordefinierte Wert des Protokolls der höheren Schicht. Wenn aber mindestens ein Erweiterungsheader zwischen Basisheader und dem Protokoll der nächsthöheren Schicht ist, müssen die Werte der Nächster Header -Felder entsprechend angepaßt werden (siehe Abb. 10) Abbildung 10: Das Prinzip der Erweiterungsheader Die Router ignorieren alle Erweiterungsheader außer den Hop-by-Hop Options Header, damit die Datagramme schnell im Netz vorankommen. Dieser Hop-by-Hop-Options Header trägt Informationen, die von jeden Router ausgewertet werden müssen. Da die Erweiterungsheader sequentiell abgearbeitet werden müssen und ein Überspringen nicht möglich ist, muß der Hop-by-Hop- Options Header unmittelbar nach dem Basisheader stehen. Die übrigen Erweiterungsheader werden dann erst vom Rechner mit der Zieladresse des Basisheaders ausgewertet. Jeder dieser Erweiterungsheader ist ein Vielfaches von 8 Byte lang. Es gibt bis jetzt 6 verschiedene Erweiterungsheader: Hop-by-Hop Options Header Routing Header Fragment Header Destination Options Header Authentication Header Encapsulating Security Payload Header 17

19 In diesem Dokument werden jedoch nur die ersten 4 erläutert. Der Authentication Header und der Encapsulating Security Payload Header sind sicherheitsrelevante Zusatzheader, die den Rahmen dieses Papiers sprengen würden. Diese beiden Header sind in den RFCs 2402 und 2406 definiert. Damit die Erweiterungsheader effizient abgearbeitet werden können, ist es wichtig, daß sie in einer vordefinierten Reihenfolge stehen. Nach dem IPv6 Basisheader muß, wie bereits erwähnt der Hop-by-Hop-Options Header stehen. Auf diesen folgt ein Destinations Options Header, welcher Informationen beinhaltet, die für den Rechner mit der Zieladresse aus dem Basisheader bestimmt sind. Dies kann auch ein Router sein, wenn ein Routing Header eingespannt ist. Ist dies der Fall, so wird dieser Destination Options Header von jedem Router auf dem Weg zum endgültigen Zielrechner ausgewertet. Nach dem ersten Destination Options Header folgt schließlich der Routing Header, welcher eine Liste mit Zwischenstationen beinhaltet. Diesem folgt der Fragment Header, der vom Zielrechner ausgewertet werden muß, wenn das Ursprungsdatagramm zu groß war für den vorgesehenen Datenpfad. Nach dem Informationen zur Reassemblierung folgen die sicherheitsrelevanten Authentication und Encapsulating Security Payload Header. Wenn die Sicherheit klargestellt ist folgt nunmehr der Destination Options Header für den eigentlichen Zielrechner. Ist dieser ausgewertet, werden die Nutzdaten an die nächsthöhere Protokollschicht weitergereicht. Bei dieser eben genannten Reihenfolge ist es klar, daß neue Erweiterungsheader nicht einfach irgendwo eingefügt werden können. Die Abarbeitungslogik eines jeden neuen Headers muß daher vorher festgelegt werden. Doch nicht nur die Abarbeitung der einzelnen Header ist zeitkritisch. Damit der Destination Options und der Hop-by-Hop Options Header, welche nebenbei bemerkt bis jetzt die einzigen Header sind, die eine variable Länge haben, schnell abgearbeitet werden können, besitzen sie sogenannte Type-Length-Value (TLV) Optionsfelder (siehe Abb. 11). Dabei bedeuten die Felder: Abbildung 11: Die TLV-Optionen Optionstyp (Option Type): Ist ein 8 Bit langer Bezeichner, der den vordefinierten Typ der Option angibt. Optionslänge (Option Data Length): Dieses Feld ist ebenfalls 8 Bit groß und gibt die Länge der kompletten Option in Byte an. Dies ist wichtig, falls die Option ignoriert werden soll, steht hier die Adresse der nächsten Option. Optionsdaten (Option Data): In diesem Feld, welches eine variable 18

20 Länge haben kann (aber höchstens 255 Byte) stehen die spezifischen Daten zu dieser Option (mit dem jeweiligen Optionsbezeichner). Die Optionen müssen genauso wie die Erweiterungsheader selber, strikt sequentiell abgearbeitet werden. Wenn ein Rechner bei der Auswertung auf einen Optionstyp stößt, der ihm unbekannt ist, so werden mit den zwei höchsten Bit des Optionstyps festgelegt, wie wichtig das Feld ist und wie der Rechner nun darauf reagieren soll: 00 : diese Option kann übersprungen werden und bei der nächsten Option kann weitergearbeitet werden 01 : das geamte Paket muß verworfen werden 10 : das gesamte Paket muß verworfen werden und es muß eine ICMP-- Nachricht an den Absender geschickt werden, die auf diese nicht erkannte Option hinweist 11 : das gesamte Paket muß verworfen werden und falls die Zieladresse keine Multicastadresse war, muß eine ICMP-Fehlermeldung an die Quelle geschickt werden Das dritthöchste Bit des Optionstyp-Feldes legt fest, ob die Optionsdaten der Option auf dem Weg zum Ziel veränderbar sind. Dabei steht eine binäre 0 für unveränderlich und eine 1 für veränderbar. Gibt es einen Authentication Header, müssen die veränderbaren Optionsfelder bei der Berechnung der Prüfsumme des Authentication Headers als Felder mit lauter binären Nullen betrachtet werden, so daß diese nicht verantwortlich sind für das Verwerfen des Pakets beim Zielrechner. Damit die Options Header die vorgeschriebene Länge des Vielfachen von 8 Byte vorweisen kann werden die variablen Optionen mit Pads, also Auffüll - Optionen vervollständigt (werden mit 0 gefüllt). Dabei gibt es eine Pad1 Option, welche eingesetzt wird, wenn nur 1 Byte aufgefüllt werden muß und von der PadN Option wird Gebrauch gemacht, wenn mehrere Bytes aufgefüllt werden müssen Der Hop-by-Hop Options Header Der Hop-by-Hop Options Header ist der Header, der von jedem Router ausgewertet werden muß, da er Informationen für diese birgt. Steht eine binäre 0 im Nächster Header -Feld des Basisheaders, so schließt sich dieser Header an. Dieser Erweiterungsheader hat den folgenden Aufbau: Nächster Header (Next Header): Dieses 8 Bit lange Feld gibt die definierte Identifikationsnummer des anschließenden Headers beziehungsweise Protokolls an. Headerlänge (Header Extension Length): Dieses 8 Bit lange Feld gibt die Länge des Headers in 8-Byte-Einheiten an außer der ersten 8 Bytes. Damit kann ein Hop-by-Hop Options Header maximal 2040 Byte lang sein. 19

21 Optionen (Options): Hier stehen nun die Optionen in TLV-Kodierung. Bis jetzt wurde erst eine Option für den Hop-by-Hop Options Header spezifiziert. Doch hat diese Bedeutung hinsichtlich der Multimediatauglichkeit von IPv6. Gemeint ist die Jumbogramm-Option (siehe Abb. 12). Abbildung 12: Das Jumbogramm Diese Option hat den dezimalen Optionsbezeichner 197, was bedeutet, daß die ersten beiden signifikanten Bits 11 sind und somit wird das gesamte Paket von einem Router verworfen, der die Option nicht kennt und eine ICMP- Fehlermeldung an den Sender des Pakets geschickt, falls der Empfänger keine Multicastadresse war. Das dritte signifikante Bit ist eine 0 und somit ist die Jumbogramm-Option eine unveränderbare Option. Die Optionslänge beträgt 4 Byte. In diesem 4 Byte großen Optionsdaten- Feld steht nun die Länge des Jumbogramms in Byte. Mit diesen 32 Bit kommt man auf die sagenhafte Maximallänge des Jumbogramms von 4096 Megabyte oder 4 Gigabyte. Voraussetzung für diese Option ist, das es kein Vorkommen eines Fragment Headers gibt und in dem Nutzdaten-Feld des Basisheaders eine binäre 0 steht Der Routing Header Dieser Erweiterungsheader ist dazu da, einem IP-Datagramm einen vordefinierten Weg mit auf den Weg zu geben. Dabei kann der Header eine Liste von 1 bis 127 IP-Adressen enthalten, die er passieren muß. Wenn im Next-Header-Feld des vorangestellten Erweiterungsheaders beziehungsweise des Basisheaders eine binäre 43 steht, folgt dieser Erweiterungsheader, der folgende Felder enthält: Nächster Header (Next Header): Wie bei jedem anderen Erweiterungsheader auch, steht in diesem 8-Bit-Feld die Kennziffer des folgenden Headers oder Protokolls. Headerlänge (Header Extension Length): Dieses 8 Bit große Feld gibt die Headerlänge in 8-Byte-Einheiten ausgenommen der ersten 8 Bytes an. Je nachdem, wieviel Platz die TLV-kodierten typspezifischen Optionen belegen, kann man bis zu 127 Adressen in die Liste aufnehmen. Routing Typ (Routing Type): Mit diesem 8-Bit-Feld wird die Art des Routings angegeben. Dabei bekommt der Router die Information, was er im typspezifischen Optionsfeld vorfinden kann. Segmente übrig (Segments left): In diesem 8-Bit-Feld steht eine Zahl in Binärdarstellung, welche die Anzahl der noch zu besuchenden Router enthält, bevor der eigentliche Zielrechner erreicht wird. 20

22 Typspezifische Optionen (type-specific data): Dieses Feld kann eine variable Länge haben, in denen für den jeweiligen Routing Typ wichtige Informationen TLV-kodiert abgelegt sind. Es gibt bis jetzt erst einen Routing Typ, der mit der Kennziffer 0 ausgezeichnet wird. Dieser sah in einer früheren Fassung eine Unterscheidung zwischen Loose Source 33 - und Strict Source 34 -Routing vor. Doch man entschied sich vorerst nur das Loose Source Routing zu implementieren und so stehen an Stelle der typspezifischen Optionen ein 4 Byte umfassender Bereich gefüllt mit binären Nullen, welches beim Empfänger ignoriert wird. In solch einem Typ-0-Routing Header dürfen keine Multicastadressen vorkommen. Um sich die Funktionsweise dieses Headers zu verdeutlichen, betrachten Sie die Abbildung 13: Abbildung 13: Arbeitsweise des Typ-0-Routing Headers In dieser vereinfachten Darstellung will der Quellrechner ein IP-Datagramm über selber definierte Zwischenstationen schicken. Er schreibt dabei die Adresse der ersten Station in das Zieladressen-Feld des Basisheaders und die folgenden in der richtigen Reihenfolge (inklusive des Zielrechners) in die Tabelle des Headers. Das Segmente-übrig-Feld wird nun, da die 3 Adressen in der Tabelle noch nicht passiert wurden sind, auf 3 gesetzt. Wenn das Datagramm beim Router1 angekommen ist, tauscht dieser die erste Adresse der Tabelle mit der Adresse in dem Zieladresse-Feld des Basisheaders und setzt das Segmente-übrig-Feld um 1 herunter. Dieser Vorgang wiederholt sich bis zum Zielrechner. Dieser überprüft das Segmente-übrig-Feld und bemerkt so, daß er der Zielrechner ist. Er kann mit der Abarbeitung des folgenden Erweiterungsheaders oder Protokolls fortfahren. In der Tabelle des Routing Headers stehen schließlich alle Router, die das Datagramm mindestens passieren mußte Der Fragment Header Ein Nachteil des alten Protokolls war es, daß Datagramme, wenn sie zu groß waren für die maximal mögliche Paketgröße eines Netzes (MTU), vom Router aufwendig fragmentiert werden mußten. Die Entwickler einigten sich darauf diese Last vom Netz zu nehmen und dem Hostrechnern selber zu überlassen. Daher wird ein IPv6-Router, falls er doch noch in solch eine Situation gerät, das 33 Hierbei können die einzelnen Router auch über andere Zwischenstationen erreicht werden 34 In diesem Fall müssen die Router, so wie sie in der Tabelle stehen, passiert werden ohne weitere Zwischenstationen zu passieren 21

23 Paket ganz einfach verwerfen und eine ICMP-Fehlermeldung an den Absender schicken. Der Fragment Header besteht dabei aus: Nächster Header (Next Header): Das obligatorische 8-Bit-Kennfeld für den nächsten Erweiterungsheader oder das nächsthöhere Protokoll. Reserviert (Reserved): Ein 8-Bit-Feld, dessen Verwendung noch nicht klar ist. Dabei wird es beim Versenden mit 0 gefüllt und beim Empfang ignoriert. Fragment Offset: Dies ist das Pendant zum gleichnamigen Feld des alten Protokolls und gibt ebenfalls die relative Adresse in Bytes vom fragmentierbaren Teil des Ursprungsdatagramm an. Mit 13 Bit hat dieses Feld nicht nur den Namen geerbt, sondern auch die Größe. Reserviert (Res): Diese 2 Bit sind zur späteren Verwendung reserviert und werden momentan noch mit 0 aufgefüllt und beim Empfang ignoriert. Mehr Fragmente Flag (M): Diese 1-Bit-Information sagt aus, ob nach einem Fragment noch weitere angehängt werden oder ob es das letzte in der Kette ist. Dabei steht 0 für keine Fragmente mehr und 1 für weitere Fragmente. Identifikation (Identification): Auch dieses Feld wurde von IPv4 geerbt, mit dem Unterschied, daß es mit 32 Bit jetzt doppelt so groß ist. Dabei soll dieses Feld eine eindeutige Identifikationsnummer für das Fragment sein, um beim Wiederzusammensetzen das ursprüngliche Datagramm bestimmen zu können. Wenn ein IPv6-Datagramm absgeschickt werden muß, wird vorher iterativ festgestellt, ob die MTU des vorhergesehenen Pfades auch die Paketgröße nicht unterschreitet. Dieser Vorgang heißt Path-MTU-Discovery und er obliegt dem ICMPv6 Protokoll. Wenn nun doch ein solcher Engpaß auftritt, muß das Paket fragmentiert werden. Dabei wird zwischen einem unfragmentierbaren und einem fragmentierbaren Teil unterschieden (siehe Abb. 14). Bei dem unfragmentierbaren Teil handelt es sich selbstverständlich um die Header, welche auf den Weg zum Ziel ausgewertet werden müssen. Dies ist natürlich der Basisheader. Falls ein Hop-by-Hop Options Header vorliegt, darf auch dieser nicht fragmentiert werden. Ein eventuell vor ein Routing Header vorgelagerter Destination Options Header mit Informationen für die Router und natürlich der Routing Header selber dürfen, wenn sie vorhanden sind, nicht fragmentiert werden. Der fragmentierbare Teil sind natürlich nur die Header, welche erst beim Zielrechner ausgewertet werden. Dies sind momentan die sichherheitsrelevanten Header und der Destination Options Header für den Zielrechner, sowie die Nutzdaten mit dem Protokollheadern der höheren Schichten. 22