Kompatibilität verbarg die Kosten. RFC 1263 wollte die Versionsgrenze sichtbar machen

Zusammenfassung

• RFC 1263, ein Informational Memo vom Oktober 1991, wandte sich gegen die damals in RFC 1072 und RFC 1185 vorgeschlagenen rückwärtskompatiblen TCP-Erweiterungen. Statt immer neue Funktionen in denselben Header zu packen, stellte es einen Weg zur expliziten Protokollversionierung zur Diskussion.
• Kompatibilität konnte die schrittweise Verbreitung erleichtern, ohne alle Systeme gleichzeitig umzustellen. Sie machte Änderungen jedoch nicht kostenlos: Nach Auffassung der Autoren konnte die Komplexität in einem einzigen Protokoll anwachsen. Das Memo formuliert eine Entwurfshypothese; es belegt weder Implementierung noch Einsatz des Vorschlags.

Die Rechnung endete nicht am Header

Der Titel von RFC 1263 klingt wie eine pauschale Absage an Erweiterungen. Der wichtigere Gedanke betrifft den Ort, an dem ein System die Kosten des Wandels trägt. Ein altes Paketformat bleibt erhalten, neues Verhalten kommt in den Optionsbereich, und ein sichtbarer Bruch scheint vermieden. Doch Aufwand kann in Aushandlung, Parser-Zweige, begrenzten Optionsraum, Wechselwirkungen und dauerhafte Implementierungspflichten wandern.

Das Memo vergleicht drei Wege: ein neues Protokoll schaffen, das bestehende rückwärtskompatibel erweitern oder es ohne Erhalt des alten Drahtformats weiterentwickeln. Ein neues Protokoll braucht eine Schnittstelle und genügend Verbreitung. Eine kompatible Erweiterung kann sich im Tempo einzelner Systeme ausbreiten, ohne synchron verteilt zu werden. Eine freiere Evolution muss den Übergang zwischen Versionen ausdrücklich regeln.

Die Autoren behaupten nicht, Kompatibilität sei nutzlos. Sie warnen davor, ihren Nutzen mit Kostenfreiheit zu verwechseln. Was sich leicht in einen Header einfügen lässt, kann schwer verständlich und wartbar werden, wenn Optionen und Kombinationen zunehmen. Zwei Versionen bedeuten zudem nicht zwangsläufig zwei unverbundene Entwürfe: Eine gemeinsame Infrastruktur kann die passende Version auswählen.

TCP als Fallstudie

Die Beispiele waren TCP-Vorschläge für Pfade mit hoher Verzögerung oder hohem Durchsatz aus RFC 1072 und RFC 1185. RFC 1072 behandelte unter anderem Window Scaling, selektive Bestätigungen und Echo-Zeitstempel; RFC 1185 untersuchte Erweiterungen für Hochgeschwindigkeitspfade. RFC 1263 stellte nicht nur deren Ziele infrage, sondern auch die Strategie, neue Semantik über Optionen in dasselbe TCP einzubauen und dabei die Kompatibilität zu erhalten.

Der Gegenentwurf skizzierte einen größeren, aber klarer strukturierten Header mit einer Protokollkennung für verschiedene TCP-Versionen. Sequenz- und Bestätigungsnummern sollten auf 64 Bit, das Fenster auf 32 Bit wachsen; Echo-Felder kämen hinzu. Systeme ohne Bedarf könnten beim bisherigen TCP bleiben, während geeignete Endpunkte über eine Auswahlsschicht eine andere Version nutzten.

Das Memo beschrieb mehrere Kompatibilitätsstufen: das alte TCP unverändert lassen und eine separate Version auswählen; für Anhänger eines monolithischen Protokolls eine TCP-VERSION-Option im SYN aushandeln; oder die neuen Informationen in eine Option packen, um die Headerform zu bewahren. Je mehr Kompatibilität der Entwurf erhalten wollte, desto mehr geerbte Beschränkungen nahm er mit.

Vielleicht wurden ohnehin zwei Versionen gepflegt

RFC 1263 vermutete, dass viele Systeme wahrscheinlich ohnehin zwei TCP-Versionen würden pflegen müssen. Die Wahl lautete deshalb nicht schlicht „ein Protokoll oder zwei“. Sie lautete: ein Protokoll mit immer mehr bedingtem Verhalten oder eine sichtbare Versionsgrenze, anhand derer Infrastruktur auswählen kann.

