Resumen

  • RFC 9792 creó un sub-TLV Prefix Extended Flags de longitud variable para OSPFv2 y OSPFv3, sin definir ningún bit en el propio documento.
  • Hoy IANA registra U y UP conforme a RFC 9929, pero la asignación no sustituye pruebas de implementación, emisión, aceptación o encaminamiento.

Cuando apareció en junio de 2025, la RFC 9792 afirmaba con precisión que no definía bits. Había normalizado el espacio donde otras especificaciones podrían describir propiedades, junto con las reglas para tratarlo si falta, llega recortado, se repite o está mal formado. Había sintaxis, no una nueva propiedad del prefijo.

En OSPFv2, el sub-TLV es de tipo 11 y vive dentro del Extended Prefix TLV de RFC 7684. En OSPFv3, el tipo 37 puede aparecer en los TLV de prefijo de RFC 8362 y en el SRv6 Locator TLV de RFC 9513.

El valor se organiza en bloques de 32 bits. Su longitud debe ser múltiplo de cuatro octetos; de lo contrario, la LSA contenedora es inválida y debe ignorarse. El emisor termina en el último bloque que necesite para transportar un uno. Un indicador definido más allá de la longitud recibida se interpreta como cero. Los bits no asignados deben transmitirse a cero e ignorarse.

Así, ausencia y cero evitan una inferencia positiva. Los receptores antiguos ignoran el sub-TLV desconocido según RFC 3630 o RFC 8362. Si el mismo TLV padre contiene varias instancias, se usa únicamente la primera; las posteriores se descartan y el error se registra con límite de frecuencia. El receptor no combina copias.

Una segunda norma aporta el significado

Los registros vivos de IANA para OSPFv2 y OSPFv3 ahora asignan el bit 0 a U y el bit 1 a UP mediante RFC 9929; 2–31 siguen sin asignar. La cronología es esencial: RFC 9792 creó el contenedor y RFC 9929 añadió después las primeras propiedades.

Incluso un bit activado necesita contexto. U señala un prefijo inalcanzable; UP, uno cuya inalcanzabilidad está planificada. UP sin U se ignora. En OSPFv2 ambos requieren métrica LSInfinity. En OSPFv3 también se exige LSInfinity y NU en Prefix Options. Ese campo fijo, definido en RFC 5340, no fue reemplazado por la extensión.

La formulación responsable encadena las capas: documento normativo, registro IANA, versión de software, configuración, LSA completa transmitida, interpretación del receptor, cálculo, FIB y tráfico. “IETF Review”, conforme a RFC 8126, controla la asignación del nombre y el número; no observa ninguna red.

La utilidad inicial de RFC 9792 consistió precisamente en limitar el significado. Una extensión puede cruzar receptores antiguos sin ser entendida, pero esa tolerancia no demuestra que una política nueva haya sido aplicada de extremo a extremo.

Fuentes