Schlagwort-Archive: IPv6

IPv6 und die Privatsphäre

Veröffentlicht am von
Kommentar

Die in IPv6 gebotene Möglichkeit der Stateless Autoconfiguration erlaubt die Generierung einer eigenen IPv6 Adresse alleine aus dem jeweiligen Netzwerkpräfix und der IEEE 802 MAC-Adresse des Netzwerkendgeräts. Die MAC-Adresse besteht aus dem herstellerspezifischen Organizationally Unique Identifier (OUI) und einem gerätespezifischen Teil (Interface Identifier), der das Netzwerkendgerät identifiziert. Die Berechnung der IPv6-Adresse erfolgt nach einem vorgegebenem Schema (modified Extended Unique Identifier, modified EUI-64, siehe Abb. 7.37) und erlaubt daher umgekehrt die Identifikation eines Netzwerkendgeräts über dessen zugewiesene IPv6 Adresse. Da die meisten Netzwerkendgeräte nur von einer Person alleine genutzt werden (Personal Computer, Smartphone, etc.), erlaubt die Kenntnis der IPv6 Adresse, eine Datenspur, die ein Endgerät bei jeder Benutzung eines Dienstes im Internet hinterlässt, eindeutige Rückschlüsse auf die Identität des Endgeräts und damit auf dessen Benutzer. Damit ist es für Außenstehende möglich, schon auf der IP-Ebene des Netzwerks Rückschlüsse über das Benutzerverhalten zu ziehen und Bewegungsprofile zu erstellen.

Unter IPv4 waren derartige Möglichkeiten zum Rückschluss auf die Identität eines Benutzers nicht möglich, da die IP-Adressvergabe innerhalb eines Netzwerks meist durch das Dynamic Host Configuration Protocol (DHCP) geregelt wurde, das die IP-Adressen einfach nach Verfügbarkeit nur temporär zuweist. Zudem erschwert dies zusätzlich die Network Address Translation (NAT) Technologie, die den Aufbau und die Verwaltung ganzer Netzwerke unter einer einzigen IPv4 Adresse ermöglicht.

Zum Schutz der Privatsphäre wurden daher mit RFC 4941 die sogenannten ”IPv6 Privacy Extensions“ eingeführt. Diese erzeugen für die letzten 64 Bits der IPv6 Adresse zufällige Interface Identifier, die mit Hilfe einer MD5 Hashfunktion (Message Digest Algorithm 5) jeweils aus dem ursprünglichen Interface Identifier bzw. dem zuletzt berechneten MD5-Wert erzeugt werden und nur für eine begrenzte Zeit ihre Gültigkeit behalten. Damit wird einerseits eine Identifikation des Benutzers verhindert, aber andererseits auch das Führen einer permanenten IPv6 Adresse. Neben den IPv6 Privacy Extensions gibt es weitere Möglichkeiten zur Verschleierung der Benutzeridentität. So kann anstelle des in IPv6 zur Autokonfiguration eingesetzten Neighbor Discovery Protokolls (NDP) das Secure Neighbor Discovery Protocol (SEND) eingesetzt werden, das mit Hilfe kryptografischer Methoden einen neuen Interface Identifier (Cryptographically Generated Addresses, CGA) aus dem vorgegebenen Netzwerkpräfix, einem öffentlichen Schlüssel und einem Nonce-Wert berechnet. Sowohl IPv6 Privacy Extensions als auch CGA verwenden zur Berechnung des Interface Identifiers einen situationsabhängigen Nonce-Wert, so dass bei jeder neuen Netzwerkverbindung auch ein neuer Interface Identifier generiert wird.

IPv4 und IPv6 Tunneln (Tunneling)

Veröffentlicht am von
Kommentar

Bei dieser Variante der IPv4/IPv6 Protokollumsetzung werden IPv6-Datagramme innerhalb eines IPv4 Netzwerkes unverändert weitergegeben. Eine Interpretation des IPv6-Datagramms findet dabei jeweils nur auf Systemen statt, die IPv6-fähig sind. IPv6-Datagramme werden vollständig als Nutzlast in IPv4-Datagramme gekapselt und durch das IPv4 Netzwerk versendet. IPv6 wird in diesem Falle wie ein auf IPv4 aufgesetztes Protokoll betrieben, als würde es im Protokollstapel in einer höheren Protokollschicht liegen.

