Resumen

  • Desde RFC 1883, los dos bits superiores del tipo de una opción TLV IPv6 marcaban la conducta ante un tipo no reconocido: omitirlo, descartar el paquete o descartarlo y devolver un error ICMPv6 que señalara el octeto problemático.
  • El tercer bit declaraba si los datos podían cambiar en tránsito. Era un contrato sobre las consecuencias de no saber, no una garantía de que todos los routers procesaran la opción, de que los cortafuegos la dejaran pasar o de que su contenido fuera confiable.

La compatibilidad empezaba con una frontera de bytes

Un nodo puede reconocer un encabezado Destination Options y, dentro de él, encontrar un TLV que su versión de software jamás vio. No conoce la función del valor, pero sí puede leer el tipo y Opt Data Len. Esa diferencia permite separar dos preguntas: dónde termina lo desconocido y qué hacer con ello.

RFC 1883, publicado en diciembre de 1995, insertó las respuestas en el octeto de tipo. Los dos primeros bits elegían la acción ante el desconocimiento; el tercero declaraba si los datos eran estables durante el trayecto. Los otros cinco seguían participando en la identidad.

Así, el autor de una opción nueva no transfería su significado a una máquina vieja. Solo declaraba una consecuencia común que esa máquina podía ejecutar sin adivinar.

Dos bits producían cuatro resultados

00 permite saltar la opción y continuar con el encabezado. La longitud indica cuántos octetos hay que avanzar. 01 exige descartar el paquete. 10 exige descartarlo y enviar a la fuente ICMPv6 Parameter Problem, Code 2, con un puntero al tipo que no se reconoció. 11 hace lo mismo, salvo que omite el informe si la dirección de destino era multicast.

No se trata de una escala de peligrosidad. Una opción marcada para omisión puede ser incompatible con una regla local; una opción que manda descartar puede ser legítima y simplemente necesitar comprensión para conservar su semántica.

El puntero mejora el diagnóstico porque identifica el punto exacto de ruptura. Aun así, el mensaje puede perderse, filtrarse o quedar sujeto a límites. Recibirlo demuestra una observación local. No recibirlo no distingue entre omisión exitosa, descarte silencioso y fallo anterior en el camino.

Multicast tenía una frontera propia

Los patrones 10 y 11 se separan precisamente por la respuesta a un destino multicast. El primero informa incluso en ese caso; el segundo descarta sin generar el error.

La diferencia hace visible el posible gasto de respuestas. Un operador puede leer qué solicita el tipo y contrastarlo con sus límites ICMP y con los paquetes emitidos. No convierte a multicast en sospechoso ni elimina la responsabilidad local de contener tráfico de control.

El tercer bit evitaba autenticar una ficción

El bit siguiente no decide el destino del paquete desconocido. Declara la mutabilidad del campo de datos. Cero significa que no cambia durante el trayecto; uno, que puede cambiar.

Cuando existe un Authentication Header, los datos marcados como mutables se consideran octetos cero al calcular o verificar el valor de autenticación. El diseño evita cubrir como invariante una zona que una función legítima puede modificar en tránsito.

La exclusión no concede poder de escritura. La especificación de cada opción sigue definiendo quién puede modificarla y cómo. El bit solo impide que el cálculo de integridad haga una promesa que ese campo no puede cumplir.

Los ocho bits formaban una identidad

RFC 2460 aclaró que los tres bits superiores no eran metadatos separables. Formaban parte del tipo completo de ocho bits. Coincidir en los cinco bits inferiores no bastaba para ser la misma opción.

Hop-by-Hop Options y Destination Options comparten el espacio de tipos, aunque la definición de uno puede limitar su ubicación. Además, las opciones deben procesarse en orden. El receptor no puede buscar una conocida más adelante y ejecutarla antes de resolver la desconocida que la precede.

El orden impide reescribir la causalidad: una instrucción temprana de descarte no puede quedar anulada porque al final aparezca algo familiar.

Opción desconocida y encabezado desconocido no eran lo mismo

Los bits viven dentro de un TLV alojado en un encabezado de opciones ya reconocido. No describen automáticamente cómo atravesar un valor Next Header que nombra un encabezado de extensión desconocido.

RFC 6564 prefirió usar nuevas opciones de destino cuando fueran suficientes y reservó la creación de nuevos encabezados para casos justificados. Para los futuros encabezados fijó un formato común con longitud, pero no cambió retrospectivamente todos los formatos existentes.

RFC 7045 asignó responsabilidades distintas. Un host de destino descarta el paquete con un encabezado de extensión que no reconoce. Un nodo de reenvío no debería descartarlo solo por desconocer un encabezado nuevo; si inspecciona la cadena, debe mantener actualizada su lista. Eso difiere de aplicar los bits de una opción desconocida dentro de un contenedor que sí sabe recorrer.

Los equipos intermedios mostraron el límite

Un cortafuegos o balanceador suele buscar puertos y otros campos de transporte. Cadenas largas, tipos nuevos y rutas lentas de procesamiento pueden consumir recursos o impedir encontrar esa información.

RFC 8200 conservó las cuatro acciones y el bit de cambio, pero condicionó el procesamiento Hop-by-Hop en tránsito a la configuración explícita. RFC 9098 documentó la disyuntiva operativa: dejar pasar sin la inspección deseada, descartar o sacar el paquete de la vía rápida.

El octeto de tipo no asigna capacidad de silicio ni obliga a un camino a aceptar el coste. Solo vuelve predecible a un procesador que ya alcanzó ese TLV.

Lo que los bits nunca decidieron

00 no autentica seguridad. 11 no prueba intención hostil. El bit mutable no permite cambios arbitrarios. Un tipo registrado no demuestra apoyo de extremo a extremo, y un ICMP no certifica identidad.

El contrato funciona porque es estrecho: especificación pública, aplicación local y prueba en paquetes reales.

Fuentes y límites de la evidencia

La regla aparece en RFC 1883, se precisa en RFC 2460 y continúa en RFC 8200. Los límites frente a encabezados nuevos y reenvío están en RFC 6564 y 7045; la realidad operativa, en RFC 9098. No son una medición actual de todos los fabricantes ni caminos.