Zusammenfassung

  • RFC 1146 ließ Endpunkte mit Option Kind 14 in beiden SYNs exakt dieselbe alternative Prüfsumme wählen. Fehlt eine Option, unterscheiden sich die Werte oder ignoriert ein älterer Stack das unbekannte Feld, gilt für die gesamte Verbindung die Standardprüfsumme.
  • Die 32-Bit-Fletcher-Variante belegte im Datenverkehr zusätzlich Option Kind 15. SYN und RST blieben immer im Standardformat. RFC 4614 vermerkte später mangelndes Interesse; RFC 6247 setzte die Spezifikation auf Historic und die Optionsnummern auf obsolete.

Der Zusatz, der in jedem passenden Segment bezahlt wurde

Das bestehende TCP-Headerfeld konnte 16 Bits aufnehmen. Für den 8-Bit-Fletcher-Algorithmus aus RFC 1146 reichte es, weil dessen Ergebnis ebenfalls 16 Bits umfasste. Die 16-Bit-Fletcher-Berechnung erzeugte dagegen 32 Bits. Der A-Anteil kam in das normale Checksum-Feld, der B-Anteil in eine zusätzliche Alternate Checksum Data Option mit Kind 15.

Diese Option war nicht bloß ein Schild am Anfang der Verbindung. Sie begleitete die anwendbaren gewöhnlichen Segmente, sobald die lange Variante vereinbart war. Damit wurde aus einer Entscheidung in zwei SYNs ein fortlaufender Verbrauch knappen TCP-Optionsraums und eine weitere Parsing-Pflicht auf dem Datenpfad.

RFC 1146 behandelte falsche Verwendung streng. Eine Kind-15-Option mit falscher Länge oder in einem unpassenden Kontext sollte zum Verwerfen des Segments, zu einem RST und zum Abbruch der Verbindung führen. Nach vollzogener Wahl durfte Mehrdeutigkeit nicht tolerant weitergetragen werden: Beide Seiten mussten dieselben Bits nach derselben Regel lesen.

Die Platzrechnung zeigt deshalb mehr als Header-Ökonomie. Eine neue Prüfsumme war nicht mit dem Benennen eines Algorithmus erledigt. Sie veränderte Zustandsmaschine, Segmentformat, Fehlerpfad und Beobachtbarkeit.

Die Wahl stand in einem alten Umschlag

Vor jeder Wahl galt die TCP-Basis. RFC 793 definierte die TCP-Prüfsumme als 16-Bit-Einerkomplement über Header, Nutzdaten und Pseudoheader. RFC 9293 formuliert den heutigen Standard ohne Ausweichmöglichkeit: Ein Sender muss die Prüfsumme erzeugen, ein Empfänger muss sie prüfen.

Ein erster SYN konnte daher nicht schon unter einer unbekannten Alternative geschützt sein. Der Empfänger hätte die Botschaft, die ihm die neue Prüfregel erklärte, nicht zuverlässig lesen können. RFC 1146 legte die Alternate Checksum Request Option Kind 14 in einen SYN, dessen Integrität weiterhin die Standardprüfsumme sicherte.

Die alte Methode war damit nicht nur Fallback, sondern Bootstrapsprache. Erst nachdem ein gültiger Standard-SYN gelesen war, konnte ein Stack den Vorschlag erkennen. Die neue Regel erhielt ihre Legitimation durch einen Umschlag, den beide Seiten bereits öffnen konnten.

Auch nach der Wahl blieben SYN und RST bei der Standardprüfsumme. SYN trägt den Vorschlag, bevor Einigkeit existiert. Ein RST kann von einem Host ohne Verbindungszustand kommen; er darf nicht voraussetzen, dass der Absender ein früheres Ergebnis kennt. Der gemeinsame Ausgang blieb also in derselben Sprache wie der gemeinsame Eingang.

Zwei SYNs, ein identischer Wert

Kind 14 war drei Octets lang: Kind, Länge und Algorithmusnummer. RFC 1146 ordnete 0 der normalen TCP-Prüfsumme, 1 einem 8-Bit-Fletcher-Ergebnis von 16 Bits und 2 einem 16-Bit-Fletcher-Ergebnis von 32 Bits zu.

