Dans le geofeed de LACNIC, deux codes pays pour un même préfixe

Résumé

• Deux téléchargements réussis le 3 septembre livrent des fichiers identiques : 13 569 lignes et 13 546 préfixes distincts. Vingt-trois préfixes apparaissent chacun deux fois.
• Neuf paires sont des copies exactes. Quatorze diffèrent dans leurs champs de localisation ; quatre de ces paires portent des codes pays différents.
• RFC 8805 distingue les préfixes répétés des réseaux emboîtés, qui sont permis. Choisir le préfixe le plus long ne départage pas deux /24 identiques.
• Le constat porte sur le fichier, non sur une localisation physique vérifiée. Ni l’origine des déclarations concurrentes ni leurs effets chez un fournisseur ou un utilisateur n’ont été établis.

Dans le geofeed public de LACNIC, le préfixe 170.51.97.0/24 a deux réponses à la question du pays. La ligne 2 631 le décrit avec UY, UY-MO et Montevideo. La ligne 12 633 reprend exactement le même préfixe avec PY, PY-ASU et Asuncion. L’Uruguay et le Paraguay sont ainsi associés à la même clé.

Entre ces deux lignes, aucun changement de longueur ne permet de distinguer une zone générale d’une zone plus précise. Aucun horodatage propre à la ligne ne démontre non plus que la seconde corrige la première. La succession dans le fichier est observable ; la succession des mises à jour ne l’est pas.

Cette différence suffit à faire apparaître un problème de responsabilité. Un programme qui conserve la première occurrence peut retenir l’Uruguay. Un autre, qui remplace une valeur à chaque nouvelle occurrence de la clé, peut retenir le Paraguay. Il s’agit de deux politiques de lecture imaginables, pas d’une description des logiciels de LACNIC ou d’un fournisseur identifié. Leur résultat pourrait pourtant être présenté, dans les deux cas, comme « la donnée de LACNIC ».

Le programme aurait choisi. Personne n’aurait, pour autant, apporté une preuve géographique supplémentaire.

Compter sans transformer le décompte en verdict

La première requête réussie a commencé le 3 septembre à 10:31:23 UTC. Une seconde a commencé à 10:45:12 et s’est achevée à 10:45:48. Les deux fichiers de 438 145 octets sont identiques octet par octet. Deux tentatives intermédiaires ont expiré ; elles ne fondent ici aucune conclusion sur la disponibilité générale du service. Les captures n’indiquent pas depuis quand les répétitions existent, ni ce qui s’est produit en dehors de ces deux observations.

Leur contenu permet en revanche de décrire précisément le phénomène. Le fichier compte 13 569 lignes de données non vides et hors commentaires : 10 782 en IPv4 et 2 787 en IPv6. L’analyse des adresses et des longueurs de préfixe, avec normalisation des écritures IPv6, donne 13 546 réseaux distincts. Les 23 paires mobilisent 46 lignes, soit 23 lignes supplémentaires par rapport à une seule entrée par préfixe. Un regroupement plus simple des chaînes de préfixe reproduit ce total.

Une première séparation est indispensable. Neuf paires sont entièrement identiques. Pour 200.123.12.0/24, par exemple, les mêmes informations sur Lima, au Pérou, apparaissent deux fois de suite. Ce sont deux copies dans une sortie, pas deux confirmations indépendantes de la ville.

Quatorze autres paires comportent des différences de localisation. Dix conservent le pays : quatre changent la région ou la ville, six seulement le niveau de détail. Le préfixe 200.63.248.0/21 porte ainsi Ibarra puis Quito, avec des codes de région différents, toujours en Équateur. Pour 200.80.255.0/24, une déclaration renseigne l’Argentine, la région et Buenos Aires ; l’autre ne donne que le pays.

Les quatre paires restantes contredisent le code pays. Outre le cas Uruguay–Paraguay, 181.238.0.0/24, 181.239.32.0/24 et 186.182.0.0/24 combinent chacun PY et AR, le Paraguay et l’Argentine.

Ces catégories ne sont pas interchangeables. L’absence d’une ville n’est pas en soi une erreur. Une ville renseignée ne rend pas une déclaration plus récente. Deux villes différentes appellent une explication différente de celle d’une copie exacte. Enfin, deux codes pays ne démontrent pas lequel est faux.

Le dénominateur reste celui des lignes et des préfixes. Il ne désigne ni des abonnés, ni des organisations, ni des systèmes autonomes, ni des trajets réseau mesurés. Le résultat délimite une liste finie de cas à examiner. Il ne mesure pas la justesse géographique de l’ensemble du fichier.

