Synthèse

  • AS142130 était visible sur 321 des 322 pairs IPv6 de RIPE RIS le 15 juillet 2026 à 08:00 UTC, annonçant cinq préfixes IPv6 et aucun espace IPv4. C'est une preuve solide d'une empreinte de routage active, pas d'une flotte d'hébergement commerciale.
  • L'opérateur déclare qu'AS142130 et AS142282 sont utilisés pour son réseau domestique, son accès IPv6 personnel et ses technologies expérimentales, le tout construit comme une superposition logicielle définie par tunnel. Cette description de première main l'emporte sur les étiquettes de catégorie appliquées par les annuaires réseau tiers.
  • PeeringDB répertorie quatre connexions opérationnelles à des points d'échange IPv6, mais aucune installation associée, tandis que le réseau ne divulgue ni trafic ni portée géographique. Un port d'échange virtuel ou distant ne peut être considéré comme une preuve que NICHONET possède du matériel dans la ville indiquée de l'échange.
  • Les registres publics ne révèlent aucun nombre de serveurs, d'inventaire de baies, d'allocation électrique, de pool de stockage, de contrat client, d'engagement de niveau de service, d'objectif de restauration, d'équipe de support ou de capacité commercialisable. Toute affirmation selon laquelle NICHONET vend des services d'hébergement reste donc invérifiée.

Le fait le plus important est l'inadéquation

Le 15 juillet 2026 à 08:00 UTC, un collecteur de routes pouvait voir cinq préfixes IPv6 annoncés par AS142130. PeeringDB montrait le même système autonome sur quatre fabrics d'échange, avec des vitesses de port allant de 1 Gbit/s à 10 Gbit/s. Une adresse du bloc 2a0e:b107:1204::/48 a répondu à une mesure externe depuis Chicago. Lus rapidement, ces faits peuvent ressembler aux contours d'un petit fournisseur d'infrastructure international.

Ils n'en sont pas. Il s'agit de la preuve d'une superposition routée.

La distinction devient inévitable dans lecurriculum vitaede l'opérateur lui-même. Chenkai (Nicholas) Wang déclare être le seul opérateur d'AS142130 et AS142282, utilisant ces réseaux pour son réseau domestique et son accès IPv6 personnel, et y exécutant des technologies expérimentales. Il décrit une superposition logicielle définie par tunnel, des présences à plusieurs points d'échange Internet et sites de peering privé, ainsi que du transit IPv6 vers un réseau en aval. Ce récit est précis, techniquement plausible et cohérent avec les données de routage publiques. Il ne décrit pas une entreprise d'hébergement avec personnel, un parc de serveurs ou un cloud orienté client.

Cela importe parce que le nom enregistré, NICHONET Inter-Continental Hosting Operation Network, contient trois implications qui nécessitent des preuves distinctes. « Inter-Continental » suggère une géographie. « Hosting Operation » suggère des équipements et des services. « Network » suggère le routage, qui est la seule implication fortement étayée par les preuves. Les deux premières ne peuvent être déduites de la troisième.

Le résultat n'est pas que NICHONET est fictif ou inactif. AS142130 est manifestement actif. Le résultat est plus restreint et plus utile: les preuves publiques étayent l'existence d'un réseau IPv6 personnel et expérimental, avec une visibilité de routage mondiale réelle, plusieurs points d'interconnexion logiques et plus d'un fournisseur de transit en amont observé. Elles ne soutiennent pas la proposition plus forte selon laquelle l'entité contrôle une plateforme d'hébergement physique intercontinentale. Pour tout utilisateur envisageant d'en dépendre, cette limite de preuve est le point de départ.

Identité: un objet réseau enregistré, pas une forme juridique vérifiée

L'enregistrementAPNIC RDAP pour AS142130indique NICHONET Inter-Continental Hosting Operation Network comme titulaire, marque le numéro comme actif, enregistre une date de création au 28 avril 2021 et identifie les États-Unis comme pays. L'enregistrement d'organisation associé est de type « OTHER », pas une classification de société. Nicholas Wang est le contact administratif et technique nommé. L'enregistrement établit donc qui est responsable de la ressource de numéros Internet; il n'établit pas la constitution en société, les employés, le chiffre d'affaires ou la propriété de bâtiments et de serveurs.

L'adresse administrative est à Champaign, dans l'Illinois. Lesite personnelde l'opérateur indique qu'il est doctorant en informatique à l'université de l'Illinois à Urbana-Champaign et publie une biographie de recherche et d'enseignement, pas un catalogue d'hébergement. L'ancien domaine NICHONET,nicho1as.wang, redirige vers ce site personnel. Une adresse d'enregistrement est un lieu où les notifications peuvent atteindre le détenteur de la ressource. Elle ne constitue pas, sans preuve d'installation corroborante, un point de présence, une salle de données ou un point d'atterrissage de câble.

Il existe également une frontière de parrainage. L'enregistrement de système autonome APNIC identifie ORG-ASL11-AP comme organisation de parrainage. L'entrée d'organisation d'APNIC nomme ce sponsor Aperture Science Limited, un LIR à Hong Kong. Le parrainage peut fournir la voie d'adhésion et administrative par laquelle une ressource de numéro est enregistrée. Cela ne fait pas du sponsor l'opérateur de NICHONET, et ne prouve pas un lien physique entre Hong Kong et le réseau.

Inversement, l'existence d'un sponsor signifie que l'enregistrement ASN seul ne doit pas être interprété comme une preuve que NICHONET est membre d'APNIC avec sa propre infrastructure d'allocation.

