Zusammenfassung

  • RFC 818 registrierte Port 107 für einen optionalen Remote-User-Telnet-Dienst. Hinter dem eingehenden Telnet-Zugang lag damit eine Anwendung, die selbst eine weitere Telnet-Verbindung eröffnen konnte.
  • Im BBN-Terminalkonzentrator TC68K verband ein Pseudo-Terminal den eingehenden Server Telnet mit dem ausgehenden User Telnet. Ein Bediener sah eine Sitzung, obwohl zwei TCP-Verbindungen, zwei Telnet-Zustände und mehrere lokale Zuständigkeiten beteiligt waren.
  • Ein gelungener Lauf belegte genau diese beobachtete Kette. Die bekannte Portnummer fand den Dienst; sie identifizierte weder den Menschen noch erlaubte sie jedes Ziel oder bestätigte die Wirkung in der letzten Anwendung.

Das Testergebnis musste in seine Bestandteile zerlegt werden

BBN wollte einen TC68K in einem anderen Gebäude prüfen. Der Bediener stellte eine Telnet-Verbindung zum entfernten Konzentrator her, rief von dort aus dessen vorhandenes User Telnet auf und ließ sich Statistiken eines Ziels anzeigen. Auf dem Bildschirm erschien ein zusammenhängender Dialog. Im Rechner liefen jedoch vier unterscheidbare Schritte:

  1. Das lokale User Telnet des Bedieners eröffnete die erste TCP-Verbindung.
  2. Der Server-Telnet-Prozess des TC68K terminierte sie.
  3. Ein Pseudo-Terminal transportierte Zeichen lokal zum User-Telnet-Prozess des TC68K.
  4. Dieser Prozess eröffnete eine zweite TCP-Verbindung zum gewählten Ziel.

Der Erfolg bewies, dass der Hörer erreichbar war, die eingehende Sitzung weit genug funktionierte, das PTY Daten übergab, User Telnet die geprüfte ausgehende Verbindung herstellen konnte und das Ziel genügend Information zurückgab. Das war mehr Evidenz als ein bloßes Echo und weniger als ein Gesamturteil über das Netz.

Nicht geprüft waren alle anderen Routen, jede denkbare Telnet-Option oder die Wirkung an einem beliebigen Endgerät. Ein Zeichen, das TCP auf der ersten Strecke bestätigte, war noch kein bestätigter Auftrag der letzten Anwendung. Ein sichtbarer Prompt benannte auch nicht automatisch den Menschen, der ihn bediente.

Diese Beschränkung ist keine Schwäche des Tests. Sie macht ihn brauchbar. Operative Evidenz wird belastbar, wenn ihre beobachteten Grenzen erhalten bleiben, statt aus einer grünen Oberfläche in eine allgemeine Gesundheitsbehauptung verwandelt zu werden.

Der gewöhnliche Eingang führte zu einem Executive

Der frühe Telnet-Gebrauch hatte eine bekannte Gestalt. User Telnet eröffnete die Verbindung; Server Telnet lauschte typischerweise an Port 23 und schloss die Gegenstelle an ein allgemeines Executive an. Auf einem großen Service-Host erhielt der Benutzer eine Umgebung, in der er danach ein Programm auswählen konnte.

RFC 764 beschrieb darunter einen allgemeineren Vertrag. Telnet war eine bidirektionale Byte-Einrichtung für Terminals und terminalorientierte Prozesse. Die Network Virtual Terminal, eine gemeinsame gedachte Tastatur-und-Drucker-Schnittstelle, ersparte jedem Host die Kenntnis jedes fremden Terminaltyps. Optionen durften reichere Fähigkeiten aushandeln; bei Ablehnung blieb die minimale NVT-Konvention arbeitsfähig.

Auch die Wörter User und Server waren Beziehungsbegriffe. Für Terminal-zu-Terminal- oder Prozess-zu-Prozess-Verkehr war User die Seite, die die Kommunikation initiierte. Eine Maschine erhielt damit keinen dauerhaften Rang. Derselbe Host konnte in verschiedenen Verbindungen verschiedene Rollen tragen.

Port 23 ließ trotzdem eine Anwendungsform selbstverständlich wirken: Betritt den Host und wähle dort weiter. Für einen kleinen Rechner ohne sinnvolles Executive war diese Form kein natürlicher Endpunkt.

Ein kleiner Host konnte eine einzelne Fähigkeit anbieten

