IT-Academy Logo
Sign Up Login Help
Home - Netzwerke - Protokolle - Internet Protokoll (IPv6 - IPnG)



Internet Protokoll (IPv6 - IPnG)

IPv4 wird heutzutage in einem derartigen Ausmaß verwendet, dass die Adressen für die Zukunft nicht ausreichen werden. Deshalb wird IPv6 eingeführt. Hier eine sehr fundierte Einführung in das neue Protokoll


Autor: Uwe Tönjes (Big_Idler)
Datum: 23-01-2002, 19:32:07
Referenzen: www.ipv6-net.de/
Schwierigkeit: Anfänger
Ansichten: 7829x
Rating: 9.2 (5x bewertet)

Hinweis:

Für den hier dargestellte Inhalt ist nicht der Betreiber der Plattform, sondern der jeweilige Autor verantwortlich.
Falls Sie Missbrauch vermuten, bitten wir Sie, uns unter missbrauch@it-academy.cc zu kontaktieren.

[Druckansicht] [Als E-Mail senden] [Kommentar verfassen]



| special deluxe | Einleitung

Das 1973 eingeführte Internet Protokoll Version 4 (IPv4) wurde ursprünglich dafür konzipiert, Rechner des Pentagon und verschiedener amerikanischer Hochschulen miteinander zu verbinden. Zu dieser Zeit waren ca. 250 Standorte mit weniger als 1000 Rechnern an das damalige ARPA-NET angeschlossen. Da nicht abzusehen war, daß das Netz in kurzer Zeit so stark wachsen würde, hielt man eine Adreßlänge von 32 Bit für ausreichend.

Da aber zunehmend Firmen und Privatleute das Internet für sich entdecken, werden einige Schwächen des noch immer genutzten IPv4 sichtbar. Ein großes Problem besteht darin, daß die freien Adressen langsam zu Ende gehen (vor allem durch die Aufteilung des Adreßraums in Klasse-A-, Klasse-B- und Klasse-C-Netze). Weiterhin weist das Protokoll einige Schwachstellen z.B. hinsichtlich der Sicherheit oder der Unterstützung von real-time Anwendungen auf.

Es gab daher schon frühzeitig Bestrebungen, IPv4 durch andere Protokolle zu ersetzen. Als Nachfolger wurde IPv5 entwickelt, welches sich gegenüber IPv4 vor allem durch eine erweiterte Unterstützung bei der Übertragung von Audio- und Videodaten auszeichnete. Daß sich jedoch IPv5 als neuer Standard nicht durchsetzen konnte, lag vor allem daran, daß kommerzielle Hard- und Softwarehersteller aus Kostengründen keine Portierungen ihrer Produkte angeboten haben. Dies hat sich mit Beginn der Entwicklung von IPv6 allerdings geändert. Die Hersteller der wichtigsten Betriebssysteme haben die Notwendigkeit eines neuen Protokolls erkannt und bieten entsprechende Implementationen an. IPv6 hat also gute Chancen sich als neuer Standard zu etablieren.

Trotzdem kommt die Einführung des neuen Protokolls nicht so recht voran. Jeder wartet ab, daß andere den ersten Schritt machen. Die Provider zögern, weil sie nicht wissen, welche Probleme mit der Umstellung auf IPv6 auf sie zukommen. Außerdem ist die Nachfrage auf ihrer Kundenseite noch sehr gering. Auch die Hersteller von Routern beschränken sich noch darauf, Betaversionen mit IPv6 Support herauszugeben, scheuen sich aber davor, in kommerzielle Produkte zu investieren. Die Herren der letzten Meile wiederum haben Bedenken, daß durch IPv6 und die damit verbundenen neuen Anwendungen den bisherigen leitungsvermittelten Diensten das Aus droht, weil sich Internetzugänge über Kabel oder Stromleitung durchsetzen könnten. Da für jeden Nutzer ausreichend IPv6 Adressen zur Verfügung stehen, wäre es sogar möglich, daß Internettelefonie die bisherigen Techniken vollkommen überflüssig macht.

Diese Arbeit soll dem Leser einen Einblick in den Aufbau des neuen Protokolls sowie die gegenwärtig vorhandenen Anwendungsmöglichkeiten gewähren. Im ersten Abschnitt wird dazu zunächst gezeigt, wie die verschiedenen Elemente von IPv6 funktionieren und miteinander interagieren. Dabei werden auch die neuen Möglichkeiten der Adreßkonfiguration vorgestellt. Im zweiten Abschnitt sollen die technischen Möglichkeiten zur Umstellung von Rechnern und Netzwerken von IPv4 auf IPv6 genauer untersucht werden. Zum Abschluß werden IPv6 Implementationen einiger Betriebssysteme vorgestellt und innerhalb eines Testnetzes erprobt.

IPv6 - Das Protokoll

Anfang der 90er Jahre gab es mehrere Vorschläge für ein neues Protokoll, die miteinander konkurrierten und von denen jeder seine Vor- und Nachteile hatte. Ab 1993 wurden diese Ideen unter dem Namen IPnG zusammengefaßt, wobei man versuchte, die Vorteile der einzelnen Papiere zu übernehmen und bestehende Nachteile auszumerzen. Es wurde z.B. in den IPNGWG der IETF darüber gestritten, auf wieviel Bit man die Adreßlänge erhöhen sollte. Während einige Mitglieder der Meinung waren, daß 64 Bit vollkommen ausreichend sind, wollten andere mit einer variablen Länge arbeiten, um das Problem der knappen Adressen für alle Zeiten zu lösen.

Anfang der 90er Jahre gab es mehrere Vorschläge für ein neues Protokoll, die miteinander konkurrierten und von denen jeder seine Vor- und Nachteile hatte. Ab 1993 wurden diese Ideen unter dem Namen IPnG zusammengefaßt, wobei man versuchte, die Vorteile der einzelnen Papiere zu übernehmen und bestehende Nachteile auszumerzen. Es wurde z.B. in den IPNGWG der IETF darüber gestritten, auf wieviel Bit man die Adreßlänge erhöhen sollte. Während einige Mitglieder der Meinung waren, daß 64 Bit vollkommen ausreichend sind, wollten andere mit einer variablen Länge arbeiten, um das Problem der knappen Adressen für alle Zeiten zu lösen. Schließlich einigte man sich auf eine Adreßlänge von 128 Bit. Damit entstand ein Adreßraum von etwa 3,4 * 1038 Adressen[1]. Um dies etwas anschaulicher darzustellen dient folgender Vergleich: Pro Quadratmillimeter Erdoberfläche stehen nun ca. 667 Billiarden, pro Mensch 6,5*1028 Adressen bereit. In den Jahren 1995 und 1996 erschienen die ersten Entwürfe unter dem Namen IPv6, welche 1997 zum Draft Standard erklärt wurden.


Das Adreßformat und seine Darstellung

Behielte man die bisherige Schreibweise für Adressen (z.B. 139.18.38.71) bei, würde dies bei IPv6 zu einer äußerst langen und unhandlichen Darstellung führen. Eine Adresse sähe dann in etwa so aus: 63.254.4.0.2.128.0.0.0.0.0.0.0.0.0.1 Deshalb wurde beschlossen, die 128 Bit durch 16 Bit Integerzahlen zu repräsentieren, wobei jedes Integer durch ein Tupel hexadezimaler Ziffern dargestellt wird. Diese Tupel werden durch Doppelpunkte voneinander getrennt, dabei können führende Nullen weggelassen werden.

Beispiel: 3ffe:400:280:0:0:0:0:1

Außerdem führte man eine komprimierte Schreibweise ein. Sie erlaubt es, eine Gruppe von aufeinanderfolgenden Nullen durch zwei Doppelpunkte zu ersetzen. Obiges Beispiel sieht in komprimierter Schreibweise wie folgt aus:

3ffe:400:280::1

