Résumé

  • Chittagong Multi Channel Limited peut être rattachée de manière prudente à l’objet de répertoire « Nizam Uddin Mazud T/A Chittagong Multi Channel Limited » grâce à une chaîne de traces publiques : répertoire BTW, membre APNIC, RDAP APNIC, PeeringDB et domaine cmclbd.com. Cette chaîne établit une identité réseau exploitable; elle n’établit pas l’actionnariat, le chiffre d’affaires, l’effectif, le nombre d’abonnés, les engagements de niveau de service ni la topologie privée.
  • Les enregistrements APNIC associent AS137029 et le bloc IPv4 portable 103.102.136.0/22 à CMCL. Les observations RIPEstat consultées pour le 1er août 2026 indiquaient six annonces IPv4, 1 280 adresses IPv4 observées, aucun préfixe IPv6 observé et deux voisins BGP observés. Ces éléments sont des observations publiques bornées dans le temps, non un inventaire interne.
  • Le résultat RPKI examiné valide seulement le couple origine AS137029 et agrégat 103.102.136.0/22, avec un maxLength examiné à /22. Il ne faut donc pas déclarer que les routes /24 observées sont couvertes ou valides sans validation séparée.
  • Le site de CMCL décrit des offres Internet et une connectivité IIG/IX. C’est une preuve de capacité déclarée par la société, non une preuve indépendante de débit, de latence, de disponibilité, de redondance ou de résultat client.

Note image : la photographie d’accompagnement montre des bobines de câble à fibre optique stockées dans un entrepôt. Elle sert de contexte matériel général. Elle ne représente pas Chittagong Multi Channel Limited, le Bangladesh, une installation CMCL, un réseau client, une panne, une fiabilité mesurée ou un résultat de production.

Entrée de répertoire liée : Nizam Uddin Mazud T/A Chittagong Multi Channel Limited

Une identité exacte, mais pas une biographie individuelle

Le point de départ doit rester l’objet d’entreprise, non le nom d’une personne extrait de la forme longue. L’entrée BTW utilise « Nizam Uddin Mazud T/A Chittagong Multi Channel Limited » et la rattache à une société privée. La formule « T/A » indique une dénomination commerciale; elle ne transforme pas l’article en portrait individuel. Pour l’analyse publique, le raccourci lisible est Chittagong Multi Channel Limited, tandis que la forme longue demeure utile pour relier les registres.

La page des membres APNIC renforce ce lien, car elle reprend la forme longue, situe l’entrée dans l’économie BD et pointe vers cmclbd.com. Cette information est importante, mais elle a une portée administrative. Une classe de membre APNIC ou une présence dans un annuaire ne donne pas le revenu, la taille du réseau, le nombre de clients, le statut réglementaire complet ni la capacité réelle. Elle indique qu’un acteur nommé existe dans l’écosystème des ressources Internet et qu’il possède une surface de contact publique.

RDAP APNIC ajoute une couche plus technique. L’enregistrement autnum pour AS137029 associe l’AS à CMCL-AS-AP, au Bangladesh et à Chittagong Multi Channel Limited. L’enregistrement RDAP pour 103.102.136.0/22 décrit une plage active, allouée portable, liée aux mêmes poignées et à la même organisation. Ces données sont les éléments minimaux d’une identité réseau : un nom, un système autonome, un bloc d’adresses et des contacts.

PeeringDB donne une autre surface, maintenue par l’écosystème d’interconnexion. L’organisation 21941 y est nommée Chittagong Multi Channel Limited, l’alias CMCL apparaît, le site cmclbd.com est présent, et le réseau AS137029 est rattaché à cette organisation. PeeringDB n’est pas un registre d’entreprise souverain, mais il est utile pour voir comment l’opérateur se présente aux autres réseaux. En combinant APNIC, RDAP, PeeringDB et le site de l’entreprise, l’identité devient suffisamment solide pour une analyse de société de télécommunications régionales.

