Zusammenfassung

  • RFC 1118 setzte voraus, dass ein Standort einige IP-Hosts auf Ethernet betreiben konnte, aber noch nicht mit dem Internet verbunden war.
  • Der Text erklärte Adressvergabe, Eskalationswege und Informationsdienste und stellte zugleich klar: Er ist weder Standard noch Lehrbuch.

Die erste Hürde beim Anschluss war nicht allein technischer Art. Ein Campus konnte funktionierende IP-Hosts haben und trotzdem keine eindeutige Netznummer besitzen, den zuständigen Betreiber im Upstream nicht kennen oder die Folgen lokaler Entscheidungen für andere Netze nicht einschätzen. RFC 1118 aus dem September 1989 richtete sich an genau diese Lücke. Sie setzte ein kleines, bereits betriebenes, aber isoliertes IP-Netz voraus und wollte dessen Anschluss ermöglichen, ohne eine Seite unnötig zu gefährden.

Diese Grenze bestimmte die Form des Dokuments. Es definierte kein neues Protokoll, sondern sammelte Verweise, Literatur und Hinweise, die laut Autor oft nicht niedergeschrieben wurden. Es erklärte, wie neue Teilnehmer die Ausrichtung des Internets verstehen, Online-Informationen finden und sich als gute Netzwerknachbarn verhalten konnten. Im Mittelpunkt stand der Übergang von lokaler Betriebskompetenz zur Teilnahme an einem Verbund unabhängiger Netze.

Die Betriebsstruktur war verteilt. ARPANET, NSFNET und regionale Netze verfügten über eigene Network Operations Centers. Trat bei einem Campus am regionalen Netz ein Problem auf, sollte dessen Ansprechpartner den direkt angeschlossenen Betreiber kontaktieren, auch wenn das Regionalnetz über Gateways NSFNET und ARPANET erreichte. Der Eskalationsweg folgte der tatsächlichen Betriebsbeziehung. Ein neuer Standort musste nicht zuerst beim bekanntesten Backbone anrufen.

Auch die Adressvergabe gehörte zum Eintritt. RFC 1118 beschrieb den Antrag beim SRI-NIC auf eine eindeutige IP-Netznummer. Sie erläuterte die damalige klassenbasierte Zuteilung und den Druck auf Gateway-Tabellen, als die Zahl der Netze wuchs. RFC 950 legte das Subnetzverfahren formal fest; RFC 1009 formulierte Anforderungen an Internet-Gateways. RFC 1118 ordnete diese Dokumente in Entscheidungen ein, die Campus-Verwalter treffen mussten. Hinweise zu Klasse A, B und C und zu NIC-Kontakten gehören ins Jahr 1989; sie sind kein heutiger Anschlussleitfaden.

Sicherheit war eine wechselseitige Pflicht. Laut RFC 1118 war das Internet zunächst für etwa 50 Netze ausgelegt, näherte sich aber bereits 1.000; Gateway-Kapazität und Überlastung wurden zum Problem. Viele Gateways vertrauten Routing-Informationen, sodass ein bösartiges Gateway erheblichen Schaden anrichten konnte. Das belegt keinen konkreten Angriff. Es zeigt, weshalb ein Anschluss mehr bedeutete, als einen Host erreichbar zu machen: Eine Routenankündigung konnte den Verkehr weit außerhalb des Campus beeinflussen.

Informationsdienste gehörten ebenfalls zu dieser Karte. Das Dokument verwies auf das SRI-NIC und unterschied dessen Angebote von BBN-Diensten für CSNET und NSFNET sowie Merit-Diensten für NSFNET. Telnet, FTP, E-Mail, Mailinglisten und Betreiberkontakte boten unterschiedliche Wege zu Informationen. Es gab keine zentrale Stelle für jede Frage. Neue Teilnehmer mussten erkennen, welche Institution wofür zuständig war.

Der redaktionelle Hinweis war ungewöhnlich offen. RFC 1118 stellte klar, dass sie keine Standards festlegte, räumte eine uneinheitliche Bearbeitung ein und scherzte über mögliche Fehler. Weil das Internet dynamisch sei, sollte das Dokument regelmäßig geändert werden. Das beschreibt eine Wartungsabsicht, beweist aber weder, dass jede Überarbeitung erfolgte, noch dass alle Standorte dem Leitfaden folgten. RFC 1123 formulierte im folgenden Monat Host-Anforderungen für Anwendungen und unterstützende Protokolle in einer stärker normativen Textsorte. Dadurch wurde RFC 1118 weder zum Protokoll noch verlor sie ihren betrieblichen Zweck.

RFC 1118 dokumentiert eine Ebene, die technische Spezifikationen leicht auslassen: Für den Internetanschluss musste man einen Betreiber finden, eine Adresse erhalten, aktuelle Informationen beschaffen und die Erwartungen benachbarter Netze verstehen. Das Eingeständnis möglicher Fehler macht dieses Wissen nicht wertlos; es macht seine Haltbarkeit zum Thema. Ein Leitfaden für ein dynamisches Internet war eine datierte Karte, die bestätigt werden musste, kein Beweis für einen sicheren Weg oder eine erfolgreiche Ankunft.

Quellen