Résumé

  • L’objet aut-num RIPE décrit l’AS210417 avec l’as-name Datatokni et un statut de registre ASSIGNED ; ces champs attestent une situation administrative, pas une activité BGP en temps réel.
  • Les références FT-NET et FT-NET-MNT sont des métadonnées de contact ou de maintenance. Elles ne prouvent pas, à elles seules, la propriété juridique, l’exploitation actuelle ou la dépendance opérationnelle de Føroya Tele.

Le registre et le réseau mesurent deux réalités différentes

La difficulté centrale du dossier Datatokni ForoyaTele tient à une confusion fréquente dans l’analyse des infrastructures Internet : un objet de registre peut être actif, attribué ou correctement maintenu alors que la visibilité de ses routes varie — voire disparaît — dans les systèmes de mesure du routage. À l’inverse, une observation BGP ponctuelle ne tranche pas nécessairement la question de la propriété juridique ou du contrôle organisationnel.

Pour l’AS210417, la source la plus directe est l’objet aut-num de la base RIPE. Il publie l’as-name « Datatokni », un statut de registre et des références vers une organisation, des contacts et des mainteneurs. L’objet aut-num RIPE doit donc être lu comme un enregistrement structuré de ressources et de responsabilités déclarées, non comme un organigramme d’exploitation.

Le RDAP de l’ASN fournit une seconde vue de cette identité de registre. Il confirme que le numéro 210417 possède un objet public dans l’espace RIPE et distingue les liens vers les entités enregistrées. Le dossier RDAP de l’AS210417 est particulièrement utile pour séparer le nom de l’objet, son statut et les rôles des entités référencées. Cette séparation est essentielle : le nom affiché dans un champ d’objet n’a pas nécessairement la même fonction que l’organisation enregistrée ou que le contact technique.

FT-NET : un lien administratif, pas une preuve d’exploitation

Le dossier public FT-NET associe ce rôle de contact à des informations de réseau liées à Føroya Tele ou Faroese Telecom. L’objet de rôle FT-NET indique la nature de l’objet : il s’agit d’un rôle de contact dans la base RIPE, et non d’un objet aut-num ou d’une inscription démontrant à elle seule la propriété d’un réseau.

Cette distinction paraît technique, mais elle modifie la portée de toute conclusion. Une référence admin-c, tech-c ou mnt-by peut indiquer où adresser une demande, qui maintient un objet ou quel contact est publié. Elle ne démontre pas automatiquement que l’entité mentionnée possède l’ASN, qu’elle en contrôle les routeurs ou qu’elle dépend de celui-ci pour assurer un service donné.

Le dossier précédent consacré à Datatokni ForoyaTele insistait sur la valeur des contacts de registre comme signal de changement administratif. La question examinée ici est différente : que peut-on réellement déduire de la structure de l’AS210417 lorsqu’on confronte le registre à la visibilité du routage ? La réponse est volontairement limitée. Les références de registre établissent un périmètre administratif documenté ; elles ne ferment pas l’enquête sur l’opérateur effectif.

Le statut ASSIGNED ne signifie pas « actuellement visible »

Le champ de statut de l’objet aut-num est ASSIGNED. La réponse REST de la base RIPE permet d’identifier ce statut et les autres attributs publiés de l’objet, notamment ses références organisationnelles, ses contacts et ses mainteneurs. Mais ASSIGNED décrit l’allocation ou l’enregistrement de la ressource dans le registre. Il ne constitue pas une mesure de l’annonce de préfixes.

Le RDAP emploie lui aussi des catégories de statut propres à l’objet. La réponse RDAP doit être interprétée dans ce cadre administratif. Un ASN attribué peut ne pas être observé dans une table de routage à un instant donné ; une telle absence ne contredirait pas nécessairement son existence dans la base RIPE.

Cette non-équivalence est importante pour les investisseurs, les opérateurs et les responsables de continuité. Une base de registre répond à la question « quelle ressource est déclarée, sous quel nom et avec quelles références ? ». Un collecteur BGP répond à une autre question : « que voit-il depuis sa position et dans sa fenêtre d’observation ? ». Mélanger les deux transforme une indication limitée en affirmation de contrôle.

Ce que les systèmes de routage pourraient établir

RIPEstat fournit plusieurs interfaces qui, lorsqu’elles sont capturées avec leur réponse et leur horodatage, peuvent compléter le registre. L’API AS Overview peut exposer un libellé dérivé du registre ainsi qu’un indicateur announced associé au moment de la requête. La vue AS Overview de RIPEstat peut donc soutenir une affirmation temporelle et précisément bornée — par exemple ce que le service considérait à l’heure de la capture — mais pas une conclusion permanente sur l’activité de l’ASN.

La Routing Status API vise la visibilité observée par les collecteurs RIPE RIS. La réponse Routing Status peut indiquer des éléments tels que la première ou la dernière observation lorsqu’ils sont disponibles. Elle ne couvre toutefois pas toutes les positions du réseau Internet. Les collecteurs diffèrent par leur emplacement, leurs pairs, leurs filtres et leurs délais de mise à jour.