Die im IPv4-Datagramm verwendete Angabe zum Protokolltyp der transportierten Nutzlast ist im Falle von IPv6 die 41. Tunneling von IPv6-Datagrammen wird dann notwendig, wenn alle Netzwerkknoten zwischen den beiden IPv6 Kommunikationsendpunkten nicht über eine Dual-Stack Fähigkeit verfügen. Umgekehrt kann auch der Fall eintreten, in dem IPv4-Datagramme durch ein IPv6 Netzwerk transportiert werden müssen. In diesem Fall werden IPv4 Datenpakete als Nutzlast in IPv6-Datagrammen transportiert. Abb. 7.41 zeigt die Weiterleitung von IPv6-Datagrammen über einen IPv6 Tunnel innerhalb eines IPv4-only Netzwerks.

Parallele Implementation (Dual Stack Implementation) IPv4 und IPv6

Veröffentlicht am von
Kommentar

Bei dieser Variante kommen Systeme, insbesondere Router, zum Einsatz, die in der Lage sind, beide IP-Versionen gleichzeitig zu verstehen und in beiden Versionen zu kommunizieren. Ein Dual-Stack-fähiges Netzwerkendgerät wird auch als IPv4/IPv6 Knoten bezeichnet. Kommuniziert dieser mit einem IPv6- fähigen Netzwerkendgerät, geschieht dies über IPv6. Die Kommunikation mit einem älteren, ausschließlich IPv4-fähigen Netzwerkendgerät erfolgt über IPv4. Ein IPv4/IPv6 Rechner besitzt daher jeweils mindestens zwei IP-Adressen, eine IPv4 Adresse und eine IPv6 Adresse. Zur Adresskonfiguration werden auf IPv4-Seite entweder eine statische Konfiguration oder eine Konfiguration via DHCP eingesetzt, während die IPv6-Seite eine IPv6-eigene Autokonfiguration durchführen kann. Bei der Zuweisung von Domain Namen muss aber auf IPv6 speziell Rücksicht genommen werden. Darauf wird näher eingegangen, wenn der Domain Name Service in Abschnitt 9.2.1 ausführlich beschrieben wird.

Um den Dual Stack Betrieb in einem Netzwerk aufnehmen zu können, muss die komplette Netzwerksoftware der im Netzwerk befindlichen Router mit Hilfe eines entsprechenden Upgrades erneuert werden. Vorhandene Routingprotokolle müssen für beide Betriebsvarianten in zweifacher Ausfertigung vorgehalten werden jeweils für IPv4 und für IPv6. Die Abbildung zeigt die Kommunikation in einem Dual Stack Netzwerk: Rechner A ist für den Dual Stack Betrieb konfiguriert (Dual Stacked Host) und verfügt sowohl über eine IPv4 und eine IPv6 Adresse. Wenn Rechner A mit Rechner B kommunizieren will, fragt er den zuständigen DNS Server (Domain Name System) an bzgl. einer Adressübersetzung des Domain Namens von Rechner B in eine IP-Adresse. Im Falle von Rechner B gibt der DNS Server eine IPv4 Adresse zurück, über die dann eine IPv4-basierte Kommunikation zwischen A und B stattfinden kann. Wenn Rechner A mit Rechner C kommunizieren will, liefert der DNS Server eine IPv6 Adresse zurück und die Kommunikation zwischen A und C erfolgt über IPv6.

IPv4/IPv6 Übersetzung (IPv4/IPv6 Translation)

Veröffentlicht am von
Kommentar

Eine besondere Variante des Dual Stack Betriebs liegt darin, dass einige Systeme in der Lage sind, Anfragen von IPv6 Hosts anzunehmen, diese in IPv4- Datagramme umzusetzen und an einen IPv4 Adressaten weiterzuleiten. Die Antwort des IPv4 Geräts wird in umgekehrter Weise verarbeitet. Diese Variante sollte jedoch nur dann zum Einsatz kommen, wenn ein IPv6-only Netzwerkendgerät mit einem IPv4-only Netzwerkendgerät kommunizieren möchte. Da die beiden Protokolle IPv4 und IPv6 nicht vollständig kompatibel sind, kommt es bei der Übersetzung zu Informationsverlusten. Zudem wird der Internetschicht im Netzwerkprotokollstapel eine zusätzliche Komplexitätsebene hinzugefügt.

