Resumen

  • RFC 9647, publicado como estándar en octubre de 2024, define el módulo YANG 1.1 ietf-babel, compatible con NMDA y basado en RFC 9046, para la gestión de Babel sobre IPv6. Su valor principal es hacer visible una parte del estado operativo y administrativo que antes dependía de interfaces de gestión heterogéneas.
  • El modelo permite inspeccionar y configurar elementos como habilitación, constantes, interfaces, conjuntos de claves MAC, objetos DTLS y rutas. Sin embargo, YANG no puede obligar por sí mismo a que una implementación proporcione atributos obligatorios de solo lectura del modelo de información; esos datos deben ser poblados por la implementación.
  • Una ruta marcada como selected representa una proyección de estado interno de gestión. No constituye por sí sola una medición independiente de reenvío, autenticación completa, instalación en la FIB ni alcanzabilidad extremo a extremo.
  • La evidencia operacional fiable requiere una cadena de diez comprobantes: revisión del módulo y sus capacidades, origen temporal del dato, presencia del estado requerido, clasificación real de interfaces, resolución de valores efectivos, identidad criptográfica aplicada, resultados de autenticación, cronología de vecinos y rutas, instalación en tablas de reenvío y pruebas externas de comportamiento.

La nueva superficie de control de Babel

Los protocolos de enrutamiento distribuido generan una paradoja operativa: cuanto más automatizada es la selección de caminos, más importante resulta saber qué parte del camino de decisión puede observarse y qué parte permanece dentro de la implementación. En Babel, una ruta seleccionada puede parecer una respuesta definitiva del sistema, pero el operador necesita separar tres preguntas diferentes: qué decidió el algoritmo, qué instaló el sistema y qué ocurrió realmente cuando los paquetes circularon.

RFC 9647 aborda precisamente la primera capa de transparencia. El documento define un modelo YANG para administrar Babel utilizando el módulo ietf-babel en versión YANG 1.1. El modelo está diseñado conforme a la arquitectura de gestión basada en datos de red (NMDA) y deriva de los conceptos definidos en RFC 9046. Su ámbito es la gestión de Babel sobre IPv6, proporcionando una representación común para equipos y sistemas que necesitan exponer configuración y estado.

La especificación está disponible en el texto oficial de RFC 9647, su ficha de publicación, el registro del trabajo en IETF Datatracker y el buscador de erratas: RFC 9647, información del RFC, IETF Datatracker y erratas de RFC 9647.

El cambio importante no es que Babel adquiera una nueva lógica de selección de rutas. El cambio es que una parte mayor de esa lógica y de su contexto administrativo puede representarse mediante un modelo de datos común.

Qué hace visible RFC 9647

El modelo cubre varias dimensiones que forman la operación diaria de Babel: habilitación del protocolo, constantes, interfaces, conjuntos de claves MAC, objetos DTLS y rutas.

En el nivel de rutas, el estado incluye información como prefijo, identificador del router, vecino, métrica recibida y calculada, número de secuencia, siguiente salto, condición de factibilidad y estado de selección. Estos campos permiten reconstruir una parte de la historia de decisión: qué anuncio llegó, desde quién, con qué atributos y cuál terminó siendo la opción elegida.

Pero existe una frontera fundamental. Una estructura YANG no es una garantía física de la red. RFC 9647 señala explícitamente que YANG no puede imponer que una implementación rellene atributos obligatorios de solo lectura del modelo de información. La existencia de un campo definido por el modelo no demuestra automáticamente que un dispositivo lo publique con datos completos, precisos o actualizados.

Por ello, una auditoría seria debe distinguir entre “el modelo permite preguntar” y “la respuesta obtenida representa correctamente la realidad operativa”.

La diferencia entre intención administrativa y estado efectivo

Uno de los puntos más importantes del modelo es la separación entre intención y realidad operacional. El nodo enable representa la intención administrativa en los almacenes de configuración como running o intended, mientras que el estado efectivo de ejecución aparece en la información operacional.

Esta separación evita una confusión habitual: una configuración aceptada no equivale necesariamente a un protocolo activo. Puede existir una intención administrativa de habilitar Babel y, al mismo tiempo, una diferencia temporal, de implementación o de dependencia que impida que esa intención produzca comportamiento efectivo.

En entornos donde existen automatización y múltiples capas de gestión, la pregunta correcta deja de ser “¿está configurado Babel?” y pasa a ser “¿qué intención llegó al sistema activo, cuándo llegó, desde qué origen y qué estado operativo confirma su aplicación?”.

RFC 8342 describe la arquitectura NMDA que sustenta esta separación entre configuración e información operacional: RFC 8342.

