Resumen

  • Reconfigure es una orden autenticada para que el cliente inicie Renew, Rebind o Information-request; enviar la orden no demuestra una configuración nueva.
  • Que el servidor reciba la solicitud pedida satisface su solicitud Reconfigure, pero el Reply, la instalación local y el efecto operativo siguen siendo hechos diferentes.

Una consola de control suele premiar el verbo equivocado: «enviado». La RFC 9915 no lo trata como final. Define Reconfigure como un mensaje del servidor que provoca que el cliente abra un intercambio posterior. La distinción parece administrativa hasta que un informe convierte una marca de envío en una dirección renovada, un DNS utilizado o un servicio restablecido. Ninguno de esos resultados está contenido en el primer mensaje.

Antes de cualquier reacción existe una condición de aceptación. Reconfigure Accept permite que el cliente anuncie al servidor si está dispuesto a aceptar mensajes Reconfigure; sin esa opción, el comportamiento predeterminado es no estar dispuesto. Además, el cliente debe descartar un Reconfigure que no llegue por unicast, no traiga los identificadores exigidos, no incluya la opción de mensaje adecuada, señale un tipo inválido o carezca de autenticación válida. El registro de salida del servidor demuestra su intento protocolario, no una recepción aceptada.

Si el cliente recibe un Reconfigure válido, se abre otra capa de evidencia. La opción indica Renew, Rebind o Information-request. El cliente responde con el mensaje indicado y, mientras la transacción continúa, descarta otros Reconfigure. La RFC llama al primero un disparador. Es una palabra precisa: hace comenzar el siguiente intercambio; no instala por sí sola una dirección, un prefijo, un resolutor ni otra configuración.

El servidor puede observar después una respuesta acotada a su propia petición. La RFC 9915 dice que interpreta la recepción del Renew, Rebind o Information-request solicitado como satisfacción de la petición Reconfigure. Eso permite afirmar que el servidor recibió el tipo de mensaje que pidió. No permite afirmar que llegó un Reply, que el cliente aceptó sus opciones ni que el sistema operativo adoptó sus valores.

También importa cuál es el intercambio posterior. Renew y Rebind tienen sus propias reglas de asignación y de servidor. Information-request pide información sin pedir direcciones ni prefijos. En todos los casos, el Reply es el objeto que puede transportar la información de configuración correspondiente. Por eso una afirmación sobre un cambio concreto exige el Reply y sus opciones; una afirmación sobre instalación, ruta, DNS, tráfico o aplicación exige además la observación del lugar donde ocurrió.

La autenticación de Reconfigure protege un borde, no todos los resultados posteriores. RFC 9915 la exige por el riesgo de denegación de servicio. RFC 9096, con Volz entre sus autores, añade contexto de seguridad y privacidad para DHCPv6. Ninguno convierte un mensaje autenticado en prueba de disponibilidad, entrega de paquetes o éxito de una aplicación.

Un registro defendible conserva sus uniones: DUID del cliente, identificador del servidor, envío y validación de Reconfigure, msg-type solicitado, solicitud coincidente que vio el servidor, Reply con los valores relevantes y, cuando el reclamo lo requiere, observación local o de ejecución. El registro IANA ayuda a reconocer códigos DHCPv6; no certifica que las etapas posteriores ocurrieran.

Las notas de Heng Lu sobre especificación inicial mínima y primacía del código operativo ofrecen una disciplina simple: nombrar el hecho más pequeño que se vio. «El servidor envió Reconfigure» y «el servidor recibió la solicitud solicitada» son conclusiones útiles. Sustituirlas por «el cliente quedó configurado» borra justamente las comprobaciones que aún faltan.

Volz figura como uno de cinco autores de un estándar colectivo. Esa autoría no identifica un cliente real, una plataforma, una red ni una operación bajo su control. La lección editorial del protocolo es que una causa posible no debe adoptar el nombre de un resultado observado.

Fuentes