Aucune forme juridique vérifiée n'est visible dans ces enregistrements. Cette absence doit être énoncée comme une inconnue, et non transformée en affirmation qu'aucune entité juridique n'existe. Un futur dépôt de société, contrat, enregistrement fiscal ou accord de service pourrait régler la question. Jusqu'à ce qu'un tel document soit produit, l'identité défendable est l'organisation de réseau enregistrée associée à AS142130 et opérée, selon le témoignage de l'opérateur, par une seule personne.

L'étiquette institutionnelle dans l'aperçu est une classification de navigation publique pour ce rapport. Elle n'établit pas que NICHONET est constituée en société, enregistrée comme institution formelle ou opère comme une entreprise commerciale.

Ce qui fonctionne réellement le 15 juillet 2026

La source la plus fiable sur l'état actuel est la vueRIPEstat routing-status. Lors de son observation à 08:00 UTC le 15 juillet, 321 des 322 pairs IPv6 de RIPE RIS voyaient AS142130. Aucun pair IPv4 ne le voyait car le système autonome n'annonçait aucun espace IPv4. La vue comptabilisait cinq préfixes IPv6, équivalant en termes d'espace d'adressage à vingt-et-un réseaux /48. La première route observée associée à cet ASN remonte à avril 2021.

La vue complémentaireannounced-prefixesa identifié ces cinq origines durant la fenêtre de deux semaines précédente:

  • 2404:f4c0:fa80::/44
  • 2602:feda:b42::/47
  • 2602:feda:b44::/48
  • 2a0e:b107:1200::/48
  • 2a0e:b107:1204::/48

Quatre avaient une visibilité continue sur cette fenêtre dans les chronologies retournées. La route 2a0e:b107:1200::/48 était absente d'une partie de la période et est réapparue le 9 juillet. Ceci est une preuve de disponibilité de route aux collecteurs, pas un enregistrement d'incident. Cela ne révèle pas si la coupure était planifiée, locale, liée au fournisseur amont, filtrée chez certains observateurs ou matérielle pour un utilisateur.

Lavue des voisins RIPEstata observé trois voisins de gauche: AS20473, The Constant Company; AS53667, FranTech Solutions; et AS58057, Securebit. Leséchantillons de chemins BGPactuels montraient des routes atteignant AS142130 via AS20473 et AS53667. C'est une preuve significative que l'ASN n'est pas visible mondialement via un seul fournisseur logique au moment de l'observation.

Cela ne prouve toujours pas trois entrées physiquement diverses vers un même bâtiment. Une adjacence BGP peut être fournie par un tunnel, une machine virtuelle, un revendeur, la même fibre métropolitaine, la même conduite de câbles, ou une infrastructure qui partage finalement l'alimentation et le commutateur. Les chemins AS expriment des relations de routage et de propagation, pas des plans d'étage. Laspécification BGPdéfinie par la RFC 4271 décrit les informations de chemin échangées entre systèmes autonomes; elle ne transforme pas ces chemins en une carte de gaines, de baies ou de sous-stations.

L'état opérationnel correct est donc précis: AS142130 était actif et largement visible en IPv6 au moment de la mesure. Son statut d'hébergement physique, de service client et sa capacité à survivre à une défaillance de sous-réseau commune restent inconnus.

Cinq préfixes représentent une portée d'adressage, pas une capacité d'hébergement

Le total d'adresses semble spectaculaire si on l'étend. Un /44 contient seize /48; un /47 en contient deux; chacun des trois /48 restants contribue pour un. Cela donne vingt-et-un équivalents /48 et un nombre astronomique d'adresses IPv6 individuelles. Certaines pages de recherche commerciales traduisent cette arithmétique en septillions d'adresses. Le chiffre est mathématiquement défendable et opérationnellement trompeur.

IPv6 a été conçu pour que les réseaux reçoivent de larges plages d'adresses et puissent préserver un adressage hiérarchique. L'architecture d'adressage IPv6explique la structure; elle n'assigne pas un serveur, une machine virtuelle ou un client à chaque adresse possible. Un simple routeur basse consommation peut annoncer un très grand préfixe IPv6. La plupart des adresses peuvent rester inutilisées indéfiniment. Le nombre d'adresses ne dit rien directement sur les cœurs de processeur, la mémoire, le stockage, les unités de baie, le refroidissement, la consommation électrique, la main-d'œuvre de support ou la demande client.

Les cinq origines NICHONET ne fournissent donc aucune mesure de la capacité d'hébergement commercialisable. Les sources publiques ne divulguent aucune des unités qui rendraient une telle mesure possible. Il n'y a pas de décompte de serveurs physiques ou d'instances virtuelles; pas d'engagement de baie ou de rack; pas d'allocation en kilowatts ou mégawatts; pas de pool de stockage; pas d'inventaire installé contre disponible; pas de politique de sursouscription; et pas de registre de réservation.

Il n'existe même pas de page produit publique spécifiant si un service potentiel serait un serveur privé virtuel, du bare metal, de la colocation, du transit, un tunnel ou une application gérée.

La même prudence s'applique aux vitesses nominales de port d'échange dans PeeringDB. Un enregistrement indique 10 Gbit/s à TOHU IX, tandis qu'EVIX, ZXIX Wuhan (L) et MoeIX SEA affichent chacun 1 Gbit/s. Les additionner pour obtenir 13 Gbit/s serait erroné. Ce sont des champs de profil de port sur des fabrics d'échange distincts. Ils ne révèlent pas le débit soutenu, les engagements de transit amont, les goulots d'étranglement dans les tunnels, les limites de traitement des paquets, les allocations client ni si les ports transportent un trafic significatif. PeeringDB n'enregistre aucun niveau de trafic divulgué pour AS142130.

La capacité installée n'est pas non plus la capacité utilisable. Même si une interface logique à 10 Gbit/s est configurée, les performances peuvent être limitées par la sous-couche chiffrée ou encapsulée, le CPU d'un routeur virtuel, un accès résidentiel ou universitaire, une machine virtuelle hébergée, le serveur de routes, ou le chemin vers l'application. Sans mesures et topologie, le chiffre est un plafond de configuration dans un enregistrement autodéclaré, pas une garantie de service.

