Zusammenfassung

  • RFC 5142 definiert Mobility Header Typ 12, damit ein berechtigter Home Agent einen mobilen Knoten zum Wechsel auffordern kann.
  • Wann und welche Knoten verschoben werden, entscheidet nicht das Protokoll; Wartung oder Lastverteilung sind mögliche lokale Auslöser.
  • Die Nachricht kann eine geordnete Liste alternativer IPv6-Adressen oder eine leere Liste für eine eigenständige Home-Agent-Suche enthalten.
  • IPsec schützt Herkunft und Integrität der Nachricht, belegt aber weder Kapazität noch Aufnahme oder Datenpfad am Ziel.
  • Sendet der aktuelle Home Agent, dient das Binding Update zum Löschen der alten Bindung als Bestätigung.
  • Diese Bestätigung weist einen Austritt aus dem bisherigen Kontrollzustand nach, nicht die Ankunft im neuen Dienst.
  • Suche, Home Address, Sicherheitsbeziehungen, neue Bindung, Tunnel, Pakete und Anwendungsergebnis brauchen eigene Belege.
  • Ohne Antwort soll der alte Home Agent den Knotenzustand nicht erraten und bis zum Ende der Bindungslebensdauer weiterarbeiten.
  • Die Wechselrate benötigt Ressourcenrückmeldung vom neuen Agenten oder muss weit unter seiner Aufnahmefähigkeit liegen; Standardmaximum ist eine Nachricht pro Sekunde.
  • Ein Wechsel in ein anderes Home-Präfix kann die Home Address ändern und bestehende Verbindungen trotz korrekter Registrierung trennen.
  • Ein akzeptiertes Binding Acknowledgement bleibt ein Kontrollnachweis und ist kein Ende-zu-Ende-Beleg.
  • Führungskräfte sollten die Übergabe stufenweise steuern und den alten Pfad möglichst erhalten, bis der Ersatz durch Verkehr belegt ist.

Eine Frist koordiniert Risiko, sie beseitigt es nicht

Die Option Binding Refresh Advice kann dem mobilen Knoten anzeigen, wie lange die aktuelle Bindung noch besteht. Das Intervall wird in Vier-Sekunden-Einheiten angegeben. Für eine Betriebssteuerung ist das wertvoll: Die Beteiligten sehen, wann der letzte nachgewiesene Pfad verloren gehen könnte.

Doch eine übermittelte Frist ist kein Versprechen. Sie sagt nicht, dass in diesem Zeitraum ein alternativer Home Agent gefunden, eine neue IPsec-Beziehung ausgehandelt, ein Binding Update angenommen und ein Tunnel eingerichtet wird. Wird der Countdown auf einer Oberfläche als „Migration endet in“ dargestellt, erhält eine alte Ablaufzeit unverdient die Bedeutung eines neuen Fertigstellungstermins.

Die richtige Gegenüberstellung lautet: verbleibende Lebensdauer des alten Dienstes gegen die tatsächlich beobachtete Dauer jedes nachfolgenden Schritts. Wird der Puffer kleiner, muss die Steuerung neue Wechsel verlangsamen oder stoppen. Zeit ist hier Evidenz für eine Risikogrenze, nicht Evidenz für ein Ergebnis.

Der gemeinsame Befehl bleibt absichtlich schmal

Home Agent Switch trägt Mobility Header Typ 12. Ein Home Agent fordert einen mobilen Knoten auf, den derzeitigen Agenten nicht länger zu benutzen und einen neuen zu erwerben. Wartung, Lastverteilung, funktionale Verteilung und Renumbering gehören zu den genannten Szenarien. Die Entscheidung, wann und für welche Population der Wechsel sinnvoll ist, bleibt bei einem Backend oder einer lokalen Richtlinie.

Die Nachricht kann IPv6-Adressen alternativer Home Agents auflisten. Home Agent Preference bestimmt die Reihenfolge; gleich bewertete Kandidaten werden zufällig angeordnet. Kann der erste nicht dienen, probiert der Knoten den nächsten. Enthält die Liste keine Adresse, beginnt der Knoten eine Home-Agent-Suche.

