Mobile IP

sehr schwer gemacht, den vollen Umfang des Internet auch mobil nutzen zu kön- nen. Wesentliche Schwierigkeiten entstehen vor allem bei der Bewegung von mobi- len Endgeräten zwischen den Zellen der zugrundeliegenden Protokolle auf Bit- und 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 abge- deckte 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 manuel- ler 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 Protokol- le 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 Protokollerweiterun- gen selbst werde ich auch einen Überblick über bereits einsatzfähige Implementationen geben. Desweiteren sollen die anderen oben genannten Ansätze kurz beleuchtet wer- den.

2 Mobile IP

Mobile IP wird seit Mitte der 90er Jahre von der Mobile IP Working Group ent- wickelt. 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 Arbeitsgrup- pe 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 ent-

sprechenden Website der IETF 1 .

Im Folgenden werde ich einen Überblick über Mobile IP geben und beispielhaft ei- ne noch in der Entwicklung befindliche Erweiterung (Routen-Optimierung) vorstellen.

1 http://www.ietf.org/html.charters/mobileip-charter.html

2

Abbildung 1: IP-IP-Tunnel

2.1 Protokollüberblick

Die existierende Infrastruktur des Internets macht es unmöglich, Protokollveränderun- gen auf allen am Netz beteiligten Rechnern durchzuführen. Deshalb wurde Mobile IP so konstruiert, daß keine Eingriffe in die Protokollstacks nicht beteiligter Rechner not- wendig sind. „Nicht beteiligt” heißt hier: alle Hosts, welche nicht Teil der Infrastruk- tur 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 aus- gehen. 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 Da-

tagramme 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-agent- und co-located-care-of-address

Die Care-Of-Address definiert den Endpunkt des IPIP-Tunnels, welcher am HA be- ginnt: wurde ein Datagramm bis zur Care-Cf-Address befördert, so wird dort der Rah- men des IP-Tunnels entfernt und das originale Paket zum Endpunkt (dem MH) trans- portiert. Mobile IP läßt für die Zuweisung dieser Addresse grundsätzlich zwei Mög- lichkeiten zu: Foreign-Agent- und Co-located-Care-Of-Address. Eine Foreign-Agent- Care-Of-Address ist eine IP, welche der MH von dem FA zugewiesen bekommt. Diese

3

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ängi- gen 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 Zel- lenwechsel 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-Advertising- und 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 Dis- covery 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

2 http://www.ietf.org/rfc/rfc1256.txt

4

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 be-

nutzt werden können.

Ist ein MH an einem FA registriert, so muß er weiter auf die Advertisements hor- chen, 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 hor- chen, 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 wer- den, 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

5

Abbildung 4: Registrierung ohne Beteiligung eines Foreign Agents

muß ein MH seine aktuelle Adresse beim HA registrieren. Neben dieser sind für die korrekte Funktion des Setups auch noch folgende Registrierungs-Funktionen wichtig:

Erneuerung nach Ablauf der Expire-Time

  Deregistrierung bei Wiederkehr in das Heim-Netzwerk

  Verwalten von mehreren simultanen Care-Of Adressen

  Ermittelung der Adresse des HA (falls diese nicht bekannt ist)

  Anforderung des Forwardings für Broad-/Multicast-Datagrame

  Authorisierung

  Benutzt der MH eine foreign-agent-care-of address, so ist der FA direkt am Registrie- rungsprozeß beteiligt. Bei Co-located care-of Adressen kann die Registrierung jedoch auch direkt am HA erfolgen (siehe Abbildung 3 und 4). Auch hier sieht man, daß Mo- bile IP so entworfen wurde, daß man in fremden Netzwerken ohne großen Aufwand mobilen Hosts den Mobile-IP-Service zur Verfügung stellen kann. Es ist insbesondere nicht notwendig, Mobile IP spezifische Änderungen des IP-Stacks auf allen MSRs zu installieren.

Sämtliche Funktionen der Registrierung laufen über UDP (Port 434) und müssen authorisiert werden (siehe 2.1.5). In einem Registration-Request wird dem HA die der- zeitige Care-Of Adresse mitgeteilt und der HA dazu aufgefordert, für den MH be- stimmte Datagramme mit dieser Adresse zu kapseln. Auch die Registrierung hat eine Lebenszeit, welche vom MH festgesetzt wird und vom HA falls nötig verkleinert wer- den kann. Der HA kann den Request entweder ablehnen oder akzeptieren. Registriert ein MH mehrere Care-Of Adressen, so werden für den MH bestimmte Datagramme ge- kapselt an alle Care-Of Adressen weitergeleitet. Läuft eine Registrierung beim HA aus, so werden an die assoziierte Care-Of Adresse keine Datagramme mehr weitergeleitet. Kehrt ein MH in sein Heimnetzwerk zurück, so deregistriert er alle Care-Of Adressen beim HA.

