Zusammenfassung

  • RFC 1009 verlangte im NSF-Kontext mindestens Ethernet und serielle Verbindungen, damit Gateways verschiedener Anbieter auf Netzwerkebene gekoppelt werden konnten.
  • Der Anhang trennte den Anschluss vom Routing: Ein offenes IGP, das Gateways verschiedener Anbieter in ein gemeinsames autonomes System brachte, gab es damals nicht.
  • Das Dokument belegt eine Anforderung des NSF-Programms und die beschriebenen Verfahren, nicht die allgemeine Einhaltung oder eine erfolgreiche Paketübertragung.

Ein gemeinsamer Anschluss war noch keine gemeinsame Route

Zwei Gateways konnten über Ethernet verbunden sein und trotzdem unterschiedliche Verfahren zur Wahl des nächsten Hops verwenden. RFC 1009 stellte beides nebeneinander. Sein Anhang B verlangte einen gemeinsamen Verbindungspunkt für NSF-Gateways, hielt aber zugleich fest, dass ein offenes IGP für mehrere Anbieter innerhalb eines autonomen Systems fehlte. Ein aktiver Link allein bewies deshalb noch keinen nutzbaren Pfad.

RFC 1009 erschien im Juni 1987 als formale Anforderung an Internet-Gateways und als Leitfaden für Hersteller. Ein Gateway war darin ein IP-Router mit Anschlüssen an mindestens zwei Paketnetze. Es musste die lokalen Bedingungen jedes Netzes beachten: Rahmenformat, maximale Übertragungseinheit, Adressübersetzung sowie vorhandene Fluss- und Fehlerkontrolle. Danach hatte es das Datagramm weiterzuleiten und anhand seiner Routingdatenbank einen nächsten Hop zu wählen.

Die Einleitung erklärt, dass das Dokument speziell die NSF-Forschungsprogramme unterstützen sollte, obwohl es die Anforderungen in einem allgemeinen Internet-Kontext formuliert. Der Anhang B trägt den engeren Titel „NSFNET Specific Requirements“. Abschnitt B.2 verlangt für die Netzwerk-Interoperabilität verschiedener Anbieter in diesem Rahmen mindestens Ethernet- und serielle Protokollanschlüsse.

Ethernet war aus praktischen Gründen geeignet. RFC 1009 beschreibt die Technologie als ausgereift, weit verbreitet und weitgehend anbieterunabhängig. Sie sollte den gemeinsamen Übergabepunkt zwischen NSF-Netzen verschiedener Lieferanten bilden. Ein Unternehmen durfte intern eine proprietäre Vermittlung einsetzen; sein Gateway musste außen trotzdem eine Ethernet-Verbindung zum Gateway eines anderen Anbieters bereitstellen. Gemeinsam war damit der Anschluss, nicht der gesamte interne Aufbau.

Der Austausch von Routen blieb ein eigenes Problem

Ethernet transportiert Datagramme über einen passenden Link, sagt dem Router aber nicht, welcher Nachbar den Weg zum Ziel kennt. Abschnitt B.3 stellt fest, dass es damals kein offenes IGP gab, mit dem Gateways unterschiedlicher Hersteller ein gemeinsames autonomes System bilden konnten. Das Dokument listet mehrere Verfahren, die tatsächlich verwendet wurden.

Mindestens ein Anbieter nutzte ein eigenes IGP und EGP für den Anschluss an das übrige Internet. RIP hatte zwar die Zusammenarbeit mehrerer Hersteller ermöglicht, war aber nicht dokumentiert; die Implementierungen unterschieden sich in Einzelheiten. Die NSF-Netzgemeinschaft entwickelte außerdem einen Gateway-Daemon, der mehrere Protokolle vermitteln konnte. Der Prototyp lief auf einem 4.3BSD-Rechner, sprach intern RIP und Hello und nutzte EGP gegenüber anderen autonomen Systemen.

Diese Komponenten lösten verschiedene Aufgaben: Ethernet stellte die gemeinsame Verbindung bereit, RIP oder der Daemon tauschten beziehungsweise übersetzten Routinginformationen, und EGP verband autonome Systeme. Keiner dieser Begriffe belegt für sich, dass alle Geräte dieselbe Route berechneten, sie installierten oder ein Paket tatsächlich zustellten.

RFC 1009 hält damit einen Zwischenstand fest: Die NSF konnte einen vorhersehbaren Anschluss zwischen Anbietern verlangen, bevor ein gemeinsames Verfahren zur Routenberechnung existierte. RFC 1812 löste das Dokument 1995 ab. Die Dokumentenfolge verrät jedoch nicht, wie ein bestimmter Hersteller die Vorgabe umsetzte oder ein bestimmtes Netz migrierte.

Eine spätere Gestaltungsbrille

Lu Hengs spätere Note 64 schlägt Jahrzehnte später vor, gemeinsame Spezifikationen auf die für Interoperabilität nötigen Regeln zu beschränken und andere Entscheidungen bei den Betreibern zu belassen. Diese Perspektive hilft, RFC 1009s Grenze zwischen Ethernet-Anschluss und interner Herstellertechnik zu lesen. Die Fälle sind nicht gleich: Die NSF-Regel galt im Rahmen eines Programms und einer Beschaffung. Sie war keine freiwillige Änderung für das ganze Internet, und sie formuliert nicht die spätere Lehre von Note 64.

Quellen und Grenzen

Die Hauptquelle ist RFC 1009, insbesondere Anhang B.2–B.3. RFC 985 war der vorherige Entwurf; RFC 1812 folgte später. Diese Dokumente belegen Anforderungen und berichtete Verfahren, aber weder ein konkretes Produkt, dessen Einsatz, eine konvergierte Route noch die Zustellung von Datenverkehr.