Resumen

  • RFC 10038, publicado como norma del IETF en agosto de 2026, define OPTION_IA_SRV6_LOCATOR con código 149, OPTION_IALOCATOR con código 150 y NoSRv6LocatorAvail con código de estado 23 para distribuir locators SRv6 mediante DHCPv6.
  • El Reply demuestra una vinculación decidida por el servidor dentro de un dominio SR de confianza. No demuestra configuración local, instalación de ruta, anuncio IGP, selección en RIB, programación de FIB, comportamiento SID, paso de filtros, resultado del paquete ni retirada completa.

Supongamos que un equipo de borde recibe dos locators. El sistema de aprovisionamiento muestra los dos en el mismo orden y alguien interpreta el primero como producción y el segundo como respaldo. La especificación prohíbe esa inferencia: el orden no lleva lógica de servicio. El error no está en los bits recibidos, sino en convertir una presentación en una política que el servidor nunca prometió.

Esa precaución resume el valor de RFC 10038. Publicado en agosto de 2026, el documento distribuye un SRv6 Locator a un nodo terminal de segmentos por medio de DHCPv6 dentro de un único dominio SR de confianza. IANA incorporó las opciones y el estado al registro de parámetros DHCPv6.

OPTION_IA_SRV6_LOCATOR es el contenedor. Incluye IAID, T1, T2 y opciones anidadas. Una solicitud puede llevar varias instancias, cada una con IAID único en un espacio numérico separado de otras asociaciones de identidad. Dentro se coloca OPTION_IALOCATOR, que contiene las vidas preferida y válida, Algorithm, LB-Len, LN-Len, Fun-Len, Arg-Len y el locator codificado con la longitud mínima necesaria.

LB-Len más LN-Len define la longitud del locator. Las cuatro longitudes no pueden sumar más de 128 y la primera suma no puede ser cero. Si una opción viola esas reglas, queda inválida; no autoriza a descartar la distinción entre las demás etapas.

La preferencia del cliente no es una orden

El cliente debería enviar T1, T2 y las vidas preferida y válida a cero. El servidor ignora los valores que el cliente ponga allí y calcula el estado temporal. También puede recibir una pista: LB-Len y LN-Len distintos de cero con :: como locator. Esa combinación expresa una preferencia de tamaño, no un derecho a un prefijo, una geometría o una duración.

La política del servidor decide el pool, la forma y si un cliente puede recibir más de un locator. Puede responder NoSRv6LocatorAvail. El cliente descarta una concesión cuya vida preferida supere la válida. Tampoco asigna prioridad o función según el orden de llegada.

RFC 9915 aporta las reglas generales de DHCPv6: identidad, Solicit, Advertise, Request, Reply, renovación, re-vinculación y Release. Un intercambio correcto acredita la transacción de asignación. No contiene la confirmación de que un proceso IGP haya originado o aceptado una ruta.

El locator tampoco equivale a un SID completo. RFC 8402 define la arquitectura de Segment Routing y RFC 8986 los comportamientos SRv6. La asignación de SID locales, el uso simultáneo de varios locators y el anuncio de SID individuales quedan fuera de RFC 10038. El nodo administra esa superficie bajo su propia política.

La ruta tiene varios propietarios después del Reply

Un relay o servidor DHCPv6 puede instalar una ruta local hacia el locator, con el solicitante como siguiente salto, y puede anunciarla mediante un protocolo de enrutamiento tradicional. Son capacidades explícitas, no efectos inevitables del mensaje DHCPv6.

Después aparecen decisiones independientes. El origen publica; cada vecino autentica e importa; el cálculo IGP determina una ruta; cada RIB selecciona; la plataforma programa su FIB. Una entrada puede faltar por política, convergencia, capacidad o fallo de programación. Observar la ruta en el relay solo habla del relay.

