Resumen

  • El RFC 1542 exige que las solicitudes BOOTREQUEST de un mismo cliente lleguen al mismo destino o al mismo conjunto de destinos.
  • El documento explica el problema con un retransmisor que alternaba entre servidores: dos solicitudes consecutivas podían terminar en servidores distintos.
  • La selección estable por cliente permite distribuir carga sin dispersar los mensajes de una misma conversación.

Un protocolo de arranque que podía salir de la red local

BOOTP atendía a equipos que podían encenderse sin conocer su propia dirección IP ni el servidor que les proporcionaría los datos de arranque. El RFC 951, de 1985, describió una primera fase para averiguar la dirección y elegir el archivo de inicio. El cliente podía difundir BOOTREQUEST en su red. Si el servidor estaba en otra red, esa difusión no atravesaba por sí sola los routers como una solicitud dirigida al servidor.

El RFC 951 permitió que pasarelas cooperantes reenviaran la solicitud. La función era opcional y podía residir en el router o en otro agente conectado al segmento del cliente. El agente establecía giaddr si estaba vacío e incrementaba hops; giaddr indicaba al servidor cómo devolver la respuesta a la red del cliente. La especificación inicial ofrecía el mecanismo, pero no detallaba suficientemente el comportamiento de los agentes de retransmisión.

El RFC 1532 intentó aclarar BOOTP en octubre de 1993. El RFC 1542 apareció ese mismo mes, actualizó el RFC 951 y dejó obsoleto al RFC 1532 después de que se introdujeran errores editoriales en este último. Su resumen señala que el comportamiento del agente de retransmisión necesitaba una especificación más firme. El cambio reconoció que el agente no era un simple conducto: su decisión podía mantener unido o separar el intercambio del cliente.

Por qué no rotar el destino en cada paquete

El RFC 1542 delimitó qué podía decidir cada operador. El retransmisor debía ofrecer una configuración para habilitarlo o deshabilitarlo y, por defecto, debía permanecer deshabilitado. También debía descartar solicitudes cuyo campo hops superara 16, permitir un umbral menor y configurable, completar giaddr con una dirección de la interfaz receptora cuando estuviera vacío, incrementar hops y preservar los demás campos BOOTP. La dirección o el conjunto de direcciones de destino también era configurable.

Dentro de esa flexibilidad había una obligación: para un cliente dado, todas las solicitudes BOOTREQUEST retransmitidas debían usar el mismo destino o conjunto de destinos. El RFC describe al menos una implementación conocida que aplicaba una rotación circular para balancear la carga. Con cada solicitud nueva, enviaba el paquete al siguiente servidor de una lista; por eso, varias solicitudes consecutivas del mismo cliente podían llegar a servidores diferentes.

El problema no era que hubiera varios servidores, sino que la selección se repitiera paquete a paquete. Una conversación puede tener varias solicitudes y respuestas. El RFC advierte que el reparto rotativo reacciona mal con DHCP y con otras variantes de BOOTP que dependen de varios intercambios. Si un servidor recibe una parte y otro servidor la siguiente, puede faltarles el contexto compartido necesario para continuar. El documento describe este riesgo; no identifica una red afectada ni afirma que la práctica fuera común.

La alternativa que propone conserva la distribución. El agente puede calcular una función hash con la dirección de enlace del cliente u otro dato fiable que lo identifique, y escoger así un destino estable. Clientes distintos pueden quedar repartidos entre varios servidores, mientras que los mensajes de cada cliente siguen el mismo camino. La opción más simple es enviar todas las solicitudes a un único conjunto de destinos.

Alcance de la garantía

El RFC no asegura que los servidores estén disponibles, que compartan estado ni que el arranque finalice. Solo impide que el agente cambie el destino de un mismo cliente al retransmitir sus solicitudes. Tampoco obliga a que todos los clientes usen un servidor único: se admiten varios destinos y una asignación estable por cliente.

El RFC 1534, publicado también en octubre de 1993, definió cómo podían interoperar BOOTP y DHCP, cuyos mensajes se basaban en el formato BOOTP. El RFC 2131, de 1997, formalizó con más detalle la secuencia DHCP: descubrimiento, ofertas, elección de servidor y solicitudes posteriores. Sirve para entender por qué podía haber más de un intercambio, pero no prueba que el ejemplo de balanceo del RFC 1542 causara un incidente concreto.

El RFC Editor registra un erratum verificado para el RFC 1542: corrige en §3.1.1 una mención a BOOTREPLY que debía decir BOOTREQUEST, en el texto sobre el indicador de difusión. Es una corrección aparte de la regla de destinos del §4.1.1 y no la cambia.

La lección histórica queda en una frontera operativa: repartir clientes entre servidores puede ser compatible con el protocolo; alternar entre servidores para cada paquete del mismo cliente puede dividir una conversación con varias etapas. El RFC 1542 hizo explícita esa frontera y dejó en manos del administrador la configuración local del servicio.

Fuentes