Une règle de correspondance ne tranche pas tous les conflits

La distinction technique figure dans RFC 8805. Sa section 2.1.3 traite les répétitions d’une même adresse ou d’un même préfixe comme des erreurs à relever pour examen administratif. Elle autorise, séparément, les préfixes emboîtés et recommande de retenir la correspondance la plus spécifique. Les champs de localisation sont facultatifs.

Le fichier fournit un exemple de cet emboîtement permis : 177.126.48.0/22 et 177.126.48.0/24 y coexistent. Le /24 décrit une partie du /22. Pour une adresse située dans cette partie, la longueur du préfixe distingue la déclaration la plus précise. Deux occurrences de 170.51.97.0/24 ont au contraire la même portée. La règle de longueur ne crée aucune priorité entre elles.

Il serait donc contre-productif de baptiser « doublon » tout chevauchement de plages. Cela éliminerait des subdivisions que le format sait exprimer. Il serait également excessif d’exiger davantage de détail géographique de tous les contributeurs. Le problème observé ne justifie ni une ville obligatoire ni une collecte plus fine.

L’opération inverse, consistant à charger les données dans une structure à clé unique, peut donner l’illusion d’une solution. Il ne reste alors qu’une valeur par préfixe. Mais si le lecteur ne conserve pas la trace de son arbitrage, la contradiction disparaît sans avoir reçu d’explication. Une contrainte informatique a produit de l’ordre, pas nécessairement une donnée mieux étayée.

Le registre peut corriger la publication sans devenir géographe

La présentation du service Geofeeds explique que les administrateurs d’organisations membres renseignent volontairement pays, région et ville dans MiLACNIC. Ces déclarations sont rassemblées dans un fichier public. La présentation date de 2020 : sa consultation actuelle ne prouve pas un lancement récent.

LACNIC en expose la raison dans sa page consacrée à la géolocalisation. Les coordonnées de contact de Whois peuvent refléter le contrat d’une organisation, sans décrire le lieu d’utilisation des adresses. Le geofeed permet une déclaration propre à cet usage, notamment en subdivisant les blocs. LACNIC distingue aussi son rôle de celui des bases commerciales de géolocalisation.

C’est une défense solide du dispositif. Un outil de déclaration n’a pas besoin de vérifier physiquement chaque équipement pour rendre service. Il doit permettre aux opérateurs de fournir une information pertinente dans un format commun. Lui demander de certifier chaque localisation déplacerait radicalement sa responsabilité.

Il existe pourtant une tâche plus modeste : reconnaître qu’une même clé a été publiée deux fois et rendre visible le traitement du cas. Une copie identique peut n’être émise qu’une fois, tout en conservant l’apport d’origine. Des valeurs différentes peuvent être signalées comme concurrentes, avec un chemin de correction. Aucune de ces opérations n’exige de décréter où se trouve un réseau.

Les laisser entièrement au lecteur a aussi un coût. Chaque consommateur doit décider ce qu’il conserve, ce qu’il écarte et ce qu’il considère comme indéterminé. Le fichier demeure commun, mais sa signification peut diverger d’un programme à l’autre. La portabilité de la déclaration perd alors une partie de son intérêt.

Ce que l’enquête laisse ouvert

Les comptes des membres et les historiques confidentiels n’ont pas été consultés. Aucune mesure active de localisation, comparaison avec une base commerciale ou observation de trafic n’a été réalisée pour ces préfixes. Les captures ne disent pas qui a soumis les deux lignes, quand elles ont été modifiées, pourquoi elles coexistent ou quelle déclaration correspond à l’usage actuel.

Une explication légitime, y compris un déploiement réparti, reste possible. Elle ne rendrait pas automatiquement explicite la manière de lire deux lignes concurrentes de même portée. Pour attribuer une cause à la répétition, il faudrait des éléments absents du fichier examiné.

Les conséquences chez les consommateurs restent elles aussi inconnues. Un pays déclaré pourrait entrer dans une sélection de contenu ou une décision d’accès ; un choix implicite lors du chargement pourrait alors compter. Cela ne démontre ni qu’un fournisseur a ingéré ces cas ni qu’un utilisateur a été pénalisé.

La correction doit donc rester à la mesure du constat. Conserver les données utiles, distinguer la copie du désaccord, donner aux cas non résolus un état lisible et permettre leur révision : voilà une amélioration de publication. Affirmer qu’un fichier sans doublon est géographiquement exact serait un tout autre engagement, que ces observations ne permettent pas de prendre.