Algorithm cero admite alcanzabilidad IPv6 ordinaria. Para Algorithm distinto de cero, RFC 10038 exige los TLV de locator correspondientes. RFC 9350 describe los algoritmos flexibles de IGP y sus restricciones. Si la automatización reduce esa información a un prefijo normal, mantiene una dirección legible pero pierde la intención topológica.

El último tramo también conserva autonomía. RFC 8754 regula el Segment Routing Header de IPv6 y RFC 8986 la ejecución en el extremo. La llegada al nodo no demuestra que exista el SID deseado ni que su función sea la prevista. Los filtros pueden aceptar un comportamiento y negar otro. La asignación identifica espacio; la ruta ofrece un camino; la política local decide qué servicio existe.

El Release debe deshacer más que la concesión

Cuando el relay o servidor procesa un Release válido, debe liberar la vinculación, quitar su ruta local y retirar la ruta anunciada anteriormente. El orden de esas operaciones importa. La base de concesiones, los procesos IGP, las RIB, las FIB y el tráfico no comparten una transacción atómica.

La IA expira cuando ya no queda ningún locator válido dentro de ella. T1 conduce al cliente de vuelta al servidor original; T2 abre la renovación a un servidor disponible. Las vidas son segundos restantes y 0xffffffff representa infinito. Esos relojes gobiernan la relación administrativa. No observan cuándo desapareció la última copia de la ruta.

La agregación impide usar “prefijo específico retirado” como sinónimo de “tráfico imposible”. Una ruta de cobertura puede seguir llevando paquetes al borde delegante. Ese borde debe descartar, en la interfaz orientada al cliente, los destinos que ya no estén delegados. Así evita que una autoridad antigua sobreviva detrás de un agregado.

La reutilización requiere una secuencia verificable: cerrar la concesión; eliminar la ruta local; retirar el origen; observar la retirada en RIB y FIB diversas; borrar el comportamiento SID; demostrar silencio para el tráfico antiguo y rechazo para el prohibido; guardar un periodo de cuarentena; solo entonces devolver el locator al pool.

La confianza del dominio tiene límites físicos

El “dominio SR de confianza” define dónde pretende operar la extensión. No aporta cifrado extremo a extremo universal a DHCPv6 ni autentica cada paquete. Sin protecciones adicionales persisten secuestro, alteración y escucha. Un CPE fronterizo necesita filtros internos y externos, y conviene distinguir el espacio de locators de infraestructura del direccionamiento corriente de usuarios.

Si DHCPv6 y otro asignador comparten el mismo pool sin coordinación, ambos pueden entregar el mismo locator. Un límite por cliente tampoco frena necesariamente a quien presenta muchas identidades. Las directrices de RFC 7227 y RFC 8168 recuerdan la disciplina necesaria al crear opciones y semánticas de dirección. RFC 8987 añade el contexto operativo de la programación SRv6. El número de IANA evita colisiones de protocolo; no evita por sí mismo una colisión en el pool.

El registro común debe unir la concesión con los paquetes

Para cada locator hay que conservar DUID, IAID, puerto o relay, autorización y versión de política; la pista solicitada y el diseño concedido; tiempos de transacción, vidas, T1/T2; estado de la vinculación y dueño del pool; configuración y SID locales; ruta y siguiente salto en RIB/FIB del origen; tipo, algoritmo y versión del anuncio IGP; observaciones remotas; filtros; canarios permitidos y denegados; finalmente Release o expiración, retirada, último paquete, cuarentena y reutilización.

La primacía del código en ejecución de Heng Lu exige que el expediente siga esos actos reales. Su distinción entre soberanía técnica y control práctico explica por qué poseer la vinculación no equivale a poseer cada copia de la ruta. Su propuesta de especificación mínima y decisiones futuras localizadas encaja con RFC 10038: el protocolo crea una gramática estrecha; cada operador conserva sus decisiones y consecuencias.

El servidor puede decir con precisión qué entregó. La red todavía debe demostrar qué hizo con ello.