Quatre enregistrements d'échange ne localisent pas quatre installations NICHONET

Leprofil PeeringDB pour AS142130répertorie quatre connexions d'échange IPv6: EVIX, TOHU IX, ZXIX Wuhan (L) et MoeIX SEA. Les étiquettes de ville attachées aux enregistrements d'échange couvrent Fremont, Guangzhou, Wuhan et Seattle. C'est l'endroit le plus tentant pour transformer une présence logique en une carte physique intercontinentale. Le profil lui-même fournit la raison de ne pas le faire: NICHONET n'a aucune association d'installation dans PeeringDB.

Une connexion d'échange enregistre l'accessibilité à un fabric de peering partagé. Elle peut être locale, distante ou tunnelisée. EVIX rend cette distinction exceptionnellement explicite. SaFAQ officielleindique que l'échange est virtuel et n'a pas de véritable emplacement; les pairs distants se connectent en utilisant un tunneling de couche 2 sans présence physique. EVIX a également des options de connexion physique et hébergée dans des installations particulières, mais un enregistrement de membre EVIX seul ne révèle pas quelle méthode un réseau donné utilise. L'enregistrement NICHONET PeeringDB nomme le fabric et une adresse IPv6, pas un rack ou un cross-connect NICHONET.

La description de l'opérateur résout une grande partie de l'ambiguïté. Son CV dit qu'il a conçu, implémenté et déployé une superposition logicielle définie par tunnel, puis est apparu à plusieurs échanges et sites de peering privé. Cette formulation est cohérente avec des connexions logiques distantes. Ce n'est pas une preuve que chaque port actuel est tunnelisé, et il ne faut pas l'étendre aussi loin. C'est une preuve que la topologie tunnelisée est centrale dans l'architecture propre du réseau.

TOHU IX et MoeIX SEA affichent chacun zéro installation dans leurs enregistrements d'échange PeeringDB, tout comme ZXIX Wuhan (L). L'étiquette « (L) » peut suggérer un fabric logique, mais la lettre ne doit pas être décodée au-delà de ce que l'opérateur publie. Les enregistrements établissent des adresses de LAN de peering configurées et des vitesses nominales. Ils n'identifient pas de routeurs appartenant à NICHONET, de contrats de colocation, de commandes de cross-connect ou d'adresses physiques en Chine ou à Seattle.

Par conséquent, la carte qui peut être tracée est logique: un système autonome enregistré dans l'Illinois, des enregistrements de fabric d'échange étiquetés dans deux villes américaines et deux villes chinoises, une visibilité de routage IPv6 mondiale, et des chemins amont via au moins deux grands réseaux au moment de l'observation. La carte physique n'est pas résolue. Aucune source n'établit où les routeurs d'origine s'exécutent, où les tunnels se terminent, où une charge de serveur se trouve, ou si deux chemins logiques partagent un hôte, un lien d'accès ou une source d'alimentation.

Le site web se situe en dehors de la preuve de l'hébergement NICHONET

Un site web fournisseur peut être une preuve opérationnelle utile lorsque son DNS, ses certificats, ses points de terminaison de service et son chemin réseau sont liés à l'infrastructure du fournisseur. Ici, la présence web publique pointe dans l'autre direction. Le domaine nicho1as.wang redirige vers nicholas.wang, qui sert un site académique personnel. Durant cette revue, ses adresses publiques appartenaient au réseau de Cloudflare et ses en-têtes de réponse indiquaient une diffusion par Cloudflare avec une origine GitHub Pages. La page n'était pas servie depuis une adresse annoncée par AS142130.

Cela ne signifie pas qu'AS142130 n'héberge rien. Les opérateurs placent souvent des sites publics derrière des réseaux de diffusion de contenu, et une origine cachée peut se trouver n'importe où. Cela signifie que le site web visible ne peut pas être compté comme une charge de travail d'hébergement NICHONET démontrée. Il n'y a pas de sélecteur de produit, de formulaire de commande, de grille tarifaire, de portail client, de page d'état réseau, de politique d'utilisation acceptable, d'accord de traitement des données, d'engagement de support ou de description de service sur le site personnel.

La meilleure application visible associée à l'opérateur est b23.wtf, un service de redirection avec suppression de pistage décrit sur son site et son dépôt de code public. Cela démontre une expérience en logiciel et en opérations. Cela n'établit toujours pas que NICHONET vend de l'infrastructure à des clients, et son arrangement de diffusion public ne peut être présumé utiliser AS142130. Un projet peut être opéré par la même personne sans être un produit de l'organisation de réseau enregistrée.

La classification par des tiers doit donc être traitée avec prudence. IPinfo classe l'ASN comme entreprise ou hébergement et rapporte zéro domaine hébergé dans son résumé actuel. Un autre service de recherche l'appelle espace de centre de données, d'hébergement web ou de transit. Ces étiquettes sont des classifications dérivées, souvent basées sur les noms de registre et le routage observé. Elles entrent en conflit avec la déclaration spécifique de l'opérateur d'un usage personnel et expérimental.

L'observation de zéro domaine est un signal faible utile, pas un recensement complet: les services IPv6 peuvent manquer de domaines indexés, se trouver derrière d'autres réseaux ou être invisibles à la méthode du fournisseur.

La question commercialement importante reste sans réponse: quel service un client externe peut-il acheter, sous quelles conditions, sur quel équipement? Aucune source publique trouvée dans cette revue n'y répond.

AS142282 complique l'identité mais ne crée pas un groupe d'hébergement