Aktuell hat sich in diesem Bereich die Stateless IP/ICMP Translation (SIIT) als Standardlösung durchgesetzt. Um die Kommunikation zwischen einem IPv4- fähigen und einem IPv6-fähigen Gerät zu ermöglichen, definiert RFC 2765 ein Verfahren zur Übersetzung der IPv6 Datenpaketheader (und ICMPv6 Datenpaketheader) in korrespondierende IPv4 Datenpaketheader (bzw. ICMP Datenpaketheader) und umgekehrt. Eine mögliche Anwendung des SIIT Verfahrens besteht im Aufbau eines neuen Netzwerksegments, das im reinen IPv6-Betrieb arbeitet. Dessen Datenverkehr wird mit Hilfe der SIIT Protokollübersetzung an reguläre IPv4-fähige Netzwerksegmente und auch an das Standard IPv4-fähige Internet angeschlossen. Zu diesem Zweck wurde ein spezieller IPv6 Adresstyp eingeführt, die ” IPv4-translatable address“.

Diese Adressen besitzen den Adresspräfix 0::ffff:0:0:0/96. Als Host Identifier wird an diesen Adresspräfix eine IPv4 Adresse angehängt, die aus einem speziellen Adresspool stammt. Der Adresspräfix wurde derart gewählt, dass er bei der in höheren Protokollschichten stattfindenden Prüfsummenberechnung stets den Wert Null ergibt und daher diese Prüfsummen nicht beeinflusst.

Koexistenz und Migration von IPv4 nach IPv6

Veröffentlicht am von
Kommentar

Eine Umstellung des Internet-Protokolls von IPv4 nach IPv6 von heute auf morgen ist schon alleine auf Grund der riesigen Größe des globalen Internets und der enormen Anzahl aller daran angeschlossener Rechner und Netzwerkkomponenten vollkommen unmöglich. Da das Internet Protokoll das grundlegende Protokoll der TCP/IP Protokollsuite ist, kann man den Austausch dieses Basisprotokolls mit dem Austausch des Fundaments eines Gebäudes vergleichen. Auch wenn dieses Bild zunächst etwas abwegig erscheint, ist jedem klar, dass der Austausch eines solchen Fundaments nur sehr vorsichtig erfolgen kann. Nutzt man diese Metapher weiter, kann man den globalen Umstieg auf das neue IPv6 Protokoll mit dem Austausch aller Gebäudefundamente auf der ganzen Welt vergleichen.

Tatsächlich liegt die konzeptionelle Spezifikation des IPv6-Protokolls bereits über ein Jahrzehnt zurück, aber in der Praxis birgt die Umstellung auf das neue Internet Protokoll zahlreiche Schwierigkeiten, die nicht alleine technisch bedingt sind, sondern vor allem auch ökonomischer Natur. Die bereits installierte IPv4 Hardwarebasis hat einen enormen Umfang, ein Umstieg auf IPv6 muss deshalb sorgfältig geplant und umgesetzt werden. Nahezu unbemerkt von den Endbenutzern erfolgt dieser schrittweise Umstieg bereits seit Jahren durch die Realisierung von Koexistenz- und Migrationsszenarien von IPv4 nach IPv6. Nahezu alle eingesetzten Betriebssysteme unterstützen heute IPv6. Ebenso unterstützen annähernd alle heute verfügbaren IPv6 Hardwarekomponenten auch den Umgang mit IPv4. Lediglich ältere, reine IPv4-basierte Hardwarekomponenten können ohne eine entsprechende Übersetzung nicht mit ausschließlich über IPv6 angebundenen Komponenten kommunizieren.

Der Schlüssel zu einer erfolgreichen Umstellung auf IPv6 liegt in einer längerfristigen und möglichst kostengünstigen Migration. Prinzipiell kann diese Migration auf drei unterschiedlichen Wegen erfolgen:

