Es wird wohl noch etwas länger dauern, bis dieser Abschnitt der Arbeit endlich fertig ist, da ich im Moment ziemlich viele andere Dinge zu tun habe. Für alle, die aber jetzt schon mehr wissen wollen wenigstens ein Link auf eine englischsprachige Beschreibung von IPv6: Hinden R.: IP Next Generation (IPng)..

Die Zukunft

Das rasche (exponentielle Wachstum) des Internet zwingt dazu, das Internet Protokoll in der Version 4 (IPv4) durch ein Nachfolgeprotokoll zu ersetzen.

Bis vor einiger Zeit wurde das Internet größtenteils nur von Universitäten, Regierungsbehörden (dies aber auch fast nur in den USA und hier vor allem vom Verteidigungsministerium) und einigen Firmen aus der Industrie genutzt. Seit der Einführung des World Wide Web (WWW) ist das Internet aber auch zunehmend für Privatpersonen, kleinere Firmen etc. interessant. Das Internet wandelt sich von einem "Spielplatz für Akademiker" zu einem weltweiten Informations- und Unterhaltungssystem. Mit der ständig steigenden Anzahl von Benutzern des Internet werden sich auch die Anforderungen an das Netz ändern bzw. haben sich bereits geändert. Genannt sei hier nur als Beispiel das angestrebte Zusammenwachsen der Computer-, Unterhaltungs- und Telekommunikationsbranchen. Den Anforderungen, die z.B. Video-on-demand stellt, ist das Internet bzw. das Internet Protokoll in der Version 4 nicht gewachsen.

Vinton Cerf (der 'Vater' des Internet) bezeichnet in einem Interview mit der Zeitschrift c't [Kr98] das Internet "(...) als die wichtigste Infrastruktur für alle Arten von Kommunikation.". Auf die Frage, wie man sich die neuen Kommunikationsdienste des Internet vorstellen könne, antwortete Cerf:

"Am spannendsten finde ich es, die ganzen Haushaltsgeräte ans Netz anzuschließen. Ich denke dabei nicht nur daran, daß der Kühlschrank sich in Zukunft mit der Heizung austauscht, ob es in der Küche zu warm ist. Stromgesellschaften könnten beispielsweise Geräte wie Geschirrspülmaschinen kontrollieren und ihnen Strom genau dann zur Verfügung stellen, wenn gerade keine Spitzennachfrage herrscht. Derartige Anwendungen hängen allerdings davon ab, daß sie zu einem erschwinglichen Preis angeboten werden. Das ist nicht unbedingt ferne Zukunftsmusik; die Programmierer müßten eigentlich nur damit anfangen, endlich Software für intelligente Netzwerkanwendungen zu schreiben. Und natürlich muß die Sicherheit derartiger Systeme garantiert sein. Schließlich möchte ich nicht, daß die Nachbarkinder mein Haus programmieren!"

Auf die Internet Protokolle kommen in der nächsten Zeit also völlig neue Anforderungen zu. Wie versucht wird, diese Anforderungen zu erfüllen, wird in den nächsten Abschnitten beschrieben.

Classless InterDomain Routing - CIDR

Der Verknappung der Internet-Adressen durch die ständig steigende Benutzerzahl wird zunächst versucht, mit dem Classless InterDomain Routing (CIDR) entgegen zu wirken.

Durch die Vergabe von Internet-Adressen in Klassen (Netze der Klassen A,B,C,...) wird eine große Anzahl von Adressen verschwendet. Hierbei stellt sich vor allem die Klasse B als Problem dar. Viele Firmen nehmen ein Netz der Klasse B für sich in Anspruch, da ein Klasse A Netz mit bis zu 16 Mio. Hosts selbst für eine sehr große Firma überdimensioniert scheint. Tatsächlich ist aber oft auch ein Klasse B Netz zu groß. Für viele Firmen würde ein Netz der Klasse C ausreichen. Dies wurde aber nicht verlangt, da viele Unternehmen die Befürchtung hatten, daß ein Klasse C Netz mit seinen bis zu 254 möglichen Hosts nicht ausreichen würde.