Les limites sont tout aussi importantes. Ces sources ne disent pas qui possède actuellement la société, combien de salariés l’exploitent, combien de foyers ou d’entreprises l’utilisent, ni quels équipements ou fournisseurs composent son réseau. Elles ne démontrent pas non plus que chaque ressource historique a conservé le même régime opérationnel. Elles permettent de parler d’une identité CMCL liée à AS137029 et à un bloc IPv4; elles ne permettent pas de remplir les blancs avec une topologie imaginaire.

Pour un opérateur, cette discipline n’est pas seulement éditoriale. Les noms, alias, contrats, domaines, handles APNIC, objets PeeringDB, comptes de facturation, tickets support et circuits fournisseurs peuvent diverger avec le temps. Une carte d’identité opérationnelle doit permettre de passer de chaque alias valide à l’autorité actuelle. Sinon, un incident simple peut devenir lent : personne ne sait quel nom utiliser pour ouvrir un cas fournisseur, modifier une autorisation de route, renouveler un domaine ou répondre à une plainte abuse.

Ce que les pages de CMCL établissent réellement

Le site de CMCL présente la société comme un fournisseur de solutions Internet et décrit des services pour le domicile, l’école, le bureau, le divertissement et les communications professionnelles. La page des offres mentionne des forfaits résidentiels, notamment CMCL Basic, CMCL Family, CMCL Family Plus et CMCL Super. Le site évoque aussi une connectivité via des passerelles Internet internationales et des échanges Internet.

Ces éléments suffisent à établir une capacité déclarée : CMCL se présente publiquement comme un fournisseur d’accès Internet disposant d’offres commerciales nommées et d’une connectivité externe. Ils ne suffisent pas à établir la performance. Les pages consultées ne donnent pas de mesure indépendante de débit livré, de contention, de latence, de perte de paquets, de temps d’installation, de temps de réparation, de disponibilité, de zone de couverture ou de satisfaction client.

La distinction entre capacité, fiabilité et résultat client doit rester nette. Une offre nommée indique qu’un produit est proposé ou a été proposé sur une page consultée. Elle ne prouve pas qu’un client donné reçoit un débit précis. Une mention d’IIG ou d’IX indique une catégorie de connectivité, mais ne révèle pas les circuits, les pairs, les fournisseurs de transit, les capacités, les conditions de bascule, les contrats ou la direction des flux financiers.

La page de contact et la continuité du domaine fournissent une surface publique de support. Une page de registration visible dans l’environnement CMCL a toutefois renvoyé une erreur 404 lors de l’examen. Cette erreur ne prouve pas que les inscriptions clients sont impossibles par tous les canaux. Elle ne prouve pas non plus une panne réseau. Elle montre un risque plus ordinaire : l’information publique a un cycle de vie et peut se désynchroniser de l’exploitation.

Cette désynchronisation peut coûter cher. Une page d’offres, un formulaire, une adresse de support, un catalogue de facturation et un profil de provisionnement peuvent dépendre d’équipes ou d’outils différents. Si un lien est retiré sans redirection, si une offre reste visible après retrait, ou si un profil technique ne correspond plus au produit public, le réseau peut fonctionner tout en produisant des exceptions commerciales et support. À l’inverse, un site propre ne prouve pas une exploitation saine. Les deux surfaces doivent être rapprochées, pas confondues.

Le cas CMCL illustre donc une règle générale pour les fournisseurs d’accès régionaux : le coût d’un service ne s’arrête pas au port, à la fibre ou à l’adresse IP. Il inclut la tenue du catalogue, l’authentification, l’attribution d’adresses, la gestion du CPE, les changements de forfait, le support, la communication d’incident, les interventions terrain, les dépendances de fournisseur et les retraits propres. Le public voit un forfait. L’opérateur porte un ensemble de relations techniques et administratives.

AS137029 et le registre IPv4 APNIC