Mobile IP Version 6 – MIPv6

Veröffentlicht am von
Kommentar

Mobile IPv6 (MIPv6) wurde als Teilbereich des IPv6 Standards entwickelt, um mobile Kommunikationsverbindungen, d.h. IP-basierte Verbindungen mit und zwischen mobilen Netzwerkgeräten zu ermöglichen, und diesen auch eine kontinuierliche und netzwerkübergreifende Mobilität zu bieten. MIPv6 stellt damit eine Erweiterung des auf IPv4 basierenden Mobile IP Standards dar und wurde 2004 in RFC 3775 spezifiziert.

Dabei sind zahlreiche Mechanismen und Funktionen, die in MobileIP speziell für die Gewährleistung der mobilen Kommunikation entwickelt und integriert werden mussten, bereits integraler Bestandteil von IPv6. So gewährleistet IPv6 z.B. die sichere Übertragung von Registrierungsnachrichten, ohne dass dazu zusätzliche Maßnahmen getroffen werden müssen. Die IPv6 Autokonfiguration unterstützt die automatische Erlangung von Care-of Adressen und die Entdeckung der topologischen Nachbarn im Netzwerk (Neighbor Discovery) ist ebenfalls Bestandteil des IPv6 Protokolls, so dass zu diesem Zweck keine speziellen Foreign Agents mehr benötigt werden.

Außerdem ist jeder über IPv6 mit dem Netzwerk verbundene Rechner in der Lage, Aktualisierungsnachrichten an andere Rechner zu versenden, so dass ein mobiler Knoten (Mobile Node) seine Care-of Adresse direkt an einen korrespondierenden Knoten bzw. an den Home Agent senden kann. Während unter Mobile IP ein Foreign Agent für den Betrieb eines mobilen Gerät in einem fremden Netzwerk notwendig ist, behält das mobile Gerät unter MIPv6 seine Primäradresse und verwendet eine co-located Care-of Adresse, die an die Primäradresse gebunden wird. Dadurch wird der Betrieb eines Foreign Agents im Netzwerk überflüssig.

Befindet sich das mobile Endgerät in einem fremden Netzwerk, erfolgt eine Weitervermittlung des für das Endgerät bestimmten Datenverkehrs über einen Home Agent im Heimatnetzwerk, der die für das mobile Gerät bestimmten Datagramme abfängt und diese an die aktuelle Position des mobilen Geräts weiterleitet.

IPv6 Autokonfiguration

Veröffentlicht am von
Kommentar

