Resumen

  • DHCPv6-PD entrega el uso de un prefijo a un router solicitante, pero no describe la topología que existe detrás de él.
  • El solicitante debe convertir el arrendamiento en subprefijos estables y tiempos coherentes; el CE debe mantener rutas que unan cada arrendamiento con su siguiente salto.
  • Un recibo de delegación a ruta debe unir el estado del protocolo con pruebas de paquetes en ambas direcciones.

El arrendamiento está verde, la LAN está a oscuras

Imaginemos que la consola de soporte muestra un intercambio IA_PD satisfactorio. El router descendente recibió un prefijo, sus tiempos preferido y válido disminuyen con normalidad y no aparece ningún error DHCPv6. Sin embargo, los paquetes dirigidos a un servidor detrás de ese router mueren en el equipo de borde. El CE nunca instaló la ruta del prefijo con el router descendente como siguiente salto, o la retiró antes de que el cliente dejara de usarlo.

Ambos paneles pueden ser ciertos. DHCPv6 puede mostrar una delegación vigente mientras el plano de reenvío está incompleto. El error es convertir el éxito del arrendamiento en prueba de reserva del pool, asignación a enlaces, anuncios, programación y alcance.

RFC 8415 marca esa frontera. La delegación está diseñada para escenarios en los que el router delegante no conoce la topología conectada al solicitante. El servidor elige el prefijo y lo devuelve; el cliente pasa a ser responsable. Puede subdividirlo, asignar redes a interfaces y anunciarlas. Son decisiones posteriores, no atributos del estado de éxito de IA_PD.

Una transferencia de responsabilidad con límites temporales

La unidad operativa no es «hay prefijo», sino identidad del cliente, IAID, prefijo y longitud, servidor, T1, T2, tiempo preferido, tiempo válido y hora de observación. Una renovación puede ampliarlos, pero RFC 8415 también permite al servidor cambiar la lista de prefijos o devolver uno inapropiado con tiempos cero. Por eso debe guardarse la respuesta exacta.

Los tiempos forman una jerarquía. Las direcciones o subprefijos derivados no pueden anunciarse con un tiempo restante mayor que el del prefijo padre. De lo contrario, la LAN conserva direcciones aparentemente utilizables después de expirar la autoridad ascendente. Para el usuario parece un fallo de ruta, aunque la causa sea una frontera temporal rota.

RFC 9818 añade requisitos para los CE que delegan en la LAN. Deben admitir IA_PD en sus interfaces internas, asignar desde el pool disponible y registrar un error si no hay espacio suficiente. El prefijo de un enlace no debe cambiar sin una modificación de política o topología. Y el CE debe actualizar dinámicamente su tabla local con los arrendamientos y siguientes saltos, eliminando la ruta cuando el prefijo se libera o caduca.

Quedan fallos independientes: bloque ascendente insuficiente, subprefijo mal reservado, anuncio descendente ausente, arrendamiento sin ruta, tiempos hijos demasiado largos o políticas diferentes para ida y vuelta. Volver a leer únicamente el Reply de DHCP no resuelve ninguno.

Construir el recibo a ambos lados

En el lado delegante se conserva servidor, DUID, IAID, prefijo exacto, hora, T1/T2, tiempos preferido y válido, y tipo de evento: asignación, Renew, Rebind, Release o caducidad. En el solicitante se registran los subprefijos realmente asignados, sus interfaces o routers, los tiempos heredados y la versión de configuración que tomó la decisión.

Después se incorpora la prueba de reenvío: ruta del CE, siguiente salto, interfaz, instante de instalación, política que podría suprimirla y evento que la retira. En el router descendente se documentan la ruta local, los Router Advertisements y la selección de direcciones esperada. Por último se prueban paquetes y servicio en ambos sentidos. Un ping desde el CE no cubre DNS, filtros con estado, selección de origen ni un retorno asimétrico.

El recibo se evalúa en cuatro momentos: delegación inicial, renovación, cambio de política o topología, y retirada o caducidad. La misma cadena de prefijo en dos instantes no garantiza el mismo estado operativo.

Mantener el alcance correcto

El recibo no convierte DHCPv6 en un protocolo de topología. Reúne evidencia distribuida respetando la división de responsabilidades. Tampoco resuelve la selección de origen o las políticas multioperador. RFC 9818 deja fuera las redes con varios prefijos y proveedores por su complejidad; en ese entorno deben añadirse pruebas específicas de egreso, retorno y dominio de fallo.

Fuentes