Resumen

  • BOOTP permitía que un cliente sin disco solicitara su dirección IP, un servidor y el nombre de un archivo de arranque antes de disponer de conectividad IP normal; después, una transferencia separada, por lo general TFTP, obtenía el archivo.
  • La respuesta planteaba otro problema: sin dirección, el cliente no podía contestar a ARP. RFC 951 describió una entrada ARP temporal en el servidor o una respuesta difundida por broadcast; reglas posteriores permitieron retransmitir solicitudes entre subredes.

Al encenderse, una estación de trabajo sin disco todavía no tenía un sistema operativo que configurara su red. Su programa en memoria de solo lectura podía enviar una solicitud, pero antes necesitaba saber qué dirección usar y qué archivo cargar. Solo entonces podía pedir ese archivo. La secuencia parecía circular: ¿cómo recibe una máquina una respuesta de red antes de tener una identidad de red que pueda utilizar?

Bill Croft y John Gilmore describieron ese problema en RFC 951, publicado en septiembre de 1985. BOOTP no transfería archivos. Atendía la primera fase: determinar la dirección y elegir el archivo de arranque. El programa del cliente podía solicitar una dirección, un servidor y un nombre de archivo; tras recibir la respuesta, una segunda fase —normalmente TFTP— podía traer el archivo a la memoria. El documento proponía que la secuencia funcionara sin intervención humana al encenderse una máquina desatendida. Describía un diseño, no un recuento de cuántos equipos lo utilizaban. (RFC 951, §§2 y 7.5.)

La solicitud no necesitaba una dirección IP que aún no conocía. Si el cliente no tenía especificado un servidor, podía enviar un paquete IP/UDP con la dirección de origen cero a 255.255.255.255, un broadcast en el cable local. La petición incluía también el tipo y la dirección del hardware del cliente, así como un identificador de transacción. El servidor podía asociar esa dirección física con una dirección IP en su propia base de datos, poner el resultado en el campo yiaddr de la respuesta y seleccionar una ruta completa al archivo de arranque. Una petición genérica, como unix, podía resolverse en un archivo adaptado a ese cliente. El registro local del servidor formaba parte del proceso de arranque. (RFC 951, §§2–3, 7.1, 7.3 y 9.)

La primera respuesta tenía su propio problema del huevo y la gallina. Por lo general, un servidor necesita ARP para encontrar la dirección de enlace que corresponde a un destino IP. Pero el cliente aún no conocía su dirección y no podía responder a la consulta ARP del servidor. RFC 951 describió dos soluciones. Un equipo con el soporte adecuado en el núcleo o el controlador podía crear una entrada ARP temporal a partir de las direcciones física e IP propuestas, con un tiempo de espera. La RFC señaló expresamente que UNIX 4.2 BSD tenía esa capacidad. Si no existía ese soporte, el servidor podía difundir la respuesta por broadcast en la interfaz del cliente. La solución dependía de las prestaciones locales del sistema que enviaba la respuesta. (RFC 951, §4.)

Los dos puertos UDP también servían para entregar la respuesta. Las solicitudes iban al puerto 67 del servidor BOOTP; las respuestas, al puerto 68 del cliente. RFC 951 explica que esa separación permitía que el núcleo filtrara las respuestas difundidas en equipos que no escuchaban el puerto del cliente, sin despertar ni programar los procesos servidores BOOTP de otras máquinas. Un puerto de origen aleatorio también podía hacer que el broadcast pareciera destinado a un proceso que escuchaba en otro equipo. No era un detalle decorativo: impedía que una respuesta individual de arranque se convirtiera en un evento de aplicación para todo el segmento. (RFC 951, §3.)

El servidor de arranque no siempre estaba en el mismo cable local. RFC 951 permitía el arranque a través de pasarelas como una opción que requería cooperación. Una pasarela u otro agente podía recibir el broadcast, rellenar giaddr para identificar la red del cliente y pasar la solicitud a un servidor. Los autores desaconsejaban retransmitir los mensajes indiscriminadamente porque podían formarse bucles. En octubre de 1993, RFC 1542 precisó esta frontera: un agente de retransmisión BOOTP no era simplemente un router IP que reenviaba un datagrama de forma transparente. Podía recibir el mensaje BOOTP como destino final y generar otro mensaje BOOTP. La función podía estar en un router o en un equipo separado conectado a la subred del cliente. La retransmisión era una función configurada, con reglas propias de procesamiento. (RFC 951, §8; RFC 1542, §§4–4.1.)

Por eso no conviene reducir BOOTP a un «DHCP antiguo». RFC 2131 describió después DHCP como una extensión del mecanismo BOOTP y conservó el formato de mensajes y el comportamiento del retransmisor para permitir la interoperabilidad. También señaló un cambio central: DHCP podía conceder una dirección por un periodo limitado y volver a utilizarla cuando el cliente dejara de necesitarla. El modelo de BOOTP de 1985 buscaba en los registros del servidor tanto la dirección como el archivo de arranque. DHCP también permite asignaciones manuales; la diferencia no consiste en que todas las direcciones pasaran a ser temporales, sino en que la asignación dinámica se incorporó al protocolo. (RFC 2131, §§1–2.)

La aportación histórica de BOOTP fue acotada, pero necesaria. No hacía autónoma una máquina sin disco, no autenticaba a un usuario ni transfería por sí mismo la imagen del sistema operativo. Definía cómo una máquina con dirección física, pero sin identidad IP utilizable, podía pedir los siguientes elementos de su arranque; cómo un servidor podía elegirlos; y cómo podía regresar la respuesta antes de que ARP funcionara con normalidad. En este caso, la conectividad empezaba con un broadcast local, un registro explícito en un servidor y una respuesta entregada mediante un mecanismo especial.

Fuentes y límites

RFC 951 era una propuesta y documenta un comportamiento previsto, no la extensión de su despliegue. La mención de una función de caché ARP en 4.2 BSD no demuestra que todas las implementaciones la tuvieran. RFC 1542 recoge reglas de retransmisión posteriores, pero no prueba su cumplimiento universal. BOOTP seleccionaba parámetros de red y el nombre de un archivo; otra fase transfería el archivo. DHCP introdujo concesiones dinámicas, aunque también conservó la asignación manual.