Eine der bemerkenswertesten Eigenschaften der IPv6-Adressierung liegt in der Möglichkeit zur Autokonfiguration. IPv6 wurde so gestaltet, dass eine Autokonfiguration, d.h. die Zuteilung einer IP-Adresse an einen Rechner, der neu an das Netzwerk angeschlossen wird, ohne Einsatz eines dezidierten Servers möglich ist. Vormals wurde dieser Dienst in IPv4 entweder manuell vorgenommen oder über ein Konfigurationsprotokoll, wie z.B. das Dynamic Host Configuration Protocol (DHCP), das einen speziellen Server-Rechner im Netzwerk vorsieht, um die erforderlichen Adressauskünfte zu geben. Bei IPv6 kann über die bereits angesprochenen LLU-Adressen die eigene IP-Adresse von einem Router erfragt werden. Die über IPv6 realisierte Autokonfiguration wird auch als ” Stateless Autoconfiguration“ bezeichnet, im Gegensatz zur ” Stateful Autoconfiguration“, bei der zusätzliche Serverbasierte Methoden, wie z.B. DHCP zum Einsatz kommen. Die Autokonfiguration bei IPv6 wurde in RFC 2462 standardisiert und läuft in den folgenden Schritten ab:

  • Link-Local Adressgenerierung: Der neu an das Netzwerk angeschlossene Rechner generiert eine eigene LLU- Adresse. Diese besteht aus dem LLU-Format Präfix 1111111010 gefolgt von 54 0-Bits einem 64 Bits langen Interface Identifier, der aus der physikalischen Netzwerkadresse (MAC-Adresse) automatisch generiert wird.

  • Link-Local Adresstest: Als erstes muss geprüft werden, ob die generierte LLU-Adresse bereits im Netzwerk verwendet wird Über das IPv6 Neighbor Discovery Protocol (NDP) wird eine Anfrage an die benachbarten Rechner mit der zu überprüfenden Adresse gesendet. Sollte tatsächlich ein weiteres Gerät die erzeugte Adresse verwenden, erhält der anfragende Rechner vom betreffenden Gerät eine Benachrichtigung (Neighbor Solicitation) und eine neue Adresse muss generiert werden.

  • Link-Local Adresszuweisung: Kann die Eindeutigkeit der generierten Adresse im lokalen Netzwerk festgestellt werden, wird diese Adresse dem eigenen Netzwerk-Interface zugewiesen. Mit der so erzeugten LLU-Adresse kann der Rechner nun im eigenen Netzwerk uneingeschränkt kommunizieren. Zugriff und Erreichbarkeit aus dem globalen Internet ist damit jedoch nicht möglich.

  • Routersuche: Um auch mit Rechnern außerhalb des eigenen lokalen Netzwerks kommunizieren zu können, wird die Autokonfiguration mit der Suche nach dem nächstgelegenen Router fortgesetzt. Dazu versucht der sich konfigurierende Rechner die vom Router periodisch versendeten Router Advertisement Datagramme zu empfangen bzw. sendet selbst eine Router Solicitation in das lokale Netzwerk, damit der nächstgelegene Router ein Router Advertisement versendet. Sobald der Rechner das Router Advertisement als Antwort erhält, deklariert er den antwortenden Router zu seinem Default Router.

  • Routeranweisungen: Das vom Router versandte Router Advertisement enthält Angaben, wie mit der Autokonfiguration fortzufahren ist. Entweder teilt der Router dem Rechner mit, dass eine automatische Adresskonfiguration nicht möglich ist und dass dies manuell bzw. via DHCP-Protokoll erfolgen muss (Stateful Autoconfiguration), oder der Router teilt dem Rechner mit, wie dieser seine global gültige Unicast-Adresse generieren soll.

  • Globale Adresskonfiguration: Erlaubt das lokale Netzwerk eine automatische Autokonfiguration, generiert der ursprünglich anfragende Rechner seine jetzt global gültige Unicast-Adresse gemäß den Angaben, die ihm der Router übermittelt hat. Üblicherweise teilt der Router dabei den zu benutzenden Netzwerk-Präfix mit, der mit dem Interface Identifier des Geräts (siehe Schritt 1) kombiniert wird.

IPv6 Adressierung

Veröffentlicht am von
Kommentar

Bereits zu Beginn der 1990er Jahre wurde festgestellt, dass der im Internet mit IPv4 zur Verfügung stehende Adressraum dem explosionsartigen Wachstum des Internet nicht lange gewachsen sein würde. Einer der Hauptgründe für die Entwicklung eines IPv4-Nachfolgers war deshalb die Erweiterung des zur Verfügung stehenden Adressraums. Die Adresslänge in IPv6 wurde deshalb von 32 Bits auf 128 Bits erweitert, was einer Vervielfachung des zur Verfügung stehenden Adressraums um den Faktor 2^96 bedeutet. Ebenso wie bei IPv4 kennzeichnet eine IPv6-Adresse nicht einen individuellen Rechner, sondern lediglich eine Netzwerk-Schnittstelle, die einem bestimmten Rechner zugeordnet ist. Systeme können über mehrere Netzwerk-Schnittstellen verfügen, im Falle von Routern müssen sie es. Auch die Aufteilung in einen Adresspräfix, der das Netzwerk identifiziert, und einen Adresssuffix zur Hostidenifikation wurde von IPv4 übernommen. Lediglich auf die Einführung von Adressklassen wurde von vorne herein verzichtet. Um den Anteil der Netzwerkadresse aus der IPv6 Adresse herauszulesen, wird die bereits mit CIDR eingeführte Notation (Präfixnotation) verwendet.