Un numéro de système autonome n’est pas une carte complète du réseau. Il est un identifiant de coordination pour le routage inter-domaine. AS137029 permet aux autres réseaux et aux collecteurs de reconnaître une origine ou une relation de routage liée à CMCL. L’enregistrement RDAP consulté le présente comme actif, sous le nom CMCL-AS-AP, avec le Bangladesh comme pays.

Le bloc 103.102.136.0/22 est plus concret encore. RDAP APNIC décrit la plage 103.102.136.0 à 103.102.139.255 comme active et allouée portable. Un /22 représente 1 024 adresses sur le plan mathématique, mais cela ne veut pas dire que chaque adresse est disponible, assignée à un client ou utilisée en production. Certaines adresses peuvent servir à l’infrastructure, aux réserves, aux équipements, aux usages internes ou rester inutilisées.

Le caractère portable de l’allocation a une signification opérationnelle. Il peut soutenir la continuité lors d’un changement de connectivité, car les adresses ne sont pas nécessairement attachées à un seul fournisseur amont. Mais la portabilité n’est pas une garantie automatique. Pour qu’elle serve réellement, l’opérateur doit maintenir l’autorité de registre, les politiques de routage, les autorisations RPKI, les objets de filtrage, le reverse DNS, les affectations clients, les contacts abuse et la documentation de récupération.

Le registre agit comme un livre de comptes des ressources : il garantit l’unicité, expose la responsabilité et fournit des métadonnées de sécurité et de contact. Il n’opère pas les routeurs. Une entrée RDAP correcte ne suffit pas à faire circuler le trafic; une annonce BGP visible ne corrige pas un contact public périmé. La continuité vient de l’accord entre les enregistrements et l’état exécuté.

Les contacts publics méritent une attention particulière. Un handle abuse ou technique n’est utile que si le message atteint une file suivie, si la personne ou l’équipe peut agir, et si une procédure distingue diagnostic, approbation, exécution et vérification. Quand un contact est syntaxiquement présent mais opérationnellement mort, une fuite de route, un incident abuse ou une demande de coordination peut rester bloqué alors que la solution technique est simple.

L’inventaire interne est l’autre moitié du sujet. Les sources publiques ne disent pas quels clients ou services utilisent les adresses CMCL, et il ne faut pas l’inférer. Un fournisseur responsable doit pourtant savoir quelle adresse est assignée à quel service, avec quelle date, quelle finalité, quel reverse DNS, quelle politique de sécurité, quel responsable et quelle condition de restitution. Sans cela, l’IPv4 devient une ressource rare mais peu traçable.

État BGP observé, voisins et validation RPKI étroite

RIPEstat apporte une vue publique bornée dans le temps. L’endpoint des préfixes annoncés montrait six entrées IPv4 pour AS137029 : l’agrégat 103.102.136.0/22, quatre routes plus spécifiques /24 à l’intérieur de cet agrégat, et 114.130.72.0/24. L’endpoint de statut de routage résumait six préfixes IPv4, 1 280 adresses IPv4, aucun préfixe IPv6 observé et deux voisins observés au moment de la requête.

Il faut résister à deux erreurs. La première consiste à traiter ces six annonces comme un inventaire interne complet. Un collecteur public observe ce qu’il voit depuis certains points; il ne sait pas tout de l’intention de l’opérateur ni de chaque client. La seconde consiste à additionner naïvement les routes. Un agrégat et des plus-spécifiques peuvent se recouvrir. Le nombre de 1 280 adresses reflète l’espace observé dans cette vue, pas un nombre de clients, d’équipements ou d’adresses utilisables.

Les plus-spécifiques soulèvent une question d’exploitation légitime : quel état est intentionnel ? Des /24 peuvent être utilisés pour l’ingénierie de trafic, l’isolement d’un site, une politique amont ou une transition. Ils peuvent aussi provenir d’un reliquat de configuration, d’une fuite ou d’un changement d’urgence resté actif. Les données publiques ne tranchent pas. L’opérateur doit posséder un inventaire d’intention indiquant quels préfixes peuvent être annoncés, depuis quels routeurs, avec quelle origine, sous quelles conditions et jusqu’à quelle date.

