TFTP (Trivial File Transfer Protocol) – das einfache Dateiübertragungsprotokoll

Damit der Datenaustausch zwischen zwei Computersystemen im Netzwerk funktioniert, ist eine gemeinsame Verständigungsbasis unverzichtbar. Eines der einfachsten, zu diesem Zweck entwickelten Protokolle ist das Trivial File Transfer Protocol (TFTP), das insbesondere in den Anfängen des Internets eine wichtige Rolle gespielt hat.

Das Trivial File Transfer Protocol, kurz TFTP, ist ein sehr einfaches Client-Server-Protokoll, das den Transfer von Dateien in Computernetzwerken regelt. Eine erste Spezifikation wurde im Juni 1981 in RFC 783 veröffentlicht. Der aktuelle Standard ist im 1992 erschienenen RFC 1350 nachzulesen. Das TFTP-Protokoll setzt standardmäßig auf dem ebenfalls minimalistischen Transportprotokoll UDP (User Datagram Protocol) auf, das eine Datenübertragung ohne feste Verbindung zwischen den Kommunikationspartnern vorsieht. Die Implementierung von TFTP auf Basis anderer Protokolle ist grundsätzlich aber ebenfalls möglich.

Das paketorientierte Dateiübertragungsprotokoll, das Teil der TCP/IP-Protokollfamilie ist, wurde extra so konzipiert, dass es möglichst klein und leicht zu implementieren ist. Aus diesem Grund beschreibt es lediglich Methoden, um Dateien oder Mails von einem Server zu lesen bzw. auf diesen zu schreiben. Eine Auflistung von Verzeichnissen oder die Rechtevergabe über chmod – wie es das besser bekannte FTP (File Transfer Protocol) erlaubt – sind mit TFTP nicht möglich. Für Anfragen nutzt TFTP den Port 69. Im Anschluss gelingt die Kommunikation über individuell vergebene Port-Nummern (zwischen 1024 und 65535), die der TFTP-Server dem anfragenden Client in Form von TIDs (Transfer Identifiers) übermittelt.

Der Dateitransfer via TFTP basiert immer auf einer Client-Anfrage, bei der entweder Schreib- oder Lesezugriffe erbeten werden. Diese Anfrage dient gleichzeitig als Verbindungsgesuch, dem automatisch stattgegeben wird, wenn der Server den Zugriff akzeptiert. Im Anschluss senden Client oder Server die entsprechende Datei in Blöcken, die eine festgelegte Größe haben. In den ersten Protokollversionen galt dabei noch der fixe Wert von 512 Bytes – seit RFC 2348 haben Server und Client die Möglichkeit, die Blockgröße individuell auszuhandeln.

Der Versand findet Block für Block statt, wobei jeder empfangene Block durch ein Bestätigungspaket („Acknowledgement“) quittiert werden muss, bevor der nächste verschickt werden kann. Ein Datenpaket, das kleiner als die festgelegte Bytegröße ist, kennzeichnet das Ende des Dateitransfers. Geht ein Paket während des Transfers verloren, kommt es beim Empfänger zu einem Timeout, in dessen Folge er sein zuletzt geschicktes Paket erneut sendet. Auf diese Weise erfährt der Sender des verlorenen Pakets, dass er dieses erneut transferieren muss. Fehler, die während der TFTP-Dateiübertragung entstehen, führen zu Fehlerpaketen, die die Übertragung in den meisten Fällen beenden. Mögliche Fehlerquellen sind die folgenden drei Ereignisse:

• Die Anfrage kann nicht zufriedenstellend beantwortet werden, beispielsweise weil die Datei nicht gefunden wurde, weil der Nutzer nicht existiert oder aufgrund einer Zugriffsverletzung (geschützte Datei etc.).
• Client oder Server empfangen ein Paket, das nicht durch eine Verzögerung oder durch Duplizierung im Netzwerk erklärt werden kann, was etwa bei einem falsch gebildeten Paket der Fall ist.
• Der Zugriff auf eine notwendige Ressource geht verloren, z. B. wenn nicht mehr genügend Festplattenspeicher übrig ist.

Das TFTP-Protokoll unterstützt insgesamt fünf Typen von Paketen, die sich jeweils durch ein eigenes, 16 Bit langes „Opcode“-Feld (Operations-Code) mit dem entsprechenden Wert ankündigen:

Der opcode-Wert ist allerdings nicht die einzige Komponente, in der sich der Aufbau der aufgelisteten Paket-Typen unterscheidet.

Sowohl RRQ- als auch WRQ-Nachrichten starten mit dem protokolltypischen, 16 Bit langen Opcode-Feld. Wie die erste Tabelle zeigt, nutzen RRQ-Pakete an dieser Stelle den Wert „1“, während WRQ-Pakete durch den Wert „2“ gekennzeichnet sind. Es folgt eine Bit-Sequenz im NetASCII-Format mit variabler Größe; diese enthält den Namen der Datei, die gelesen bzw. gesendet werden soll. Das Ende kennzeichnet ein aus Nullen bestehendes 8-Bit-Feld.

Eine weitere Zeichenkette, deren Länge variabel ist, enthält schließlich die Information über den Transfermodus der Daten. Hierbei gibt es die drei Varianten „netascii“, „octet“ (für den Transfer einer Datei im 8-Bit-Format) und „mail“ (für den Transfer an eine E-Mail-Adresse). Auch das Ende dieses Felds wird durch eine angehängte 8-Bit-Gruppe aus Nullen gekennzeichnet.

