Zusammenfassung

  • RFC 814 beschrieb mehrere Übersetzungen im Host: sichtbare Namen wurden zu Adressen, Adressen zu Routen und Dienstnamen zu transportspezifischen Ports. Keine Stufe war ein vollständiger „Endpunkt“.
  • Vollständige Tabellen konnten nicht wachsen. Verteilte Pflege, nutzungsabhängige Caches und austauschbare Schnittstellen sollten lokalen Zustand klein und spätere Technik ersetzbar halten.
  • Die Trennung begrenzte Beweise: Eine Namensantwort war keine Route, eine Route kein Dienst und ein registrierter Port keine Authentisierung. DNS hielt später Netzkennungen, Adressen und Routen aus der erforderlichen Namenssyntax heraus.

Eine kleine Schnittstelle schützte vor Lock-in

David D. Clark schrieb RFC 814 im Juli 1982, als das Internet etwa 25 aktive Netze und wenige hundert Hosts umfasste. Schon diese überschaubare Welt durfte nicht zum Maßstab der Implementierung werden. Die Arbeitsannahme reichte bis zu 1.000 Netzen und ungefähr 25.000 Hosts.

Eine vollständige Kopie aller Namen in jedem Rechner wäre zu groß, zu veränderlich und überwiegend nutzlos geworden. Der vorgesehene Namensdienst verteilte die Pflege auf Netze oder Netzgruppen. Hosts fragten Server und behielten nur kürzlich gebrauchte Zuordnungen.

Doch die Migration musste beginnen, bevor der neue Dienst vollständig existierte. Deshalb sollte der bisherige Tabellengriff hinter einer Unterroutine liegen. Heute konnte sie lokal lesen, morgen einen entfernten Server fragen. Anwendungen blieben an die Frage gebunden, nicht an die Datei oder Institution, die gerade antwortete.

Diese Trennung ist eine Form praktischer Zukunftsoffenheit. Die minimale gemeinsame Spezifikation legt einen schmalen Aufruf fest. Spätere Entscheidungen werden dahinter lokal getroffen. Bestehender Code kann weiterlaufen, während die Infrastruktur ausgetauscht wird.

Ein Name konnte auf die falsche Maschine zeigen

RFC 814 kannte den Preis einer veralteten Bindung. Ein Host zog um, die lokale NIC-Tabelle war noch nicht aktualisiert und die alte Adresse gehörte inzwischen einer unerwarteten Maschine. Bei einer interaktiven Sitzung fiel das vielleicht auf. Wartende Post konnte ohne menschliche Kontrolle weiterlaufen.

Die Adresse war syntaktisch gültig, die Route funktionierte und ein Rechner antwortete. Trotzdem war der benannte Gegenstand nicht erreicht. Daraus folgt die zentrale Unterscheidung: Zeichenketten bezeichneten Netze, Hosts und Dienste; Hostnamen wurden in 32-Bit-Adressen übersetzt; Adressen in Routen; Dienstnamen in Portkennungen von TCP oder UDP.

Jede Zuordnung hat eine eigene Lebensdauer. Ein Name kann bleiben, während die Adresse wechselt. Eine Adresse kann bleiben, während der nächste Hop wechselt. Ein Dienst kann auf einem anderen Port oder Prozess erscheinen. Ein Erfolg auf einer Stufe darf die übrigen nicht grün färben.

Cache war zeitgebundene Aussage

Der verteilte Dienst löste Aktualisierungsprobleme nicht automatisch. Ein lokaler Cache konnte die alte Adresse länger behalten als ihre Quelle. RFC 814 erwähnte eine Rückfrage an die fremde Adresse nach dem zugehörigen Namen. Das war weder Signatur noch Eigentumsnachweis. Es zeigte, dass Herkunft und Alter einer Bindung beobachtbar sein müssen.

RFC 1034 machte diese Trennung später zum DNS-Grundsatz. Namen tragen typisierte Ressourcendaten, Verantwortlichkeit verteilt sich auf Zonen und Kopien haben Erneuerungsfristen. Vor allem sollten Namen nicht gezwungen sein, Netzkennungen, Adressen oder Routen zu enthalten.

Die Adresse wurde zu einer Antwort über den Namen, nicht zu dessen unveränderlichem Bestandteil. Das ermöglicht Kontinuität, garantiert sie aber nicht. Ein Name kann falsch delegiert, nicht authentisiert oder unerreichbar sein. Die Architektur entkoppelt Zustände; sie erklärt keinen davon zur absoluten Identität.

