Resumen

  • RFC 9915 es una Norma de Internet de la IETF, STD 102, publicada en enero de 2026, y deja obsoleta RFC 8415.
  • El cambio operativo no es un mensaje nuevo de dirección, sino un ciclo de vida más preciso para intercambios cliente/servidor, DUID, Server Identifier, Identity Associations, vigencias, Renew, Rebind, relays, Reconfigure y Prefix Delegation.
  • RFC 9915 elimina la asignación de direcciones temporales IA_TA y la capacidad Server Unicast, incluida su opción y el código de estado UseMulticast.
  • Esto no elimina las direcciones IPv6 de privacidad: SLAAC y sus direcciones temporales siguen delimitadas por RFC 4862 y RFC 8981.

La concesión como autoridad de estado

RFC 9915 especifica DHCPv6 para configuración sin estado y asignación con estado de direcciones y prefijos IPv6, en lugar de SLAAC o junto con SLAAC. Cliente y servidor intercambian mensajes directamente o mediante relays. El DUID identifica al cliente; el identificador del servidor permite reconocer la autoridad cuyas respuestas corresponden a la transacción activa. Las Identity Associations, o IA, agrupan recursos y estado, incluidas asociaciones de direcciones y delegaciones de prefijos.

Por eso una concesión es más que una dirección. Las vigencias preferida y válida indican cuánto tiempo puede usarse una dirección o un prefijo y cuándo debe renovarse o retirarse. Normalmente el cliente envía Renew al servidor elegido antes del vencimiento. Si ese servidor no responde, Rebind amplía la búsqueda a otros servidores disponibles. Una Reply inicial correcta demuestra solo que un intercambio funcionó; no demuestra que funcionarán el siguiente Renew, el Rebind, la ruta del relay o el uso posterior del prefijo delegado.

Los relays forman parte de esta frontera de estado. Transportan tráfico DHCPv6 por una topología donde la multidifusión, la selección del relay, la interfaz y la continuidad del servidor pueden ser distintas de las del camino inicial. Reconfigure puede pedir al cliente que revise su configuración, pero debe comprobarse que ese mensaje atraviesa el relay y las políticas reales. Un reemplazo o failover de servidor debe conservar los supuestos de identidad, IA y temporización que permiten continuar la concesión; el estándar no convierte automáticamente en segura cualquier combinación de versiones.

Prefix Delegation aplica la misma lógica al router de borde del cliente. El prefijo delegado tiene vigencias y un contexto IA, y el router debe mantener su uso en las redes descendentes de acuerdo con esas vigencias. RFC 7084 aporta requisitos y contexto para routers de borde, pero no demuestra que una implementación o topología concreta conserve la delegación durante un failover. Hay que probar por separado la frontera del servidor, la del relay y la renumeración descendente.

Capacidades retiradas y límites de privacidad

RFC 9915 elimina IA_TA, el mecanismo DHCPv6 de asignación de direcciones temporales. También elimina Server Unicast, su opción y el código de estado UseMulticast. Son cambios de superficie del protocolo que reducen el comportamiento heredado esperado de la máquina de estados. No significan que hayan desaparecido las direcciones de privacidad. RFC 4862 define SLAAC y RFC 8981 define direcciones temporales para SLAAC; esos mecanismos pueden seguir utilizándose según la política de cada red. Tampoco debe inferirse que DHCPv6 sustituye siempre a SLAAC.

Las opciones con estado múltiples y las múltiples IA necesitan una matriz propia. RFC 7550 describe problemas operativos relacionados con múltiples opciones DHCPv6 con estado: que una IA funcione no prueba que funcionen las demás. Correlacione DUID, Server Identifier e IA; observe por separado las vigencias de direcciones y prefijos; registre qué servidor y relay atendieron cada transición.

Ruta de decisión para la aceptación del operador

  1. Inventariar. Identificar servidores DHCPv6, caminos de relay, dependencias de multicast, comportamiento de DUID, Server Identifier, cada IA, consumidores de prefijos delegados y cualquier expectativa de IA_TA o Server Unicast.
  2. Crear una línea base. Registrar asignación inicial, vigencias preferida y válida, tiempos de Renew y Rebind, autoridad de la Reply, metadatos del relay y estado final de direcciones y rutas.
  3. Forzar transiciones. Probar pérdida y reemplazo de servidor, pérdida y cambio de relay, multicast inalcanzable, Reconfigure, múltiples IA y comportamiento mixto RFC 8415/RFC 9915. Ese comportamiento mixto es desconocido hasta medirlo.
  4. Probar la delegación. Hacer que un router de borde renueve y haga Rebind del prefijo delegado; verificar luego el uso descendente, el vencimiento y la recuperación tras cambiar servidor o relay.
  5. Comprobar privacidad y coexistencia. Validar SLAAC y RFC 8981 según la política. La eliminación de IA_TA no demuestra que hayan desaparecido las direcciones temporales ni que DHCPv6 haya reemplazado SLAAC.
  6. Observar y revertir. Exigir métricas de DUID, Server Identifier, IA, vigencias, Renew, Rebind, Reconfigure, camino de relay y continuidad del prefijo. Revertir si una transición pierde autoridad, deja aislada una red descendente o produce un estado de direcciones sin límite claro.

La decisión es go solo cuando la evidencia cubre el ciclo completo, no cuando la asignación inicial funciona. Si no, mantener un piloto acotado, conservar la configuración anterior y fijar disparadores de reversión. Este es el análisis de Theo March: el estándar define la máquina de estados; el operador debe demostrar que el sistema que la rodea conserva ese estado.

Fuentes

Registro de afirmaciones y evidencia RFC

Afirmación Evidencia
Estado DHCPv6 actual, intercambios, identificadores, IA, vigencias, Renew, Rebind, Reconfigure, capacidades retiradas y delegación RFC 9915
Línea base DHCPv6 anterior y frontera de revisión RFC 8415
Coexistencia con SLAAC y autoconfiguración de direcciones RFC 4862
Contexto de routers de borde y delegación de prefijos RFC 7084
Opciones con estado múltiples y límite operativo de múltiples IA RFC 7550
Privacidad mediante direcciones temporales de SLAAC RFC 8981

Este briefing no afirma soporte de ningún proveedor, despliegue universal ni migración completada. Tampoco pretende cubrir el estado de rutas proyectadas RPL de RFC 9914, la normalización de capacidades radio de RFC 9913 o el grafo de recuperación RAW de RFC 9912. Son planos distintos; aquí el objeto es la máquina de estados de concesión, identidad, vigencia y continuidad de prefijos DHCPv6.