Resumen

  • DHCPv6 Reconfigure no contiene las direcciones ni los parámetros nuevos. Pide a un cliente que previamente aceptó el mecanismo que inicie Renew, Rebind o Information-request y deja que el intercambio posterior determine el estado.
  • RFC 6977 permite que una Reconfigure-Reply indique Success aunque el servidor no vaya a enviar Reconfigure a ninguno de los clientes solicitados. Selección, entrega, autenticación, transacción, instalación y continuidad requieren pruebas diferentes.

El primer hecho fue una respuesta positiva

Un relé de acceso detecta que cambió un dato de provisión asociado a un enlace. Envía al servidor una Reconfigure-Request con la dirección del enlace y varios identificadores DUID. La respuesta llega con Success y el panel declara completada la operación. Sin embargo, todos los clientes todavía conservan su estado anterior.

La secuencia es legal. El servidor puede aceptar la petición y devolver en la lista de exclusión a los clientes que no reconoce, que no tienen estado suficiente o que nunca anunciaron Reconfigure Accept. Puede aplazar otros por una política de carga. Un mensaje enviado puede fallar la autenticación, activar un Renew que aún no obtiene Reply o terminar en un cliente cuya aplicación continúa ligada a una dirección antigua.

El panel sólo es exacto si identifica la frontera: el servidor procesó una petición del relé. El error aparece cuando ese acuse adquiere autoridad sobre hechos posteriores que no observó.

RFC 6977 incluso autoriza Success cuando la respuesta enumera a todos los clientes y, por tanto, el servidor no enviará Reconfigure a ninguno. La semántica protege una distinción importante: aceptar una solicitud de coordinación no equivale a certificar una ejecución distribuida.

Un mensaje que elige el siguiente intercambio

RFC 9915 es la especificación base vigente de DHCPv6 y sustituyó a RFC 8415. IANA asigna el valor 10 a RECONFIGURE. Su función común es limitada: impulsar a un cliente concreto hacia una nueva conversación con el servicio DHCPv6.

Reconfigure debe enviarse por unicast e incluir Server Identifier, el Client Identifier correspondiente, autenticación válida y Reconfigure Message. Esta última opción sólo puede señalar Renew, Rebind o Information-request. No debe introducir en el disparador las nuevas opciones ordinarias de configuración. Esas opciones pertenecen a la Reply del intercambio solicitado.

Esta separación reduce la autoridad del mensaje. El servidor inicia, pero el cliente valida y formula su propia petición. El servidor vuelve a evaluar su estado al responder. Después el código del cliente decide qué instalar. La observación operativa determina si el servicio efectivo cambió sin daño.

Por eso una captura de Reconfigure no demuestra la nueva configuración. Tampoco una captura de Renew demuestra que la Reply llegó, ni una Reply demuestra que una aplicación abandonó el estado previo. Son puntos distintos de una cadena y no variantes del mismo comprobante.

La aceptación es voluntaria y visible

Un cliente anuncia su disposición mediante Reconfigure Accept. Si omite esa opción, el servidor no puede tratarlo como participante. El cliente sigue siendo compatible con DHCPv6 y recibe cambios por las duraciones normales, renovaciones iniciadas localmente o Information-request propias.

La distinción es una salvaguarda contra la conversión de una extensión opcional en obligación de facto. También obliga a medir la flota. Si sólo una fracción acepta Reconfigure, el plan de cambio debe conservar tiempo y rutas para los demás. No puede descontarlos después de mirar únicamente los mensajes que sí se enviaron.

En equipos pequeños, RFC 8947 muestra que el coste de autenticación y almacenamiento puede justificar una implementación más estrecha. El operador puede preferir una reacción rápida, pero no puede atribuir al protocolo una universalidad que éste no exige.

Autenticación: autoridad para disparar, no para declarar realidad

Reconfigure Key Authentication Protocol entrega una clave de 128 bits en una Reply inicial y emplea HMAC-MD5 en los disparadores siguientes. La entrega inicial ocurre sin cifrado por el propio camino DHCPv6, de modo que su exposición forma parte del modelo de amenaza.

El valor de detección de repetición debe aumentar de forma monotónica. El servidor necesita conservarlo incluso después de reiniciar. Una plataforma que recupera los leases pero no las claves o los contadores puede saber a quién querría contactar y, a la vez, no poder producir un mensaje aceptable.

La validación criptográfica sólo prueba que el disparador pertenece a la autoridad que comparte la clave y que no parece una repetición. No valida el criterio que seleccionó al cliente. No garantiza que el estado actual del servidor sea correcto. No certifica la Reply posterior ni la conducta de la aplicación.

Usar la palabra «autenticado» como sinónimo de «correcto de extremo a extremo» elimina precisamente las fronteras que la criptografía ayuda a definir.

El relé solicita; el servidor conserva la decisión

RFC 6977 define Reconfigure-Request y Reconfigure-Reply para la comunicación entre relé y servidor. El relé puede enviar la dirección de enlace y los identificadores de clientes que considera afectados. El servidor decide si reconoce al relé, si acepta la información, si posee estado suficiente, qué clientes son aptos y cuándo puede dispararlos.

La política inicial es conservadora: el servidor no acepta por defecto estas peticiones y descarta las de relés desconocidos. RFC 8213 permite proteger con IPsec los mensajes entre servidor y relé. La protección del canal confirma a los extremos de ese canal, pero no garantiza que el relé haya clasificado bien a la población.

