NTT DOCOMO BUSINESS et AS4713 : ce qu’une identité réseau prouve

Résumé

NTT indique que NTT Communications Corporation a pris le nom de NTT DOCOMO BUSINESS, Inc. le 1er juillet 2025. La réponse RDAP actuelle d’APNIC redirigée vers JPNIC, les données de RIPEstat et la liste de JPNAP relient, chacune dans son propre cadre, le nouveau nom, OCN et AS4713, tandis que PeeringDB affiche encore l’ancienne raison sociale.
AS4713 fournit une identité publique utile pour le routage. Une observation RIPEstat datée du 5 août 2026 comptait 187 enregistrements de préfixes, soit 181 en IPv4 et six en IPv6, mais cette mesure filtrée n’est ni un cadastre d’adresses ni une preuve de disponibilité pour chaque utilisateur.
La vérification RPKI consultée porte uniquement sur le couple AS4713 et 61.207.0.0/16, revenu valide avec une longueur maximale de 16. Elle ne permet pas de déclarer toutes les routes d’AS4713 valides pour toujours.
Pour un acheteur ou une équipe d’exploitation, la bonne méthode consiste à relier le contrat, la société, l’ASN, les préfixes autorisés, les réglages de routage et les mesures du service, puis à conserver la date et la portée de chaque preuve.

Entrée du répertoire : NTT DOCOMO Business, Inc

Note sur l’image : la photographie d’accompagnement est une reconstitution éditoriale de style réaliste. Elle montre une analyste indépendante fictive comparant des documents sans marque à côté d’un cordon de fibre sans marque. Elle ne représente ni le personnel, ni les locaux, ni les équipements, ni les clients de NTT DOCOMO BUSINESS, de l’ancienne NTT Communications Corporation, d’OCN, d’APNIC ou de JPNAP. Les feuilles et la petite carte sont illustratives : elles ne montrent pas une véritable route AS4713 et ne prouvent ni identité de société, ni propriété de préfixe, ni validité de route, ni performance, ni continuité de service.

Analyse

Le nom de l’entreprise et le numéro du réseau ne remplissent pas la même fonction

La page de présentation de NTT DOCOMO BUSINESS donne le nom actuel de l’entreprise et précise que NTT Communications Corporation a changé de nom le 1er juillet 2025. Un communiqué du groupe NTT, publié avant cette date, avait annoncé cette évolution. Ces deux documents permettent donc une affirmation mesurée : selon les sources émises par le groupe, le changement de nom annoncé est devenu effectif à cette date.

Ils ne permettent pas d’aller beaucoup plus loin. Les documents publics examinés ne sont pas un extrait indépendant d’un registre des sociétés retraçant toutes les conséquences juridiques de l’opération. Ils ne décrivent ni acquisition, ni fusion, ni transfert général d’actifs, ni création d’une nouvelle société. Ils ne montrent pas non plus que chaque contrat, chaque compte technique et chaque fiche de réseau a été renommé au même instant. Présenter l’événement comme un changement de nom respecte ce que les documents disent réellement.

Cette limite explique en partie les libellés différents que l’on trouve aujourd’hui. La réponse RDAP actuelle d’APNIC, redirigée vers le service de JPNIC pour cette ressource japonaise, utilise le nom OCN et fait référence à NTT DOCOMO BUSINESS, Inc. RIPEstat associe également OCN et le nouveau nom dans son aperçu du système autonome. La liste de participants de JPNAP relie NTT DOCOMO BUSINESS, OCN et AS4713 à Tokyo et Osaka. PeeringDB conserve, pour sa part, le libellé « NTT Communications Corporation (OCN) ».

La coexistence de ces noms n’est pas, à elle seule, la preuve qu’un registre est faux. Une page institutionnelle décrit une identité d’entreprise. Un registre régional tient des informations sur les ressources numériques. Un observateur de routes restitue ce que ses collecteurs ont vu. Une bourse d’échange publie une liste de participants. Un annuaire d’interconnexion comporte des champs entretenus selon son propre calendrier. Les usages et les responsables ne sont pas les mêmes.