Auch DATA-Pakete beginnen mit dem Opcode-Feld, dem in diesem Fall der Wert „3“ zugeordnet wird. Die darauffolgende 16-Bit-Sequenz kennzeichnet die Nummer des Datenblocks, wobei der Wert „1“ als Startnummer dient. Dieser Wert erhöht sich mit jedem weiteren Datenblock, der zu der Datei gehört, automatisch um 1. Die Blöcke selbst finden sich derweil im Datenfeld wieder, das zwischen 0 und 512 Bytes (4096 Bit) groß ist, sofern TFTP-Server und -Client keine andere Maximalgröße für die Blöcke ausgehandelt haben. Wird die jeweilige Maximalgröße ausgefüllt, ist dies ein Signal dafür, dass das DATA-Paket nicht den letzten Datenblock der Datei enthält. Dieser letzte Block, der das Ende des Datentransfers kennzeichnet, ist immer um mindestens ein Byte kleiner. Sollte der zu übertragende Dateirest zufällig exakt die Größe des Blocks haben, muss der Sender noch ein Paket mit leerem Datenblock nachreichen.

Alle WRQ-Pakete sowie alle Datenpakete, die nicht das Ende des Dateitransfers kennzeichnen, werden bei funktionierender Kommunikation über das Trivial File Transfer Protocol durch ACK-Nachrichten bestätigt (außer es kommt zu einem Timeout).

Die ACK-Nachrichten der TFTP-Protokoll-Kommunikation bestehen aus dem 16 Bit langen Opcode, der den Wert „4“ annimmt, und der ebenfalls 16 Bit langen Nummer des Datenblocks, den die ACK-Nachricht bestätigt. Handelt es sich um eine Antwort auf eine WRQ-Anfrage, hat das ACK-Paket die Datenblock-Nummer „0“.

Nach dem auch in ERROR-Nachrichten voranstehenden Opcode (Wert „5“) folgt ein 16 Bit langes Feld, das den Fehlercode enthält. So steht der Wert „1“ beispielsweise dafür, dass die entsprechende Datei nicht gefunden werden konnte, während der Wert „6“ dem empfangenden System verrät, dass die Datei bereits existiert. Die sich anschließende Fehlernachricht hilft dem Nutzer, das Problem zu verstehen. Auch aus diesem Grund ist diese Zeichenkette mit variabler Größe typischerweise im NetASCII-Format. Den Abschluss bildet ein 8-Bit-Feld aus Nullen.

TFTP überzeugt in erster Linie durch seine Schlichtheit. Das Protokoll soll das Schreiben und Lesen von Dateien ermöglichen und erfüllt diese Rolle, ohne dass eine Verbindung zwischen Client und Server etabliert werden muss. In der Konsequenz ist das TFTP-Protokoll nicht nur einfach zu implementieren, sondern auch Wegbereiter einer schnellen Dateiübertragung. Individuelle Transfer Identifier (TIDs) und einzigartige Datenblock-Nummern schaffen dabei die Basis dafür, dass die jeweilige Datei vollständig beim Empfänger ankommt.

Das Fehlen einer Verschlüsselung sowie eines Authentifizierungs- bzw. Zugriffskontrollmechanismus macht den Versand sensibler Dateien via TFTP allerdings zu einer höchst riskanten Angelegenheit, weshalb hierfür sicherere Alternativen wie das komplexere FTP eingesetzt werden sollten. Ferner ist das Löschen und Umbenennen von Dateien auf vielen TFTP-Servern nicht erlaubt.

Das TFTP-Protokoll ist eng an das sogenannte Netzwerk-Booting (auch „Bootstrapping“) geknüpft. Bei dieser Technik, die insbesondere in den 1980er Jahren zum Einsatz kam, bezieht und startet ein Netzwerk-Computer das Betriebssystem von einem zentralen Server. Insbesondere für Terminals und festplattenlose Workstations, die keine Installation eines eigenen Betriebssystems ermöglichten, war die Entwicklung und Implementierung von TFTP daher von entscheidender Bedeutung. Unterstützung fand das Dateiübertragungsprotokoll durch das 1985 veröffentlichte BOOTP, durch das die Netzwerk-Clients die Adresse des TFTP-Servers automatisch beziehen konnten.

Heute kommt das Trivial File Transfer Protocol wesentlich seltener zum Einsatz. In Netzwerken, deren Teilnehmer heutzutage standardmäßig über eigene Betriebssysteme verfügen, ist die Netzwerk-Boot-Methode nur noch vereinzelt und in abgewandelter Form wiederzufinden. So können beispielsweise Systeminstallationen, Wartungen, Firmware-Updates oder Virus-Scans über sogenannte Hilfsbetriebssysteme zu einer Reduzierung des Administrationsaufwands beitragen. Auch in den nicht flüchtigen Festwertspeichern (ROM-Speichern) sind Implementierungen von TFTP nicht ungewöhnlich, da diese dank der Verbindungslosigkeit des Protokolls nur wenig Aufwand bedeuten. Ferner dienen TFTP-Server zur Absicherung von Konfigurationen und System-Images von Cisco-Routern und -Switches sowie zur Ablage von Gebührendatensätzen bei Siemens-Telefonanlagen.