Resumen

  • ARIN indica que /rest/net/NETHANDLE/routes devuelve objetos de ruta del NET directo y no proporciona subredes.
  • reassignments=true amplía la consulta a los NET reasignados aguas abajo; ninguno de los dos resultados es una observación BGP en vivo ni una decisión de RPKI.

El límite que no aparece en una celda vacía

El error comienza con una respuesta limpia. Un operador consulta el handle de un NET y recibe una colección sin entradas. El panel traduce esa ausencia en un estado rojo: no hay ruta, no hay origen, quizá no hay red.

La petición, sin embargo, no ha recorrido todo el árbol de direcciones. La guía REST de ARIN define /rest/net/NETHANDLE/routes como la lista de objetos identificados por prefijo y origen para el NET directo. La misma guía advierte que no incluye subredes. El resultado describe un registro concreto, no todos los registros situados dentro de su rango.

Esto importa porque una asignación directa puede contener reasignaciones a clientes. Cada registro descendente conserva su propio handle y puede estar vinculado a objetos IRR distintos. La consulta al padre puede estar vacía y ser correcta al mismo tiempo que existe información en la rama que no se pidió.

Una opción que cambia el universo consultado

ARIN ofrece /rest/net/NETHANDLE/routes?reassignments=true para incluir el NET y sus reasignaciones descendentes. El parámetro no certifica mejor los objetos. Cambia la población registral que puede aparecer.

Las dos colecciones aplican otra condición: la ruta debe ser visible y estar autorizada dentro del sistema IRR. Ese alcance es esencial. Visible en el registro no equivale a visible en todo BGP, alcanzable desde cualquier red o presente en un colector determinado. Autorizada en el IRR tampoco equivale a propiedad legal, control operativo ni validación criptográfica de origen.

El contenido de la respuesta es sobrio: tipo de entrada, handle de organización, AS de origen y prefijo. No contiene una ruta de AS, un colector, una hora de observación, datos de tráfico, cobertura de propagación ni estado RPKI. Esos datos pertenecen a otras capas de prueba.

Registro, autorización y observación

RDAP modela el árbol administrativo mediante handles separados y un posible parentHandle. Una asignación directa y una reasignación son objetos de registro distintos aunque una esté contenida en el espacio de la otra. Las dos variantes de la API siguen esa estructura.

RPSL responde a otra necesidad. Según la RFC 2622, la clave de un objeto route es la pareja formada por el prefijo y el AS de origen. Esa declaración puede servir para construir filtros, pero no configura un router ni demuestra que el anuncio esté activo.

Una ROA añade una autorización firmada. ARIN y la RFC 9582 la describen como un objeto criptográfico que permite comprobar que un AS está autorizado a originar ciertos prefijos. Aun así, una ROA válida no demuestra que el prefijo se anuncie ahora. Del mismo modo, un objeto IRR no se convierte en una ROA por aparecer junto a los mismos números.

Cómo conservar una conclusión defendible

El análisis debe guardar el handle exacto, el endpoint, los parámetros y la hora. La colección directa responde por el NET directo. La colección con reasignaciones amplía la jerarquía registral. Whois o RDAP muestran la relación padre-hijo. RPKI responde por la autorización criptográfica. Los colectores con fecha responden por la visibilidad observada desde puntos concretos.

Ante una lista directa vacía, la siguiente pregunta es si la rama descendente formaba parte de la consulta. Ante una lista ampliada con objetos, la pregunta pasa a ser qué registro y qué pareja prefijo-origen fueron admitidos, y qué evidencia independiente confirma su uso actual. La disciplina consiste en no permitir que el borde de la petición desaparezca de la conclusión.

Fuentes