Una retransmisión puede reducir el conjunto de clientes, no aumentarlo. Esa regla impide que una solicitud crezca silenciosamente mientras está activa. El servidor sigue necesitando verificar la relación entre enlace, identidad, binding y autoridad del relé.

Con varios servidores, la misma solicitud puede producir selecciones diferentes porque sus estados o políticas no coinciden. Sumar respuestas positivas no crea una única verdad. Cada disparador debe quedar vinculado al servidor que lo emitió, al cliente concreto y a la transacción posterior.

Una contabilidad por fronteras

La operación debería conservar, como mínimo, los siguientes eventos separados:

  1. cambio de la fuente observado por el relé y población candidata;
  2. petición aceptada o rechazada por el servidor;
  3. cliente seleccionado y Reconfigure emitido;
  4. autenticación aceptada y petición del cliente observada;
  5. Reply posterior recibida y procesada;
  6. estado instalado y aplicación verificada.

Cada fase produce evidencia propia: registro del relé, Reconfigure-Reply, log de selección, contador de emisión, resultado de autenticación, identificador de transacción, estado local y prueba del servicio. El hueco entre dos conteos ayuda a localizar el problema.

Un Success con todos los DUID en la lista devuelta significa que el procesamiento fue correcto y la cobertura fue cero. Un Renew sin Reply separa un disparador efectivo de una transacción fallida. Un cliente que confirma su estado mientras la aplicación conserva el socket anterior revela otra frontera. Ninguna de estas situaciones se diagnostica bien con un único indicador de finalización.

La cola también cambia el significado del tiempo

Un evento puede provocar un abanico de mensajes individuales y nuevos intercambios DHCPv6. RFC 6977 contempla limitación de tasa para evitar que Reconfigure perjudique el trabajo normal del servidor. La capacidad reservada para asignaciones, renovaciones y recuperación no puede consumirse por una orden masiva.

Aceptar la solicitud ahora no implica emitir todos los disparadores ahora. Por ello, la latencia relevante va desde la observación del cambio hasta el estado aplicado, con marcas intermedias para selección, cola, entrega y transacción. La Reconfigure-Reply sólo mide el principio.

Las políticas deben fijar máximos por evento fuente, por petición, por intervalo y por ventana, además de un presupuesto de reintentos. Un ciclo de reintentos ilimitado convierte una población ausente en presión permanente y puede empeorar el incidente que pretendía resolver.

Recuperar registros no recupera el presente

Leasequery, Bulk Leasequery y Active Leasequery —RFC 5007, RFC 5460 y RFC 7653— permiten reconstruir o mantener una vista más reciente de los bindings. Son herramientas importantes para la continuidad de un servidor. Aun así, describen observaciones y transferencias de estado, no la presencia física actual de un cliente.

El DUID recuperado puede corresponder a un terminal que ya se marchó. Una corriente activa puede retrasarse o requerir resincronización. El binding puede sobrevivir mientras la clave y el valor antirrepetición no. La procedencia, la edad y la completitud del dato deben acompañar cualquier decisión de alcance amplio.

RFC 9243 aporta un modelo YANG para hacer visible la configuración del servicio DHCPv6. Esa visibilidad explica la intención del plano de control. No transforma el modelo en una medición del terminal, y por ello no sustituye la verificación posterior.

Renumerar sin confundir aceleración con certeza

Los escenarios de RFC 6879 muestran redes IPv6 que necesitan adoptar nuevos prefijos. Reconfigure puede adelantar el momento en que los clientes vuelven al servidor. No elimina la necesidad de coexistencia, los clientes que no aceptaron el mecanismo ni las aplicaciones que mantienen direcciones anteriores.

El camino reversible mantiene durante un periodo explícito el estado antiguo y el nuevo. Mide quién quedó excluido, quién se retrasó y qué aplicación no migró. La retirada final sólo ocurre tras esa observación. Si el operador reduce la coexistencia porque vio Success en el diálogo relé-servidor, una demora permitida por diseño se convierte en una interrupción.

Reconfigure es por tanto un acelerador dentro de una transición, no un botón que vuelve seguro el corte inmediato.

El estándar pequeño y las decisiones locales

El núcleo común puede precisar formatos, identificadores, aceptación, autenticación, repetición y tres tipos de intercambio. No debe decidir qué acontecimiento comercial justifica el cambio, qué relé merece confianza en cada despliegue, cuántos clientes puede soportar un servidor ni cuándo una aplicación está lista para perder la dirección anterior.

El relé opera la detección y propone la población. El servidor controla confianza, estado y presupuesto. El cliente ejecuta su implementación. El operador define continuidad, pruebas y reversión. Estas decisiones localizadas permiten reemplazar componentes sin convertir la coordinación en un controlador universal.

La disciplina de Heng Lu coloca primero el código que funciona. Una especificación, una recomendación o un acuse describen posibilidades y decisiones; sólo la implementación validada y observada produce la nueva realidad. La especificación inicial mínima crea el mecanismo común. La decisión futura localizada deja la política en manos de quienes asumen el resultado. La adopción voluntaria explica por qué un cliente puede permanecer fuera sin dejar de ser interoperable.

El disparador merece autoridad para iniciar una conversación. No merece autoridad para certificar cómo terminó.

Fuentes