Gratis online lesen
Inhaltsverzeichnis
1 Einführung
2 Mobile IP
2.1 Protokollüberblick
2.1.1 foreign-agentund co-located-care-of-address
2.1.2 Agent-Discovery
2.1.3 Erkennung von Zellenwechseln
2.1.4 Registrierung
2.1.5 Authorisierung
2.1.6 Kaskadierung und mobile Router
2.2 Protokoll-Optimierungen und -Erweiterungen
2.2.1 IP-Kapselung und deren Minimierung
2.2.2 Routen-Optimierung
2.2.3 Andere Protokollerweiterungen
2.3 Implementierungen
2.3.1 Überblick
2.3.2 Dynamics HUT Mobile IP - Hierarchisches Modell
3 Andere mobile Protokolle
3.1 Transportprotokoll-Handling
3.1.1 Fast Retransmit / Fast Recovery
3.1.2 Indirect TCP
3.1.3 Snoop TCP
3.2 Zeroconf Networking
3.2.1 IP Interface Konfiguration
3.2.2 Name-To-Address Translation
3.2.3 Service Discovery
3.2.4 IP Multicast-Address Discovering
1 Einführung
Obwohl das Internet als Medium inzwischen Alltag geworden ist, sind wir gewohnt, den Zugang zum Internet nur an entsprechend ausgerüsteten, festen Plätzen nutzen zu können. Sieht man von sehr beschränkt einsatzfähigen Protokollen wie WAP ab, so hat es das nicht auf Mobilität ausgelegte Design des Internetprotokolls es bisher sehr schwer gemacht, den vollen Umfang des Internet auch mobil nutzen zu können. Wesentliche Schwierigkeiten entstehen vor allem bei der Bewegung von mobilen Endgeräten zwischen den Zellen der zugrundeliegenden Protokolle auf Bitund Datenübertragungs-Schicht (GPRS, UMTS, CDMA2000). Wechselt ein mobiler Host die Zelle, so ist es normalerweise nötig, die komplette IP-Konfiguration samt dessen Routing zu verändern. Mit der wachsenden Verbreitung dieser Netze wird die abgedeckte Fläche pro Zelle sich wesentlich verkleinern um „Löcher” zu vermeiden. Da jede dieser Zellen normalerweise mit einem assoziiertem IP-Router korrespondiert, müsste ein sich bewegender Mobiler Host (MH) seine IP-Konfiguration quasi ständig wechseln oder es müssten laufend neue Routen propagiert werden. Dies ist bei manueller Konfiguration unmöglich. Auch bei dynamischer Konfiguration beispielsweise über DHCP entstehen Probleme: Offene Verbindungen können bei Wechsel der IP Adresse nicht gehalten werden und ein ständiger Wechsel der IP-Adresse erfordert auf höheren Protokollebenen einen ständigen administrativen Aufwand. Auch können auf z.B. der Transportebene existierende Verbindungen bei Wechsel der IP-Adresse nicht gehalten werden.
Es existieren eine Reihe von Ansätzen und Ideen, welche diese Beschränkungen aufheben sollen. An erster Stelle ist hier Mobile IP - eine IP-Protokollerweiterung zu nennen. Auf Transportebene ermöglichen Protokollergänzungen wie Indirect-TCP (I- TCP) das unterbrechungsfreie Mitführen von TCP-Verbindungen über Zellengrenzen hinweg. Auf Applikationsebene unterstützen Zero Configuration Networking Protokolle das automatische Finden und Konfigurieren von lokalen Parametern wie IP-Adresse/ Subnetzmaske, Service-Discovery, etc.
Im Wesentlichen soll es hier um Mobile IP gehen. Neben den Protokollerweiterungen selbst werde ich auch einen Überblick über bereits einsatzfähige Implementationen geben. Desweiteren sollen die anderen oben genannten Ansätze kurz beleuchtet werden.
2 Mobile IP
Mobile IP wird seit Mitte der 90er Jahre von der Mobile IP Working Group entwickelt. Das primäre Ziel der Arbeitsgruppe ist, eine Erweiterung des IP-Protokolls zu standardisieren, welche ein transparentes und unterbrechungsfreies Wechseln von IP-Subnetzen ermöglichen soll. Bisher resultierten die Bemühungen der Arbeitsgruppe in RFCs zu folgenden Themenbereichen (Auszug):
RFC 2002: Unterstützung von mobilen Endgeräten für IP (Mobile IP)
RFC 2003/2004: IPIP-Kapselung
RFC 2977/3012: Authentifizierung und Authorisierung in Mobile IP
Desweiteren existieren Internet Drafts zur Portierung auf IPv6, Routenoptimierung, Fast Handovers, Security und mehr. Eine vollständige Übersicht gibt es auf der entsprechenden Website der IETF[1].
Im Folgenden werde ich einen Überblick über Mobile IP geben und beispielhaft eine noch in der Entwicklung befindliche Erweiterung (Routen-Optimierung) vorstellen.
Abbildung in dieser Leseprobe nicht enthalten
Abbildung 1: IP-IP-Tunnel
2.1 Protokollüberblick
Die existierende Infrastruktur des Internets macht es unmöglich, Protokollveränderungen auf allen am Netz beteiligten Rechnern durchzuführen. Deshalb wurde Mobile IP so konstruiert, daß keine Eingriffe in die Protokollstacks nicht beteiligter Rechner notwendig sind. „Nicht beteiligt” heißt hier: alle Hosts, welche nicht Teil der Infrastruktur für das IP-Routing mobiler Geräte sind. Desweiteren soll ein mobiler Host immer adressierbar sein, d.h. eine feste IP-Adresse behalten.
Die grundsätzliche Idee ist, mobilen Hosts (MH) eine feste IP Adresse in seinem Heimnetzwerk zuzuordnen, welche wie üblich administriert wird. Diese IP-Adresse unterliegt nur der Beschränkung, daß sie routable sein muß, d.h. sie darf nicht aus einem der drei privaten IP-Netze sein. Dies liegt daran, daß der MH diese IP als Quell- Adresse für alle (bis auf wenige Ausnahmen) Datagramme nutzt, welche von ihm ausgehen. Bewegt sich der MH außerhalb seines Heimnetzwerkes, so bekommt er von einem Foreign Agent (FA) eine zweite IP-Adresse - die Care-Of Address zugewiesen. Diese Care-Of Address wird dem Home Agent (HA) bekannt gemacht. Der HA ist der dem MH am nahegelegenste Router (in seinem Heimnetzwerk). Ist ein MH bei seinem HA mit einer Care-Of-Address registriert, so tunnelt dieser für den MH bestimmte Datagramme mit dessen Care-Of-Adress über den FA zum gegenwärtigen Aufenthaltsort des MH.
Das heißt insbesondere auch, daß die Care-Of Address auch aus einem nicht-privatem Adreßraum sein muß. Siehe hierzu auch Abbildung 1.
2.1.1 foreign-agentund co-located-care-of-address
Die Care-Of-Address definiert den Endpunkt des IPIP-Tunnels, welcher am HA beginnt: wurde ein Datagramm bis zur Care-Cf-Address befördert, so wird dort der Rahmen des IP-Tunnels entfernt und das originale Paket zum Endpunkt (dem MH) transportiert. Mobile IP läßt für die Zuweisung dieser Addresse grundsätzlich zwei Möglichkeiten zu: Foreign-Agentund Co-located-Care-Of-Address. Eine Foreign-Agent- Care-Of-Address ist eine IP, welche der MH von dem FA zugewiesen bekommt. Diese
Abbildung in dieser Leseprobe nicht enthalten
Abbildung 2: Co-located-care-off-address ist eine IP des FA, welche routable ist. In dieser Betriebsart endet der IPIP-Tunnel am FA (Abbildung 1). Der Vorteil ist hier, daß kein zusätzlicher (rarer) IP-Adreßraum für MHs benötigt wird. Desweiteren fällt auf den MHs keine Rechenzeit für das entpacken des Tunnels an. Die Care-Of Address kann jedoch auch über einen völlig unabhängigen Dienst wie z.B. einem DHCP-Server zugewiesen werden. Auch ein einmalig auf dem MH konfigurierter, statischer Pool ist möglich. In diesem Fall endet der IPIP- Tunnel erst am MH und muß dort entpackt werden, weshalb dieser auch ein Interface mit dieser IP konfigurieren muß. Vorteil dieses Setups ist, daß kein FA benötigt wird, z.B. in Netzen, welche noch nicht auf Mobile IP aufgerüstet wurden. Ein Nachteil von Co-located Care-Of Adressen ist, daß zusätzlicher IP-Adreßraum benötigt wird und verwaltet werden muß.
2.1.2 Agent-Discovery
Home-Agents und Foreign-Agents (Mobile Agents) müssen ihre Verfügbarkeit für MHs sichtbar machen, damit MHs darüber informiert werden können, ob sie sich in ihrem Heim-Netzwerk oder in einem fremden Netzwerk befinden. Auch müssen etwaige Zellenwechsel erkannt werden können und der MH über seine derzeitige Care-of Address informiert werden.
Grundsätzlich könnten diese Aufgaben auch auf Link-Layer-Ebene gelöst werden, was die von Mobile-IP vorgeschlagenen Mechanismen unnötig machen würde. Mobile IP definiert Agent-Advertisingund Agent-Solicitation-Messages über Erweiterungen des ICMP Router Discovery Protokolls[2], welche mithin in einer Implementation nicht vorhanden sein müssen, wenn im konkreten Fall schon auf Link-Layer ein Router Discovery stattfindet.
Ein Mobile Agent (MA) sendet in Sekunden-Intervallen Advertisement Messages via IP-Multicast in das Subnetz für MHs aus (Abbildung 3), welche neben normalen Router-Parametern auch Moble-IP-spezifische Optionen bekanntmachen. Diese sind im Einzelnen:
Informationen darüber, ob der Router die Funkion eines Home-Agent oder eines Foreign-Agent übernehmen kann
Abbildung in dieser Leseprobe nicht enthalten
Abbildung 3: Agent Discovery
Informationen über Überlastung des Mobility Agents
Informationen darüber, ob Minimal-Kapselung unterstützt wird (siehe 2.2.1) Informationen über benötigte Registrierungen
Informationen über Default-Router
Ein Pool von Care-Of Adressen, welche von in diesem Subnetz neuen MHs benutzt werden können.
Ist ein MH an einem FA registriert, so muß er weiter auf die Advertisements horchen, um erkennen zu können, ob der aktuelle FA noch erreichbar ist. Dazu haben die Advertisement-Messages auch ein Lifetime-Feld. Empfängt ein MH nach Ablauf der Lifetime-Period keine Agent-Advertisements mehr, so wird davon ausgegangen, daß der Agent nicht mehr erreichbar ist und es wird nach einem neuen gesucht.
Ein MH ist nicht darauf beschränkt, passiv auf Router-Advertisements zu horchen, sondern kann auch aktiv welche suchen. Dies geschieht über Router-Solicitation- Messages (nach RFC 1256), welche ein MH aussendet, wenn z.Z. keine Care-Of- Address verfügbar ist. Aus etwaigen Antworten von Routern kann dann ermittelt werden, ob dieser die Funktion eines FA/HA übernehmen kann.
2.1.3 Erkennung von Zellenwechseln
Ein MH kann an RouterAdvertisements erkennen, ob er eine Zelle gewechselt hat. Empfängt ein MH nach abgelaufener Lifetime keine neuen Advertisements mehr von seinem MA, so wird davon ausgegangen, daß er die Zelle verlassen hat. Ein MH wird dann Solicitation-Messages aussenden, um einen neuen Agenten zu finden oder sich bei einem Agenten registrieren, von dem er zuvor Advertisements empfangen hat.
2.1.4 Registrierung
Bewegt sich ein MH außerhalb seines Heimnetzwerkes, so muß der Home-Agent für den MH bestimmte Datagramme mit der aktuellen Care-Of Address kapseln. Dazu
Abbildung in dieser Leseprobe nicht enthalten
Abbildung 4: Registrierung ohne Beteiligung eines Foreign Agents
muß ein MH seine aktuelle Adresse beim HA registrieren.
[...]
[1] http://www.ietf.org/html.charters/mobileip-charter.html
[2] http://www.ietf.org/rfc/rfc1256.txt