Zusammenfassung

  • RFC 3025 nannte 37 für CVSE und 133 für NVSE. IANA hatte 38 und 134 vergeben. RFC 3115 erklärte das Februar-Dokument im April für überholt, weil damalige Implementierungen den IANA-Zuweisungen folgten.
  • Die äußere Typnummer bestimmte die Fehlerpolitik: Ein unbekannter Typ unter 128 verwarf die ganze Nachricht; ab 128 ließ sich die Erweiterung überspringen und der Rest weiterverarbeiten.

Zwei Zahlen trennten Text und Leitung

Ein Mobile Node sendet eine Registrierungsanforderung. Der Foreign Agent empfängt sie, kennt aber die erste Erweiterung nicht. Liegt deren Typ im unteren Zahlenbereich, endet die Verarbeitung. Das Datagramm wird ohne Fehlermeldung an den Absender verworfen. Liegt der Typ im oberen Bereich, liest der Parser die Länge, springt über die fremden Bytes und macht weiter.

Diese Verzweigung war älter als RFC 3115. RFC 2002 hatte die Mobile-IP-Erweiterungen in 0–127 und 128–255 geteilt. Unbekanntes im unteren Bereich war nicht überspringbar. Unbekanntes im oberen Bereich durfte ignoriert werden, während die restliche Nachricht verarbeitet werden musste.

Im Februar 2001 definierte RFC 3025 zwei Behälter für hersteller- oder organisationsspezifische Daten. Die Critical Vendor/Organization-Specific Extension, CVSE, trug dort Typ 37. Die normale NVSE trug 133. Im IANA-Repository standen dagegen 38 und 134.

RFC 3115 legte den Widerspruch im April offen und ersetzte RFC 3025. Die Begründung war ungewöhnlich knapp und operativ: Gegenwärtige Implementierungen folgten den IANA-Zuweisungen.

Die Quellen nennen weder Produkte noch Versionen oder Verbreitungszahlen. Sie belegen keinen konkreten Ausfall. Deshalb ist die Aussage begrenzt: Nicht jede Implementierung ist nachgewiesen, aber das beobachtete Verhalten war stark genug, um den Standards-Eintrag zu ändern.

Kritisch hieß: Unwissen entwertet die Nachricht

CVSE 38 lag im nicht überspringbaren Bereich. NVSE 134 lag im überspringbaren. „Kritisch“ bezeichnete nicht den geschäftlichen Wert der privaten Daten. Es war die Zusage des Senders, dass die restliche Nachricht ohne diese Bedeutung nicht sicher ausgewertet werden dürfe. „Normal“ sagte, dass die private Funktion fehlen könne, ohne alles andere zu vernichten.

37 und 38 lagen beide unter 128; 133 und 134 lagen beide darüber. Der Fehler tauschte die grundlegende Politik also nicht aus. Er verhinderte die exakte Erkennung. Ein Empfänger, der nur 38 kannte, behandelte 37 als anderen unbekannten kritischen Typ und ließ die ganze Anforderung verschwinden. Ein Empfänger, der 134 erwartete, konnte 133 überspringen und scheinbar erfolgreich fortfahren, obwohl die private Funktion nie verarbeitet wurde.

Der erste Fall sieht von außen wie Paketverlust aus. Der zweite kann wie ein unvollständiger Erfolg aussehen. Ein einziges Erfolgsfeld erklärt keinen von beiden. Benötigt werden das empfangene Byte, die Parser-Konstante und die gewählte Verzweigung.

„Silently discard“ war ebenfalls nicht gleichbedeutend mit Beweisvernichtung. Der Empfänger sollte keine weitere Verarbeitung und keine Rückmeldung vornehmen, aber den Fehler samt verworfenem Datagramm protokollieren und zählen können. Auf der Leitung herrschte Schweigen; im Betrieb sollte eine Spur bleiben.

Erkennung geschah außen und innen

RFC 3115 unterschied zwei Arten des Nichtwissens. Ein Empfänger konnte den äußeren Typ 38 überhaupt nicht erkennen. Oder er erkannte die CVSE-Struktur, verstand danach aber Vendor/Org-ID oder Vendor-CVSE-Type nicht.