2.1.5 Authorisierung

Registrierungs-Datagramme müssen immer authorisiert sein. Dazu wird zwischen MH und HA eine Mobility Security Association vereinbart. Diese besteht aus:

6

Abbildung 5: Authorisierung beim Home-Agent und beim Foreign Agent

einem Authorisierungs-Algorithmus

einem Shared Key

einer Definition eines Sicherungsalgorithmus gegen Replay-Angriffe

MH und HA halten diese Informationen geheim und übermitteln lediglich einen 4 Byte

langen Security Parameter Identifier (SPI), welche dann die Assoziation definieren. Als Default-Algorithmus wird eine 128-Bit MD5 Prüfsumme über alle Registrierungsdaten und einem geheimen Schlüssel gebildet. Diese Prüfsumme wird zusamman mit dem

SPI jedem Registrierungs-Datagramm angehängt. Mobile IP ist jedoch nicht auf MD5

beschränkt. Soll ein anderer Algorithmus benutzt werden, so kann dies über einen SPI vereinbart werden.

Desweiteren kann eine Authorisierung nicht nur zwischen HA und MH stattfinden, sondern auch zwischen HA und FA oder MH und FA. Hier werden exakt die gleichen Mechanismen benutzt: es werden einfach der entsprechende SPI und die Authorisierungs- Prüfsumme an das Registrierungs-Datagramm angehängt (Abbildung 5). Ein bösartiger Angreifer könnte ohne weiteres die Registration-Requests eines MH abhorchen, um sie später ein weiteres mal versenden zu können (Replay Attack). Damit das nicht passiert, müssen alle Registrierungs-Datagramme einzigartigen Inhalt haben, denn so wird die MD5-Prüfsumme immer unterschiedlich sein. Mobile IP sieht hier zwei verschiedene Möglichkeiten vor:

1. Time-Stamps: jeder Registration-Request bekommt einen Zeitstempel. Ist die-

ser nicht zu weit von der aktuellen Zeit des HA entfernt, so wird der Request angenommen, ansonsten nicht. Natürlich müssen hier der MH und der HA zeit- synchronisiert sein. Auch ist dieses Verfahren nicht gegen Attacken gegen das normalerweise benutzte Zeitsynchronisierungsprotokoll NTP gefeit, denn es wä- re möglich, die Zeit auf dem MH zu beeinflußen, um Registration-Requests mit einer Zeit in der Zukunft zu erzeugen.

2. Pseudo-Zufallszahlen: jeder Registration-Request wird mit einer 32-Bit Zufalls-

zahl versehen, so daß es unwahrscheinlich ist, daß zwei Prüfsummen gleich aus- fallen. Hier müssen MH und HA die Zufallszahlenreihe synchron halten.

7

Abbildung 6: IP-Tunnelung bei mobilem Foreign Agent

2.1.6 Kaskadierung und mobile Router

Das Design von Mobile IP läßt mehrstufige Tunnelung von Datagrammen zu. Mithin ist es möglich, gleichzeitig ein MH und ein FA zu sein. Ein solches Setup liegt z.B. in sich bewegenden Einheiten nahe (Abbildung 6).

Stellt man sich den MH als sich bewegend (z.B. in einem Flugzeug) vor, so re- gistriert er sich am im Flugzeug vorhandenen FA (im Bild: MFA). Dieser gibt dem

MH als Care-Of Adresse seine eigene Home-Address. Der MFA kann sich im Flug

bei verschiedenen FAs (im Bild MFAFA) selbst als mobiler Host registrieren. Die IP- Datagramme nehmen dann folgenden Weg:

Datagramme vom MH zum FH werden über MFA und MFAFA direkt zum FH

geroutet

Datagramme vom FH zum MH werden zunächst unter Benutzung der Home-IP

des MH zum HA des MHs (MHHA) gesendet

Dort wird das Paket gekapselt und mit der derzeitigen Care-Of IP des MHs (also

der Home-IP des MFA) weitergeroutet

Dann wird das Datagramm am HA des FA (FAHA) erneut gekapselt und mit der

derzeitigen Care-Of IP des FA versehen weitergeroutet

Am FA des FA (MFAFA) wird das Datagramme um eine Stufe entkapselt und

zum FA weitergeroutet

Dort wird nun das ursprüngliche Datagramm wiederhergestellt und zum MH

geschickt

An diesem Beispiel sieht man, daß die Möglichkeit der Kaskadierung in Mobile IP eine gute Technik ist, ganze Subnetze beweglich zu halten. Allerdings wird mit jeder tieferen Stufe der Kaskadierung auch ein zusätzlicher Tunnel benötigt, was einerseits