Ein größeres Hostfeld für Netze der Klasse C (z.B. 10 Bit, das entspricht 1022 Host pro Netz) hätte das Problem der knapper werdenden IP-Adressen vermutlich gemildert. Ein anderes Problem wäre dadurch allerdings entstanden: die Einträge der Routing-Tabellen wären explodiert.

Ein anderes Konzept ist das Classless InterDomain Routing (RFC 1519): die verbleibenden Netze der Klasse C werden in Blöcken variabler Größe zugewiesen. Werden beispielsweise 2000 Adressen benötigt, so können einfach acht aufeinanderfolgende Netze der Klasse C vergeben werden; das entspricht einem Block von 2048 Adressen. Zusätzlich werden die verbliebenen Klasse C Adressen restriktiver und strukturierter vergeben (RFC 1519). Die Welt ist dabei in vier Zonen, von denen jede einen Teil des verbliebenen Klasse C Adreßraums erhält, aufgeteilt:

Jede der Zonen erhält dadurch in etwa 32 Millionen Adressen zugewiesen. Vorteil bei diesem Vorgehen ist, daß die 32 Millionen Adressen einer Region im Prinzip zu einem Eintrag in den Routing-Tabellen komprimiert worden sind. Der Vorteil der dadurch entsteht ist, daß z.B. jeder Router, der eine Adresse außerhalb seiner Region zugesandt bekommt...

Internet Protokoll Version 6 - IPv6 (IP Next Generation)

Der vorrangige Grund für eine Änderung des IP-Protokolls ist auf den begrenzten Adreßraum zurückzuführen. CIDR schafft hier zwar wieder etwas Luft, dennoch ist klar absehbar, daß auch diese Maßnahmen nicht ausreichen, um die Verknappung der Adressen für eine längere Zeit in den Griff zu bekommen.

Weitere Gründe für eine Änderung des IP-Protokolls sind die oben schon erwähnten neuen Anforderungen an das Internet. Diesen Anforderungen ist IP in der Version 4 nicht gewachsen. Die IETF (Internet Engineering Task Force) begann deshalb 1990 mit der Arbeit an einer neuen Version von IP. Die wesentlichen Ziele des Projekts sind [Ta96]:

• Unterstützung von Milliarden von Hosts, auch bei ineffizienter Nutzung des Adreßraums
• Reduzierung des Umfangs der Routing-Tabellen
• Vereinfachung des Protokolls, damit Router Pakete schneller abwickeln können
• Höhere Sicherheit (Authentifikation und Datenschutz) als das heutige IP
• Mehr Gewicht auf Dienstarten, insbesondere für Echtzeitanwendungen
• Unterstützung von Multicasting durch die Möglichkeit, den Umfang zu definieren
• Möglichkeit für Hosts, ohne Adreßänderung auf Reise zu gehen
• Möglichkeit für das Protokoll, sich zukünftig weiterzuentwickeln
• Unterstützung der alten und neuen Protokolle in Koexistenz für Jahre

Im Dezember 1993 forderte die IETF mit RFC 1550 [IP: Next Generation (IPnG) White Paper Solicitation, Dec. 1993] die Internet-Gemeinde dazu auf, Vorschläge für ein neues Internet Protokoll zu machen. Auf die Anfrage wurde eine Vielzahl von Vorschlägen eingereicht. Diese reichten von nur geringfügigen Änderungen am bestehenden IPv4 bis zur vollständigen Ablösung durch ein neues Protokoll. Die drei besten Vorschläge wurden im IEEE Network Magazine veröffentlicht ([De93], [Fr93], [KF93]). Aus diesen Vorschlägen wurde von der IETF das Simple Internet Protocol Plus (SIPP) als Grundlage für die neue IP-Version ausgewählt. SIPP ist eine Kombination aus den Vorschlägen von Deering [De93] und Francis [Fr93].

