Zusammenfassung

  • RFC 875 unterschied das Internet-Gateway, das ein gemeinsames IP-Datagramm bewahrte, von einem Übersetzungs-Gateway, das Adressen, Bestätigungen, Flusssteuerung und Anwendungssemantik aufeinander abbilden musste.
  • Sobald die Zwischenstelle beide Protokollseiten terminierte, sammelte sie privaten Verbindungszustand und wurde zum Singularitätspunkt für Ausfall, Redundanz und spätere Änderungen.

Auf einem Architekturdiagramm kann ein Rechteck zwei unvereinbare Netze mit einem einzigen Pfeil verbinden. Das Rechteck heißt „Gateway“, und die schwierigen Verben verschwinden: bestätigen, unterbrechen, bremsen, wiederaufnehmen. Der Pfeil zeigt, dass Daten die Grenze passieren. Er sagt nicht, welche Behauptung nach der Grenze noch gilt.

M. A. Padlipsky veröffentlichte im September 1982 RFC 875, Gateways, Architectures, and Heffalumps. Das Memo war weder ein Standard für einen bestimmten Übersetzer noch eine Erhebung über eingesetzte Systeme. Es war eine Architekturkritik: Ein Gateway zwischen inkompatiblen Protokollfamilien ließ sich nicht als bloß leistungsfähigere Form eines Internet-Gateways behandeln.

Ein gemeinsames Datagramm machte lokale Unterschiede beherrschbar

RFC 791 definierte IP für miteinander verbundene paketvermittelte Netze. Internet-Adressen und Fragmentierung ließen ein Datagramm lokale Netze mit unterschiedlichen Paketgrößen und Übertragungsverfahren durchqueren. Ende-zu-Ende-Zuverlässigkeit, Reihenfolge und Flusssteuerung gehörten ausdrücklich nicht zu IP.

Diese Leerstelle war eine Arbeitsteilung. Ein Gateway entfernte den lokalen Rahmen, wählte anhand der Internet-Adresse den nächsten Hop und verpackte dasselbe Datagramm für das nächste Netz. Es musste nicht die TCP-Endpunkte nachahmen. RFC 791 hielt sogar fest, dass höhere Protokolle nicht im Gateway implementiert werden mussten.

RFC 793 legte Verbindungszustand, Sequenznummern, zuverlässige Zustellung, Fenster und dringende Hinweise in TCP bei den Hosts. Die Schichten machten verschiedene Zusagen, und deshalb blieb sichtbar, welcher Teilnehmer welche Zusage verantwortete.

RFC 875 wandte sich also nicht gegen heterogene Netze. IP war gerade für solche Netze entworfen. Padlipsky trennte Heterogenität unterhalb einer gemeinsamen schmalen Schicht von semantischer Inkompatibilität oberhalb dieser Schicht. Einen lokalen Rahmen kann das Gateway ersetzen, weil beide Seiten das enthaltene Datagramm als dasselbe Objekt erkennen. Eine fehlende Transport- oder Anwendungszusage entsteht nicht durch Umbenennung eines Feldes.

Der NCP-Adresse fehlte die Dimension des fremden Netzes

Eine NCP-Hostschnittstelle bezeichnete einen Host innerhalb des ARPANET-Adressraums. Eine IP-Adresse enthielt Netz- und Hostanteil. Auf der gewöhnlichen NCP-Seite gab es daher keine Stelle für die Aussage: „dieser Host in jenem anderen Netz“.

Ein Übersetzer konnte freie Bits suchen, das anfängliche Verbindungsprotokoll ändern oder die Internet-Adresse in Anwendungsdaten unterbringen. Jede Lösung veränderte jedoch die NCP-Umgebung, die angeblich unverändert bleiben sollte. Es ging nicht um das Druckbild einer Zahl. Dem einen Vertrag fehlte der Geltungsbereich des anderen.

