Zusammenfassung

  • RFC 9868 schafft hinter den per UDP Length erklärten Nutzdaten einen Optionsbereich. Die zusätzlichen Bytes sind ein Erweiterungsumschlag, kein umgedeuteter Anwendungstext.
  • Scheitert eine Optionsprüfung, wird normalerweise der Umschlag verworfen und validierte Nutzdaten bleiben lieferbar. Eine strengere Folge muss die Anwendung oder ihre Bibliothek ausdrücklich festlegen.

UDP ist auch deshalb langlebig, weil es wenig behauptet. Sein Header führt Ports, Prüfsumme und Länge, aber keine Sitzung, keine Gegenstellenidentität und keinen Geschäftserfolg. RFC 9868, im Oktober 2025 veröffentlicht, nutzt eine vorhandene Eigenschaft: UDP Length kann vor dem Ende der IP-Nutzlast enden. Den Rest nennt das Dokument surplus area; dort liegen Transportoptionen.

Diese Lage ist eine Zuständigkeitsgrenze. Optionbytes werden nicht in die Anwendungsnachricht geschoben, und ihr Vorhandensein beweist keine Zustimmung der Anwendung zu einer neuen Semantik. UDP Length begrenzt weiterhin die Nutzdaten; für den Rest gelten eigene Analyse- und Integritätsregeln. Das RFC nennt dies eine weiche Steuerungsebene, stellt aber zugleich fest, dass UDP zustandslos und unidirektional bleibt und Optionen nur ein Rahmen, kein vollständiges Protokoll sind.

SAFE-Optionen dürfen von einem Empfänger, der sie nicht versteht, ignoriert werden, ohne Nutzdaten oder deren Bedeutung zu ändern. Ein optionsfähiger Empfänger ignoriert unbekannte oder fehlerhafte SAFE-Optionen still. UNSAFE-Optionen können Bedeutung ändern und unterliegen daher Einschränkungen: Sind sie vorhanden, müssen gewöhnliche UDP-Nutzdaten leer sein; die Transportnutzlast wird durch FRAG getragen.

Die Optionsprüfsumme schützt die surplus area getrennt von der UDP-Prüfsumme für die deklarierten Daten. Schlägt ihre Validierung fehl, muss der Empfänger alle Optionen ignorieren und den Überschuss verwerfen. Nutzdaten mit korrekter UDP-Prüfsumme müssen dennoch wie ohne Optionen geliefert werden. Das Ergebnis bezeugt also einen Fehler im Erweiterungsumschlag, nicht automatisch einen Fehler der Anwendungsnachricht.

Diese Voreinstellung ist absichtlich kompatibel. Außer bei Fragmenten führen fehlgeschlagene Optionsprüfsumme, Authentisierung oder Entschlüsselung nicht automatisch zum Unterdrücken eines empfangenen Pakets. Soll ein Fehler die Lieferung ändern, muss die Anwendung die Regel ausdrücklich überschreiben. Die Transportschicht kann einen Optionsfehler melden; sie kann nicht selbst entscheiden, ob Resolver, Telemetrieempfänger oder Steuerungssystem ansonsten valide Daten ablehnen soll.

Eine brauchbare Beobachtung trennt daher IP- und UDP-Länge, Optiontypen und Reihenfolge, Parsergebnis, gegebenenfalls OCS/APC/AUTH/UENC, Empfängerpolitik und Anwendungsergebnis. Ein Paket beweist weder Identität noch Berechtigung oder Erfolg. Auch Touchs Beitrag bleibt begrenzt: Sein IETF-Profil belegt technische Arbeit, RFC 9868 gemeinsame Autorschaft, nicht Kontrolle über jede Implementierung, Middlebox oder Anwendungspolitik.

Quellen