Technische Universität Ilmenau Fakultät für Elektrotechnik und

Transcription

Technische Universität Ilmenau
Fakultät für Elektrotechnik und Informationstechnik
Medienprojekt
Mobile IP - aktuelle Entwicklungen
vorgelegt von:
eingereicht am:
Christoffer Cruse, Marko Wilde
01. 03. 2010
Studiengang:
Medientechnologie
Studienrichtung:
Medienproduktion
Anfertigung im Fachgebiet:
Kommunikationsnetze
Fakultät für Elektrotechnik und Informationstechnik
Verantwortlicher Professor:
Wissenschaftlicher Betreuer:
Ilmenau, 28.02.2010
Prof. Dr. rer. nat. habil. Jochen Seitz
Dipl.-Ing. Karsten Renhak
Abstract
Mobile IP is a well known IETF standard for mobile scenarios in IP networks. This
composition presents detailed information on key aspects of Mobile IPv6.
The main approach to ensure mobility is described, while a focus lies on multicast
mechanisms.
Furthermore a testbed was build and a Mobile IPv6 implementation installed. We tested
the setup with different protocol traffic types and correct functionality was proved.
Information on configuration and usage of the testbed and Mobile IPv6 implementation
is also provided.
Kurzfassung
Diese Arbeit beschäftigt sich in Schwerpunkten mit der Funktionsweise von Mobile
IPv6, dem aktuell am häufigsten verwendeten Standard zur Realisierung von Mobilität
über Internetprotokoll.
Es wird eine Übersicht über den Funktionsablauf gegeben sowie eine intensivere Betrachtung der Multicastthematik vorgenommen.
Weiterhin entstand im Rahmen des Medienprojektes eine Testumgebung, in der eine
Mobile IPv6 Umsetzung realisiert wurde. Anschließend wurde die Funktionalität mit
einer Testauswahl erfolgreich überprüft.
Zu Konfiguration und Betrieb dieser Testumgebung sowie der Mobile IPv6 Implementation, liefert die Arbeit entsprechende Beschreibungen.
Inhaltsverzeichnis
i
Inhaltsverzeichnis
1 Einleitung
1
2 Mobile IP
2.1 Einführung . . . . . . . . . . . . . . . . . . . . .
2.2 Terminologie . . . . . . . . . . . . . . . . . . . . .
2.3 Topologien . . . . . . . . . . . . . . . . . . . . . .
2.4 Mobile IPv4 und Mobile IPv6 im Überblick . . .
2.4.1 Mobile IPv4 (MIPv4) . . . . . . . . . . . .
2.4.2 Mobile IPv6 (MIPv6) . . . . . . . . . . . .
2.5 Aufstellung der Unterschiede zwischen MIPv4 und
.
.
.
.
.
.
.
3
3
4
6
7
7
8
9
.
.
.
.
.
.
11
11
11
12
14
14
18
.
.
.
.
.
.
.
21
21
25
25
27
27
28
30
5 Mobile IP Implementierungen
5.1 Übersicht . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
31
31
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
MIPv6
.
.
.
.
.
.
.
.
.
.
.
.
.
.
3 Funktionsabläufe in Mobile IPv6
3.1 Handoff Prozess . . . . . . . . . . . . . . . . . . . . . . . . . .
3.1.1 Erkennen der Router - Router Discovery . . . . . . . .
3.1.2 Konfiguration der Adresse - Address Configuration . .
3.1.3 Erkennen des Netzwerkwechsels - Movement Detection
3.1.4 Registrierung . . . . . . . . . . . . . . . . . . . . . . .
3.2 Return Routability Procedure . . . . . . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
4 Multicast in Mobile IP
4.1 Grundlagen . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4.2 Multicast bei Mobile IP . . . . . . . . . . . . . . . . . . . . . .
4.2.1 Multicast Preference Extension Format . . . . . . . . . .
4.2.2 Remote Subscription . . . . . . . . . . . . . . . . . . . .
4.2.3 Bidirectional Tunneling . . . . . . . . . . . . . . . . . . .
4.2.4 Optimiertes Tunneling . . . . . . . . . . . . . . . . . . .
4.2.5 Multicast in vorhandenen Mobile IP Implementierungen
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
Medienprojekt Christoffer Cruse, Marko Wilde
Inhaltsverzeichnis
5.2
UMIP
5.2.1
5.2.2
5.2.3
5.2.4
5.2.5
ii
. . . . . . . . . . . . . . . . . . . . . . . .
Konfiguration und Installation von UMIP
Kompilieren von UMIP . . . . . . . . . . .
Einstellungen für UMIP . . . . . . . . . .
Konfiguration des Radvd Daemons . . . .
Starten von UMIP . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
33
34
34
35
39
41
.
.
.
.
44
44
48
48
49
7 Auswertung der Testszenarien
7.1 Handoff Verhalten und simulierte Datenströme . . . . . . . . . . . . . .
7.2 Verhalten von Anwendungssoftware . . . . . . . . . . . . . . . . . . . .
51
51
56
8 Zusammenfassung
8.1 Ergebnisse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
8.2 Ausblick . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
59
59
59
A Messungen
62
Literaturverzeichnis
69
Abbildungsverzeichnis
73
Listingverzeichnis
75
Tabellenverzeichnis
76
Abkürzungsverzeichnis
77
Erklärung
79
6 Testumgebung
6.1 Aufbau . . . . . . . . . . . . . . . . . . . . . . . . . .
6.2 Testszenarien . . . . . . . . . . . . . . . . . . . . . .
6.2.1 Handoff Verhalten und simulierte Datenströme
6.2.2 Verhalten von Anwendungssoftware . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
1 Einleitung
1
1 Einleitung
Das rasante Wachstum im Markt mobiler Endgeräte, die in ihrer Leistungsfähigkeit
den Desktop PCs in nichts nachstehen und der stetig steigenden Verfügbarkeit an Möglichkeiten sich mit dem Internet zu verbinden, hat es nötig gemacht sich zunehmend
mit dem Faktor Mobilität auseinanderzusetzen.
Die Nutzer haben sich diesen Gegebenheiten schnell angepasst und ein großes Interesse
daran nahezu überall und jeder Zeit ’Online’ gehen zu können. Damit einhergehend
wächst das Verlangen eine unterbrechungsfreie Verbindung angeboten zu bekommen,
während man mit dem Endgerät unterwegs ist.
Für die Entwicklungsarbeit heißt dies, dass der Verbindungswechsel in erster Linie
transparent für die Anwendungen, gleichzusetzen für den Nutzer, sein muss. Das bedeutet auch, dass der Nutzer keine Interaktionen mit dem Gerät durchführen soll um
die Konnektivität der Verbindung sicherzustellen. Am Ende steht das Ziel, dem Nutzer nahtlose Verbindungsübergänge für ein Höchstmaß an Komfort gewährleisten zu
können.
Auf Betreiberseite wiederum stehen Synergien im Vordergrund. Die Infrastruktur soll
nach Möglichkeit keine Veränderung erfahren um Mobilität als Mehrwert anbieten zu
können. Darüber hinaus sollte der Entwicklungsaufwand durch Verwendung vorhandener Standards, Dienste und Protokolle gering gehalten werden.
Als Ergebnis aus den Anforderungen fiel die Wahl früh auf die Vermittlungs- respektive
Internetschicht nach ISO/OSI bzw. TCP/IP Referenzmodell.
An dieser Stelle können Veränderungen vorgenommen werden, die zum einen Unabhängig vom konkreten physikalischen Medium und zum anderen unsichtbar für die
darüberliegenden Schichten gestaltet sind.
Mobile IP ist die Entwicklung die den Anforderungen gerecht wird und sich als Standard zur Realisierung von Mobilität im Internet etabliert hat. Nachdem mit Mobile
IPv4 als Erweiterung von IPv4 erste gute Erfahrungen gesammelt werden konnten,
greift Mobile IPv6 die Neuerungen durch IPv6 auf und erfüllt dadurch vollends die
1 Einleitung
2
Forderung nach unveränderter Infrastruktur. Da IPv6 und Mobile IPv6 ausgereifte
und zukunftssichere Konzepte für das Internet darstellen, liegt hier der Schwerpunkt
dieser Arbeit.
Themenstellung
Am Fachgebiet Kommunikationsnetze der TU Ilmenau wird an Protokollen und Diensten für die Verwendung im Bereich Mobilkommunikation geforscht. Dabei liegt der
Schwerpunkt auf der Vereinigung von stationären und mobilen Lösungen aus der Internetprotokollwelt.
Mobile IP ist hier ein etablierter Ansatz zur Unterstützung von Mobilitätsszenarien
unter Einbeziehung vorhandener Infrastruktur, der im Rahmen der allgemeinen IPv6
Entwicklung hohe Aufmerksamkeit erhält.
Diese Arbeit hat das Ziel, eine Testumgebung mit läuffähiger Mobile IP Implementation zu realisieren und deren Leistungsfähigkeit zu ermitteln. Dafür sind im Vorfeld
vorhandene Umsetzungen zu recherchieren und relevante Testparameter zu identifizieren. Sollten mehrere öffentlich verfügbare Implementationen gefunden werden, sind
diese gegenüberzustellen und gegebenenfalls praktisch auf der Testumgebung zu vergleichen. Darüber hinaus sollen die veränderten Kommunikationsabläufe von Mobile
IPv6 im Vergleich zu Mobile IPv4 beschrieben und besonderes Augenmerk auf die
Multicastfunktionalität gelegt werden.
2 Mobile IP
3
2 Mobile IP
2.1 Einführung
Mobile IP ist ein Standard zur Realisierung von Makromobilität. Das heißt er ermöglicht das nahtlose Wechseln zwischen verschiedenen Netzwerken mit unterschiedlicher
Netzwerkkennung (Subnetzprefix, Subnetzkennung) in der Adressierung. Dabei ist die
Art des physikalischen Mediums irrelevant, solange die Adressierung mittels Internetprotokoll umgesetzt wird. Abbildung 2.1 gibt ein Beispiel für den Aufbau einer IP
Adresse.
Länge der Netzkennung hier ersten 16 Bit
192.168.0.25/16
Netzkennung
Endgerätkennung
Abbildung 2.1: Aufbau einer IPv4 Adresse
Grundlegend basiert Mobile IP auf einem Drei-Säulen-Modell: der Erkennung des
Netzwerkwechsels, der Registrierung der aktuellen IP Adresse und dem Tunneln von
Paketen zu dieser aktuellen IP Adresse [Perk98].
Dabei identifiziert die IP Adresse ein konkretes Endgerät und ermöglicht, durch den
Aufbau über Netzwerkkennungen, die Wegewahl (Routing) durch das gesamte Netz.
Welche Richtung ein Paket nimmt entscheidet die jeweilige Zieladresse und die Zustände der möglichen Wege. Verändert ein Endgerät seinen Standort und ebenso das
Zielsubnetz aber seine IP Adresse nicht, können die Pakete nicht mehr zugestellt werden. Hieraus ergibt sich die Notwendigkeit zusätzliche Maßnahmen zu ergreifen um die
Erreichbarkeit sicherzustellen.
Mobile IP führt dazu die Verwendung von zwei IP Adressen ein. Eine Adresse dient
der Identifikation des Endgerätes, die andere der Wegewahl. Diese Änderung allei-
2 Mobile IP
4
ne würde aber Probleme auf der darüberliegenden Transportschicht hervorrufen. Das
Transmission Control Protocol (TCP) z.B. verwaltet aktive Verbindungen anhand der
IP Adresse plus einer Portnummer. Damit Pakete derselben Verbindung zugeordnet
werden, erwartet TCP immer die gleiche Adressierung.
Hier sorgt Mobile IP dafür, dass Pakete nur mit der Identifikationsadresse an höhere
Schichten weitergereicht werden. Die Identifikationsadresse muss somit jedem Paket
angefügt werden.
Um die Verknüpfung zwischen beiden Adressen herzustellen bzw. bekannt zu geben,
wird eine Registrierung bei einer verwaltenden Instanz (sog. Home Agent) und eventuell bei den Kommunikationspartnern (sog. Correspondent Node) durchgeführt.
2.2 Terminologie
Bevor in den nachfolgenden Ausführungen auf einzelne Aspekte der Mobile IP Standards eingegangen wird, soll zunächst eine Reihe von Begriffsdefinitionen vorangstellt
werden. Die Definitionen sind den entsprechenden Standards, [Perk02] und [JoPA04],
entlehnt und sollen das Verständnis unterstützen.
Heimnetz Bezeichnet das Netz in dem sich der Home Agent befindet und aus dessen
Subnetzkennung die Heimadresse für den Mobile Node abgeleitet wird.
Heimadresse Ist eine eindeutige IP Adresse, die mit dem Mobile Node assoziiert ist
und die sich nicht ändert, solange der Mobile Node sein Heimnetz verlassen hat.
Home Agent (HA) Der Home Agent ist ein Router der die Mobile Nodes eines
Subnetzes verwaltet. Verlässt ein Mobile Node sein Heimnetz, registriert dieser seine
aktuelle Adresse beim Home Agent. Der Home Agent leitet anschließend alle Pakete
die für einen, bei ihm angemeldeten Mobile Node bestimmt sind, an dessen aktuelle
Adresse weiter. Der Home Agent muss dabei nicht derjenige Router sein der den Zugang
zum Subnetz kontrolliert, sondern kann sich an einem beliebigen Punkt im Heimnetz
befinden.
Mobile Node (MN) Als Mobile Node gelten alle Endgeräte die ihren Standort zwischen verschiedenen Subnetzen wechseln und mit jedem der Subnetze eine Verbindung
aufbauen. Der Mobile Node bezieht hierbei eine sogenannte Care-of Address und registriert diese bei seinem Home Agent.
2 Mobile IP
5
Care-of Adresse (CoA) Ist eine eindeutige IP Adresse des aktuell besuchten Fremdnetzes, unter der der Mobile Node global erreichbar ist. Die Verknüpfung von CoA
und Heimadresse heißt Binding, eine entsprechende Aktualisierung dieser Verknüpfung Binding Update.
Correspondent Node (CN) Die Bezeichnung Correspondent Node umfasst all die
Endgeräte, welche mit dem Mobile Node kommunizieren. Diese müssen nicht Notwendigerweise Mobile IP untersützen.
Foreign Agent (FA) / Access Router (AR) Im Falle von Mobile IPv4 ist der Foreign
Agent derjenige Router, bei dem sich der Mobile Node im Fremdnetz registriert und
dessen IP Adresse (Foreign Care-of Address) den Tunnelendpunkt für weitergeleitete
Pakete des Home Agent darstellt. Der FA leitet diese Pakete anschließend an den
Mobile Node weiter.
Access Router in Mobile IPv6 leiten ebenfalls Pakete direkt an den MN weiter, erfüllen
darüber hinaus aber keine Funktionalitäten des Standards.
FA und AR sind in der Regel die Defaultrouter des MN.
Handover / Handoff Wechselt ein Mobile Node bei aktiver Verbindung den Access
Point, d.h. den Punkt an dem er mit dem Netz verbunden ist, spricht man von einem
Handover oder Handoff. Findet der Wechsel innerhalb desselben Subnetzes statt, wird
einzig die physische Verbindung neu aufgebaut und keine neue IP Adresse bezogen. Es
handelt sich dabei um einen Layer-2 Handoff. Ein Layer-3 Handoff bezeichnet dann
den Wechsel des Subnetzes mit entsprechender Änderung der IP Adresse.
2 Mobile IP
6
2.3 Topologien
Im Internetprotokoll wird eine Netzwerkunterteilung in Subnetze vorgenommen. Diese
Subnetze werden durch eine Subnetzeknnung identifiziert. Mobile IP teilt die Subnetze in zwei Kategorieren ein, auf der einen Seite Heimsubnetze und auf der anderen
Fremdsubnetze.
Ein oder mehrere Home Agents spannen hierbei ein Heimnetz auf und verwalten dem
Heimnetz zugehörige mobile Endgeräte. Ein Home Agent muss dabei nicht zwingend
der Gateway für das Heimnetz sein.
Fremdnetze werden im Falle von Mobile IPv4 über Foreign Agents gebildet und sind
Gateways zum Internet. Bei Mobile IPv6 entfällt die Funktionalität der Foreign Agents.
Damit unterscheiden sich die Topologien von Mobile IPv4 und Mobile IPv6 nicht
grundlegend. Es ergeben sich die in den Abbildungen 2.2 für MIPv4 und 2.3 für MIPv6
Netzwerktopologien. Der Tunnelendpunkt vom Home Agent zum Mobile Node ist standardmäßig vom Foreign Agent direkt zum Mobile Node verlegt.
5.2.0.0
Correspondent Node
Pakete für MN
Home Agent
Internet
IP - Tunnel
FA 1 : 10.5.0.0
FA 2 : 20.10.0.0
HoA : 5.2.0.10
CoA:
1. FA CoA : 10.5.0.0
Movement
2. Co-located CoA : 10.5.x.x
Mobile Node
Abbildung 2.2: MIPv4 Topologie
2 Mobile IP
7
HA :
2001:1af8:fe85:100c::10/64
Correspondent Node
Pakete für MN
Internet
IP - Tunnel
AR 1 :
AR 2 :
2001:1af8:fe85:100a::10/64
Movement
HoA :
2001:1af8:fe85:100c::17:01/64
CoA :
2001:1af8:fe85:100a::ac:dc/64
2001:1af8:fe85:100b::10/64
Mobile Node
Abbildung 2.3: MIPv6 Topologie
Durch die Integration der Routen Optimierung als fester Bestandteil von MIPv6
ergibt sich die Notwendigkeit des IP Tunnels nur in den Fällen, in denen der Correspondent Node noch nicht über die aktuelle Care-of Adresse verfügt.
2.4 Mobile IPv4 und Mobile IPv6 im Überblick
In diesem Abschnitt folgt jeweils eine kurze Zusammenfassung der Funktionsweise von
Mobile IPv4 und Mobile IPv6. Daran anknüpfend werden die wesentlichen Unterschiede zwischen beiden Standards aufgeführt, um im nächsten Kapitel die Neuerungen und
Besonderheiten von Mobile IPv6 näher zu beschreiben.
2.4.1 Mobile IPv4 (MIPv4)
Mobile IPv4 dient der Realisierung von Mobilität in IPv4 Netzen und stellt eine Erweiterung des entsprechenden IPv4 Standards dar. Es wurden hierfür drei Objekte
eingeführt mittels derer die Funktionalität implementiert wird: der Home Agent (HA),
Mobile Node (MN) und Foreign Agent (FA).
Der Home Agent befindet sich im Heimnetz des Mobile Node und ist für die Verwaltung der Mobilitätsinformationen der mit ihm assoziierten MNs zuständig. Befindet
2 Mobile IP
8
sich ein Mobile Node in einem Fremdnetz stellt der Foreign Agent eine Care-of Adresse (CoA) zur Verfügung. Diese fungiert als aktuelle Adresse unter der der Mobile Node
erreichbar ist. Diese CoA ist dabei nicht eindeutig, sondern umfasst alle mobilen Geräte innerhalb der Abdeckung eines Foreign Agents.
Darüber hinaus besteht für den FA die Möglichkeit einem Mobile Node eine eigene
Co-located Care-of Address zuzuweisen. Damit wird ermöglicht, den MN direkt über
diese Adresse zur erreichen.
Das ein Router als FA agieren kann, gibt dieser mittels Broadcast von Agent Advertisment Messages bekannt. Ein Mobile Node der sich mit einem solchen Subnetz verbindet, empfängt diese Nachrichten und meldet sich beim FA an. Anschließend initialisiert
er die Registrierung bei seinem Home Agent. Durch Registration Request/Response
Nachrichten wird die Verknüpfung von Heimadresse und CoA hergestellt.
Pakete die an die Heimadresse des Mobile Node gesendet werden, fängt der Home
Agent in der Folge ab und tunnelt sie an die CoA. Der FA ist Tunnelendpunkt und
leitet die Pakete entsprechend weiter.
Ein Problem, welches hierbei auftritt, ist das Triangular Routing. Alle Pakete der Kommunikationspartner, Correspondent Nodes (CN), werden über den HA geroutet. Das
bedingt zum einen lange Handover Verzögerungen, durch den Umweg über den HA
[XiNa09] und zum anderen vermeidbaren Verkehr in Teilen des Netzes.
Durch Route Optimization, als nicht standardisierte Erweiterung zu MIPv4, kann das
Triangular Routing Problem gelöst werden. Dafür wird auch beim CN eine Verknüpfung zur aktuellen CoA registriert.
2.4.2 Mobile IPv6 (MIPv6)
Die Entwicklung von Mobile IPv6 erfolgte anhand der Erfahrungen mit Mobile IPv4
und den grundlegenden Neuerungen durch IPv6. Als entscheidende Änderung ermöglicht der große Adressraum der 128 Bit langen IPv6 Adressen, die Zuteilung von eindeutigen Care-of Adressen für jedes mobile Endgerät. Deshalb entfällt in MIPv6 der
Foreign Agent vollständig. Ersetzt wird die Bestimmung einer gültigen CoA durch die
Address Autoconfiguration.
Den Layer-3 Handoff und damit die Veränderung der Subnetzkennung kann der Mobile
Node aufgrund von Router Advertisment Messages und Neighbor Unreachable Detection erkennen. Weiterhin kann der MN durch eine Neighbor Solicitation Message einen
Router zum senden eines Router Advertisments zwingen.
Nach einer Verbindungsunterbrechung lässt sich hiermit die Verzögerung bis zum er-
2 Mobile IP
9
kennen des neuen Subnetzprefixes verringern.
Alle vier Funktionalitäten sind in IPv6 [DeHi98] spezifiziert.
Hat der Mobile Node eine gültige CoA bezogen wird ebenfalls eine Aktualisierung der
Verknüpfung HoA / CoA beim Home Agent durchgeführt. MIPv6 sieht darüber hinaus
eine Registrierung mit den Correspondent Nodes vor. Route Optimization ist damit
ein integraler Bestandteil von Mobile IPv6.
CNs die nicht über die gültige CoA verfügen, senden ihre Pakete weiterhin an die Heimadresse. Der HA tunnelt diese dann direkt an den MN unter Verwendung der in IPv6
vorgesehenen und in MIPv6 spezifizierten Extension Header.
2.5 Aufstellung der Unterschiede zwischen MIPv4 und
MIPv6
Die aus den vorangestelten Erläuterungen bereits abzusehenden Unterschiede zwischen
MIPv4 und MIPv6, sollen an dieser Stelle nochmals aufgeführt und um weitere, gemäß
RFC 3775 [JoPA04], ergänzt werden.
• Die Notwendigkeit eines Foreign Agents ist nicht mehr gegeben. An die Router
in Fremdnetzen werden keine gesonderten Anforderungen mehr gestellt.
• Route Optimization (RO) wurde als obligatorische Funktionalität in den Standard aufgenommen und ist nicht mehr externe Erweiterung. Weiterhin ist die
Routen Optimierung auf globaler Ebene, auch ohne vorherigen Austausch über
Sicherheitsmechanismen, gesichert. MIPv6 spezifiziert hierzu die sogenannte Return Routability Procedure 3.2.
• Die Verwendung von Route Optimization zwischen Netzen deren Router Ingress
Filtering 1 implementieren, wird ebenso unterstüzt.
• Durch die Neighbor Unreachable Detection ist die Erreichbarkeit zwischen Mobile
Node und Defaultrouter für beide Seiten gewährleistet.
• Aufgrund der Nutzung des Routing Header, anstatt IP-in-IP Encapsulation reduziert sich der notwendige Overhead in Mobile IPv6. Ebenso entfällt hierdurch
das vorhalten von Tunnel Soft State Informationen.2
1
Ingress Filtering - Zugangskontrolle; alle Pakete deren IP Subnetzkennung nicht zum nachgeschalteten Netz des Routers gehören, werden verworfen. - siehe [FeSe00]
2
Umfasst Informationen über: Maximum Transmission Unit (MTU), Time To Life (TTL) und Erreichbarkeit des Endpunktes des Tunnels [GiNH93]
2 Mobile IP
10
• Mit der Einführung der Neighbor Discovery ist Mobile IPv6 unabhängig von
einer bestimmten Umsetzung der Netzzugangsschicht. Das Address Resolution
Protocol (ARP) aus IPv4 findet keine Verwendung mehr. Damit erhöht sich
weiterhin die Robustheit von MIPv6.
11
3.1 Handoff Prozess
Der Handoff Prozess oder Handover beschreibt die Änderung der IP - Verbindung und
wird durch Initialisierung einer neuen Verbindung auf Ebene der Netzzugangsschicht
(Link-Layer Handoff ) eingeleitet. Wurde eine neue physikalische Verbindung aufgebaut, beginnt der Mobile Node mit der Suche nach neuen Routern und anschließend
der Konfiguration einer IP Adresse. Ist die Adresse eingestellt startet die Movement
Detection, d.h. der Mobile Node überprüft ob eine Änderung der Subnetzkennung vorliegt. Abschließend wird die Registrierung nach MIPv6 durchgeführt.[Vogt06]
Den Ablauf des Handoff Prozesses ohne zusätzliche Optimierung zeigt Abbildung 3.1,
nachstehend wird auf die einzelnen Schritte näher eingegangen.
Router
Discovery
Address
Configuration
Movement
Detection
Bindings
Abbildung 3.1: Blockdiagramm Handoff Prozess
3.1.1 Erkennen der Router - Router Discovery
Um einem Endgerät die im Netz vorhanden Router und Netzkennungen anzuzeigen,
werden Router Advertisement Messages nach Definition in RFC 4861 [NNSS07] durch
die Router versendet. Dabei handelt es sich konkret um ICMPv6 Pakete die per Multicast verschickt werden.
Das Intervall für die Router Advertisements (RA) in IPv6, beginnt im unteren Bereich
bei 3 bis 4 Sekunden und liegt im Maximum bei 1800 Sekunden. Zur Detektion von
Netzwechseln bzw. Prefixänderungen sind die Wartezeiten von mehreren Sekunden für
ein Advertisement zu lang.
Deshalb definiert Mobile IPv6 an dieser Stelle neue untere Grenzen der Wiederholraten
12
von 30 Millisekunden (Minimales RA Intervall) bzw. 70 Millisekunden (Maximales RA
Intervall). Damit ergibt sich im Mittel eine Zeitspanne von 50ms zwischen zwei Router
Advertisements, was wiederum bedeutet, dass ein Mobile Node im Mittel 25ms nach
einem Handover ein RA erwarten kann.[Vogt06]
Neben der mit dieser Maßnahme verbesserten Unterstützung von mobilen Endgeräten,
nimmt MIPv6 weitere Änderungen an den Nachrichten vor.
Um dem MN anzuzeigen, dass ein Router als Homet Agent fungiert wird das H - Flag
in den RA Nachrichten eingeführt. Weiterhin erhält der Home Agent die Möglichkeit
Informationen über seine Lebensdauer (Zeitdauer wie lange der HA als solcher arbeitet) und Priorität (Rangfolge bei mehreren HAs im Heimnetz) anzuhängen. Zuletzt
kann ein Router durch das neue R - Flag und das zugehörige Prefix - Feld seine
globale IPv6 Adresse bekannt geben. Das vereinfacht die Bestimmung des aktuellen
Subnetzprefixes. Abbildung 3.2 zeigt ein Router Advertisment nach Darstellung in
Wireshark.
3.1.2 Konfiguration der Adresse - Address Configuration
Eine neue Care-of Adresse wird dann vom Mobile Node erstellt, wenn er ein Router
Advertisement mit geänderter Subnetzkennung empfängt. Die Bestimmung der neuen,
global eindeutigen Adresse erfolgt typischerweise mittels Stateless Address Autoconfiguration [ThNJ07]. Hierzu setzt der Mobile Node aus dem Subnetzprefix des RAs und
einem entweder zufällig gewähltem oder aus der MAC - Adresse bestehenden Interface
Identifier, die IPv6 Adresse zusammen.
Anschließend sendet der MN eine Multicast Listener Report Message (MLR) um der
Multicastgruppe der neuen IP Adresse beizutreten. Wurde das Router Advertisement
zuvor per Multicast gesendet, wartet der MN bis zu einer Sekunde mit dem versenden
der MLR. Dies dient dazu eine Desynchronisation1 mit benachbarten Knoten zu erreichen, die ebenfalls auf dasselbe RA reagieren.
Im nächsten Schritt führt der Mobile Node den Duplicate Address Detection Mechanismus aus. Es wird an dieser Stelle überprüft, ob die zuvor erstellte Care-of Adresse
bereits im Subnetz verwendet wird oder nicht. Der Mobile Node verschickt dafür eine
Neighbor Solicitation Message mit der Care-of Adresse als Ziel. Wird innerhalb einer
Sekunde keine Antwort, d.h. eine Neighbor Advertisement Message empfangen, ist die
CoA dem Interface fest zugewiesen. Daraus ergibt sich eine Zeitspanne zwischen einer
und zwei Sekunden für die Konfiguration der Adresse.
1
Verhindern von Lastspitzen
13
Abbildung 3.2: Beispiel für ein Router Advertisement
14
3.1.3 Erkennen des Netzwerkwechsels - Movement Detection
Der Übergang zwischen zwei Netzen geht einher mit einer Änderung der IP - Verbindung und daraus resultierenden Arbeitsschritten. So muss ein neuer Standardrouter
gewählt, die letzte CoA entfernt und eine neue eingerichtet werden. Ebenfalls muss die
Link-Local Adresse im neuen Netz auf Eindeutigkeit überprüft und zuletzt der MIPv6
Registrierungsprozess durchlaufen werden.
Die Bewegung lässt sich prinzipiell auf zwei Arten detektieren. Zum einen aktiv, durch
die Neighbor Unreachability Detection nach [NNSS07]. Mittels Neighbor Solicitation
/ Advertisement Messages wird festgestellt ob der Link zum Defaultrouter bidirektionale Erreichbarkeit gewährleistet. Ist dies nicht der Fall muss entsprechend ein neuer
Defaultrouter gefunden werden. Bedient dieser ein anderes Subnetzprefix wird eine
neue CoA erstellt und registriert. Enthalten die RAs des neuen Defaultrouters dieselbe
Subnetzkennung, kann sich daraus ein eventueller L2 - Handoff ableiten lassen.
Im Regelfall wird der Netzwerkwechsel durch passives verfolgen der Router Advertisements erkannt. Enthält ein empfanges RA eine neue Subnetzkennung, kann davon
ausgegangen werden, dass ein Wechsel stattgefunden hat. Da ein RA allerdings ein unvollständiges oder fehlerhaftes Subnetzprefix enthalten könnte, sollten für eine sichere
Aussage mehrere RAs abgewartet werden.
Erschwert wird die Detektion eines Handovers zusätzlich durch den nicht exakt zu
bestimmenden Zeitpunkt des eintreffens eines Router Advertisements. Um dem entgegenzuwirken spezifiziert MIPv6 eine Advertisement Interval Option. Hier trägt der
Router die Maximale Zeitspanne bis zum senden des nächsten RAs ein. Diese Angabe
korrespondiert mit dem Wert des ’Maximum Router Advertisement Interval’. Beläuft
sich dieser Wert auf unter 200ms, z.B. 70ms wie in 3.1.1, addiert der Mobile Node 20ms
und erwartet ein neues RA somit nach spätestens 90ms. Empfängt der Mobile Node
drei RAs in Folge nicht, kann von einem Handover ausgegangen werden [Vogt06]. Damit
ergäbe sich eine Maximale Verzögerung von 270ms bis zum anzeigen eines Handoffs.
3.1.4 Registrierung
Nachdem der Mobile Node eine gültige IPv6 Adresse bezogen hat, registriert er diese
bei seinem Home Agent sowie allen aktiven Correspondent Nodes. Mit dieser Registrierung wird die Verknüpfung (Binding) zwischen Care-of Adresse und Heimadresse
hergestellt.
Die an dieser Stelle ausgetauschten Nachrichten verwenden den mit MIPv6 neu eingeführten Mobility Header (Abb. 3.3). Der Mobility Header ist dabei ein zusätzlicher
15
Extension Header im Sinne des IPv6 Standards. Die für die einfache Registrierung
verwendeten Nachrichten sind das Binding Update, Binding Acknowledgement und
Binding Refresh Request.
IPv6 Header
Next
Header
Header
Length
MH Type
Reserved
Checksum
Message Data
Mobility Header = Wert 135 im IPv6 - / Next - Header Feld
MH Type Werte:
0 - Binding Refresh Request
1 - Home Test Init
2 - Care-of Test Init
3 - Home Test
4 - Home Test Init
5 - Binding Update
6 - Binding Acknowledgement
7 - Binding Error
Abbildung 3.3: Aufbau Mobility Header
Der Mobile Node beginnt immer mit dem senden des Binding Updates für den Home
Agent. Darin werden die im Datenfeld enthaltenen Flags für Home Registration (H)
und Acknowledgement (A) immer gesetzt.
Um die Verbindung aus Care-of Adresse und Heimadresse anzuzeigen, wird im Destination Option Header aus IPv6 die Home Address Option als neuer Typ definiert. Die
Heimadresse wird dadurch im Destination Option Header, bei gesetztem Heimadresse
Option Type, übertragen. Hat der Home Agent das Binding Update empfangen, aktualisiert er entsprechend seinen Binding Cache und Antwortet dem Mobile Node mit
einem Binding Acknowledgement, sofern keine Fehler aufgetreten sind.
Um Pakete die für den Mobile Node im Heimnetz eintreffen abzufangen und anschlies-
16
send weiterzuleiten, führt der Home Agent bestimmte Operationen im Heimnetz aus.
Dies sind zum einen die Duplicate Address Detection um sicherzustellen, dass kein anderes Endgerät im Heimnetz die Heimadresse des Mobile Node verwendet. Die zweite
Operation ist die Proxy Neighbor Discovery, hier antwortet der HA auf Neighbor Solicitation Nachrichten anderer Knoten im Heimnetz, die die Heimadresse des MN als
Ziel verwenden. Durch diese Mechanismen übernimmt der Home Agent die Identität
des Mobile Node im Heimnetz, solang dieser abwesend ist.
Hieraus folgt weiterhin, dass bei Rückkehr ins Heimnetz, der Mobile Node ebenso ein
Binding Update durchführen muss. So wird gewährleistet, dass der Home Agent den
zugehörigen Eintrag im Binding Cache entfernt und nicht mehr als Mobile Node agiert.
Neben der Übernahme der Identität für globale IPv6 Adressen, kann der Mobile Node
durch dass Link-local Address Compatibility (L-) Flag im Datenfeld, dasselbe Verhalten für seine ’Link-local Adresse’ bewirken.
Zur Veranschaulichung des Aufbaus zeigt Abbildung 3.4 ein Binding Update für den
Home Agent.
Binding Updates mit Correspondent Nodes können auf zwei Arten umgesetzt werden. Der Mobile Node sendet entweder ein Binding Update (mit oder ohne Acknowledgement Flag) oder greift auf die in Abschnitt 3.2 erläuterte Return Routability Procedure zurück. Letztere führt einen minimalen Sicherheitsmechanismus ein.
Unterstützt der CN Mobile IPv6, sendet er nach erhalt des Binding Updates alle weiteren Pakete direkt an die Care-of Adresse. Um die Transparenz für höhere Schichten
aufrecht zu erhalten, hängt er dem IPv6 Header einen Type-2 Routing Header an.
Dieser ist im Vergleich zum Standard IPv6 Routing Header in der Art modifiziert,
dass er die Heimadresse des Mobile Node enthält. Der Mobile Node greift nach erhalt
des Paketes auf den Header zurück und entnimmt hieraus seine Heimadresse für die
Transportschicht.
Abbildung 3.5 zeigt ein Binding Acknowledgement, welches von einem Correspondent
Node gesendet wurde.
17
Abbildung 3.4: Binding Update an Home Agent
18
Abbildung 3.5: Binding Acknowledgement vom CN
3.2 Return Routability Procedure
Durch den Return Routability Mechanismus wird in Mobile IPv6 eine Authorisierungsmethode eingeführt, die sicherstellen soll, dass die Verbindung aus Care-of Adresse und
Heimadresse eines Mobile Nodes zu diesem gehört und korrekt ist. Wichtig ist diese
Operation vorallem zwischen CNs und MNs, die im Vorfeld keine Informationen übereinander besitzen und somit ein Mindestmaß an Sicherheit gewährleistet werden soll.
Der Ablauf des Vorgangs ist in Abbildung 3.6 dargestellt.
Realisiert wird die Authentifizierung über Cookies und Keygen Token, letzterer repräsentiert einen Wert der über einen geheimen Schlüssel und weitere Daten gebildet
wird. Die Cookies enthalten einen Wert, der vom MN den Nachrichten beigefügt und
vom CN schlicht in seiner Antwort zurückgeschickt wird. Damit wird ein einfaches
Maß ein Gewissheit integriert, dass es sich um den richtigen Kommunikationspartner
handelt.
19
HA
1: - HoA Test Init
- HoA Test
2: - CoA Test Init
- CoA Test
CN
MN
3: - Binding Update
- Binding ACK
Abbildung 3.6: Return Routability Procedure
Soll nun zwischen dem Mobile Node und einem Correspondent Node die Routen Optimierung durchgeführt werden, startet der MN den Return Routability Mechanismus.
Dazu sendet er je eine are-of Test (CoT) Init und Home Test (HoT) Init Message an
den CN. Dabei gelangt die CoT Init auf direktem Weg und die HoT Init über den
Home Agent zum Correspondent Node.
Der komplette Inhalt der Nachrichten ist in Listing 3.1 zu sehen.
1
2
3
4
5
6
7
8
9
10
11
12
13
Home Test Init :
Source Address = Home Address
Destination Address = Correspondent
Parameters :
- Home Init Cookie
Care - of Test Init :
Source Address = Care - of Address
Destination Address = Correspondent
Parameters :
- Care - of Init Cookie
Listing 3.1: Inhalt der CoT und HoT Init Nachrichten [JoPA04]
Nach dem der CN die Nachrichten empfangen hat, berechnet er je einen Keygen
Token für die CoT und HoT. Der Keygen Token, das Cookie und ein Indexwert, der dem
20
CN die Überprüfung des folgenden Binding Updates erleichtert, werden anschließend
an den MN zurück gesendet. Listing 3.2 führt den Inhalt der CoT/HoT nochmals auf.
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
Home Test :
Source Address = Correspondent
Destination Address = Home Address
Parameters :
- Home Init Cookie
- Home Keygen Token
- Home Nonce Index
Care - of Test :
Source Address = Correspondent
Destination Address = Care - of Address
Parameters :
- Care - of Init Cookie
- Care - of Keygen Token
- Care - of Nonce Index
Listing 3.2: Inhalt der CoT und HoT Nachrichten [JoPA04]
Damit die Home Test Nachricht korrekt über den Home Agent zum Mobile Node
getunnelt werden kann, muss entsprechend vor dem Start der Return Routability Operation das Binding Update mit dem HA abgeschlossen sein.
Nachdem die Test Nachrichten ausgetauscht sind, ist der Return Routability Prozess
abgeschlossen. Daran anschließend erzeugt der Mobile Node mittels einer Hashfunktion2 über die beiden Tokens einen Binding Management Key. Mit diesem Key und
weiteren Daten wird erneut ein Hashwert gebildet. Dieser dient dann schlussendlich
der Authentifizierung des Binding Updates.
Die exakten Berechnungsvorschriften sollen an dieser Stelle ausgespart und auf den
RFC 3775 S. 22 ff [JoPA04] verweisen werden.
2
Die Abbildung einer Quellmenge auf eine kleinere Zielmenge
21
4.1 Grundlagen
Die immer stärkere Vernetzung von Rechnern und das vermehrte Nutzen von InternetTV und Webradio macht es notwendig, dass Netzwerke in der Lage sind, Gruppenrufe
von anderen Hosts zu empfangen. Es ist wichtig, dass sich dabei nicht die Bandbreite
beim Sender mit der Anzahl der Empfänger multipliziert. Im Gegensatz zu Broadcastnachrichten, die an alle Teilnehmer eines Netzwerkes gesendet werden, muss ein Host
der Multicastnachrichten empfangen möchte, sich zuerst bei einem Multicastrouter registrieren und sich in die entsprechende Multicastgruppe einschreiben. Alle Nachrichten
dieser Gruppe werden dann durch den Multicastrouter an den PC weitergeleitet (siehe
dafür auch Abbildung 4.1).
Die Hosts, die eine bestimmte IP-Multicastadresse überwachen, werden als Hostgruppe bezeichnet. Ein Computer kann Daten auch an Multicastgruppen übermitteln in
denen er kein Mitglied ist. Die Teilnahme an einer Hostgruppe ist dynamisch, das heißt
die Mitgliedschaft in einer Hostgruppe kann jederzeit aufgelöst oder angetreten werden. Eine Multicastgruppe kann IP-Router in mehreren Netzwerksegmenten umfassen.
Damit diese Konfiguration möglich ist, müssen auch die IP-Router Multicast unterstützen.
Wenn man von Multicast spricht, meint man im üblichen IP-Multicast. Der IP- Multicastverkehr wird an eine einzige IP-Zieladresse gesendet. Dabei handelt es sich jedoch
nicht um eine Adresse welche gezielt für einen Host steht, sondern um eine Gruppenadresse. Ein spezieller Adressbereich ist hierfür vorgesehen, um Konflikte bei der
Adressierung von real existierenden Computern zu vermeiden. Für IPv4 ist durch die
IANA der Adressbereich 224.0.0.0 bis 239.255.255.255 reserviert und bei IPv6 alle
Adressen beginnend mit FF00::/8.
Beim IP-Multicasting, wie es auch beim Mobile-IP angewendet wird, werden die Multicastadressen auf eine Pseudo Media Access Controll(Mac)-Adresse im Ethernet übermittelt. Diese nicht real existierende Mac-Adresse, dient den Routern Multicastnach-
22
Abbildung 4.1: Übersicht von IPv4 Multicast
richten von Unicastnachrichten zu unterscheiden und bereits in der Netzwerkkarte, den
Traffic zu filtern. Die Mac-Adresse wird bei IPv4 und IPv6 aufgrund ihrer verschiedenen Adressierungsformen unterschiedlich erstellt.
Abbildung 4.2: Abbildung einer Multicast IPv4 Adresse auf eine Pseudo Mac-Adresse
Abbildung 4.2 zeigt das Verfahren zur Erstellung von IPv4 Mac-Adressen. Bei IPv4
werden die untersten 23 Bit der IP-Adresse in die MAC-Adresse 01-00-5e-00-00-00
eingesetzt, wodurch sich MAC-Adressen aus dem Bereich von 01-00-5e-00-00-00 bis
01-00-5e-7f-ff-ff ergeben können. Hierbei wird bewusst in Kauf genommen, dass mehrere IPv4-Adressen auf eine MAC-Adresse abgebildet werden. IPv6-Multicast-Adressen
werden abgebildet, indem die letzten vier Bytes der Adresse in die MAC 33-33-0000-00-00 eingesetzt werden. Auch hierbei werden verschiedene Multicast-Adressen auf
23
identische MAC-Adressen dargestellt.
Abbildung 4.3: Einkapselung von IGMP Mittelungen in ein IP-Datagramm
Zur Verwaltung des Multicastverkehrs wird bei IPv4 das Internet Group Message
Protocoll [IGMP] verwendet. Die Abbilldung 4.3 zeigt den Aufbau und die Einkapselung einer IGMP Meldung in ein IP Datagramm. Das Internet Group Message Protocoll
wurde mit der Zeit immer wieder um zusätliche Mitteilungen erweitert. Die IGMP in
der Version 3 wird im RFC 3376 [CDKF+ 02] beschrieben und stellte die letzte Version
dieses Protokolls dar. Sie beinhaltet drei wesentliche Mitteilungen, die zum Verwalten
von Multicastmitgliedern notwendig sind:
• Der Hostmitgliedschaftsbericht, der einer Multicastgruppe mitteilt, dass sich
ein neues Hostmitglied in ihre Gruppe eingetragen hat.
• Die Hostmitgliedschaftsabfrage, welche von Multicastroutern gesendet werden, um sicherzustellen, dass sich Mitglieder in einer Multicastgruppe befinden.
Ist dies nicht der Fall, stellt der Router das Senden von Multicastnachrichten
an diese Gruppe ein. Diese Nachricht wird in regelmäßigen Abständen an die
Multicastadresse der Gruppe gesendet.
• Leave Group Nachricht. Sie dient dazu einem Multicastrouter mitzuteilen,
dass ein Host die Gruppe verlässt und er das letzte Mitglied dieser Subnetzgruppe
war. Dies hat zur Folge das der Router das Senden von Multicastnachrichten an
dieses Subnetz einstellt.
24
Abbildung 4.4: Aufbau einer MLD Nachricht
Bei IPv6 regelt den Verwaltungsprozess beim Gruppenruf die Multicast Listener
Detection (MLD). Die MLD ist im RFC 2710 [DeFH99] beschrieben. Diese Nachricht
ist äquivalent der IGMP in IPv4 und besteht aus einer Reihe ICMPv6 Nachrichten.
Im Gegensatz zu IGMP ist jedoch die MLD ein fester Bestandteil des Internet Controll Message Protokoll Version 6 (ICMPv6). Der Multicast Listener Bericht regelt die
Registrierung eines Host bei einer Multicastgruppe. Die Multicast Listener Abfrage
ist identisch der Hostmitgliedschaftsabfrage in IPv4 und der Multicast Listener Done
Bericht dient zur Beendigung einer Multicastmitgliedschaft in IPv6.
Der Aufbau einer MLD ist in Abbildung 4.4 zu sehen und enthält folgende Datenbereiche:
• Type - Legt die Art der MLD Nachricht fest. Der Wert 130 steht für eine MLD
Abfrage, die 131 für einen MLD Bericht und der Wert 132 steht für eine MLD
Done Nachricht.
• Code - Sender setzen diesen Wert auf 0 und werden vom Empfänger ignoriert.
• Checksum - Standart ICMPv6 Checksum, dient zur Erkennung von Übertragungsfehlern.
• Maximale Antwort Verzögerung - Feld nur für MLD-Abfrage Nachrichten
wichtig. Es gibt an, wie lange nach Erhalt der MLD die Antwort darauf hinausgezögert werden kann.
• Reserviert - Sender setzt diesen Wert auf 0 und wird vom Empfänger ignoriert.
25
• Mutlicast Adresse - Wird bei MLD-Abfrage Nachrichten mit 0 belegt. Bei
Bericht und Done Nachrichten enthält das Feld die Multicast-Adresse die der
Sender überwacht.
Die Anzahl der eingetragenen IP Adressen legt die Größe der MPE Extension fest.
4.2 Multicast bei Mobile IP
Die Multicastunterstützung für Mobile IPv4 ist im RFC 3344 [Perk02] und für Mobile
IPv6 im RFC 3775 [JoPA04] beschrieben. Sie zeigen Empfehlungen zur Umsetzung von
Multicastverkehr in Mobile IP Netzwerken auf. Ein Mobile Node welches sich in seinem
Heimnetzwerk befindet verhält sich beim Empfangen und Senden von Multicastdatagrammen genau so, wie ein Host, welcher sich statisch in einem Netzwerk befindet. Es
benutzt also die selben Multicastmechanismen, wie sie im statischen Netzwerkbetrieb
Anwendung findet. Wechselt der Mobil Node in ein Fremdnetzwerk kann er diese Methoden nicht mehr verwenden. Das folgende Kapitel beschreibt einfache Umsetzungen
von Multicastunterstützung in Mobile IP Netzwerken. Desweiteren wird eine Erweiterung für IGMP Nachrichten in Mobile IPv4 Netzwerken vorgestellt.
4.2.1 Multicast Preference Extension Format
Die Multicast Preference Extension (MPE) erlaubt einem Mobile Node in einem Fremdnetzwerk, dass übermitteln von Optionen an den Home Agent, die das Empfangs- und
Sendeverhalten für verschiedene Multicast Adressen beeinflussen. Dieses Format stellt
eine Erweiterung an die IGMP Nachricht für den mobilen Multicastverkehr da. Perkins
beschreibt den Aufbau dieser Nachricht in seinem Buch Mobile-IP - Design Principles
”
and Practises“ [Perk98] (siehe dazu auch Abbildung 4.5). Durch die Erweiterung ist es
Abbildung 4.5: Aufbau der MPEF
26
möglich, mehrere Multicast Adressen mit einer einzelnen Nachricht beim Home Agent
zu registrieren. Die wichtigsten Flags und Felder sind wie folgt definiert:
• Type - 41
• Length - 2+ (4* Anzahl der enthaltenen Multicast Adressen)
• C - Wenn dieses Flag gesetzt ist, werden alle empfangenen Multicasteinstellungen
durch den Home Agent entfernt. Alle zuvor gesendeten MPE’s des Mobile Nodes
werden vom Home Agent ignoriert.
• P - Der Permanent“ Flag teilt dem Home Agent mit, dass er alle folgenden
”
Multicast Datagramme aktiv halten muss. Bis eine weitere MPE vom Mobile
Node gesendet wird, in der das C“ Flag gesetzt ist.
”
• A - Das Ergänzungs“ Flag verwendet die zuvor empfangenen Spezifikationen
”
und erweitert sie um die Einstellungen, die in dieser MPE enthalten sind. Ist das
A Flag nicht gesetzt, werden alle alten Datagramme ohne Permanent Flag zuerst
gelöscht, bevor die neuen Einstellungen verwendet werden.
• XH - Ist das Senden nach Hause Flag“ gesetzt, möchte das Mobile Node Multi”
castpacket an das Heimnetzwerk senden. Die Zieladressen sind im Multicast IP
”
Adresse“ - Feld festgelegt.
• XF - Ist das Senden ins Fremdnetzwerk“ Flag gesetzt möchte das Mobile Node
”
Multicastpacket an das Fremdnetzwerk senden. Die Zieladressen sind im Multi”
cast IP Adresse“ - Feld festgelegt.
• RH - Das Empfangen von zu Hause“ Flag teilt mit, dass der Mobile Node Data”
gramme aus dem Heimnetzwerk empfangen möchte. Im Multicast IP Adresse“ ”
Feld ist aufgeführt, von welchen Multicastgruppen das Mobile Node Datagramme
empfangen möchte.
• RF - Das Empfangen aus dem Fremdnetz“ Flag teilt mit, dass der Mobile No”
de Datagramme aus dem Fremdnetzwerk empfangen möchte. Im Multicast IP
”
Adresse“ - Feld ist aufgeführt von welchen Multicastgruppen das Mobile Node
Datagramme empfangen möchte.
• rsvd - 0
• Multicast IPv4 Adresse - In diesem Feld sind alle Adressen angegeben, für
die diese Einstellungen gelten.
27
4.2.2 Remote Subscription
Bei dieser Methode nimmt der Mobile Node Verbindung mit einem lokalen Multicastrouter im Fremdnetz auf. Diese Methode ist natürlich nur dann möglich, wenn sich in
dem besuchten Fremdnetzwerk ein Multicastrouter befindet. Das Mobile Node benutzt
seine Co-located Care-of Address für die IGMP Nachricht, um sich beim Multicastrouter zu registrieren. Im RFC 3344 [Perk02] wird ebenfalls vorgeschlagen, dass es
möglich ist, die Heimadresse als Sendeadresse in die IGMP einzutragen. Für Mobile
IPv6 wird eine identische Vorgehensweise bei der Remote Subscription vorgeschlagen.
Der RFC 3775 [JoPA04] beschreibt die Registierung mittels einer MLD Nachricht an
den Router. Zur Registrierung verwendet der Host seine IPv6 Care-of Adresse die er
im Fremdnetzwerk besitzt.
Möchte der Mobile Node in einem Fremdnetzwerk Multicastnachrichten versenden, so
schickt er diese an den entsprechenden Multicastrouter unter Angabe seiner Co-located
Care-of Address bzw. seiner Care-of Adresse als Absendeadresse.
4.2.3 Bidirectional Tunneling
Eine weitere Methode, welche in den RFCs 3344 und 3775 festgelegt ist, um Multicastnachrichten zu erhalten, ist das Bidirectional Tunneling. Das Ablaufdiagramm in Abbildung 4.6 zeigt die Registrierungsprozedur für Multicastpakete über einen Bidirectionalen Tunnel. Ein Mobile Node, dass Multicastnachrichten aus seinem Heimnetzwerk
empfangen möchte, kann mit diesem Verfahren realisiert werden. Dafür ist es jedoch
notwendig, dass der Home Agent ein Multicastrouter ist. Dadurch ist es möglich, dass
der Home Agent anstelle des Mobile Nodes treten kann. Das heißt, im Heimnetzwerk
können alle Multicastnachrichten für den Mobil Node durch den Home Agent abgefangen werden. Der Home Agent übernimmt somit die Aufgabe eines Multicastproxy
für das Mobile Node. Damit der HA die Aufgabe übernimmt, leitet das Mobil Node
über einen Tunnel eine IGMP oder MLD Nachricht an den Home Agent. Dabei wird
die Heimadresse des Mobile Nodes als Quelladresse in den IP-Header eingetragen. Das
Mobile Node signalisiert so seine Empfangsbereitschaft für Multicastdatagramme. Alle Multicastpackete, welche für die Multicastgruppe des Mobile Node bestimmt sind,
werden so vom Home Agent an den Mobilen Rechner weitergeleitet.
Beim Bidirectionalen Tunnel der Multicastpakete ist, wie auch beim normalen Mobile
IP, eine Kapselung von IP-Adressen notwendig. Der Router fängt die Datagramme,
welche für den Mobile Node bestimmt sind ab und wandelt das Multicastpaket in Uni-
28
Abbildung 4.6: Ablauf des Bidirectional Tunnelings in IPv6
castpaket um. Danach tunnelt er die Pakete an die Care-of Adresse des Mobile Nodes.
Das senden von Multicast-Nachrichten durch einen Mobile Node an das Heimnetzwerk
kann ebenfalls auf den selben Weg zurück geschehen. Auch hier ist es wieder Notwendig
das der Home Agent ein Multicast Router ist.
Als Absenderadresse wird in den Nachrichten die Heimatadresse des Mobil Nodes
angegeben. Das Bidirectional Tunneling ist ein sehr einfaches und schnell zu implementierendes Verfahren. Dadurch ergeben sich aber auch Probleme, die in verschiedenen
anderen Internet-Drafts und RFC’s diskutiert wurden. Ein Problem des Tunneling
ist die Individualisierung von Tunneln bei mehreren Mobile Nodes die sich nicht im
Heimnetzwerk befinden. Das heißt, der Home Agent muss für jedes Mobile Node einen
eigenen Tunnel öffnen und verwalten. Befinden sich viele Mobile Nodes, im Netzwerk
des Foreign Agents bzw. Access Routers kann dieses schnell zur Überlastung und zu
Verzögerungen des Multicastverkehrs kommen. Durch viele Tunnel kann es zwischen
Tunnelende und Homeagent bei der Verwaltung der Datagramme zur Überlastung der
Router führen. Ein Problem was besonders bei Echtzeitdiensten, wie Voice over IP zu
Sprachaussetzern führen kann. Eine Möglichkeit dieses Problem zu umgehen, stellt das
Optimierte Tunneling da, dass im folgenden Abschnitt beschrieben werden soll.
4.2.4 Optimiertes Tunneling
Eine Verbesserung des Bidirectional Tunneling kann durch das Einführen eines Multicast Foreign Agent [MFA] oder in IPv6 eines Multicast Member Agent [MMA] umgesetzt werden. Da beide Agents nach dem selben Verfahren funktionieren, wird im
folgenden Abschnitt die Realisierung eines optimierten Multicastverkehrs mittels eines
29
Abbildung 4.7: Ablaufdiagramm eines optimierten Tunnels mittels eines MMA
MMA beschrieben. Ein Entwurf dieses MMA wird von der IETF im Internet-Draft vom
15 Januar 2009 [YaDW09] beschrieben. Der MMA arbeitet als ein Proxy für mehrere
verschiedene Mobile Nodes. Er öffnet jedoch anders, als beim normalen Bidirectional
Tunneling nicht für jedes Node einen Tunnel zum Homeagent. Der MMA verwendet für
das Senden und Empfangen von Multicastpaketen mit dem Home Agent einen einzigen
Bidirectionalen Tunnel. Er ist genau, wie ein normaler Foreign Agent der Endpunkt des
Tunnels, deshalb sollte er gleichzeitig der Accesspoint für die Mobile Nodes darstellen.
Abbildung 4.7 zeigt ein Ablaufdiagramm von Multicast mittels eines MMAs, wie er
in im Internet-Draft Multicast tunneling optimization für Mobile IPv6“ beschrieben
”
wird.
• (0) Der Home Agent sendet in regelmäßigen Abständen über den bidirectional
Tunnel MLD Mitgliedsabfragen zum Mobile Node.
• (1) Das Mobile Node sendet seine Multicastgruppenmitgliedschaft mittels einer
MLD. Diese Mitteilung wird zuerst über den Tunnel an den Homeagent und im
Anschluss an die entsprechenden Multicastrouter versendet.
• (2) Wenn der Home Agent ein Mobile Node gefunden hat, welches einer neuen
Multicastgruppe beitreten möchte, informiert der Home Agent den MMA und
übermittelt die Adresse des MN und die Multicast Adresse. Der MMA speichert
diese Daten in der Multicast Serving Tabelle (MST). Der Home Agent speichert
ebenfalls die Adresse des MN, MMA und die Multicastadresse im lokalen Cache.
30
• (3) Der Home Agent empfängt einen Multicaststream und überprüft, ob die Daten in seinem Cache, mit der Adresse des empfangenen Multicaststreams übereinstimmt.
• (4) Alle Multicastdatagramme, welche für das Mobile Node bestimmt sind, werden zuerst an den dafür zuständigen MMA getunnelt. Der äußere IP Header enthält als Ziel die MMA-Adresse und im inneren das eigentliche Multicastpacket.
• (5) Der Multicast Member Agent überprüft die Multicast Adresse und sucht
aus dem MST die Adresse des Nodes, welche sich für diese Multicastgruppe
eingeschrieben haben. Dabei wird bei mehreren Mobile Nodes, die sich in die
Multicastgruppe eingeschrieben haben, dass Paket einfach so oft wie benötigt
dupliziert.
Der äußere Header wird durch den MMA modifiziert und mit der jeweiligen Heimadresse der einzelnen Nodes ersetzt und weitergeleitet. Verlässt der Mobile Node das
Foreign Netzwerk und betritt ein neues Subnetz teilt das Node dem Home Agent den
Netzwechsel mit. Der Home Agent übermittelt dem neue MMA die Multicastadresse
des Nodes aus seinem Cache. Der neue MMA aktualisiert darauf hin seine MST. Der
alte MMA bekommt ebenfalls eine Nachricht vom HA, um seine MST zu aktualisieren
und den nun überflüssig gewordenen Multicasteintrag für das Node zu entfernen. Nach
dem Handover läuft der Multicastverkehr normal, wie in Abb. 4.7 dargestellt über den
neuen MMA ab.
4.2.5 Multicast in vorhandenen Mobile IP Implementierungen
Multicastunterstützung in Mobile IP ist in vielen Standarts beschrieben. Trotz vielen
theoretischen Ideen, zur Umsetzung eines multicastfähigen mobilen Netzwerkes, ist in
den modernen Implementierungen noch keine Multicastunterstützung gegeben. Keine
recherchierte Mobile IP Umsetzung enthält diese Funktion. Gründe hierfür liegen in den
Schwerpunkten der einzelnen Entwicklergruppen. Das Nautilus6 Projekt zum Beispiel,
welches die modernste frei verfügbare Mobile IP Implementierung besitzt, konzentriert
sich zur Zeit auf andere Schwerpunkte. Besonders das Entwickeln von Verschlüsselungen des Mobile IP Datenverkehrs und das regelmäßige Update ihrer Implementierung
hat einen besonders hohen Stellenwert. Andere Mobile IP Implementierungen sind nur
zu Testzwecken entwickelt wurden und bieten lediglich die minimale Unterstützung
für Mobile IP. Die Umsetzung der vorgeschlagenen Lösungen aus den Standards, wird
vermutlich erst in späteren Implementierungen vorhanden sein.
31
5.1 Übersicht
In diesem Kapitel sollen alle bereits vorhandenen Implementierungen von Mobile IP
aufgezeigt werden. Im Rahmen unseres Medienprojektes wurde die Implementierung
UMIP-0.4 auf ihre Leistungsfähigkeit hin getestet.
Bei der Recherche zu vorhanden Implementierungen fiel auf, dass es für Windowsbetriebssysteme wie zum Beispiel, Windows XP oder Vista, keine Mobile IP Lösungen
gibt. Jedoch arbeitet das Unternehmen Microsoft an einer Lösung, um dieses Feature nachträglich in ihre verschiedenen Betriebssysteme zu integrieren. Lediglich die
Funktionalität als Correspondent Node ist mit Windows XP SP2 und Windows Server 2003 möglich. In der Linux und UNIX Gemeinschaft existieren einige Mobile IPv6
Implementierungen. Jedoch nur noch die UMIP-0.4 Implementierung wird regelmäßig
aktualisiert und ist auf aktuellen Kerneln lauffähig. Der Grund für das durchsetzen von
IPv6 Implementierungen ist die immer größer werdende Nachfrage von IP Adressen
im Internet. Die Übersicht in Tabelle 5.1 zeigt alle vorhandenen Mobile IPv6 Umsetzungen. Die Weiterentwicklung von Mobile IPv4 ist in den Entwicklungsgruppen
eingestellt. Keine der vorhandenen IPv4 Implementierungen arbeitet mit aktuelle Kernelversionen. Der Vollständigkeit halber sind sie in der Tabelle 5.2 mit aufgeführt,
jedoch sind diese Versionen für moderne Netzwerksysteme nicht mehr von Relevanz.
Name
32
Betriebssystem
-
MIPl2v6
[TU H06]
Linux
Kernel 2.4.22 bis
Kernel 2.6.29
-
-
-
MIPv6 Lancaster
[JANE09]
Linux
Kernel 2.6.27
Umip
[WIDE09]
Linux
Kernel 2.4.26
bis
Kernel 2.6.31
-
-
Homeguy
[WIDE09]
Linux
Kernel 2.6.22
-
Shisha
[WIDE09]
UNIX und MacOS 10
-
Bemerkungen
mittels Kernelpatch Kernel 2.6.29
möglich
entwickelt an der TU Helsinki
unterstützt die Standards aus dem
RFC 3775 - Mobility Support
in Ipv6
Entwicklung eingestellt und vom
Nautilus Projekt aufgenommen
und zu Umip weiterentwickelt
entwickelt an der Universität
Lancaster
wird nicht weiterentwickelt
Live CD mit Debian Distribution
enthält die Mobile Ipv6 Implementierung der Uni Lancaster
mittels Startup Scripts werden
Mobile Node Daemons oder
Home Agent Daemon gestartet
Linux Kernel 2.6 (GPL Linzenz)
2005 entwickelt im Rahmen des
Nautilus6 Projekts für Mobil Ipv6
Implementierungen
wird regelmäßig weiterentwickelt
Entwickelt durch das Nautlius6
Projekt
arbeitet mit Umip Implementierungen
Live CD mit Mobile IP Testprogrammen
kann Home Agent oder
Mobile Router simulieren
Entwickelt durch das Nautlius6
Projekt
arbeitet mit Umip Implementierungen
unterstützt die Standarts:
RFC 3775 - Mobility Support
in Ipv6
RFC 4584 - Extensions to
Sockets API for Mobile Ipv6
RFC 3963 - NEMO Basics
NEMO Basic Support Protocol
Unterstützt IPSEC wie er im
RFC 3776 beschrieben wird
Tabelle 5.1: Verfügbare Mobile IPv6 Implementierungen
Name
33
Betriebssystem
UoB-zNOMAD
Linux
[Univ07]
Kernel 2.0 und 2.2 -
HP Mobile IP
[Rodr97]
Linux
Kernel 2.0.30
-
Bemerkungen
Mobile IPv4
Entwicklung eingestellt
basiert auf NOMADv4
unter Sun Public Lizenz
2003 entwickelt an der Universität
Bremen
verwendet RFC 2002 - IP Mobility
Support und RFC 2356 - Sun’s SKIP
Firewall Traversal for Mobile IP
Mobile Ipv4
1997 von HP in Bristol UK entwickelt
enthält die Standards welche im RFC
2002 beschrieben werden
Entwicklung eingestellt
Tabelle 5.2: Verfügbare Mobile IPv4 Implementierungen
5.2 UMIP
Eine weitere Mobile IPv6 Software ist die vom Nautilus6-Projekt gepflegte NEPL
oder auch UMIP. Das UniverSAl playGround for IPv6 (USAGI)-patched MIPv6 for
”
Linux“ kurz UMIP, ist eine Weiterentwicklung der eingestellte Mobile IPv6 Implementierung MIPL2. Es arbeitet mit den in den RFC 3542 [STNJ03] und RFC 4584
[ChNo06] beschriebenen Standards. Dadurch enthält UMIP Socket-API und die im
RFC 4584 [ChNo06] definierte Erweiterung für Netzwerksockets. Das UMIP-Projekt
und Implementierungen für andere Betriebssysteme sind auf der Nautilus6-Projektseite
zusammengefasst. Die Arbeitsgruppen entwickeln und aktualisieren neben UMIP auch
die SHISHA Implementierung für MacOSX und UNIX Systeme. UMIP ist eine Userspaceanwendung, welche durch einfaches installieren in das System eingebunden wird.
Die Arbeitsmodi HA, MN und CN werden durch diese Implementation unterstützt.
Die Software unterstützt Binding Updates, welches ein routenoptimiertes Kommunizieren erlaubt. Die Wahl zur Implementierung von Umip in ein Testbed, lag zum einen
in der Aktualität, da sie als einzige derzeitige Mobile IP Umsetzung, mit aktuellen
Kernels arbeitet und zum anderen stellt sie zugleich die einzige moderne verfügbare
Opensource Implementierung für Linux da. Der UMIP-Daemon ist eine parallelisierte Applikation. Je nach dem wie die Anwendung konfiguriert wurde, arbeiten bis zu
sechs modulierte Threads gleichzeitig. Aufgrund der schlechten Dokumentation ist das
verstehen des Quellcodes sehr schwer. Eine teilweise Beschreibung des Codes wird in
der Diplomarbeit von Stephan Bärwolf [Bärw10] vorgenommen. Das Medienprojekt
34
wird lediglich die für die reibungslose Installation notwendigen Dateien im Kapitel
5.2.3 beleuchten. Ein weiteres Feature dieser Implementierung ist die Unterstützung
von multiplen Care-of Adressen für mobile Router. Diese Unterstützung erlaubt den
mobilen Routern mehrere Care-of Adressen von einem Home Agent zu bekommen.
Dadurch ist es möglich Policy Routing für die mobilen Router zu gewährleisten.
5.2.1 Konfiguration und Installation von UMIP
Die derzeitige Version 0.4 arbeitet mit allen Kernelversion bis 2.6.31. Sie muss im
Gegensatz zu früheren Versionen nicht mehr durch einen Kernelpatch in den Kernel
integriert werden. Ab der Kernelversion 2.6.19 ist die Mobilität von IPv6 ein fester
Bestandteil geworden. Obwohl im Testbed die einzelnen Systeme mit unterschiedlichen
Kernelversionen laufen, ist es notwendig, dass einige wichtige Parameter im Kernel
aktiviert sind, um UMIP zu kompilieren. Diese Parameter werden an dieser Stelle
kurz genannt. Dabei stehen die Bezeichnungen y“ für fest in den Kernel integrierte
”
Parameter und m“ für Module die später geladen werden können.
”
CONFIG_TUN = m - Ein Modul welches ein virtuelles Interface erzeugt , dass später für
IPv6 Tunnelsoftware verwendet werden kann .
INET = y
CO NFIG _IKC ONFI G = y
CONFIG_IKCONFIG_PROC = y
INET6_ESP = y
IPV6_TUNNEL = y
CONFIG_IPV6 = y - Ermöglicht IPv6 Unterstützung im Kernel .
IPV6_MULTIPLE_TABLES = y
IPV6_MIP6 = y - Aktiviert die MIPv6 Unterstützung , welche ab Kernelversion 2.6.19
integriert ist .
XFRM = y
XFRM_USER = y
XF RM_S UB_P OLIC Y = y
INET6_XFRM_MODE_ROUTEOPTIMIZATION = y
NET = y
NET_KEY = y
NET_KEY \ _MIGRATE = y
CONFIG_IP6_NF_IPTABLES = m
CONFIG_IP6 \ _NF_MATCH = m
Listing 5.1: Kernel Konfiguration
5.2.2 Kompilieren von UMIP
Das Kompilieren des UMIP Daemon erfolgt auf dem Home Agent, Correspondent Node
und dem Mobile Node. Dies macht es Notwendig, dass der Mobile Node mit UMIP konfiguriert werden muss, um Mobile IP im Netzwerk zu ermöglichen. Das Paket mipv6”
daemon-umip-0.4.tar.gz“ beinhaltet alle Dateien die für das vollständige kompilieren
35
notwendig sind. Dabei wird nach dem entpacken des Archives, mittels eines configure“”
Script, dass die Software auf das Betriebssystem konfiguriert und Pfadangaben als auch
weitere optionale Anweisungen für den Make-Befehl einstellt. Der Parameter –prefix“
”
erlaubt dem configure“-Scripts, dass festlegen des Zielverzeichnis für die Installation.
”
Das fehlen dieses Parameter installiert den Daemon in das Standardverzeichnis /usr/local/sbin. Das virtuelle Terminal wird mittels des Parameters –enable-vt“ in der
”
Übersetzung berücksichtigt. Für weitere Hilfe zum configure“-Script kann durch den
”
Parameter –help“ eine ausführlich Hilfe angezeigt werden.
”
Nach der erfolgreichen Konfiguration der Übersetzung, kann mittels des make“-Befehls
”
der Daemon erzeugt werden. Wichtig bei dieser Erstellung ist das setzen eines CFLAG
für die Übersetzung. Grund hierfür ist ein Fehler, der in Gentoo beim kompilieren des
Wortes NULL“ auftritt. Dies wird beim Kompilieren als Fehler interpretiert, sodass
”
der make“-Befehl abgebrochen wird. Durch setzen der Umgebungsvariable CFLAGS“
”
”
in Verbindung mit dem Makro (NULL=((void*)0)), wird dieser Fehler behoben. Der
Befehl make install“ installiert die übersetzte Datei in das zuvor durch configure“
”
”
angegebene Verzeichnis.
1
2
3
4
5
6
-
# cd / tmp
/ tmp # tar - xvf mipv6 - daemon - umip -0.4. tar . gz
/ tmp # cd mipv6 - daemon - umip -0.4/
/ tmp / mipv6 - daemon - umip -0.4 # ./ configure -- prefix =/ -- enable - vt
/ tmp / mipv6 - daemon - umip -0.4 # make CFLAGS +=" - DNULL =$\( void \*$0\)"
/ tmp / mipv6 - daemon - umip -0.4 # make install
Listing 5.2: Befehle für das Installerien von Umip-0.4 Daemons
5.2.3 Einstellungen für UMIP
Die Konfiguration des UMIP Daemons erfolgt mit der mip6d.conf. Die Datei muss
erstellt und im Ordner /etc“ abgespeichert werden. Zum besseren Verständnis der
”
einzelnen Optionen, die in der mip6d.conf Verwendung finden, werden sie im folgenden Abschnitt kurz genannt und erläutert:
Allgemeine Parameter:
• NodeConfig - Konfiguriert durch die Werte HA, CN, MN den Arbeitsmodus
des Deamons.
• DebugLevel - Definiert die Menge an Debuginformationen, die auf dem Bildschirm ausgegeben werden sollen.
36
• DoRouteOptimizationCN - Aktiviert optimiertes Routing mit anderen MNs.
Parameter nur für den Home Agent:
• HaMaxBindingLife - Bestimmt die maximale Lebensdauer der Bindings von
MNs in Sekunden.
Parameter für Home Agent und Mobile Node:
• UseMnHalPsec - Schützt bei gesetztem enabled“ die Signalisierungnachrichten
”
zwischen HA und MN mittels IPSec.
• KeyMngMobCapability - Aktiviert den dynamischen Schlüsselaustausch über
MIPv6 fähiges Internet Key Exchange Protokoll.
• Interface - Definiert die Netzwerkschnittstelle mit der UMIP arbeiten soll. Es
ist möglich mit den Parametern MnIfPreference“ und IfType“ mehrer Netz”
”
werkschnittstellen festzulegen, die mittels Prioritäten, hierarchisch von UMIP
verwendet werden. IfType“ legt dabei den Arbeitsmodus des Schnittstelle fest.
”
37
Parameter nur für den Mobile Node:
• DoRoutOptimizationMN - durch Aktivierung mittels enabled“ erlaubt dies
”
den MNs optimiertes Routing zu verwenden, um mit CNs zu kommunizieren
• UseCnBuAck - Aktivierung erlaubt Bestätigungen von CNs für empfangene
Bindingupdates.
• MnDiscardHaParamProb - Erlaubt dem MN das Auswerten der vom HA
gesendeten ICMPv6 Parameterproblem Nachrichten.
• MnRouterProbes - Gibte die Wiederholungsversuche zu einem Router an,
wenn dieser nicht mehr erreichbar ist. Aufgrund der Einflussnahme dieser Einstellung auf den Handoff sollte der Wert auf 0“ gesetzt werden
”
• MNHomeLink - Definiert die Netzwerkschnittstelle, über die das MN mit dem
Heimnetz verbunden ist. Als Block enthält der Parameter HomeAdress“ die
”
Heimnetzadresse mit deren Präfixbitlänge, sowie HomeAgentAdress“ zur Fest”
legung der IPv6-Adresse des HA.
Die einzelnen Konfigurationsdateien für die jeweiligen Arbeitsmodi sind im folgenden
Abschnitt aufgelistet.
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
# Home Agent Configuration
NodeConfig HA ;
Interface " eth0 " {
MnIfPreference 7;
IfType HA ;
}
MnIfPreference 3;
IfType HA ;
}
UseMnHaIPsec disabled ;
K e y M n g M o b C a p a b i l i t y enabled ;
B in d in g Ac l Po l ic y 2001:1 af8 : fe85 :100 c :2 c0 :9 fff : fee1 : b35e allow ;
H aM a xB i nd i ng L if e 60;
Listing 5.3: mip6d.conf für den Home Agent
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
38
# Mobile Node Configuration
NodeConfig MN ;
DebugLevel 0;
# Support Route Optimization with MNs
D o R o u t e O p t i m i z a t i o n C N enabled ;
# Use Route Optimization with CNs
D o R o u t e O p t i m i z a t i o n M N enabled ;
UseCnBuAck enabled ;
M n D i s c a r d H a P a r a m P r o b enabled ;
MnRouterProbes 1;
M n M a x H a B i n d i n g L i f e 60;
M n M a x C n B i n d i n g L i f e 60;
MnIfPreference 1;
IfType MN ;
}
MnIfPreference 5;
IfType MN ;
}
MnHomeLink " eth0 " {
H om e Ag e nt A dd re s s 2001:1 af8 : fe85 :100 c ::1;
HomeAddress 2001:1 af8 : fe85 :100 c :2 c0 :9 fff : fee1 : b35e /64;
}
# IPsec Configuration
UseMnHaIPsec disabled ;
# Key Management Mobility Capability
Listing 5.4: mip6d.conf für das Mobile Node
1
2
3
4
NodeConfig CN ;
DebugLevel 0;
D o R o u t e O p t i m i z a t i o n C N enabled ;
Listing 5.5: mip6d.conf für das Corespondent Node
39
5.2.4 Konfiguration des Radvd Daemons
Für den Betrieb von UMIP ist es notwendig Router Adervertisements über das Netzwerk zu verschicken. Sie dienen der Konfiguration des Mobile Nodes durch den Router
oder Access Point. Der Start des Radv Daemons erfolgt automatisch beim Systemstart. Je nach Knotentyp müssen sie jedoch einzeln Konfiguriert werden. Der Radv
Daemon befindet sich in der Gentoo Portage und lässt sich mit dem Befehl emerge
”
radvd“ installieren. Mittels der Konfigurationsdatei radvd.conf“ können die einzeln
”
Einstellungen für die HA und Access Router vorgenommen werden. Router Advertisements sind speziele IPv6 Datagramme welche ICMPv6 Netzwerkpakete enthalten. Der
übliche IPv6-Paketkopf wie er im RFC 4861 [NNSS07] beschrieben wird ist in der Abbildung 5.1 dargestellt. Sie zeigt den Bitgenauen Aufbau eines Routeradvertisements.
Im folgenden sollen die einzelnen Bereiche des Paketkopfes erläutert werden.
Abbildung 5.1: Datenformat eines IPv6 Router Advertisments
• Type - Der Wert 134 dient neben dem Wert Code zur Signalisierung eines
Router Advertisements.
• Prüfsumme - Dient zur Vermeidung von Übertragungsfehlern und damit verbundenen Paketfehlern.
• Aktives Hop-Limit - Der Wert gibt die empfohlen Routingschritte in IPv6
Paketen für die Netzwerkknoten an.
• M,O - Dienen zur Signalisierung weiterer oder anderer Konfigurationsarten und
machen ggf. bestimmte Paketfelder überflüssig.
• reserviert - Für MIPv6 von Interesse, da hier die Erkennung des verwendeten
Mobilitätsmanagementprotokolls angezeigt wird.
40
• Router Lebensdauer - Gibt in Millisekunden die Zeit an, wie lange der angezeigte Router als Default Router verwendet werden soll.
• Erreichbarkeitszeitraum - Gibt die Zeit an, in der das Advertisement gültig
ist.
• Pause bis Wiederholung - Gibt die Pause nach dem erlöschen des Erreichbarkeitsfensters an. Danach wird eine neue Router Advertisement gesendet.
In den nachfolgenden Dateiauszügen werden die einzelnen Parameter aufgelistet,
welche in der radvd.conf vorgenommen werden müssen. Sie sind notwendig um den
jeweiligen Arbeitsmodi zu ermöglichen.
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
interface eth2 {
AdvSendAdvert on ;
AdvIntervalOpt off ;
A dv H om e Ag e nt F la g on ;
AdvLinkMTU 1280;
Ig nore IfMi ssin g on ;
H o m e A g e n t L i f e t i m e 10000;
H o m e A g e n t P r e f e r e n c e 20;
A dv H om e Ag e nt I nf o on ;
M a x R t r A d v I n t e r v a l 0.1;
M i n R t r A d v I n t e r v a l 0.03;
M i n D e l a y B e t w e e n R A s 0.03;
prefix 2001:1 af8 : fe85 :100 c ::1/64 {
AdvRouterAddr on ;
AdvOnLink on ;
AdvAutonomous on ;
A d v P r e f e r r e d L i f e t i m e 10000;
A dv V al i dL i fe t im e 12000;
};
};
Listing 5.6: radvd.conf für den Home Agent
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
41
# AP1
interface wlan0 {
AdvSendAdvert on ;
AdvLinkMTU 1280;
prefix 2001:1 af8 : fe85 :100 a ::1/64 {
AdvOnLink on ;
AdvAutonomous on ;
AdvRouterAddr on ;
};
};
Listing 5.7: mip6d.conf für den Foreign Access Point 1
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
# AP2
interface wlan3 {
AdvSendAdvert on ;
AdvLinkMTU 1280;
prefix 2001:1 af8 : fe85 :100 b ::1/64 {
AdvOnLink on ;
AdvAutonomous on ;
AdvRouterAddr on ;
};
};
Listing 5.8: mip6d.conf für den Foreign Access Point 2
5.2.5 Starten von UMIP
Um die UMIP Implementierung im Testbed zu betreiben, ist eine feste Reihenfolge beim Starten der einzelnen Komponenten zu befolgen. Sie stellt sicher, dass alle
Komponenten reibungslos funktionieren und der UMIP Daemon erfolgreich startet.
An allen Systemen muss sich zu erst erfolgreich angemeldet werden. Dafür werden die
Login Daten des Mobile IP Medienprojektes verwendet. Dieser Login ist zu gleich mit
Root Rechten ausgestattet, sodass jede Anwendung ohne Probleme gestartet werden
kann. Die einzelnen Befehle zum Starten der benötigten Software an den einzelnen
Terminals, ist in den folgenden Abschnitten beschrieben.
42
Access Points
Zuerst werden die Access Points, die später die Fremdnetze simulieren, gestartet. Dazu muss lediglich der Radv Daemon gestartet werden. Mittels der Anweisung /etc/i”
nit.d/radvd -c /etc/radvd.conf“ wird der Daemon angewiesen mit einer Config“- Datei
”
zu starten die sich im Ordner /etc“ befindet.
”
1
# - / etc / init . d / radvd -c / etc / radvd . conf
Listing 5.9: Befehle zum starten Radvd Daemons in den Access Points
Mobile Node
Beim Mobile Node muss lediglich der MIP6 Daemon gestartet werden. Ähnlich wie
beim Radv Daemon kann mittels des Parameters -c“ eine Config“- Datei beim Star”
”
ten angegeben werden. Der Parameter -d“ kann optional verwendet werden. Er gibt
”
an wieviel Debug Informationen auf dem Terminal ausgeben werden sollen. Der d“
”
Parameter kann einen Wert von 1 bis 10 annehmen.
1
# - / etc / init . d / mipd6d -d 10 -c / etc / mip6d . conf
Listing 5.10: Startbefehle für die UMIP Implementierung beim Mobile Node
Home Agent
Der Home Agent ist das Bindeglied in der UMIP Implementierung. Hier ist es wichtig
das dass Mobile Node mit dem Home Agent verbunden ist. Nur so ist es möglich das der
Radv Daemon erfolgreich startet. Der Grund dafür ist, dass der Daemon beim starten
überprüft ob ein Host mit dem LAN-Interface verbunden ist. Wenn der Radv Daemon
keine verbunden Netzwerkhosts finden kann, werden auch nach späterem Anschluss
von Hosts, keine Advertisements versendet.
Nachdem Radvd erfolgreich gestartet ist, kann mit dem Befehl etc/init.d/mip6d -c
”
/etc/mip6d.conf“ der MIP6 Daemon initialisiert werden. Auch hier kann wieder der
Debug Parameter -d“ gesetzt werden um zusätzliche Informationen zu erhalten.
”
1
2
43
# - / etc / init . d / radvd -c / etc / radvd . conf
# - / etc / init . d / mipd6d -d 10 -c / etc / mip6d . conf
Listing 5.11: Startbefehle für die UMIP Implementierung und Radvd beim Home
Agent
Correspondent Node
Der Correspondent Node braucht zum ordnungsgemäßen Arbeiten in der UMIP Implementierung, nur das starten des MIP6 Daemons. Auch hier wird wie im Abschnitt
Mobile Node“ mittels Parameter -c“ und des genauen Config-Pfads der MIP6 Daemon
”
”
gestartet.
1
# - / etc / init . d / mipd6d -c / etc / mip6d . conf
Listing 5.12: Startbefehle für die UMIP Implementierung beim Correspondent Node
6 Testumgebung
44
6 Testumgebung
In diesem Abschnitt wird als erstes der Aufbau der Testumgebung mit den verwendeten
Komponenten und Einstellungen behandelt. Anschließend folgt eine Beschreibung der
durchgeführten Testszenarien deren Ergebnisse im Kapitel 7. dargestellt werden.
6.1 Aufbau
Die Testumgebung, die im Rahmen des Medienprojektes eingerichtet wurde, besteht
aus sechs IPv6-fähigen Netzwerkknoten. Die verwendete Hardware kommt bis auf den
CN und MN aus dem Bestand der TU Ilmenau.
Das verwendete “/48 IPv6-Subnetz“ wurde beim Tunnelbroker “sixxs“ (http://www.
sixxs.net/) registriert und stellt global eindeutige IPv6 Adressen und IPv6 Subnetze
bereit. Über einen IPv6-in-IPv4 Tunnel ist der Zugang zum Internet v6 gewährleistet.
Die sechs Knoten sind nun konkret ein IPv6-Gateway, ein Home Agent, zwei Access
Router, ein Correspondent Node und Mobile Node. Alle Geräte verfügen über zwei
Netzwerkinterfaces, im Falle der AR, CN und des MN je ein Ethernet und WLAN
Interface. Die Verbindung zwischen IPv6-Gateway, AR, HA und CN erfolgt über einen
D-Link 10/100Mbit Ethernet Switch. Der Abbildung 6.1 ist der Testaufbau zu entnehmen.
Der Gateway bildet in diesem Aufbau den Backbone-Router und stellt das Subnetz
2001:1af8:fe85:1000::/64 zur Verfügung. An dieses Subnetz sind die statischen Knoten (HA, AR, CN) über das erste Interface angeschlossen.
Der Mobile Node verbindet sich über ein IEEE 802.11g Interface mit den beiden Access
Routern und über ein 10/100Mbit Ethernet Interface mit dem Home Agent.
Als Betriebssystem wurde auf allen eingesetzen Rechnern die Linux Distribution
Gentoo in der Kernelversion 2.6.31-r8 bzw. 2.6.30-r8 verwendet.
6 Testumgebung
45
Correspondent Node
Internet
eth0: 2001:1af8:fe85:1000::20/64
sixxs: 2001:1af8:fe00:1f7::2/64
Gateway
Switch
HA
eth2: 2001:1af8:fe85:1000::1/64
eth2: 2001:1af8:fe85:100c::1/64
eth0: 2001:1af8:fe85:1000::100a/64
eth0: 2001:1af8:fe85:1000::100b/64
AR 1
AR 2
wlan0: 2001:1af8:fe85:100a::1/64
MN
eth0: 2001:1af8:fe85:1000::100c/64
wlan3: 2001:1af8:fe85:100b::1/64
Movement
HoA: 2001:1af8:fe85:100c:2c0:9fff:fee1:b35e/64
Abbildung 6.1: MIPv6 Testaufbau
WLAN Konfiguration Die verwendeten WLAN Karten der Access Router basieren
auf dem Atheros-Chipsatz. Dementsprechend wurde im Linux Kernel der ath5k Treiber als Modul compiliert. Um die Karten im Access Point Modus zu betreiben, wird
der hostap Deamon benötigt. Über emerge hostapd lässt sich dieser installieren. Im Testbed wurde die Version 0.6.9 verwendet. Voraussetzung für die Verwendung von hostapd ist die Verfügbarkeit des nl80211-Treiber, dieser ist Teil der Linux
mac80211-Treiber die ebenfalls als Modul im Kernel integriert sind. Die Konfiguration des hostap Deamon für den AR1 ist in Listing 6.1 dargestellt.
Die AR stellen nur ein IEEE 802.11b WLAN bereit, da das Interface im Access Router
1 den 802.11g Standard nicht unterstüzt.
Unterschieden werden beide WLAN-Subnetze über die SSID, für den AR1 lautet diese
AP1“ und für den AR2 AP2“. Über ein Script, welches nach Ablauf einer Zeit tx die
”
”
SSID wechselt, wird die Bewegung zwischen den Netzen simuliert.
6 Testumgebung
1
2
3
4
5
6
7
8
9
10
11
12
13
46
interface = wlan0
driver = nl80211
loggersyslog = -1
l o g g e r s y s l o g l e v e l =2
loggerstdout = -1
l o g g e r s t d o u t l e v e l =2
dump_file =/ tmp / hostapd / dump
ctrl_interface =/ var / run / hostapd
c t r l _ i n t e r f a c e _ g r o u p =0
channel =7
ssid = AP1
country_code = DE
hw_mode = b
Listing 6.1: hostapd Konfiguration für AR1
Probleme der WLAN Konfiguration Zu erwähnen ist, dass bei Änderungen an der
Konfigurationsdatei des hostapd ein einfacher Neustart nicht funktioniert. Bevor der
hostap Deamon neugestartet werden kann, müssen zuvor das mac80211 und jeweilige
WLAN-Treiber Modul de-/reaktiviert werden. Andernfalls kommt es zu einer Fehlermeldung, wonach der nl80211-Treiber nicht initialisiert werden konnte.
Weitere Probleme mit den WLAN Karten ergaben sich aus der Tatsache, dass nicht
alle Chipsätze bzw. deren Treiber den Master / Access Point Modus unterstützen.
Neben den verbauten Atheros Karten wurden zwei Karten mit Hermes (Orinoco/Prism2)Chipsatz sowie ein WLAN Stick mit ZyDAS ZD1211 Chipsatz getestet. Diese ließen
sich nicht in dem Master / Access Point Modus betreiben. Das Problem war zum einen
die fehlende Unterstützung durch den hostap Deamon (Hermes Chipsatz ) beziehungsweise der verfügbaren Firmware (ZyDAS Chipsatz ).
IPv6 Routing Wie bereits erwähnt, stellt der Gateway neben dem Zugang zum Internet ebenfalls den Backbone Router des Netzes dar. Er verfügt als einziger Netzwerkknoten über die Kenntnis aller verwendeter Subnetze.
Damit das Routing korrekt funktioniert muss in den Netzknoten AR1, AR2, HA und
Gateway die Funktion IP Forwarding aktiviert sein. Um dies zu überprüfen und die
Einstellung vorzunehmen, sind die Befehle entsprechend Listing 6.2 auszuführen.
1
2
3
4
5
6
<--- Überprüfung ob IP Forwarding aktiviert ist -->
<--- Ausgabe : 1 - Ja , 0 - Nein -->
~ # cat / proc / sys / net / ipv6 / conf / all / forwarding
<--- Aktivieren des IP Forwarding -->
~ # echo 1 > / proc / sys / net / ipv6 / conf / all / forwarding
Listing 6.2: Einstellen des IP Forwarding
6 Testumgebung
47
Damit das Routing durch die Access Router bzw. den Home Agent zu den angeschlossenen Subnetzen funktioniert, sind am Backbone Router diese 3 Knoten jeweils
als Gateways zu den Subnetzen einzutragen. Die dazu korrespondierende Routingtabelle zeigt Abbildung 6.3.
1
2
3
4
5
6
7
8
9
bootes ~ # route -A inet6
Kernel IPv6 routing table
Destination
2001:1 af8 : fe00 :1 f7 ::/64
2001:1 af8 : fe85 :1000::/64
2001:1 af8 : fe85 :100 a ::/64
2001:1 af8 : fe85 :100 b ::/64
2001:1 af8 : fe85 :100 c ::/64
2000::/3
Next Hop
Flag Met
::
Un 256
::
U
256
2001:1 af8 : fe85 :1000::100 a UG 1
2001:1 af8 : fe85 :1000::100 b UG 1
2001:1 af8 : fe85 :1000::100 c UG 1
2001:1 af8 : fe00 :1 f7 ::1
UG 1
IF
sixxs
eth2
eth2
eth2
eth2
sixxs
Listing 6.3: Routingtabelle des Backbone-Router
6 Testumgebung
48
6.2 Testszenarien
6.2.1 Handoff Verhalten und simulierte Datenströme
Handoff Latenz Um die Dauer eines Handovers zu bestimmen, werden sowohl in
Richtung Correspondent Node - Mobile Node als auch in Richtung Mobile Node Correspondent Node ICMPv6 Echo Requests gesendet. Dazu wird der ping6 Befehl
verwendet, das Intervall zwischen zwei ICMPv6 Requests entspricht dem Standardwert
von einer Sekunde.
Als Handoff wird die Zeit zwischen dem letzten ICMPv6 Echo Reply und dem Binding
Acknowledgement des Home Agent respektive Correspondent Node definiert.
Der Wechsel zwischen den Subnetzen wird automatisiert durchgeführt, dass dazu verwendete Script zeigt Listing 6.4.
1
2
3
4
5
6
7
8
9
10
11
#!/ bin / bash
# N Wechsel zwischen
N =1
while [ $N - le 10];
sleep 10
iwconfig eth1 essid
sleep 10
iwconfig eth1 essid
N = $ [ $N +1]
done
# EOF
APs alle 10 s
do
" AP1 "
" AP2 "
Listing 6.4: Script zum Wechseln der Subnetze alle 10s
Der Wechsel zwischen den Subnetzen wird dabei alle 2s, 5s und 10s durchgeführt,
um die Leistungsfähigkeit hinsichtlich der Geschwindigkeit zu testen.
Zusätzlich wird der Test mit unterschiedlichen Intervallen der Router Advertisements
durchlaufen. Die dafür gewählten Werte unterscheiden sich um den Faktor 10 und
belaufen sich auf:
• MinAdvInterval: 0,03s bzw. 0,3s
• MaxAdvInterval: 0,1s bzw. 1s
Zu erwarten wäre eine entsprechende Änderung der Latenz um einen ähnlichen hohen
Faktor.
Handoff Paket Verlust Die Bestimmung des Paketverlustes erfolgt ebenfalls über
die ICMPv6 Echo Request / Reply Nachrichten. Dabei zählt jedes Paket als Verlust,
welches während der Handoffdauer nicht gesendet bzw. empfangen werden kann. Da
6 Testumgebung
49
der Test im Verbund mit der Messung der Handoff Latenz durchgeführt wird, gelten
die selben Randbedingungen wie im vorhergehenden Abschnitt.
Auf der Seite des Mobile Nodes sind höhere Verlustraten im Downlink zu erwarten.
Begründet liegt dies in der Dauer des Registrierungsprozesses mit dem Correspondent
Node für die Routen Optimierung, da sie sich negativ auf die erfolgreiche Paketvermittlung auswirkt.
TCP/UDP Datenstrom Neben der Messung der Latenz zwischen letztem ICMPv6
Request und erhaltenem Binding Acknowledgement, soll die Verzögerung für die Fortsetzung von Datenströmen ermittelt werden. Dazu werden jeweils ein TCP und UDP
Datenstrom über ein Simulationstool künstlich erzeugt. Dabei sollen die Datenströme
eine konstante Paketrate über die Messung besitzen.
Der Fremdnetzwechsel wird wieder unter Verwendung des in Listing 6.4 gezeigten
Scripts durchgeführt.
Zu erwarten sind hier niedrigere Verzögerungen bei UDP Verkehr, da der Dienst verbindungslos und nicht zuverlässig modelliert ist. Dadurch wird die Übertragung nur
von der Dauer des Handoffs beeinträchtigt. Ohne zusätzliche Mechanismen gehen allerdings alle Pakete, die während des Handovers gesendet werden, verloren.
Im Gegensatz stellt TCP eine zuverlässige Übertragung bereit, es sind dadurch höhere Latenzen zu erwarten. Ursache sind Wartezeiten für Acknowledgements sowie die
Fluss- und Staukontrolle, die durch Paketverluste während der Handover negativ in
Erscheinung treten wird.
6.2.2 Verhalten von Anwendungssoftware
FTP und HTTP An dieser Stelle soll das Verhalten von FTP und HTTP bei Netzwechseln betrachtet werden. Es soll überprüft werden wie FTP und HTTP durch Mobile IP beeinflusst werden, sofern überhaupt eine Wechselwirkung stattfindet.
Interessant ist hierbei vorallem der Umgang mit dem Routing Header im Hinblick
auf die korrekte Verarbeitung der Heimadresse. Erwartet wird hier, dass die Care-of
Adresse für FTP und HTTP Anwendungen unsichtbar bleibt und keine negativen Auswirkungen durch Mobile IP zu beobachten sind.
Um das Verhalten zu testen wird jeweils ein IPv6 fähgier FTP Server und ein Webserver auf dem Correspondent Node aufgesetzt. Anschließend wird ein Download bzw.
HTTP Anfragen vom Mobile Node gestartet und mehrer Handover durchlaufen. Der
Download sollte nach erfolgreichem Binding Update wieder aufgenommen und die Da-
6 Testumgebung
50
tei unbeschädigt übertragen werden.
HTTP Anfragen / Antworten die in den Handoff fallen, sollten entsprechend nach
erfolgreichem Verbindungsaufbau neu gesendet werden.
Voice over IP (VoIP) Mit diesem Test soll untersucht werden, ob Sprachkommunikation mittels ’Voice over IP’ während des Bewegungsszenarios möglich ist. Dazu muss
IPv6-fähige VoIP Software installiert und eine Sprachverbindung aufgebaut werden.
Da VoIP auf UDP basiert ist allerdings zu erwarten, dass durch die Handover hohe
Paketverluste auftreten und damit eine akzeptable Sprachverbindung zu bezweifeln ist.
51
7.1 Handoff Verhalten und simulierte Datenströme
Handoff Latenz
Das Messen der Handofflatenz, wurde mittels eines einfachen ICMPv6 Echo Request
realisiert. Der Handoff wurde zwischen zwei Fremdnetzen und dem Wechsel vom Heimnetz ins Fremdnetz betrachtet. Da Aufgrund des Aufbaues des Testbeds ein Heimnetzwechsel nur manuell durch Interfacewechsel möglich ist, wurde der Heimnetzhandoff
in der Auswertung nicht berücksichtigt. Bei der Durchführung der Messungen wurde
durch ein Script der Handoff automatisiert. Die Zeiten zwischen den Wechseln betrugen dabei 10, 5 und 2 Sekunden. Dabei stellte sich heraus, dass ein kompletter Handoff
durchschnittlich 6448 Millisekunden dauerte, sodass die Wechsel unter 10 Sekunden
für korrekte Messungen unbrauchbar waren.
Als Messpunkte für das bestimmen der einzelnen Handoffs, wurde der Empfang des
letzten ICMPv6 Reply vor dem Handoff als Startwert genommen. Die Endpunkte waren die jeweiligen Binding Acknowledgements des Mobile Nodes bzw. des Correspondent Node. Abbildung 7.1 zeigt die durchschnittlichen Handofflatenzen zwischen zwei
Fremdnetzen. Dabei wurden die ICMPv6 Nachrichten einmal über den Correspondent
Node an den Mobile Node geschickt und im zweiten Durchlauf in umgedrehte Richtung gesendet. Bei den Messungen fiel auf, dass die Handoffs zwischen Mobile Node
und Correspondent Node fast fünfmal so lange dauerten, wie die Handoffs zwischen
dem Mobile Node und dem Home Agent. Dieses ausbremsen“ beruht auf einem enor”
men Registrierungsprozess zwischen CN und HA. Da verschiedene Test Nachrichten,
Home-Test Mitteilung und Care-of Test Mitteilungen, vor dem Binding Acknowledgement gesendet werden müssen. Ein Versuch den Handoff zu manipulieren sollte durch
verringern der Zeitspanne zwischen den Routeradvertisements getestet werden. Dabei
wurde die Zeitspanne von 0.3 auf 0.03 Sekunden hinabgesetzt. Dies sollte die Handofflatenzen zwischen MN und HA um 270 Millisekunden verringern. Jedoch wider
erwarten, veränderten sich die Zeiten unmerklich. Grund hierfür ist, dass die Adver-
52
tisements zwar früher beim Mobile Node eintreffen aber die Binding Updates durch
UMIP nicht schneller versendet werden.
Obwohl die Wechsel vom Heimnetz ins Fremdnetz für die Messung der Latenzen nicht
hilfreich waren, sind die Ergebnisse dieser Messung, der Vollständigkeit halber, in der
Abbildung 7.2 dargestellt. Auffällig ist hierbei der schnelle Handoff zwischen CN und
HA wenn der Mobile Node das Heimnetz betritt. Dies ist in der Abbildung 7.2 an allen
ungeraden Handoffs zu erkennen. Grund für den schnelleren Handoff ist das wegfallen
der Testmitteilungen. Dies hat zur Folge das der Handoff von CN und HA unter 4
Millisekunden absinkt und somit schneller als im Wechsel zwischen zwei Fremdnetzen
erfolgt.
Abbildung 7.1: Durchschnittliche Handofflatenzen beim Wechel zwischen zwei
Fremdnetzwerken
Handoff Paket Verlust
Der Handoff Paket Verlust wurde ebenfalls mit dem ICMPv6 Echo Request Signal
durchgeführt. Dabei wurde jedes Paket welches zwischen dem Handoff nicht empfangen
oder durch ein ICMPv6 Reply bestätigt wurde, bei der Messung als Verlust gewertet.
Der Handoff wurde ebenfalls wie im Abschnitt Handoff Latenz“ von letzten ICMPv6
”
Reply bis zum jeweiligen Binding Acknowledgement gemessen. Auch hier wurde das
53
Abbildung 7.2: Handoffs zwischen Heimnetz und Fremdnetz
Senden von Pings“ in beide Richtungen durchgeführt. Ebenfalls wurden das verändern
”
der Router Advertisementzeiten auf den Paketverlust getestet.
Die Messergebnisse in Abbildung 7.3 zeigen beim Senden des Echo Requests vom Mobile Node an den Correspondent Node sehr niedrige Verluste, einhergehend mit einer
hohen Standardabweichung. Dieses Phänomen erklärt sich indem man sich das Senden
des Pings“ durch den MN betrachtet. Während des Handoffs zum Access Point 1 setzt
”
das Senden von ICMPv6 Mitteilungen durch den MN aus. Fehlermeldung wie Ope”
ration not permitted“ erschienen anstelle eines Pings“. Dieser Fehler wird vermutlich
”
durch den Quellcode des MIP6 Daemons erzeugt und ist in der Nautilus Community
bereits häufiger aufgetreten. Die Router Advertisements verändern die Paketverluste
nicht, da wie zu erwarten war, die Handoffzeiten durch andere Test- und Bindingnachrichten ausschlaggebender sind.
Abbildung 7.3: Paketverluste beim Wechseln zwischen zwei Fremdnetzen mit unterschiedlichen Routeradvertisementzeiten
54
UDP Latenzen
Der UDP Datenstrom wurde mit dem Streaming Tool D-ITG der Universität Napoli
[Univ09] generiert. Das Tool generierte jede Millisekunde ein 512 Byte großes UDP
Paket und schickt es vom Correspondent Node an den Mobile Node. So ist es möglich
Internettraffic, wie er zum Beispiel bei VoIP entsteht, zu simulieren.
Das Senden der UDP Pakete geschah vom Correspondent Node zum Mobile Node
und wurde mit einem Script für den Handoff gesteuert, sodass die ganze Messung
automatisiert werden konnte. Als Messpunkte dienten das letzte empfangene UDP
Paket bis zum ersten UDP Paket nach dem Handoff. Bei den Messungen wie sie in
Abbildung 7.4 dargestellt sind, wurde mit und ohne Route Optimization getestet.
Durch die kurzen Wege, von nur zwei Sprüngen eines Paketes zu seinem Ziel, stellte
sich die Deaktivierung der Routen Optimierung als das schnellere Verfahren heraus.
Im Vergleich zu Routen optimiertem Mobile IP, bei dem der durchschnittliche Handoff
6800 Millisekunden betrug, war das nicht optimierte Routen über den Home Agent mit
1670 Millisekunden 4 mal schneller. Dies ist jedoch nur der Fall bei sehr kurzen Routen
wie in unserem aufgebauten Testbed. Im Alltag würde dieser Vorteil aufgrund der
Komplexität moderner Netzwerke hinfällig werden und sich sogar Nachteilig auswirken.
Aufgrund der hohen Latenzzeiten ist das betreiben des zeitkritischen Internetdienst
VoIP unter Mobile IP nicht möglich. Aufgrund der durschnittlichen Latenzen, ist der
Paketverlust bei einem normalen Handoff mit durchschnittlich 7 Paketen anzurechnen.
TCP Latenzen
Der TCP Datenstrom wurden ebenfalls mit D-ITG Tool der Napoli Universität durchgeführt. Dabei wurden eine Paketgröße von 1180 Byte gewählt. Auch hier wurden
wieder zwischen dem letzten empfangen TCP Paket und dem erst Paket nach dem
Handoff gemessen. Die Paketrate betrug 2 Pakete pro Sekunde.
Bei den Messungen stellte sich heraus das die Latenzen 4 Sekunden länger waren, als
beim normalen Echo Request. Ein Grund dafür ist sicherlich die Fluss- und Staukontrolle in TCP. Wurde die Route Optimization jedoch ausgeschaltet und alle Pakete
über den Home Agent geleitet, führt der erweiterte Header zu einer Too BIG“ Ant”
wort des Home Agent an den Correspondent Node. Die Paketzerlegung ist somit in
der nicht Routen optimierten Weiterleitung nicht gegeben. Bei einer durchschnittlichen
Latenz von 10453 ms liegt der Paketverlust bei durchschnittlich 20 Paketen, die nach
dem Handoff neu gesendet werden müssen.
55
Abbildung 7.4: UDP Latenzen mit und ohne Route Optimization
Abbildung 7.5: TCP Handoff Latenzen
56
Abbildung 7.6: Darstellung der unterschiedlichen Latenzen der einzelnen Protokolle
7.2 Verhalten von Anwendungssoftware
FTP Download
Zum testen des Verhaltens eines FTP-Servers unter Mobile IP, wurde das Programm
PureFTP verwendet. Dieser Server arbeitet mit allen gängigen Linux und BSD Distributionen zusammen. PureFTP ist ein sehr anpassungsfähiger Server. Diese Anpassungsfähigkeit erlaubt es dem Server auch das IPv6 Protokoll zu unterstützen. Neben
dem FTP-Daemon welcher den FTP-Server startet, wurde zusätzlich eine graphische
GUI mit dem Namen Pureadmin“ installiert. Diese Oberfläche erlaubt eine schnellere
”
und einfachere Wartung des Servers. Alle benötigten Pakete sind in der Gentoo Portage
enthalten und sind mit dem emerge“ Befehl auf dem Correspondent Node installiert
”
worden.
1
2
3
# - emerge pureftpd
# - emerge pureadmin
# - pureadmin
Listing 7.1: Befehle zum installieren und starten des PureFTP Servers
Nach der Installation befand sich im /home“ Verzeichnis ein FTP“ Ordner. In ihm
”
”
wurde ein 139 MB großes ISO-Image einer Kernel-CD hinterlegt. Sie diente als Traffic
für den FTP-Server und wurde während der Messung vom Mobile Node heruntergela-
57
den. Abbildung 7.7 zeigt die Ergebnisse der Messungen. Die Latenzen sind im Vergleich
zu den zuvor gemachten Handoffs mittels des Ping6“ Befehls wesentlich länger. Wäh”
rend des Handoffs unterbrach der FTP-Server den Datentransfer und führte ihn danach
ohne Probleme fort. Nach Abschluss der Messung war die Kernel-CD vollständig auf
dem Mobile Node und enthielt keine Fehler.
Abbildung 7.7: FTP Latenzen beim Handoff
Webserver
Das Verhalten eines Webserver mit Mobile IP wurde mit dem Programm Lighttp getestet. Es handelt sich um einen kleinen und einfach zu konfigurierenden Webserver. Er ist
in der Gentoo Portage enthalten und kann mittels des emerge“ Befehls in das System
”
integriert werden. Die Konfiguration erfolgt über die Datei lighttp.conf“ im Verzeich”
nis /etc/lighttp/lighttp.conf“. Es wurde mit einer minimalen Konfigurationsdatei ge”
arbeitet, die schnell und einfach einen Webserver realisiert. In der Konfigurationsdatei
wurde neben der IPv6 Adresse, Port und Stammverzeichnis auch das Quellverzeichnis
der Webseite angegeben. Der genaue Inhalt der Config-Datei ist im Listing 7.2 dargestellt. Für den Traffic wurde eine Webseite erstellt. Der Inhalt bestand aus vier 3.5 MB
großen Bildern, über 70000 Zeilen Text und einigen Hyperlinks. Beim herunterladen
der Webseite während eines Handoffs, verhielt sich der Webserver genau wie der FTP-
58
Server - der Aufbau wurde während des Netzwechsel gestoppt und danach fortgesetzt.
Aufgrund der Verwendung von TCP Paketen unter HTTP können nicht empfangene
Pakete einfach erneut gesendet werden. Dies hat zur Folge das keine Datenverluste auftreten. Dieser Aspekt bestätigte sich, da sogar nach mehreren Netzwechseln während
eines Ladevorgangs die Webseite Fehlerfrei aufgebaut wurde.
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
var . basedir = "/ var / www / localhost "
var . logdir
= "/ var / log / lighttpd "
var . statedir = "/ var / lib / lighttpd "
server . document - root = "/ var / www /"
server . use - ipv6 = " enable "
server . port = 3000
$SERVER [" socket "] == "[2001:1 af8 : fe85 :1000::20]:80" {
server . document - root = "/ var / www /" }
mimetype . assign = (
". html " = > " text / html " ,
". txt " = > " text / plain " ,
". jpg " = > " image / jpeg " ,
". png " = > " image / png "
)
Listing 7.2: Serverkonfigurationsdatei des Lighttp Webservers
VoIP
Das Testszenario Voice over IP konnte leider im Rahmen unseres Medienprojektes nicht
getestet werden. Grund hierfür war das fehlen einer IPv6 Unterstützung in den gängigen VoIP Clienten. Es wurden die Clienten KPhone 4.2-r1, Ekiga 3.2.6 und twinkle1.4.2 getestet. Es war zwar möglich unter IPv4 eine IP to IP Kommunikation mittels
Ekiga herzustellen, jedoch scheitert dies bei IPv6. Auch die Anmeldung an einen SIPServer war nur über IPv4 möglich. Dies liegt daran das die derzeitigen SIP-Server der
einzelnen Anwendungen nur das IPv4 Protokoll unterstützen.
8 Zusammenfassung
59
8 Zusammenfassung
8.1 Ergebnisse
Mit diesem Medienprojekt ist es gelungen eine Testumgebung für Mobile IPv6 funktionsfähig aufzubauen. Durch verschiedene Testszenarien und Anwendungsbezogene
Kompatibilitätsprüfungen, war es möglich das Verhalten von Mobile IPv6 zu überprüfen. Dabei kristallisierte sich schnell heraus, dass die Handofflatenzen für zeitkritische
Anwendungen, wie zum Beispiel Streaming Dienste, zu hoch sind und dadurch die Anwendungenen schwer beeinträchtigt wären.
Ferner zeigten die Tests auch, dass sich nicht zeitkritische Anwendung von Mobile IPv6
in ihrer Stabilität und Funktionsfähigkeit nicht beeinflussen lassen.
Ein weiterer Aspekt den diese Arbeit darstellt, sind die theoretischen Lösungsansätze
von Multicastimplementierungen in Mobile IP. Aufgrund der nicht vorhandenen praktischen Umsetzung, zu diesem Zeitpunkt, ist das Testen dieser Ansätze ein Ziel für
spätere Arbeiten.
8.2 Ausblick
Die Verbreitung von Mobile IP ist zu diesem Zeitpunkt noch sehr spärlich. Jedoch ist
diese langsame Verbreitung kein Scheitern der Idee von Mobilität über Internetprotokoll. Viel mehr ist die geringe Nachfrage auf die Durchsetzung von IPv6 im Internet zu
beziehen. Dies wird sich jedoch ändern, da die Umstellung immer mehr vorangetrieben
wird. So ist besonders das verbessern der Latenzen, durch schnellere Handoffverfahren
ein interessanter Aspekt, der in Zukunft die Leistungsfähigkeit von Mobile IP erhöhen
wird. Lösungsansatz ist hier zum Beispiel die Mobile IP Fast Authentification. Eine
Interessante Möglichkeit auch zeitkritische Anwendungen über Mobile IP zu betreiben.
Auch die Sicherheit in Mobile IP ist für großen Netzwerke besonders wichtig. Da zur
Zeit in der UMIP Implementierung keine Kryptographien oder Sicherheitszertifika-
8 Zusammenfassung
60
te vorhanden sind, stellen diese Lücken eine weitere Baustelle für spätere Versionen
dieser Implementierung da. Ebenfalls erlaubt der offene Quellcode von UMIP Verbesserungen. So ist die Stabilität immer noch ein Problem und könnten durch Patches
oder zusätzliche Erweiterungen behoben werden.
61
Anhang
A Messungen
62
A Messungen
Abbildung A.1: TCP Datenstrom Messungen - Correspondent Node sendet an Mobile
Node
A Messungen
63
Abbildung A.2: UDP Datenstrom - Correspondent Node sendet an das Mobile Node
A Messungen
64
Abbildung A.3: Fremdnetz ins Fremdnetz - Correspondent Node sendet ICMPv6 Pakete an Mobile Node mit Router Advertisements von 0,3 Sekunden
A Messungen
65
Abbildung A.4: Fremdnetz ins Fremdnetz - Correspondent Node sendet ICMPv6 Pakete an Mobile Node mit Router Advertisements von 0,03 Sekunden
A Messungen
66
Abbildung A.5: Fremdnetz ins Fremdnetz - Mobile Node sendet ICMPv6 Pakete an
Correspondent Node mit Router Advertisements 0,3 Sekunden
A Messungen
67
Abbildung A.6: Fremdnetz ins Fremdnetz - Mobile Node sendet ICMPv6 Pakete an
Correspondent Node mit Router Advertisements von 0,03 Sekunden
A Messungen
68
Abbildung A.7: Heimnetz ins Fremdnetz - Correspondent Node sendet ICMPv6 Paket
an das Mobile Node
Abbildung A.8: FTP Datenstrom - Correspondent Node sendet an das Mobile Node
69
[6NET05]
The
6NET
Consortium,
http://www.6net.org/book/
deployment-guide.pdf.
An IPv6 Deployment Guide, September
2005.
[ArDD04]
J. Arkko, V. Devarapalli und F. Dupont. Using IPsec to Protect Mobile IPv6 Signaling Between Mobile Nodes and Home Agents. RFC 3776,
http://tools.ietf.org/html/rfc3776, Juni 2004.
[Bärw10]
S. Bärwolf. Aufbau eines IPv6-basierten Testbeds zur Implementierung des Mobilitätsmanagementprotokolls MIFAv6. Diplomarbeit, TU
Ilmenau, Januar 2010.
[CDKF+ 02] B. Cain, S. Deering, I. Kouvelas, B. Fenner und A. Thyagarajan. Internet
Group Management Protocol, Version 3. RFC 3376, http://tools.ietf.
org/html/rfc3376, October 2002.
[ChCh03]
Hyun-Ho Choi und Dong-Ho Cho. Mobility Management Based on Mobile
IP in Mixed IPv4/IPv6 Networks. IEEE, 2003, S. 2048–2052.
[ChNo06]
S. Chakrabarti und E. Nordmark. Extension to Sockets API for Mobile
IPv6. RFC 4584, http://tools.ietf.org/html/rfc4584, 2006.
[Corp04]
Microsoft Corporation. Understanding Mobile IPv6, April 2004. Updated
Januar 2007.
[Corp06]
Microsoft Corporation.
TCP/IP-Grundlagen für Microsoft Windows - Anhang A: IP-Multicast.
Technischer Bericht, Microsoft,
http://www.microsoft.com/germany/technet/itsolutions/
network/evaluate/technol/tcpipfund/tcpipfund_appa.mspx, März
2006. [Online Check 08.02.2010 21:25 Uhr].
[Deer89]
S. Deering. Host Extensions for IP Multicasting. RFC 1112, http://
tools.ietf.org/html/rfc1112, August 1989.
70
[DeFH99]
S. Deering, W. Fenner und B. Haberman. Multicast Listener Discovery
(MLD) for IPv6. RFC 2710, http://tools.ietf.org/html/rfc2710,
October 1999.
[DeHi98]
S. Deering und R. Hinden. Internet Protocol, Version 6 (IPv6) Specification. RFC 2460, http://tools.ietf.org/html/rfc2460, Dezember
1998.
[Deng08]
H. Deng. Multicast tunneling optimization for Mobile IPv4. Internet Draft,
December 2008.
[DeWP05]
V. Devarapalli, R. Wakikawa und A. Petrescu. Network Mobility (NEMO) Basic Support Protocol. RFC 3963, http://tools.ietf.org/html/
rfc3963, Januar 2005.
[FeSe00]
P. Ferguson und D. Senie. Network Ingress Filtering: Defeating Denial
of Service Attacks which employ IP Source Address Spoofing. RFC 2827,
http://tools.ietf.org/html/rfc2827, Mai 2000.
[GiNH93]
R. Gilligan, E. Nordmark und B. Hinden. IPAE: The SIPP Interoperability
and Transition Mechanism. Internet Draft, http://tools.ietf.org/
html/draft-ietf-sip-ipae-transition-00, November 1993.
[Gren03]
Lars Grenzdörfer. Untersuchung existierender Implementierungen von
Mobile IP. Studienarbeit, Technische Universität Ilmenau Fakultät Elektrotechnik und Informationstechnik, Februar 2003. Fachgebiet Kommunikationsnetze.
[GuSh09]
R. Gunasundari und S. Shanmugavel. Performance Comparison of Mobile
IPv4 and Mobile IPv6 Protocols in Wireless Systems. IEEE COMSNETS
2009, 2009.
[HiDe06]
R. Hinden und S. Deering. IP Version 6 Addressing Architecture. RFC
4291, http://tools.ietf.org/html/rfc4291, Februar 2006.
[JANE09]
JANET (UK), http://www.ja.net/development/network-access/
mobile-ip/. Lancaster Mobile IP, 2009.
[JoPA04]
D. Johnson, C. Perkins und J. Arkko. Mobility Support for IPv6. RFC
3775, http://tools.ietf.org/html/rfc3775, Juni 2004.
71
[Kunt09]
Romain Kuntz. nautilus6 Projekt.
nautilus6.org, 2009.
Nautilus6 Working Group, www.
[Ligh10]
Lighttp Projekt, http://www.lighttpd.net/. Lighttp, Februar 2010.
[NNSS07]
T. Narten, E. Nordmark, W. Simpson und H. Soliman. Neighbor Discovery for IP Version 6 (IPv6). RFC 4861, http://tools.ietf.org/html/
rfc4861, September 2007.
[Perk98]
Charles E. Perkins. Mobile IPv6 - Design Principles and Practices. Addison-Wesley Wireless Communications Series. Addison-Wesley.
2. Auflage, 1998.
[Perk02]
C. Perkins. Mobility Support for IPv4. RFC 3344, http://tools.ietf.
org/html/rfc3344, August 2002.
[Rodr97]
Manuel Rodriguez. HP Mobile IP. Hewlett-Packard, http://www.
hpl.hp.com/personal/Jean_Tourrilhes/MobileIP/index.html, August 1997.
[STNJ03]
W. Stevens, M. Thomas, E. Nordmark und T. Jinmei. Advanced Sockets
Application Program Interface (API) for IPv6. RFC 3542, http://tools.
ietf.org/html/rfc3542, Mai 2003.
[ThNJ07]
S. Thomson, T. Narten und T. Jinmei. IPv6 Stateless Address Autoconfiguration. RFC 4862, http://tools.ietf.org/html/rfc4862, September 2007.
[TU H06]
TU Helsinki, http://web.archive.org/web/20070929071348/http://
www.mobile-ipv6.org/. www.mobile-ipv6.org, März 2006. Webseite nur
noch über http://web.archive.org erreichbar.
[Univ07]
Universität Bremen, http://www.mobileip.org. Mobileip.org, November
2007.
[Univ09]
Universita’ degli Studi di Napoli ”Federico II”, http://www.hpl.hp.com/
personal/Jean_Tourrilhes/MobileIP/index.html. Distributed Internet Traffic Generator, 2009.
[Vogt06]
C. Vogt. A Comprehensive and Efficient Handoff Procedure for IPv6
Mobility Support. IEEE International Symposium WoWMoM, 2006.
72
[WIDE09]
WIDE organization, http://www.nautilus6.org/implementation/
index.php. Nautilus Project für Mobil IPv6, Februar 2009.
[XiNa09]
Jiang Xie und Uday Narayanan. Performance Analysis of Mobility Support in IPv4/IPv6 Mixed Wireless Networks. IEEE, 2009.
[YaDW09]
P. Yang, H. Deng und Q. Wu.
Multicast tunneling optimization for Mobile IPv6. Internet-Draft, http://tools.ietf.org/html/
draft-yang-multimob-mip6-mc-tunnel-opt-02, Januar 2009.
73
2.1
2.2
2.3
Aufbau einer IPv4 Adresse . . . . . . . . . . . . . . . . . . . . . . . . .
MIPv4 Topologie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
MIPv6 Topologie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.1
3.2
3.3
3.4
3.5
3.6
Blockdiagramm Handoff Prozess . . .
Beispiel für ein Router Advertisement
Aufbau Mobility Header . . . . . . .
Binding Update an Home Agent . . .
Binding Acknowledgement vom CN .
Return Routability Procedure . . . .
.
.
.
.
.
.
.
.
.
.
.
.
11
13
15
17
18
19
4.1
4.2
4.3
4.4
4.5
4.6
4.7
Übersicht von IPv4 Multicast . . . . . . . . . . . . . . . . . . . . . .
Abbildung einer Multicast IPv4 Adresse auf eine Pseudo Mac-Adresse
Einkapselung von IGMP Mittelungen in ein IP-Datagramm . . . . . .
Aufbau einer MLD Nachricht . . . . . . . . . . . . . . . . . . . . . .
Aufbau der MPEF . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Ablauf des Bidirectional Tunnelings in IPv6 . . . . . . . . . . . . . .
Ablaufdiagramm eines optimierten Tunnels mittels eines MMA . . . .
.
.
.
.
.
.
.
22
22
23
24
25
28
29
5.1
Datenformat eines IPv6 Router Advertisments . . . . . . . . . . . . . .
39
6.1
MIPv6 Testaufbau . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
45
7.1
Durchschnittliche Handofflatenzen beim Wechel zwischen zwei Fremdnetzwerken . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Handoffs zwischen Heimnetz und Fremdnetz . . . . . . . . . . . . . . .
Paketverluste beim Wechseln zwischen zwei Fremdnetzen mit unterschiedlichen Routeradvertisementzeiten . . . . . . . . . . . . . . . . . .
UDP Latenzen mit und ohne Route Optimization . . . . . . . . . . . .
TCP Handoff Latenzen . . . . . . . . . . . . . . . . . . . . . . . . . . .
Darstellung der unterschiedlichen Latenzen der einzelnen Protokolle . .
7.2
7.3
7.4
7.5
7.6
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
3
6
7
52
53
53
55
55
56
7.7
74
FTP Latenzen beim Handoff . . . . . . . . . . . . . . . . . . . . . . . .
A.1 TCP Datenstrom Messungen - Correspondent Node sendet an Mobile
Node . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
A.2 UDP Datenstrom - Correspondent Node sendet an das Mobile Node . .
A.3 Fremdnetz ins Fremdnetz - Correspondent Node sendet ICMPv6 Pakete
an Mobile Node mit Router Advertisements von 0,3 Sekunden . . . . .
A.4 Fremdnetz ins Fremdnetz - Correspondent Node sendet ICMPv6 Pakete
an Mobile Node mit Router Advertisements von 0,03 Sekunden . . . .
A.5 Fremdnetz ins Fremdnetz - Mobile Node sendet ICMPv6 Pakete an Correspondent Node mit Router Advertisements 0,3 Sekunden . . . . . . .
A.6 Fremdnetz ins Fremdnetz - Mobile Node sendet ICMPv6 Pakete an Correspondent Node mit Router Advertisements von 0,03 Sekunden . . . .
A.7 Heimnetz ins Fremdnetz - Correspondent Node sendet ICMPv6 Paket
an das Mobile Node . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
A.8 FTP Datenstrom - Correspondent Node sendet an das Mobile Node . .
57
62
63
64
65
66
67
68
68
75
Listingverzeichnis
3.1
3.2
Inhalt der CoT und HoT Init Nachrichten [JoPA04] . . . . . . . . . . .
Inhalt der CoT und HoT Nachrichten [JoPA04] . . . . . . . . . . . . .
19
20
5.1
5.2
5.3
5.4
5.5
5.6
5.7
5.8
5.9
5.10
5.11
5.12
Kernel Konfiguration . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Befehle für das Installerien von Umip-0.4 Daemons . . . . . . . . . . .
mip6d.conf für den Home Agent . . . . . . . . . . . . . . . . . . . . . .
mip6d.conf für das Mobile Node . . . . . . . . . . . . . . . . . . . . . .
mip6d.conf für das Corespondent Node . . . . . . . . . . . . . . . . . .
radvd.conf für den Home Agent . . . . . . . . . . . . . . . . . . . . . .
mip6d.conf für den Foreign Access Point 1 . . . . . . . . . . . . . . . .
mip6d.conf für den Foreign Access Point 2 . . . . . . . . . . . . . . . .
Befehle zum starten Radvd Daemons in den Access Points . . . . . . .
Startbefehle für die UMIP Implementierung beim Mobile Node . . . . .
Startbefehle für die UMIP Implementierung und Radvd beim Home Agent
Startbefehle für die UMIP Implementierung beim Correspondent Node
34
35
37
38
38
40
41
41
42
42
43
43
6.1
6.2
6.3
6.4
hostapd Konfiguration für AR1 . . . . . .
Einstellen des IP Forwarding . . . . . . . .
Routingtabelle des Backbone-Router . . .
Script zum Wechseln der Subnetze alle 10s
.
.
.
.
46
46
47
48
7.1
7.2
Befehle zum installieren und starten des PureFTP Servers . . . . . . .
Serverkonfigurationsdatei des Lighttp Webservers . . . . . . . . . . . .
56
58
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
Tabellenverzeichnis
76
Tabellenverzeichnis
5.1
5.2
Verfügbare Mobile IPv6 Implementierungen . . . . . . . . . . . . . . .
Verfügbare Mobile IPv4 Implementierungen . . . . . . . . . . . . . . .
32
33
77
AR . . . . . . . . . . . . . . . . .
ARP . . . . . . . . . . . . . . .
CN . . . . . . . . . . . . . . . . .
CoA . . . . . . . . . . . . . . . .
CoT . . . . . . . . . . . . . . . .
FA . . . . . . . . . . . . . . . . .
FTP . . . . . . . . . . . . . . .
HA . . . . . . . . . . . . . . . . .
HoA . . . . . . . . . . . . . . .
HoT . . . . . . . . . . . . . . . .
HTTP . . . . . . . . . . . . .
IANA . . . . . . . . . . . . . .
ICMP . . . . . . . . . . . . . .
ICMPv4 . . . . . . . . . . . .
ICMPv6 . . . . . . . . . . . .
IETF . . . . . . . . . . . . . . .
IGMP . . . . . . . . . . . . . .
IP . . . . . . . . . . . . . . . . . .
ISO/OSI . . . . . . . . . . .
MAC . . . . . . . . . . . . . . .
MFA . . . . . . . . . . . . . . .
MIPv4 . . . . . . . . . . . . .
MIPv6 . . . . . . . . . . . . .
MLD . . . . . . . . . . . . . . .
MLR . . . . . . . . . . . . . . .
MMA . . . . . . . . . . . . . .
MN . . . . . . . . . . . . . . . .
MPE . . . . . . . . . . . . . . .
Access Router
Adress Resolution Protokoll
Correspondent Node
Care-of Address
Care-of Test
Foreign Agent
File Transfer Protocol
Home Agent
Home Address
Home Test
Hyper Text Transfer Protocol
Internet Assigned Numbers Authority
Internet Controll Message Protokoll
Internet Controll Message Protokoll version 4
Internet Controll Message Protokoll version 6
Internet Engineering Task Force
Internet Group Message Protokoll
Internet Protokoll
International Organization for Standardization / Open System
Interconnection Reference Model
Media Access Controll Adresse
Multicast Foreign Agent
Mobile Internet Protocol version 4
Mobile Internet Protocol version 6
Multicast Listener Detection
Multicast Listener Report
Multicast Membership Agent
Mobile Node
Multicast Preference Extension
78
MST . . . . . . . . . . . . . . .
MTU . . . . . . . . . . . . . . .
NEPL . . . . . . . . . . . . . .
RA . . . . . . . . . . . . . . . . .
RFC . . . . . . . . . . . . . . .
TCP . . . . . . . . . . . . . . .
TTL . . . . . . . . . . . . . . .
UDP . . . . . . . . . . . . . . .
UMIP . . . . . . . . . . . . . .
Multicast Service Tabelle
Maximum Transmission Unit
NEmo Platform for Linux
Router Advertisements
Requests For Comments
Transmission Control Protocol
Time To Life
User Datagram Protocol
UniverSAl playGround for IPv6 (USAGI)-patched MIPv6 for
Linux
VoIP . . . . . . . . . . . . . . . Voice over Internet Protocol
Erklärung
79
Erklärung
Die vorliegende Arbeit ist eine Kollektivarbeit. Von Herrn Christoffer Cruse wurden
folgende Abschnitte bearbeitet:
• 1. Einleitung
• 2. Mobile IP
• 3. Funktionsabläufe in Mobile IPv6
• 6. Testumgebung
Von Herrn Marko Wilde wurden die Abschnitte
• 4. Mulitcast in Mobile IP
• 5. Mobile IP Implementierungen
• 7. Auswertung der Testszenarien
• 8. Zusammenfassung
bearbeitet.
Wir erklären, dass wir diese Arbeit selbständig durchgeführt und abgefasst haben.
Quellen, Literatur und Hilfsmittel, die von uns benutzt wurden, sind als solche gekennzeichnet.
Ilmenau, den 28. 02. 2010
Christoffer Cruse, Marko Wilde

Technische Universität Ilmenau Fakultät für Elektrotechnik und

Transcription

Similar documents

INFINITY - Manual PAC [DE

- gds document systems gmbh

Volltext - Qucosa

Zusammenfassung - auf ThomasKaelin.ch

Studienarbeit Implementierung einer IP-Multicast