Resumen

  • RFC 3074 permitió que varios servidores DHCP tomaran la misma decisión local usando un identificador de cliente y una asignación previa de 256 cubos.
  • El hash repartía el permiso para responder, no el trabajo observado: los cubos vacíos podían dejar al cliente sin respuesta, y esperar no demostraba que finalmente obtuviera una concesión.

Repartir respuestas no es medir carga

Una difusión de DHCP puede llegar a varios servidores. En 2001, RFC 3074 propuso reducir esas respuestas duplicadas sin cambiar el software de los clientes: cada servidor calculaba el mismo hash para una transacción y contestaba únicamente si el resultado estaba dentro de su Hash Bucket Assignment (HBA).

La entrada era la opción Client Identifier, si estaba presente. Si no, se usaban el campo de longitud del hardware y la dirección del cliente, con un máximo de dieciséis bytes. El hash de Pearson devolvía uno de 256 valores. Un mapa de 32 octetos decía qué valores podía atender cada servidor. Un relay BOOTP también podía asignar intervalos de cubos a identificadores de servidor y reenviar las solicitudes de forma selectiva.

La idea sustituyó la negociación repetida por una decisión tomada al configurar el sistema. Nació como una optimización del protocolo DHCP Failover, que entonces estaba en desarrollo, y luego se amplió a servidores cooperantes y relays BOOTP. La eficiencia consistía en evitar intercambios entre servidores para cada petición y no exigir cambios al cliente.

Sin embargo, el porcentaje configurado no era una lectura de CPU, presión sobre el pool, latencia ni asignaciones completadas. El propio RFC advierte que la proporción real puede apartarse del objetivo en intervalos breves y acercarse a medida que crece el volumen de solicitudes. Eso describe la distribución de transacciones a lo largo del tiempo; no implica que cada transacción cueste lo mismo ni que los servidores terminen con una carga equivalente.

Un cubo sin dueño podía significar silencio

El límite decisivo está en el mapa. RFC 3074 dice que una transacción cuyo hash cae en un valor no asignado puede ignorarse por completo; añade que, en ciertas situaciones, puede ser lo deseado. El silencio podía ser una consecuencia intencional de la política de asignación y no solo una pérdida de paquetes.

El parámetro opcional Delayed Service permitía que un servidor no seleccionado respondiera después de una espera. Es una salida temporizada, no un consenso en vivo ni la prueba de que el servidor previsto haya fallado. El RFC también permite que las implementaciones atiendan el caso de un servidor no disponible o sin direcciones adecuadas, pero no prescribe una garantía común de recuperación.

El relay muestra las etapas por separado: puede dirigir cada cubo a un servidor o a una pareja principal-respaldo que opera con otro arreglo de failover. Seleccionar, reenviar, compartir el estado de concesiones y que el cliente use la dirección son resultados distintos. RFC 3074 especifica una regla de selección; no convierte la HBA en estado de concesiones compartido ni en recibo de extremo a extremo.

Datatracker sigue clasificando RFC 3074 como Proposed Standard del IETF. Ese dato describe la posición del documento, no su adopción actual. RFC 8156, de 2017, define el failover de DHCPv6 y la toma de control de concesiones tras una falla o partición de red. Sirve como contraste acotado, no como prueba de que RFC 3074 se actualizó o se desplegó.

La nota posterior de Heng Lu sobre las “capas de realidad” funciona aquí como lente editorial, no como evidencia sobre DHCP: separar la regla escrita, la configuración del operador, el comportamiento observado del servidor y el resultado para el cliente. Así, la aportación histórica de RFC 3074 fue hacer calculable quién podía responder; no hacer que el resultado del servicio se acreditara por sí solo.

Fuentes