La validation RPKI examinée est plus étroite que l’ensemble des annonces. Le résultat RIPEstat/Routinator a retourné un état valide pour l’origine AS137029 et le préfixe agrégé 103.102.136.0/22, avec un maxLength à /22. Cela signifie que le couple agrégat-origine était cohérent au moment de la requête. Cela ne signifie pas que les /24 observés sont couverts par la même autorisation. Pour le dire, il faudrait valider chaque route plus spécifique avec son état RPKI courant et sa politique attendue.

Cette précision n’est pas académique. Un ROA trop strict peut bloquer une annonce d’urgence plus spécifique. Un ROA trop large peut autoriser des annonces que la politique interne ne voulait pas rendre valides. Un ROA correct aujourd’hui peut devenir faux après une réorganisation, un changement d’amont ou une migration. L’exploitation doit donc tester les changements avant activation, vérifier les validateurs indépendants après activation, documenter les exceptions et retirer les autorisations temporaires.

L’endpoint des voisins AS a observé AS17806 et AS58717 à côté d’AS137029. Ces voisins sont des indices de routage, pas des contrats publiés. Ils ne prouvent pas un fournisseur de transit, une capacité, une redondance indépendante, un accord financier, une hiérarchie de service ou une direction de paiement. Deux AS visibles peuvent partager un conduit, un site, une alimentation, un routeur, une configuration ou un fournisseur commun. La redondance doit être testée sur les couches physique, logique, opérationnelle et organisationnelle.

L’absence de préfixe IPv6 observé doit aussi être formulée correctement. La vue consultée n’a pas observé d’annonce IPv6 pour AS137029. Cela ne prouve pas qu’aucun plan IPv6, laboratoire, tunnel, allocation future ou travail préparatoire n’existe chez CMCL. Cela pose une question de cycle de vie : quel est l’état approuvé de l’IPv6, et comment l’opérateur évite-t-il à la fois la dépendance indéfinie à l’IPv4 et l’annonce prématurée d’un déploiement non mesuré ?

Capacité, fiabilité et résultats clients : trois niveaux distincts

Les sources disponibles soutiennent plusieurs affirmations de capacité. CMCL possède une identité cohérente dans APNIC et PeeringDB. AS137029 apparaît dans des observations de routage. APNIC associe un bloc IPv4 portable à l’entreprise. CMCL présente des forfaits Internet. Une requête RPKI valide l’agrégat avec l’origine AS137029.

Aucune de ces affirmations n’est une preuve de fiabilité. La fiabilité demanderait une frontière de service définie et des mesures répétées : disponibilité de l’accès, perte de paquets, latence, gigue, congestion, performance DNS, authentification, stabilité de routage, temps de prise en charge, temps de rétablissement, récurrence d’incidents et proportion de clients affectés. Un préfixe visible à un instant ne dit pas ce qui se passe à l’heure de pointe. Un ROA valide ne dit rien d’une coupure fibre. Une page d’accueil fonctionnelle ne mesure pas l’accès client.

Les résultats clients exigent encore un autre niveau de preuve. Pour affirmer qu’un service a amélioré un résultat commercial ou opérationnel, il faudrait un client ou un groupe clairement attribuable, une situation de départ, une période, une mesure, et une méthode pour séparer les autres variables. Les sources consultées ne fournissent aucun résultat client de ce type. Il serait donc faux d’inventer une amélioration de revenu, de disponibilité applicative, de productivité ou de performance métier.

L’absence de résultat public n’est pas une preuve d’échec. Beaucoup de fournisseurs d’accès ne publient pas de mesures détaillées, et certains clients gardent leur réseau confidentiel. La bonne conclusion est plus sobre : les capacités visibles sont réelles dans les registres et les pages consultées; la fiabilité et les résultats restent non vérifiés publiquement.