Diese Vereinfachung darf jedoch in jeder Adresse nur einmal verwendet werden, da sich sonst Mehrdeutigkeiten ergeben. Zudem ist vorgesehen, daß bestehende IPv4 Adressen im IPv6 Adreßraum beibehalten werden können. Für diesen Sonderfall ist eine weitere Schreibweise möglich:

::ffff:139.18.38.71 was ::ffff:8b12:2647 entsprechen würde.

Eine IPv6 Adresse setzt sich, wie bei IPv4, aus einem Präfix und einem lokalen Anteil zusammen. Um dies darzustellen wird folgende Schreibweise verwendet:


IPv6/Präfix, z.B. 3ffe:400:280:0:0:0:0:1/48

Das bedeutet, daß die ersten 48 Bit fest sind (Präfix) und die hinteren 80 Bit im lokalen Subnetz vergeben werden.


Aufteilung der Adressen nach link local / site local / global

Wie bei IPv4 sind auch bei IPv6 bestimmte Adressen für spezielle Anwendungen vorgesehen. Zur Unterscheidung dient der sogenannte Format-Präfix, an welchem sich der Typ der Adresse erkennen läßt. Wie Tabelle 1 zeigt, sind zur Zeit erst 15,1% des Adreßbereichs in Benutzung.

Verwendung Präfix Anteil
reserviert für spezielle Anwendungen 0::0/8 0,4%
noch nicht zugeordnet 100::0/8 0,4%
Abbildung von NSAP-Adressen 200::0/7 0,8%
Abbildung von IPX-Adressen 400::0/7 0,8%
noch nicht zugeordnet 600::0/7 0,8%
noch nicht zugeordnet 800::0/5 3,1%
noch nicht zugeordnet 1000::0/4 6,3%
global eindeutige Adressen 2000::0/3 12,5%
noch nicht zugeordnet 6000::0/3 12,5%
noch nicht zugeordnet 8000::0/3 12,5%
noch nicht zugeordnet A000::0/3 12,5%
noch nicht zugeordnet C000::0/3 12,5%
noch nicht zugeordnet E000::0/3 6,3%
noch nicht zugeordnet F000::0/5 3,1%
noch nicht zugeordnet F800::0/6 1,6%
noch nicht zugeordnet FE00::0/7 0,8%
noch nicht zugeordnet FE00::0/9 0,2%
auf eine Verbindung begrenzte Adressen FE80::0/10 0,1%
auf eine Einrichtung begrenzte Adressen FEC0::0/10 0,1%
Multicast-Adressen FF00::0/8 0,4%
Tabelle 1 IPv6 Adreßbereiche


Adressen mit dem Präfix FE80::0/10 werden als link-local bezeichnet und sind nur innerhalb eines Subnetzes eindeutig. Jedes Interface bekommt bei der Aktivierung eine solche Adresse zugewiesen. IP-Pakete mit diesem Präfix dürfen von Routern nicht weitergegeben werden. Adressen mit dem Präfix FEC0::0/10 (site-local) sind mit den privaten Adreßbereichen von IPv4 (z.B. 192.168.0.0/16) vergleichbar. Sie können an Rechner vergeben werden, auf welche Zugriffe von außen nicht erwünscht sind. Dabei muß sichergestellt sein, daß Pakete dieses Typs die Institution nicht verlassen. Soll ein Rechner uneingeschränkt kommunizieren können, muß ihm eine global gültige Adresse zugewiesen werden.

Die IPv6 Multicast-Adressen unterteilen sich ebenfalls noch einmal in link-local, site-local und global Bereiche. Eine Tabelle mit den entsprechenden Präfixen befindet sich im Anhang (Vordefinierte Multicast-Adressen).

Außerdem wurde neben den schon von IPv4 bekannten Adreßtypen Unicast und Multicast ein weiterer Typ definiert: Anycast. Hier wird ähnlich wie bei Multicast eine Gruppe von Empfängern beschrieben, wobei im Gegensatz zu Multicast nicht jedes, sondern nur ein Mitglied der Gruppe das Paket erhält. Eine denkbare Anwendung wäre z.B. eine DNS Anfrage, welche an die Gruppe „alle Nameserver“ gestellt wird, und dann genau ein Server das Anfragepaket erhält (in der Regel der am nächsten gelegene). Die von IPv4 bekannten Broadcast Adressen gibt es nicht mehr.


IPv6 Header Format

Abbildung 1 zeigt den Aufbau des IPv6 Basisheaders wie in [RFC 2460] definiert.

Abbildung 1 IPv6 Header Format


Der Basisheader enthält die im folgenden näher erläutertern Felder:

Version: 4 Bit Internet Protokoll Versionsnummer
Durch die Verwendung dieses Feldes, welches auch bei IPv4 existiert, ist die Unterscheidung zwischen den verschiedenen Protokollversionen und somit auch der parallele Betrieb möglich.
Class: 8 Bit Feld zur Beschreibung der Priorität
Hier kann vom Absender angegeben werden, mit welcher Priorität die Pakete auf dem Weg zum Empfänger behandelt werden sollen. Dabei haben die Router des Transportweges die Möglichkeit, je nach Netzauslastung und Belegung des Class Feldes, Pakete auf unterschiedlichen Wegen zum Empfänger zu senden, zu verwerfen oder bei Bedarf die Werte des Class Feldes zu verändern. Zur Zeit ist die genaue Normierung dieses Feldes noch im Gange. Unter dem Namen DIFFSERV hat sich eine IETF Arbeitsgruppe gebildet, welche an der weiteren Definition arbeitet.
Flow Label: 20 Bit Identifikationsnummer
Der Wert in diesem Feld wird benutzt, um Pakete zu kennzeichnen, für die eine besondere Behandlung durch IPv6 Router gewünscht wird, z.B für non-default Quality of Service Pakete oder Echtzeitanwendungen. In diesem Fall wird hier eine (pseudo) Zufallszahl abgelegt, welche für jeden Absender eindeutig sein muß. Ebenfalls muß sichergestellt werden, daß alle Pakete mit diesem Label die gleiche Zieladresse sowie dieselben Hop-by-Hop und Routing Header haben. Hosts oder Router, welche keine Flow-Label Funktionalität implementieren, müssen beim Versenden in diesem Feld eine 0 eintragen, beim Forwarding bleibt der Wert unverändert und beim Empfang wird das Feld ignoriert. Dieses Feld soll die Router vor allem beim Verarbeiten von Video- und Audiodaten unterstützen, indem das Feld als Hash-Code verwendet wird.
Payload Length: 16-Bit unsigned Integer
Dieser Wert gibt die Größe des Paketes nach dem IPv6 Header in Octets an.
Next Header: 8 Bit Selector
Er identifiziert den Typ des ersten Erweiterungsheaders nach dem IPv6 Basisheader.
Hop Limit: 8 Bit unsigned Integer
Dieses Feld wird von jedem Router, welcher das Paket weiterleitet, dekrementiert. Hat der Wert 0 erreicht, wird das Paket verworfen.


Mit der Einführung des neuen Headers wurde folgendes erreicht:

Vergrößerung des Adreßraumes
Dadurch erhält man neben der größeren Anzahl von nutzbaren Adressen neue Möglichkeiten zur Autokonfiguration, mehrere Stufen in der Adreßhierarchie (link lokal / site lokal / global) sowie einen neuen Typ von Adressen: Anycast Adressen.

Einführung von Erweiterungsheadern
Durch ihre Integration in das Protokoll wird die Nutzung von Optionen mit variabler Länge möglich. Auch ergibt sich eine größere Flexibilität beim Hinzufügen von neuen Optionen in der Zukunft.

Vereinfachung des Headers
Einige Felder des IPv4 Headers wurden entfernt oder in die Eweiterungsheader ausgelagert, was zu einer einfacheren Auswertbarkeit der Pakete durch die Router führt.

Quality of Service Funktionen
Sie erlauben die Markierung von Paketen, für die der Absender eine besondere Behandlung wünscht, z.B. bei real-time Anwendungen.

