Zusammenfassung

  • RFC 906 schlug TFTP über IP als gemeinsamen Weg vor, den ersten Code auf einen plattenlosen Rechner zu laden. Zuvor konnten unterschiedliche Herstellerverfahren mehrere Bootserver-Implementierungen erforderlich machen.
  • In Ross Finlaysons Beispiel für eine Motorola-68000-Workstation mit Ethernet beendete ein ERROR die Suche nicht; erst das erste gültige DATA-Paket legte den Transferpartner fest. Der ROM-Code war kleiner als 4 KB, ohne Ethernet-Treiber. Das belegt eine Implementierung, keine breite Einführung.

Eine Workstation konnte nach dem Start dieselben Internetprotokolle wie ihre Nachbarn sprechen und trotzdem einen eigenen Weg benötigen, um überhaupt dorthin zu gelangen. Das Betriebssystem lief noch nicht und konnte keine Datei anfordern. Ein kleines Programm im Nur-Lese-Speicher musste erst genug Netzwerk aufbauen, um den nächsten Code zu laden.

Ross Finlaysons RFC 906 vom Juni 1984 beschreibt die praktische Reibung an dieser Grenze. Verschiedene Hersteller nutzten unterschiedliche Verfahren, um die ersten Dateien zu laden. Eine Einrichtung, die mehrere Rechnertypen betrieb, musste deshalb womöglich mehrere Bootserver-Implementierungen vorhalten, obwohl die Maschinen nach dem Start problemlos miteinander kommunizieren konnten. RFC 906 schlug für den ersten Transfer ein gemeinsames Protokoll vor: TFTP über IP. Das Dokument bezeichnet sich selbst als Vorschlag für die ARPA-Internet-Gemeinschaft und bittet um Diskussion und Verbesserungsvorschläge.

Es behauptet nicht, das Verfahren sei bereits allgemein üblich gewesen.

Die Wahl von TFTP war bewusst bescheiden. Das Bootprogramm sandte eine Leseanforderung mit Dateinamen, empfing danach DATA-Pakete und antwortete mit Bestätigungen oder Fehlern. Ein langsamer Ersttransfer sei vertretbar, erklärte der RFC, weil eine spätere Stufe ein schnelleres Protokoll verwenden könne. Der Client musste IP-Datagramme bis zu 524 Oktetts ohne IP-Header empfangen können: höchstens 516 Oktetts für ein TFTP-DATA-Paket plus 8 Oktetts für den UDP-Header. Der startende Rechner musste nicht auf eingehende TFTP-Lese- oder Schreibanforderungen reagieren.

Es ging um einen begrenzten Client zum Laden von Code, nicht um einen allgemeinen Dateiserver.

Der RFC standardisierte auch nicht den gesamten Startvorgang. Er legte nur die Netzwerkprotokolle fest. Wie eine Person den Rechner startete oder welchen Befehl sie an der Konsole eingab, blieb offen; ebenso war kein bestimmtes Datenlink-Verfahren wie Ethernet vorgeschrieben. Ein gemeinsamer Paketaustausch konnte also mit unterschiedlichen lokalen Abläufen zum Starten und zur Dateiauswahl zusammenarbeiten.

Das beschriebene Beispiel macht die Trennung greifbar. Finlayson meldete eine ROM-Implementierung für eine Motorola-68000-Workstation mit Ethernet. Die Person gab einen Dateinamen ein und konnte die Internetadressen der Workstation und eines Servers ergänzen. Fehlte die Serveradresse, konnten mehrere TFTP-Server die Anforderung empfangen. Entscheidend war dann nicht nur, ob jemand antwortete, sondern welche Antwort den Zustand des Clients änderte.

Die Regel war eindeutig. Ein TFTP-ERROR von einem Server brach den Vorgang nicht ab, weil ein anderer Server die Datei noch senden konnte. Das erste gültige DATA-Paket legte die Internet- und Ethernet-Quelladressen fest, an die spätere ACKs gingen. Meldete sich danach ein anderer Server mit DATA, erhielt er einen ERROR. Die Anforderung konnte mehrere Server erreichen, aber eine gültige erste Antwort machte einen davon zum Partner dieser Übertragung.

Das kann wie eine Authentifizierung wirken, ist aber keine. TFTP Revision 2 sagt ausdrücklich, dass das Protokoll keine Benutzer-Authentifizierung vorsieht. RFC 906 wählt mit seiner Regel einen Antwortgeber aus; sie beweist weder, dass dieser Server der vom Betreiber gewünschte ist, noch dass die Herkunft des Boot-Abbilds unabhängig geprüft wurde. Die Quellen berichten weder von einem Angriff noch von einem Einsatzvorfall. Sie zeigen, wo der Vorschlag die Entscheidung ansiedelte: in der Antwortlogik des Clients und in der lokalen Umgebung, die bestimmte, wer antworten konnte.

Auch die Größenangabe für den Code ist eng begrenzt zu lesen. Die beschriebene Implementierung umfasste weniger als 4 KB, ohne Ethernet-Gerätetreiber. Das zeigt, dass ein Autor den Client in ein knappes ROM-Design einpassen konnte. Es ist keine Messung für andere Prozessoren, keine Installationszahl und kein Nachweis dafür, dass herstellerspezifische Bootverfahren verschwanden.

Spätere Dokumente erklären die Architektur, belegen aber keine direkte Einführungskette. RFC 951 von 1985 beschreibt BOOTP als erste Phase zur Adressbestimmung und Auswahl der Bootdatei; der anschließende Dateitransfer sollte typischerweise TFTP verwenden. RFC 1123 beschreibt 1989 ebenfalls zwei Phasen beim Start plattenloser Rechner durch ein Boot-ROM-Programm: IP konfigurieren und danach den Systemcode laden. Diese Texte machen die Trennung von Vorbereitung und Transfer deutlicher. Sie verwandeln die eine in RFC 906 erwähnte Implementierung nicht in eine Verbreitungsstatistik.

Die historische Bedeutung von RFC 906 liegt daher in einer Grenze, nicht in einem vollendeten Siegeszug. Ein kleines Programm im ROM konnte die nächste Datei über IP anfordern, während Startbefehl und Teile der Serverwahl lokal blieben. Das erste gültige DATA-Paket markierte klar, wann ein Antwortgeber zum Transferpartner wurde. So blieb das Protokoll überschaubar; zugleich blieb es Aufgabe der Betreiber, die zuerst antwortende Codequelle zu kennen.

Heng Lus spätere Note 65 dient hier als redaktionelle Leitlinie, nicht als Beleg für Finlaysons Absicht: Ein veröffentlichter Vorschlag, eine gemeldete Implementierung, tatsächliche Einführung und Nutzung sind unterschiedliche Belege. Nachweisbar sind der Vorschlag und ein Beispiel. Wie viele Einrichtungen ihn einsetzten oder ob er die beschriebenen Supportkosten senkte, bleibt offen.

Quellen