Cette échelle de preuve protège les lecteurs et l’opérateur. Le marketing tend à comprimer les niveaux, car une capacité technique est facile à annoncer et un résultat client est convaincant. L’ingénierie doit les séparer. Une route existe. Un contrôle est testé. Un service respecte une limite dans le temps. Un client obtient un résultat mesuré. Ce sont quatre propositions différentes, avec quatre exigences de preuve.

Coûts de supervision, d’intégration, de maintenance et d’exception

La supervision consiste à savoir quel état devrait exister et à détecter l’écart. Dans le cas CMCL, elle couvre l’identité de société, le compte RIR, l’ASN, l’inventaire des préfixes, les origines autorisées, les ROA, les contacts publics, le domaine, le DNS, les sessions externes, les plateformes d’accès, les affectations clients, le monitoring et les files de support. Chaque contrôle à fort impact a besoin d’un propriétaire, d’un suppléant, d’une date de revue, d’une preuve d’action possible et d’une observation indépendante.

L’intégration consiste à faire correspondre des systèmes qui n’ont pas été conçus comme un seul ensemble. La forme longue du membre APNIC, le nom court CMCL, l’étiquette AS, le slug de répertoire, les entrées PeeringDB, les contrats clients, les circuits, les ports, les VLAN, les pools d’adresses, la facturation et les tickets support doivent pouvoir être reliés. Une modification peut réussir dans un système et échouer au suivant. Créer un compte client ne prouve pas que l’accès, la politique, l’adresse, l’assistance et la facture sont cohérents.

La maintenance conserve les contrôles utilisables. Les enregistrements APNIC et PeeringDB doivent être revus. Les ROA et les politiques de route doivent rester alignés. Les routeurs, optiques, plateformes d’accès, systèmes d’authentification, DNS, monitoring et équipements clients vieillissent selon des cycles différents. Les pages publiques vieillissent aussi : un lien cassé, une offre retirée mais encore visible ou une consigne de contact obsolète peuvent augmenter la charge support et brouiller la communication pendant un incident.

Le traitement des exceptions consomme souvent plus de temps que le flux normal. Une adresse déjà assignée, une route vue depuis une origine inattendue, un ROA incompatible avec une annonce d’urgence, un niveau optique marginal, un cas fournisseur ouvert sous le mauvais circuit, une offre qui ne correspond plus au catalogue de facturation ou une demande reçue sous un ancien nom exigent du jugement. Chaque exception matérielle doit avoir un propriétaire, un impact, une preuve, une prochaine action, une limite de temps, un chemin de communication et un test de clôture.

Ces coûts ne sont pas visibles dans une simple fiche d’entreprise. Pourtant, ils expliquent pourquoi la continuité d’un FAI régional dépend autant des relations entre données que des actifs eux-mêmes. Un lien peut être en place, mais mal documenté. Une route peut être visible, mais non conforme à l’intention. Une offre peut être vendue, mais difficile à provisionner. Une adresse peut répondre, mais être rattachée à un client ou à un service mal identifié.