RFC 875 beschrieb einen offeneren Ausweg. Die Zwischenstelle konnte als Host auftreten, die erste Verbindung beenden, den Benutzer nach dem fremden Ziel fragen und eine zweite Verbindung eröffnen. Padlipsky nannte sie „Janus Host“. Für interaktives Telnet konnte das nützlich sein; transparent war die Verbindung nicht mehr.

Der Übergangsplan in RFC 801 zeigte diese Grenze im Betrieb. Ein Telnet-Benutzer meldete sich an einem Relay-Host über ein besonderes Konto an und startete anschließend die zweite Telnet-Sitzung. FTP erforderte zwei Dateiübertragungen durch das Relay. Für Mail gab es ein eigenes Verfahren. Das Relay legte die zwei Teilbeziehungen offen, statt eine allgemeine verlustfreie Übersetzung vorzutäuschen.

Eine nahe Bestätigung war kein Beleg über den fernen Host

Bei NCP kam Ready for Next Message vom Ziel-IMP. Stand ein Übersetzer dazwischen, konnte das der IMP neben dem Übersetzer sein, nicht der letztlich gemeinte Host in der fremden Protokollwelt. Das Signal beschrieb einen nahen Rand des Weges.

Das Übersetzungs-Gateway konnte es verzögern und Daten puffern. Dann musste es entscheiden, welches Ereignis auf der anderen Seite die Fortsetzung erlaubte: Annahme durch das lokale Netz, Empfang durch den Transport oder Verarbeitung in der Anwendung? Wenn das fremde Protokoll die benötigte Tatsache nicht meldete, konnte ein größerer Puffer sie nicht erzeugen.

Flusssteuerung benennt nicht nur eine Rate. Sie bestimmt, wer anhalten soll, welche Ressource geschützt wird und welcher Nachweis die Fortsetzung erlaubt. Legen zwei Protokolle diese Grenzen verschieden, besitzt das Gateway den Widerspruch als Zustand. Speicher verschiebt die Entscheidung, löst sie aber nicht.

Dringende Signale konnten verschiedene Akteure befehlen

NCP hatte einen Unterbrechungsbefehl auf einer Kontrollverbindung. TCP bot den Urgent-Mechanismus innerhalb der Verbindung, Telnet einen Interrupt Process, andere Architekturen beschleunigte Daten. Die Wörter klangen verwandt, doch sie mussten nicht dieselbe Komponente zu derselben Handlung veranlassen.

RFC 793 beschrieb die TCP-Grenze: Der Urgent-Mechanismus sollte den empfangenden Benutzer zur Verarbeitung dringender Informationen anregen und die Übergänge des dringenden Modus anzeigen. Ein Protokollinterpreter mit Vorrangdienst ist nicht dasselbe wie ein Zielprozess, der seine Arbeit unterbricht.

Wo eine entsprechende Handlung fehlte, hatte der Übersetzer keine neutrale Abbildung. Verwerfen verlor Funktion. Beschleunigte Zustellung als Prozessunterbrechung zu behandeln erfand Befugnis. Die Anwendung zu terminieren und eine lokale Regel anzuwenden machte wenigstens sichtbar, dass die Zwischenstelle entschied.

Padlipsky erwähnte ein Terminal-Gateway des University College London zwischen ARPANET-Telnet und X.25/X.28/X.29. Nach dem begrenzten Bericht in RFC 875 konnten Daten übertragen werden, aber nur die Echo-Option überschritt die Grenze. Daraus folgt kein vollständiges Urteil über das System. Der Befund trennt lediglich zwei Nachweise: Zeichenübertragung und Erhaltung des Optionsvokabulars um diese Zeichen.

Der Verbindungszustand band die Sitzung an eine Box

Ein funktionierender Übersetzer hielt nun zwei Verbindungskennungen, zwei Sequenzräume, zwei Flusszustände, Adressbindungen, Optionen und Anwendungsannahmen. Eine zweite identische Maschine daneben kannte diese lebenden Tatsachen nicht automatisch.