8

Abbildung 7: IP Header

die Routen länger und andererseits die Datagrame selbst größer macht. Um diese Pro- bleme zu lösen, wurden von der Mobile IP Workgroup einige Protokollerweiterungen erbarbeitet, welche nun kurz vorgestellt werden sollen.

2.2 Protokoll-Optimierungen und -Erweiterungen

2.2.1 IP-Kapselung und deren Minimierung

Bei normaler IP-Kapselung nach RFC 2003 wird einem IP-Datagramm zwecks Kap- selung einfach ein weiterer IP-Header vorangestellt. Dies bedeutet, daß zusätzlich 24 Byte (die Größe eines IP-Headers) mittransportiert werden müssen (Abbildung 7). Jede zusätzliche Stufe der Kaskadierung würde zusätzlich weitere 24 Byte hinzufü- gen, was das Paket zeitweise unnötig groß machen würde, da viele Felder des Headers redundante Informationen tragen. Prinzipiell ist ja lediglich die Absicht, eine (falls die Source-Adress und der Anfangspunkt des Tunnels zusammenfallen) bzw. zwei IP- Adressen hinzuzufügen und am Endpunkt des Tunnels wieder zu entfernen. Um dieses Ziel zu erreichen wurde in RFC 2004 eine Technik vorgestellt, welche dem gekapselte IP-Datagramm lediglich 8 bzw. 12 Byte hinzufügen (Abbildung 8). Bei Minimierung des gekapselten Headers werden im vorhandenen Header lediglich folgende Verände- rungen vorgenommen:

1. Protocol wird von 4 auf 55 gesetzt, um zu kennzeichnen, daß es sich um ein

minimal gekapseltes IP-Datagramm handelt

2. Die Ziel-IP-Adresse wird entsprechend der neuen Route verändert

3. Beginnt der Tunnel auf einem anderen Host, als der Quell-IP-Adresse, so wird

diese auf die IP-Adresse des Tunnelbeginns gesetzt. Fallen beide Hosts zusam- men, so bleibt die Quell-IP die gleiche

9

Abbildung 8: IP-Kapselung mit und ohne Minimierung

Abbildung 9: Minimal Forwarding Header

4. Die Total Length wird um die Länge des Minimal-Forwarding Headers inkre-

mentiert. Dies können entweder 8 oder 12 Byte sein, je nachdem, ob die Quell- IP-Adresse ausgetauscht wurde oder nicht

5. Die Header-Checksum wird neu berechnet und ersetzt

Die verlorengegangenen Informationen werden im Minimal Forwarding Header (Abbildung 9) angehängt:

1. Protocol: das ursprüngliche Prtokollversionsfeld des Headers

2. Original Destination Address: die ursprüngliche Ziel-Adresse

3. Das S-Bit gibt an, ob auch die Quell-Adresse verändert wurde. Ist das S-Bit 0, so

ist dies nicht der Fall und der Minimal Forwarding Header ist nur 8 Byte lang.

4. Ist das S-Bit gesetzt, so wird noch die Original Source Address angehängt; der

zusätzliche Header ist dann 12 Byte lang

5. Natürlich wird auch hier eine Header Checksum benötigt

Bis auf das Vermeiden von Overhead hat die Minimierung der Kapselung noch den Vorteil, daß das TTL-Feld des alten Headers erhalten bleibt und somit die Hops, welche das Datagramm genommen hat, korrekt gezählt werden. Als Nachteil kann allerdings gewertet werden, daß solche Datagramme zuvor nicht fragmentiert werden dürfen, da für diese Informationen kein Platz im Minimal-Forwarding-Header vorgesehen ist.

10

Abbildung 10: Binding Cache Update

2.2.2 Routen-Optimierung

Befindet sich ein MH nicht in seinem Heim-Netzwerk, so werden alle für ihn bestimm- ten Datagramme über seinen HA getunnelt. Dadurch entsteht ein Dreiecks-Routing welches zu einer unnötigen Belastung des Netzwerks und der beteiligten Router führt. Beispielsweise werden Datagramme aus dem gleichen aktuellen Subnetz trotzdem im- mer über den HA getunnelt. Dieses Vorgehen hat große Nachteile, jedoch sichert es die Transparenz für alle nicht unmittelbar am Setup beteiligten Hosts. Läßt man neben HA, FA und MH noch eine vierte Klasse von Hosts zu, welche zwar nicht direkt am Setup beteiligt sind, jedoch in der Lage sein sollen, schnell und ohne Umwege mit ei- nem MH zu kommunizieren, so kann man dies mit dem ebenfalls von der Mobile IP

Working-Group vorgeschlagenem Route-Optimization 3 lösen. Potenzielle Kandidaten für solche Hosts sind z.B. jene, welche Standard-Services wie Filezugriff oder Email bieten.