Verschlüsselung und Authentifizierung
Hiermit werden IPsec Funktionen im Protokoll verankert.


Erweiterungsheader

In IPv6 werden Erweiterungsheader zum Transport zusätzlicher Informationen verwendet. Sie werden zwischen dem Basis Header und den Nutzdaten (upper layer header) plaziert. Ziel dieser Entwicklung ist es, alle für das Routing unnötigen Daten aus dem Basis Header zu entfernen, um die Durchlaufzeiten der Pakete durch das Netz bzw. die Router zu verringern. Zusätzlich erhofft man sich eine größere Flexibilität, vor allem in Hinsicht auf spätere Erweiterungen des Protokolls.
Das Prinzip der Erweiterungsheader verdeutlicht Abbildung 2.

Abbildung 2 Prinzip der Erweiterungsheader


Zur Zeit sind 6 Erweiterungsheader definiert:

Hop-by-Hop Options Header
Dieser Header wird verwendet, um Optionen zu transportieren, welche bei jedem Transportschritt ausgewertet werden müssen.

Routing Header
Mit seiner Hilfe kann die Route, die ein Paket zum Zielrechner nimmt, beeinflußt werden. Gegenwärtig wird hier nur das „lose routing“ unterstützt. Hierbei kann der Absender festlegen, über welche Router ein Paket laufen soll. Im Gegensatz zum „strikten routing“ darf es zusätzlich über Router gehen, welche nicht explizit angegeben sind.

Fragment Header
Bei IPv6 ist es im Gegensatz zu IPv4 den Routern nicht gestattet, Pakete auf dem Weg zum Zielrechner zu fragmentieren. Statt dessen muß der Absender die maximale Paketgröße des Transportpfades zum Zielrechner bestimmen und bei Bedarf die Pakete selbst fragmentieren. Mit Hilfe des Fragment Headers ist es dem Zielrechner möglich, die Pakete wieder richtig zusammenzusetzen.

Authentication Header
Er erlaubt es einem Empfänger festzustellen, ob das Paket tatsächlich von dem angegebenen Absender stammt oder ob es während der Übertragung verändert wurde.

Encapsulating Security Payload Header
Er wird zur Verschlüsselung des Paketes benötigt (IPsec).

Destination Options Header
Er wird benutzt, um optionale Informationen zu übertragen, welche ausschließlich vom Zielrechner ausgewertet werden.

Wird mehr als ein Erweiterungsheader verwendet, ist die Reihenfolge aus Tabelle 2 vorgeschrieben. Dabei darf jeder Header (außer dem Destination Options Header) nur einmal verwendet werden.

Header Code
IPv6 Basis Header  
Hop-by-Hop Options 0
Routing Header 43
Fragment Header 44
Authentication Header 51
Encapsulating Security Payload Header 50
Destination Options Header 60
Upper-Layer Header (Nutzdaten) 59
Tabelle 2 Reihenfolge der Erweiterungsheader


Header Optionen

Da sich eine feste Definition der Erweiterungsheader in der Zukunft unter Umständen als zu unflexibel erweisen könnte, wurden zusätzliche Header Optionen definiert, welche einzelnen Headern übergeben werden können. Diese type-length-value (TLV) codierten Optionen haben den in Abbildung 3 beschriebenen Aufbau.

Abbildung 3 Aufbau von Header Optionen


Option Type 8 Bit Feld für die Option
Opt Data Len 8 Bit Feld, das die Länge des Option Data Feldes in Octets angibt
Option Data optionsspezifische Daten


Die beiden höchstwertigen Bits des Optionstypes werden verwendet, um die Behandlung von Optionen festzulegen, die dem Empfänger unbekannt sind.

00 Die aktuelle Option wird ignoriert und die nächste Option wird bearbeitet.
01 Das ganze Paket wird verworfen.
10 Das Paket wird verworfen und eine ICMP Nachricht mit Problem Code 2 und der aktuellen Option wird an den Absender geschickt.
11 Das Paket wird verworfen und, falls die Zieladdresse keine Multicast-Addresse ist, wird eine ICMP Nachricht mit Problem Code 2 und der aktuellen Option an den Absender geschickt.
Tabelle 3 Behandlung von Optionen


Das dritthöchstwertige Bit wird gesetzt, falls sich die Daten einer Option während der Übertragung zum Ziel ändern können. Dies ist dann wichtig, wenn Pakete mit einem Authentication Header versehen sind. In diesem Fall wird bei der Berechnung bzw. der Überprüfung der Checksumme die gesamte Option als ein Feld von 0-Bytes angesehen.

Da für einige Optionen eine Ausrichtung an bestimmten Byte-Grenzen vorgeschrieben ist, werden zuerst zwei Pad Optionen definiert. Sie dienen ausschließlich als Platzhalter und sind bei jedem Erweiterungsheader verwendbar..

Abbildung 4 Pad1 Option


Abbildung 5 PadN Option


Die Pad1 Option ist ein Spezialfall, da sie das in der Regel vorgeschriebene Längenfeld nicht hat.
Die PadN Option wird benutzt, um Felder von zwei und mehr Bytes auszufüllen. Opt Data Len gibt an, wieviele Bytes Option Data enthält.
Weitere Optionen werden in Zusammenhang mit speziellen Features wie z.B. Neighbor Discovery oder Mobile IPv6 beschrieben.


Hop-by-Hop Options Header

Der Hop-by-Hop Options Header beinhaltet Optionen, welche bei jedem Transportschritt ausgewertet werden. Das Längenfeld gibt die Größe des Headers in 8 Byte Einheiten an, wobei die ersten 8 Byte nicht gezählt werden.

Abbildung 6 Aufbau des Hop-by-Hop Headers


Routing Optionen

Der Routing Header wird genutzt, um IPv6 Adressen anzugeben, an welchen das Paket auf dem Weg zum Ziel vorbeikommen soll. Diese Funktionalität entspricht in etwa der Loose Source bzw. Record Source Option von IPv4.

Abbildung 7 Aufbau des Routing Headers


Die Länge wird in 8 Byte Einheiten angegeben, wobei die ersten 8 Byte nicht mitgezählt werden. Im Feld Routing Typ ist bisher nur der Wert 0 definiert. Dabei wurde in einer frühen Version ([RFC 1883]) des Protokolls noch zwischen losem und striktem Routing unterschieden. Da man inzwischen entschieden hat, auf das strikte Routing zu verzichten, wird das Reserved Feld zur Zeit nicht benutzt. Der Wert Segments Left gibt an, wieviel Adressen noch abgearbeitet werden müssen, bevor das Paket sein Ziel erreicht. Bei den Adressen darf es sich nur um Unicast Adressen handeln.
Das Datenfeld hat einen vom Routing Type abhängigen Aufbau, hier für Typ=0:

Abbildung 8 Routing Header Datenfeld für Routing Type=0


Fragment Header

Ein weiterer Header wird zur Fragmentierung von Paketen verwendet. Bei IPv6 ist es so, daß Router normalerweise keine Fragmentierung von zu großen Paketen vornehmen dürfen. Es ist also die Aufgabe des Senders, die maximale Paketgröße für einen Transportpfad zu bestimmen und falls nötig die Pakete in kleinere Einheiten aufzusplitten. Zu diesem Zweck wird vom Absender ein Fragment Header verwendet.
Aufbau:

Abbildung 9 Fragment Header


