Zusammenfassung

  • RFC 3963 ließ einen Mobile Router den Anschlusspunkt eines ganzen Netzes verlagern, während dessen Knoten nichts von der Mobilität wissen mussten. Eine positive Binding-Bestätigung mit R belegte Verarbeitung und Präfixweiterleitung, nicht die Erreichbarkeit jedes Knotens.
  • Explizite Optionen, implizite Vorkonfiguration und dynamisches Routing lieferten unterschiedliche Präfixnachweise. Autorisierung, Route, Tunnel, Knotenprobe, Sitzung und Dienst bleiben daher getrennte Belege.

In einem Zug, Schiff oder Einsatzfahrzeug kann ein vollständiges Netz reisen. Seine Sensoren und Rechner behalten Adressen und Gateway, obwohl sich draußen der Zugang ändert. Der Mobile Router trägt diese Ortsänderung stellvertretend. RFC 3963, im Januar 2005 als Standards-Track-Dokument veröffentlicht, nannte das NEMO Basic Support.

Außerhalb des Heimatnetzes bezog der Router eine Care-of Address und schickte ein Binding Update an seinen Home Agent. Das R-Flag verlangte die Behandlung als Mobile Router. Der Agent verband die feste Home Address mit der aktuellen Care-of Address und richtete die Weiterleitung für autorisierte Mobile Network Prefixes ein. Ein bidirektionaler Tunnel führte den Verkehr zum neuen Standort und zurück.

Die Bestätigung hatte einen präzisen Umfang. Status null zusammen mit R erlaubte die Annahme, dass der Home Agent das Update verarbeitet und die Präfixweiterleitung installiert hatte. Sie sagte nichts darüber, ob ein interner Rechner eingeschaltet war, eine Sitzung fortbestand, der Pfad optimal war oder eine Anwendung Zugriff gewährte. Sie war eine Quittung der Steuerungsebene.

Ein Flag benennt die Behandlung, nicht die Identität

Der Mobile Router setzte R in der Anfrage; bei Annahme spiegelte der Home Agent R in der positiven Antwort. Das Bit gab der Nachricht Bedeutung, authentisierte aber nicht den Absender. RFC 3963 verlangte IPsec für die Signalisierung zwischen beiden. Die geschützte Security Association trug die Authentizität, das Flag beschrieb den Auftrag innerhalb dieser Beziehung.

Ein prüfbarer Datensatz bewahrt deshalb Home Address, Care-of Address, Sequenz, Lebensdauer, H und R, exakte Präfixoptionen, IPsec-Zuordnung, Antwortstatus, Tunnelenden sowie installierte und entfernte Routen. Selbst diese Gesamtheit beobachtet nur die Weiterleitungsanordnung, nicht jedes Gerät dahinter.

RFC 3775 lieferte die damalige Mobile-IPv6-Grundlage für Hosts, RFC 6275 überarbeitete sie später. RFC 3963 stellte hinter den mobilen Endpunkt ein Netz. Eine Bindung repräsentierte damit mehr Adressen, aber nicht mehr Wahrnehmung.

Drei Herkunftswege für Präfixwissen

Im expliziten Modus trug das Binding Update eine oder mehrere Mobile-Network-Prefix-Optionen. Der Home Agent konnte sie gegen eine Prefix Table prüfen, die erlaubte Präfixe auswies. Die Entscheidung war atomar: Konnte er nicht für alle angegebenen Präfixe Weiterleitung einrichten, durfte er keines weiterleiten und musste mit Status 141 ablehnen. Ein nicht autorisiertes Präfix ergab 142.

Alles oder nichts verhinderte, dass eine Bestätigung einen halb vollzogenen Umzug verdeckte. Ein Treffer in der Tabelle belegte jedoch nur Berechtigung. Er bewies nicht, dass jeder Knoten im Adressraum lebte.

Im impliziten Modus fehlten Präfixoptionen. Der Home Agent verwendete vorher konfigurierte Informationen; ohne sie wies er die Anfrage mit 143 zurück. Gleich aussehende Erfolge konnten also auf Daten in der aktuellen Nachricht oder auf einem extern gepflegten Bestand beruhen. Modus, Version, Eigentümer und Beobachtungszeit dieses Bestands gehören in die Provenienz.

Dynamisches Routing durch den Tunnel bildete einen dritten Weg. Es konnte Änderungen lernen, zugleich aber interne Topologie offenlegen; der RFC empfahl daher ESP-Vertraulichkeit für Routingnachrichten. Die Feststellung „Route vorhanden“ ist ohne Herkunft unvollständig: statisch, explizit beantragt, implizit hinterlegt oder dynamisch gelernt?

Gerade zu statischen Routen enthielt das Dokument eine ernüchternde Warnung. Sie senkten den Signalisierungsaufwand, konnten aber fortbestehen, obwohl der zugehörige Mobile Router nicht mehr erreichbar war. Konfigurationswahrheit und Gegenwartswahrheit fielen auseinander.

Transparenz bündelte auch Abhängigkeit

Im Basismodell lief der Verkehr zwischen Mobile Network Nodes und Correspondent Nodes über den Home Agent. Abwärts kapselte dieser zur Care-of Address. Der Mobile Router prüfte die äußere Quelle als seinen Home Agent, sofern Tunnel-IPsec das nicht schon absicherte, und leitete nur innere Ziele aus einem Mobile Network Prefix weiter.

Aufwärts filterte er innere Quellen außerhalb der Präfixe; auch der Home Agent prüfte die topologische Plausibilität, bevor er Tunnelverkehr freigab. Das begrenzte Adressfälschung. Es attestierte weder ein Gerät noch einen Benutzer und entschied keine Anwendungsberechtigung.

Basic Support definierte keine Routenoptimierung für den Präfixverkehr. Verschachtelte Mobile Router konnten einen Baum bilden und Tunnel stapeln. RFC 4885, RFC 4886 und RFC 4887 ordneten Begriffe, Ziele und Probleme. RFC 4888 untersuchte Optimierungsprobleme, RFC 4889 den Lösungsraum. Eine funktionierende Route war noch keine optimale Route.

Spätere Texte ergänzten benachbarte Mechanismen. RFC 5488 und RFC 6276 behandelten DHCPv6-Präfixdelegation für mobile Netze; RFC 6089 beschrieb Flow Bindings. Sie fügten Entscheidungen hinzu, aber keine machte die ursprüngliche Bestätigung zur Knotenprobe.

Der offizielle Verlauf steht auf der Informationsseite des RFC Editor, in der Errata-Suche, im IETF Datatracker und im IANA Mobility Parameters Registry. Diese Quellen belegen Status, gemeldete Korrekturen und koordinierte Werte, nicht Verbreitung oder korrekte Umsetzung in einem bestimmten Netz.

Das Betriebsjournal sollte die Kette getrennt halten: Bewegungserkennung, beide Adressen, Updateinhalt, Sequenz und Gültigkeit, Präfixmodus, Autorisierungsquelle, atomare Entscheidung, Antwort, IPsec, Tunnel, jede Routenänderung, Adressfilter, Präfixtests, Knotenreaktionen, Sitzungen und Dienste. Dann kann ein Erfolg nur für die Schicht sprechen, die ihn erzeugt hat.

RFC 3963 reduzierte die Zahl der beweglichen Teile, indem ein Router viele Knoten vertrat. Seine bleibende Lehre lautet, die Zahl der Behauptungen einer einzelnen Quittung nicht im selben Maß zu vergrößern.

Quellen