L'opérateur associe AS142130 à AS142282 dans son CV. L'enregistrementAPNIC RDAP pour AS142282nomme le réseau NICHONET-NG, liste Nicholas Wang comme contact administratif et technique, et enregistre un titulaire différent: Wuhan LSHIY Network Technology Co., Ltd. L'enregistrement est actif et date de mai 2021. Ces faits démontrent une administration technique commune; ils ne démontrent pas, en eux-mêmes, une propriété d'entreprise commune.

La relation importe parce que l'un des cinq préfixes maintenant annoncés par AS142130, 2404:f4c0:fa80::/44, est enregistré par APNIC sous le nom NICHONET-NG. L'enregistrement d'adresseidentifie Nicholas Wang dans les rôles techniques et administratifs. Le 15 juillet 2026, RIPE RIS voyait AS142130 annoncer ce bloc, et la validation d'origine de route RIPEstat a retourné une autorisation valide pour AS142130.

C'est un bon exemple de pourquoi l'enregistrement d'adresse, l'annonce de route et la propriété d'organisation doivent rester séparés. Le nom d'enregistrement du préfixe le lie au réseau de « nouvelle génération ». Une autorisation d'origine de route valide permet à AS142130 de l'annoncer. Aucun de ces faits ne dit où l'équipement se trouve, si le préfixe est utilisé pour des clients, si la ressource est louée ou assignée sous un autre accord, ou si les deux organisations enregistrées ont une relation légale au-delà de l'administration technique partagée.

La même retenue s'applique à l'appartenance à un AS-set et aux références en aval. L'opérateur dit fournir du transit IPv6 à un réseau en aval, mais ne l'identifie pas dans le CV. Certains annuaires de routage affichent de nombreux pairs ou membres d'AS-set. Un pair échange des routes; un aval reçoit du transit; un AS-set est un objet de politique de routage. Aucun ne devient automatiquement une filiale, un client avec un contrat payant ou une partie d'une flotte d'hébergement.

Pour l'analyse de dépendance, l'opérateur commun est significatif. Une seule personne administrant les deux systèmes autonomes peut créer un risque opérationnel partagé même lorsque les titulaires de registre diffèrent. Pour l'analyse d'entreprise, l'opération commune n'est pas suffisante. Des contrats, des dépôts légaux ou une divulgation directe seraient nécessaires avant de dresser une structure de propriété.

L'autorisation de route n'est pas une certification de résilience

Trois des cinq origines observées avaient une autorisation d'origine de route valide dans lesvérifications RPKI de RIPEstat: 2404:f4c0:fa80::/44, 2a0e:b107:1200::/48 et 2a0e:b107:1204::/48. Les deux préfixes 2602:feda ont retourné « unknown » car aucune autorisation de validation n'a été trouvée. Inconnu ne signifie pas invalide. Cela signifie que la validation d'origine de route ne fournit pas de réponse cryptographique affirmative pour ces annonces.

RPKI est précieux car il permet à un détenteur de ressource d'autoriser quel système autonome peut annoncer un préfixe. L'architecture définie dans la RFC 6480concerne la sécurité du routage et l'autorisation. Un résultat valide ne certifie pas que les paquets atteignent un serveur sain, que la route est courte, que l'alimentation reste allumée, qu'une sauvegarde existe ou que les données client peuvent être restaurées. Un résultat inconnu ne prouve pas un détournement ou une panne.

Le résultat partagé crée un point de vigilance opérationnel. Si les réseaux rejettent de plus en plus les routes invalides et préfèrent les politiques validées, maintenir des autorisations complètes et correctes réduit le risque d'accessibilité évitable. Les deux préfixes inconnus de NICHONET ne sont pas actuellement invalides, mais leur protection est plus faible dans cette dimension que les trois origines valides. Les archives publiques ne divulguent pas qui maintient les autorisations, comment les changements sont examinés ou quelle procédure de retour existe après une mise à jour erronée.

La visibilité de route a une limite similaire. Voir une origine depuis presque chaque pair IPv6 de RIS est une preuve forte que le plan de contrôle s'est propagé mondialement. Cela ne mesure pas la perte de paquets, la latence, la gigue ou le succès applicatif. Une route peut rester visible tandis que l'hôte derrière elle tombe en panne. Inversement, une route peut disparaître d'un collecteur tandis que les utilisateurs finaux ailleurs conservent le service. Une affirmation sérieuse de disponibilité nécessite à la fois des preuves du plan de contrôle et du plan de données dans le temps.

Aucun engagement de niveau de service public NICHONET, aucune série historique de disponibilité ou ensemble de sondes indépendant n'a été trouvé. Le réseau est visible maintenant; sa distribution de fiabilité et ses performances de récupération restent inconnues.

La diversité des fournisseurs amont logiques peut toujours partager une défaillance physique unique

Les données actuelles sur les voisins sont meilleures qu'une image de fournisseur unique. AS20473, AS53667 et AS58057 apparaissaient comme voisins observés dans RIPEstat, tandis que les chemins échantillonnés montraient les deux premiers transportant des origines NICHONET. Plusieurs systèmes autonomes en amont peuvent réduire l'exposition à une erreur de politique de routage, à un événement de maintenance ou à une résiliation commerciale d'un même fournisseur. Ils peuvent également offrir des chemins de propagation alternatifs lorsqu'une session tombe.

Mais la question physique n'est pas combien de numéros d'AS apparaissent. C'est où chaque session se termine et ce qu'elle traverse avant d'atteindre le routeur d'origine. Deux tunnels peuvent commencer sur la même machine virtuelle. Deux fournisseurs de transit peuvent entrer dans le même hôte sur une seule interface. Des sessions d'échange séparées peuvent dépendre d'un seul circuit haut débit. Les fournisseurs peuvent partager une fibre métropolitaine, une entrée de bâtiment, un commutateur, un opérateur de peering distant, un hyperviseur ou une alimentation électrique. Rien dans le chemin AS n'expose ces points communs.