Jedes IPv6 Paket besteht aus einem fragmentierbaren und einem nicht fragmentierbaren Bereich. Ersterer enthält den IPv6 Basis Header sowie die Header, welche während der Übertragung ausgewertet werden (Routing Header, Hop-by-Hop Header). Dieser Teil muß jedem Fragment vorangestellt werden. Nun folgt der Fragment Header, wobei Next Header immer mit dem Next Header Wert des Originalpaketes gesetzt wird. Bei Fragment Offset handelt es sich um einen 13 Bit Wert, welcher relativ zum Start des fragmentierten Teils im Originalpaket in 8 Bit Einheiten angibt, wo dieser Teil der Nachricht wieder eingesetzt werden muß. Es ist daher notwendig, daß jeder Teil der Nachricht, mit Ausname des letzten Fragmentes, als Länge ein Vielfaches von 8 Bit hat. Das M(ore) Flag gibt an, ob weitere Teile folgen (M=1) oder ob es sich um das letzte Paket gehandelt hat (M=0). Im Feld Identification wird ein für jedes fragmentierte Paket eindeutiger Wert eingetragen, so daß der Empfänger jedes Teil eindeutig zuordnen kann.
Anhand von Abbildung 10 soll das Verfahren noch einmal verdeutlicht werden.

Abbildung 10 Fragmentierung eines Paketes


Beim Empfang werden alle Teile mit derselben Source Adresse und derselben Identifikationsnummer mit Hilfe des Offsets aus dem Fragment Header wieder zusammengesetzt.

Destination Options Header

Der Destination Options Header wird zur Übermittlung von optionalen Informationen an den Empfänger des Paketes verwendet. Der Aufbau und die Verwendung der Felder entspricht der des Hop-by-Hop Options Headers, mit dem Unterschied, daß der Destination Options Header im vorangehenden Header mit dem Wert 60 angekündigt wird. Außerdem wurde eine weitere Zieloption für diesen Header definiert, die Jumbo-Payload-Option.
(Ausrichtung: 4n+2)

Abbildung 11 Jumbo Payload Header Option



Verwendet wird die Option für Pakete deren Länge sich mit dem normalen 16 Bit Wert im Basis Header nicht mehr darstellen läßt. Die maximale Paketgröße ist also auf 2^32 Byte beschränkt, was im allgemeinen als ausreichend betrachtet wird.

Neben den in diesem Abschnitt beschriebenen Erweiterungsheadern wurden auch Header zur Unterstützung von Verschlüsselung und Authentisierung in das Protokoll integriert. So ist es möglich, Daten auf dem Transportpfad zu verschlüsseln und sie auf ihre Echtheit hin zu überprüfen. Im Abschnitt IPsec werden die Anwendung dieser Features sowie die dazu verwendeten Eweiterungsheader näher beschrieben.


IPv6 Neighbor Discovery

Für die Interaktion von Systemen, welche sich am selben Link befinden, müssen Funktionen bereitstehen, um Netzwerkinformationen wie MAC Adressen von Nachbarn, MTU oder HOP Limit zu bestimmen. Außerdem muß sichergestellt werden, daß innerhalb eines Netzes keine doppelte Adreßvergabe erfolgt. Diese und weitere Probleme soll bei IPv6 das Neighbor Discovery Protokoll lösen [RFC 2461]. Hierbei handelt es sich um ICMPv6 Nachrichten, welche zur Konfiguration von Interfaces verwendet werden. Dieses Protokoll übernimmt u.a. die Aufgaben, die in IPv4 vom Address Resolution Protocol (ARP), ICMP Router Discovery und ICMP Redirect erledigt wurden.
Das IPv6 Neighbor Discovery bietet folgende Funktionen an:

Router Discovery
Rechner suchen nach Routern im lokalen Netz.

Prefix Discovery
Rechner erkennen automatisch, welche Ziele (Präfixe) vom lokalen Netz aus erreichbar sind. Außerdem wird unterschieden, ob sich ein Ziel am selben Link (on-link) befindet oder ob es nur über einen Router erreichbar ist (off-link).

Parameter Discovery
Rechner lernen Parameter wie z.B. MTU (maximum transmission unit) oder hop limit, welche dann bei zu versendenden Paketen gesetzt werden.

Address Autoconfiguration
Interfaces bekommen automatisch eine Adresse zugewiesen.

Address Resolution
Rechner bestimmen die link-layer Adresse von on-link Zielen aus der IPv6 Adresse.

Next-Hop Determination
Ist ein Algorithmus, welcher die Abbildung der Zieladresse auf eine Adresse eines Nachbarn beschreibt. Der Next-Hop kann ein Router oder das Ziel selbst sein.

Neigbor Unreachability Detection
Rechner erkennen, wenn ein Nachbar nicht länger erreichbar ist. Falls dies ein Router ist, versucht der Host einen alternativen Router zu finden. In diesem Fall erfolgt wiederum eine Address Resolution.

Duplicate Address Detection
Bevor ein Interface eine Adresse benutzt, vergewissert es sich, daß diese noch nicht von einem anderen Interface verwendet wird.

Redirect
Router informieren Rechner darüber, daß es einen besseren First-Hop Host für das angegebene Ziel gibt.

Für diese Funktionen wurden fünf ICMP Paket Typen definiert: ‘Router Solicitation’ mit ‘Router Advertisement’, ‘Neighbor Solicitation’ mit ‘Neighbor Advertisement’ sowie eine ‘Redirect Message’.

Router Solicitation und Router Advertisement

Bei der Entwicklung von IPv6 wurde sehr viel Wert auf die Möglichkeit der Automatischen Konfiguration von Rechnern gelegt. Aus diesem Grund wurden Router Ankündigungen (Router Advertisement) eingeführt.

Abbildung 12 Router Advertisement


Diese Pakete werden von Routern in regelmäßigen Abständen, normalerweise aller 600 Sekunden, ausgesendet und enthalten alle Informationen, die ein Host benötigt, um sich selbst zu konfigurieren. So wird der Wert des Feldes Hop Limit in den IP Header jedes von dem Rechner erzeugten Paketes übernommen. Bei dem M-Bit handelt es sich um das ‘Managed Address Configuration’ Flag. Mit seiner Hilfe kann zwischen zwei möglichen Verfahren zur Adreßkonfiguration unterschieden werden. Ist es gesetzt, wird die ‘stateful’ (dhcp) ansonsten die ‘stateless’ Adreßkonfiguration verwendet. Ist das O-Bit gesetzt, verwendet der Host für die Autokonfiguration von anderen (nicht Adreß) Informationen das statusbehaftete Protokoll. Mit gesetztem H-Bit wird mitgeteilt, daß der Router als ‘Home Agent’ für mobile Agenten arbeiten kann.
Bei der Lifetime handelt es sich um eine 16 Bit Integer Zahl, welche die Gültigkeitsdauer der Informationen über diesen Router angibt. Der Wert wird in Sekunden angegeben, woraus sich eine maximale Gültigkeit von 18,2 Stunden ergibt. Ist der Wert Null, so können zwar die Informationen aus dem Paket verwendet werden, der Router kann aber nicht als Default Router zu anderen Netzen fungieren. Bei den beiden folgenden Feldern handelt es sich jeweils um einen 32 Bit Integer Wert, wobei die Reachable Time in Millisekunden angibt, wie lange ein Host als erreichbar gilt, nachdem eine entsprechende Erreichbarkeitsmeldung eingegangen ist. Dieser Wert wird später vom Neigbor Unreachability Detection Algorithmus verwendet. Der Retrans Timer gibt an, wieviel Millisekunden ein Rechner nach einer ‘Neighbor Solication Message’ warten soll, bevor er diese erneut versendet. Dieser Wert wird ebenfalls vom Neigbor Unreachability Detection Algorithmus benötigt.
Das Paket kann noch weitere Optionen enthalten, in welchen z.B. Werte für die MTU oder die Hardwareadresse des Routers mitgeteilt werden. Außerdem werden hier mögliche Präfixe für die statuslose Autokonfiguration übergeben.

Eine Router Solicitation Message wird von einem Rechner versendet, falls dieser ein neues Interface konfigurieren will, ohne auf die automatischen Ankündigungen zu warten. Er veranlaßt damit den Router sofort ein entsprechendes Antwortpaket zu senden.

Abbildung 13 Router Solicitation


Die Nachricht wird an die Multicast-Adresse FF02::2 gesendet und somit von allen Routern empfangen. Als Absender wird die link-local Adresse des Senders eingetragen. Somit ist es möglich, die Antwort direkt an den Empfänger zu senden, anstatt wie sonst üblich an alle angeschlossenen Interfaces. Das Hop-Limit des IP-Paketes wird auf 255 gesetzt.

