Resumen

  • En RFC 9740, ipv6ExtensionHeadersLimit=false declara información parcial por un límite de inspección; true declara que la información corresponde a todas las cabeceras de extensión contenidas. El nombre del elemento puede inducir a leerlo al revés.
  • Los nuevos elementos distinguen tipo, repetición consecutiva, orden y longitud. Poder representar una cabecera observada no demuestra que un destino haya procesado su función ni que todos los equipos hayan implementado el formato.
  • Las observaciones ausentes o limitadas deben mantenerse separadas de un cero válido. Un salto de uso registrado tras una actualización puede ser un salto de visibilidad.

El cero que llega demasiado lejos

Pensemos en tres exportadores frente a una cadena con HIP en una posición tardía. Uno recorre la cadena completa. Otro alcanza su límite antes de esa posición. Un tercero sigue usando un campo que no representa HIP. Si los dos últimos terminan etiquetados como «sin HIP», el sistema ha emitido una conclusión que ninguno de ellos estableció. Es un ejemplo hipotético, no una prueba de un producto concreto.

RFC 9740, publicado en marzo de 2025 en la vía normativa de IETF, añade doce elementos de información IPFIX y el tipo unsigned256. El antiguo ipv6ExtensionHeaders (64) tenía un conjunto representable congelado: no cubría HIP, protocolo 139, Shim6, 140, ni las extensiones experimentales, y no expresaba explícitamente orden, repetición, longitud de cadena o informe completo frente a limitado. tcpOptions (209) solo representaba Kinds hasta 63 y no identificaba experimentos que comparten 253 y 254. Ambos están obsoletos. Cambiar el nombre de una columna histórica no amplía la evidencia que produjo.

Una declaración de alcance, no de resultado

La regla central está en §3.5. ipv6ExtensionHeadersLimit (517) es false cuando lo exportado cubre únicamente la porción disponible hasta un límite, normalmente de hardware o software. Es true cuando corresponde a las cabeceras de extensión completas contenidas. Si falta el elemento, no existe por ello una declaración afirmativa de inspección completa.

Además, el booleano IPFIX no usa el cero ordinario del código. RFC 7011 §6.1.5 codifica true como 1 y false como 2; otros valores son indefinidos. Un cero bruto no es un false normativo. Esa distinción no invalida un bitmap legítimo cuyo valor sea cero.

Incluso la declaración completa está acotada a lo observado. La definición de Flow de RFC 7011 reúne paquetes con propiedades comunes en un punto de observación y un intervalo. No acredita todos los paquetes del enlace, otros caminos, toda una población de aplicaciones o el procesamiento correcto en el extremo receptor. La selección y el denominador siguen siendo externos a esa declaración.

Tampoco debe inferirse un descarte de un informe limitado. RFC 8883 describe límites de procesamiento y diagnósticos ICMP relacionados con longitudes o cantidades excesivas de cabeceras. Inspección, reenvío y exportación son hechos distintos. Un diagnóstico puede perderse, filtrarse o limitarse en frecuencia; su silencio no prueba éxito.

Cada representación responde a otra pregunta

RFC 8200 sitúa las extensiones en una cadena enlazada por Next Header antes de la capa superior. RFC 9740 permite describirla con precisión sin confundir sus dimensiones. ipv6ExtensionHeaderType (513) informa del código observado. ipv6ExtensionHeaderCount (514) cuenta repeticiones consecutivas del mismo tipo: no paquetes, usuarios ni adopción.

La lista ordenada ipv6ExtensionHeaderTypeCountList (516) conserva los pares tipo-cuenta. En Hop-by-Hop, Destination Options, Fragment, Destination Options, las dos posiciones de Destination Options permanecen separadas. Las cadenas distintas dentro de un Flow deben notificarse por separado. Si la implementación determina que un código observado es una extensión, debe incluir el código exacto aunque no soporte su función. Distinguir una extensión desconocida de un protocolo de capa superior desconocido sigue siendo un problema de clasificación.

El bitmap ipv6ExtensionHeadersFull (515) informa presencia entre los paquetes observados del Flow, pero no conserva orden. Sus bits proceden del registro IANA IPFIX: Destination Options, protocolo 60, corresponde al bit 0; Hop-by-Hop, 0, al bit 1; HIP, 139, al bit 10. El número de protocolo no es la posición del bit. No Next Header se incluye como excepción deliberada aunque no sea una extensión. RFC 9740 prohíbe exportar juntos 515 y 516.

ipv6ExtensionHeadersChainLength (518) suma en octetos las longitudes de las extensiones y excluye las cabeceras IPv6 básica y de capa superior. No cuenta cabeceras. ipv6ExtensionHeaderChainLengthList (519) empareja 515 con 518 y mantiene separadas las cadenas diferentes. Con 519 no se deben agregar sus bitmaps; sin esa lista, el RFC permite combinarlos o separarlos según sus reglas. La pareja de presencia y longitud no reconstruye el orden ni convierte una observación parcial en completa.

Una actualización puede fabricar una tendencia aparente

tcpOptionsFull (520) asigna directamente cada Kind TCP, de 0 a 255, a su bit. Puede informar una opción observada aunque el exportador no ejecute su función. IPv6 usa otra política: las nuevas atribuciones de extensiones se reflejan en el próximo bit libre del registro IPFIX; excepciones que necesitan bits de comportamiento pasan por Expert Review. Actualizar el registro no actualiza simultáneamente todos los analizadores y colectores.

El nuevo tipo lógico de 256 bits tampoco exige siempre 32 octetos en el mensaje. El codificado de tamaño reducido omite ceros iniciales permitidos y el Template declara la longitud transmitida. Un valor presente y abreviado correctamente es distinto de un elemento ausente. Almacenar enteros anchos no demuestra que el equipo inspeccione una cadena amplia.

RFC 6994 distingue experimentos que comparten 253 y 254 mediante ExID de 16 o 32 bits. Las listas de ExID de RFC 9740 tienen precedencia: si están presentes para el Flow, los bits genéricos compartidos deben permanecer a cero. Leer solo el bitmap puede perder información positiva. La identificación autónoma y la determinación de anchura suponen una lista válida de ExID mantenida por la implementación, no garantizada por registrar un elemento.

Por tanto, reemplazar 64 o 209, ampliar la inspección o cambiar una tabla puede elevar el uso registrado sin elevar el uso real. Una serie estable también puede ocultar que el tráfico ha superado la capacidad del instrumento. La comparación más sólida mantiene poblaciones equivalentes y, cuando es posible, mediciones solapadas sobre tráfico comparable. Si no hay solapamiento, necesita una ruptura declarada y una incertidumbre pendiente. Rellenar la región antes invisible con ceros solo suaviza la curva inventando evidencia. Estos documentos establecen semántica, no cifras actuales de adopción mundial ni pruebas de éxito en los extremos.

Fuentes