Route-Optimization liegt z.Z. noch nicht als RFC, sondern nur als Internet Draft vor. Es soll hier vorgestellt werden, um einen Einblick in die aktuelle Diskussion zu geben.

Hosts, welche Route-Optimization beherrschen, haben die Möglichkeit, die aktu- elle Care-Of-Address eines MH zu cachen, und Datagramme so direkt an den MH zu tunneln. Desweiteren definiert Route-Optimization eine Möglichkeit einen nahtlosen Übergang von einem zum anderen FA, ohne daß bereits versandte Datagramme ver- worfen werden müssen. Somit müssen verlorengegangene Pakete nicht mehr durch die Flußkontrolle höherer Protokollschichten korrigiert werden.

Insgesamt werden also zwei Aufgaben durch Routen-Optimierung angegangen:

1. Pflege eines Binding-Caches auf Foreign Hosts

2. Implementieren von Smooth-Handoffs zwischen Foreign Agents

Sämtliche Nachrichten, welche für die Routen-Optimierung benötigt werden, laufen - genau wie die Registrierungs-Nachrichten - über UDP Port 434. Auch die Authentifi- zierung läuft genau so wie bei der Registrierung. D.h. insbesondere, daß beteiligte FHs und der HA eines MH einen Mobility Security Association vereinbart haben müssen. In Abbildung 10 ist ein Update des vom FH gehaltenen Caches dargestellt, wenn man davon ausgeht, daß der FH noch über keine Informationen über Care-Of IPs ver- fügt. Zunächst schickt der FH Datagramme an den HA des MH. Dieser tunnelt diese

3 http://www.ietf.org/internet-drafts/draft-ietf-mobileip-optim-11.txt

11

Abbildung 11: Binding Warning

Abbildung 12: Foreign Agent Smooth Handoff

zum MH und schickt gleichzeitig eine Binding Update Message zum FH, welcher diese auf Authentizität überprüft und bestätigt (Binding Acknowledge Message). Daraufhin kann der FH Datagramme an den MH selbst direkt an die Care-Of IP des MH tunneln. Genau wie Registrierungsnachrichten haben Cache-Einträge eine TTL und verfallen. Sollte ein MH die Zelle - und damit die Care-Of IP - wechseln so muß dieser Cache invalidiert werden. Ein FA schickt dazu eine Binding Warning Message an den HA ei- nes ehemaligen MH. Der HA ist immer über die Care-Of IP seiner MHs informiert und schickt so dem FH eine Binding Update Message (Abbildung 11).

Ein Problem hier ist, daß Datagramme welche an eine verfallene Care-Of IP adres- siert sind, immer über den HA geroutet werden müssen. Dieser Umweg kann durch die ebenfalls im Route-Optimization Draft definierten Foreign Agent Smooth Handoffs vermieden werden (Abbildung 12).

Zusammen mit der Registrierung an einem neuem FA kann ein MH den FA da- zu auffordern, dem vorigem FA ein Binding Update zu schicken. Der neue FA tut dies dann im Auftrag des MH und der vorige FA Bestätigt den Update dann direkt. Hat der vorige FA ein Binding Update empfangen, so kann er seine Registrierung des

MH sofort aufheben ohne auf die Lebenszeit dieser zu achten. An die alte Care-Of IP

12

adressierte Datagramme können dann direkt an den neuen FA weitergetunnelt werden. Smooth Handoffs haben den Vorteil, daß der Home Agent, welcher u.U. weit entfernt liegt, überhaupt nicht einbezogen werden muß.

2.2.3 Andere Protokollerweiterungen

Neben den obigen Optimierungen existieren noch einige andere Erweiterungen wie z. B.:

Mobile IP für IPv6

Mobile IP Authentifizierung, Authorisierung, und Accounting Anforderungen

Challenge/Response Erweiterungen

Reverse Tunneling

Hauptfokus dieser Erweiterungen liegt auf der Absicherung des Protokolls und der Optimierung von Routen. Da Mobile IP insbesondere auch für ISPs interessant sein dürfte, liegt ein weiterer Schwerpunkt in der Definition von Anforderungen an ein Abrechnungs/Authorisierungs-Konzept.

2.3 Implementierungen

2.3.1 Überblick

Es existieren eine Reihe von Implementierungen von Mobile IP. Eine Auswahl soll hier kurz vorgestellt werden:

MOQUITONET MOBILE IP URL: http://gunpowder.stanford.edu/mip/

OS: Linux 2.2 Bemerkungen:

-Kernelpatch und Userspace-Daemon -es besteht die Option wahlweise „normales” IP oder Mobile IP zu benutzen, was für Services wie Web-Browsing von Vorteil sein kann -die Mobile IP Erweiterung Reverse Tunneling wurde implementiert: wahlweise kann das Dreiecks-Routing von Mobile IP benutzt oder Datagramme können vom MH zum FH über den HA getunnelt werden.

THE PORTLAND STATE UNIVERSITY SECURE MOBILE NETWORKING PRO-

JECT URL: http://www.cs.pdx.edu/research/SMN

OS: 4.4BSD/Linux2.0 Bemerkungen:

-Kernelpatch und Userspace-Daemon -Integration von Mobile IP und IPSEC -Projekt wurde 1999 eingestellt

13

LANCASTER MOBILE IPV6 PACKAGE URL: http://www.cs-ipv6.lancs.ac.uk/MobileIP/ OS: Linux2.1 Bemerkungen:

-Kernelmodul -Eine Implementation von Mobile IP für IPv6 -Route Optimization -Project wurde 1998 eingestellt

CMU MONARCH PROJECT URL: http://www.monarch.cs.cmu.edu/

OS: 4.4BSD Bemerkungen:

-Kernelpatch und Userdaemon -IPv4, IPv6 -Route Optimization

INRIA HMIPV6 PROJECT URL: http://www.inrialpes.fr/planete/people/bellier/hmip.html

OS: FreeBSD 3.4 Bermerkungen:

-Kernelpatch und User-Daemon -IPv6 -Route Optimization -Inria ist eine Abwandlung von Mobile IP; Ein Host bekommt gleich zwei Care-Of Adressen: eine globale und eine lokale. Wechselt er innerhalb einer Domain, so be- kommt er immer nur eine neue lokale Care-Of Adresse zugewiesen, die globale bleibt so lange erhalten, bis er die Domain wechselt. So kann eine einstufige Hierarchie rea- lisiert werden, welche es unnötig macht, Binding-Updates an Hosts außerhalb der Do- main zu senden (Micro-Mobility)

SUN MOBILE IP URL: http://playground.sun.com/pub/mobile-ip/sunlabs/

OS: Solaris 7/8 Bemerkungen:

-generische Implementation für IPv4

POLITEHNICA UNIVERSITY OF BUCHAREST URL: http://mip-nt.aii.pub.ro/

OS: Windows NT4 Bemerkungen:

-generische Implementation für IPv4 -Zusammenarbeit mit dem GMD Fokus Berlin

NUS MOBILE IP URL: http://opensource.nus.edu.sg/projects/mobileip/

OS: Linux 2.0, Windows Bemerkungen:

-IPv4, IPv6 (nur Linux)

14

MIPL MOBILE IPV6 FOR LINUX URL: http://www.mipl.mediapoli.com/ OS: Linux 2.4 Bemerkungen:

-Kernelpatch und User-Daemon -IPv6 -MIPL ging aus dem HUT-Projekt (s.u.) hervor -Intergration von IPSEC und der AAA-Erweiterung

MICROSOFT IPV6 URL: http://research.microsoft.com/msripv6/

OS: Windows NT/2000 Bemerkungen:

-nur für MHs -integriert in den IPv6-Stack

Dynamics - HUT Mobile IP URL: http://www.cs.hut.fi/Research/Dynamics/index.html OS: Linux 2.1-2.4, Windows (nur MH) Bemerkungen:

-aktuellste Implementierung -Kernelmodul (für den IPIP-Tunnel) und Userspace-Daemon -Konfigurationsassistenten, Webinterface für HA und FA -Verschlüsselung über RSA möglich -kommerzielle Variante: Lifix GO! - http://www.lifix.fi -auch für alle Windows-Versionen verfügbar(nur MH) -Reverse Tunneling -hierarchische Anonrdnung von FAs => Nutzung eines privaten Adreßraumes für Care-Of Adressen möglich

2.3.2 Dynamics HUT Mobile IP - Hierarchisches Modell

Unter allen oben genannten Implementationen ist die - auch als kommerzielle Variante erhältliche Version - von der Dynamics HUT Mobile IP Arbeitsgruppe entwickelte, die vielversprechenste. Neben den meisten Erweiterungen zeichnet diese Software sich durch eine (dem Standard konforme) Erweiterung auf ein hierarchisches Modell aus (Abbildung 13).