RFC 818 setzte im November 1982 genau dort an. Ein kleiner Host konnte nur begrenzte Funktionen und überhaupt kein Executive besitzen. Ein allgemeiner Telnet-Einstieg war dann unnötig; eine bestimmte Anwendung konnte dennoch eine bekannte Anlaufstelle verdienen.

Die Anwendung hieß Remote User Telnet. Ein Host, der sie freiwillig bereitstellte, lauschte an Port 107. Die äußere Verbindung sprach Telnet, aber hinter dem Hörer lag die Fähigkeit, als User eine weitere Telnet-Verbindung zu initiieren.

Das war keine bloße Umbenennung des Servers. Außen bestand weiterhin ein lauschender Dienst, der die eingehende Verbindung annahm. Innen bestand ein User-Telnet-Prozess, der eine neue Verbindung eröffnete. Die Spezifikation machte die Komposition adressierbar, ohne die beiden Beziehungen zu verschmelzen.

Die Nummer beantwortete daher nur die Frage nach dem lokalen Rendezvous. Sie sagte nicht, wer den Dienst aufrufen durfte, welche Ziele der innere Client erreichen sollte und welcher Akteur am Ende eine Aktion genehmigte.

Sechzehn serielle Leitungen brauchten kein neues Managementsystem

Der praktische Rechner war BBNs TC68K, ein auf dem Motorola MC68000 basierender Terminalkonzentrator. Er besaß eine Netzverbindung, sechzehn RS-232-Anschlüsse und einen programmierbaren Timer. Sein Micro-Operating System führte IP, ICMP, TCP und Telnet aus.

Zwei Teile waren schon vorhanden. User TC-Telnet erlaubte einem Menschen an einem angeschlossenen Terminal den Verbindungsaufbau zu einem Netzhost. Server Telnet stellte nicht netzfähige Geräte wie entfernte Drucker, Plotter und Computer nach außen bereit.

Für den gebäudeübergreifenden Test setzte BBN diese Programme Rücken an Rücken. Der entfernte Bediener erschien dem User TC-Telnet so, als säße er an einem lokalen Terminal. Er konnte die zweite Verbindung eröffnen und bereits geführte Statistiken abfragen.

Die einzige zusätzliche Software war laut Memo ein Pseudo-Teletype-Treiber. Für die Anwendungen sah das PTY wie ein Terminal aus; innerhalb des Systems stellte es den Zeichenstrom zwischen zwei Prozessen her.

Der geringe Zusatzaufwand war nicht nur Sparsamkeit. Er begrenzte die gemeinsame Spezifikation auf das, was mehrere Implementierungen wirklich teilen mussten. Der lokale Betreiber durfte vorhandene laufende Komponenten neu anordnen, ohne dafür Telnet um eine allgemeine Managementlehre zu erweitern.

Rücken an Rücken bedeutete nicht transparent

Beide Telnet-Verbindungen besaßen eigene Optionszustände. Jede TCP-Verbindung konnte unabhängig schließen. Der innere Prozess konnte noch existieren, nachdem der äußere Teilnehmer verschwunden war. NVT-Abbildungen und lokale Prozessregeln blieben an den Endpunkten aktiv.

RFC 818 definierte weder einen universellen Übersetzer für jede Option noch eine Ende-zu-Ende-Sicherheitsbeziehung über das PTY. Sie schrieb auch keine vollständige Regel für die Fortpflanzung jedes Fehlers vor. „Rücken an Rücken“ beschrieb die Implementierungstopologie, nicht ein verlustloses Rohr ohne Zustandsgrenzen.

Die spätere RFC 854 behielt die symmetrische Grundidee bei. Terminals und Prozesse sollten über eine gemeinsame Darstellung und Optionsverhandlung miteinander arbeiten. Dass ein TC68K auf der äußeren Verbindung Server und auf der inneren User war, verletzte diese Symmetrie nicht; die Rollen gehörten verschiedenen Verbindungen.

Eine Architekturzeichnung, die beide Strecken zu einer Linie vereinfacht, verliert gerade die Information, die Betrieb und Sicherheit benötigen: Wo wurde angenommen, wo umgesetzt, wer wählte das Ziel und welche Wirkung wurde zuletzt beobachtet?

Die gemeinsame Mindestform ließ Nichtteilnahme zu