Eine Seite durfte einen Wert anbieten. Verwenden durften beide die Alternative aber nur, wenn der SYN der Gegenseite ebenfalls Kind 14 mit exakt derselben Nummer enthielt. Das Protokoll kannte kein Mehrheitsprinzip, keine Präferenzliste und kein nachträgliches Herunterhandeln zwischen zwei verschiedenen Alternativen.

Fehlte Kind 14 auf einer Seite oder unterschieden sich die Werte, benutzte die Verbindung vollständig den Standard. Ein voriges erfolgreiches Experiment, eine lokale Voreinstellung oder bloße Kenntnis der Optionsnummer schuf keine Zustimmung für diese Sitzung.

Diese Regel macht Paketbelege abgestuft. Ein Kind-14-Feld in einem SYN beweist ein Angebot. Zwei passende Felder beweisen die im RFC definierte Einigung. Erst die folgenden Segmente und ihre prüfbaren Werte belegen Verwendung. Wer nur nach Optionsnummern zählt, verwechselt Vorschlag mit Betrieb.

Unwissen wurde in einen sicheren Rückfall übersetzt

RFC 1122 verlangt, unbekannte TCP-Optionen mit Längenangabe ohne Fehler zu ignorieren. Ein älterer Stack musste Kind 14 deshalb nicht verstehen, um erreichbar zu bleiben. Er las den standardgeschützten SYN, übersprang die fremde Option und antwortete ohne passendes Angebot.

Der neue Stack interpretierte diese Abwesenheit nicht als stillschweigende Zustimmung. Er erkannte, dass die beiderseitige Bedingung fehlte, und blieb für die ganze Verbindung bei der Standardprüfsumme. Der alte Endpunkt musste weder einen Fehlercode kennen noch eine neue Zustandsvariable führen.

Das ist ein sorgfältiger Kompatibilitätsmechanismus: Unwissen erzeugt kein uneindeutiges Halbformat. Die Verbindung funktioniert, aber die Erweiterung bleibt aus. Genau dadurch können einseitige Upgrades gefahrlos sein.

Die gleiche Eigenschaft erschwert jedoch den Erfolg einer optionalen Erweiterung. Wenn nur eine Seite aktualisiert wird, sieht der Nutzer meist keinen Ausfall. Ohne gesonderte Telemetrie bleibt unsichtbar, dass die Alternative nie aktiviert wurde. Der robuste Rückfall nimmt dem Betreiber den natürlichen Alarm, der koordinierte Einführung erzwingen würde.

Das Standardfeld trug einen anderen Sinn

Bei Algorithmus 1 füllte das 16-Bit-Fletcher-Ergebnis das vorhandene TCP-Checksum-Feld. Bei Algorithmus 2 nahm dieses Feld nur Teil A auf; Teil B wanderte in Kind 15. Dasselbe Feld hatte somit abhängig vom vorherigen Handshake eine andere Berechnungssemantik.

Ein Paketanalysator darf den Zahlenwert deshalb nicht isoliert lesen. Er braucht die Richtung beider SYNs, die vereinbarte Algorithmusnummer, den Segmenttyp und bei der langen Variante die zusätzliche Option. Bei SYN oder RST gilt unabhängig vom Verbindungswunsch wieder der Standard.

Ein unvollständiger Mitschnitt kann den Handshake auslassen, der die spätere Interpretation festlegt. Das RFC definiert die Semantik; für ihren Nachweis braucht der Beobachter jedoch beide SYNs und die dazugehörigen späteren Segmente.

So wurde aus zwei Bytes mehr Ergebnis eine Zustandsabhängigkeit in jedem Werkzeug, das TCP korrekt deuten wollte. Der Preis lag nicht nur auf dem Draht, sondern in Testfällen, Diagnostik und Betrieb.

Eine Registry ist kein Nutzungszähler

Die IANA-TCP-Parameterregistratur führt Kind 14 und 15 weiterhin, heute mit dem Status obsolete. Eine eigene Tabelle bewahrt die Algorithmusnummern 0 bis 3: Standard, beide Fletcher-Varianten und Redundant Checksum Avoidance.