Une question plus utile que « quel site détient la vérité absolue ? » est donc : « quelle question ce document pouvait-il répondre, à quelle date, et qui doit rapprocher son information des autres systèmes ? » Cette façon de procéder évite de transformer une étiquette familière en certificat universel.

AS4713 expliqué sans présupposer de connaissances réseau

Internet relie des milliers de réseaux administrés indépendamment. Pour s’indiquer les blocs d’adresses qu’ils savent joindre, ces réseaux échangent des annonces au moyen du protocole BGP, ou Border Gateway Protocol. Un numéro de système autonome, abrégé ASN, identifie la politique de routage d’un réseau dans cet échange. AS4713 est un de ces numéros.

Un ASN n’est pas une adresse IP. Ce n’est pas non plus un numéro d’immatriculation d’entreprise, un compte client, une référence de routeur ou une note de qualité. Il sert d’identifiant stable lorsque des réseaux annoncent et sélectionnent des chemins. Dans les documents consultés, AS4713 est associé à OCN et, à certains niveaux de registre, à NTT DOCOMO BUSINESS.

La stabilité d’un ASN a une valeur pratique. Un changement de marque ou de raison sociale n’oblige pas nécessairement tous les voisins Internet à remplacer un numéro de routage. Les politiques, les filtres, les alertes et les contacts peuvent ainsi continuer à s’appuyer sur un identifiant connu pendant que les informations administratives sont rapprochées.

Cette stabilité ne constitue pourtant pas une preuve d’absence d’interruption. Voir AS4713 dans un registre actuel et dans une observation de routes ne démontre pas que chaque paquet client a circulé sans coupure le 1er juillet 2025. Cela ne révèle pas qui a validé chaque changement, si tous les outils internes ont adopté le nouveau nom ni si une application particulière était accessible. Cela montre une identité de routage persistante dans les limites de temps et de méthode des sources.

On peut comparer l’ASN au numéro d’une ligne ferroviaire. Le numéro aide voyageurs et systèmes de contrôle à reconnaître la ligne même si l’exploitant change de nom. Il ne prouve pas la propriété de chaque rail, la ponctualité de tous les trains ou la mise à jour de chaque contrat. Ces dernières questions exigent d’autres documents. Il en va de même pour un numéro de réseau.

Ce que dit précisément la réponse RDAP APNIC-JPNIC

APNIC est le registre Internet régional de la zone Asie-Pacifique. Pour la ressource japonaise consultée ici, le point d’accès d’APNIC redirige la requête vers le service RDAP de JPNIC. RDAP, pour Registration Data Access Protocol, fournit des données structurées sur les ressources numériques et évite de déduire leur contenu à partir d’une page sans structure.

La réponse RDAP APNIC-JPNIC actuelle pour AS4713 indique le nom OCN, le pays JP, un état actif et une description mentionnant NTT DOCOMO BUSINESS, Inc. C’est une preuve primaire solide pour une proposition délimitée : dans la couche actuelle du registre régional, ces libellés sont rattachés à AS4713.

Le mot « actif » doit rester dans cette couche. Il qualifie l’objet du registre, pas le fonctionnement minute par minute du réseau. Une fiche active peut coexister avec une panne d’accès locale, une erreur DNS, un incident applicatif ou un mauvais réglage chez un client. À l’inverse, l’indisponibilité temporaire du site d’un registre ne ferait pas disparaître un réseau en fonctionnement.

La fiche ne constitue pas davantage un titre de propriété sur chaque préfixe observé derrière l’ASN. Un opérateur peut annoncer des adresses fournies par un client dans le cadre d’une autorisation. Des préfixes peuvent changer d’origine pendant une migration ou une opération de protection. Les contacts administratifs, les titulaires d’adresses et les personnes qui exploitent une session BGP peuvent être différents.