RFC 1123 fasste Telnet 1989 überwiegend als Standard für Remote Login zwischen Tastatur/Anzeige und Befehlsinterpreter zusammen. Gleichwohl führte sie Pflichten für User und Server Telnet getrennt auf. Beide Seiten mussten grundlegende Steuerfunktionen unterstützen, unbekannte Befehle behandeln und die Optionsverhandlung bewahren. Wenn keine reichere Option zustande kam, blieb NVT der gemeinsame Boden.

Diese Mindestform machte die ungewöhnliche Komposition möglich, ohne sie vorzuschreiben. Ein TC68K konnte Port 107 anbieten. Ein anderer Host konnte es lassen. Ein veröffentlichter Eintrag war eine Koordinationsmöglichkeit, kein zentraler Installationsbefehl.

Das heutige IANA-Verzeichnis der Dienstnamen und Transportprotokoll-Ports enthält weiterhin rtelnet an Port 107, beschrieben als Remote Telnet Service. Dieser Registereintrag hält eine Namenszuordnung fest. Er belegt keine heutige Verbreitung, Sicherheit oder Produktunterstützung. Die dortige UDP-Zeile macht aus RFC 818 auch kein Datagramm-Protokoll; das Memo spezifizierte Telnet über eine Verbindung.

Register bewahren Symbole länger als konkrete Installationen. Daher muss gegenwärtige Existenz aus laufendem Dienst und beobachtbarem Verhalten folgen, nicht aus der Fortdauer einer Zeile.

Spätere serielle Kontrolle musste angewandten Zustand melden

Fünfzehn Jahre später untersuchte RFC 2217 eine verwandte, aber eigenständige Grenze. Ein Telnet-Client sollte einen seriellen Port erreichen, an dem etwa Modem, Drucker, Plotter oder Überwachungsgerät hing. Für einen solchen Zugriff reichte ein Zeichenstrom nicht aus.

Baudrate, Datenbreite, Parität, Stoppbits, Modemsignale und zwei Ebenen der Flusskontrolle mussten ausdrücklich geändert und beobachtet werden. RFC 2217 definierte deshalb COM-PORT-OPTION innerhalb der normalen WILL-, WON'T-, DO- und DON'T-Verhandlung von Telnet. Nach Annahme benannten Befehle die lokale Portkonfiguration und Meldungen den Leitungszustand.

Besonders lehrreich war die Bestätigung nach der Verarbeitung. Der Server antwortete mit dem tatsächlich gesetzten Wert, der vom gewünschten abweichen konnte. TCP hatte zu diesem Zeitpunkt den Empfang der Bytes bereits bestätigt. Die Anwendungsantwort belegte eine andere Tatsache: Der Zugangsserver hatte den Auftrag verarbeitet und einen konkreten lokalen Zustand eingestellt.

Auch die Beendigung erhielt eine eigene Bedeutung. Authentifizierung entschied über den Eintritt. Beim Sitzungsende musste der Server den entfernten Dienst trennen und die serielle Geometrie auf eine administrativ bekannte Form zurücksetzen. Sonst wurde eine lokale Wahl des ersten Benutzers zur Realität des nächsten.

RFC 2217 ist hier kein behaupteter Nachfolger oder Ersatz von RFC 818. Der spätere Text prüft dieselbe Grenze unter reicheren Anforderungen. Ein Strom kann Zeichen transportieren; die Verfügung über Hardwarezustand benötigt zusätzliche Verben, Rückmeldungen und einen verantwortlichen Eigentümer.

Die Nummer fand den Dienst, nicht die Autorität

RFC 818 zeigt, wie weit eine kleine gemeinsame Vereinbarung reichen kann, wenn lokale Ausführung beweglich bleibt. Telnet bestimmte das Gespräch zwischen Peers. Der TC68K-Betreiber entschied, welche Prozesse er verband und ob er Port 107 öffnete. Der Bediener wählte innerhalb lokaler Regeln ein Ziel. Das Ziel behielt die Entscheidung über die letzte Wirkung.

Die Registrierung benannte eine Tür. Der laufende Hörer machte sie auf einem bestimmten Host real. Authentifizierung konnte einen Aufrufer benennen, Autorisierung dessen nächste Verbindung begrenzen und Anwendungsevidenz die tatsächliche Arbeit belegen. Keiner dieser Nachweise ersetzte die anderen.

Der Client wurde durch funktionierende Komposition zum Dienst – nicht durch eine Nummer zur Autorität.