Keiner dieser Einträge reserviert Ressourcen. Die Position in der Liste sagt weder, ob der Kandidat den Knoten autorisiert, noch ob er dasselbe Home-Präfix, ausreichend Rechenleistung oder einen brauchbaren Pfad besitzt. Die Nachricht macht Kandidaten interoperabel beschreibbar. Aufnahme bleibt eine spätere lokale Entscheidung.

Das entspricht einer minimalen gemeinsamen Spezifikation: gerade genug, um den nächsten Schritt auszulösen, aber nicht so viel, dass eine zentrale Darstellung die Verantwortung der beteiligten Systeme ersetzt.

IPsec schützt die Aussage, nicht ihre Prognose

Der Wechsel wird über die IPsec Security Association zwischen Home Agent und mobilem Knoten geschützt. ESP-Integrität ist erforderlich; Vertraulichkeit kann die Kandidatenliste verbergen. Auch ein Agent, der noch nicht der aktuelle ist, darf senden, wenn die passende Sicherheitsbeziehung besteht. Üblicherweise schlägt er sich selbst als Ziel vor.

Die kryptografische Schicht belegt den konfigurierten Absender und schützt die Bytes vor Veränderung und bestimmten Wiederholungen. Sie misst keine Warteschlange am Ziel, prüft keine aktuelle Aufnahmerichtlinie und sieht weder Routing noch Anwendung. Eine gültige Nachricht kann auf einer korrekten Beobachtung des alten Agenten und einer inzwischen veralteten Annahme über den neuen beruhen.

Deshalb sind vier Fragen getrennt zu protokollieren: Wer durfte senden? Welche lokale Evidenz löste den Wechsel aus? Welche Kapazitätsinformation rechtfertigte das Ziel? Welcher spätere Beobachter bestätigte den Dienst? Ein einziges Feld authentifiziert beantwortet nur die erste Teilmenge.

Eine Bestätigung beendet nicht automatisch die Übergabe

Kommt der Wechsel vom aktuellen Home Agent, beendet der mobile Knoten dessen Nutzung und sendet ein Binding Update zum Löschen der alten Bindung. Laut RFC 5142 wirkt dieses Update als Bestätigung der Switch-Nachricht. Damit hat der Sender einen belastbaren Beleg für die Verarbeitung seines Befehls bis zum Austritt.

Kommt die Nachricht dagegen von einem nicht aktuellen Home Agent, dient das Binding Update zur Anlage einer Bindung bei diesem Sender als Bestätigung. Ein Fall beschreibt Löschung an der Quelle, der andere einen Anlageversuch am vorgeschlagenen Ziel. Beide unter „bestätigt“ zusammenzufassen, zerstört die entscheidende Semantik.

Die alte Löschung kann eintreffen, bevor ein brauchbarer Kandidat existiert. Der neue Antrag kann abgelehnt werden. Ein positives Binding Acknowledgement kann vor vollständiger Tunnel- oder Routeninstallation eintreffen. Selbst ein funktionsfähiger Tunnel sagt noch nicht, ob eine bestehende Anwendung die Änderung überstand.

Ein überprüfbares Zustandsmodell benennt daher die Verben: Wechsel verifiziert, alte Bindung gelöscht, Kandidat gewählt, Sicherheit aufgebaut, neue Bindung angefragt, angenommen, Tunnel aktiv, erstes Paket beobachtet, Anwendungskontinuität geprüft. Der letzte nachgewiesene Zustand darf nicht durch einen bequemeren späteren Namen ersetzt werden.

Schweigen erlaubt keine Statusannahme

Der Sender wiederholt die Nachricht, bis das passende Binding Update eintrifft. Das Intervall startet bei fünf Sekunden, wächst exponentiell und ist bei zwanzig Sekunden gedeckelt. Danach kann der Agent mit geringerer Frequenz unbegrenzt fortfahren.

Wenn die maximale Wartezeit abläuft und die alte Bindung noch existiert, soll der Home Agent den Zustand des mobilen Knotens nicht ableiten. Er soll den Dienst bis zum Ablauf der Bindung weiterführen. Die Norm schützt damit den letzten bekannten Pfad vor einer Schlussfolgerung aus fehlender Sichtbarkeit.

