Zusammenfassung

  • Data Offset markiert die physische Headergrenze; EOL beendet die logische Optionsliste.
  • NOP kann die nächste Option ausrichten, verpflichtet den Empfänger aber nicht zu einer Ausrichtung.

Zwei Arten von Ende

Ein Empfänger läuft oktettweise durch den Optionsbereich. Kind 1, NOP, verbraucht ein Oktett. Eine normale Option enthält Typ, Länge und Daten; die Länge umfasst Typ und Längenfeld und erlaubt es, auch eine unbekannte Option zu überspringen. Kind 0, EOL, beendet die Auslegung der bedeutungstragenden Optionen. Bis zur von Data Offset angegebenen Grenze bleibt Nullfüllung, keine Nutzlast.

RFC 793 beschrieb diese beiden Formate bereits 1981. RFC 9293 verlangt weiterhin für jede Option außer EOL und NOP ein Längenfeld, auch für künftige Optionen. Der Empfänger muss daher nicht jede Bedeutung kennen, wohl aber innerhalb des begrenzten Bereichs sicher weiterlaufen. Null- oder widersprüchliche Längen sind unzulässig und müssen defensiv behandelt werden.

Ausrichtung als Senderwahl

Ein Sender kann NOP einfügen, um eine folgende Option etwa an einer Wortgrenze beginnen zu lassen. Das ist eine Layoutentscheidung, keine Wire-Anforderung. Schon RFC 793 verlangte, nicht an Wortgrenzen beginnende Optionen zu akzeptieren; RFC 9293 macht dies weiterhin ausdrücklich. Eine allgemeine Geschwindigkeitsgarantie für NOP gibt es nicht.

EOL ersetzt Data Offset nicht, verkürzt den Header nicht und startet die Nutzlast nicht sofort. Es schließt nur die logische Liste. Steht EOL vor der physischen Grenze, müssen die restlichen Headerbytes null sein. Erreicht die Liste die Grenze von selbst, ist EOL nicht nötig.

Beständige Erweiterbarkeit

Die Kombination aus Längenfeldern, EOL und NOP bewahrt die Bytegrenzen, auch wenn neue Bedeutungen hinzukommen. Das ist die zentrale Kontinuität von RFC 793 zu RFC 9293.

Sources