Les archives publiques ne montrent pas non plus si tous les préfixes sont annoncés via tous les fournisseurs amont. Les chemins échantillonnés différaient selon le préfixe et le collecteur. L'origine 2a0e:b107:1200::/48 incluait des entrées AS142130 répétées dans certains chemins, ce qui est cohérent avec l'utilisation du préfixage de chemin AS pour influencer le choix de route. C'est de la politique de routage, pas une distance physique ou un équipement supplémentaire. Un chemin affiché plus long peut être un signal de plan de contrôle délibéré.

La conception en tunnel du réseau introduit une autre dépendance de sous-couche. Un tunnel donne à un opérateur la flexibilité d'apparaître sur un fabric de couche 2 distant sans installer de routeur là-bas. Cela signifie aussi que la session de peering dépend du chemin Internet ordinaire transportant le tunnel. Si cette sous-couche tombe, le port de superposition peut disparaître même si le commutateur d'échange et le serveur de routes restent sains. Si plusieurs tunnels partagent la même connexion d'accès ou le même fournisseur d'hébergement, des emplacements d'échange nominalement séparés peuvent tomber ensemble.

Aucun diagramme de topologie, inventaire de circuits, contrat fournisseur ou test de disjonction de chemin n'est public. Par conséquent, l'affirmation la plus solide qui puisse être faite est « visibilité logique multi-fournisseurs en amont ». « Transit physiquement diversifié » et « redondance intercontinentale » ne sont pas vérifiés.

La chaîne de capacité n'a aucun début public

Un service d'hébergement commence par une chaîne d'engagements. Quelqu'un contrôle de l'espace dans une installation ou sur la plateforme d'un autre fournisseur. L'alimentation est installée et sauvegardée. Les ports réseau et le transit sont sous contrat. Les serveurs et le stockage sont installés. La capacité est réservée pour les opérations, les pannes et la croissance des clients. Une fonction de support peut remplacer le matériel défaillant et restaurer le service. Les conditions définissent qui supporte la perte quand un maillon se brise.

Pour NICHONET, les preuves publiques commencent près de la couche réseau et s'arrêtent là. Il y a des ressources d'adressage, un ASN, une visibilité de route, des enregistrements d'échange et des chemins amont. Il n'y a aucun premier maillon divulgué vers le calcul ou le stockage. La propriété des actifs est inconnue. La location de colocation est inconnue. La propriété des serveurs est inconnue. Le dispositif d'alimentation est inconnu. L'inventaire matériel et le stock de remplacement sont inconnus. Le système d'exploitation et la couche de virtualisation sont inconnus.

Les supports de sauvegarde, la rétention et les tests de restauration sont inconnus. Le nombre de clients et leur concentration sont inconnus.

Cela rend la « capacité disponible » impossible à calculer. La capacité de conception n'est pas publiée. La capacité installée n'est pas publiée. La capacité alimentée n'est pas publiée. La capacité opérationnelle n'est pas publiée. La capacité vendue et réservée n'est pas publiée. La capacité du service à continuer pendant une panne n'est pas publiée. Un port d'échange nominal est la seule unité de capacité conventionnelle visible, et il appartient à la couche d'interconnexion, où il ne peut répondre à aucune de ces questions.

Il n'y a également aucune preuve tarifaire publique. Le prix est important car il révèle l'unité commerciale: par CPU virtuel, par gigaoctet, par unité de rack, par mégabit, par tunnel ou par projet. Sans produit et unité de facturation, le terme « hébergement » dans le nom enregistré n'a pas de surface économique définie. Il peut s'agir d'une marque historique, d'une aspiration, d'un arrangement privé ou simplement d'un nom pour un réseau expérimental.

Cette constatation négative ne doit pas être enjolivée en allégation d'échec. Aucune preuve examinée ici ne montre que NICHONET a promis une capacité client et n'a pas réussi à la fournir. Les preuves montrent quelque chose de plus fondamental: un acheteur public ne peut pas vérifier qu'une offre d'hébergement existe.

L'économie de l'hébergement reste inobservable

L'expression « économie de l'hébergement » invite normalement à un calcul familier: coût de l'installation et de l'énergie, amortissement du matériel, engagement de bande passante, main-d'œuvre de support, utilisation, prix et attrition. Aucune de ces données n'est publique pour NICHONET. Tenter de les estimer à partir de l'ASN créerait une fausse précision.

Il existe un modèle à bas coût plausible pour un réseau de ce type. Un ASN personnel peut fonctionner sur une ou plusieurs machines virtuelles, des serveurs peu coûteux ou de petits routeurs. L'accès aux échanges par tunnel peut réduire le besoin de cross-connects physiques. Les ressources IPv6 peuvent être parrainées ou assignées via des fournisseurs. Le peering ouvert peut échanger des routes sélectionnées sans relation de transit payant conventionnelle sur chaque lien. L'opérateur peut fournir sa propre main-d'œuvre.

Cette architecture peut soutenir un apprentissage précieux, de la recherche et une connectivité personnelle à une échelle bien inférieure à un budget de centre de données commercial.

La plausibilité n'est pas une preuve des factures réelles de NICHONET. Les archives publiques ne divulguent pas si le réseau paie des tarifs d'hébergement de détail, reçoit des services donnés, utilise la connectivité universitaire, s'appuie sur un accès résidentiel, achète du transit, échange du transit réciproque, ou combine plusieurs arrangements. Le CV de l'opérateur confirme la conception et le but de la superposition, mais pas les fournisseurs, les factures ou les conditions des ressources. Même la relation de parrainage APNIC est une preuve administrative; elle ne révèle pas les frais ou le bouquet de services.