Schweigen kann Nachrichtenverlust, Verlust der Rückantwort, einen ausgefallenen Knoten, erfolglose Suche, verzögerten Schlüsselaustausch, Ablehnung oder lokale Untätigkeit bedeuten. Das Symptom wählt keine Ursache. Auch der spätere Ablauf der Bindung belegt nur das Ende des alten Zustands, nicht den Aufbau eines neuen.

Der mittlere Teil ist die eigentliche Migration

Die Mobile-IPv6-Dokumente zur Bootstrap-Phase trennen Home-Agent-Adresse, Home Address sowie Berechtigungsdaten und IPsec-Sicherheitsbeziehungen. RFC 5026 strukturiert diese Anforderungen. RFC 6610 und RFC 6611 stellen Mechanismen für Suche oder Bereitstellung bereit. RFC 4640 beschreibt das zusammengesetzte Bootstrap-Problem.

Die Switch-Nachricht erledigt davon nichts automatisch. Der Knoten muss einen zulässigen Kandidaten entdecken oder wählen, Adresskontinuität klären, IKE/IPsec aufbauen, ein neues Binding Update senden und einen akzeptablen Status erhalten. Danach folgen Tunnel und Routing, reale Pakete und schließlich die gewünschte Dienstwirkung.

Jeder Übergang braucht einen eigenen Beleg mit Zeit, Identität und Ergebnis. Ein früher Nachweis bleibt gültig, darf aber keine spätere Realität vertreten. Genau hier diszipliniert laufender Code die symbolische Macht des Kontrollobjekts.

Ein anderes Home-Präfix verdient einen gesonderten Abbruchpfad. Es kann eine neue Home Address erzwingen und bestehende Verbindungen verlieren lassen. RFC 5142 rät vom Einsatz in dieser Situation ab und empfiehlt für Lastverteilung Agenten mit denselben Präfixen. Registrierungserfolg und Kontinuität können deshalb gleichzeitig wahr und falsch sein, je nachdem, welche Aussage gemeint ist.

Aufnahmeleistung muss den Takt setzen

Der alte Agent kann Nachrichten billiger erzeugen, als das Ziel kryptografische Aushandlungen, Bindungen und Tunnel aufbauen kann. RFC 5142 verlangt deshalb eine Rückkopplung zwischen Ressourcen des neuen Home Agents und weiteren Wechseln oder eine Obergrenze, die weit unter dessen Registrierungsfähigkeit liegt. Standardmäßig gilt höchstens eine Nachricht pro Sekunde.

Dieser Wert ist kein Produktionsziel. Steigende IKE-Zeiten, Binding-Ablehnungen, Tunnelverzögerungen oder Zeiten bis zum ersten Paket müssen die Rate reduzieren. Das Ziel benötigt eine wirksame Möglichkeit, den Zufluss zu stoppen, bevor Lastverteilung zur Lastverschiebung wird.

Auch ein gesundes Ziel kann einen Pfad mit anderer Latenz, Verlustquote oder Reihenfolge liefern. Dann gelingt die Kontrolle und der Transport leidet. Eine Kampagne muss deshalb den Zweck messen, der ihren Auslöser rechtfertigte, nicht nur die Anzahl erzeugter Bindungen.

Quellen

  1. RFC 5142, HTML
  2. RFC 5142, Textfassung
  3. Eintrag beim RFC Editor
  4. IETF Datatracker
  5. Dokumenthistorie
  6. Errata-Suche für RFC 5142
  7. IANA Mobility Parameters
  8. RFC 3775: Mobility Support in IPv6
  9. RFC 6275: Mobility Support in IPv6
  10. RFC 4301: IP Security Architecture
  11. RFC 4303: Encapsulating Security Payload
  12. RFC 4877: Mobile IPv6 mit IKEv2 und IPsec
  13. RFC 5026: Mobile-IPv6-Bootstrapping
  14. RFC 6611: Bootstrapping im integrierten Szenario
  15. RFC 6610: DHCP-Optionen zur Home-Information-Suche
  16. RFC 4640: Problemstellung des Mobile-IPv6-Bootstrappings
  17. RFC 4192: Renumbering von IPv6-Netzen
  18. Minimale Anfangsspezifikation, lokale Zukunftsentscheidung und freiwillige Annahme
  19. Realitätsebenen, symbolische Macht und Klarheit
  20. Vorrang von Running Code