Zusammenfassung

  • DRAP ersetzte einen DLSw-Peer pro Arbeitsplatz durch viele schlanke Clients, einen Server und eine DLSw-Beziehung zur Zentrale.
  • Der Server vergab oder speicherte MAC-Adressen, beantwortete Erreichbarkeitsfragen, handelte Fähigkeiten aus, erzeugte Sitzungskennungen und konnte Leitungen bei ruhender TCP-Verbindung erhalten.
  • Diese Signale bewiesen weder menschliche Identität noch Berechtigung, echte Herkunft oder Ende-zu-Ende-Zustellung; RFC 2106 definierte keine Authentifizierung und war Informational, kein Internetstandard.

Die Anzahl der Verbindungen schrumpfte, der Zustand nicht

RFC 2106 begann mit einem Skalierungsproblem. Lief auf jedem entfernten Arbeitsplatz vollständiges DLSw, wuchs die Zahl der TCP-Sitzungen zur Zentrale mit der Zahl der Arbeitsplätze. Ein Verfahren zwischen Switches wurde bis zum einzelnen Endgerät ausgedehnt.

DRAP ordnete die Hierarchie neu. Die Arbeitsplätze wurden Clients eines nahen Servers; nur der Server hielt die DLSw-Peer-Beziehung zum zentralen Router. Viele Randanschlüsse teilten sich so eine Backbone-Beziehung. Die Komplexität verschwand nicht, sondern wanderte zu einem Gateway, das für die Clients erinnerte und sprach.

Damit unterscheidet sich der Fall von den benachbarten Analysen: RFC 1434 betraf zwei lokale LLC-Verbindungen über einen gemeinsamen Transport, RFC 2024 die DLSw-MIB für Verzeichnis, Cache, Transport und Schaltkreise, RFC 2043 zwei getrennte SNA-Zulassungen über PPP und RFC 2097 die Zulassung einzelner NetBIOS-Namen. RFC 2106 machte den Server zum operativen Gedächtnis vieler Arbeitsplätze.

Eine virtuelle MAC war keine Identitätsprüfung

Ein per PPP angeschlossener Arbeitsplatz konnte eine IP-, aber keine LAN-MAC-Adresse besitzen. Der DRAP-Server durfte eine virtuelle MAC vergeben. Meldete der Client eine von null verschiedene Adresse, prüfte der Server ihre Eindeutigkeit und speicherte sie. Für serverinitiierte Sitzungen konnte der Client MAC und IP vorab registrieren.

Diese Adresse machte den Endpunkt im Protokoll erreichbar. Sie sagte nicht, welcher Mensch das Gerät steuerte, ob die Nutzung einer Anwendung erlaubt war oder ob die Registrierung aus einer authentischen Quelle stammte. Der Cache war ein Speicher operativer Behauptungen, keine Identitätsinstanz.

Bei mehreren konfigurierten Servern konnte der Client Anfragen senden und den ersten Antwortenden wählen. Die erste Antwort belegte aktuelle Verfügbarkeit und Laufzeit, nicht die richtige administrative Zuständigkeit.

Ein Zustandswechsel bewies genau einen Zustandswechsel

CAN_U_REACH fragte nach einem Ziel; I_CAN_REACH gab die Einschätzung des Servers wieder. START_DL verlangte eine Link-Station, DL_STARTED meldete ihre Erzeugung. Sender- und Empfängerkennungen trennten Schaltkreise. Der Fähigkeitenaustausch regelte MAC, NetBIOS-Unterstützung, SAP-Listen und den TCP-Listen-Modus.

Eine positive Antwort zeigte, dass der Server Erreichbarkeit behauptete. Sie bewies keine Zustellung an die Anwendung. Ein gestarteter Link zeigte eine lokale Transition, keine Berechtigung. Eine Sitzungskennung benannte internen Zustand, ohne dessen Herkunft unabhängig zu bestätigen.

RFC 2106 verwendete pro Client-Server-Paar eine bidirektionale TCP-Verbindung auf Port 1973. TCP konnte ausgesetzt werden, während die Datenverbindungen bestehen blieben. Bei neuen Nutzdaten verband sich der Client erneut, ohne den Fähigkeitenaustausch zu wiederholen. Optionale Keepalives prüften die Antwortfähigkeit; nach drei Fehlschlägen sollten TCP und Schaltkreise geschlossen werden.

„Verbunden“ war damit eine Aussage über mehrere Schichten. Ein Socket konnte fehlen, obwohl ein logischer Schaltkreis fortbestand. Ein Keepalive belegte Antwortfähigkeit, nicht die Ankunft einer Transaktion am Ziel.

Informational war keine Standardisierung

RFC 2106 erschien im Februar 1997 als Informational und erklärte ausdrücklich, keinen Internetstandard festzulegen. Es beschrieb keinen Authentifizierungsmechanismus und enthielt keinen Abschnitt zu Sicherheitsüberlegungen. Das Dokument spezifizierte Fernzugriff und Zustandsübergänge, keine Identitätsarchitektur.

RFC 2114 löste es noch im selben Monat ab, nannte das Verfahren DCAP und ergänzte Entdeckungsoptionen, behielt aber das Client-Server-Modell. Eine Portregistrierung, eine interoperable Implementierung oder eine RFC-Nummer können ein System betriebsfähig machen. Dauerhaften Standardkonsens beweisen sie einzeln nicht.

Quellen