Resumen

  • El campo cidr0_cidrs representa como prefijo el intervalo registrado entre 196.1.0.0 y 196.1.0.255.
  • La respuesta no demuestra una publicación BGP, un sistema autónomo de origen, una trayectoria ni la llegada efectiva del tráfico.
  • Registro y enrutamiento pueden compararse mediante el prefijo, pero cada dato debe conservar su fuente, fecha y alcance probatorio.

La misma notación no implica el mismo hecho

La observación parte de un objeto de registro. El 28 de agosto de 2026, el servicio RDAP público de AFRINIC respondió a la consulta de 196.1.0.0/24 con un objeto de clase ip network. El identificador superior abarca 196.1.0.0 - 196.1.0.255, el tipo es ASSIGNED PI y la lista cidr0_cidrs contiene una entrada con el prefijo 196.1.0.0 y longitud 24.

Todos esos valores reciben su significado del objeto que los contiene. Las direcciones inicial y final delimitan el registro. El parentHandle sitúa el objeto dentro de una jerarquía de registros. El estado active describe la instancia registrada. Ninguno de esos campos convierte la respuesta en una medición del plano de control de Internet.

La guía de AFRINIC explica que la consulta de una dirección o prefijo devuelve la red registrada más específica que lo engloba por completo. Es una respuesta a una pregunta de directorio: ¿qué objeto registrado contiene el recurso consultado? No es una búsqueda de la ruta más específica que observa un router ni de la trayectoria que seguirán los paquetes.

La ambigüedad surge porque CIDR también es el lenguaje habitual de las tablas BGP. Un colector podría mostrar la cadena 196.1.0.0/24 como destino de una ruta, mientras que RDAP usa exactamente esa cadena para expresar un intervalo de registro. La coincidencia textual permite relacionar datos; no permite atribuir a una fuente lo que solo aparece en la otra.

En BGP, una ruta combina destinos expresados como información de alcanzabilidad con atributos de camino intercambiados entre sistemas autónomos. Una afirmación sobre esa ruta necesita un punto de observación, una hora, un origen y los atributos recibidos. El registro RDAP observado no contiene ese conjunto de elementos.

Por eso el prefijo debe tratarse como una clave, no como una conclusión. Puede unir una ficha de registro con una observación de enrutamiento independiente. Hasta que exista esa segunda observación, los campos «ruta vista», «AS de origen» o «alcanzabilidad» deben permanecer vacíos.

Para qué existe cidr0_cidrs

El objeto de red IP definido por RDAP utiliza una dirección de inicio y otra de fin. Esa representación admite intervalos que no encajan en un único bloque CIDR. Si los límites atraviesan fronteras de prefijo, se necesitan varias expresiones para cubrir exactamente las direcciones registradas sin añadir otras.

La extensión cidr0 ofrece esa conversión. Su campo es una lista porque puede contener uno o varios objetos, cada uno con un prefijo IPv4 o IPv6 y su longitud. Leída completa, la lista reproduce en notación CIDR el rango del objeto de registro. No enumera rutas aprendidas de un colector BGP.

En el ejemplo de AFRINIC, los límites se alinean de forma exacta. Las 256 direcciones desde 196.1.0.0 hasta 196.1.0.255 forman un solo /24. La lista tiene, por tanto, un único elemento. Esa sencillez resulta práctica para inventarios y controles, pero no amplía el tipo de evidencia disponible.

La propia respuesta anuncia la conformidad cidr0. Ese identificador permite a un cliente localizar la especificación correcta y procesar el campo sin adivinar. La conformidad indica cómo interpretar la estructura; no autoriza a incorporar propiedades ajenas como origen, visibilidad o tránsito.

La transformación válida es estrecha: de cidr0_cidrs puede obtenerse una lista de prefijos que representan el rango registrado. Transformarla automáticamente en una lista de prefijos anunciados sería introducir un dato que la fuente nunca observó.

Las pruebas que faltan para hablar de BGP

La captura no afirma que 196.1.0.0/24 estuviera presente en una tabla BGP. Tampoco identifica un AS de origen, un AS_PATH, el número de pares que vieron la ruta, una fecha de publicación o una retirada. No muestra si un agregado mayor cubría el intervalo ni si había rutas más específicas dentro de él.

No son detalles secundarios. Son componentes del hecho de enrutamiento que se quiere afirmar. RFC 4271 describe BGP como un protocolo entre sistemas autónomos para intercambiar información de alcanzabilidad. Sin una observación de los destinos y atributos comunicados, el registro de direcciones no sustituye la prueba de la ruta.

Una publicación confirmada tampoco demostraría todo lo demás. Podría probar que un observador recibió una ruta con ciertos atributos en un instante. No probaría por sí sola la entrega de paquetes, el volumen de tráfico, la calidad de servicio, un contrato de tránsito, el acceso a los routers o el control corporativo. Cada nivel requiere su propia fuente.

La dimensión temporal también limita la inferencia. Los datos de registro y los de enrutamiento pueden cambiar en momentos distintos. Una ficha puede actualizarse mientras la ruta permanece estable, o una ruta puede cambiar sin que el registro se modifique. Una comparación responsable conserva la fecha de ambas capturas y no convierte la proximidad en causalidad.

Las afirmaciones negativas requieren todavía más cautela. Que un colector no vea una ruta no significa que ningún punto de Internet la vea. La visibilidad depende del observador, del periodo y del método. La conclusión correcta siempre debe nombrar la fuente y el intervalo de observación.

Reconciliar sin borrar la procedencia

Un modelo de datos sólido separa tres capas. La primera conserva el hecho RDAP: URL, hora, identificador, límites, conformidad y lista CIDR. La segunda registra su interpretación limitada: esos prefijos expresan el intervalo de la ficha. La tercera incorpora, si existe, la evidencia de enrutamiento con sus propios atributos y procedencia.

Esta separación evita que una comodidad técnica se convierta en una afirmación editorial. Un campo llamado prefijosRegistrados puede alimentarse con cidr0_cidrs. Un campo llamado rutasObservadas no. El origen debe quedar nulo hasta que una fuente BGP lo proporcione, y la alcanzabilidad exige una evidencia adecuada a la entrega de tráfico.

Mantener los datos separados también permite analizar desacuerdos. Un rango puede aparecer bajo un agregado, incluir un anuncio más específico o mostrar caminos diferentes según el colector. Un origen puede variar con el tiempo. Estos resultados no anulan el registro; describen otra propiedad del recurso y otro momento.

La regla de redacción es equivalente. «AFRINIC representa este rango como 196.1.0.0/24» está respaldado por la captura. «El prefijo está anunciado» necesita una observación BGP citada. «La organización controla la red» necesita pruebas adicionales de autoridad y operación. La precisión está en la cláusula que conserva el origen del dato.

Fuentes y límite de la observación

Este artículo utiliza una captura acotada de los campos superiores del RDAP de AFRINIC realizada a 2026-08-28T06:35:54Z. El expediente no contiene una consulta BGP y no sostiene ninguna afirmación sobre publicación actual, origen, camino, alcanzabilidad o tráfico del prefijo.

La interpretación del campo procede de la documentación de AFRINIC, el registro de extensiones RDAP de IANA, la especificación cidr0 del NRO y los estándares de IETF para RDAP y BGP. Esas fuentes fijan tanto la utilidad del dato como su frontera.