Le registre est donc précieux comme grand livre : il contribue à préserver l’unicité d’un numéro, son état, ses désignations et des points de contact. Mais il n’est ni souverain sur tous les faits entourant le réseau ni remplaçant du système réellement en marche. Son rôle gagne en crédibilité lorsque sa portée reste claire.

Une photographie du routage prise le 5 août 2026

RIPEstat rassemble plusieurs produits fondés sur des données de registre et des observations de routage. Pour AS4713, la consultation retenue couvre la période du 5 août 2026 entre 00 h 00 et 16 h 00 UTC. Le résultat des préfixes annoncés contient 187 enregistrements : 181 en IPv4 et six en IPv6.

Le nombre n’a de sens qu’avec sa méthode. Le service indique qu’il exclut les routes vues par moins de dix pairs à table complète de RIPE RIS. La liste n’est donc pas une collection de toute route qui pourrait apparaître depuis n’importe quel point d’Internet. Elle restitue un sous-ensemble conforme au seuil de cet observateur pendant cette fenêtre.

Pour l’état de routage demandé à 16 h 00 UTC, RIPEstat a renvoyé une visibilité auprès de 326 pairs IPv4 sur 326 retenus et de 322 pairs IPv6 sur 322 retenus. Le résultat mentionnait également 181 préfixes IPv4, six préfixes IPv6 et 122 voisins observés. Le service signalait que l’heure demandée avait été ajustée aux dernières données disponibles ; il faut donc conserver l’heure effectivement renvoyée et l’avertissement, pas présenter l’heure souhaitée comme garantie.

Les fractions 326 sur 326 et 322 sur 322 peuvent sembler signifier « tout Internet voyait le réseau ». Ce serait une extrapolation. Les dénominateurs désignent les pairs inclus dans cette vue RIPE RIS. Un collecteur peut recevoir une annonce alors qu’un utilisateur rencontre une coupure d’accès, un filtrage, une congestion, une panne de serveur ou une erreur d’application. La visibilité d’une route et l’expérience de bout en bout ne sont pas la même mesure.

Les 122 voisins ne constituent pas non plus une liste de clients. Une relation visible dans un chemin BGP peut correspondre à plusieurs modèles d’interconnexion ; son interprétation dépend du point d’observation et de la politique appliquée. Le nombre peut évoluer si la couverture des collecteurs ou les annonces changent.

La formulation correcte est donc datée : dans cette fenêtre et selon ce seuil, l’observateur a renvoyé 187 enregistrements de préfixes pour AS4713 et les valeurs de visibilité indiquées. Ces chiffres ne disent pas qui détient chaque bloc, qui l’utilise, quelle application répond ni si chaque route est autorisée.

Une validation RPKI ne vaut que pour le couple interrogé

RPKI, l’infrastructure à clés publiques pour les ressources, permet de publier des autorisations d’origine de route. Une ROA, ou Route Origin Authorisation, indique qu’un ASN déterminé est autorisé à être l’origine d’un préfixe, éventuellement jusqu’à une longueur maximale donnée.

La vérification incluse ici porte sur AS4713 et le préfixe 61.207.0.0/16. Le service a retourné le statut valide avec le validateur Routinator, pour une autorisation dont l’origine est 4713 et la longueur maximale 16. Cette information est pertinente : elle décrit des métadonnées de sécurité vérifiables pour ce couple précis.

Elle ne couvre pas toutes les annonces d’AS4713. D’autres préfixes peuvent être couverts par d’autres ROA, par des longueurs maximales différentes, ou ne pas disposer du même état. Les autorisations peuvent évoluer. Changer l’origine ou le préfixe interrogé revient à poser une autre question.

