Resumen

  • Un cliente envía Confirm cuando detecta cambios de red y quiere saber si sus direcciones anteriores siguen siendo apropiadas para el enlace. La consulta no nombra al servidor que las asignó.
  • Success confirma el encaje topológico del conjunto completo. El servidor ignora T1, T2 y las vidas preferida y válida; por tanto, no concede tiempo nuevo.
  • Tomek Mrugalski y los demás autores de RFC 9915 dejaron separadas la autoridad para juzgar el enlace, la autoridad para extender una concesión y las pruebas de que el tráfico realmente funciona.

Dos libros para una misma dirección

La primera libreta pertenece al enlace. Contiene prefijos válidos aquí, interfaz, relé y momento. Su pregunta es espacial: ¿puede esta dirección estar en esta red?

La segunda pertenece a la concesión. Contiene el servidor que la otorgó, la asociación de identidad, T1, T2, vida preferida y vida válida. Su pregunta es temporal y administrativa: ¿cuánto tiempo puede seguir usándola este cliente?

Confirm consulta la primera libreta. Renew modifica la segunda. Que ambas hablen de la misma dirección no las convierte en una sola fuente de autoridad.

RFC 9915 usa Confirm cuando un cliente con direcciones —pero sin prefijos delegados— detecta que cambió la información de red. Incluye Client Identifier, sus IA y todas las direcciones asociadas. No puede incluir Server Identifier. Cualquier servidor capaz de conocer los prefijos del enlace puede responder.

Esa regla evita que una pregunta local dependa del servidor original. El mensaje no dice «servidor A, renueva lo que me diste». Dice «servidores de este enlace, decidme si estas direcciones corresponden aquí».

Un predicado con sujeto explícito

La palabra Success necesita sujeto. No significa «todo está bien». Significa «todas las direcciones de esta solicitud son apropiadas para este enlace según el servidor que responde».

Si una sola dirección falla, la respuesta es NotOnLink. Si el servidor carece de información para hacer la prueba, o la solicitud no aporta direcciones, no debe contestar. El silencio no se convierte en una tercera forma de éxito.

La solicitud debería poner a cero T1 y T2, además de preferred-lifetime y valid-lifetime. El servidor los ignorará. Esta aparente renuncia protege la semántica: un servidor con conocimiento topológico no necesita fingir que posee el registro de la concesión.

En Renew, en cambio, el cliente se dirige al servidor que originó los leases. Este busca el binding y puede devolver vidas nuevas. Si no responde antes de T2, Rebind permite que cualquier servidor disponible prolongue la concesión. Solo esas respuestas crean prueba nueva sobre el tiempo.

IANA registra Confirm, Renew, Rebind y Reply como tipos distintos. La asignación fija el vocabulario interoperable, no certifica que una implementación haya formulado la pregunta correcta ni que el receptor tuviera datos suficientes.

Continuar no equivale a empezar de nuevo

Tras Success, el cliente puede conservar las direcciones. Tras agotar el intercambio sin respuestas, también debería conservarlas, junto con la configuración previa. En ambos casos usa las últimas vidas conocidas.

Por eso observar una dirección todavía configurada no permite reconstruir el resultado. Puede haber un Reply positivo o puede haber vencido el temporizador de Confirm. Para distinguirlos hacen falta transaction ID, estado, DUID del servidor y hora.

Tampoco aparece tiempo adicional. Si quedaban 900 segundos de vida válida, el contador sigue bajando. Un Success no repone 900. Solo un Renew o Rebind posterior, con vidas nuevas, puede alterar esa cuenta.

RFC 4862 divide la vida de una dirección en preferred y valid. Al terminar la primera, la dirección queda deprecated: puede sostener comunicaciones existentes, pero no debería ser la opción para nuevas. Al acabar la segunda, es invalid y no debe usarse. «Confirmada» no sustituye ninguno de esos estados.

El diseño permite continuidad sin falsificar autorización. Cuando nadie puede responder a tiempo, la red no interrumpe de inmediato lo que aún está legítimamente vivo. Pero tampoco regala segundos que no figuran en la concesión.

La respuesta decisiva puede venir de un tercero

Al no haber Server Identifier, varios servidores pueden responder. RFC 9915 establece una regla asimétrica: cualquier Reply válido con Success permite usar las direcciones e ignorar respuestas NotOnLink. Solo una colección de respuestas exclusivamente negativas obliga a reiniciar el descubrimiento.

