Zusammenfassung

  • RFC 5149 definiert eine Service Selection Mobility Option für Mobile-IPv6-Binding-Updates.
  • Die Option bezeichnet den angeforderten Service-Kontext, sie gewährt ihn nicht.
  • Pro Binding Update ist höchstens eine Option erlaubt, nach MN-NAI, falls vorhanden, und vor Autorisierungs- oder Authentifizierungsoptionen.
  • Typ 20 enthält einen nicht leeren, NFKC-normalisierten UTF-8-Identifier mit 1 bis 255 Oktetten.
  • Der Identifier muss nur unter den Home Agents eindeutig sein, bei denen dieser mobile Knoten registrierungsberechtigt ist.
  • Der Home Agent authentifiziert den Knoten und prüft die Service-Berechtigung gesondert.
  • Nicht autorisierte Anfragen werden mit Status 151, SERVICE_AUTHORIZATION_FAILED, abgelehnt.
  • Ein Service-Wechsel erzwingt eine neue Autorisierung; ihr Fehlschlag kann das bestehende Binding löschen.
  • Auswahl kann Adresse, Präfix, Routing, Firewall, Sicherheit, Richtlinie und QoS beeinflussen, ohne deren Wirksamkeit zu belegen.
  • Ein Correspondent Node ohne gemeinsames Service-Wissen soll die Option stillschweigend ignorieren.
  • ESP kann den Identifier vertraulich übertragen, beweist aber weder Berechtigung noch Lieferung.
  • Registrierungsentscheid, Durchsetzung, Datenpfad, Abrechnung und Nutzerergebnis brauchen getrennte Belege.

Integrität beantwortet nicht die Abonnementfrage

Die Reihenfolge der Mobilitätsoptionen hat eine klare Funktion. Ist MN-NAI vorhanden, folgt darauf die Service-Auswahl; anschließend kommen autorisierungs- oder authentifizierungsbezogene Optionen. Damit kann die Sicherheitsverarbeitung die benannte Auswahl binden und Manipulationen erkennen.

Was sie nicht kann, ist die Wahrheit der Quelle zu beurteilen. Ein gültig geschütztes Update beweist unter dem jeweiligen Mechanismus Herkunft und Unversehrtheit. Es beweist nicht, dass die Abonnementdaten aktuell sind, dass der Katalogname auf die beabsichtigte Richtlinie zeigt oder dass der Vertrag den gewünschten Service umfasst.

Der Home Agent muss deshalb zwei Entscheidungen auseinanderhalten: Ist der mobile Knoten für die Registrierung authentifiziert und autorisiert? Und darf genau dieser Knoten den angegebenen Service nutzen? Erst die zweite Abfrage, typischerweise gegen das Subscription Profile, beantwortet die Service-Frage. Der Identifier liefert nur den Suchschlüssel.

Ein lokaler Name mit engem Drahtvertrag

Typ 20 transportiert ein bis 255 Oktette UTF-8, normalisiert nach NFKC. Der Wert darf nicht leer sein, und pro Binding Update darf er höchstens einmal vorkommen. Solche Grenzen sichern eine interoperable Syntax; sie errichten kein universelles Namensregister.

Der Service-Identifier muss nur zwischen den Home Agents eindeutig sein, bei denen dieser mobile Knoten registrieren darf. Sieht der Wert wie ein Domainname aus, folgt daraus weder DNS-Kontrolle noch globale Delegation. Exportiert ein Betreiber das Label in Abrechnung, Analytik oder Partnernetze, muss er seinen Verwaltungsraum mitführen, sonst kann derselbe Text verschiedene Dinge bezeichnen.

Fehlt die Option, behandelt der Home Agent die Anfrage als Wunsch nach gewöhnlichem Internetzugang. RFC 5149 empfiehlt nachdrücklich, diesen Standard zu erlauben, damit Grundzugang keine betreiberspezifische Konfiguration braucht. Es verpflichtet aber nicht dazu, ihn jedem Teilnehmer zu gewähren. Der Default ist eine Anfrageklasse, keine Verfügbarkeitszusage.

Status 151 kann den bisherigen Zustand mitnehmen

