Resumen

  • El RFC 906 propuso TFTP sobre IP como vía común para obtener el primer código de una máquina sin disco, en un entorno donde mantener el arranque de varios fabricantes podía exigir varios servidores.
  • En el ejemplo de Ross Finlayson para una estación Motorola 68000 con Ethernet, un ERROR no detenía la búsqueda: el primer DATA válido fijaba el interlocutor de la transferencia. El código en ROM ocupaba menos de 4 KB sin contar el controlador Ethernet; eso demuestra una implementación, no una adopción general.

Una estación podía usar los mismos protocolos de Internet que sus vecinas después de arrancar y, aun así, necesitar un mecanismo especial para llegar hasta ese punto. El sistema operativo todavía no podía pedir el archivo. Un programa guardado en memoria de solo lectura tenía que establecer la conexión suficiente para recibir el siguiente código.

El RFC 906, publicado por Ross Finlayson en junio de 1984, describe el costo práctico de ese límite. Los fabricantes habían recurrido a métodos distintos para cargar los primeros archivos. Una instalación con varios tipos de equipos podía necesitar distintas implementaciones de servidor de arranque, aunque las máquinas se comunicaran sin problemas una vez activas. El RFC propuso un protocolo común para esa primera transferencia: TFTP transportado por IP. El documento lo presenta como una propuesta para la comunidad de ARPA Internet y pide comentarios y mejoras; no dice que ya fuera una práctica universal.

La elección de TFTP era deliberadamente modesta. El programa enviaba una solicitud de lectura con el nombre del archivo, recibía paquetes DATA y devolvía confirmaciones o errores. El RFC consideraba aceptable que el primer tramo fuese lento: una segunda etapa podía usar un protocolo más rápido. El cliente debía recibir datagramas IP de hasta 524 octetos, sin incluir la cabecera IP: un paquete TFTP DATA de hasta 516 octetos más los 8 octetos de la cabecera UDP. La máquina que arrancaba no tenía que responder a solicitudes TFTP entrantes de lectura o escritura. Era un cliente reducido para recuperar código, no un servidor de archivos general.

El texto tampoco normalizaba toda la experiencia de arranque. Especificaba los protocolos de red, pero no cómo debía iniciar la máquina una persona ni qué orden debía escribir en la consola. Tampoco imponía Ethernet ni otro tipo de enlace. El intercambio común podía convivir con distintas rutinas locales para arrancar el equipo y escoger el archivo.

El ejemplo vuelve concreta esa separación. Finlayson describió una implementación en ROM para una estación Motorola 68000 sobre Ethernet. La persona introducía un nombre de archivo y podía indicar las direcciones de Internet de la estación y del servidor. Si no proporcionaba la dirección del servidor, varios servidores TFTP podían recibir la solicitud. La pregunta decisiva no era solo si alguien contestaba, sino qué respuesta cambiaba el estado del cliente.

La regla era precisa. Un paquete TFTP ERROR de un servidor no hacía que el cliente abandonara, porque otro servidor todavía podía enviar el archivo solicitado. El primer paquete DATA válido fijaba las direcciones Internet y Ethernet a las que se dirigirían las confirmaciones posteriores. Si más tarde llegaban datos desde otro servidor, el cliente le respondía con un ERROR. La solicitud podía llegar a varios equipos, pero una sola respuesta válida se convertía en el interlocutor de esa transferencia.

Esa regla puede parecer autenticación, pero no lo era. La revisión 2 de TFTP dice que el protocolo no ofrece mecanismos de autenticación del usuario. El criterio del primer DATA válido selecciona a quien responde; no demuestra que sea el servidor previsto por el operador ni que el archivo de arranque tenga un origen verificado por separado. Las fuentes no documentan un ataque ni un incidente de despliegue. Sí muestran dónde quedaba la decisión: en cómo el cliente procesaba las respuestas y en el entorno local que determinaba quién podía contestar.

La cifra de tamaño del código también tiene límites claros. La implementación descrita ocupaba menos de 4 KB, sin contar el controlador del dispositivo Ethernet. Eso indica que un autor pudo encajar el cliente en una ROM restringida. No es una medición aplicable a todos los procesadores, un recuento de instalaciones ni prueba de que desaparecieran los métodos propios de cada fabricante.

Los documentos posteriores aclaran la arquitectura, pero no demuestran una cadena directa de adopción. El RFC 951 de 1985 describe BOOTP como una primera fase para determinar la dirección y seleccionar el archivo; después, la transferencia solía usar TFTP. En 1989, el RFC 1123 describe el arranque de una máquina sin disco como dos pasos gestionados por un programa en ROM: configurar IP y cargar el código del sistema. Esos textos hacen explícita la separación entre preparación y transferencia; no convierten la única implementación citada por RFC 906 en una estadística de despliegue.

La importancia histórica del RFC 906 está en ese límite, no en una victoria consumada. Un programa pequeño en ROM podía pedir el siguiente archivo mediante IP, mientras el inicio de la máquina y parte de la elección del servidor seguían siendo decisiones locales. El primer DATA válido marcaba con claridad cuándo un servidor pasaba a ser el interlocutor. El protocolo permanecía acotado, pero el operador seguía siendo responsable de la fuente de código que respondiera primero.

La Note 65 posterior de Heng Lu aporta una disciplina editorial, no evidencia sobre las intenciones de Finlayson: una propuesta publicada y una implementación descrita no equivalen a despliegue y uso. La evidencia disponible demuestra una propuesta y un ejemplo. No permite saber cuántas instalaciones la adoptaron ni si eliminó el costo de soporte que señalaba.

Fuentes