RFC 875 bezeichnete die Zwischenstelle als Singularitätspunkt. Paket-Routing konnte eine ausgefallene Leitung umgehen, aber nicht die private Gesprächsgeschichte des Übersetzers rekonstruieren. Echte Übernahme verlangte Zustandsübertragung, Konfliktregeln und ein Protokoll für die Eigentumsübergabe. Das Rechteck war zu einem verteilten System geworden.

Auch Änderungen verstärkten die Bindung. Ein Übersetzer A–B löste nicht A–C. Eine Änderung an Adressierung, Option oder Anwendung auf einer Seite erforderte die Prüfung aller betroffenen Paarungen. Die vermeintlich bequeme Grenze sammelte Release-Zeitpläne und Zweideutigkeiten beider Seiten.

Ein späterer IP-Router verrichtete weiterhin erhebliche Anpassung

RFC 1009 definierte ein Internet-Gateway später als Router auf IP-Ebene. Es behandelte Rahmen, MTU, lokale Adresszuordnung sowie lokale Fluss- oder Fehlerhinweise, verwaltete Puffer und bestimmte nächste Hops. „Schmal“ bedeutete keineswegs trivial.

Zwischen diesen Anpassungen blieb das IP-Datagramm jedoch dasselbe Objekt. Der Router musste keine Bestätigung einer fremden Anwendung erzeugen oder einen Befehl für einen Protokollinterpreter in einen Prozessabbruch übersetzen. Die gemeinsame Zusage hatte eine erkennbare Grenze.

Spätere Middleboxes stellten die Fragen neu

RFC 2775 hielt später fest, dass Adressübersetzung die Ende-zu-Ende-Adress-Transparenz bricht. Anwendungen mit Adressen in ihren Nutzdaten benötigen dann Anwendungs-Gateways oder Proxys; jede neue adressabhängige Anwendung kann neues Wissen in der Zwischenstelle verlangen.

RFC 3234 ordnete Middleboxes, erkannte ihre nützlichen Aufgaben an und beschrieb zugleich neue Ausfälle: Umleitung kann zu einer Box ohne alten Zustand führen, ein Absturz Sitzungen beschädigen und Diagnose mehrere Schichten durchqueren. Ein Anwendungs-Gateway speichert Zustand, weil es an Anwendungssemantik teilnimmt.

RFC 4966 setzte NAT-PT aus konkreten technischen und betrieblichen Gründen auf Historic: eingebettete Adressen, unterschiedliche IPv4/IPv6-Semantik, Fragmentzustand, Lebensdauer von Abbildungen, Skalierung des DNS-ALG und ein konzentrierter Ausfall- oder Angriffspunkt. Das ist kein Beweis gegen jede Übersetzung und keine Behauptung direkter Abstammung von RFC 875. Es zeigt erneut, weshalb „Pakete umschreiben“ keine vollständige Spezifikation ist.

Fehlende Bedeutung muss als Entscheidung sichtbar werden

Jeder Pfeil durch eine Zwischenstelle lässt sich mit vier Fragen prüfen: Welche Behauptung tritt ein? Welche tritt aus? Wer erklärt sie für entsprechend? Welcher Nachweis bleibt nach einem Fehler?

Teilen beide Netze ein minimales Protokoll, kann das Gateway lokale Ausführung anpassen und ein gemeinsames Objekt bewahren. Stimmen die Protokolle nicht überein, bleiben ausdrückliche Entscheidungen: Dienst auf die Schnittmenge reduzieren, terminieren und neu eröffnen, einen Endpunkt erweitern oder anerkennen, dass eine Funktion nicht übertritt.

Angekommene Bytes, umgeschriebene Adressen und ein funktionierendes Echo sind beobachtbare Erfolge. Sie beweisen nicht, dass Bestätigung, Dringlichkeit, Anwendungsoptionen oder Sitzungsfortsetzung dieselbe Bedeutung behielten. Ein Gateway kann tragen, was beide Seiten definiert haben. Eine Zusage, die auf einer Seite nie bestand, muss sichtbar ergänzt, eingeschränkt oder verworfen werden.

Quellen