No es mayoría ni consenso. Basta un servidor que afirma conocer el enlace. Esa elección favorece continuidad, pero obliga a guardar la identidad del que decidió. Si tres servidores discrepan, el resultado operativo puede ser verde y la salud de la configuración, amarilla.

Un indicador agregado pierde el desacuerdo. Un buen registro conserva todos los DUID, el camino de relé, la interfaz, las direcciones sometidas a prueba y la revisión de prefijos usada por cada servidor. El Success que prevaleció puede señalar cuál de las bases está actualizada; los NotOnLink pueden revelar cuáles no.

Además, el resultado cubre el conjunto entero. Un solo elemento incorrecto vuelve negativa la transacción, pero el status no tiene por qué indicar cuál. Sin la entrada exacta, el operador solo sabe que falló «algo».

No es una prueba de duplicados, vecinos ni rutas

Que una dirección pertenezca al prefijo del enlace no demuestra que esté libre. Duplicate Address Detection responde otra pregunta.

Tampoco demuestra que el siguiente salto conteste. Neighbor Discovery mantiene su propio estado de alcance.

No confirma una ruta de salida ni de retorno. Un prefijo local válido puede convivir con filtros o anuncios ausentes aguas arriba.

No prueba que el servidor original conserve el binding. El servidor que respondió puede conocer la topología sin conocer la concesión.

Ni garantiza que una aplicación siga funcionando. DHCP configura; no certifica sesiones.

Esta lista no reduce el protocolo. Define un módulo pequeño que puede combinarse con recibos de unicidad, vecino, ruta, binding y aplicación sin que ninguno usurpe al otro.

Una trayectoria entre estándar y código en ejecución

RFC 9915 es el Internet Standard STD 102 desde enero de 2026. Sus autores son Tomek Mrugalski, Bernie Volz, Michael C. Richardson, Sheng Jiang y Timothy Winters. El texto y los agradecimientos pertenecen a una comunidad; no otorgan a nadie control sobre servidores desplegados.

El Datatracker muestra una extensa participación de Mrugalski en DHCP. Un perfil escrito por ISC en 2024 recorre Dibbler, nacido de su trabajo académico, y el desarrollo posterior de Kea. La biografía demuestra experiencia fechada con especificaciones e implementaciones, no conformidad universal.

Su figura sirve porque la frontera no es solo teórica. En el programa que corre, las tres ramas —Success, solo NotOnLink, ninguna respuesta— pueden mantener una dirección visible durante un intervalo. Running-Code Primacy exige observar qué rama se ejecutó y qué reloj siguió vivo.

La Minimum Initial Specification de Heng Lu ayuda a valorar la economía del diseño. El sistema comparte la respuesta mínima sobre el enlace y deja la concesión, la ruta y la aplicación en las capas que poseen esos datos. Convertir la respuesta mínima en una promesa total sería recentralizar autoridad mediante una etiqueta.

El problema de agencia aparece en los cuadros de mando. El fabricante publica fácilmente una tasa de éxitos. El operador paga por conservar contexto de relé y versiones de prefijo. El servicio de leases mantiene bindings. El usuario sufre la expiración. Si el primer dato habla por todos, quien produce la métrica barata dicta la interpretación cara.

La cadena que permite afirmar continuidad

Primero, el recibo del cambio: interfaz, señal que hizo sospechar un nuevo enlace, estado anterior y hora.

Segundo, el recibo del lease existente: servidor asignador, IAID, dirección, T1, T2, vidas y segundos restantes.

Tercero, la solicitud: DUID del cliente, transaction ID, conjunto íntegro de direcciones, relé y ausencia de Server Identifier.

Cuarto, cada respuesta: DUID, contexto del enlace, conocimiento de prefijos y status. La falta de respuesta se registra como expiración del intercambio.

Quinto, la regla aplicada: al menos un Success, todas las respuestas NotOnLink, o silencio.

Sexto, lo que ocurrió después: Renew o Rebind, nuevas vidas, deprecación, invalidez, DAD, vecino y ruta.

Con esos seis recibos, «la dirección siguió» deja de ser una impresión y se vuelve una afirmación acotada: encajó en el enlace y siguió bajo el reloj anterior.

Fuentes