La validation d’origine a aussi une limite fonctionnelle. Elle vérifie la relation entre un préfixe et l’ASN déclaré à l’origine du chemin. Elle n’authentifie pas chaque réseau traversé. Elle ne mesure ni l’état d’une fibre, ni la latence, ni les pertes, ni le fonctionnement de l’application finale.

Une phrase responsable dit donc : « le couple AS4713–61.207.0.0/16 est revenu valide lors de cette consultation ». La phrase « AS4713 est sécurisé par RPKI » serait trop large. Pour gouverner l’ensemble, il faut maintenir l’inventaire des adresses, les origines prévues, les ROA, les longueurs maximales, les objets de route, les filtres et les alertes.

Les contrôles d’un produit ne sont pas des résultats de production

La documentation de routage de Super OCN Flexible Connect décrit un autre niveau de preuve. Pour ce produit, elle indique AS4713 du côté OCN et présente des choix entre routage statique et BGP. Elle explique aussi certains cas d’usage d’un ASN client et d’adresses IP apportées par le client lorsque les conditions prévues sont remplies.

La page publie plusieurs paramètres concrets. Pour le profil BGP décrit, elle exige un mot de passe d’authentification MD5, indique une limite de 1 000 préfixes et un temps de maintien minimal de 30 secondes, et documente des communautés BGP liées à la priorité du trafic. Elle précise également que LFS et BFD ne sont pas pris en charge pour ce produit.

Ces détails illustrent le travail dissimulé derrière une connexion apparemment simple. Une personne doit confirmer l’ASN attendu, contrôler l’éligibilité des adresses fournies par le client, régler la limite de préfixes, protéger le secret d’authentification, examiner les communautés et tester les changements. Une autre doit surveiller les écarts et connaître la procédure de retour en arrière.

La limite de 1 000 ne mesure pas la taille d’AS4713. C’est un garde-fou associé à une session relevant de cette offre. Le minimum de 30 secondes n’est pas une promesse de rétablissement. MD5 protège un mécanisme de session particulier sans rendre tout le service invulnérable. Quant à BFD, son absence dans ce produit ne permet pas de conclure à un mauvais service ; elle oblige simplement à concevoir la détection et la continuité avec les mécanismes réellement disponibles.

La documentation de l’opérateur établit les capacités et contraintes publiées. Elle ne prouve pas que chaque client les a configurées correctement, qu’un changement précis a été relu ou qu’un incident a respecté un engagement contractuel. Ces résultats nécessitent la configuration du client, ses journaux, ses mesures, ses tickets et ses essais.

Pourquoi PeeringDB et RIPEstat peuvent afficher des nombres différents

PeeringDB est un annuaire entretenu par les opérateurs pour faciliter l’interconnexion. Son profil de réseau numéro 826 présente AS4713 sous l’ancien nom « NTT Communications Corporation (OCN) ». Dans la vue consultée, les compteurs de préfixes IPv4 et IPv6 étaient tous deux à zéro.

Ce zéro apparaît à côté des 181 enregistrements IPv4 et six IPv6 observés par RIPEstat. En mettant les valeurs dans une seule colonne appelée « nombre de préfixes », un logiciel pourrait déclencher une alerte spectaculaire. Mais il comparerait deux champs qui n’ont ni la même définition, ni le même responsable, ni le même calendrier.

PeeringDB est un annuaire volontaire. Certains champs peuvent ne pas être renseignés, être anciens ou servir surtout à la découverte entre opérateurs. RIPEstat construit un résultat à partir d’un dispositif d’observation et d’une fenêtre temporelle. Le zéro de l’annuaire ne prouve donc ni l’absence de préfixes ni une panne. Les routes observées ne prouvent pas, en retour, que tous les champs de l’annuaire sont à jour.

La différence est utile parce qu’elle révèle un besoin de sémantique. Un tableau de bord devrait stocker le nom de la source, la définition du champ, la date, la méthode d’entretien et le niveau de confiance. Il peut alors demander une vérification humaine au lieu de déclarer qu’une des plateformes a nécessairement tort.

