Résumé

  • ARIN désigne Ailuj Inc. comme titulaire enregistré de l’AS11246 et lui rattache les allocations directes 64.93.76.0/22 et 2602:fa0f::/36. Le registre établit une responsabilité publique, pas une mesure de performance.
  • RIPEstat a observé le préfixe couvrant 64.93.76.0/22 et les deux routes plus spécifiques 64.93.78.0/24 et 64.93.79.0/24. Ces deux /24 sont inclus dans le /22 et ne constituent donc pas une capacité d’adressage supplémentaire.
  • L’instantané de statut de routage indiquait une visibilité IPv4 auprès de 329 pairs RIS sur 330 et aucune annonce IPv6 observée pour l’AS11246. Cette visibilité ne vaut ni disponibilité de bout en bout, ni débit, ni latence.
  • Un seul voisin, l’AS20473, apparaissait dans la vue bornée. Cette observation ne révèle ni contrat, ni exclusivité, ni topologie privée, ni niveau de redondance.
  • Les trois annonces IPv4 observées étaient valides au regard de RPKI pour l’origine AS11246, sous une autorisation couvrante acceptant une longueur maximale de /24. Cette preuve concerne l’autorisation d’origine, pas l’ensemble de la sécurité du routage.
  • Ailuj décrit publiquement des services de conception, déploiement, supervision, sécurité, réseau cloud, VPN, reprise et continuité. Il s’agit de capacités déclarées par l’entreprise, non de résultats de production indépendamment mesurés.

Le registre fournit une carte de responsabilité, pas le réseau en fonctionnement

Le dossier RDAP d’ARIN établit un lien vérifiable entre Ailuj Inc., l’AS11246 et des ressources numériques précises. Pour un opérateur, un partenaire ou une équipe chargée d’un incident, cette chaîne d’identification est utile: elle donne un point de départ pour contrôler le titulaire, les objets associés et les contacts publiés.

La portée de cette preuve doit rester exacte. ARIN tient le registre; il ne configure pas les équipements d’Ailuj, n’approuve pas chaque modification BGP et ne garantit pas qu’un contact pourra exécuter une intervention urgente. Le registre est une couche de tenue de comptes. Le routage réel dépend des configurations, des sessions, des politiques et des personnes qui les exploitent.

Une entreprise sérieuse relie ces deux couches par une cartographie d’autorité interne: responsable métier, responsable technique, intention de routage approuvée, accès au registre, gestion des ROA, canaux d’escalade et procédures de relève. Les sources publiques ne montrent pas si Ailuj dispose d’une telle cartographie complète. Elles montrent en revanche une surface suffisamment précise pour poser ces questions.

Cette gouvernance a un coût continu. Les rôles changent, les accès expirent, les fournisseurs évoluent et les coordonnées vieillissent. La continuité ne consiste pas à inscrire plusieurs noms dans un registre; elle exige que les remplaçants puissent s’authentifier, retrouver l’intention approuvée, mesurer l’impact d’une modification et conserver la trace de la décision.

Allocation et annonces: deux inventaires qui ne doivent pas être confondus

ARIN enregistre un bloc IPv4 /22 et un bloc IPv6 /36 directement attribués à Ailuj. Ces allocations ne disent pas comment les adresses sont segmentées, réservées, affectées ou annoncées. RIPEstat répond à une autre question: quelles routes les collecteurs publics ont-ils observées à un moment donné ?

Dans cette vue, l’AS11246 annonçait trois routes IPv4. Le /22 couvre 1 024 adresses, tandis que les deux /24 décrivent des portions de ce même espace. Additionner les trois annonces produirait un double comptage. Le nombre de routes exprime une politique de propagation; il ne mesure pas la capacité unique.

L’absence d’annonce IPv6 observée ne prouve pas que l’allocation IPv6 est inutilisée. La ressource peut être réservée, en préparation, visible dans un autre contexte ou annoncée selon un arrangement que la vue choisie ne montre pas. La seule conclusion défendable est que l’instantané interrogé n’a pas observé d’annonce IPv6 provenant de l’AS11246.

Le contrôle opérationnel exige donc trois inventaires réconciliés: ce qui est enregistré, ce qui devrait être annoncé et ce qui est effectivement observé. Un écart n’est pas automatiquement un incident, mais il doit avoir un propriétaire, une explication datée et un critère de réexamen.

Les routes plus spécifiques ajoutent de la souplesse et des obligations

En BGP, une route plus spécifique est normalement préférée à une route couvrante. Les deux /24 observés peuvent servir à séparer une politique, conduire du trafic différemment, accompagner une transition ou limiter l’effet d’une opération. Les données publiques ne permettent pas de choisir entre ces scénarios pour Ailuj.

Chaque intention supplémentaire doit toutefois être documentée et surveillée. L’opérateur doit savoir pourquoi la route existe, où elle doit se propager, quelle origine est autorisée, quel service en dépend et dans quelles conditions elle doit être retirée. Une configuration syntaxiquement correcte peut encore représenter une intention erronée.

Les modes de défaillance sont concrets: un /24 obsolète peut attirer du trafic vers une destination déplacée; une route peut rester visible alors que l’application est indisponible; le /22 peut disparaître tandis qu’une partie de l’espace reste joignable; une annonce plus spécifique non autorisée peut prendre le pas sur la couverture prévue. Rien dans les sources ne dit que ces incidents ont touché Ailuj. Ils découlent de la structure de routage observée et expliquent les contrôles nécessaires.

La visibilité des collecteurs ne constitue pas un indicateur de disponibilité