Zwar erweitern die neuen IPv6-Adressen den zur Verfügung stehenden Adressraum enorm, doch wird die Darstellung recht unübersichtlich, wenn man die gewohnte Dezimal-Punkt-Notation wählt, wie folgendes Beispiel einer 128 Bit Adresse zeigt:

103.230.140.100.255.255.255.255.0.0.17.128.150.10.255.255

Um derartigen Adressen eine bessere Lesbarkeit zu verschaffen, entschieden sich die Entwickler von IPv6 für eine Hexadezimal-Doppelpunkt-Notation, in der jeweils Einheiten zu 16 Bits als Hexadezimalzahl zusammengefasst und durch Doppelpunkte getrennt dargestellt werden. Im Beispiel ergibt sich:

67E6:8C64:FFFF:FFFF:0000:1180:96A:FFFF

Um die Übersichtlichkeit weiter zu erhöhen, können führende Nullen weggelassen und eine Folge von Nullwerten durch ” ::“ ersetzt werden (Zero Compression). So kann z.B. die Adresse

000E:0C64:0000:0000:0000:1342:0E3E:00FE

abgekürzt geschrieben werden als

E:C64::1342:E3E:FE

Die Ersetzung von aufeinanderfolgenden Null-Ketten durch ”::“ darf in einer IPv6- Adresse allerdings nur an einer Stelle vorgenommen werden, sonst kann die Adresse nicht eindeutig rekonstruiert werden. Insbesondere bei speziellen Adressen, wie z.B. der allgemeinen Loopback-Adresse bringt die Ersetzung der Nullfolgen große Vorteile. So wird aus

0:0:0:0:0:0:0:1

durch Ersetzung der Nullfolgen mit

::1

eine deutliche Vereinfachung.

IPv6 Erweiterungs-Header

Veröffentlicht am von
Kommentar

Für zusätzliche Steuer- und Kontrollinformation im Header des IPv6-Datagramms sind die sogenannten Erweiterungs-Header vorgesehen. Aus Gründen der Effizienz verzichtete man bei der Spezifikation des IPv6-Basis-Headers darauf, Felder mit in den Header aufzunehmen, die nicht von allen Datagrammen für die Spezifikation zusätzlicher Optionen benötigt werden. Sie können bei Bedarf über Erweiterungs- Header mit aufgenommen werden. Insgesamt lassen sich in einem IPv6-Datagramm bis zu 6 Erweiterungs-Header nutzen, die ebenfalls über ein Next-Header Feld verfügen, das entweder den Typ eines Folge-Erweiterungs-Headers angibt oder als Abschluss-Header den Typ des Protokolls, dessen Header als erstes im Nutzdatenbereich befördert wird (siehe Abbildung).

Erweiterungs-Header werden mit Ausnahme des Hop-by-Hop Headers und des Destination-Options Headers ausschließlich vom Zielrechner, an den das IPv6- Datagramm adressiert ist, gelesen und verarbeitet. Folgende sechs Erweiterungs- Headertypen stehen für IPv6 zur Verfügung, wobei jeder Headertyp mit Ausnahme des Destination-Options Headers jeweils nur ein einziges Mal in einem IPv6- Datagramm benutzt werden darf:

  • Hop-by-Hop Options Header
    Dieser Headertyp enthält optionale Angaben in Form sogenannter Type-Length- Value-Angaben (TLV) Angaben, die von jedem Router entlang des Weges vom Sender zum Empfänger interpretiert werden. Der Hop-by-Hop Header folgt stets als erstes nach dem Basis-Header, um Verarbeitungszeit bei den Routern zu sparen. Ebenso wie der Destination-Options Header besitzt der Hop-by-Hop Options Header eine variable Länge und lässt sich daher anwendungsspezifisch verwenden. Zwei spezielle Anwendungen des Hop-by-Hop Options Headers betreffen das Versenden von überlangen IPv6-Datagrammen (Jumbogramme) oder von Steuerungs- und Kontroll-Datagrammen, die zur Resourcenreservierung an den Routern genutzt werden können.
  • Destination Options Header
    Der Destination-Options Header kann maximal zweimal in einem IPv6-Datagramm vorkommen. Er beinhaltet Informationen, die sowohl für die weitervermittelnden Router als auch für den Empfänger-Rechner von Bedeutung sind und von diesen interpretiert werden müssen. Handelt es sich um Router-Informationen, folgt der Destination-Options Header direkt dem Hop-by-Hop Options Header noch vor dem Routing Header, handelt es sich aber um Informationen für den Empfänger, dann steht der Destination-Options Header an letzter Stelle, direkt vor den beförderten IP-Nutzdaten.
  • Routing Header
    Dieser Header gibt eine Liste von Routern (Zwischensystemen) an, die auf dem Pfad vom Sender zum Empfänger zu besuchen sind. Der in RFC 2460 festgeschriebene Standard sieht die Möglichkeit unterschiedlicher Routing-Varianten vor, bislang wird nur die Variante des Loose Source Routings benutzt, bei dem die im Header angegebenen Router zwar besucht werden müssen, das Datenpaket allerdings auch andere Router passieren darf.
  • Fragment Header
    Mit Hilfe des Fragment Headers kann ein IPv6-Datagramm, dessen Länge die MTU (Maximum Transmission Unit) des unterliegenden Netzwerks überschreitet, in einzelne Fragmente zerlegt werden. Der Fragment-Header enthält dann die jeweils notwendigen Informationen, um die einzelnen Fragmente eines IPv6- Datagramms beim Empfänger wieder zusammensetzen zu können.

