Resumen

  • Una Reply válida con IA_PD e IAPREFIX acredita una vinculación de prefijo y sus tiempos de vida; no observa una ruta ni un plano de reenvío operativo.
  • La aceptación debe unir la transacción DHCPv6 con RIB/FIB de acceso, estado del router del cliente, anuncios LAN y pruebas del prefijo en ambos sentidos.

El panel del equipo marca éxito. El servidor entregó un /56 y el cliente guardó las vigencias. Sin embargo, un host de la LAN no puede mantener una sesión IPv6 y una sonda externa no alcanza una dirección del bloque. La captura de DHCPv6 es correcta, pero no dice dónde terminó la cadena.

RFC 8415 define Reply para transportar concesiones y parámetros en distintas conversaciones. En Prefix Delegation, IA_PD contiene uno o varios prefijos y los temporizadores T1 y T2; cada IA Prefix incorpora las vigencias preferida y válida. Esos datos establecen qué puede usar el cliente y durante cuánto tiempo.

No certifican que los paquetes encuentren el camino.

Dos sistemas pueden divergir

La propia RFC señala que la delegación no obliga por sí sola al cliente a reenviar paquetes destinados a terceros. Tras recibir el bloque, el cliente puede dividirlo, asignar subredes a interfaces internas y emitir Router Advertisements. Ninguna de esas acciones forma parte del hecho observado por la Reply.

En el lado del operador ocurre algo similar. Si el servidor se comunica mediante un relay, RFC 8415 advierte que puede ser necesario otro protocolo o un canal fuera de banda para configurar la información de enrutamiento en los equipos intermedios. Por eso un enlace DHCPv6 válido puede existir junto a una ruta ausente, antigua o dirigida a otra sesión.

RFC 7084 exige al router CE funciones adicionales: aceptar longitudes distintas de la pista solicitada, mantener el encaminamiento WAN, seleccionar /64 para la LAN y anunciarlos. Son obligaciones relacionadas, no una única confirmación atómica. Además, la parte del agregado delegado que no se asigne a ninguna LAN debe terminar en destino nulo; poseer el /56 no vuelve alcanzable cualquier dirección del bloque.

Qué debe contener la evidencia

El registro comienza por los identificadores de cliente y servidor, el contexto de transacción, IAID, prefijo, longitud, estado, T1, T2 y vigencias. Después incorpora el router de acceso responsable, el siguiente salto, la generación de RIB/FIB y la sesión del abonado. En el CE conserva la ruta por defecto, el /64 usado en la LAN, la generación de reenvío y las vigencias de los anuncios.

Las pruebas de tráfico deben usar una dirección del /64 realmente asignado, declarar el punto de observación y separar ida de retorno. Un ping sin vínculo con el prefijo y la generación actuales puede probar una caché o un estado anterior.

RFC 9096 añade el factor temporal: un IAID estable evita renumeraciones accidentales, las vigencias de la LAN no pueden superar la vigencia restante de la delegación y la información obsoleta debe señalarse. Renew, Rebind, reinicio, cambio de prefijo o sustitución de ruta invalidan la evidencia anterior.

Fuentes