Resumen

  • El relay puede ordenar que un servidor compatible copie una dirección IPv4 elegida por el relay en la opción 54. Esa dirección devuelve futuras renovaciones al relay, pero no revela ni autentica la interfaz real del servidor.
  • En un grupo de servidores, el relay debería reenviar cada mensaje a todos en vez de mantener una tabla paralela de leases. La recepción, la decisión y la aplicación requieren comprobantes distintos.

La topología tiene tres servidores DHCP y un relay. Llega una renovación. El relay recuerda qué servidor respondió durante la asignación inicial, pero ese recuerdo puede estar obsoleto tras una conmutación. RFC 5107 prefiere otra arquitectura: el relay distribuye el mensaje y deja que cada servidor confronte la solicitud con su estado de lease.

El problema nace del comportamiento normal de DHCPv4. Durante DHCPDISCOVER, el relay inserta Relay Agent Information con datos como Circuit-ID y Remote-ID. Después de conceder el lease, el cliente en RENEWING envía DHCPREQUEST directamente a la dirección de Server Identifier. Si ese trayecto evita el relay, el servidor ya no recibe la misma evidencia de acceso.

Server Identifier Override, subopción 11, cambia el retorno. El relay introduce cuatro octetos de dirección IPv4. Un servidor que implementa RFC 5107 debe poner ese valor en la opción 54 de su respuesta. El cliente conserva el valor y la siguiente renovación llega al relay, que añade de nuevo la información de agente y la reenvía al servidor efectivo.

La dirección no tiene por qué pertenecer a ninguna interfaz del servidor. El nombre de la opción sugiere identidad, pero su función en este caso es encaminamiento de control. Distinguir destino del cliente, instancia que decide el lease y relay que aporta contexto no es una sutileza semántica: es la base de un registro verificable.

El servidor debe guardar el override para mensajes posteriores del cliente hasta recibir otro mensaje desde el relay. Ese estado necesita una generación. Un operador debería saber cuándo se aprendió, desde qué relay, para qué clave de cliente o lease y con qué digest de subopciones. El valor aislado no explica su autoridad.

Un servidor incompatible ignora la subopción y usa su propia dirección en la opción 54. La asignación puede terminar con éxito y ocultar la incompatibilidad. Solo al renovar se observa que el cliente fue directamente al servidor y que el relay no pudo reconstruir Circuit-ID o Remote-ID.

La compatibilidad debe comprobarse por instancia, no por clúster. Si dos servidores soportan el override y uno no, un porcentaje agregado de ACK puede parecer sano. El recibo correcto registra la subopción recibida, la opción 54 emitida y el camino de la renovación para cada servidor.

Normalmente, un servidor acepta un DHCPREQUEST dirigido a una de sus direcciones. Con el override presente, compara la opción 54 con la subopción 11. Si coinciden, debería procesar la solicitud aunque la dirección no sea local. La igualdad cambia la regla de admisión del mensaje.

No cambia la naturaleza de la prueba. Coincidencia significa consistencia entre dos campos. No prueba quién insertó la subopción, si el relay era confiable, si el cliente recibió un mensaje auténtico ni si el servidor posee la dirección. Convertir esa comparación en “identidad validada” sería una ampliación injustificada.

El relay sigue rellenando giaddr. La dirección de retorno no sustituye el contexto usado para seleccionar la red de asignación. Tampoco sustituye Circuit-ID, Remote-ID, Device Class o el origen broadcast/unicast. Cada dato tiene un alcance diferente y debe conservarse por separado.

Cuando hay varios servidores, RFC 5107 recomienda que el relay envíe todos los mensajes a todos ellos, incluidas las renovaciones. Así evita mantener estado de lease. La estrategia también exige telemetría por destino: intento de envío, recepción, silencio esperado, error de transporte y respuesta autoritativa.

Un solo ACK no demuestra que el fan-out fue completo. Del mismo modo, el silencio de un servidor sin el lease no demuestra una caída. La correlación debe usar la transacción del cliente, la generación del override y la identidad interna de cada servidor, no solo la dirección de opción 54 compartida.

RFC 5010 permite indicar si el mensaje del cliente llegó originalmente por broadcast o unicast. RFC 5107 recomienda usar esos flags. El servidor no puede reconstruir el modo original observando el paquete que le entrega el relay; esa observación pertenece a otra capa y otro tramo.

El relay se convierte en dependencia de renovación. Si el cliente no alcanza la dirección sobrescrita, la solicitud no entra en el relay. Si el relay pierde conectividad con los servidores, la solicitud entra pero no llega a la autoridad. Ambas fallas pueden terminar en expiración del lease y exigen códigos diferentes.

El modelo de evidencia debería registrar: recepción del cliente, selección de dirección, giaddr, modo original, digest de Relay Agent Information, envíos por servidor, recepción por servidor, comparación entre campos, decisión de lease, respuesta al cliente, aplicación local y primer tráfico. Ningún paso debe inferirse del siguiente.

La persistencia del override merece una prueba de reinicio. Un servidor puede restaurar el lease sin restaurar la dirección auxiliar. El cliente conserva la opción 54 antigua. El próximo DHCPREQUEST parece nombrar un servidor desconocido, aunque la verdadera divergencia está entre el lease duradero y el estado de retorno perdido.

Las migraciones crean la divergencia opuesta. La misma dirección anycast puede apuntar a otro relay; el mismo conjunto de servidores puede recibir renovaciones por una dirección nueva. La plataforma debe versionar retorno, relay e instancia decisora de manera independiente.

El límite de seguridad es explícito. Relay Agent Information presupone confianza entre relay y servidor. Un relay malicioso puede elegir su propia dirección, atraer renovaciones, negarlas después, modificar opciones en DHCPACK o presentar al cliente una duración diferente. La subopción no añade por sí sola una ventaja de seguridad.

La autenticación DHCP y la autenticación de la opción Relay Agent Information son defensas distintas. Debe registrarse qué principal fue autenticado y qué campos quedaron protegidos. Un indicador global authenticated=true no aclara si el cliente confió en el servidor o si el servidor confió en el relay.

Incluso un DHCPACK auténtico y recibido solo certifica un mensaje. Falta saber si el cliente instaló dirección, máscara, router y rutas; si la política de acceso permitió tráfico; y si el servicio respondió. La dirección llamada Server Identifier no puede cerrar ninguno de esos estados.

El valor directivo de RFC 5107 está en rechazar dos atajos. El relay no debe apropiarse de la autoridad de lease para ahorrar fan-out, y el observador no debe convertir una dirección de retorno en identidad del servidor. Ambos atajos concentran poder y eliminan evidencia precisamente donde la arquitectura distribuyó responsabilidades.

Fuentes