Aus der Adresse entstand erst die Route

IP prüfte, ob das Zielnetz direkt angeschlossen war. Andernfalls musste ein Gateway gewählt werden. Frühe statische Tabellen mit 256 möglichen Netznummern wurden unzuverlässig, sobald Gateways umzogen, ausfielen oder nicht mehr der beste Weg waren.

RFC 814 empfahl einen Route Cache für tatsächlich aktive Ziele. Fehlte ein Eintrag, konnte der Host ein erreichbares Gateway versuchen. Ein ICMP Redirect konnte einen besseren nächsten Hop melden und den lokalen Eintrag ändern. Die Route war lernbarer Betriebszustand, keine Eigenschaft des Namens.

Wie das erste Gateway entdeckt wurde, blieb bewusst dem lokalen Netz überlassen. Broadcast, ein netzspezifischer Mechanismus oder manuelle Konfiguration waren gleichermaßen denkbar. Die Internetschicht machte aus einer lokalen Fähigkeit keinen weltweiten Zwang.

RFC 1122 ordnete später die Routingkomplexität hauptsächlich den Gateways zu und wollte Hostsoftware von der Entwicklung der Routingarchitektur isolieren. Ein Cache konnte auch MTU oder Laufzeit einer Pfadphase speichern. Solche Werte gehören zur beobachteten Route, nicht dauerhaft zum Namen.

Ports gehörten nicht in den IP-Kern

Eine IP-Adresse brachte das Datagramm zum Host und zum oberen Protokoll. TCP oder UDP wählte dann über Ports Prozess oder Verbindung. Obwohl beide damaligen Protokolle ähnlich angeordnete Portfelder hatten, wollte RFC 814 daraus keine universelle IP-Regel machen.

Andere Protokolle konnten andere Größen und Verfahren brauchen. Bekannte Ports hatten protokollspezifische Bedeutung. IP sollte genau die Funktionen enthalten, die Gateways verstehen mussten. Würden Ports Teil von IP, erschiene Anwendungswissen als Pflicht jedes Gateways.

Clark verglich auch einen Rendezvous-Server, der eine Zeichenkettenbeschreibung entgegennimmt und für die konkrete Sitzung einen Port auswählt. Bei einer Verbindung ist der Einrichtungsaufwand vertretbar. Für ein einzelnes UDP-Datagramm wären zusätzlicher Weg und Vermittler unverhältnismäßig. Die Wahl blieb beim höheren Protokoll.

Die heutige IANA-Liste koordiniert Dienstname, Transport und Port. Sie begrenzt zugleich die Aussage: Eine Zuteilung unterstützt kein Produkt, und Verkehr auf dem Port muss weder dem eingetragenen Dienst entsprechen noch gutartig sein.

32 Bit waren ein Lieferkompromiss

Ein virtuelles Netz kann beim Aufbau eine lange Adresse übertragen und danach eine kurze Verbindungskennung verwenden. Ein Internet-Datagramm musste ohne Aufbau einzeln routbar sein; die Adresse stand deshalb in jedem Paket. RFC 814 beschrieb 32 Bit als Kompromiss zwischen Reichweite und Headergröße.

Das war keine Vorhersage von CIDR, NAT, IPv6 oder heutigen Märkten. Es definierte die Adresse als knappe Lieferkoordinate. Würde der menschliche Name diese Koordinate enthalten müssen, würde jede technische Migration die Referenz selbst beschädigen.

Ein prüfbarer Endpunkt besteht aus mehreren Belegen

Für einen Vorgang sind Name, Antwortquelle und TTL getrennt von den gelieferten Adressen zu speichern. Die Route braucht Schnittstelle, nächsten Hop, Policy-Tabelle und Version. Transport und Ports folgen als weitere Zuordnung. Authentisierung, Autorisierung und Anwendungsergebnis bleiben eigene Belege.

Damit lässt sich unterscheiden: Der Name löst auf, aber die Route fehlt. Der Host ist erreichbar, aber der Dienst nicht. Ein bekannter Port antwortet mit einem anderen Prozess. Der richtige Prozess authentisiert, führt die Operation aber nicht aus.

Der historische Wert von RFC 814 liegt in dieser Weigerung zur Überladung. Der Name war nicht die Adresse, die Adresse nicht die Route, die Route nicht der Prozess und der Port kein Beweis des Dienstes. Austauschbarkeit entstand, weil jede Schicht nur für ihre eigene Übersetzung einstand.

Quellen