Neighbor Solicitation und Neighbor Advertisements

Neighbor Solicitation wird zur Ermittlung der Hardwareadresse eines Nachbarn verwendet. Außerdem wird mit seiner Hilfe die Erreichbarkeit anderer Nodes am selben Link getestet. Neighbor Solicitation dient auch zur Entdeckung doppelt vergebener Adressen.

Abbildung 14 Neighbor Solicitation


Bei einer Neighbor Solicitation Message werden die Felder des IP Paketes wie folgt initialisiert:

Source Address Sie enthält die IPv6 Adresse des Interfaces, welche die Nachricht versendet oder eine unspezifizierte[3] Adresse, falls nach doppelt vergebenen IP Adressen gesucht werden soll.

Destination Address Hat man die Absicht, die Erreichbarkeit einer Node zu überprüfen, wird hier die zu testende IPv6 Adresse eingetragen. Falls es sich um Duplicate Address Detection handelt, wird die Multicast Adresse eingetragen, welche aus dem Präfix FF02::1:FF00:0/104 und den unteren 24 Bit der gesuchten IPv6 Adresse gebildet wird.

Code Das Feld ist 1 falls die Anfrage von einem Router stammt, sonst 0.

Hop Limit Das Hop Limit wird auf 255 gesetzt. Sollte das Feld beim Empfang kleiner als 255 sein, so wurde das Paket geroutet und muß vom Empfänger verworfen werden.


Je nach Initialisierung des IP Headers werden verschiedene Aufgaben erledigt. Der einfachste Fall ist der Test der Erreichbarkeit eines Nachbarn (Neighbor Unreachibility Detection). Wurde für einen gewissen Zeitraum kein Paket von einem Rechner empfangen, wird ein ICMP Paket des Typs 135 erzeugt. Die Quell- und Zieladresse sind hierbei bekannt und eindeutig bestimmt. Die Ethernetadresse des Nachbarn befindet sich noch im Cache. Wird eine solche Anfrage vom Empfänger nicht beantwortet, so gilt der Rechner als nicht mehr erreichbar und die Ethernetadresse wird aus dem Cache entfernt. Anders verhält es sich bei der Duplicate Address Detection. Hier ist die Hardwareadresse nicht bekannt. Daher muß das Paket an alle Stationen gesendet werden, welche sich in der o.g. Multicast Gruppe befinden. Wird ein solches Paket empfangen und stimmt die eigene IP mit der gesuchten überein, so wird eine entsprechende Antwort generiert, welche anzeigt, daß die Adresse bereits verwendet wird. Da solche Antworten auch die Ethernetadresse des Absenders enthalten, wird diese Funktion gleichzeitig als Ersatz des ARP Protokolls von IPv4 verwendet.
Die als Antwort versendeten Neighbor Advertisements haben den in Abbildung 15 dargestellten Aufbau.

Abbildung 15 Neighbor Advertisement


Dabei werden die Felder des IP Headers wie folgt belegt:

Source Address Sie entspricht der IPv6 Adresse des Interfaces, welches die Antwort sendet.

Destination Address Falls das zugehörige Neighbor Solication Paket eine gültige Source Adresse hat, wird diese verwendet, falls es sich um die unspezifizierte Adresse handelt, wird die Multicast Adresse eingesetzt, welche alle on-link Rechner anspricht.

Code Die Verwendung des Wertes erfolgt analog zur Neighbor Solicitation.



Im ICMP Paket zeigt das R Bit (Router Flag) an, daß der Absender ein Router ist. Es wird verwendet, um Hosts zu erkennen, welche vom Router zum Rechner werden und umgekehrt. Anhand des S Bits (Solicited Flag) läßt sich erkennen, ob es sich um eine selbst generierte Ankündigung (S=0) oder um eine Reaktion auf eine Anfrage (S=1) handelt. Mit gesetztem O (Override) Flag wird der Empfänger dazu aufgefordert, alle bestehenden Cache Einträge zu löschen und mit den Informationen aus diesem Paket zu überschreiben.


Redirect Messages

Router können Redirect Messages senden, wenn sie einen Host darüber informieren wollen, daß sie einen besseren Weg zu dem gewünschten Ziel kennen. In diesem Fall wird dem Rechner ein anderer First-Hop Router bekanntgegeben oder er wird darüber informiert, daß es sich bei dem Ziel um einen Nachbarn handelt, welcher dann direkt über seine MAC Adresse erreichbar ist.

Abbildung 16 Redirect Message


In die IP Felder der Nachricht sind als Quelladresse die link-local IP des Absenders, als Ziel die Source Adresse des beanstandeten Paketes einzutragen. Das Hop Limit wird auf 255 gesetzt. Bei der Nachricht selbst wird die Target Address auf den besseren First-Hop gesetzt. Handelt es sich dabei um den Endpunkt der Kommunikation (also einen Nachbarn), so wird der Wert aus dem zurückgewiesenen ICMP Paket verwendet, sonst die link-local Adresse des Routers.


Optionen beim Neighbor Discovery

Wie aus den Abbildungen 12 bis 16 ersichtlich, kann man dem Neighbor Discovery zusätzliche Optionen übergeben. Dabei ist es möglich, daß Optionen eines Typs mehrmals in ein und derselben Nachricht auftreten.
Grundsätzlich haben sie den in Abbildung 17 beschriebenen Aufbau. Dabei wird die Länge der Optionen in Einheiten von 8 Byte angegeben.

Abbildung 17 Optionen beim Neighbor Discovery


Im Zusammenhang mit Neighbor Discovery sind bisher folgende Typen definiert:

Source Link-Layer Address 1
Target Link-Layer Address 2
Prefix Information 3
Redirect Header 4
MTU 5


Der Wert Length gibt die Länge der Option in Einheiten von 8 Byte an.
Hier soll nur auf die Optionen vom Typ 3 etwas näher eingegangen werden, da diese für das Verständnis der statuslosen Adreßkonfiguration besonders wichtig sind.

Abbildung 18 Prefix Information Header Option



Im Feld Prefix Length wird die Länge des Präfixes in Bit angegeben, wobei Werte von 0 bis 128 erlaubt sind. Hält man sich jedoch an die EUI-64 Norm, worin für den Host Identifier 64 Bit vorgesehen sind, darf der Wert in diesem Feld nicht größer als 64 sein. Valid Lifetime gibt an, wieviel Sekunden der Präfix gültig ist. Preferred Lifetime beschreibt die Gültigkeitsdauer der mit Hilfe des Präfixes generierten Adresse. Sind alle Bits gesetzt, so ist der jeweilige Wert unbegrenzt gültig. Im Präfix Feld dürfen nur so viele Bits verwendet werden, wie in Prefix Length angegeben. Der restliche Bereich muß mit 0 initialisiert werden. Außerdem dürfen Router keine link-local Präfixe aussenden.
Alle Werte für die Neighbor Discovery Funktionen können in den Routern konfiguriert werden. So ist es möglich, im jeweiligen Subnetz bestimmte Eigenschaften zu optimieren, z.B. Reduzierung der Netzlast durch längere Intervalle für Discovery Nachrichten. Die Konfiguration erfolgt durch das Setzen bestimmter Variablen in den Routern (Variablen zur Routerkonfiguration).

Vergleich mit IPv4