Les revenus sont encore moins visibles. Un réseau en aval peut recevoir du transit IPv6, pourtant le CV ne dit pas si cette relation est payante, réciproque, expérimentale ou offerte à un ami. Les pairs d'échange ne sont pas des clients simplement parce que des routes sont échangées. Les adresses réactives ne sont pas des instances facturables. Un AS-set n'est pas une liste de ventes. Sans offre ou contrat publié, aucun chiffre public ne peut soutenir un revenu récurrent annuel, une utilisation, une marge brute ou une concentration client.

Cette distinction change la façon dont une défaillance se propagerait économiquement. Sur une plateforme commerciale, une panne peut déclencher des avoirs, de l'attrition, des transactions perdues et des coûts de support. Dans un réseau de recherche personnel, l'effet financier direct peut être faible tandis que l'effet technique sur les expériences ou la connectivité dépendante est significatif. Les preuves publiques de NICHONET soutiennent plus clairement ce dernier contexte. Attribuer une économie d'hébergement d'entreprise exagérerait à la fois la capacité et la responsabilité.

Il n'y a également aucune base pour une évaluation des ressources d'adressage en tant qu'actifs opérationnels. Les préfixes IPv6 sont enregistrés ou assignés selon des politiques et des arrangements de fournisseurs; le nombre étendu d'adresses n'est pas un inventaire de biens vendables. L'actif pertinent est la configuration fonctionnelle, les relations, la compétence opérationnelle et la continuité d'accès aux ressources. La plupart de cette valeur est concentrée chez l'opérateur et ne peut être mesurée à partir des tables de routage.

Pour un acheteur, l'économie manquante se traduit par des questions contractuelles. Qui facture? Quelle unité de service apparaît sur la facture? Quelle entité possède l'équipement ou a le droit de le revendre? Quels coûts de fournisseur amont et d'installation pourraient forcer une révision des prix ou une résiliation? Y a-t-il une période de remboursement, d'avoir ou de préavis? Qu'advient-il des adresses et des données à la fin de l'arrangement? Jusqu'à ce que ces réponses existent, le réseau ne doit pas être modélisé comme un fournisseur d'hébergement conventionnel.

L'approvisionnement doit tester le service, pas le nom

Un utilisateur potentiel peut résoudre la plupart des incertitudes sans exiger des secrets commerciaux. La première demande devrait être une définition de produit en une phrase. « Transit IPv6 livré par tunnel », « une machine virtuelle sur une plateforme tierce nommée », « hébergement géré sur du matériel appartenant à l'opérateur » et « accès expérimental sans engagement de service » sont des produits matériellement différents. Chacun a une frontière d'actif et un chemin de défaillance différents.

La partie contractante doit ensuite faire correspondre les preuves d'enregistrement. APNIC nomme NICHONET comme une organisation de type OTHER et un individu comme ses contacts techniques et administratifs. Si un contrat nomme une autre entreprise, le vendeur doit expliquer son autorité à utiliser AS142130, allouer des adresses et soutenir la charge de travail. Si l'arrangement est personnel, cela doit être explicite pour que le client ne suppose pas une continuité d'entreprise qui n'a pas été offerte.

L'emplacement doit être répondu au niveau de la couche de travail. Une étiquette d'échange est insuffisante. Une réponse utile identifie le pays et l'installation ou le fournisseur d'infrastructure où le calcul et le stockage s'exécutent, les emplacements des répliques et des sauvegardes, et les juridictions depuis lesquelles les administrateurs peuvent y accéder. Si le produit est uniquement du transit, la réponse doit identifier les points de terminaison de tunnel et les fournisseurs de sous-couche au lieu d'impliquer que les données sont stockées à l'échange.

La capacité doit être énoncée en unités client et limites mesurées. Pour un serveur virtuel, cela signifie cœurs, mémoire, stockage, gestion de la bande passante et toute politique de sursouscription. Pour le transit, cela signifie débit garanti, rafale, hypothèses de taille de paquet, surcoût de tunnel et chemin attendu. Pour la colocation, cela signifie unités de rack, alimentation et cross-connects. Une vitesse de port PeeringDB ne peut se substituer à aucune de ces données.

Les questions de continuité devraient couvrir à la fois la technologie et les personnes. Le client doit demander quelles pannes déclenchent un fournisseur amont alternatif, si l'alternative utilise un hôte et un circuit d'accès différents, qui peut récupérer les identifiants, comment les configurations sont sauvegardées, et à quelle vitesse le matériel ou l'infrastructure virtuelle défaillant peut être remplacé. Une démonstration de basculement est plus persuasive qu'une liste de numéros d'AS.

Enfin, la voie de sortie doit être connue avant le déploiement. Le format d'exportation des données, le contrôle DNS, la renumérotation des adresses, le préavis de résiliation et la récupération des sauvegardes déterminent si une défaillance d'un petit fournisseur devient une défaillance durable pour le client. Aucune condition de migration de ce type n'est publique pour NICHONET. Cela ne rend pas un arrangement privé inutilisable; cela signifie que l'utilisateur doit obtenir et évaluer directement les conditions plutôt que d'emprunter de la confiance au nom mondialement visible du réseau.

Les chemins de défaillance commencent par le modèle d'opérateur unique

Le témoignage de première main de l'opérateur est exceptionnellement utile car il identifie une surface de contrôle claire. Il est le seul opérateur des deux systèmes autonomes nommés. Cela peut rendre un petit réseau expérimental cohérent: une personne comprend la conception, peut changer rapidement la politique et a peu de frais de coordination. Cela concentre également les identifiants, les connaissances opérationnelles, la réponse de surveillance et les décisions de récupération.

