Seit Jahren erwartet, ist endlich Version 4 des Samba-Servers erschienen, der nun als vollwertige Alternative zu Microsofts Active Directory dienen kann. In der ... (mehr)

So funktioniert Mobile IPv6

Solange der MN an seinem Home Link sein normales Präfix nutzt, kann er über ganz normale Routing-Mechanismen erreicht werden, da hier auch der Home Agent mit der Home Address lokal angesiedelt ist. Unterwegs beziehungsweise außerhalb seines Home Links erhält er in einem beliebigen Foreign Link eine zusätzliche Adresse (Care-of-Address), die er in einer Binding-Update-Nachricht an seinen Home Agent schickt. Der Home Agent sendet ein Binding Acknowledgement und weiß durch den Binding-Prozess immer, unter welcher Care-of-Address der MN gerade erreichbar ist. Der Correspondent Node nutzt zunächst grundsätzlich zur Kommunikation mit dem MN die Home Address, die zum Home Agent führt.

Der MN kann über zwei Wege mit dem Correspondent Node kommunizieren. Beim Bidirectional Tunneling werden Pakete vom CN an den Home Agent geschickt, der diese durch einen Tunnel zum MN weiterleitet. Der MN schickt die Antworten durch einen Reverse Tunnel zum Home Agent, der die Daten zum CN weiterleitet. Auf dem Correspondent Node ist keine Unterstützung für Mobile IPv6 notwendig.

Bei der Route Optimization findet die Kommunikation nach der initialen Verbindung durch den Home Agent direkt zwischen MN und CN statt, ohne Umweg über den HA. Dazu wird ein Typ-2-Routing-Header verwendet. Route Optimization ermöglicht eine effizientere Kommunikation, da hier das Routing optimiert werden kann und nicht der Umweg über den HA erfolgen muss. Dies erfordert jedoch Mobile IPv6-Unterstützung auf dem CN. Route Optimization ist einer der Hauptvorteile von Mobile IPv6 gegenüber Mobile IPv4, da Letzteres keine Extension Header (und damit keinen Routing Header) erlaubt.

Das Protokoll

IPv6 ist insbesondere durch die Extension Header sehr flexibel. Für MIPv6 wurde ein eigener Extension Header namens Mobility Header (MH) entwickelt. Er wird von allen Beteiligten, also Mobile Node, Correspondent Node und Home Agent, in Nachrichten verwendet, die mit der Verwaltung und Aktualisierung von Bindings zu tun haben. Abbildung 3 zeigt den Aufbau des Mobility Headers. Der Mobility Header wird durch den Next Header-Wert 135 im vorhergehenden Header angezeigt. Er selbst hat in seinem Next-Header-Feld (das hier den Namen »Payload Proto« trägt) derzeit den Wert 59, um anzuzeigen, dass ihm keine weiteren Daten folgen. Dieses Feld ist für zukünftige Entwicklungen vorgesehen, wenn später weitere Daten angehängt werden.

Abbildung 3: Der Mobility-Header.

Das Header-Length-Feld enthält die Länge des Mobility Headers in 8-Byte-Einheiten, wobei die ersten 8 Bytes nicht mitgezählt werden. Damit muss der MH immer ein Vielfaches von 8 Byte lang sein. Das MH-Type-Feld enthält den Typ der Mobility-Nachricht. Derzeit sind 16 Mobility-Nachrichtentypen definiert, unter anderem Binding Update und Binding Ack. Ein Checksum-Feld berechnet eine Checksumme aufgrund eines Pseudo-Headers und folgt den in RFC 2460 (Internet Protocol, Version 6) festgelegten Regeln.

In Mobility-Nachrichten können Optionen enthalten sein, die im TLV-Format (Type-Length-Value) angegeben werden. Insbesondere die Option Home Address ist relevant, da der Mobile Node hier an den Correspondent Node eine Nachricht sendet, in der er die seine Home Address mitteilt. Dadurch ist der Correspondent Node in der Lage, den Mobile Node jederzeit zu erreichen. Allerdings ist dies auch gleichzeitig ein Sonderfall, da diese Option in einem Destination Header und nicht wie sonst im Mobility Header gesendet wird. Ein Destination Header ist ein Extension Header, der nur vom Ziel ausgewertet wird.

Für MIPv6 wurde außerdem ein neuer Routing Header definiert. Dadurch können Mobile Node und Correspondent Node direkt Daten austauschen, ohne über den Home Agent gehen zu müssen. Dieser Extension Header trägt die Bezeichung Typ 2 und sieht vor, dass auf Firewalls für MIPv6-Pakete spezielle Regeln konfiguriert werden können. Da die MIPv6-Kommunikation grundsätzlich erst einmal über den Home Agent und die Home Address geht, wird Letztere im Routing Header Typ 2 eingefügt, während die Zieladresse im IPv6-Header die Care-of-Address des Mobile Nodes ist. Der empfangende Mobile Node entfernt den Routing Header und ersetzt die Care-of-Address durch die Home Address, um den Upper-Layer-Protokollen in den OSI-Schichten darüber "vorzugaukeln", dass die Kommunikation über die Home Address gegangen ist.

Ähnliche Artikel

comments powered by Disqus

Artikel der Woche

Eigene Registry für Docker-Images

Wer selber Docker-Images herstellt, braucht auch eine eigene Registry. Diese gibt es ebenfalls als Docker-Image, aber nur mit eingeschränkter Funktionalität. Mit einem Auth-Server wird daraus ein brauchbares Repository für Images. (mehr)
Einmal pro Woche aktuelle News, kostenlose Artikel und nützliche ADMIN-Tipps.
Ich habe die Datenschutzerklärung gelesen und bin einverstanden.

Konfigurationsmanagement

Ich konfiguriere meine Server

  • von Hand
  • mit eigenen Skripts
  • mit Puppet
  • mit Ansible
  • mit Saltstack
  • mit Chef
  • mit CFengine
  • mit dem Nix-System
  • mit Containern
  • mit anderer Konfigurationsmanagement-Software

Google+

Ausgabe /2019