Das IPv6 Neighbor Discovery Protokoll weist einige Unterschiede zu den analogen IPv4 Mechanismen auf. So enthalten die Advertisments die link-layer Adresse des Absenders, was zusätzliche Nachrichten (ARP) unnötig macht. Die Router Advertisments verbreiten die Präfixinformationen, wodurch auch die bisher benutzte Netzmaske ersetzt wird. Vollkommen neu ist die statuslose Autokonfiguration, für die es in IPv4 keine analogen Mechanismen gibt. Auch die Möglichkeit zur Übergabe von Netzwerkparametern wie MTU oder Hop Limit durch den Router stellt eine Neuerung dar. Redirect Nachrichten enthalten jetzt die link-layer Adresse des besseren First-Hop Routers und nicht wie bisher seine IP-Adresse. Auch lernen die Rechner alle on-link Präfixe von den Routern, so daß Pakete an Hosts, welche sich im lokalen Subnetz befinden, direkt zugestellt werden können. Bisher wurden alle Pakete, welche sich laut Netzwerkmaske nicht on-link befanden, zuerst zum Router gesendet. Da Neighbor Discovery Nachrichten immer mit einem Hop Limit von 255 initialisiert werden, hat man einen wirksamen Schutz vor spoofing Attacken.



Statuslose Autokonfiguration

Bei IPv4 werden die Adressen der Endgeräte in der Regel manuell eingestellt. Dies führt häufig dazu, daß weniger versierte Anwender falsche Angaben zur IP oder Netzmaske machen, was den Betrieb des Gerätes oder des ganzen Netzes stören kann. Auch ist es bei IPv4 nötig, jede Station einzeln zu konfigurieren, was bei Änderungen in großen Netzen sehr aufwendig ist. Für IPv4 wurde daher das Dynamic Host Configuration Protokoll (dhcp) entwickelt, welches mit einigen Modifikationen auch für IPv6 zur Verfügung steht [draft dhc00-0]. Zusätzlich gibt es bei IPv6 die Möglichkeit der ‘statuslosen’ Konfiguration. Dieses, in [RFC 2462] beschriebene Verfahren, ermöglicht es Geräten sich in einem Netz vollkommen selbständig zu konfigurieren. Nachteil hierbei ist, daß der Administrator die vergebenen IP Adressen nicht beeinflussen kann.
Das Verfahren beginnt mit dem Initialisieren des IPv6 Stacks und der Bildung einer link-local Adresse, welche aus der Hardwareadresse der Netzwerkkarte und dem Präfix fe80::/112 besteht. Um sicherzustellen, daß die so gebildete Adresse noch nicht benutzt wird, muß eine Duplicate Address Detection (Neighbor Solicitation und Neighbor Advertisements) durchgeführt werden. Stellt diese fest, daß die Adresse schon verwendet wird, verlangt das System eine manuelle Konfiguration des Interfaces. Die Duplicate Address Detection beginnt erneut.
Nach der Zuordnung der link-local Adresse haben die Geräte die Möglichkeit, mit anderen Geräten im selben Subnetz via IPv6 zu kommunizieren.Die im folgenden beschriebenen Schritte sind nur noch für Rechner definiert, die keine Router sind.
Um mit Systemen außerhalb des lokalen Netzes kommunizieren zu können, müssen die Hosts nun versuchen einen Router zu finden. Dazu können sie entweder auf die regelmäßig ausgesendeten Router Advertisements warten oder durch Senden von Router Solicitations aktiv nach Routern suchen. Bleiben die Anfragen erfolglos, wird mit Hilfe von Multicast Messages versucht, einen dhcp Server zu finden und mit einer statefull Adreßkonfiguration fortzufahren.
Empfängt der Rechner ein Advertisement Paket, werden zunächst das M bzw. O Flag ausgewertet. Ist der Host dann weiterhin an der Bildung einer global gültigen Adresse interessiert, wird diese aus den Präfixinformationen und der link-local Adresse erzeugt. Eine erneute Duplicate Address Detection ist nicht mehr nötig, da der lokale Anteil schon überprüft wurde. Zur Zeit werden für den lokalen Anteil der Adresse 64 Bit (EUI-64) verwendet. Danach ergibt sich eine maximale Präfixlänge von 64 Bit.
Bei IPv6 haben Adressen per default nur eine begrenzte Gültigkeitsdauer. Somit muß jedes Device in regelmäßigen Abständen den Prozeß der Autokonfiguration neu durchlaufen. Dies bietet dem Netzwerkadministrator die Möglichkeit, neue Präfixe im Router einzutragen. Spätestens nach Ablauf der für das Netz definierten Gültigkeitsdauer verwenden alle Stationen die neuen Adressen.

Mobile IPv6

Da in Zukunft die Anzahl der mobilen Internetnutzer, welche von einem Ort zum anderen reisen und dort immer unter ihrer Heimatadresse erreichbar sein wollen, stark wachsen wird, wurde unter dem Namen ‘Mobility Support in IPv6’ eine spezielle Unterstützung für diese Fälle definiert. [draft mi00]
Jeder Rechner wird zunächst durch seine Heimatadresse indentifiziert, egal an welchem Punkt er ans Internet angeschlossen ist. Ist der Host an einem fernen Punkt ans Netz angeschlossen, ist er außerdem unter seiner dortigen (sogenannten care-of) Adresse zu erreichen. Diese bezieht er an seinem Einsatzort z.B. durch statuslose Autokonfiguration oder dhcp. Um weiterhin auch unter der eigenen Adresse erreichbar zu sein, muß der Heimatrouter aufgefordert werden, als Home Agent zu agieren. Dieser Home Agent hat die Aufgabe, Pakete, welche an die Heimatadresse des mobilen Systems gerichtet sind, an die aktuell verwendete care-of Adresse weiterzuleiten. Um diese Funktion zu aktivieren, sendet man ein Paket mit einem ‘Binding Update’ an den Router. Dieses enhält die zur Zeit benutzte care-of Adresse. Der Home Agent sendet als Antwort ein ‘Binding Acknowledgement’ an den Rechner zurück, in welchem die aktuelle Paketweiterleitung bestätigt wird.
Versucht nun ein ferner Rechner den Mobilen Client zu erreichen, wird dieses Paket vom Heimatrouter erkannt und unter Benutzung eines Routing Headers an die care-of Adresse weitergeleitet. Dabei wird in einem speziellen Optionsfeld die Originaladresse des Absenders mit übergeben. Die mobile Station hat jetzt die Möglichkeit, die Antwort direkt an den Sender zu schicken, wobei sie im IP Header die care-of Adresse einträgt und als Option die Heimatadresse mit übergibt. Der ferne Host sollte dies erkennen und weitere Antworten ohne Umweg über den Home Agent gleich an die aktuell benutzte Adresse senden.
Um zu verhindern, daß diese Funktionen von Hackern ausgenutzt werden, darf Mobile IPv6 nur in Verbindung mit den bei IPv6 definierten Header Sending Authentication, Data Integrity Protection and Replay Protection Funktionen verwendet werden !

1 Binding Update
2 Binding Acknowledgement
3 Paket für mobile Station
4 Weiterleitung des Paketes
5 Antwortpaket, enthält als Option die care-of Adresse
6 Weitere Kommunikation erfolgt über care-of Adresse
Abbildung 19 Funktionsweise von Mobile IPv6


Um seinem Home Agent die aktuelle care-of Adresse bekanntzugeben, wird ihm ein leeres IP Paket mit einem Destination Options Header gesendet, welcher als Option ein Binding Update enthält.

Abbildung 20 Binding Update


Die Felder des Paketes werden wie folgt verwendet:

Option Length: Länge der Option in octets ohne Längen und Type Feld

Acknowledge (A) wird benutzt, um den Home Agent zum Senden eines Binding Acknowledgements aufzufordern

Home Registration (H) wird benutzt, um den Empfänger aufzufordern als Home Agent für die mobile Station zu agieren

Router (R) zeigt an, daß die mobile Station ein Router ist; dieses Bit darf nur zusammen mit dem H Bit gesetzt werden

Prefix Length darf nur in Verbindung mit dem H Flag verwendet werden; Hier wird die Präfixlänge der Heimatadresse übergeben. Diese wird vom Router dazu verwendet, alle anderen Heimatadressen des mobilen Benutzers zu errechnen

Sequence Number dient zur Sicherung gegen Fälschungen

Lifetime gibt die Gültikgeit der Bindung in Sekunden an

