Zusammenfassung

  • RFC 938 schreibt für ein DATA-Paket im Acknowledgement-Fenster mit unbekanntem Zielport ein PORT NAK vor: Der Empfänger meldet sein aktuelles rcv_nxt zurück und verwirft die Daten.
  • Damit wird die kumulierte Paketaufnahme bis zu dieser Sequenzgrenze bestätigt; abgewiesen wird die Portnummer. Über Annahme, Prüfung, Autorisierung oder Speicherung durch eine Anwendung sagt das nichts aus.

Der Name Internet Reliable Transaction Protocol klingt größer als die Zusage, die RFC 938 tatsächlich macht. Seine aufschlussreichste Passage ist gerade keine Vollendungsgarantie. Sie erklärt, dass PORT NAK die Portnummer ablehnt, nicht die Paketnummer. Ein Host kann also einen wahren Befund über seine Empfangsfolge behalten, während er offenlegt, dass die lokale Adresse der Nutzdaten keinen Besitzer hat.

Der RFC ist laut seiner Informationsseite von Februar 1985 experimental/proposed. Er belegt daher einen Entwurf, keine Verbreitung, kein gemessenes Verkehrsaufkommen und keine heutige Nutzung. RFC 791 begrenzt die Einordnung weiter: Das IP-Feld Protocol bezeichnet das Protokoll der nächsten Ebene. Das IANA-Register führt Nummer 28 als IRTP mit Verweis auf RFC 938. Das ist Namensraumkoordination, keine Betriebsstatistik.

Zwei Fragen in einem kurzen Header

Der acht Oktette lange IRTP-Header enthielt Typ, Portnummer, Sequenznummer, Länge und Prüfsumme. Definiert waren SYNCH, SYNCH ACK, DATA, DATA ACK und PORT NAK. Die Sequenznummer gehörte zum zuverlässigen Verhältnis zwischen Hosts. Der Port stand für das höhere Protokoll oder den lokalen Prozess, an den die Daten gehen sollten.

Ein Prozess durfte mehrere Ports beanspruchen, ein bestimmter Port aber nur einen Prozess haben. Zugleich war eine IRTP-Verbindung nach entfernter Internetadresse organisiert, nicht nach jedem Host-Port-Paar. Die Verbindungstabelle führte etwa snd_nxt, rcv_nxt und snd_una; SYNCH und SYNCH ACK stellten diesen Host-zu-Host-Zustand her oder synchronisierten ihn neu. Der Port benannte die verlässliche Beziehung nicht. Er wurde erst bei der lokalen Demultiplexfrage relevant.

Die Empfangsfolge hält die Trennung fest. Für DATA prüfte das Modul zunächst die Acknowledgement-Window. Nur für ein dort liegendes Paket berechnete es rcv_nxt neu und fragte danach, ob der Port bekannt war. Beim bekannten Port durfte nach DATA ACK für den Nutzerprozess eingereiht werden. Beim unbekannten Port ging PORT NAK mit aktuellem rcv_nxt zurück; die Daten wurden verworfen.

Beide Antworten tragen deshalb eine Aussage über die Sequenzgrenze, aber nur eine über die erfolgreiche Portzuordnung. RFC 938 sagt ausdrücklich, dass PORT NAK den Empfang aller Paketnummern bis zur Nummer im Sequenzfeld bestätigt. Das NAK gilt dem Port. Es verlangt keine Wiederholung dieser Paketnummer und eröffnet keiner Anwendung einen Empfangsvorgang.

Eine Quittung hat nicht die Vollmacht der nächsten Schicht

Ein solcher Trace stützt zwei eng begrenzte Aussagen: Das IRTP-Modul behandelte das Paket in seinem relevanten Empfangsbereich und berichtete eine kumulierte rcv_nxt-Grenze; zu diesem Zeitpunkt kannte es keinen Prozess, der den Port beansprucht hatte. Daraus folgt weder, dass eine Anwendung Bytes las oder verstand, noch dass eine Identität geprüft, eine Aktion autorisiert, ein Datensatz gespeichert oder ein Vorgang abgeschlossen wurde. Auch eine dauerhafte Abwesenheit des Dienstes folgt nicht.

Sequenzempfang, Port-Claim und Anwendungsergebnis müssen als verschiedene Evidenzobjekte geführt werden. Ersteres beschreibt die Beziehung zweier Hostmodule. Zweiteres beschreibt eine lokale Zuordnung. Das Anwendungsergebnis gehört wiederum zu Parsern, Berechtigungen, Transaktionen und Persistenz, also zu anderen Entscheidungsträgern. Heng Lu Note 64 liefert dafür die passende Lesart: Eine gemeinsame Regel darf minimal und lokal überprüfbar sein, ohne spätere lokale Entscheidungen an sich zu ziehen.

Auch „reliable“ schrieb keine einheitliche Betriebsstrategie vor. RFC 938 verlangte einen Mechanismus zum Anstoß der Retransmission und die Wiederholung von snd_una, ließ Timer und Strategie aber offen. Der Verweis auf zwei Minuten Quiet Time bei bekannt werdender Gegenadresse und auf RFC 793 ist eine begrenzte Designparallele; er macht IRTP nicht zu TCP und beweist keine gemeinsame Einsatzgeschichte.

Quellen und Grenzen

RFC 938 trägt die Aussagen über Header, Verbindung und PORT NAK; die Informationsseite den Status; RFC 791 die Rolle des IP-Feldes; RFC 793 nur den Quiet-Time-Vergleich; IANA die Zuweisung 28. Keine Quelle quantifiziert Einführung, Verkehr, Leistung oder Gegenwartsnutzung. Insbesondere ist ein PORT NAK keine Sicherheits- oder Geschäftsbestätigung. Die Spezifikation hält eine wahre Empfangsaussage und eine wahre lokale Ablehnung gleichzeitig fest.