TFTP (Trivial File Transfer Protocol): un protocolo muy simple para la tra­n­s­fe­re­n­cia de archivos

Para que dos sistemas in­fo­r­má­ti­cos puedan in­te­r­ca­m­biar datos en la red, es in­di­s­pe­n­sa­ble disponer de una base de co­mu­ni­ca­ción común. Uno de los pro­to­co­los más simples de­sa­rro­lla­dos con este fin es el Trivial File Transfer Protocol (TFTP), un protocolo que tuvo mucha im­po­r­ta­n­cia durante los primeros tiempos de Internet.

El protocolo Trivial File Transfer Protocol, en su forma abreviada TFTP, es un protocolo cliente-servidor muy simple que regula la tra­n­s­fe­re­n­cia de archivos en redes in­fo­r­má­ti­cas. Se definió ori­gi­na­l­me­n­te en junio de 1981 en el RFC 783, si bien en la ac­tua­li­dad está vigente el estándar RFC 1350, publicado en 1992. Por defecto, el protocolo TFTP se basa en el protocolo mínimo de nivel de tra­n­s­po­r­te UDP (User Datagram Protocol), que ofrece la po­si­bi­li­dad de tra­n­s­mi­tir datos sin necesidad de una conexión fija entre los miembros de la co­mu­ni­ca­ción. No obstante, también es posible im­ple­me­n­tar el protocolo TFPT basándose en otros pro­to­co­los di­fe­re­n­tes.

Se trata de un protocolo de tra­n­s­fe­re­n­cia de archivos que funciona mediante paquetes de datos. Forma parte de la familia de pro­to­co­los TCP/IP y fue es­pe­cí­fi­ca­me­n­te diseñado para que su im­ple­me­n­ta­ción fuese lo más sencilla y ligera posible. Por esta razón, su fu­n­cio­na­li­dad consiste pri­n­ci­pa­l­me­n­te en la lectura o escritura de un archivo o un correo ele­c­tró­ni­co de un servidor. Sin embargo, con el protocolo TFTP no es posible listar di­re­c­to­rios o es­ta­ble­cer permisos usando chmod. TFTP utiliza el puerto 69. Po­s­te­rio­r­me­n­te, la co­mu­ni­ca­ción se produce a través de números de puerto asignados in­di­vi­dua­l­me­n­te (entre el 1024 y el 65535), que el servidor del protocolo TFTP envía al cliente so­li­ci­ta­n­te a través de ide­n­ti­fi­ca­do­res TID (Transfer Ide­n­ti­fie­rs)

La tra­n­s­fe­re­n­cia de archivos a través de TFTP se basa siempre en una solicitud de acceso del cliente, bien de lectura bien de escritura. Esta solicitud funciona al mismo tiempo como petición de conexión que se concede au­to­má­ti­ca­me­n­te en el momento en el que el servidor acepta el acceso. A co­n­ti­nua­ción, el cliente o el servidor envía el archivo que co­rre­s­po­n­da en bloques de tamaño fijo. En las primeras versiones del protocolo, se utilizaba un valor fijo de 512 bytes pero, a partir del RFC 2348, el servidor y el cliente tienen la po­si­bi­li­dad de negociar en cada caso el tamaño del bloque.

La tra­n­s­fe­re­n­cia se realiza bloque a bloque. El servidor no envía un nuevo bloque hasta que reciba el paquete de co­n­fi­r­ma­ción del bloque anterior. El paquete de datos final se ide­n­ti­fi­ca por ser más pequeño del tamaño es­ta­ble­ci­do. Si un paquete se pierde se generará un timeout, tras el que se efectuará la re­tra­n­s­mi­sión del último paquete. De esta manera, el emisor del paquete perdido sabrá que tiene que re­tra­n­s­mi­tir dicho paquete. Cualquier error que ocurra al tra­n­s­fe­rir archivos mediante TFTP dan lugar a paquetes de error que en la mayoría de los casos causan la fi­na­li­za­ción de la tra­n­s­fe­re­n­cia. Las posibles causas de error son:

• No es posible aceptar una solicitud de tra­n­s­fe­re­n­cia, por ejemplo, porque el archivo no se ha podido encontrar, el usuario no existe o se ha producido una violación de permisos (archivo protegido, etc.).
• Los clientes o se­r­vi­do­res reciben un paquete que no se puede explicar por un retraso o du­pli­ca­ción en la red. Es el caso, por ejemplo, de paquetes con formato in­co­rre­c­to.
• Se pierde el acceso a un recurso necesario, por ejemplo, si no hay espacio en el disco duro.

El protocolo TFTP utiliza cinco tipos de paquetes, cada uno de los cuales empieza con un campo de código de operación de 16 bits (Ope­ra­tio­ns Code) con el valor co­rre­s­po­n­die­n­te:

Sin embargo, el valor del código de operación no es el único co­m­po­ne­n­te que distingue la es­tru­c­tu­ra de los tipos de paquetes listados.

Los mensajes RRQ y WRQ empiezan los dos con el campo de código de la operación de 16 bits que ca­ra­c­te­ri­za al protocolo. Como se muestra en la primera tabla, los paquetes RRQ utilizan el valor "1", mientras que los paquetes WRQ utilizan el valor "2". A esto le sigue una secuencia de bits en formato NetASCII de tamaño variable que contiene el nombre del archivo que hay que leer o enviar. Este campo de 8 bits está formado por ceros.

Otra cadena de longitud variable contiene la in­fo­r­ma­ción sobre el modo de tra­n­s­fe­re­n­cia de los datos. Se definen tres variantes “netascii”, "octeto” (para tra­n­s­fe­rir datos de 8 bits) y “mail” (para efectuar la tra­n­s­fe­re­n­cia a una dirección de correo). El final de este campo se indica mediante un grupo de ceros de 8 bits.