Als die Entwickler mit den Arbeiten an der neuen Version des Internet Protokolls begannen, wurde natürlich auch ein Name für das Projekt bzw. das neue Protokoll benötigt. Wohl angeregt durch eine gleichnamige Fernsehsendung, wurde als Arbeitsname IP - Next Generation (IPnG) gewählt. Schließlich bekam das neue IP eine offizielle Versionsnummer zugewiesen: IP Version 6 oder kurz IPv6. Die Protokollnummer 5 (IPv5) wurde bereits für ein experimentelles Protokoll verwendet.

Die folgende Beschreibung von IPv6 orientiert sich an RFC 2460 [Internet Protocol, Version 6 (IPv6) Specification, Dec. 1998]. Dieses Dokument gibt den neuesten Stand der Spezifikation des Internet Protokolls in der Version 6 wieder. RFC 2460 enthält einige wesentliche Änderungen der Spezifikation gegenüber RFC 1883 [Internet Protocol, Version 6 (IPv6) Specification, Dec. 1995].

Die Merkmale von IPv6

Viele der als erfolgreich betrachteten Merkmale von IPv4 bleiben in IPv6 voll erhalten. Trotzdem ist IPv6 im allgemeinen nicht mit IPv4 kompatibel, wohl aber zu den weiteren Internet-Protokollen, insbesondere den Protokollen der Transportschicht (TCP, UDP); eventuell nach geringfügigen Modifikationen. Die Modifikationen betreffen im wesentlichen die erweiterte Adreßgröße (bisher 32 Bit auf nun 128 Bit).

Die wesentlichen Merkmale von IPv6 sind:

• Adreßgröße: Als wichtigstes Merkmal hat IPv6 gegenüber IPv4 größere Adressen. Statt bisher 32 Bit stehen nun 128 Bit für die Adressen bereit. Theoretisch lassen sich damit 2¹²⁸ = 3.4*10³⁸ Adressen vergeben.
• Header-Format: Der IPv6 (Basis)Header wurde vollständig geändert. Der Header enthält nur 7 statt bisher 13 Felder. Diese Änderung ermöglicht Routern, Pakete schneller zu verarbeiten. Im Gegensatz zu IPv4 gibt es bei IPv6 nicht mehr nur einen Header, sondern mehrere Header. Ein Datengramm besteht aus einem Basis-Header, sowie einem oder mehreren Zusatz-Headern, gefolgt von den Nutzdaten.
• Erweiterte Unterstützung von Optionen und Erweiterungen: Die Erweiterung der Optionen ist notwendig geworden, da einige, bei IPv4 notwendige Felder nun optional sind. Darüber hinaus unterscheidet sich auch die Art, wie die Optionen dargestellt werden. Für Router wird es damit einfacher, Optionen, die nicht für sie bestimmt sind, zu überspringen. Dies ermöglicht ebenfalls eine schnellere Verarbeitung von Paketen.
• Dienstarten: IPv6 legt mehr Gewicht auf die Unterstützung von Dienstarten. Damit kommt IPv6 den Forderungen nach einer verbesserten Unterstützung der Übertragung von Video- und Audiodaten entgegen. IPv6 bietet hierzu eine Option zur Echtzeitübertragung.
• Sicherheit: IPv6 beinhaltet nun im Protokoll selbst Mechanismen zur sicheren Datenübertragung. Wichtige neue Merkmale von IPv6 sind hier Authentifikation (authentication), Datenintegrität (data integrity) und Datenverlässlichkeit (data confidentiality).
• Erweiterbarkeit: IPv6 ist ein erweiterbares Protokoll. Bei der Spezifikation des Protokolls wurde nicht versucht alle potentiell möglichen Einsatzfelder für das Protokoll in die Spezifikation zu integrieren. Vielmehr bietet IPv6 die Möglichkeit über Erweiterungs-Header (s.u.) das Protokoll zu erweitern. Damit ist das Protokoll offen für zukünftige Verbesserungen.

Das IPv6 Datengrammformat

Ein IPv6-Datengramm besteht aus dem Basis-Header (s.u. Der IPv6-Basis-Header), gefolgt von den optionalen Zusatz-Headern (s.u. Erweiterungs-Header) und den Nutzdaten.