Modes de défaillance concrets à borner

  1. Divergence entre identités d’entreprise et de réseau. La forme APNIC longue, le nom RDAP court, PeeringDB, le domaine, le contrat et le support ne pointent plus vers la même autorité. Le contrôle est une carte d’alias datée, avec base juridique, propriétaires de systèmes, dates d’effet et règle d’approbation.
  2. Contacts publics présents mais inopérants. Un contact abuse ou technique existe dans RDAP mais ne mène pas à une file suivie. Le contrôle est un test périodique de livraison, des suppléants, une preuve de réponse et une procédure de mise à jour de tous les enregistrements dépendants.
  3. Retrait involontaire d’un préfixe. Une maintenance, un filtre amont, une erreur de configuration ou une panne physique supprime une route attendue. Le contrôle est une surveillance externe contre l’intention approuvée et un plan de rétablissement qui ne dépend pas du chemin défaillant.
  4. Origine inattendue. Un autre AS annonce un espace CMCL. Le contrôle est la surveillance d’origine, des ROA étroits, des filtres amont, des contacts de coordination et une clôture fondée sur la preuve.
  5. Désaccord entre plus-spécifiques et maxLength RPKI. L’agrégat est valide, mais des /24 ne sont pas couverts. Le contrôle est la validation avant changement de chaque paire préfixe-origine et l’expiration des autorisations temporaires.
  6. Confusion entre routage visible et disponibilité. Un préfixe est vu par des collecteurs et l’on conclut que le service client fonctionne. Le contrôle est une mesure par couches : routage, atteignabilité, authentification, DNS, qualité de paquet, frontière applicative et impact client.
  7. Voisins BGP pris pour une redondance indépendante. Deux AS observés partagent peut-être une dépendance physique ou opérationnelle. Le contrôle est une cartographie des dépendances et des exercices de panne.
  8. Statut IPv6 inféré à partir d’une seule vue. Aucun préfixe IPv6 observé devient une affirmation absolue. Le contrôle est un modèle d’état IPv6 approuvé : plan, routage, DNS, sécurité, monitoring, support et activation mesurée.
  9. Divergence entre inventaire d’adresses et clients. Une adresse reste assignée après résiliation ou est récupérée alors qu’une dépendance existe. Le contrôle est un cycle d’affectation traçable, avec dates, finalité, reverse DNS, politique et preuve de restitution.
  10. Offre publique et profil de provisionnement désalignés. Le site nomme un forfait que les systèmes ne peuvent plus créer. Le contrôle est un catalogue produit unique, des tests du parcours commande-provisionnement et un processus de retrait.
  11. Lien public cassé sous-estimé. Une erreur 404 est traitée comme cosmétique alors qu’elle touche un chemin d’inscription. Le contrôle est une classification par impact de service, un propriétaire et une route alternative vérifiée.
  12. Inventaire fibre incohérent avec le terrain. Un splice, un boîtier, un port ou une desserte client porte un nom différent dans l’outil et sur site. Le contrôle est la vérification terrain, la correspondance géographique et logique, et une preuve de changement.
  13. Monitoring dépendant du service surveillé. Le chemin d’alarme utilise le même DNS, accès ou domaine électrique que le service. Le contrôle est une sonde indépendante et une escalade hors bande.
  14. Autorité de maintenance indisponible. Une seule personne ou un seul compte peut modifier RIR, ROA, routeurs, DNS ou cas fournisseur. Le contrôle est l’accès par rôle, des suppléants, des secrets d’urgence et des tests de récupération.
  15. Exception temporaire devenue permanente. Un plus-spécifique d’urgence, un contournement de filtre ou une affectation manuelle reste en place. Le contrôle est un registre d’exceptions avec raison, impact, date d’expiration et revue.
  16. Maintenance externe non reliée aux clients. Un avis IIG, IX, fibre ou site arrive sans que l’opérateur sache quels services sont touchés. Le contrôle est un graphe reliant circuits, ports, sessions, préfixes, services et groupes de communication.
  17. Copie commerciale répétée comme preuve de fiabilité. Une description de forfait devient un argument de performance. Le contrôle est une échelle de preuve séparant capacité, mesure de fiabilité et résultat client.
  18. Documentation ou image trop révélatrice. Une photo ou un document expose identifiants, clients ou procédures sensibles. Le contrôle est une revue de publication, une image contextuelle et une divulgation minimale.

Questions d’opérateur

Un opérateur responsable devrait pouvoir répondre à plusieurs questions simples sans enquête longue. Quelle entité actuelle autorise les changements sur AS137029, les ressources APNIC, le domaine cmclbd.com, les contrats clients et les fournisseurs ? Comment la forme longue du membre APNIC se rattache-t-elle au nom court CMCL dans les systèmes internes ?

Quels préfixes AS137029 doit-il annoncer aujourd’hui ? Les /24 observés sont-ils permanents, temporaires, liés à l’ingénierie de trafic ou à un client ? Quel système compare l’intention à l’observation externe ? Combien de temps faut-il pour détecter une origine inattendue ou un retrait non prévu ?