Sub-Options zusätzliche Optionen, welche bei Bedarf übergeben werden können



Alle Pakete, die ein Binding Update enthalten, müssen auch eine "Home Address Option" enthalten !
Als Antwort wird vom Heimatrouter ein Binding Acknowledgement gesendet.

Abbildung 21 Binding Acknowledgement


Die Belegung der Felder entspricht der bei einem Binding Update. Der Refresh Wert gibt an, aller wieviel Sekunden die mobile Station ein Refresh Paket für die Paketweiterleitung senden sollte.
Der Status gibt den Return Wert für die aktuell angeforderte Bindung an, wobei folgende Werte definiert sind:

Status Bedeutung
0 Bindung wurde erfolgreich aufgebaut
128 unbekannter Fehler
130 Bindung wurde vom Administrator untersagt
131 keine ausreichenden Resourcen vorhanden
132 Home Agent Funktion wird nicht unterstützt
133 Rechner liegt nicht in diesem Subnetz
135 Antwort auf dynamische Anforderung
136 falsche Interface Identifier Länge
137 kein Home Agent für diese mobile Station
Tabelle 4 Binding Acknowledgement Statuswerte


Eine weitere Option (Binding Request) wurde zur Abfrage der aktuellen Bindung eines mobilen Rechners definiert. Erhält ein Rechner ein Paket mit einer solchen Option, sollte er ein Binding Update an den Rechner senden, von welchem das Paket stammt.

Abbildung 22 Binding Request


Eine Home Address Destination Option wird von einer mobilen Station verwendet, um einen fernen Rechner von der aktuellen care-of Adresse zu unterrichten. Befindet sich die Station außerhalb des Heimatnetzes, wird im Absender des IP Feldes die gültige care-of Adresse eingetragen und als Option diesem Paket zusätzlich die Heimatadresse übergeben. Der ferne Rechner muß jetzt in der Lage sein, ein solches Paket zu erkennen und Antwortpakete direkt an die care-of Adresse zu senden.

Abbildung 23 Home Address Destination Optionen


Parameter, welche nur in Einzelfällen benötigt werden, können durch Sub-Options übergeben werden. In diesem Fall wird in dem Length Feld der Option ein Wert eingetragen, welcher größer ist als der Standardwert. Die überzähligen Bytes werden als TLV codierte Sub-Options interpretiert und haben das in Abbildung 24 beschriebene Format.

Abbildung 24 Aufbau einer Sub-Option


Ist einem Empfänger ein Sub-Optionstyp unbekannt, so wird diese Option ignoriert.
Zur Zeit sind die folgenden Optionstypen definiert:

Abbildung 25 Pad1 Sub-Option


Das Format dieser Option stellt eine Ausnahme dar, da sie nur einen Typ, aber kein Daten- und Längenfeld besitzt.

Abbildung 26 PadN Sub-Option


Die beiden Optionen übergeben keine Daten und werden nur eingefügt, um eine Ausrichtung von nachfolgenden Optionen an bestimmten Byte Grenzen zu erzwingen. Die PadN Option enthält den Wert N-2 um N Octets auszufüllen. Bei den folgenden Sub-Optionen wird immer die vorgeschriebene Ausrichtung an bestimmten Byte Grenzen mit angegeben.

Abbildung 27 Unique Identifier Sub-Option


Diese Option kann zusammen mit einem Binding Request und einem Binding Update verwendet werden. Sie enthält einen 16 Bit Wert, welcher u.a. dazu genutzt wird, verschiedene Binding Updates, welche von einer Quelladresse gesendet werden, zu unterscheiden.

Abbildung 28 Home Agent List Sub-Option


Diese Option wird ausschließlich zusammen mit Binding Acknowledgement Optionen verwendet. Sie enthält ein Feld mit Adressen von Home Agents für die mobile Station, an welche dieses Binding Acknowledgement gesendet wurde.

Die letzte definierte Option wird zusammen mit einem Binding Update verwendet. Sie enthält eine alternative care-of Adresse, welche anstelle der Source Adresse vom Home Agent im IP Feld verwendet werden soll.

Abbildung 29 Alternate Care-of Address Sub-Option


Die dargestellten Mechanismen von Mobile IPv6 ähneln denen des heutigen GSM Mobilfunkes. Dort erhält ein im Heimatnetz angemeldeter Nutzer bei einem Aufenthalt in einer anderen Zelle ebenfalls eine Gastadresse zugeteilt, so daß bei einem Anruf unter der Heimatnummer der Anruf weitergeleitet werden kann. Gegenwärtig laufen in Japan größere Feldversuche von Mobilfunkanbietern, bei denen versucht wird, IPv6 und Mobilfunk sinnvoll zu verbinden. Zur Zeit ist jedoch noch unklar, ob IPv6 auf der Funkschnittstelle vom Mobilsystemen der dritten Generation zum Einsatz kommen wird. Ein wichtiges Problem dabei ist der noch nicht abgeschlossene Standardisierungsprozeß von Mobile IPv6. Gegenwärtig befindet es sich noch im Draft-Stadium, eine Verabschiedung als RFC steht aber kurz bevor.




IPsec

Während Sicherheitsaspekte bei der Definition von IPv4 weitgehend keine Rolle gespielt haben, wurde diese Problematik bei IPv6 sehr ausgiebig diskutiert. Dies geschah parallel zu den IPsec Erweiterungen von IPv4, so daß beide Protokolle in diesem Punkt sehr starke Ähnlichkeiten aufweisen.
Man hat sich dazu entschlossen, Sicherheit nicht allein den Anwendungsprogrammen zu überlassen, sondern auch auf der IP Ebene Möglichkeiten zur Verschlüsselung und Authentifikation anzubieten.

Authentisierung

Mit Hilfe des Authentication Headers (Tabelle 2) ist es möglich, die Echtheit eines Paketes zu überprüfen sowie die Unversehrtheit der Daten während ihrer Übertragung zu garantieren. Mit Hilfe einer Sequenznummer kann sich der Empfänger vor Angriffen schützen, die aus einer mehrmaligen Wiederholung desselben Paketes hervorgehen können.
Wie schon angedeutet, haben die Authentication Headers (AH) von beiden Protokollversionen im Prinzip den selben Aufbau, wobei hier nur auf die IPv6 Version eingegangen wird.
Der Authentication Options Header hat den in Abbildung 30 beschriebenen Aufbau.

Abbildung 30 Authentication Options Header


Next Header und Hdr Ext Len geben wie üblich den Typ des nachfolgenden Extension-Headers bzw die Länge des AH in 32 Bit Einheiten an, wobei die ersten 8 Byte nicht gezählt werden. Bei dem Security Parameters Index (SPI) handelt es sich um einen 32-Bit Wert, der zusammen mit der Zieladdresse des Paketes das gewünschte Verfahren zur Authentisierung festlegt. Für den SPI sind die Werte 1 bis 255 für eine spätere Verwendung durch die IANA reserviert. Der Wert 0 zeigt an, daß keine Authentisierung vorhanden ist und sollte im Normalfall nicht verwendet werden.
Die Sequenznummer enhält einen monotonen Zähler, welcher vom Sender bei jedem Paket um eins erhöht werden muß. Der Empfänger verwendet dieses Feld zur Anti-Replay Protection. Beherrscht er diese Funktion nicht, wird das Feld ignoriert. Falls über eine Verbindung mehr als 2^32 Pakete laufen, ist ein Überlauf der Sequenznummer nicht vorgesehen. Statt dessen ist eine Initialisierung der Verbindung mit einem Austausch neuer Schlüssel vorgeschrieben.
Das Datenfeld enhält die eigentliche Checksumme, Integrity Check Value (ICV). Dieses Feld muß als Länge ein Vielfaches von 64-Bit haben. Die genaue Verwendung der ICV hängt von dem gewählten Verfahren ab.
Bei der Anwendung der Authentisierung wird, wie später auch bei der Verschlüsselung, zwischen zwei Verfahren unterschieden, dem Transportmodus und dem Tunnelmodus.