Le changement de nom ajoute une difficulté. Une ancienne raison sociale peut rester attachée à des informations d’interconnexion encore exploitables. Un nom récent peut côtoyer un champ opérationnel ancien. Il vaut mieux rapprocher les champs un à un, conserver la provenance de l’ancien nom et indiquer la date de la correction.

Ce que la présence chez JPNAP démontre — et ce qu’elle ne démontre pas

La liste actuelle de JPNAP relie NTT DOCOMO BUSINESS, OCN et AS4713 dans les contextes d’échange de Tokyo et d’Osaka. Elle fournit ainsi une jonction publique utile entre le nom actuel, l’étiquette du réseau et l’ASN à l’intérieur de cet annuaire d’échange.

Un point d’échange Internet, ou IX, facilite l’interconnexion de réseaux. Une présence publiée peut aider à trouver un opérateur et à planifier des échanges. Elle ne révèle pas chaque accord privé, le volume de trafic, les préférences de route ou le résultat de performance d’une application.

Deux emplacements nommés ne prouvent pas non plus que le service d’un client possède deux chemins entièrement indépendants. Des liaisons peuvent partager un accès au bâtiment, un transport, une alimentation électrique, un équipement ou une équipe d’exploitation. La résilience se vérifie sur le trajet réellement acheté, pas sur le seul nombre de villes figurant dans une liste.

La bonne conclusion reste étroite : à la date de consultation, JPNAP associait ces libellés et AS4713 à Tokyo et Osaka. La liste ne remplace ni un contrat, ni une topologie physique, ni une mesure de trafic.

Le nom NTT ne désigne pas un seul système autonome

Une difficulté fréquente consiste à prendre la marque d’un groupe pour un identifiant de routage unique. Deux sources consultées permettent d’éviter ce raccourci. Un article technique d’APNIC publié en 2023 distingue l’OCN domestique AS4713, le réseau mobile AS9605 et le GIN mondial AS2914. Une ancienne page de l’opérateur distingue elle aussi GIN AS2914 et OCN AS4713 dans la description d’un service à deux ASN.

L’article de 2023 contient une analyse historique : il ne faut pas transformer ses conclusions de l’époque en chiffres actuels. La page de l’opérateur n’est pas datée : elle ne peut étayer une affirmation présente sur l’échelle, la qualité ou la part de marché. Les deux sources restent utiles pour un point limité, à savoir que « NTT » ne correspond pas à un seul numéro de réseau.

Cette précision réduit les erreurs lors d’un incident. Un trajet contenant AS2914 ne doit pas être décrit automatiquement comme AS4713. Une observation concernant AS9605 ne doit pas être attribuée à OCN par simple proximité de marque. Le bon ASN oriente l’alerte vers le responsable pertinent et aide à vérifier la bonne liste de préfixes.

Les pannes administratives qu’un changement de nom peut provoquer

Un changement de nom paraît souvent sans effet technique. Pourtant, une identité d’entreprise se retrouve dans les contrats, les factures, les certificats, les listes d’autorisation, les dépôts de politique de routage, les tableaux de bord, les contacts d’urgence, les portails fournisseurs et les pièces d’audit. Les documents publics ne montrent qu’une petite partie de cette surface.

Un premier risque est le rejet d’un contact portant l’ancien nom. En pleine panne, une personne peut croire qu’il s’agit du mauvais fournisseur alors que le numéro de téléphone et l’équipe sont toujours compétents. L’escalade perd alors du temps à cause d’une différence d’étiquette.

Un deuxième risque vient des comparaisons automatiques. Une règle littérale peut traiter NTT Communications Corporation et NTT DOCOMO BUSINESS, Inc. comme deux sociétés sans rapport et créer une fausse exception. Une règle trop large peut, au contraire, regrouper tous les réseaux portant la marque NTT et autoriser un périmètre excessif.