Zwei einfache Protokolle könnten günstiger zu warten sein als ein komplexes, schrieb das Memo; zwei Kopien benötigten allerdings zusätzlichen Speicher. Das sind Entwurfsurteile, keine Messwerte. Eine vergleichende Studie realer Implementierungen enthält die Quelle nicht. Sie beweist auch nicht, dass Versionswahl oder Protokollverteilung die Einführungskosten gesenkt hätten.

Kompatibilität kann alte Systeme weiterarbeiten lassen, während neue Funktionen sich verbreiten. Sie hat aber eine eigene Betriebsfläche: Aushandlung, Parsing-Regeln, begrenzten Optionsraum, Wechselwirkungen und langfristige Wartung. Eine Versionsgrenze macht diese Aufgaben sichtbarer, schafft zugleich aber Arbeit für Auswahl, Verteilung und Unterstützung.

Eine neue Grenze verlagert die Koordination

Ein Auswahlmechanismus beseitigt Koordination nicht. Er muss verfügbare Versionen kennen, beide Endpunkte brauchen eine gemeinsame Wahl, und alte Systeme dürfen keinen unverständlichen Header erhalten. Eine Versionskennung macht den Unterschied für Protokollsoftware sichtbar; sie beweist nicht, dass Zwischenstationen oder Betreiber korrekt damit umgehen.

RFC 1263 verlangte, solche Kosten mit der Wartung immer komplizierterer kompatibler Erweiterungen ehrlich zu vergleichen. Die Autoren wollten Protokollverteilung als Infrastruktur behandeln, die durch Wiederholung besser wird, statt als seltenes Ereignis, das dauerhaft im bestehenden Protokoll versteckt bleibt. Das ist eine Aussage über technische und institutionelle Anreize, nicht nur über Bitfelder.

Das Memo ist jedoch kein neutrales Kostenmodell. Die Autoren bevorzugten einfachere Protokolle und schnellere Weiterentwicklung und kritisierten das damalige Standardisierungsverfahren scharf. Es zeigt weder, dass dieses Verfahren der entscheidende Änderungshemmnis war, noch dass der eigene Verteilungsansatz funktioniert hätte. Die bleibende Frage lautet: Wer zahlt, wenn Kompatibilität verspricht, niemand müsse sich abstimmen?

Was die Quelle belegt

RFC 1263 ist Informational. Das Memo vergleicht Protokollneuschöpfung, kompatible Erweiterung und Evolution und kommentiert Vorschläge. Es legt keinen endgültigen TCP-Standard fest, dokumentiert keine abgeschlossene Migration, weist keine eingesetzte Versionsauswahlschicht nach und misst nicht die Kosten paralleler Stacks. Der vergrößerte Header und die Versionsauswahl bleiben Vorschläge in diesem Dokument.

Die historische Lehre lautet nicht, dass Rückwärtskompatibilität schlecht sei. Sie kann wertvoll sein, weil alte Systeme während der Verbreitung neuer Funktionen weiterarbeiten. Ein vertrautes Drahtformat ist aber kein kostenloser Behälter für jede künftige Anforderung. Eine sichtbare Versionsgrenze kann Pflichten klären, entscheidet allein jedoch nicht, welcher Weg günstiger ist.

Quellen und Grenzen

Diese Analyse stützt sich auf RFC 1263, TCP Extensions Considered Harmful, den RFC-Editor-Eintrag, RFC 1072, TCP Extensions for Long-Delay Paths und RFC 1185, TCP Extensions for High-Speed Paths. Die Primärquellen belegen den Vergleich der Änderungswege, die diskutierten TCP-Vorschläge, die Optionen für eine Versionswahl und die Aussagen der Autoren zu Komplexität, Speicher- und Verteilungskosten.

Sie belegen weder, dass der RFC-1263-Gegenentwurf implementiert oder ausgewählt wurde, noch dass er in der Praxis günstiger war oder spätere TCP-Entwürfe bestimmte. Die mögliche Verlagerung von Kosten in Komplexität ist das Argument des Memos und die Interpretation dieses Vergleichs, keine gemessene Betriebskostenbilanz.