Zusammenfassung

  • RFC 5177 kennt einen expliziten Modus mit Präfixen in der Mobile-IPv4-Registrierung und einen impliziten Modus, in dem der Home Agent sie etwa aus Konfiguration, AAA oder einem Routingprotokoll lernt.
  • Wird ein Präfix per Routingprotokoll über den Tunnel übertragen, soll es nicht zugleich in der Registrierungsanfrage stehen. Ein erfolgreicher Austausch verhindert sonst keine inkohärenten FIBs.

Ein Präfix kann zweimal korrekt eintreffen und dennoch einen falschen Betriebszustand erzeugen. Die Registrierungslogik sagt, welcher Mobile Router für ein Präfix autorisiert wurde und ob der Home Agent Forwarding eingerichtet hat. Das Routingprotokoll sagt, welche Topologie und welcher Pfad aktuell gelten. Beide Nachrichten können authentisch sein. Sie können sich trotzdem widersprechen.

Zwei Modi, zwei mögliche Autoritäten

Im expliziten Modus nennt der Mobile Router jedes Mobile Network Prefix in einer eigenen Erweiterung. Der Home Agent prüft die Zuordnung zur Home Address und antwortet für jedes Präfix. Im impliziten Modus fehlen diese Erweiterungen; Präfixwissen stammt aus statischer Konfiguration, AAA oder dynamischem Routing.

RFC 5177 empfiehlt den impliziten Modus, wenn ein Routingprotokoll die mobilen Netze über den bidirektionalen Tunnel meldet. Dasselbe Netz soll dann nicht zusätzlich in der Mobile-IPv4-Anfrage erscheinen. Der Grund ist nicht Eleganz, sondern die Vermeidung inkohärenter Forwarding Information Bases.

Damit benennt der Standard eine Governance-Frage: Welches System besitzt für welches Feld die Schreibautorität? Redundante Sichtbarkeit ist hilfreich. Redundante, unentschiedene Autorität ist es nicht.

Der obere Erfolgscode sieht den Konflikt nicht

Auch ohne doppelte Quellen enthält die Antwort zwei Ebenen. Pro Präfix kann sie Erfolg, ungültige Länge, fehlende Autorisierung oder gescheiterten Forwarding-Aufbau melden. Der Hauptcode wird bereits null, wenn mindestens ein Präfix erfolgreich eingerichtet wurde. Nur wenn alle scheitern, folgt HA_MOBNET_ERROR.

Ein grüner Hauptcode kann deshalb neben einem nicht autorisierten Präfix, einem Ressourcenfehler und einer veralteten Route stehen. Er beweist nicht, dass die Routingquelle zustimmte oder dass alle FIBs dasselbe Ergebnis installierten.

Die passende Darstellung ist eine Matrix: Präfix, Autorisierungsquelle, Registrierungsantwort, Routingquelle, installierte nächste Station, Gültigkeitsepoche und beobachteter Datenpfad.

Eine ausgelassene Zeile kann Forwarding abschalten

Bei der Aktualisierung einer bestehenden Bindung behandelt der Home Agent die explizite Präfixliste als Ersatzbestand. Ein bisher registriertes, nun fehlendes Präfix muss aus der Tabelle gelöscht und sein Forwarding deaktiviert werden.

Eine Routingmeldung könnte dieses Präfix gleichzeitig noch kennen. Dann ist nicht nur unklar, welches System aktueller ist; die Ebenen können tatsächlich verschiedene Zustände halten. Das Versäumnis liegt nicht im Tunnel, sondern in der unentschiedenen Autorität und fehlenden Epochensynchronisation.

Autorisierung, Installation und Reichweite

Die Mobile-IPv4-Authentisierung schützt die Anfrage, aber der Home Agent muss die Präfixberechtigung getrennt prüfen. Nach erfolgreicher Prüfung muss er Forwarding zur Care-of Address einrichten. Die Erreichbarkeit nach außen kann wiederum durch Aggregation oder Routenverbreitung entstehen.

Diese Schritte sind kumulativ, nicht austauschbar. Ein positiver Präfixcode ist ein starkes lokales Protokollzeugnis. Er ist kein Messwert für Routenverbreitung, Tunnelverkehr oder Anwendungserfolg.

Bei verschachtelten mobilen Netzen bleibt noch mehr außerhalb dieses Zeugnisses. Physische Schleifen werden nicht erkannt; jede Ebene fügt einen Tunnelkopf hinzu und senkt die nutzbare MTU. Ein formal korrekt eingerichtetes Präfix kann auf einem unbrauchbaren Pfad liegen.

Dynamische Zuteilung braucht dieselbe Quellenklarheit

RFC 6626 erlaubt eine Null im Prefix-Feld als Zuteilungsanfrage. Der Home Agent kann ein Präfix eigener Länge vergeben oder MOBNET_UNASSIGNED melden. Mehrere Anfragen sind zulässig, die Lebensdauer folgt dem Binding.

Auch hier darf die Rückgabe nicht unbemerkt mit einem parallel gelernten Routingbestand konkurrieren. Eine Zuteilung schafft einen kontrollierten Datensatz; sie beweist weder dessen Propagierung noch dessen Vorrang gegenüber einer anderen Quelle.

Der robuste Betrieb verlangt daher nicht weniger Automatisierung, sondern explizite Zuständigkeit: eine Quelle entscheidet über Mitgliedschaft, eine über Topologie, und Beobachtungen bestätigen den Pfad. Erfolgscodes bleiben wertvoll, solange sie nicht zu Eigentümern fremder Ebenen gemacht werden.

Quellen