Résumé

  • La RFC 9910 réserve rdap-down aux enfants immédiats et définit rdap-bottom comme l’ensemble des objets les plus spécifiques qui couvrent ensemble la plage demandée.
  • Dans la capture ARIN du /21, un /22 actif et un /8 administratif apparaissent ensemble ; le /8 couvre le reliquat, il n’est pas présenté comme l’enfant du /21.

Une hiérarchie apparemment renversée

La réponse semble d’abord impossible. Pour 149.112.152.0/21, le service RDAP d’ARIN renvoie l’objet NET-149-112-152-0-1, allocation directe active décrite en /22, ainsi que NET-149-0-0-0-0, objet administratif décrit en /8.

Un /8 n’est évidemment pas plus spécifique qu’un /21. Mais l’interface ne dit pas qu’il l’est. L’erreur vient de la traduction spontanée de « bottom » par « toutes les feuilles sous ce nœud ». Dans la RFC 9910, la relation répond à une autre question : quels sont les objets enregistrés les plus spécifiques qui, pris ensemble, rendent compte de toute la valeur INR fournie ?

Le /22 ne couvre que la moitié du /21. Pour les adresses restantes, l’objet enregistré le plus spécifique disponible dans cette réponse est le /8. Le résultat accepte donc le chevauchement. Il ne découpe pas la plage en descendants disjoints ; il expose les objets du registre qui assurent la couverture complète de la demande.

Descendre n’est pas couvrir par le bas

La requête jumelle clarifie la mécanique. Pour le même /21, rdap-down ne renvoie que l’allocation directe en /22. Cette relation cherche les enfants immédiats : les prochains objets enregistrés sous la plage demandée. L’objet en /8 n’entre pas dans cette définition.

rdap-bottom, en revanche, calcule une couverture. Si les objets plus spécifiques ne couvrent pas toute la demande, un objet englobant peut rester dans l’ensemble afin de représenter le reliquat. La RFC précise que les objets « bottom » ne sont pas nécessairement disjoints et qu’un objet moins spécifique que la requête peut apparaître. La documentation ARIN décrit la même règle : lorsque les objets trouvés ne couvrent pas entièrement la valeur, l’objet réseau le plus spécifique est également renvoyé.

Cette fonction évite au client de reconstruire récursivement toute la hiérarchie. Mais elle rend dangereuse toute présentation qui renomme chaque résultat « sous-allocation ». Une simple liste plate supprimerait la raison pour laquelle l’objet englobant a été inclus et fabriquerait une relation qui n’existe pas.

Les limites matérielles de la réponse

Les éléments sont des objets ip network. Ils portent des identifiants, des adresses de début et de fin, une représentation CIDR, un type propre au modèle ARIN et un statut. Dans la capture, le /22 est une DIRECT ALLOCATION active ; le /8 a un statut administratif.

Ce sont des propriétés de registre. Elles n’établissent ni annonce BGP, ni accessibilité, ni trafic, ni autorisation RPKI. Les tableaux optionnels d’AS d’origine d’ARIN étaient vides dans les deux objets. Ce vide ne prouve pas qu’aucune route n’existe ; il décrit seulement un champ de cette réponse à cet instant.

La RFC 9083 définit l’objet réseau IP comme une information d’enregistrement. La RFC 9082 indique qu’une recherche IP ordinaire vise le réseau enregistré le plus spécifique qui englobe complètement la valeur demandée. Aucune des deux ne transforme la géométrie administrative en état opérationnel.

Conserver la relation avec la donnée

Une preuve exploitable doit garder la relation demandée, la plage d’entrée, l’heure, l’identifiant, les bornes, le CIDR, le type et le statut de chaque objet. Le /8 cesse alors d’être une anomalie : il constitue la couverture enregistrée du reliquat que le /22 ne couvre pas.

Cette preuve doit rester distincte des collecteurs BGP, des objets de route IRR, de la validation RPKI et de l’inventaire interne. La recherche « bottom » décrit la couverture du registre. Elle ne révèle ni l’opérateur d’un routeur, ni l’accès au compte, ni le titre juridique, ni la visibilité effective d’une route.

La distinction paraît minuscule, mais son abandon est durable. Une réponse exacte devient un faux arbre de délégation dès que le nom de la relation disparaît. L’étiquette correcte est littérale : couverture par les objets enregistrés les plus bas disponibles pour la plage demandée.

Sources