Resumen

  • CRH-16 y CRH-32 son dos cabeceras experimentales de la RFC 9631; cada SID corto consulta una entrada local con dirección IPv6, función topológica y argumentos opcionales.
  • El valor transportado no incluye la versión de la CRH-FIB ni la procedencia de su configuración. Dos nodos, o dos épocas de un mismo nodo, pueden ejecutar decisiones distintas ante el mismo número.
  • La prueba de ruta debe enlazar validación, estado instalado, ACL y uRPF, reescritura de destino, interfaz real, observación del siguiente salto y recepción final.

Una captura mostró el número correcto. El contador de búsqueda subió. Segments Left disminuyó como indicaba la especificación. Aun así, el paquete salió por una interfaz que el controlador ya no consideraba parte de la ruta.

La captura no mentía. El error estaba en pedirle que contara una decisión que nunca viajó dentro del paquete.

La RFC 9631 propone el Compact Routing Header como experimento IPv6. Sus SID de 16 o 32 bits reducen el espacio que ocupa una lista de segmentos. Esa compactación convierte a la CRH-FIB local en parte inseparable del significado.

El SID señala un cajón local

Los SID aparecen en orden inverso. El nodo reduce Segments Left, toma la posición resultante y busca el identificador en su CRH-FIB. La entrada devuelve una dirección IPv6, una función topológica y, si la función lo requiere, parámetros.

La función puede ordenar que se llegue a la dirección por el camino de menor coste. También puede imponer una interfaz concreta. Por eso el SID no es un resumen autosuficiente de la ruta: es el índice de una decisión almacenada fuera de la cabecera.

La RFC permite que los identificadores tengan alcance de dominio o solo de nodo. Cada SID lo procesa exactamente un router configurado para CRH cuya dirección coincide con el destino actual. El 2 de un equipo puede ser ajeno al 2 de otro. En el mismo equipo puede cambiar después de una orden CLI, una transacción PCEP o NETCONF, o una actualización distribuida.

Para interpretar la captura hacen falta el nodo, la hora, la revisión instalada, la entrada, la función, sus argumentos y la fuente que la programó. Sin esos datos, el SID prueba que hubo una consulta, no qué autoridad gobernó el salto.

Pasar la gramática no es recorrer el camino

El algoritmo rechaza una cabecera mayor de lo que la implementación admite. Calcula la longitud mínima compatible con el tipo y los segmentos restantes. Descarta una longitud imposible, una entrada inexistente y una dirección multicast situada antes del último segmento. En esos casos prescribe mensajes ICMPv6 Parameter Problem.

Es una frontera útil: distingue entradas legales de ciertos errores. Pero la acción decisiva viene después. El router copia la dirección de la entrada en el destino IPv6 y entrega el paquete, la función y sus argumentos al módulo IPv6. Ese módulo selecciona el siguiente salto o ejecuta la conducta solicitada.

Por tanto, un “CRH válido” no demuestra salida. Tampoco basta con no ver ICMPv6: el error puede perderse o limitarse, y una entrada válida puede dirigir a un enlace caído. Incluso una salida observada no demuestra que el siguiente nodo conservó el paquete ni que la aplicación lo usó.

El comprobante debe mantener separadas la validación, la resolución, la reescritura, la selección, la transmisión y la recepción. Juntarlas bajo un único estado sano solo desplaza la incertidumbre.

La configuración tiene una historia que la cabecera no guarda

La CRH-FIB puede proceder de una consola del operador, un controlador PCEP o NETCONF, o un protocolo distribuido. La RFC deja esos métodos fuera de su alcance. Esa neutralidad evita imponer una arquitectura de control, pero no resuelve las carreras entre intención e instalación.

Un controlador puede confirmar su cálculo antes de que el ASIC reciba la entrada. Dos routers pueden converger en momentos distintos. Una reversión puede recuperar el SID y no los parámetros. Una actualización parcial puede dejar la función nueva junto a un argumento antiguo.

El paquete no lleva un identificador de época. La investigación necesita conservar solicitud, configuración candidata, estado operacional, programación del plano de datos y observación del paquete con relojes comparables. Dos volcados correctos tomados antes y después del cambio no identifican por sí solos cuál decidió el tránsito intermedio.

Esta dependencia también cambia la prueba de interoperabilidad. Leer el mismo formato es solo el comienzo. La RFC pide saber si las implementaciones admiten funciones y argumentos equivalentes y si entienden su semántica del mismo modo. Compartir el SID mientras se discrepa sobre el efecto es interoperabilidad de bits, no de ruta.

El prefijo de origen no firma al remitente

RFC 9631 considera fiables a los nodos operados por la misma parte y usa la dirección de origen para reconocerlos. Los nodos deben bloquear con ACL los CRH que vengan de fuentes no fiables hacia una dirección local.

Una dirección se puede falsificar. EFP-uRPF reduce ciertas falsificaciones, pero no todas. Además, cada borde debe rechazar CRH entrantes cuyo origen simule una interfaz perteneciente a un nodo fiable.

De aquí sale otra cadena de pruebas: interfaz de entrada, conjunto de prefijos, versión y ubicación de la ACL, regla aplicada, contador o traza, datos de enrutamiento usados por uRPF y resultado. La apariencia del origen no sustituye esa decisión.

Authentication Header puede proteger la integridad del paquete bajo sus claves. No certifica qué versión de la tabla local se consultó, que todas las fronteras tenían el filtro correcto o que el paquete recorrió el camino previsto.

Ahorrar bytes no mide el coste real

La motivación es concreta. Algunos ASIC trasladan las cabeceras desde memoria de búfer a memoria interna limitada. Además, la fragilidad práctica de Path MTU Discovery hace que muchos emisores permanezcan cerca del mínimo IPv6 de 1.280 bytes, donde una cabecera grande consume una fracción relevante.

La hipótesis merece experimento. El resultado depende del hardware, la profundidad de análisis, el número de SID, el tamaño de carga, las MTU, el tratamiento de ICMPv6 y la mezcla de tráfico. Una cabecera corta puede activar un camino lento o llegar a un nodo sin soporte.

Para afirmar mejora hay que conservar línea base, versiones, distribución de tamaños, pérdida, latencia y definición de contadores. El ancho del campo se lee en la RFC. El beneficio aparece solo en ejecución comparada.

El documento experimental no es un certificado de despliegue

RFC 9631 no está en Standards Track. Pide resultados sobre esfuerzo e incrementalidad del despliegue, sincronización, actualización de hardware, alcance de los SID, seguridad, rendimiento, eficacia y coste de ACL, población de la FIB, escala, interoperabilidad y OAM.

Esa enumeración es una lista de asuntos todavía por demostrar, no una conclusión implícita. Que ping, traceroute, tcpdump o Wireshark reconozcan la cabecera mejora la observación. No responde si el significado fue común, el borde fue seguro o el destino obtuvo un efecto útil.

La autoridad debe avanzar con la evidencia: parser, tabla instalada, decisión de seguridad, salida, siguiente salto, destino y aplicación. Una etiqueta compacta coordina esas etapas. No las reemplaza.

Fuentes