L’interface des préfixes annoncés répond à une question encore plus étroite : quels préfixes RIPEstat associe-t-il à l’AS210417 dans la période et selon les paramètres de la réponse ? La liste des préfixes annoncés ne doit être utilisée pour compter des préfixes ou attribuer une origine qu’avec une capture conservant la réponse, les paramètres et le moment de la requête.

Dans le présent dossier, les valeurs mutables de routage ne sont pas suffisamment capturées pour soutenir une affirmation actuelle sur le nombre de préfixes, l’état announced, les voisins ou la continuité. Cette limite n’est pas un détail éditorial : elle empêche de transformer un service de consultation en preuve durable.

Pourquoi les vues tierces ne remplacent pas une capture datée

BGP.Tools et le BGP Toolkit de Hurricane Electric peuvent fournir des vues indépendantes de l’AS210417. La fiche BGP.Tools et la page du BGP Toolkit peuvent servir à comparer les préfixes, les pairs ou les relations amont visibles depuis leurs propres sources. Mais ces données peuvent diverger de RIPEstat en raison de la couverture, du cache et du calendrier de mise à jour.

Une relation amont affichée par un collecteur est une observation de routage, non une preuve d’actionnariat. De même, l’absence de préfixe sur une page publique ne permet pas de conclure à une cessation permanente, à une perte de contrôle ou à une dépendance d’un service local. Il faudrait une série d’observations datées, une définition claire de la question et, pour les affirmations d’exploitation, des éléments organisationnels ou techniques supplémentaires.

Les statistiques de délégation RIPE NCC ajoutent une autre couche de contrôle. Le fichier de statistiques de délégation peut aider à vérifier la présence de l’ASN dans les données de délégation, son statut, son code de pays et sa date d’allocation. Il ne décrit pas la visibilité BGP et n’identifie pas nécessairement l’opérateur actuel.

Une architecture de preuve en trois couches

Pour Datatokni ForoyaTele, la lecture la plus robuste repose sur trois couches distinctes.

La première est la couche d’identité : l’AS210417 possède un objet RIPE et l’as-name publié est Datatokni. Le RDAP, l’objet aut-num et le rôle FT-NET rendent cette structure observable. La deuxième est la couche de registre : le statut ASSIGNED et les références d’organisation, de contact et de maintenance montrent comment la ressource est documentée dans le système RIPE. La troisième est la couche opérationnelle : les réponses RIPEstat, les données BGP.Tools et le BGP Toolkit pourraient montrer ce que des collecteurs ont observé à des moments précis.

Ces couches se recouvrent sans se confondre. La première ne prouve pas la troisième. La deuxième n’établit pas automatiquement une relation de dépendance. La troisième, même lorsqu’elle est positive, n’établit pas toujours la propriété légale. Cette méthode réduit le risque de surinterpréter un nom, une adresse de contact ou un statut.

La question de la continuité

La continuité ne peut pas être déduite de la seule présence d’un ASN dans un registre. Pour évaluer un risque de continuité, il faudrait savoir quels services dépendent réellement de l’AS210417, quels préfixes sont effectivement annoncés, quels opérateurs ou transitaires peuvent reprendre la connectivité et quelle est la relation contractuelle entre la ressource, le réseau et les services concernés.

Les documents réunis ici ne démontrent pas ces dépendances. Ils permettent seulement de formuler une question opérationnelle : si Datatokni est utilisé comme ressource de routage, quelles preuves datées relieraient l’objet de registre à une annonce active et à un service identifié ? La réponse devrait combiner des observations BGP reproductibles avec des documents ou déclarations de l’opérateur. Un contact FT-NET, pris isolément, ne suffit pas.

Cette prudence est particulièrement importante dans les petits marchés, où un même groupe peut apparaître dans plusieurs fonctions administratives ou techniques. La concentration des contacts peut être un signal de gouvernance ou de capacité de support, mais elle n’est pas la même chose qu’une preuve de contrôle exclusif. Elle peut aussi refléter des conventions historiques de registre.

Conclusion : la valeur est dans la séparation des rôles

Le dossier AS210417 montre pourquoi l’intelligence des ressources Internet doit distinguer le registre du réseau. RIPE publie un objet aut-num sous le nom Datatokni, un statut ASSIGNED et des références administratives comprenant FT-NET. Ces éléments constituent une base vérifiable pour suivre l’identité et la gestion déclarée d’une ressource de numérotation.

Ils ne permettent pas, sans captures de routage datées et preuves organisationnelles complémentaires, d’affirmer que Føroya Tele possède ou exploite actuellement l’ASN, que celui-ci annonce des préfixes précis ou qu’un service donné en dépend. La conséquence pratique est simple : toute veille sérieuse doit conserver séparément les changements de registre, les observations BGP et les éléments de contrôle opérationnel.

Le signal est donc réel, mais borné. Datatokni est une identité publiée dans le registre ; l’activité et le contrôle sont des questions supplémentaires.

Sources