Im ersten Fall griff die allgemeine Regel für 0–127: stilles Verwerfen. Im zweiten Fall konnte der Parser bereits Felder lokalisieren. Eine Request mit erkanntem CVSE-Behälter und nicht unterstützter Organisation oder Unterart musste deshalb ausdrücklich abgelehnt werden.

Bei einer Reply kam die Rolle hinzu. Ein Transitknoten, der sie noch weiterleiten sollte, musste eine Ablehnung in Richtung des nächsten Teilnehmers erzeugen. Ein Endempfänger behandelte die Reply als abgelehnt. Bei NVSE wurde ein unbekannter innerer Hersteller oder Subtyp übersprungen und die Verarbeitung fortgesetzt.

Ein Logeintrag „unknown vendor extension“ verwischt diese Grenzen. Er muss äußeren Typ, Parser-Version, Behältererkennung, Enterprise Number, Subtyp, Richtung, Knotenrolle, Längenprüfung, Drop/Skip/Reject und erzeugten Code enthalten. Eine veraltete äußere Konstante ist nicht dasselbe wie eine fehlende private Fähigkeit.

Eine Enterprise Number vergab Namen, keine Vollmacht

Beide Formate enthielten eine vier Oktette lange Vendor/Org-ID. Das höchste Oktett war null; die unteren drei trugen den SMI Network Management Private Enterprise Code. Innerhalb dieses Raums verwaltete die Organisation einen zwei Oktette langen Subtyp und dessen Wert.

Damit war Verantwortung verteilt. IANA vergab äußere Mobile-IP-Typen und Fehlercodes. Das Enterprise-Register ordnete den privaten Namensraum zu. Die Organisation definierte Untertypen. Der Sender wählte Instanzen aus. Der Empfänger implementierte ausgewählte Semantik. Mobile-IP-Sicherheitsbeziehungen authentisierten Nachrichten, wo das Basisprotokoll es verlangte. Lokale Policy entschied weiterhin über den Dienst.

Eine Enterprise Number authentisierte keinen Absender. Eine authentisierte Nachricht erklärte keinen unbekannten Subtyp. Erkennung war keine Autorisierung. Akzeptierte Registrierung belegte noch keinen funktionierenden Nutzerdatenverkehr.

Mehrere CVSE- und NVSE-TLVs durften nach dem festen Nachrichtenteil stehen. Zwischenknoten sollten ihre Reihenfolge nicht verändern. Eine nachträgliche Sortierung kann die Bytefolge verlieren, die der Authenticator schützte, der Sender erzeugte und nachgelagerte Parser sahen.

Der Sicherheitsabschnitt nahm an, dass Mobile-IP-Nachrichten nach dem Basisprotokoll authentisiert würden, und stellte keine zusätzlichen Anforderungen. Das ist eine Spezifikationsannahme, kein Beweis für jeden Einsatz. Authenticator-Ergebnis, semantische Unterstützung und lokale Erlaubnis bleiben getrennte Tatsachen.

Vier Fehlercodes zeichneten den Weg durch drei Rollen

100 und 101 waren Ablehnungen des Foreign Agent. Code 100 betraf unbekannte kritische Daten vom Mobile Node, 101 solche vom Home Agent. 140 und 141 waren Ablehnungen des Home Agent und unterschieden wiederum Herkunft vom Mobile Node oder Foreign Agent.

Die Codes lokalisierten den interpretierenden Knoten und einen Teil der Provenienz. Sie erklärten nicht den privaten Geschäftswert, belegten nicht die Zustellung der Ablehnung an den Mobile Node und bewiesen keinen späteren Diensterfolg.

Ein Foreign Agent konnte als Transit eine vom Home Agent kommende Reply verstehen, am inneren CVSE scheitern und daraus eine neue Ablehnung für den Mobile Node machen. Das Home-Agent-Log allein zeigte dann keinen Endzustand; das Mobile-Node-Log zeigte nur die Ablehnung. Erst Eingabe, Entscheidung und Ausgabe jedes Hops ergeben die Kette.

Das Online-Register wurde aktive Infrastruktur

RFC 1700 war 1994 eine statische Momentaufnahme der Assigned Numbers. RFC 3232 erklärte 2002, dass IANAs Online-Datenbanken diese Reihe ersetzt hatten und RFC 1700 unvollständig, teilweise falsch geworden war. RFC 3115 erlebte diese institutionelle Veränderung bereits auf dem Draht.