Interfaces: donde los valores predeterminados pueden cambiar la interpretación

RFC 9647 también modela interfaces Babel, y aquí aparece una zona donde los detalles operativos importan especialmente. Babel utiliza comportamientos distintos según el tipo de enlace. Para interfaces cableadas, los valores predeterminados incluyen una política de selección basada en dos de tres anuncios y split horizon. Para interfaces inalámbricas, los valores predeterminados utilizan ETX sin split horizon.

Esto significa que una observación superficial de una ruta no revela necesariamente la política que produjo esa decisión. Un puerto cableado, un enlace radio, un túnel o una ruta de respaldo con coste económico pueden requerir una interpretación diferente.

Los operadores deben prestar especial atención a casos como radios conectadas detrás de puertos cableados, túneles que no reflejan las características físicas del transporte subyacente o enlaces de respaldo medidos por consumo. En estos escenarios, los valores predeterminados pueden necesitar anulaciones explícitas y elecciones concretas de temporizadores.

La pregunta operativa no es únicamente “¿qué interfaz participa en Babel?”, sino “¿qué clasificación recibió, qué valores efectivos quedaron aplicados y por qué?”.

Criptografía: configuración visible, identidad todavía verificable

RFC 9647 incorpora objetos relacionados con autenticación MAC y DTLS. Los valores predeterminados de aplicación para MAC y DTLS pueden añadir referencias a interfaces creadas posteriormente, facilitando una política reutilizable. Sin embargo, esa facilidad administrativa introduce otra obligación: comprobar que las referencias efectivas corresponden a las interfaces correctas.

Una configuración que contiene una referencia criptográfica no prueba que el intercambio autenticado haya ocurrido. Es necesario comprobar la asociación real entre interfaz, identidad, claves, vecino y resultado de negociación.

Las claves MAC sensibles y las claves privadas DTLS cuentan con protecciones mediante NACM. RFC 8341 define el modelo de control de acceso basado en roles para datos YANG: RFC 8341.

La seguridad de RFC 9647 está limitada al modelo YANG. El propio RFC aclara que las consideraciones de seguridad específicas del protocolo Babel, incluida la protección MAC y DTLS, se encuentran en los documentos correspondientes: RFC 8966, RFC 8967 y RFC 8968. Esos textos deben consultarse para evaluar amenazas y mecanismos de seguridad del protocolo: RFC 8966, RFC 8967 y RFC 8968.

La cadena de diez comprobantes

Para convertir una fila de estado Babel en una conclusión operacional defendible, hace falta una cadena de evidencia más amplia que el dato selected.

El primer comprobante es la revisión de la versión del módulo, sus revisiones y características disponibles. El segundo es el contexto del dato: almacén YANG de origen, momento de captura y procedencia. El tercero es la presencia efectiva de los estados de solo lectura necesarios, reconociendo que la implementación debe proporcionarlos.

El cuarto comprobante es la clasificación verificada de la interfaz. El quinto es la resolución de valores efectivos: qué vino de los valores predeterminados y qué fue modificado mediante configuración explícita. El sexto conecta identidad y seguridad: conjuntos de claves MAC, objetos DTLS y sus asociaciones reales.

El séptimo comprobante son los resultados de autenticación y negociación con vecinos. El octavo reconstruye la cronología de vecinos y rutas: anuncios recibidos, cambios de secuencia, métricas calculadas y decisiones posteriores. El noveno verifica que la decisión llegó a la infraestructura de reenvío, incluyendo la instalación correspondiente en RIB y FIB.

El décimo abandona el plano de gestión: prueba el reenvío mediante paquetes, recuperación tras cambios y observación independiente de alcanzabilidad.

Esta cadena evita un error común en la operación de redes: tratar una representación administrativa como si fuera una medición completa del mundo físico.

Límites de evidencia y decisiones operativas

RFC 9647 mejora la capacidad de inspección, pero no elimina la necesidad de correlacionar múltiples fuentes. Una ruta seleccionada puede quedar invalidada por una instalación incompleta, una política de interfaz inesperada, un fallo de autenticación posterior o un problema fuera del alcance del modelo.

El modelo YANG tampoco proporciona por sí solo una prueba de disponibilidad de aplicación, calidad de experiencia o funcionamiento extremo a extremo. Es una pieza dentro de una arquitectura de observabilidad más amplia.

La referencia de asignaciones YANG de IANA proporciona el contexto de registro utilizado por módulos YANG: IANA YANG Parameters. La base conceptual de extensiones y módulos relacionados con Babel se apoya también en RFC 9046: RFC 9046.

Sources