Quels ROA doivent exister pour l’agrégat et pour toute route plus spécifique autorisée ? Qui peut les modifier, comment une modification est-elle testée, et que se passe-t-il si les identifiants RIR ou la personne habilitée sont indisponibles ?

Quels chemins physiques et logiques sous-tendent les voisins observés, l’IIG et l’IX ? Quels risques partagent-ils ? Une diversité d’AS cache-t-elle une dépendance de fibre, de site, de routeur, d’alimentation, de fournisseur ou d’équipe ?

Quelle est la frontière exacte de chaque forfait publié ? Où s’arrête la responsabilité de CMCL ? Quelles mesures démontrent l’état de l’accès, de l’authentification, de la qualité de paquet, du support et de la réparation ? Les pages publiques correspondent-elles encore au catalogue et au provisionnement ?

Quel est l’état approuvé de l’IPv6 ? S’agit-il d’absence publique, de plan, de test, de déploiement partiel ou d’offre client ? Les outils de sécurité, DNS, supervision et support sont-ils prêts avant l’annonce commerciale ?

Quelles exceptions restent ouvertes ? Depuis combien de temps ? Quel risque créent-elles ? Qui possède la prochaine action ? À quelle date le risque accepté expire-t-il ?

Inconnues et conclusion

Le dossier public établit une identité de société et de réseau cohérente. Le répertoire BTW donne l’objet long. APNIC relie ce nom au Bangladesh et à cmclbd.com. RDAP associe CMCL à AS137029 et au bloc 103.102.136.0/22. PeeringDB relie l’organisation, le réseau, le domaine et l’ASN. RIPEstat fournit des observations de routage, de voisins et de validation RPKI pour l’agrégat.

Le dossier public n’établit pas l’actionnariat, les revenus, l’effectif, le nombre d’abonnés, la géographie détaillée, la topologie, les circuits, les fournisseurs, les équipements, l’utilisation, l’historique d’incidents, les SLA, les performances, les affectations clients, les contrôles de sécurité ou les tests de reprise. Il n’établit pas non plus les relations commerciales derrière AS17806 et AS58717.

Cette limite ne rend pas le cas faible; elle le rend utile. CMCL montre comment un fournisseur d’accès régional existe à travers des registres, des routes, des métadonnées de sécurité, des pages commerciales, des contacts, des fibres et des dépendances externes. La continuité ne découle pas d’une seule inscription APNIC, d’un seul ASN ou d’une seule session BGP. Elle découle de relations maintenues : identité vers autorité, préfixe vers intention, ROA vers annonce, circuit vers service, offre vers provisionnement, exception vers clôture.

Une analyse défendable doit donc rester dans la réalité observée. CMCL dispose d’une identité réseau publique, d’un AS, d’un bloc IPv4 portable, d’annonces IPv4 observées, d’un résultat RPKI valide pour l’agrégat et d’une présence commerciale de fournisseur d’accès. La fiabilité, les résultats clients et l’architecture interne restent à prouver par d’autres éléments. C’est précisément là que se situe le coût durable d’un FAI : maintenir les preuves, les systèmes et les personnes assez alignés pour que la capacité déclarée devienne un service continu.

Sources

  1. Répertoire BTW : Nizam Uddin Mazud T/A Chittagong Multi Channel Limited
  2. Annuaire des membres APNIC : entrée CMCL
  3. Page d’accueil CMCL
  4. Page des offres CMCL
  5. Page de contact CMCL
  6. RDAP APNIC : AS137029
  7. RDAP APNIC : 103.102.136.0/22
  8. PeeringDB organisation : Chittagong Multi Channel Limited
  9. PeeringDB réseau : AS137029
  10. RIPEstat AS overview : AS137029
  11. RIPEstat announced prefixes : AS137029
  12. RIPEstat routing status : AS137029
  13. RIPEstat RPKI validation : AS137029 et 103.102.136.0/22
  14. RIPEstat voisins ASN observés : AS137029
  15. Wikimedia Commons : bobines de fibre optique en entrepôt