Si l'opérateur est indisponible, les questions sans réponse sont immédiates. Y a-t-il une autre personne avec un accès console? Les configurations sont-elles sauvegardées en dehors des hôtes en cours d'exécution? Un sponsor ou un fournisseur amont peut-il authentifier un changement d'urgence? Les identifiants de domaine, RPKI, registre, serveur de routes et serveur sont-ils séparés et récupérables? Y a-t-il un processus documenté pour le remplacement du matériel ou le traitement des abus? Les sources publiques n'offrent aucune réponse.

La description du réseau domestique ajoute des modes de défaillance possibles sans prouver une topologie spécifique. Si un routeur d'origine ou un point de terminaison de tunnel se trouve réellement à un domicile, l'alimentation locale, l'accès grand public et l'équipement des locaux pourraient devenir des dépendances. Le CV ne dit pas que chaque routeur est à la maison; il dit que les réseaux sont utilisés pour le réseau domestique et l'accès IPv6 personnel. Un point de terminaison hébergé peut transporter certaines ou toutes les routes.

La conclusion correcte est que la dépendance résidentielle est plausible et non résolue, pas établie pour chaque préfixe.

Au niveau du routage, une session amont peut échouer, un tunnel peut tomber, un serveur de routes d'échange peut dé-pairer un membre inactif, un filtre de route peut rejeter un préfixe modifié, ou une erreur d'autorisation peut rendre une origine invalide. Au niveau du service, une machine virtuelle, un disque ou une application peut échouer pendant que BGP reste sain. Au niveau administratif, le parrainage, la facturation, le renouvellement de domaine ou l'escalade d'abus peut interrompre une conception autrement fonctionnelle.

Les preuves de récupération sont absentes. Il n'y a pas d'objectifs publiés de temps ou de point de récupération, pas de test de basculement, pas de rapport de restauration et pas d'historique d'incident public lié à un service d'hébergement NICHONET. L'opérateur dit que le réseau a fonctionné de manière stable depuis 2020, mais AS142130 lui-même a été enregistré en avril 2021. La déclaration peut se référer au projet plus large ou à des travaux réseau antérieurs. C'est une preuve d'expérience de première main, pas un pourcentage de disponibilité mesuré pour cet ASN exact.

Qui pourrait être affecté

L'utilisateur le plus clairement exposé est l'opérateur lui-même. Le CV dit que le réseau fournit son accès IPv6 domestique et soutient des technologies expérimentales. Une panne prolongée pourrait donc affecter sa propre connectivité, ses environnements de recherche ou ses services personnels. Le site public démontre que son travail s'étend au-delà du routage, mais il ne divulgue pas quelles applications dépendent directement d'AS142130.

La deuxième dépendance visible est un réseau en aval non nommé qui, selon le même CV, reçoit du transit IPv6. Le transit signifie que NICHONET peut se trouver sur le chemin de ce réseau vers l'Internet IPv6 plus large. Si le réseau en aval n'a pas de route indépendante, la perte d'AS142130 ou de sa sous-couche pourrait supprimer son accessibilité. S'il est multi-hébergé, l'effet peut être plus faible. L'identité du réseau en aval, ses préfixes, son contrat, son cas d'usage et ses chemins alternatifs ne sont pas divulgués, donc l'impact ne peut être quantifié.

Les pairs d'échange peuvent également remarquer des changements de route, mais le peering ne signifie pas qu'ils dépendent de NICHONET pour une connectivité générale. Une session de serveur de routes ne peut échanger que les préfixes que chaque partie choisit d'annoncer. Perdre cette session peut supprimer un chemin direct tandis que le trafic bascule vers le transit. Le nombre de pairs affichés ne doit pas être converti en nombre de clients.

Aucune preuve n'identifie de clients d'hébergement payants, de domaines hébergés, de charges de travail d'entreprise ou de données réglementées sur l'ASN. Par conséquent, il n'y a aucun support pour des affirmations concernant les totaux de clients affectés, l'exposition à la perte de données, l'impact sur les revenus ou la concentration sectorielle. L'absence de domaines visibles chez IPinfo est cohérente avec un petit réseau expérimental, mais elle ne peut exclure des services privés ou des points de terminaison IPv6 que le fournisseur n'indexe pas.

Pour un utilisateur potentiel, l'implication pratique est la diligence raisonnable avant toute dépendance. Demandez l'entité de service exacte, le contrat, l'emplacement de déploiement, la conception amont, le contact de support, les conditions de sauvegarde et le chemin de sortie. Si la réponse est un service de tunnel ou de transit plutôt que de l'hébergement, évaluez-le comme tel. Si la réponse est un arrangement expérimental informel, adaptez les attentes et la sensibilité des données à cette réalité.

La localisation des données ne peut être déduite du pays de registre ou de la ville d'échange

L'aperçu classe le rapport dans une région mondiale parce que les routes du réseau sont visibles mondialement et que son nom revendique une portée intercontinentale. Cela n'établit pas une zone de service mondiale. PeeringDB lui-même laisse la portée géographique non divulguée. Le champ de pays États-Unis d'APNIC reflète le contexte de la ressource enregistrée. Il ne dit pas où chaque paquet est traité ou où les données stockées reposent.

De même, une ville d'échange est l'emplacement ou l'étiquette d'un fabric de peering, pas nécessairement le routeur membre. EVIX prend explicitement en charge les tunnels distants. TOHU IX, ZXIX Wuhan (L) et MoeIX SEA fournissent des adresses de peering mais aucune association d'installation NICHONET. Une superposition peut rendre un routeur logiquement adjacent à un échange distant tandis que le matériel reste dans une autre ville ou un autre pays.