Abbildung 31 Transportmodus (vor Einfügen des AH)


Abbildung 32 Transportmodus (nach Einfügen des AH)


Der AH schützt das gesamte Paket, mit Ausnahme der Felder, die beim Transport verändert werden können. Diese Felder werden bei der Bildung der ICV als mit 0 initialisiert betrachtet. Der Destination Options Header kann in einem Paket mehrmals vorkommen und sich vor, nach, oder wie im Beipiel angegeben vor und nach dem AH befinden.

Der Tunnelmodus wird als Point to Point Verbindung (ppp) verwendet, meist um entfernte Netzwerke zu einem logischen Netzwerk zusammenzufassen. Wenn diese Verbindung über das Internet erfolgt, ist es notwendig, diesen Tunnel vor Angriffen zu schüzten. Mehr dazu im Abschnitt über Verschlüsselung.

Abbildung 33 AH im Tunnelmodus




Verschlüsselung

Encapsulating Security Payload (ESP) wird verwendet, um vertrauliche Daten zu verschlüsseln und ihre Unversehrtheit zu garantieren. Außerdem bietet ESP einen wirksamen Schutz vor Data-Replay Attacken. Wie schon beim AH erwähnt, unterscheidet man bei der Anwendung der Verschlüsselung zwischen dem Transportmodus und dem Tunnelmodus. Die erste Variante wird bei der Kommunikation zwischen zwei Rechnern verwendet. Im Normalfall geht man hier davon aus, daß sich die Rechner nicht kennen bzw. keine gültigen Keys für eine Verbindung besitzen. Es muß daher von einem Trust-Center von beiden Rechnern ein One-Session-Key angefordert werden, welcher dann für eine begrenzte Zeit Gültigkeit hat.

Abbildung 34 Verschlüsselung im Transportmodus


Bei diesem Verfahren ist es notwendig, daß jeder Rechner die Verschlüsselung beherrscht und die CPU Leistung ausreichend ist, um sämtliche Daten hinreichend schnell zu verschlüsseln. Die IP Header selbst bleiben unverschlüsselt, so daß Hacker Informationen darüber erhalten können, wohin ein Rechner Verbindungen aufbaut und wann er wieviel Daten sendet.

Zur Verbindung von zwei Firmennetzen über öffentliche Leitungen bietet sich daher der Tunnelmodus an. Hier ist nach außen hin nur die Kommunikation der beiden Router sichtbar, weitere Informationen werden nicht nach außen bekannt.

Abbildung 35 Verschlüsselung im Tunnelmodus


Bei der Verwendung von ESP im Tunnelmodus kann der Einsatz eines Trust-Centers und auch die mit ihm verbundenen Sicherheitsrisiken entfallen, da beide Rechner bei Bedarf neue Schlüssel erzeugen und austauschen können.
Gegenwärtig ist es noch so, daß bestehende US-Exportbeschränkungen eine größere Verbreitung von IPsec Implementationen und Trust-Centern verhindert haben und in diesem Bereich noch keine praktischen Erfahrungen bestehen. Eine Lockerung dieser Bestimmungen könnte hier jedoch für neuen Schwung sorgen.
Im Aufbau stellt der ESP Header eine Ausnahme dar. Er beginnt nicht wie üblich mit Next Header und Längenfeld, sondern sofort mit dem SPI:

Abbildung 36 ESP Header


SPI und Sequenznummer werden bei ESP verwendet wie beim AH beschrieben. Das Feld Payload Data enthält die eigentlichen verschlüsselten Daten. Anhand des SPI und der Zieladresse wird implizit die Länge eines Initialization Vectors (IV) festgelegt, welcher sich am Beginn des Datenfeldes befindet. Die letzten 8 Bit geben den Typ des ersten Headers im Datenfeld, Pad Length die Anzahl der Füllbytes an. Diese Informationen werden vom Empfänger benötigt, um nach der Entschlüsselung das Originalpaket wieder zusammenzusetzen. Da Verschlüsselung alleine wenig Sinn macht, beinhalten die meisten Verfahren zusätzlich noch Möglichkeiten zur Authentifizierung.

Abbildung 37 ESP im Transportmodus


Abbildung 38 Tunnelmodus


Als ESP Trailer werden hier alle Padding sowie das Next Header Feld bezeichnet.
Auf die einzelnen Verfahren zur Verschlüsselung und Authentizierung wird nicht weiter eingegangen, da dies den Rahmen der Arbeit sprengen würde. Auch sind die Methoden selbst nicht Bestandteil von IPv6.



IPv6 Address Privacy

Ein weiterer Aspekt, der im Zusammenhang mit Sicherheit von der IETF diskutiert wird, ist die Adreßgeheimhaltung. Hierbei geht es um Probleme mit „Unique Serial Numbers“, welche man in Zukunft in vielen Geräten finden wird. Hier werden die Adressen aus dem Präfix und der Seriennummer des Herstellers gebildet. Wenn ein solches Gerät eine Web-Page oder eine e-mail anfordert, werden durch die in der Adresse codierten Seriennummer unter Umständen gegen den Willen des Nutzers Informationen, wie z.B. die Art der verwendeten Hardware, übertragen. Die Möglichkeit, die werksseitig gemachten Einstellungen manuell oder per DHCP zu überschreiben, ist zwar vorhanden, war für die IETF aber nicht ausreichend. Daher wird seit kurzem an der Definition eine neuen Typs von Adressen gearbeitet, welcher mit Hilfe von Zufallszahlen gebildet wird.
Man geht davon aus, daß im Normalfall für jede Verbindung ein Initiator und ein Ziel existieren. Dabei ist es so, daß der Endpunkt, z.B. ein Webserver, eine feste Adresse hat, während die Adresse des Clients keine Rolle spielt. Durch eindeutige Seriennummern auf Netzwerkkarten können solche festen IP Adressen ohne manuelle Eingriffe oder evtl. vorhandene Adreßserver generiert werden. Für Geräte, die nicht das Ziel von Verbindungen sein sollen, reicht eine temporär gültige Adresse, die nur für die Dauer der Verbindung verwendet wird. Hier soll in Zukunft der neue Adreßtyp zum Einsatz kommen.
Eine weitere Verbreitung von Internetdiensten über Kabel- und Stromnetze und damit verbundenen Anwendungen wie Telefonie werden dazu führen, daß viele Geräte sowohl Initiator als auch Ziel einer Verbindung sind. Jedes Device sollte also sowohl feste als auch temporär gültige Adressen unterstützen und jeweils neu entscheiden, welcher Adreßtyp für bestimmte Dienste verwendet wird.


[1] Exakt: 340.282.366.920.938.463.463.374.607.431.768.211.456

[2] Als lokales Netz (auch Subnetz) werden alle Rechner bezeichnet, welche sich in der selben Broadcast Domain befinden.

[3] Als unspezifizierte Adresse bezeichnet man die IP 0::0.

 



TheDude
Junior-Member
Beitrag vom:
03-03-2002, 22:52:47

Grosses Kompliment

Dein Artikel ist wirklich gut gelungen, diese Einführung in IPv6 kann ich jeden empfehlen, der sich in übersichtlicher Weise in die Kernpunkte dieser neuen Technologie einlesen will...Gratulation

-----------------------------------------------------
while (!asleep()) sheep++;


[back to top]



Userdaten
User nicht eingeloggt

Gesamtranking
Werbung
Datenbankstand
Autoren:04503
Artikel:00815
Glossar:04116
News:13565
Userbeiträge:16551
Queueeinträge:06236
News Umfrage
Ihre Anforderungen an ein Online-Zeiterfassungs-Produkt?
Mobile Nutzung möglich (Ipone, Android)
Externe API Schnittstelle/Plugins dritter
Zeiterfassung meiner Mitarbeiter
Exportieren in CSV/XLS
Siehe Kommentar



[Results] | [Archiv] Votes: 1136
Comments: 0