Eine Domain besitzt immer einen FA, welcher am nächsten zum globalem Internet liegt. Wechselt ein MH von einer Domain in einer andere, so wird über diesen eine neue Care-Of IP beim HA registriert. Innerhalb dieser Domain dient der äußere FA als eine Art Foreign Home Agent (FHA): der MH bekommt innerhalb der Hierarchie neue Care-Of IPs, welche dann beim FHA registriert werden. Diese Art von Hierarchie kann um theoretisch beliebig viele Stufen weitergetrieben werden. Der große Vorteil ist hier, daß Registrierungen und Binding-Updates bei Wechseln innerhalb der Domain nicht über das (langsame) Internet an den HA des MH transportiert werden müssen, sondern innerhalb des Netzwerkes der Domain bleiben. Auch muß die Kommunikation innerhalb der Domain nicht über den HA des MH geroutet werden, so daß die Nutzung von Services innerhalb der Domain effizient gestaltet werden kann. Ein weiterer Vorteil ist, daß innerhalb der Domain ein privater IP-Adreßraum be- nutzt werden kann. Dieselbe Möglichkeit besteht für Home Agents: durch einen äuße- ren HA können weitere HAs (beispielsweise zum Load-Balancing) private Adressen

15

Abbildung 13: Dynamics HUT - hierarchisches Modell

Abbildung 14: TCP Slowstart

benutzen. Registrierungen etc. werden dann immer über den äusseren HA weiterge- reicht. Auf diese Weise sind offizielle IPs nur an den jeweiligen Zugangspunkten zum Internet nötig, eine Prämisse, welche auch Netze kleinerer Unternehmen und Privat- personen erfüllen.

3 Andere mobile Protokolle

3.1 Transportprotokoll-Handling

Um die wahren Vorteile einer persistenten IP-Verbindung zum Internet nutzen zu kön- nen, sind auch Erweiterungen auf höheren - insbesondere der Transport-Schicht - not- wendig. Das mit IP nahezu zwingend verbundene TCP weist jedoch in Bezug auf die Tauglichkeit im mobilen Einsatz einige Schwächen auf. Das Design von TCP ist nicht mit dem Gedanken an mobile Endgeräte entworfen worden. Dies macht sich besonders in den benutzten Flußkontroll-Mechanismen bemerkbar, denn hier geht TCP davon aus, daß Segment-Verluste grundsätzlich auf Netzwerk-Overhead zurückzuführen sind

- die Möglichkeit, daß Segmente z.B. durch unzuverlässige drahtlose Links hervorgeru- fen worden sein könnten wird nicht in Betracht gezogen (Abbildung 14). Dementspre- chend sind die Flußkontroll-Mechanismen als zu konservativ zu werten, denn in dem

16

Abbildung 15: TCP Fast Retransmit

Abbildung 16: TCP Fast Recovery

Fall, in dem ein Segment durch z.B. Störungen des drahtlosen Netzes verursacht wur- de, sind andere Algorithmen, als die von TCP benutzten, geeigneter. Es wurden einige Vorschläge zur Anpassung der TCP-Layer an mobile Endgeräte gemacht. Zunächst ist es möglich, die Fehlerkorrektur und die Flußkontrolle auf TCP-Ebene logisch vonein- ander zu trennen.

3.1.1 Fast Retransmit / Fast Recovery

Eine Möglichkeit, durch Übertragungsfehler verlorengegangene Segmente abzufan- gen, ist die Kombination von Fast Retransmit und Fast Recovery. Fast Retransmit ist eine Technik, bei der verlorengegangene Segmente nach z.B. drei gleichen ACKs ein- fach nocheinmal übertragen werden (Abbildung 15).

Normalerweise wechselt TCP nach einem solchen Event in den Slow-Start-Mode. Wird jedoch Fast Recovery eingesetzt, so wird einfach die Größe des letzten Congestion- Windows halbiert. So ossziliert die Größe des Fensters um den für die Verbindung optimalen Wert (Abbildung 16).

Neben diesen gibt es noch weitere Ansätze wie Forward ACKs oder Selective ACKs, welche hier jedoch nicht weiter erläutert werden sollen.

17

Abbildung 17: I-TCP Verbindung

3.1.2 Indirect TCP

Ähnlich wie beim IP, ist heute nicht mehr die Möglichkeit gegeben, direkte Protokol- länderungen einzuführen, was eine indirekte Umgehung notwendig macht. Eine Mög- lichkeit ist Indirect-TCP[1], ein Protokoll, welches auf Mobile IP aufsetzt und mit ähn- lichen Mechanismen arbeitet.

Will ein MH eine I-TCP-Verbindung mit einem entferntem Host aufbauen, so wird dies über den jeweiligen MSR signalisiert. Dieser baut auf Anforderung des MH eine herkömmliche TCP-Verbindung mit dem FH auf. Auf Seiten des MH wird eine zweite Transport-Verbindung aufgebaut. Je nach Implementierung kann dies TCP, aber auch über ein ganz anderes, besser auf Mobilität ausgelegtes Protokoll sein (Abbildung 17).

