Résumé

  • La réponse d’AFRINIC pour 196.216.2.1 décrit la plage enregistrée 196.216.2.0–196.216.3.255 avec ipVersion: v4.
  • La RFC 9083 limite cette valeur à l’objet réseau renvoyé ; elle ne constitue pas un inventaire de toutes les plages d’adresses, routes ou services liés à l’organisation.

La réponse suit la requête

La réponse AFRINIC est un objet ip network contenant bornes, identifiant, nom, type, pays, parent, statut et événements. L’adresse interrogée étant en IPv4, la valeur ipVersion est v4.

C’est la fonction exacte définie par la RFC 9083 : v4 désigne un réseau IPv4 et v6 un réseau IPv6. Le champ aide le logiciel à interpréter l’objet. Il ne dit pas si le titulaire, une entité associée ou le registre possède d’autres dossiers dans l’autre famille d’adresses.

L’erreur consiste à élargir la portée. Une application interroge une adresse IPv4, lit v4, puis classe l’organisation comme « uniquement IPv4 ». Pourtant, la réponse n’a recherché ni allocations IPv6, ni routes IPv6, ni enregistrements AAAA, ni services accessibles en IPv6.

Une preuve IPv6 exige une observation IPv6

Pour l’enregistrement, il faut interroger les objets IPv6 et conserver l’heure et le périmètre. Pour le routage, il faut des préfixes IPv6 et des attributs de chemin issus de collecteurs identifiés. La RFC 4271 place ces preuves dans les destinations et attributs échangés par UPDATE, non dans ipVersion. Pour un service, il faut tester des hôtes précis depuis des points déclarés.

Ces résultats peuvent diverger : enregistrement sans route, route sans service public, ou service absent du dossier IPv4 initial. La conclusion défendable reste : au moment de la capture, AFRINIC a renvoyé cet objet borné comme IPv4.

Sources