Resumen

  • RFC 9910 define rdap-down como búsqueda de hijos inmediatos y rdap-bottom como el conjunto de objetos más específicos que, juntos, cubren el rango solicitado.
  • En la captura de ARIN para un /21 aparecieron un /22 activo y un /8 administrativo; el /8 cubre el residuo y no se presenta como hijo del /21.

El cajón que parece estar al revés

La forma de la respuesta sorprende. Para 149.112.152.0/21, el servicio RDAP de ARIN entregó NET-149-112-152-0-1, una asignación directa activa descrita como /22, y NET-149-0-0-0-0, un objeto administrativo descrito como /8.

Un /8 no puede ser un descendiente más específico de un /21. El servicio tampoco afirma que lo sea. La contradicción nace de leer “bottom” como “todas las hojas bajo este nodo”. RFC 9910 plantea otra pregunta: ¿qué objetos registrados, en su versión más específica disponible, cubren en conjunto todo el valor INR que pidió el cliente?

El /22 ocupa solo la mitad del /21. Para las direcciones restantes, el objeto registrado más específico disponible en la respuesta es el /8. Por eso el conjunto se solapa. No es una partición limpia de descendientes, sino una explicación de cobertura con la geometría del registro.

Bajar y cubrir son operaciones distintas

La consulta paralela permite verlo. rdap-down sobre el mismo /21 devolvió únicamente la asignación /22. Esa relación busca hijos inmediatos: los siguientes objetos registrados por debajo del valor de entrada. El /8 no cumple ese criterio.

rdap-bottom calcula cobertura. Si los objetos más específicos cubren solo una parte, se conserva un objeto envolvente para dar cuenta del espacio residual. RFC 9910 advierte que los objetos bottom no tienen por qué ser disjuntos y que uno de ellos puede ser menos específico que la propia consulta. La documentación de ARIN aplica la misma regla: cuando los objetos encontrados no cubren por completo el valor, también devuelve el objeto de red más específico que cubre lo restante.

La función ahorra una reconstrucción recursiva del árbol. El peligro aparece después, en la interfaz. Si un tablero denomina “subasignación” a cada fila, convierte el objeto de cobertura en una relación de descendencia falsa. El prefijo no está equivocado; falta la semántica que explica su presencia.

Qué contiene realmente la respuesta

Los elementos son objetos ip network. Incluyen identificadores, direcciones inicial y final, representación CIDR, tipo específico del modelo de ARIN y estado. En la captura, el /22 figura como DIRECT ALLOCATION y active; el /8, como administrative.

Son campos registrales. No confirman un anuncio BGP, alcance, tráfico, una ROA válida ni control operativo. Los arreglos opcionales de ASN de origen estaban vacíos en ambos objetos. Ese vacío no demuestra ausencia de rutas: solo describe un campo de una respuesta tomada en un momento concreto.

RFC 9083 define el objeto de red IP como información de registro. RFC 9082 explica que una consulta IP ordinaria apunta a la red registrada más específica que contiene por completo el valor consultado. Ninguna especificación transforma el contorno administrativo en estado de la red.

La relación debe viajar con los prefijos

Un registro defendible conserva la relación solicitada, el rango de entrada, la hora de captura, el handle, las direcciones límite, el CIDR, el tipo y el estado. Con esos datos, el /8 deja de parecer una anomalía: es el registro que cubre el residuo fuera del /22.

La evidencia de enrutamiento debe mantenerse aparte. Los colectores BGP, los objetos IRR, la validación RPKI y el inventario interno responden preguntas distintas. rdap-bottom describe cobertura registral; no identifica quién configura un router, quién controla una cuenta, quién posee legalmente un recurso o qué ruta es visible ahora.

Eliminar el nombre de la relación convierte una respuesta correcta en un árbol inventado. La etiqueta más segura es también la más precisa: cobertura por los objetos registrados más bajos disponibles para el rango solicitado.

Fuentes