Eine I-TCP-Verbindung besitzt demnach drei anstatt zwei IP/Port-Paare als Verbin- dungscharakteristik: MH-IP/Port, FH-IP/Port, MSR-IP/Port. Die genauen Endpunkte sind in Abbildung 18 zu sehen. Wechselt ein MH die Zelle und damit den MSR, so werden auf dem neuen Router zwei Sockets mit genau den gleichen Parametern wie auf dem vorigen MSR aufgebaut. Für den MH und den FH bleiben die Parameter al- so völlig gleich und die I-TCP-Verbindung kann transparent mitgeführt werden. Die Verantwortlichkeit für den Handoff liegt beim MH selbst. Dieser muß, sobald ein Zel- lenwechsel erkannt worden ist, versuchen, entsprechende Requests an den neuen MSR zu senden, welcher dann die entsprechenden Sockets generiert. Wie in Abbildung 18 ebenfalls zu sehen ist, muß ein MSR in der Lage sein, Sockets mit einer nicht selbst benutzten IP-Adresse aufzubauen.

Da sowohl Mobile IP und auch I-TCP in irgendweiner Form Handoffs implemen- tieren müssen, liegt eine Integration nahe, zumal durch ein asynchrones Handoff Pro- bleme entstehen können. Darauf soll hier aber nicht weiter eingegangen werden.

3.1.3 Snoop TCP

Unter Snoop TCP[6] bekannt, ist eine andere Möglichkeit, die für mobile Hosts charak- teristische hohe Segmentverlustrate abzufangen. Anstatt - wie bei I-TCP - zwei TCP- Verbindungen zu verwalten, fungiert hier der MSR einfach als Monitor, welcher alle ACKs abfängt und für den MH/FH entsprechend aufbereitet. Auf der drahtlosen Seite werden dann verlorengegangene Segmente schnell nocheinmal übertragen.

18

Abbildung 18: I-TCP Setup

Abbildung 19: Snoop TCP

19

3.2 Zeroconf Networking Neben der Persistenz von Verbindungen, welche durch Mobile IP realisiert wird, ist ein Hauptvorteil von Mobile IP die fehlende Notwendigkeit, bei Netzwechseln die vorhan- dene IP-Konfiguration anzupassen. Zumindest in diesem Punkt überschneiden sich die

Interessen der Mobile IP Workgroup mit denen der Zeroconf Workgroup 4 , obwohl hier ganz andere Ansätze benutzt werden. Um einen Überblick zu bekommen, sollen hier die Grundzüge von Zeroconf erörtert werden.

Die Anstrengungen der Zerconf WG resultierten bisher lediglich in einigen Internet Drafts, welche zugrundeliegende Ideen und Ansätze festhalten. Hier wurden bisher vier Bereiche ausgemacht, in denen Zeroconf-Protokolle sinnvoll sein könnten:

1. IP-Interface Konfiguration

2. Name<->Address-Übersetzung

3. IP Multicast-Address Discovering

4. Service Discovery auf Applikationsebene

Jeder dieser Bereiche wird als eigenständig und von den anderen unabhängig angese- hen.

3.2.1 IP Interface Konfiguration

DHCP-Server sind seit langem im Internet etabliert, jedoch realisieren sie lediglich eine dynamische Konfiguration. Im Gegensatz dazu unterscheidet sich die durch die Zerconf-WG vorgeschlagene automatische Konfiguration dadurch, daß nicht einmal ein solcher Server benötigt wird: Hosts, welche zu einem Netzwerk zusammenge- schlossen werden, konfigurieren das von ihnen gebildete Subnetz vollständig autonom und ohne Nutzereingriff selbst. Folgende Aufgaben sind dabei zu lösen: IP-Adressen müssen einzigartig sein

¡

alle Hosts müssen über die gleiche Subnetzmaske verfügen

¡

evtl. müssen Gateways gefunden und das Routing entsprechend konfiguriert wer-

¡

den Es wird weiterhin zwischen globaler und lokaler Konfiguration unterschieden: Hosts fallen nur auf eine lokale (d.h. über ein Zeroconf-Protokoll gesteuerte) Konfiguration zurück, sollte es mit einer globalen Konfiguration (z.B. feste IP oder DHCP) nicht möglich sein, eine IP Kommunikation herzustellen.

3.2.2 Name-To-Address Translation

Der zweite Bereich für Zeroconf-Protokolle wird in herkömmlichen Netzen über DNS- Server abgedeckt. In Umgebungen, in denen ein solcher nicht benutzt werden kann

oder soll, kann Multicast DNS 5 benutzt werden.

Multicast DNS ist ein einfacher Mechanismus um den Nameservice auch ohne de- dizierten Server dynamisch halten zu können. Wird versucht, einen Namen aufzulösen,

4 http://www.ietf.org/html.charters/zeroconf-charter.html

5 http://www.ietf.org/internet-drafts/draft-ietf-dnsext-mdns-07.txt

20