Un troisième risque concerne l’association entre produit, ASN et contrat. Les ingénieurs peuvent parler d’OCN, le service achats du nom de la société, et un outil de routage d’AS4713. Si aucun tableau de correspondance ne relie ces identifiants, un changement peut être approuvé pour le mauvais préfixe ou envoyé à la mauvaise équipe.

Un quatrième risque touche les adresses apportées par un client. Le fait qu’un préfixe soit observé avec AS4713 comme origine ne suffit pas à l’inscrire parmi les actifs de NTT DOCOMO BUSINESS. Il peut relever d’une autorisation de service. La confusion fausserait inventaire, sécurité et audit.

Un cinquième risque est la dérive des métadonnées de sécurité. Les contacts, objets de route, ROA et filtres peuvent dépendre de propriétaires différents. Un nouveau nom affiché dans une interface ne dit pas si l’autorisation opérationnelle a changé. Ce décalage peut être normal, à condition d’être compris et traçable.

La réponse n’est pas d’imposer la même chaîne de caractères partout. Elle consiste à maintenir une table de correspondance comprenant le nom actuel, l’ancien nom, le libellé de service, l’ASN, les handles de registre, les préfixes utiles, la partie au contrat et les responsables d’escalade. Chaque lien doit porter une source, une date de revue et un propriétaire.

Ce que l’automatisation accomplit et le travail qu’elle déplace

BGP automatise l’échange de joignabilité. Les filtres peuvent refuser des annonces qui sortent d’une politique approuvée. Les validateurs RPKI classent des relations entre origine et préfixe. Les outils de surveillance signalent rapidement une modification. Ces mécanismes évitent une grande quantité de traitement manuel.

Ils ne suppriment pas la responsabilité. Quelqu’un définit la politique et les exceptions. Quelqu’un maintient l’inventaire. Quelqu’un décide si une annonce rejetée correspond à une erreur, à une autorisation devenue ancienne ou à un changement légitime. Quelqu’un vérifie que le retour en arrière fonctionne.

Le changement de nom rend la répartition visible. Les équipes juridiques et de communication entretiennent l’identité de société. Les spécialistes des ressources numériques tiennent les contacts du registre. Les ingénieurs exploitent les sessions et les filtres BGP. La sécurité surveille RPKI et les origines inattendues. Les équipes clients rapprochent préfixes, contrats et résultats.

Mesurer seulement le nombre de routes traitées automatiquement cache ce travail. Des indicateurs plus honnêtes comprennent l’âge des fiches anciennes, le nombre d’exceptions non résolues, le temps nécessaire pour trouver le bon responsable, la réussite du retour en arrière et la durée d’une divergence RPKI. L’automatisation exécute des hypothèses à grande échelle ; des identifiants précis rendent ces hypothèses plus sûres.

Comment un acheteur non spécialiste peut vérifier la continuité

Un acheteur n’a pas besoin de maîtriser BGP pour poser les bonnes questions. Il peut commencer par l’identité contractuelle : quelle société exacte fournit et facture le service ? Quels anciens noms subsistent dans les documents techniques ? Qui confirme qu’un changement de nom n’a pas changé la partie responsable ?

Il peut ensuite demander quel réseau est réellement concerné. Le service utilise-t-il AS4713, AS2914, AS9605 ou un autre ASN ? La réponse varie-t-elle selon le produit, le pays ou la direction du trafic ? Une marque de groupe n’est pas une réponse suffisante.

Vient ensuite l’inventaire des adresses. Qui détient les préfixes critiques ? Qui est autorisé à les annoncer ? Le client apporte-t-il ses propres adresses ? Où sont conservés la ROA, l’objet de route, l’accord d’origine et la personne qui approuve une modification ?