Ein lebendes Register konnte Zuweisungen zeitnah abbilden. Ein RFC konnte Struktur, Rollen und Fehlerpfade ausführlich beschreiben, fror aber einen Publikationsstand ein. Keines genügte allein. IANA kannte 38 und 134, nicht die gesamte Verarbeitungslogik. RFC 3025 kannte die Logik, druckte aber andere Werte.

Das heutige Mobile IPv4 Numbers Register führt CVSE 38, NVSE 134 und die vier Fehlercodes mit RFC-3115-Referenz. Es beweist den aktuellen Stand, nicht jede historische Änderung. Für den Konflikt von 2001 bleiben beide RFCs unverzichtbar.

Spätere Spezifikationen beweisen Nutzung, nicht Verbreitung

RFC 4332 definierte Cisco-Erweiterungen für Heimnetzpräfix, Gateway, DNS, DHCP und Konfigurations-URL. RFC 4784 beschrieb drei Verizon-Wireless-Erweiterungen mit Typ 38 und Enterprise Number 12951 für eine dynamische Schlüsselaktualisierung in cdma2000-Netzen.

Das sind bestimmte, veröffentlichte Anwendungsfälle. Sie messen keine Installationen, Pakete, Interoperabilitätserfolge oder Marktanteile. Eine normative Anforderung ist kein Laufzeitnachweis.

RFC 5612 reservierte später Enterprise Number 32473 für Dokumentationsbeispiele. Selbst fiktive Daten brauchten einen Raum, der nicht mit einer realen Organisation kollidiert. RFC 6709 verallgemeinerte das Risiko: Private Erweiterungen schaffen Flexibilität, doch schwache Prüfung und unklare Behandlung unbekannter Werte erzeugen Interoperabilitäts-, Sicherheits- und Betriebsprobleme.

RFC 3115 hatte die Kosten bereits konkret gemacht. Unkenntnis des kritischen Behälters verlor die Nachricht; Unkenntnis des normalen verlor eine Funktion. Die Nummernkorrektur stellte den gemeinsamen Preis der Unwissenheit wieder her.

Laufender Code war Zeuge, nicht oberstes Gericht

Die Episode besagt nicht, dass Implementierungen immer recht haben. Code kann Fehler enthalten; Register und RFCs können sich ändern. Die Entscheidung war enger: Der Text widersprach der Zuweisungsinstanz, und der Ersatz dokumentierte, dass Implementierungen der Instanz folgten.

Ein Mitschnitt beweist Versand, nicht Interpretation. Ein Parser-Log beweist eine lokale Entscheidung, nicht Registrierungserfolg. Ein Fehlercode beweist einen Protokollschritt, nicht das Nutzerergebnis. „Current implementations“ ist stärker als Entwurfsabsicht und schwächer als eine vollständige Erhebung.

Mit diesen Grenzen bleibt die Geschichte klar. RFC 3025 schrieb 37 und 133. IANA vergab 38 und 134. Das laufende Netz sprach bereits das zweite Paar. RFC 3115 löschte die Norm nicht; es korrigierte sie anhand der getrennt erhaltenen Betriebsbeweise.

Quellen

  1. https://www.rfc-editor.org/rfc/rfc3115.txt
  2. https://www.rfc-editor.org/rfc/rfc3025.txt
  3. https://www.rfc-editor.org/rfc/rfc2002.txt
  4. https://www.rfc-editor.org/rfc/rfc1700.txt
  5. https://www.rfc-editor.org/rfc/rfc2119.txt
  6. https://www.rfc-editor.org/rfc/rfc2344.txt
  7. https://www.rfc-editor.org/rfc/rfc2356.txt
  8. https://www.rfc-editor.org/rfc/rfc3232.txt
  9. https://www.rfc-editor.org/rfc/rfc3344.txt
  10. https://www.rfc-editor.org/rfc/rfc4332.txt
  11. https://www.rfc-editor.org/rfc/rfc4784.txt
  12. https://www.rfc-editor.org/rfc/rfc5612.txt
  13. https://www.rfc-editor.org/rfc/rfc5944.txt
  14. https://www.rfc-editor.org/rfc/rfc6709.txt
  15. https://www.iana.org/assignments/mobileip-numbers/mobileip-numbers.xml