Zusammenfassung

  • Mit dem S-Bit konnte ein Mobile-IPv4-Knoten verlangen, dass der Heimatagent beim Akzeptieren einer neuen Care-of-Adresse frühere Mobilitätsbindungen beibehält.
  • Unterstützte der Heimatagent gleichzeitige Bindungen, tunnelte er jedes eintreffende Datagramm separat an alle aktiven Adressen; die neue erfolgreiche Registrierung bewies daher weder Exklusivität noch das Ende des alten Pfades.

Eine Mobilitätstabelle sieht auf den ersten Blick wie ein überschreibbares Feld aus: dauerhafte Heimatadresse, aktuelle Care-of-Adresse, Ablaufzeit. RFC 3344 erlaubte stattdessen eine Menge. Unter derselben Heimatadresse konnten mehrere Zeilen gleichzeitig gelten, jede mit eigener Lebensdauer. Der Heimatagent wählte nicht zwingend eine aus, sondern vervielfältigte den Verkehr.

Diese Mehrzahl war ausdrücklich signalisiert. Im Registration Request stand das S-Bit für simultaneous bindings. Der mobile Knoten setzte es, wenn frühere Bindungen fortbestehen sollten. Ohne diese Bitte oder ohne Unterstützung ersetzte die neue Bindung die alten Einträge.

Eine Care-of-Adresse war ein Tunnelende

Mobile IPv4 hielt die Heimatadresse stabil, während sich der Netzanschlusspunkt änderte. Die Care-of-Adresse bezeichnete den Endpunkt des Tunnels. Sie konnte einem Fremdagenten gehören, der Pakete entkapselte, oder als co-located Adresse direkt am mobilen Knoten liegen.

Damit war sie eine Weiterleitungsangabe, kein Ortszertifikat. Sie bewies weder den physischen Standort einer Person noch Funkqualität, gültigen Besucherzustand oder Zustellung an eine Anwendung. Authentisierung stützte die Berechtigung der Registrierungsnachricht; sie machte aus dem gespeicherten Eintrag keinen Lieferbeleg.

RFC 3344 nannte einen Knoten, der sich in Reichweite mehrerer Fremdagenten befindet. Bei gleichzeitigen Bindungen fing der Heimatagent ein an die Heimatadresse gerichtetes Datagramm ab, erzeugte pro Care-of-Adresse eine Kopie und kapselte jede für ihren Tunnel ein. Der Text stellte klar, dass IP Datagrammduplikation zulässt und der Knoten mehrere Kopien empfangen kann.

Zwei gleiche Pakete sind deshalb nicht automatisch Replay oder Störung. Zwei aktive Tabellenzeilen beweisen umgekehrt nicht, dass beide Pfade funktionieren. Akzeptierter Kontrollzustand und beobachtete Datenzustellung bleiben getrennt.

Erfolgscode 0 und 1 waren nicht austauschbar

Code 0 bedeutete, dass die Registrierung akzeptiert wurde. Code 1 war ebenfalls erfolgreich, meldete aber fehlende Unterstützung für gleichzeitige Mobilitätsbindungen. Das heutige IANA-Register führt beide Bedeutungen weiterhin getrennt.

Nach einer Anfrage mit S konnte Code 0 alte und neue Einträge gemeinsam bestehen lassen. Code 1 akzeptierte die neue Registrierung, ohne die gewünschte Mehrfachfähigkeit zu liefern. Code 135 war ein anderer Zustand: Ablehnung wegen zu vieler gleichzeitiger Bindungen.

Ein Betriebsbildschirm, der 0 und 1 zu demselben grünen Zustand macht, entfernt die entscheidende Information. Spätere Duplikate oder fehlende Kopien lassen sich dann nicht korrekt erklären. Das Protokolljournal braucht das angeforderte Bit, den Antwortcode, die Bindungsmenge, jede gewährte Lebensdauer und die Beobachtung pro Tunnel.

Ein Ablauf entfernte nicht die ganze Menge

Eine Registrierung mit Lebensdauer null hatte zwei Reichweiten. Entsprach die Care-of-Adresse der Heimatadresse, löschte der Heimatagent sämtliche Bindungen und beendete den Mobilitätsdienst. Nannte sie eine bestimmte andere Care-of-Adresse, wurde nur dieser Eintrag gelöscht; die übrigen blieben aktiv.

Eine Lebensdauer ungleich null fügte die angeforderte Adresse hinzu. Bei unterstütztem S blieben frühere Zeilen bestehen, andernfalls wurden sie entfernt. Lief eine einzelne Bindung ab, musste der Heimatagent genau sie löschen und alle anderen nicht abgelaufenen gleichzeitigen Bindungen behalten.

Allein wegen eines Ablaufs sendete der Heimatagent keine neue Registration Reply. Der Besucherlisteneintrag beim Fremdagenten konnte natürlich auslaufen. Schweigen bewies daher nicht das Ende aller Wege, und das Entfernen eines Weges bewies keine vollständige Unerreichbarkeit.

Auch identische Wiederholungen hatten Grenzen. Stimmten Heimatadresse, Care-of-Adresse und Identification mit einer akzeptierten aktuellen Registrierung überein, durfte die neue Lebensdauer nicht über das ursprünglich gewährte Ende hinausreichen. Zuordnung und Replay-Schutz waren keine heimliche Verlängerung.

Spätere Spezifikationen machten die Pfade einzeln steuerbar

RFC 3344 erschien im August 2002 und ersetzte RFC 3220 in der mit RFC 2002 begonnenen Linie. RFC 5944 ersetzte ihn 2010, behielt jedoch Mehrfachregistrierung und eine Kopie pro aktiver Care-of-Adresse. Ein zur Dokumentpflege gehaltener redaktioneller Erratum und ein abgelehnter technischer Erratum ändern diese Regeln nicht.

Mobile IPv6 unterschied in RFC 3775 eine primäre Care-of-Adresse von einer vorübergehend behaltenen früheren Adresse. RFC 5648 führte Binding Identifiers für mehrere unabhängig verwaltete IPv6-Adressen ein. Der experimentelle RFC 7629 brachte solche Kennungen, mehrere Tunnel und Flussrichtlinien später auch in Mobile IPv4 ein.

Der Vergleich zeigt die Grenze des alten S-Bits. Es ordnete pauschale Kopien an, keine Pfadauswahl, Lastverteilung oder Gesundheitsprüfung. Eine alte Bindung konnte Redundanz liefern, Bandbreite verschwenden oder ins Leere führen. Der Kontrollzustand allein entschied das nicht.

Das belastbare historische Protokoll muss deshalb mengenförmig bleiben: Retentionswunsch, Fähigkeitsantwort, jede Adresse, jede Frist, jede Tunnelkopie und jede beobachtete Zustellung. Die neueste Adresse erhält durch ihr Alter kein Recht, alle Vorgänger als beendet auszugeben.

Quellen