Scheitert die Service-Autorisierung, lehnt der Home Agent die Registrierung mit Status 151 SERVICE_AUTHORIZATION_FAILED ab. Bei einer erstmaligen Anfrage scheint das ein sauber abgegrenztes Nein zu sein. Bei einem Wechsel kann dieselbe Antwort einen bereits funktionierenden Pfad beenden.

Unterschiedliche Services können unterschiedliche Home Addresses oder Home Network Prefixes verlangen. Zeigt ein Update den Wechsel an, muss der Home Agent neu autorisieren. Bei einem Fehlschlag verweigert er nicht nur die neue Registrierung, sondern löscht auch ein Binding für die bestehende Adresse oder das bestehende Präfix. Der mobile Knoten muss nach Empfang von Status 151 das passende Binding ebenfalls entfernen.

Die Empfehlung, den alten Service vor der Registrierung des neuen abzumelden, verstärkt den Migrationscharakter. „Der neue Service wurde korrekt abgelehnt“ bedeutet nicht „der alte blieb verfügbar“. Dafür braucht es Belege über Ausgangszustand, Löschung, Ersatz-Binding, wiederhergestellte Route und Anwendungssitzung.

Policy-Ausgaben sind noch keine Wirkung

Eine akzeptierte Auswahl kann Adress- oder Präfixzuweisung, ausgehendes Routing, Firewall-Einstellungen, Sicherheitsregeln, andere Richtlinien und QoS beeinflussen. Ein erfolgreiches Binding Acknowledgement bestätigt jedoch nur den Registrierungsausgang beim Home Agent.

Ein zugewiesenes Präfix beweist keinen Rückweg. Eine erzeugte Firewall-Regel beweist nicht ihre Installation am Durchsetzungspunkt. Eine QoS-Klasse beweist keine gemessene Behandlung. Auch DNS, externe Filter, Zielanwendung und Abrechnung liegen außerhalb der Semantik dieser Option. Für jede Schicht ist ein Readback oder ein direkter Test nötig.

RFC 5149 warnt ausdrücklich, dass getrennte Verwaltungsdomänen mit strenger Ein- oder Ausgangsfilterung gleichzeitige Services beschränken können. Ein grüner Registrierungsstatus kann daher neben einem unerreichbaren Ziel oder einer verlorenen bisherigen Sitzung stehen.

Geteilte Wörter sind kein geteilter Zustand

Der mobile Knoten soll die Option normalerweise nicht an einen Correspondent Node senden, weil er gemeinsames Katalogwissen nicht voraussetzen kann. Ohne dieses Wissen soll die Gegenstelle die Option stillschweigend ignorieren. Nichtreaktion kann also spezifikationskonform sein.

Unter gemeinsamer Administration dürfen Home Agent und Correspondent Node denselben Katalog kennen und serviceabhängig handeln. Doch Katalogrevision, Subscription Cache, Policy-Compiler, Firewall und Forwarding Plane können auseinanderlaufen. Derselbe Name belegt nicht dieselbe installierte Wirkung.

Soll die Auswahl vertraulich bleiben, empfiehlt das RFC ESP im Transportmodus mit nicht-null Verschlüsselung für Binding Updates und Acknowledgements. Vertraulichkeit schützt die Beobachtbarkeit des Labels, nicht seine Berechtigung oder operative Richtigkeit. Umgekehrt beweist eine Autorisierung keine vertrauliche Übertragung.

IANA-Typ 20 und Status 151 sind stabile Koordinationspunkte, aber keine Inventarliste implementierter Home Agents. RFC 3775 wurde später durch RFC 6275 abgelöst. Dokumentenverweise zeigen technische Abstammung und Wiederverwendung, nicht heutige Unterstützung oder Interoperabilität.

Quellen

  1. RFC 5149, HTML
  2. RFC 5149, Text
  3. RFC-Editor-Eintrag
  4. IETF-Datatracker-Eintrag
  5. Verlauf von RFC 5149
  6. Referenzen zu RFC 5149
  7. Errata zu RFC 5149
  8. RFC 3775
  9. RFC 6275
  10. RFC 4877
  11. RFC 4283
  12. RFC 6089
  13. RFC 5778
  14. RFC 5779
  15. RFC 6097
  16. RFC 7222
  17. Minimum Initial Specification
  18. On Reality Layers
  19. Running-Code Primacy