Diese Einträge sind für die Interpretation notwendig. Ohne sie könnte ein historischer Mitschnitt oder alter Quellcode nicht eindeutig gelesen werden. Ihre Fortdauer ist aber kein Beweis aktueller Implementierung, Verbreitung oder Empfehlung.

Die Registry beantwortet: Was bedeutete diese Nummer, und welchen Standardstatus hat sie? Sie beantwortet nicht: Wie viele Verbindungen haben sie gestern ausgehandelt? Diese zweite Frage braucht Endpunkt- oder Verkehrsdaten, die auch beide SYNs und die nachfolgenden Segmente erfassen.

Wer „bei IANA registriert“ mit „im Internet aktiv“ gleichsetzt, verwechselt Namensverwaltung mit Messung. Gerade obsolete Einträge müssen erhalten bleiben, damit alte Bits nicht neu und widersprüchlich belegt werden.

Das Experiment war nie eine Produktionsanweisung

Der mathematische Hintergrund der Standardprüfung war gut dokumentiert. RFC 1071 beschreibt Eigenschaften und Implementierungstechniken des Internet Checksum. Aus seinen Beispielen lässt sich jedoch keine Einführung von RFC 1146 ableiten; zudem mahnen gehaltene Errata an Beispielcode dazu, Berechnungshinweise nicht als Einsatzstatistik zu lesen.

RFC 1146 erschien im März 1990 als Experimental und empfahl ausdrücklich nicht den Einsatz in Produktionssystemen. Sein Wert lag in einer präzisen Versuchsanordnung: Algorithmuswahl, Rückfall, Segmentausnahmen und lange Datenoption waren festgelegt.

RFC 4614 beschrieb 2006 die TCP-Spezifikationslandschaft und notierte mangelndes Interesse an Alternate Checksum. Das ist eine begrenzte historische Aussage. Sie beweist weder, dass keine Implementierung existierte, noch dass Fletcher mathematisch untauglich war.

RFC 6247 setzte RFC 1146 im Jahr 2011 formell auf Historic und wies IANA an, die Optionsnummern 14 und 15 als obsolete zu markieren. Es stellte fest, die Mechanismen hätten keine breite Verbreitung erreicht. Die dort ausführlicher diskutierten Spoofing-Probleme betreffen T/TCP; sie dürfen nicht nachträglich als spezifischer Todesgrund von Alternate Checksum ausgegeben werden.

Der dokumentierte Schluss ist kleiner und belastbarer: Eine experimentelle, bilateral zu aktivierende TCP-Erweiterung gewann nicht genügend Interesse und Verbreitung, um aktuell zu bleiben. Die Standardsorganisation schloss ihren Status, ohne die historische Lesbarkeit der Nummern zu zerstören.

Der wiederkehrende Preis begann vor dem ersten Byte Daten

Kind 15 macht den laufenden Aufwand sichtbar, aber die erste Ausgabe war Koordination. Zwei Implementierungen mussten dieselbe Alternative anbieten, korrekt zwischen SYN/RST und normalen Segmenten unterscheiden, Optionen durch den Pfad bringen und Diagnosewerkzeuge mit derselben Zustandslogik ausstatten.

Der sichere Fallback verhinderte eine harte Netzteilung. Gleichzeitig lieferte jede einseitige Installation vor allem einen weiteren erfolgreichen Standard-Handshake. Ohne ein messbares Ziel und beidseitige Einführung konnte der Nutzen nicht kumulieren.

Diese Geschichte handelt daher nicht davon, dass zwei zusätzliche Bytes zu teuer gewesen wären. Sie zeigt, wie wiederkehrende Formatkosten, beidseitige Zustimmung und unsichtbarer Fallback zusammen eine Adoptionsschwelle bilden.

Die neue Prüfsumme musste sich mit der alten anmelden, weil nur die alte bereits gemeinsame Autorität besaß. Sie musste danach in jedem passenden Segment Platz mieten, weil längere Integrität nicht kostenlos in ein altes Feld passte. Als das Interesse ausblieb, blieb die alte Sprache zugleich Rettungsweg und Endzustand.

Quellen