Resumen

  • El cliente enviaba RRQ o WRQ al TID conocido 69, pero el servidor aceptante respondía desde un TID propio; ambos valores, usados como puertos UDP, delimitaban el intercambio restante.
  • El error 5 aislaba datagramas de otro TID sin cancelar la transferencia válida, y las correcciones y opciones posteriores conservaron esa frontera aunque aumentaran la cantidad de datos en vuelo.

Un arranque con memoria mínima

La popularidad histórica de TFTP en el arranque de nodos se entiende desde la restricción. RFC 1123 lo describía como lo bastante pequeño para una ROM y, a la vez, carente de control de acceso y seguridad propios. Su misión era leer o escribir un archivo, no reproducir las sesiones, directorios y autenticación de FTP.

Esa sencillez exigía que cada campo hiciera un trabajo preciso. El cliente elegía un identificador de transferencia y enviaba la petición al 69 del servidor. Al aceptar una lectura, el servidor enviaba DATA 1 desde otro TID; al aceptar una escritura, enviaba ACK 0. Los dos identificadores pasaban a UDP como puertos y se conservaban hasta terminar.

El 69 era una dirección de cita. Permitía encontrar al servidor antes de que existiera una conversación. La respuesta positiva decía cuál era el extremo servidor de esa conversación. Confundir ambos planos produce una paradoja operativa: el cortafuegos ve la petición correcta y bloquea la respuesta correcta porque esperaba que el archivo tuviera el mismo puerto de origen.

La pareja elegida clasificaba los datagramas

Después de aceptar la primera respuesta, el cliente debe verificar el TID fuente. Un número distinto no es un nuevo tramo de la misma transferencia. Se descarta y recibe el error 5, identificador de transferencia desconocido.

RFC 1350 ilustra el caso con una petición duplicada en la red. El servidor puede responder dos veces y escoger un TID diferente para cada copia. El cliente continúa con la respuesta que aceptó primero y rechaza la otra. No existe razón para que el segundo intento destruya al primero.

Por eso el puerto fuente incorrecto es el error reconocido que no termina la conexión TFTP. La mayoría de los ERROR anuncian un final y ni siquiera se confirman o retransmiten. Error 5 actúa sobre el datagrama ajeno y preserva el estado legítimo.

La protección es de clasificación, no de identidad fuerte. Un TID no demuestra quién opera el servidor, no impide por sí solo la suplantación de IP y no valida el archivo. Su afirmación es más modesta: el paquete coincide, o no, con los extremos elegidos para este intercambio.

El número de bloque reemplazó una cola

RFC 783 organizó la transferencia como una alternancia. Cada DATA tenía un número consecutivo y esperaba su ACK antes de que saliera el siguiente. El bloque ordinario medía 512 octetos. Uno más corto marcaba el final; un archivo de tamaño múltiplo exacto necesitaba un DATA vacío adicional.

Con una sola pieza pendiente, el emisor guardaba únicamente el bloque actual y el receptor no necesitaba reordenar. La combinación de TID, número y temporizador era la memoria de la transferencia. Un número siguiente avanzaba; uno antiguo era un duplicado; un TID extraño pertenecía fuera; un timeout podía justificar recuperar.

La última confirmación requería cautela. Quien enviaba el ACK final podía demorarse antes de cerrar. Si reaparecía el último DATA, repetía el ACK, porque era posible que el primero se hubiera perdido. Así, el cierre se definía por una conducta repetible ante la incertidumbre, no por una certeza unilateral.

Una recuperación que se copiaba a sí misma

La formulación temprana permitía que cualquiera de los dos lados, al recibir un datagrama duplicado antiguo, reenviara el actual. Tras un retraso y un timeout, una copia tardía podía producir otra respuesta; esa respuesta duplicada provocaba otra copia, y el patrón se repetía bloque tras bloque.

RFC 1123 llamó al defecto síndrome del aprendiz de brujo. No era necesario que cambiara un solo byte del archivo. Bastaba con duplicar tráfico hasta agravar la congestión, ampliar los retrasos y hacer que la transferencia expirara.

La corrección obligatoria fue retirar al ACK viejo la capacidad de ordenar un DATA nuevo: el originador de DATA no debe reenviar el bloque actual solo por recibir un ACK duplicado. El temporizador pertinente conserva autoridad para recuperar; el eco de un estado ya confirmado no. RFC 1350 sustituyó RFC 783 con esa conducta corregida.

Pedir opciones no era imponerlas

El lockstep de un bloque reducía código, pero desperdiciaba capacidad. RFC 2347 abrió un mecanismo de opciones conservando una regla de iniciativa: solo el cliente las añade a RRQ o WRQ. El servidor incluye en OACK únicamente las solicitadas que reconoce y acepta. Las no confirmadas se ignoran; una opción nunca pedida en OACK es un error.

En una lectura, ACK 0 acepta OACK. En una escritura, DATA 1 lo acepta. RFC 2348 negoció tamaño de bloque; RFC 2349, intervalo de retransmisión y tamaño total. RFC 7440 permitió enviar varios bloques consecutivos antes de esperar el ACK del último de la ventana.

Una ventana mayor cambia la cantidad de estado pendiente y el costo de una pérdida. No cambia los TID acordados ni convierte la negociación en acceso. Aumentar rendimiento sin conservar quién propuso, quién aceptó y qué valor rige volvería invisible la misma frontera que la extensión necesita.

El permiso para mover no estaba en el cable

TFTP no contiene autenticación de usuario. Tampoco decide qué raíz de archivos publicar, si una escritura es legítima, si una imagen de arranque tiene firma válida o si un equipo debe confiar en el servidor. Un intercambio puede ser impecable según sus TID y bloques y entregar el archivo equivocado con total precisión.

La operación segura depende de controles externos: limitar direcciones alcanzables, separar lectura y escritura, fijar raíces, verificar artefactos, registrar el vínculo entre petición y par dinámico, y abrir en NAT o cortafuegos solo el estado necesario. El número de puerto registrado no absuelve esas decisiones.

La contribución histórica de TFTP está en haber hecho visible una separación que sistemas mayores esconden en una sesión: el lugar donde se pide un servicio no tiene por qué ser el extremo que lo presta; un error puede proteger una conversación al negar pertenencia; y una señal repetida no debe recibir poder para multiplicar trabajo ya hecho.

Fuentes y límites

RFC 783 contiene el diseño temprano, RFC 1123 el arreglo de retransmisión y RFC 1350 la revisión vigente. RFC 2347, RFC 2348, RFC 2349 y RFC 7440 definen las opciones; el registro de IANA muestra el puerto 69. Las fuentes no son un censo de 2026 y no atribuyen a TID autenticación, cifrado, autorización ni integridad del archivo.