Allgemeine Form eines IPv6-Datengramms.

Der IPv6-Basis-Header

Der IPv6-Basis-Header ist doppelt so groß wie der IPv4-Header. Der IPv6-Basis-Header enthält weniger Felder als der IPv4-Header, dafür ist aber die Adreßgröße für die Quell- und Zieladresse von bisher 32-Bit auf nunmehr 128-Bit erweitert worden.

IPv6 Basis-Header.

Version:

Mit dem Feld Version können Router überprüfen, um welche Version des Protokolls es sich handelt. Für ein IPv6-Datengramm ist dieses Feld immer 6 und für ein IPv4-Datengramm dementsprechend immer 4. Mit diesem Feld ist es möglich für eine lange Zeit die unterschiedlichen Protokollversionen IPv4 und IPv6 nebeneinander zu verwenden. Über die Prüfung des Feldes Version können die Daten an das jeweils richtige "Verarbeitungsprogramm" weitergeleitet werden.

Priority:

Das Feld Priority (oder Traffic Class) ...

Flow Label

Das Feld Flow Label...

Payload Length

Das Feld Payload Length (Nutzdatenlänge) gibt an, wie viele Bytes dem IPv6-Basis-Header folgen, der IPv6-Basis-Header ist ausgeschlossen. Die Erweiterungs-Header werden bei der Berechnung der Nutzdatenlänge mit einbezogen. Das entsprechende Feld wird in der Protokollversion 4 mit Total Length bezeichnet. Allerdings bezieht IPv4 den 20 Byte großen Header auch mit in die Berechnung ein, wodurch die Bezeichnung "total length" gerechtfertigt ist.

Next Header

Das Feld Next Header gibt an, welcher Erweiterungs-Header dem IPv6-Basis-Header folgt. Jeder folgende Erweiterungs-Header beinhaltet ebenfalls ein Feld Next Header, das auf den nachfolgenden Header verweist. Ist dies der letzte zu IPv6 zugehörige Header, so gibt das Feld an, welches Transportprotokoll (z.B. TCP oder UDP) folgt. Eine genauere Beschreibung des Konzepts mehrerer Header folgt im Abschnitt Erweiterungs-Header.

Hop Limit

Mit dem Feld Hop Limit wird festgelegt, wie lange ein Paket überleben darf. Der Wert des Feldes wird nach jeder Teilstrecke gesenkt. Ein Datengramm wird dann verworfen, wenn das Feld Hop Limit auf Null herunter gezählt ist, bevor das Datengramm sein Ziel erreicht hat. IPv4 verwendet hierzu das Feld Time to Live, welches die Zeit in Sekunden angibt, die ein Paket überleben darf. Allerdings wird dieses Feld von den meisten Routern nicht so interpretiert. In IPv6 wurde das Feld deshalb umbenannt, um die tatsächliche Nutzung wiederzugeben.

Source Address, Destination Address

Die beiden Felder Quell- und Zieladresse dienen zur Identifizierung des Senders und Empfängers eines IP-Datengramms. IPv6 verwendet zur Adressierung 4 mal so große Adressen wie IPv4: 128 Bit statt 32 Bit. Eine genaue Beschreibung der IPv6-Adressen folgt im Abschnitt IPv6-Adressierung.

Ein Vergleich des IPv4-Headers mit dem IPv6-Basis-Header veranschaulicht, welche Felder bei IPv6 weggelassen wurden:

• Das Feld Length (Internet Header Length - IHL) ist nicht mehr vorhanden, da der IPv6-Basis-Header eine feste Länge von 40 Byte hat. Bei IPv4 ist dieses Feld notwendig, da der Header aufgrund der Optionen eine variable Länge hat.
• Das Feld Protocol wird nicht mehr benötigt, da das Feld Next Header angibt, was nach dem letzten IP-Header folgt (z.B. TCP oder UDP).
  
