Résumé

  • RFC 9877 introduit l'identifiant geofeed1, la relation de lien geofeed et le type application/geofeed+csv pour relier un objet réseau RDAP à un fichier publié en HTTPS.
  • La présence de ce lien atteste un chemin de découverte dans une réponse donnée ; elle n'atteste ni l'actualité de chaque ligne, ni la présence physique d'un équipement, ni la localisation d'une personne.
  • L'exploitation sérieuse conserve la portée de l'objet, écarte les préfixes hors périmètre, vérifie l'autorité du déclarant et la fraîcheur, puis soumet l'usage à une politique distincte.

Une requête RDAP vise une adresse précise. La réponse livre l'objet réseau le plus spécifique, sans lien geofeed. Le client remonte vers l'objet parent et y découvre enfin une URL. Ce simple parcours suffit à montrer pourquoi « absent », « présent » et « vrai » ne sont pas synonymes.

Publié sur la voie Standards Track de l'IETF en octobre 2025, RFC 9877 organise la découverte. Un serveur peut placer dans le membre links d'un objet IP une URL HTTPS dont la relation vaut geofeed et dont le type recommandé est application/geofeed+csv. Pour les logiciels consommateurs, cette syntaxe commune supprime une part d'ambiguïté.

Le texte prend néanmoins soin de laisser hors de son périmètre le téléchargement et l'utilisation du fichier. La frontière est décisive. Un annuaire rend un pointeur intelligible ; il ne transforme pas une déclaration de géographie opérationnelle en constat physique.

Ce que signifie réellement geofeed1

Un serveur qui annonce geofeed1 dans rdapConformance s'engage à le faire dans ses réponses de recherche ou de consultation contenant des objets réseau, ainsi que dans sa réponse d'aide. S'il détient une URL geofeed pour l'objet demandé et peut la communiquer, il doit fournir le lien correspondant. Des obligations réglementaires peuvent toutefois l'en empêcher.

L'absence devient donc une information conditionnelle : pour cet objet, auprès de ce serveur et dans ces circonstances, aucune donnée geofeed n'est disponible par cette voie. Elle ne démontre pas que le détenteur n'a rien publié ailleurs, qu'un parent n'a pas de lien, ni que le préfixe est sans réalité géographique.

L'inverse mérite la même prudence. Un serveur est autorisé à employer la relation et le type enregistrés sans annoncer l'extension geofeed1. Le client doit lire la déclaration de conformité et les liens effectifs. Résumer la réponse à un seul booléen ferait disparaître une nuance prévue par le protocole.

Le recours à HTTPS protège le transport et authentifie le service web selon la WebPKI. Il ne prouve pas automatiquement que l'opérateur de ce service est habilité à parler pour chaque espace d'adresses cité dans le CSV. L'adresse de récupération et l'autorité sur la ressource sont deux preuves différentes.

Remonter vers le parent élargit le périmètre

Selon RFC 9082, la consultation d'une adresse renvoie l'objet réseau le plus spécifique qui la couvre. RFC 9877 prévoit le cas où cet objet ne comporte pas de geofeed alors qu'un parent moins spécifique en possède un. Une remontée récursive est possible, mais elle agrandit le champ dans lequel le lien a été obtenu.

Le consommateur doit alors ignorer toute ligne du fichier située hors de l'intervalle couvert par l'objet référent. Un unique fichier peut servir plusieurs ressources ; il n'acquiert pas pour autant le droit de décrire tout ce qu'il contient dans le contexte de la requête. La plage RDAP est une limite de compétence, pas une décoration technique.

RFC 8805 recommande de vérifier que l'éditeur est bien compétent pour les ressources concernées. Le mécanisme d'amorçage de RFC 9224 aide à atteindre le service RDAP capable de déclarations faisant autorité sur la disposition des ressources. Cela consolide l'origine du pointeur. Cela ne garantit ni l'exactitude d'une ville, ni la position d'un trafic anycast, ni le domicile d'un utilisateur.

Une geofeed est une déclaration du détenteur sur la géographie de ses préfixes. Elle peut être volontairement grossière, changer après le déplacement d'une infrastructure ou rester en cache après sa mise à jour. La bonne formulation est donc « géographie opérationnelle déclarée, à telle date et pour telle plage », jamais « personne localisée ».

Signature, fraîcheur et vie privée restent autonomes

RFC 9632, qui remplace RFC 9092, décrit une authentification RPKI facultative. Une signature valable renforce l'attribution du fichier à un certificat couvrant l'espace d'adresses. Elle n'approuve pas la sémantique de chaque localisation et ne décide pas de l'usage commercial, sécuritaire ou réglementaire qui en sera fait.

Une chaîne auditable distingue donc : lien découvert, fichier récupéré, transport vérifié, plage référente mémorisée, lignes filtrées, autorité contrôlée, signature évaluée, âge mesuré, base de traitement validée et décision locale enregistrée. Un champ unique du type « localisation confirmée » efface précisément les informations nécessaires à une correction.

La fraîcheur impose également de la retenue. RFC 9877 interdit les consultations fréquentes en temps réel qui chargeraient indûment les serveurs. RFC 9632 recommande de suivre les indications HTTP et, à défaut, de ne pas récupérer plus souvent qu'une fois par semaine. Une API interrogée maintenant ne rend pas instantanée une source mise à jour hebdomadairement.

Enfin, le texte reprend les garanties de vie privée de RFC 9632 : le fournisseur ne doit pas exposer la localisation d'un individu. Les opérateurs de registre doivent vérifier si leur cadre juridique autorise la fonctionnalité. La commodité d'un lien ne remplace ni la proportionnalité, ni la finalité, ni le droit applicable.