Le chiffre 329 sur 330 montre une large propagation vers les pairs RIS inclus dans l’instantané. Il ne faut pas le transformer en « 99,7 % de disponibilité ». Un collecteur BGP observe une route; il ne vérifie pas l’accès au serveur, la résolution DNS, l’authentification, la réponse applicative ni l’achèvement d’une tâche utilisateur.

Une supervision crédible combine plusieurs plans. Le plan de contrôle suit annonces, retraits, origine, longueurs et changements de chemin. Le plan de données mesure accessibilité, perte et latence depuis des points pertinents. La couche service contrôle DNS, transport, identité et application. Enfin, la couche métier vérifie que l’action attendue par le client aboutit.

Ces signaux peuvent diverger. Une route visible peut mener à un service en panne; un test local peut réussir alors qu’une région externe est affectée. Le coût n’est donc pas seulement celui des sondes, mais celui de la corrélation, de l’horodatage, des seuils, des propriétaires et de l’escalade.

Un voisin observé n’est pas un schéma d’architecture

La vue des voisins mentionne l’AS20473. Cette donnée permet d’affirmer qu’une adjacence était visible dans l’observation. Elle ne permet pas d’affirmer qu’il s’agit de l’unique fournisseur, d’un contrat principal, d’un lien de secours ou d’une dépendance exclusive.

Les relations privées, les tunnels, certains pairs et des sessions conditionnelles peuvent ne pas apparaître. Même lorsqu’une relation est visible, le chemin public ne révèle pas les obligations contractuelles ni l’indépendance réelle des domaines de défaillance.

Pour l’exploitation, une adjacence externe implique néanmoins un travail d’intégration: politiques échangées, filtres, authentification éventuelle, contacts, maintenance et procédure d’incident. Une redondance documentée n’a de valeur que si l’alternative est accessible, testée et capable de supporter le service requis.

RPKI réduit une classe de risque sans garantir la fiabilité

Les trois requêtes de validation RPKI renvoyaient un état valide pour l’origine AS11246. La route couvrante et les deux /24 entraient dans la longueur maximale autorisée. C’est une preuve positive: un opérateur appliquant la validation d’origine peut accepter ces annonces au regard du ROA concerné.

RPKI ne vérifie pas la totalité du chemin AS, la capacité, la disponibilité d’une application ou la correction d’une politique de trafic. Une annonce peut être RPKI valide tout en étant indésirable sur le plan opérationnel. Inversement, une erreur de ROA peut rendre invalide une route légitime.

La maintenance des ROA exige donc un inventaire d’intentions, une gestion stricte des accès, des changements coordonnés et une surveillance externe. Le /24 comme longueur maximale donne de la flexibilité, mais cette flexibilité agrandit l’ensemble des annonces techniquement autorisées. La politique interne doit être plus précise que la seule enveloppe cryptographique.

Distinguer capacité, fiabilité et résultat client

Le site d’Ailuj décrit des capacités de conception, d’installation, de supervision, de sécurité, de réseau cloud, de VPN et de continuité. Cette source établit ce que l’entreprise propose. Elle ne prouve pas qu’un déploiement précis a atteint un objectif de disponibilité, qu’un exercice de reprise a réussi ou qu’un client a accepté un résultat.

La fiabilité d’un produit ou d’un service demande d’autres preuves: procédure reproductible, critères d’acceptation, observations sur la durée, gestion des écarts et responsabilité claire. Le résultat de production d’un client demande en plus un périmètre convenu, un test représentatif et une validation par la partie responsable.

Cette séparation protège l’analyse contre deux excès: nier les capacités visibles parce que les résultats privés ne sont pas publics, ou convertir une description commerciale en garantie. Les sources permettent de reconnaître une surface réseau réelle tout en conservant les limites de preuve.

Quatre familles de coûts dominent la surface de contrôle

La supervision couvre l’état des routes, la visibilité, RPKI, l’accessibilité des services et la qualité des alertes. L’intégration relie le registre, les équipements, les fournisseurs, la sécurité, le DNS et les applications. La maintenance conserve les contacts, accès, configurations, ROA, inventaires et procédures dans un état exécutable. Le traitement des exceptions organise l’autorité, le diagnostic, le retour arrière et la communication lorsque les signaux se contredisent.

Ces coûts ne disparaissent pas avec un petit nombre de préfixes. Un inventaire compact peut être plus facile à comprendre, mais il concentre aussi l’impact d’une erreur. La qualité dépend de la discipline avec laquelle l’intention est reliée à l’état observé et aux résultats de service.

Conclusion

Les sources publiques établissent qu’Ailuj Inc. possède une identité réseau enregistrée, des ressources directes et une surface IPv4 observable. Elles montrent une propagation large dans la vue interrogée et une autorisation RPKI valide pour les trois annonces examinées.

Elles ne révèlent ni l’architecture privée, ni les contrats, ni la capacité, ni les clients, ni les incidents, ni les résultats de service. La conclusion responsable est donc opérationnelle: la surface d’AS11246 peut être suivie, réconciliée et gouvernée, mais la fiabilité et les résultats clients exigent des preuves supplémentaires.

Sources

  1. Site public d’Ailuj Inc.
  2. Enregistrement RDAP ARIN de l’AS11246
  3. Enregistrement RDAP ARIN de l’entité AILUJ
  4. Allocation IPv4 ARIN 64.93.76.0
  5. Vue générale RIPEstat de l’AS11246
  6. Préfixes annoncés observés par RIPEstat
  7. Statut de routage RIPEstat
  8. Voisins observés par RIPEstat
  9. État BGP observé par RIPEstat
  10. Validation RPKI de 64.93.76.0/22
  11. Validation RPKI de 64.93.78.0/24
  12. Validation RPKI de 64.93.79.0/24