• Alle Felder die bisher zur Fragmentierung eines IP-Datengramms benötigt wurden (Identification, Flags, Fragment Offset), sind im IPv6-Basis-Header nicht mehr vorhanden, da die Fragmentierung in IPv6 gegenüber IPv4 anders gehandhabt wird. Alle IPv6 kompatiblen Hosts und Router müssen Pakete mit einer Größe von 1280 Byte (RFC 1883 legte diese Größe noch auf 576 Byte fest) unterstützen. Durch diese Regel wird eine Fragmentierung im Prinzip nicht notwendig. Empfängt ein Router ein zu großes Paket, so führt er keine Fragmentierung mehr durch, sondern sendet eine Nachricht an den Absender des Pakets zurück. In dieser Nachricht wird der sendende Host angewiesen, alle weiteren Pakete zu diesem Ziel aufzuteilen. Das bedeutet, daß von den Hosts "erwartet" wird, daß sie von vornherein eine Datengrammgröße wählen, die keine Fragmentierung voraussetzt. Dadurch wird eine größere Effizienz bei der Übertragung erreicht, als wenn Pakete von Routern auf dem Weg fragmentiert werden müssen. Die Steuerung der Fragmentierung erfolgt bei IPv6 über den Fragment Header.
• Das Feld Checksum ist nicht mehr vorhanden, da die Berechnung der Prüfsumme sich nachteilig auf die Leistung der Datenübertragung ausgewirkt hat. Das entfernen der Prüfsumme aus dem Internet Protokoll hat zu heftigen Diskussionen geführt [Ta96]. Die eine Seite kritisierte heftig das entfernen der Prüfsumme, während die andere Seite argumentierte, daß Prüfsummen etwas sind, das auch von Anwendungen übernommen werden kann, sofern sich die Anwendung tatsächlich um Datenintegrität kümmert. Ein weiteres Gegenargument war, daß eine Prüfsumme auf der Transportschicht bereits vorhanden ist, weshalb innerhalb der Vermittlungsschicht keine weitere Prüfsumme notwendig sei. Letztendlich fiel die Entscheidung, daß IPv6 keine Prüfsumme enthält.

Erweiterungs-Header

IPv6 nutzt das Konzept der Erweiterungs-Header, um a) eine effiziente Datenübertragung und b) eine Erweiterung des Protokolls zu ermöglichen. Der erste Punkt ist leicht ersichtlich: Der Basis-Header enthält nur Felder, die unbedingt für die Übermittlung eines Datengramms notwendig sind, erfordert die Übertragung weitere Optionen, so können diese über einen Erweiterungs-Header angegeben werden. IPv6 sieht vor, das einige Merkmale des Protokolls nur gezielt benutzt werden. Ein gutes Beispiel ist hier die Fragmentierung von Datengrammen. Obwohl viele IPv4-Datengramme nicht fragmentiert werden müssen, enthält der IPv4-Header Felder, für die Fragmentierung. IPv6 gliedert die Felder für die Fragmentierung in einen separaten Header aus, der wirklich nur dann verwendet werden muß, wenn das Datengramm tatsächlich fragmentiert werden muß. Ein weiterer wesentlicher Vorteil des Konzepts der Erweiterungs-Header ist, daß das Protokoll um neue Funktionen erweitert werden kann. Es genügt, für das Feld Next Header einen neuen Typ und ein neues Header-Format zu definieren. IPv4 erfordert hierzu eine vollständige Änderung des Headers.

Derzeit sind 6 Erweiterungs-Header definiert. Alle Erweiterungs-Header sind optional. Werden mehrere Erweiterungs-Header verwendet, so ist es erforderlich, sie in einer festen Reihenfolge anzugeben.

Die ersten 5 Header sind in RFC 2460 (bzw. RFC 1883). Der Authentifikations-Header sowie der Header für Sicherheitsdaten werden in RFC 2402 (RFC 1826) und RFC 2406 (RFC 1827) beschrieben.

IPv6 Datengramme. (a) IPv6-Basis-Header und Nutzdaten; (b) IPv6-Basis-Header mit einem Zusatz-Header für Routing-Informationen, gefolgt von Nutzdaten.

Hop-by-Hop Options Header

Routing Header

Fragment Header

Destination Options Header

IPv6-Adressierung