Abbildung 20: Multicast DNS

Abbildung 21: Service Location Protocol Version 2

so wird über eine fest definierte Multicast-Adresse ein Request geschickt. Alle Hosts können diese Pakete auswerten und - falls der angeforderte Name auf sie zutrifft - einen

DNS RR zurückgeben. Dies funktioniert auch in umgekehrter Richtung mit PTR-RRs.

Zeroconf-Protokolle müssen überdies die Möglichkeit von Hostnamen-Doppelungen miteinkalkulieren und in der Lage sein, diesen bei Bedarf dynamisch zu ändern.

3.2.3 Service Discovery

Der schon bei der Namensauflösung benutzte Multicast kann auch in anderen Berei- chen nützlich sein. In der Vergangenheit wurde immer wieder versucht, im lokalen Netz verfügbare Dienste in irgendeiner Form kenntlich zu machen. Meist wurde das Problem über Broadcast-Anfragen gelöst, was ein nicht-skalierendes Verhalten zur Folge hatte

(siehe IPX). Neuere Ansätzen, wie z.B. das Service Location Protocol SLP 6 , benutzen hier Link-Local- oder Administrative-Scope Multicast.

Ähnlich, wie bei der Namensauflösung wird über eine Multicast-Adresse ein Ser- vice über seinen Typ und/oder bestimmte Attribute angefordert. Trifft die Anfrage auf einen angebotenen Dienst zu, so antwortet der entsprechende Host. Die Suche über At- tribute ist deshalb wichtig, weil viele Dienste einzigartig in ihrer Funktion sind (z.B. Fi- leserver, Drucker, welche bestimmte Treiber benötigen) und ein Client erst bei Kennt- nis gewisser Attribute entscheiden kann, ob er diesen Dienst nutzen kann oder will. Andere Dienste wie z.B. Web-Proxies oder SMTP-Relays können jedoch (meist) rein über den Typ referenziert werden.

Ein anderer Weg, Service-Discovery zu realisieren, ist ein spezieller Resource Re- cord SRV im DNS: Clients können über die Angabe eines Servicetyps und eines Trans- portprotokolls einen entsprechenden Host über DNS finden.

6 http://www.ietf.org/html.charters/svrloc-charter.html

21

3.2.4 IP Multicast-Address Discovering Anders als Host-Adressen, sind Multicast-IP-Adressen eine geteilte Resource und müs- sen deshalb auch in der automatischen Konfiguration ein anderes Prozedere durchlau- fen, als die reinen IP-Adressen. Das ebenfalls von der Zeroconf Workgroup vorge- schlagene Zeroconf Multicast Allocation Protocol (ZMAAP) löst diese spezifischen Probleme.

Literatur

[1] Ajay Bakre and V. Badrinath. Implementation and Performance Evaluation of Indirect TCP. IEEE Transactions on Computers, 46(3), March 1997. [2] Claude Castellucia. A Hierarchical Mobile IPv6 Proposal. Technical report, IN-

RA - Institut Natinonal de Recherche en Informatique et en Automatique, No-

vember 1998.

[3] Antonella Di Stefano and Corrado Santoro. Netchaser: Agent Support for Perso- nal Mobility. IEEE: Internet Computing, March 2000.

[4] Vipul Gupta. Solaris Mobile IP: Design and Implementation. Technical report,

SUN Microsystems, Inc„ 17 February 1998.

[5] Erik Guttman. Autoconfiguration for IP Networking. IEEE: Internet Computing, May 2001.

[6] Hari Balakrishnan, Srinivasan Seshan, and Randy H. Katz. Improving Reliable Transport and Handoff Performance in Cellular Wireless Networks. ACM Wire- less Networks, 1(4), December 1995.

[7] Geoff Huston. TCP in a Wireless World. IEEE: Internet Computing, March 2001. [8] Jouni K. Malinen. Using private addresses with hierarchical Mobile IPv4. Ma- ster’s thesis, Helsinki University of Technology, 20 March 2000. [9] Andrew Myles, David B. Johnson, and Charles Perkins. A Mobile Host Protocol Supporting Route Optimization and Authentication. IEEE Journal on Selected Areas in Communications, 13(5):839–849, June 1995. special issue: Mobile and Wireless Computing Networks.

[10] N.N. Lifix GO! Whitepaper. Lifix, 7 November 2001.

[11] Charles E. Perkins. Mobile Networking Through Mobile IP. IEEE Internet Com- puting, October 1998.

[12] James R. Rinkley and John McHugh. Secure Mobile Networking - Final Report. Technical report, Portland State University, June 1999.

[13] Tom Weckström. AAA architecture for hierarchical wireless Mobile IPv4. Ma- ster’s thesis, Helsinki University of Technology, 18 July 2000.

22