Zusammenfassung

  • RFC 1498 unterschied Dienste oder Benutzer, Knoten, Netzanschlusspunkte und Pfade und verband sie durch drei aufeinanderfolgende, veränderliche Bindungen.
  • Die Verlegung eines Dienstes änderte die Dienst-Knoten-Bindung, nicht den Namen des Dienstes. Knotenbewegung und Pfadwechsel blieben davon getrennt.
  • Ein Adress- oder Auflösungsergebnis belegt nur einen aktuellen Zustand. Identität, Berechtigung, Erreichbarkeit und Zustellung brauchen eigene Nachweise.

Bewegung ohne Umbenennung

Ein Dienst läuft heute auf Knoten 5 und morgen auf Knoten 6. Der Knoten bleibt derselbe Knoten, wenn er seine Netzschnittstelle wechselt. Der Verkehr kann einen neuen Pfad nehmen, obwohl beide Endpunkte unverändert bleiben. Diese drei Sätze beschreiben verschiedene Zeitachsen.

RFC 1498 gab ihnen ein gemeinsames Modell. Jerome Saltzers Aufsatz erschien erstmals 1982 und wurde im August 1993 als Informational RFC veröffentlicht. Er war kein Internetstandard, sondern ein Werkzeug gegen die begriffliche Kompression, die Namen, Adressen und Routen mit den bezeichneten Dingen verwechselt.

Vier Gegenstände statt drei Etiketten

Die bekannte Formel lautete: Ein Name sagt, was man will, eine Adresse, wo es ist, und eine Route, wie man dorthin gelangt. RFC 1498 setzte früher an und zählte vier benennbare Gegenstände auf.

Dienste und Benutzer sind Funktionen und ihre Klienten. Knoten sind Rechner, die Dienste oder Programme ausführen. Netzanschlusspunkte sind Ports oder logische Stellen, an denen Knoten das Netz betreten. Pfade verlaufen zwischen Anschlusspunkten über Leitungen und weiterleitende Knoten.

Die Schreibweise legt den Typ nicht fest. Eine lesbare Zeichenkette kann einen Anschluss bezeichnen; ein Binärwert kann ein Knotenname sein; derselbe Gegenstand kann hierarchischen Text und eindeutige Kennung besitzen. Darum muss jeder Beleg den Namensraum und den bezeichneten Objekttyp nennen. Der Ausdruck „Adresse“ allein reicht nicht.

Auflösung, Ortung und Wegwahl

Um einen Dienst zu erreichen, muss ein System erst einen ausführenden Knoten finden, danach einen Anschlusspunkt dieses Knotens und schließlich einen Pfad vom eigenen Anschluss zum Ziel. RFC 1498 nennt diese Funktionen Dienstnamensauflösung, Knotennamensortung und Routendienst.

Jede Stufe kann mehrere Ergebnisse liefern. Ein replizierter Dienst läuft auf mehreren Knoten, ein Knoten ist mehrfach angebunden und mehrere Pfade sind möglich. Die Entscheidungen beeinflussen einander: Schlechte Wege zu einem Knoten können einen anderen Dienststandort attraktiver machen. Tabellen dürfen deshalb nur partielle Bindungen oder Listen liefern; die letzte Auswahl kann außerhalb der drei Netzdienste erfolgen.

Eine beobachtete Zieladresse ist dann das Ende eines Auswahlvorgangs, nicht dessen vollständiges Protokoll. Sie verrät weder alle Kandidaten noch die Auswahlregel oder den späteren Anwendungserfolg.

Die DIALOG-Zeile hatte einen begrenzten Zweck

Das prägnanteste Beispiel lautet: Der Lockheed DIALOG Service läuft auf Knoten 5. Drei Zuordnungen stecken darin. Der Dienstname bezeichnet dauerhaft einen bestimmten Dienst. „5“ bezeichnet dauerhaft einen bestimmten Knoten. Nur die aktuelle Dienst-Knoten-Bindung steht in der leicht änderbaren Tabelle.

