Summary

  • En 1985, BOOTP permitía que un cliente sin disco solicitara una dirección y los datos para cargar un archivo antes de poder enviar una petición IP normal a un servidor. Un relé podía llevar el intercambio más allá de la red local.
  • giaddr describía la ruta de retransmisión propia de BOOTP. RFC 1542 aclaró después que no era el router IP general ni la ruta predeterminada del cliente.

El equipo necesita ayuda antes de poder pedirla

Al encenderse, una estación de trabajo sin disco se encontraba con un problema circular: necesitaba una dirección de Internet para usar IP, pero dependía de la red para averiguar cuál debía usar. También tenía que descubrir qué servidor y archivo continuarían el arranque. Si el servidor estaba en otra red, una difusión local no podía atravesar por sí sola los routers ordinarios.

RFC 951, publicado en septiembre de 1985, presentó BOOTP como la primera fase: determinar la dirección y seleccionar el archivo de arranque. El cliente enviaba una petición con su dirección de hardware y, si la conocía, su dirección IP. Si ciaddr era cero, el servidor podía buscar la dirección de hardware en su base de datos y devolver la dirección del cliente en yiaddr. Otros campos identificaban el servidor y el archivo. Las peticiones y respuestas usaban UDP en los puertos 67 y 68.

La respuesta no cargaba el sistema operativo. RFC 951 separó expresamente la elección de dirección y archivo de la transferencia posterior, que normalmente se hacía por TFTP. RFC 906 ya había descrito la carga de arranque por red en 1984. Una respuesta BOOTP podía indicar un servidor y un archivo, pero no demostrar que el cliente alcanzara el servidor, recibiera todos los datos o completara el arranque.

Difusión local y retransmisión hacia otro servicio

BOOTP no exigía que el cliente sin configurar conociera un servidor remoto mediante DNS ni que ya tuviera una ruta preestablecida. Podía difundir la petición por el cable local. Si el servidor estaba en otra red, una puerta de enlace o un agente de reenvío podía llevar la petición BOOTP hasta él y devolver la respuesta. RFC 951 dejó opcional esta operación entre redes: requería código adicional en puertas de enlace y servidores, pero ninguna acción especial del cliente.

El paquete incluía giaddr, descrito en 1985 como una dirección IP de puerta de enlace. Durante el reenvío, la primera puerta de enlace podía rellenar el campo si estaba vacío e incrementar hops. Si giaddr no era cero, el servidor podía enviar allí la respuesta BOOTP por el puerto de servidor, para que el relé la entregara en la red del cliente. Así, el campo conectaba al dispositivo que arrancaba con un servicio ubicado en otro lugar.

Ese trayecto no era la ruta que usaría el equipo después. La redacción inicial de RFC 951 dejaba espacio para la confusión: un pasaje sugería enviar los paquetes por giaddr «para llegar al servidor». Pero la transferencia del archivo de arranque y el enrutamiento IP ordinario del cliente eran tareas distintas. Que un campo se llamara «puerta de enlace» no las convertía en una sola.

La aclaración de 1993

RFC 1542 abordó directamente la ambigüedad. La especificación anterior no definía con claridad el comportamiento del agente de reenvío, por lo que el documento adoptó «agente relé» para distinguirlo del reenvío IP normal. El relé recibe el mensaje BOOTP como destino y genera otro; no se limita a dejar pasar un datagrama intacto. Podía operar dentro de un router interconectado, pero también en un equipo conectado directamente a la red del cliente.

RFC 1542 explicó que giaddr existe para llevar los BOOTREQUEST a través de agentes relé hasta servidores en otras redes y devolver los BOOTREPLY por esos agentes. No representa un router IP de uso general para el cliente, que no debe interpretarlo así. Para llegar a un servidor TFTP no local, el host aún necesita por separado la dirección de un primer router, obtenida mediante otra opción de configuración o un mecanismo de descubrimiento.

La aclaración no borró el diseño de 1985; delimitó lo que hacía. El relé resolvía una cuestión del servicio de arranque mientras la configuración IP del cliente estaba incompleta. No configuraba todo el tráfico posterior.

Lo que permitió centralizar el arranque

El relé permitía alojar fuera del cable local el servidor de arranque, sus registros que relacionaban direcciones físicas e IP y los archivos. Eso podía reducir la necesidad de instalar un servidor en cada segmento y dar al operador un lugar central para mantener la información. Es una implicación de la arquitectura documentada, no una medición de adopción ni de costes.

La cadena conservaba varias dependencias: enlace local, relé, destino configurado, registro correspondiente en el servidor, archivo, ruta del cliente y transferencia TFTP. Una respuesta BOOTP no demuestra que se completara ninguno de los pasos siguientes. La dirección del relé tampoco identifica a una persona, acredita una autorización ni establece la ruta predeterminada del cliente.

DHCP reutilizó posteriormente el comportamiento de los agentes relé y añadió modos de asignación, incluidos los arrendamientos de duración limitada. Esa evolución no debe mezclar el intercambio de arranque BOOTP, el ciclo del arrendamiento DHCP, la transferencia TFTP y el enrutamiento IP normal. Un mismo equipo puede depender de los cuatro; cada uno conserva su propio estado y sus propias pruebas.

La lección histórica cabe en un campo de cuatro letras. giaddr ayudaba a cruzar una frontera a un mensaje cuando el host aún estaba aprendiendo a participar en IP. Su nombre no lo convertía en la puerta de enlace del host. En la infraestructura de Internet, la ruta de retorno de un mensaje de control, el siguiente salto del cliente, la dirección del servidor de archivos y el éxito del servicio son hechos relacionados, pero no intercambiables.

Fuentes