IPv6 Basis-Header

Veröffentlicht am von
Kommentar

Obwohl der Basis-Header eines IPv6-Datagramms nur gut die doppelte Länge eines IPv4-Datagrammheaders aufweist, ist es doch möglich, Sender und Empfängeradresse in ihrer gegenüber IPv4 vierfachen Länge von jeweils 128 Bits darin unterzubringen. Dieses Paradoxon erklärt sich aus der Tatsache, dass andere Informationen aus dem IPv4-Header weggelassen und in die optionalen Erweiterungs-Header verlagert wurden, die jeweils nur bei Bedarf genutzt werden. Der IPv6-Header weist gegenüber dem älteren IPv4-Datagrammheader sogar wesentliche Vereinfachungen auf (siehe Abbildung). Neben den beiden jeweils 16 Bytes (128 Bits) langen Adressen von Sender und Empfänger – der folgenreichsten Veränderung gegenüber IPv4 – beinhaltet der IPv6–Basis-Header lediglich sechs Felder:

  • Version
    Ebenso wie der IPv4-Datagrammheader startet der Basis-Header mit einer 4 Bits langen Versionsangabe zum verwendeten IP-Protokoll. Bei IPv6 steht hier stets der Wert 6.
  • Traffic Class
    Das 8 Bits lange TClass-Feld (Traffic Class) entscheidet über die Priorisierung des vorliegenden Datagramms relativ zu anderen Datagrammen und erlaubt es den Routern im Internet, das Datagramm einer bestimmten Datenverkehrsklasse zuzuordnen, wie z.B. Daten, Audio oder Video. Die Zugehörigkeit zu einer Datenverkehrsklasse entscheidet über das Verhalten der Router bzgl. Priorisierung, Warteschlangenverwaltung und überlastbedingtem Verwerfen von Datagrammen. Die Verwendung des TClass-Feldes wird in RFC 2474 (Definition of the Differentiated Services Field in the IPv4 and IPv6 Headers) spezifiziert.
  • Flow Label
    Das 20 Bits lange FL-Feld (Flow Label, Übertragungsart) bietet Platz für eine zufällig gewählte Identifikationsnummer (im Bereich #00001 bis #FFFFF) für eine virtuelle Ende-zu-Ende-Verbindung, mit der bestimmte Datagramme für eine gesonderte Übertragung im globalen Internet gekennzeichnet werden können. Datagramme mit identischem Flow Label müssen auch dieselbe Quell- und Zieladresse beinhalten. Daher sind Router anhand des Flow Labels in der Lage, die betreffenden Datagramme direkt weiterzuleiten, ohne den Rest des Headers auswerten zu müssen. Darüber hinaus können Router anhand des Flow Labels besondere Transportentscheidungen zur Behandlung der betreffenden Datagramme treffen.