Eine Änderung auf Knoten 6 verlegt den Dienst. Sie benennt ihn nicht um. Eine echte Umbenennung müsste Programme, Dokumentation, Notizzettel und Werbung erreichen. Die Tabelle war gerade deshalb veränderlich, weil sie eine zeitabhängige Beziehung ausdrückte.

Aus ihrer Pflege folgt auch keine umfassende Autorität. Wer den Betriebsort einträgt, kann die technische Auswahl beeinflussen. Daraus entstehen nicht automatisch Eigentum am Dienst, Authentizität des Betreibers oder Entscheidungsgewalt über externe Folgen.

Eine feste Bindung spart Zustand und kostet Ausdruck

Beim Ethernet-Beispiel konnte dieselbe 48-Bit-Kennung als Knotenname und als Name des Anschlusspunktes gelten. Diese dauerhafte Bindung sparte eine Tabelle, erlaubte physische Bewegung ohne Registeränderung und vereinfachte alternative Wege.

Sollte ein Knoten jedoch zwei getrennt adressierbare Anschlüsse im selben Ethernet haben, entstanden widersprüchliche Darstellungen. Zwei Kennungen ließen ihn in anderen Datensätzen wie zwei Knoten aussehen; eine Kennung machte die Anschlüsse ununterscheidbar. Die Bindung war nicht verschwunden, sondern fest eingebaut worden.

ARPANET NCP zeigte die umgekehrte Täuschung. Mnemonische Zeichenketten sahen wie Knoten- oder Dienstnamen aus, bezeichneten aber Anschlusspunkte. Wurde der Rechner umgesteckt, mussten viele Tabellen oder der sichtbare Name geändert werden. Ein redundanter Maildienst konnte einen anderen scheinbaren „Dienstnamen“ verlangen, weil der Name nicht auf Dienstebene lag.

Mechanische Vereinigung ist keine semantische

Ein Namensserver konnte aus einem Dienstnamen unmittelbar eine Liste von Anschlusspunkten erzeugen und damit die ersten beiden Bindungen mechanisch zusammenfassen. Verteiltes Routing erledigte die dritte unbemerkt. Beim Fehler blieben dennoch drei getrennte Prüfungen: Prozessplatzierung, Knotenanschluss und Pfad.

Spätere Dokumente bestätigen den Druck dieser Trennung. RFC 1958 riet von fest codierten Adressen ab und lobte Modularität. RFC 2101 unterschied Anforderungen an Identifikatoren und Lokatoren und nannte ihre gemeinsame Verwendung in IPv4 eine historische Zufälligkeit. RFC 2956 protokollierte Schwierigkeiten der Vermischung von Knotenidentität und Zustellort. Sie sind spätere Vergleiche, keine rückwirkende Erweiterung.

Auch eine Route zum Dienst braucht noch die Aktivität oder den Socket im Knoten. Danach fehlen weiterhin Lauschen, Authentisierung, Autorisierung, Antwort und Wirkung. RFC 1498 bespricht Sicherheitsfragen ausdrücklich nicht.

Heng Lus Texte über Running-Code Primacy, lokalisierte künftige Entscheidungen und Realitätsebenen begrenzen die institutionelle Folgerung: Ein Koordinationsdatensatz hilft laufenden Systemen, wird aber weder zum Gegenstand noch zur dauerhaften Herrschaft über seine Betreiber.

Ein belastbarer Nachweis erhält Namensraum, Abfragezeit, alle Kandidaten, Dienstplatzierung, Knotenanschlüsse, Routenzustand, Auswahl, Socket, Sitzung und Anwendungsergebnis. Drei Bindungen können sich zu verschiedenen Zeiten ändern. Beweise sollten dieselbe zeitliche Auflösung besitzen.

Quellen