La géolocalisation IP commerciale ajoute une autre couche d'incertitude. Lapage AS142130 d'IPinfoa rapporté des adresses réactives mesurées depuis Chicago et attribue l'ASN aux États-Unis. De telles mesures peuvent aider à tester l'accessibilité et la latence. Elles ne peuvent pas localiser précisément un point de terminaison de tunnel, prouver la juridiction légale d'un serveur ou identifier où les données client sont stockées. L'Anycast, le proxying, les fichiers de localisation obsolètes et les paramètres par défaut des fournisseurs peuvent tous séparer une ville inférée de l'hôte physique.

Les deux préfixes enregistrés par RIPE portent des noms descriptifs « NICHONET-US-EAST » et « NICHONET-US-IL ». L'enregistrement2a0e:b107:1204::/48indique US et IL; l'enregistrement2a0e:b107:1200::/48indique US-EAST. Ce sont des étiquettes utiles fournies par l'opérateur. Ce ne sont pas des coordonnées auditées, des contrats d'installation ou une preuve de résidence des données.

Par conséquent, aucun client ne devrait inférer de garanties de souveraineté ou de localité à partir des métadonnées réseau publiques. Une réponse valide nécessiterait les emplacements réels de calcul et de stockage du service, les sous-traitants, les chemins de réplication, les emplacements d'accès de support, le contrat applicable et le processus de suppression. Rien n'est public.

Quelles preuves changeraient l'évaluation

La conclusion actuelle est délibérément réversible. NICHONET pourrait démontrer une opération d'hébergement avec des preuves ordinaires et concrètes. Un catalogue de services daté définirait ce qui est vendu. Des conditions générales et une entité juridique responsable définiraient la partie contractante. Des lettres d'installation ou des attestations de fournisseur pourraient établir où les baies ou l'infrastructure virtuelle sont situées et si NICHONET les possède, les loue ou les revend. Des enregistrements de circuits et de topologie pourraient distinguer le peering distant de la présence physique.

Les preuves de capacité nécessiteraient des unités et des états. Pour le calcul, cela pourrait inclure les modèles de serveurs installés, les cœurs et la mémoire utilisables après réserve opérationnelle, les limites de virtualisation et l'allocation vendue actuelle. Pour le stockage, cela pourrait inclure la capacité brute et utilisable, le surcoût de réplication, la séparation des sauvegardes et les tests de restauration. Pour le réseau, cela pourrait inclure les engagements de transit, l'utilisation mesurée, les goulots d'étranglement des tunnels, l'historique de perte de paquets et les tests de défaillance.

Pour l'alimentation, cela pourrait inclure les kilowatts contractés, les alimentations A/B, la couverture par générateur et la responsabilité de maintenance.

Les revendications de résilience nécessiteraient une preuve d'indépendance. Deux noms de fournisseurs amont ne suffisent pas; NICHONET devrait montrer des points de terminaison, des opérateurs, des chemins, des équipements et des domaines d'alimentation séparés, ou divulguer où ces chemins convergent. Un exercice de récupération devrait montrer qu'un service se déplace ou se restaure dans un objectif déclaré. Une liste de support et une politique d'escalade répondraient au risque d'opérateur unique.

Les preuves sur les clients et le statut pourraient rester respectueuses de la vie privée. Des comptages agrégés de services actifs, des points de terminaison surveillés indépendamment, un historique de statut public et des résultats de récupération anonymisés seraient plus informatifs que de nommer des utilisateurs. Une déclaration claire selon laquelle le réseau est non commercial et expérimental résoudrait également l'ambiguïté, bien que dans la direction opposée: cela confirmerait que les attentes d'une entreprise d'hébergement sont mal placées.

Jusqu'à ce que de telles preuves apparaissent, les acheteurs et les chercheurs doivent garder trois étiquettes séparées. AS142130 est un système autonome IPv6 actif. NICHONET est le nom de l'organisation enregistrée qui lui est associée. Une flotte d'hébergement intercontinentale commerciale n'est pas démontrée publiquement.

Un petit réseau peut être réel sans être ce que son nom implique

NICHONET mérite du crédit pour ce que les preuves montrent. Faire fonctionner un système autonome, maintenir cinq origines IPv6, organiser plusieurs chemins amont, participer à des fabrics d'échange et garder une autorisation de route valide pour trois origines exigent un travail technique. La visibilité du réseau le 15 juillet 2026 était large. La volonté de l'opérateur de décrire l'objectif de réseau domestique et expérimental fournit un contexte d'une franchise inhabituelle.

Ce même contexte ferme la porte à une lecture gonflée. Le nom n'est pas une déclaration de capacité. Cinq préfixes ne sont pas cinq sites. Quatre enregistrements d'échange ne sont pas quatre installations. Trois voisins observés ne sont pas trois routes de fibre disjointes. Un champ de profil à 10 Gbit/s n'est pas 10 Gbit/s de débit client disponible. Une autorisation d'origine de route valide n'est pas un certificat de disponibilité. Un pays de registre américain n'est pas une garantie de résidence des données.

Le niveau de preuve pour le réseau lui-même est assez fort pour le qualifier d'actif. Le niveau de preuve pour l'hébergement orienté client est négatif: la description de première main la plus autorisée dit usage personnel et expérimental, tandis que les archives publiques ne fournissent aucun des actifs, produits, contrats, états de capacité ou engagements de récupération attendus d'un opérateur d'hébergement.

Pour NICHONET, l'histoire de l'infrastructure ne concerne donc pas un nuage miniature caché attendant d'être quantifié. Elle concerne comment une superposition IPv6 peut acquérir une visibilité de routage mondiale et des étiquettes d'interconnexion géographiquement suggestives sans acquérir une empreinte d'hébergement physique documentée. C'est une réalisation légitime d'ingénierie réseau. C'est aussi exactement pourquoi les preuves de routage ne doivent pas être sollicitées pour prouver plus qu'elles ne le peuvent.