Les réglages doivent être nommés : routage statique ou BGP, limite de préfixes, mécanisme d’authentification, communautés acceptées, temporisations et fonctions non prises en charge. L’acheteur doit aussi savoir qui peut modifier ces paramètres et comment une erreur est annulée.

Enfin, il faut mesurer le résultat depuis les lieux et applications qui comptent. La visibilité publique d’une route n’est pas un test d’application. Un contrôle utile enregistre le lieu, l’heure, la résolution DNS, la perte, la latence, la réponse de l’application, le contexte de route et le code d’erreur.

Un essai de continuité complète l’analyse. Que se passe-t-il si le circuit principal, un appareil, un site ou une route disparaît ? Le trafic passe-t-il réellement par un domaine de panne différent ? Combien de temps l’application met-elle à retrouver un état utile ? Qui prend la décision de revenir à la configuration précédente ?

Cette démarche respecte les portées. Le registre prouve un fait de registre. L’observateur prouve une observation. La documentation prouve une conception publiée. Le test client prouve un résultat dans les conditions et au moment du test.

Ce que les éléments publics ne permettent pas d’affirmer

Les éléments examinés ne donnent ni disponibilité, ni latence, ni perte de paquets, ni nombre de clients, ni part de marché pour AS4713. Ils ne prouvent pas que les 187 préfixes observés appartiennent tous à NTT DOCOMO BUSINESS. Ils ne montrent pas non plus que chaque annonce d’AS4713 dispose d’une ROA valide.

Ils ne prouvent pas une exploitation sans interruption avant, pendant et après le changement de nom de juillet 2025. La persistance d’un identifiant et des observations actuelles soutiennent la continuité d’une identité réseau, pas un historique complet des incidents.

La description RDAP APNIC-JPNIC n’est pas un certificat souverain de propriété. Le compteur de PeeringDB n’est pas un inventaire de routes en temps réel. La présence chez JPNAP n’est pas un résultat de débit, de latence ou de disponibilité. Une documentation de produit émise par l’opérateur n’est pas une vérification indépendante de la configuration de chaque client.

Les documents ne quantifient pas non plus les heures gagnées ou dépensées grâce à l’automatisation. Ils montrent des mécanismes et des contrôles, pas le coût total de leur conception, des exceptions, des rapprochements, des incidents et du support.

Énoncer ces absences ne réduit pas la valeur des sources. Cela évite qu’un fait technique précis soit transformé en promesse juridique ou commerciale qu’il ne contient pas.

La conclusion qui résiste au rapprochement des couches

Une fois les limites posées, l’ensemble est cohérent. NTT dit que NTT Communications Corporation est devenue NTT DOCOMO BUSINESS, Inc. le 1er juillet 2025. La réponse de registre APNIC-JPNIC relie AS4713, OCN et le nouveau nom dans son propre périmètre. RIPEstat montre une identité de routage observée à une date et selon une méthode explicites. Une relation origine-préfixe testée est revenue valide. Une documentation de produit cite AS4713 du côté OCN et publie des contrôles précis. JPNAP relie le nouveau nom, OCN et AS4713 à Tokyo et Osaka.

PeeringDB conserve une ancienne étiquette et des champs qu’il ne faut pas prendre pour une télémétrie en direct.

AS4713 constitue donc un repère opérationnel durable. Il ne devient pas pour autant un certificat global de propriété, de continuité ou de qualité. Son utilité dépend de personnes capables d’entretenir les contacts, les autorisations, les politiques et la correspondance entre les identités.

Pour un lecteur non spécialiste, la conclusion est simple : les registres et observations permettent de reconnaître une identité de routage OCN associée à AS4713 dans les limites indiquées. Ils ne permettent pas d’ajouter automatiquement toutes les affirmations commerciales, juridiques ou de performance que l’on pourrait placer à côté du nom NTT.

NTT DOCOMO BUSINESS et AS4713 : ce qu’une identité réseau prouve encore après un changement de nom

Pourquoi c'est important