Resumen

  • RFC 3074 convertía el identificador del cliente o su dirección de hardware en uno de 256 valores y usaba un mapa compartido para decidir qué servidor DHCP debía atenderlo.
  • El propio documento contemplaba servidores asignados sin conexión o sin direcciones, buckets sin dueño, relojes de cliente defectuosos y mapas manipulados. El hash demostraba una regla configurada, no disponibilidad ni resultado.

DHCPDISCOVER se emite por difusión. Varios servidores pueden oírlo y responder, y un relay BOOTP puede reenviar la misma solicitud a todos sus destinos. En febrero de 2001, B. Volz, S. Gonczi, T. Lemon y R. Stevens publicaron RFC 3074 para reducir esa duplicación. Con una configuración inicial común, cada participante podía calcular por su cuenta la misma decisión de servir o no servir.

El punto de partida era el Service Transaction ID. Si existía Client Identifier, debía usarse; si no, hlen fijaba la longitud y chaddr aportaba hasta dieciséis bytes. La función de Pearson especificada devolvía un número entre 0 y 255. Cada servidor recibía un Hash Bucket Assignment de 32 octetos: un bit encendido significaba que debía atender toda solicitud cuyo STID produjera ese valor.

La coordinación era concreta. Misma entrada, misma tabla de mezcla y mismos mapas daban el mismo responsable sin intercambio permanente. Un relay podía asociar Server-ID con buckets y elegir el destino de reenvío. La técnica distribuía una población de clientes sin pedir cambios a esos clientes.

Pero el cálculo no consultaba el presente. No sabía si el proceso estaba vivo, si la ruta llegaba, si dos bases de leases coincidían o si quedaban direcciones apropiadas. El STID identificaba una transacción y el HBA expresaba reparto administrativo. Ninguno era telemetría de capacidad.

RFC 3074 reconoce el corte al hablar del servidor que debería responder pero no está disponible o carece de direcciones adecuadas. El parámetro opcional Delayed Service permite que otro servidor, normalmente excluido por el hash, responda después de S segundos desde el primer intento. No declara incorrecta la asignación: abre una excepción temporal cuando el turno inicial no produjo servicio.

Hasta el tiempo necesita una fuente. El servidor debería usar secs cuando el cliente envía un valor distinto de cero, pero la RFC advierte que algunos clientes implementan mal ese campo. La alternativa es recordar una solicitud previa con el mismo transaction ID y medir localmente el intervalo hasta la repetición. Una fuente declara edad; la otra une observaciones. Ninguna prueba por sí sola si el primer servidor cayó, agotó su pool o descartó la petición por política.

Sin Delayed Service, el mapa impone una separación estricta. Un bucket sin asignar hace que se ignore por completo la transacción correspondiente; el texto admite que en ciertos escenarios puede ser deseable. Por eso la cobertura es un recibo propio. Un programa puede ejecutar a la perfección el algoritmo y llegar a un valor que ningún servidor aceptará.

Tampoco debe confundirse el porcentaje con una medición instantánea. En intervalos cortos, la carga real puede apartarse del porcentaje configurado; al aumentar el número de solicitudes debería aproximarse. El hash no observa CPU, cola, latencia ni direcciones libres. Reparte identificadores y depende de que los STID tengan variedad suficiente, no de que sean necesariamente únicos.

La configuración completa la superficie de control. Los HBA pueden residir en archivo, registro de Windows NT, EEPROM o algoritmo acordado, y también viajar dentro de otro protocolo. La propuesta no aporta seguridad. Si el mapa se transmite, el mensaje debe protegerse contra alteraciones porque un atacante puede negar servicio a parte o a todos los clientes. Un hash idéntico no detecta mapas divergentes ni repara una instrucción común falsificada.

RFC 2131 sitúa el mecanismo en contexto: el cliente debe soportar varias respuestas y DHCP opera bajo política administrativa local. Tras DISCOVER todavía quedan OFFER, elección, REQUEST, ACK y uso efectivo de los parámetros. RFC 3074 organiza quién tiene permiso de empezar a responder, no garantiza la cadena completa. RFC 1542 explica el relay BOOTP, pero no demuestra que un relay concreto aplicara esta selección.

RFC 7031 observó años después que la configuración desigual entre socios de failover era frecuente y dejó el reparto de carga fuera del núcleo de DHCPv6 failover. No es evidencia retroactiva sobre despliegues de RFC 3074. Sí ayuda a mantener separadas tres tareas: repartir solicitudes, sincronizar estado y recuperarse de una avería.

Running-Code Primacy propone seguir recibos ejecutables: origen del STID, bucket, cobertura, servidor, camino, dirección disponible, toma tardía, OFFER, REQUEST, ACK y configuración utilizable. Reality Layers impide que la exactitud simbólica de un dueño calculado sustituya la autoridad operacional del resultado. Son lentes posteriores, no ideas atribuibles a los autores ni a la IETF.

RFC 3074 resolvió una pregunta acotada con elegancia: quién debía intentarlo primero. Su mecanismo no prometió presencia, capacidad, integridad ni éxito. Justamente por eso sigue siendo una buena lección histórica: una decisión determinista puede ser correcta y, aun así, no ser un servicio.

Fuentes