Los paquetes DATA también comienzan con el campo de código de operación que, en este caso, tiene asignado el valor "3". La siguiente secuencia de 16 bits ide­n­ti­fi­ca el número del bloque de datos, donde el valor "1" sirve como número de inicio. Este valor se in­cre­me­n­ta au­to­má­ti­ca­me­n­te de uno en uno con cada bloque de datos adicional asociado al archivo. Los bloques pe­r­te­ne­cen al campo de datos y tienen un tamaño de 0 a 512 bytes (4096 bits), a menos que el servidor y el cliente TFTP hayan es­ta­ble­ci­do un tamaño máximo diferente para los bloques. El último bloque, con el que se indica el final de la tra­n­s­fe­re­n­cia, es al menos un bit más pequeño del tamaño máximo es­ti­pu­la­do. Es decir, con un tamaño por bloque de 512 bytes, el último bloque tendría de 0 a 511 bytes. Si se da el caso de que el último paquete con el resto de archivos tuviese el mismo tamaño que los bloques an­te­rio­res, el remitente todavía haría llegar un paquete con un bloque de datos vacío.

Todos los paquetes WRQ, así como todos los paquetes de datos que no marcan el final de la tra­n­s­fe­re­n­cia de archivos, deben ser co­n­fi­r­ma­dos mediante un mensaje ACK siempre y cuando el Trivial File Transfer Protocol funcione co­rre­c­ta­me­n­te (salvo que se produzca un timeout).

Los mensajes ACK uti­li­za­dos en la co­mu­ni­ca­ción del protocolo TFTP están formados por un código de operación de 16 bits, que toma el valor "4", y el número de 16 bits del bloque de datos que confirma el mensaje ACK. Si se trata de una respuesta a una solicitud WRQ, el paquete ACK tiene como número de bloque de datos el valor "0".

Al código de operación con valor "5", que aparece en los mensajes de ERROR, le sigue un campo de 16 bits con el código de error. Por ejemplo, el valor "1" significa que no se pudo encontrar el archivo co­rre­s­po­n­die­n­te, mientras que el valor "6" indica al receptor que el archivo ya existe. El mensaje de error que se muestra ayuda al usuario a co­m­pre­n­der el problema. Ese es uno de los motivos por el que esta cadena de longitud variable se encuentra no­r­ma­l­me­n­te en formato NetASCII. El paquete contiene al final un campo de 8 bits formado por ceros.

Una de las pri­n­ci­pa­les ventajas del protocolo TFTP es su si­m­pli­ci­dad, pues está diseñado para permitir la escritura y la lectura de archivos sin tener que es­ta­ble­cer una conexión entre el cliente y el servidor. Por ello, el protocolo TFTP no solo es fácil de im­ple­me­n­tar, sino que también es el precursor de la tra­n­s­fe­re­n­cia rápida de archivos. Los ide­n­ti­fi­ca­do­res TID y los números de bloque de datos únicos hacen que el archivo llegue en su totalidad al de­s­ti­na­ta­rio.

Sin embargo, la falta de cifrado y de un mecanismo de control de au­te­n­ti­ca­ción y acceso hacen que el envío de archivos co­n­fi­de­n­cia­les a través del protocolo TFTP suponga riesgos altos. En su lugar, pueden uti­li­zar­se otras al­te­r­na­ti­vas más seguras como FTP, un protocolo más complejo. Además, muchos se­r­vi­do­res TFTP no permiten eliminar y renombrar archivos.

El protocolo TFTP está es­tre­cha­me­n­te re­la­cio­na­do con el llamado arranque en la red (también conocido como "boots­tra­p­pi­ng"). Con esta técnica, que se utilizó es­pe­cia­l­me­n­te en la década de los años 80, un ordenador de red obtiene e inicia el sistema operativo desde un servidor central. Es­pe­cia­l­me­n­te en el caso de te­r­mi­na­les y es­ta­cio­nes de trabajo sin disco duro, que no permitían la in­s­ta­la­ción de su propio sistema operativo, el de­sa­rro­llo y la im­ple­me­n­ta­ción del protocolo TFTP fue crucial. El protocolo de tra­n­s­fe­re­n­cia de archivos era co­m­pa­ti­ble con BOOTP, publicado en 1985, que permitía a los clientes de la red obtener de forma au­to­má­ti­ca la dirección del servidor TFTP.

Hoy en día, el protocolo Trivial File Transfer Protocol ya no es tan popular. En las redes donde los usuarios disponen de sus propios sistemas ope­ra­ti­vos de forma estándar, el método de arranque solo se encuentra de forma aislada y mo­di­fi­ca­da. Por ejemplo, las in­s­ta­la­cio­nes del sistema, el ma­n­te­ni­mie­n­to, las ac­tua­li­za­cio­nes de firmware o los análisis de virus pueden ayudar a reducir la so­bre­ca­r­ga ad­mi­ni­s­tra­ti­va a través de los llamados sistemas ope­ra­ti­vos au­xi­lia­res. También en el caso de las memorias de solo lectura (ROM), es frecuente encontrar im­ple­me­n­ta­cio­nes de TFTP debido a que requieren poco esfuerzo, pues este protocolo no exige que haya una conexión. Además, los se­r­vi­do­res TFTP se utilizan para guardar las co­n­fi­gu­ra­cio­nes y crear copias de seguridad de la imagen CISCO IOS y para almacenar los registros de carga de las centrales de Siemens.