NICHONET's five-prefix IPv6 footprint does not add up to a documented hosting fleet

Summary

• AS142130 was visible to 321 of 322 IPv6 peers in RIPE RIS at 08:00 UTC on 15 July 2026, originating five IPv6 prefixes and no IPv4 space. That is firm evidence of an active routing footprint, not evidence of a commercial hosting fleet.
• The named operator says AS142130 and AS142282 are used for a home network, personal IPv6 access and experimental technologies, built as a tunnel-based software-defined overlay. That first-party description outweighs category labels applied by third-party network directories.
• PeeringDB lists four operational IPv6 exchange attachments but no associated facilities, while the network discloses neither traffic nor geographic scope. A virtual or remote exchange port cannot be treated as proof that NICHONET owns hardware in the exchange's named city.
• Public records disclose no server count, rack inventory, power allocation, storage pool, customer contract, service-level commitment, restore objective, support roster or saleable capacity. Any claim that NICHONET sells hosting therefore remains unverified.

The most important fact is the mismatch

At 08:00 UTC on 15 July 2026, a routing collector could see five IPv6 prefixes originated by AS142130. PeeringDB showed the same autonomous system on four exchange fabrics with port labels ranging from 1 Gbps to 10 Gbps. An address in the 2a0e:b107:1204::/48 block answered an outside measurement from Chicago. Read quickly, those facts can resemble the outline of a small international infrastructure provider.

They are not that outline. They are evidence of a routed overlay.

The distinction becomes unavoidable in the operator's own curriculum vitae. Chenkai (Nicholas) Wang says he is the sole operator of AS142130 and AS142282, uses the networks for his home network and personal IPv6 access, and runs experimental technologies on them. He describes a tunnel-based software-defined overlay, appearances at multiple internet exchanges and private peering sites, and IPv6 transit to one downstream network. That account is specific, technically plausible and consistent with the public routing data. It does not describe a staffed hosting company, a server estate or a customer-facing cloud.

This matters because the registered name, NICHONET Inter-Continental Hosting Operation Network, contains three implications that require separate proof. “Inter-Continental” suggests geography. “Hosting Operation” suggests equipment and services. “Network” suggests routing, which is the one implication the evidence supports strongly. The first two cannot be inherited from the third.

The result is not that NICHONET is fictional or inactive. AS142130 is demonstrably active. The result is narrower and more useful: public evidence supports a personal, experimental IPv6 network with real global route visibility, multiple logical interconnection points and more than one observed upstream. It does not support the stronger proposition that the entity controls an intercontinental physical hosting platform. For any user considering dependence on it, that evidentiary boundary is the starting point.

Identity: a registered network entity, not a verified corporate form

The APNIC RDAP record for AS142130 names NICHONET Inter-Continental Hosting Operation Network as the registrant, marks the number active, records registration on 28 April 2021 and identifies the United States as its country. The associated organisation record uses the type “OTHER”, not a corporate classification. Nicholas Wang is the named administrative and technical contact. The record therefore establishes who is accountable for the internet number resource; it does not establish incorporation, employees, revenue or ownership of buildings and servers.

The administrative address is in Champaign, Illinois. The operator's personal site says he is a computer-science doctoral candidate at the University of Illinois Urbana-Champaign and publishes a research and teaching biography, not a hosting catalogue. The older NICHONET domain, nicho1as.wang, redirects to that personal site. A registration address is where notices can reach a resource holder. It is not, without corroborating facility evidence, a point of presence, a data hall or a cable landing.

There is also a sponsorship boundary. The APNIC autonomous-system record identifies ORG-ASL11-AP as sponsoring organisation. APNIC's organisation entry names that sponsor as Aperture Science Limited, an LIR in Hong Kong. Sponsorship can provide the membership and administrative route through which a number resource is registered. It does not make the sponsor the operator of NICHONET, and it does not prove a physical link between Hong Kong and the network. Conversely, the existence of a sponsor means the ASN record alone should not be read as proof that NICHONET is an APNIC member with its own allocation infrastructure.

No verified legal form is visible in these records. That absence should be stated as an unknown, not converted into a claim that no legal entity exists. A future corporate filing, contract, tax registration or service agreement could settle the matter. Until one is produced, the defensible identity is the registered network organisation associated with AS142130 and operated, by the operator's account, by one individual.

The institutional label in the Overview is a public navigation classification for this report. It does not establish that NICHONET is incorporated, registered as a formal institution or operating as a commercial company.

What is actually operating on 15 July 2026

The strongest current-status source is the RIPEstat routing-status view. At its 08:00 UTC observation on 15 July, 321 of 322 RIPE RIS IPv6 peers saw AS142130. No IPv4 peer saw it because the autonomous system originated no IPv4 space. The view counted five IPv6 prefixes, equivalent in address-space terms to twenty-one /48 networks. The first observed route associated with the ASN dates to April 2021.

The companion announced-prefixes view identified these five origins during the preceding two-week window:

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

Four had continuous visibility across that window in the returned timelines. The 2a0e:b107:1200::/48 route was absent from part of the period and reappeared on 9 July. This is evidence of route availability at the collectors, not an incident record. It does not reveal whether the gap was planned, local, upstream-related, filtered at some observers or material to any user.

The RIPEstat neighbour view observed three left-side neighbours: AS20473, The Constant Company; AS53667, FranTech Solutions; and AS58057, Securebit. Current BGP path samples showed routes reaching AS142130 through AS20473 and AS53667. This is meaningful evidence that the ASN is not globally visible through only one logical provider at the observation time.

It still does not prove three physically diverse entrances to one building. A BGP adjacency can be delivered over a tunnel, a virtual machine, a reseller, the same metro fibre, the same conduit, or infrastructure that ultimately shares power and switching. AS paths express routing relationships and propagation, not floor plans. RFC 4271's BGP specification defines the path information exchanged between autonomous systems; it does not turn those paths into a map of ducts, racks or substations.

The correct operating-status statement is therefore precise: AS142130 was active and widely visible over IPv6 at the measurement time. Its physical hosting status, customer-service status and ability to survive a common underlay failure remain unknown.

Five prefixes are address scope, not hosting capacity

The address total looks spectacular if expanded. A /44 contains sixteen /48s; a /47 contains two; each of the three remaining /48s contributes one. That produces twenty-one /48 equivalents and an astronomical number of individual IPv6 addresses. Some commercial lookup pages translate that arithmetic into septillions of addresses. The figure is mathematically defensible and operationally misleading.

IPv6 was designed so that networks receive large address ranges and can preserve hierarchical addressing. The IPv6 addressing architecture explains the structure; it does not assign one server, virtual machine or customer to every possible address. A single low-power router can originate a very large IPv6 prefix. Most addresses can remain unused forever. Address count says nothing direct about processor cores, memory, storage, rack units, cooling, power draw, support labour or customer demand.

The five NICHONET origins therefore provide no measure of saleable hosting capacity. Public sources disclose none of the units that would make such a measure possible. There is no count of physical servers or virtual instances; no cabinet or rack commitment; no kilowatt or megawatt allocation; no storage pool; no installed-versus-available inventory; no oversubscription policy; and no reservation ledger. There is not even a public product page specifying whether a potential service would be a virtual private server, bare metal, colocation, transit, tunnel or managed application.

The same caution applies to the nominal exchange-port speeds in PeeringDB. One record says 10 Gbps at TOHU IX, while EVIX, ZXIX Wuhan (L) and MoeIX SEA each show 1 Gbps. Adding them to obtain 13 Gbps would be wrong. These are port-profile fields on separate exchange fabrics. They do not reveal sustained throughput, upstream transit commits, bottlenecks in the tunnels, packet-processing limits, customer allocations or whether the ports carry material traffic. PeeringDB records no disclosed traffic level for AS142130.

Installed capacity is also not usable capacity. Even if a 10 Gbps logical interface is configured, performance may be constrained by the encrypted or encapsulated underlay, a virtual router's CPU, a residential or campus access circuit, a hosted virtual machine, the route server, or the path to the application. Without measurements and topology, the number is a configuration ceiling in a self-reported record, not a service guarantee.

Four exchange records do not locate four NICHONET facilities

The PeeringDB profile for AS142130 lists four IPv6 exchange attachments: EVIX, TOHU IX, ZXIX Wuhan (L) and MoeIX SEA. The city labels attached to the exchange records span Fremont, Guangzhou, Wuhan and Seattle. This is the most tempting place to turn logical presence into an intercontinental physical map. The profile itself supplies the reason not to do so: NICHONET has no facility associations in PeeringDB.

An exchange attachment records reachability to a shared peering fabric. It can be local, remote or tunnelled. EVIX makes that distinction unusually explicit. Its official FAQ says the exchange is virtual and has no true location; remote peers connect using Layer 2 tunnelling without a physical presence. EVIX also has physical and hosted connection options in particular facilities, but an EVIX membership record alone does not reveal which method a given network uses. The NICHONET PeeringDB record names the fabric and an IPv6 address, not a NICHONET rack or cross-connect.

The operator's description resolves much of the ambiguity. His CV says he designed, implemented and deployed a tunnel-based software-defined overlay, then appeared at multiple exchanges and private peering sites. That wording is consistent with remote logical attachments. It is not proof that every current port is tunnelled, and it should not be stretched that far. It is proof that tunnelled topology is central to the network's own architecture.

TOHU IX and MoeIX SEA each show zero facilities in their PeeringDB exchange records, as does ZXIX Wuhan (L). The “(L)” label may suggest a logical fabric, but the letter should not be decoded beyond what the operator publishes. The records establish configured peering-LAN addresses and nominal speeds. They do not identify NICHONET-owned routers, colocation contracts, cross-connect orders or street addresses in China or Seattle.

Consequently, the map that can be drawn is a logical one: an Illinois-registered autonomous system, exchange-fabric records labelled in two US and two Chinese cities, global IPv6 route visibility, and upstream paths through at least two large networks at the observation time. The physical map is unresolved. No source establishes where the origin routers run, where tunnels terminate, where any server workload sits, or whether any two logical paths share a host, access link or power source.

The website sits outside the proof of NICHONET hosting

A provider website can be useful operating evidence when its DNS, certificates, service endpoints and network path tie back to the provider's infrastructure. Here, the public web presence points in the other direction. The nicho1as.wang domain redirects to nicholas.wang, which serves a personal academic site. During this review, its public addresses belonged to Cloudflare's network and its response headers indicated Cloudflare delivery with a GitHub Pages origin path. The page was not served from an address originated by AS142130.

That does not mean AS142130 hosts nothing. Operators often place public sites behind content-delivery networks, and a hidden origin can sit anywhere. It means the visible website cannot be counted as a demonstrated NICHONET hosting workload. There is no product selector, order form, pricing schedule, customer portal, network-status page, acceptable-use policy, data-processing agreement, support commitment or service description on the personal site.

The best visible application associated with the operator is b23.wtf, a tracking-removal redirect service described on his site and public code repository. It demonstrates software and operations experience. It still does not establish that NICHONET sells infrastructure to customers, and its public delivery arrangement cannot be assumed to use AS142130. A project can be operated by the same person without being a product of the registered network organisation.

Third-party classification should therefore be treated cautiously. IPinfo classifies the ASN as business or hosting and reports zero hosted domains in its current summary. Another lookup service calls it data-centre, web-hosting or transit space. Those labels are derived classifications, often based on registry names and observed routing. They conflict with the operator's specific statement of personal and experimental use. The zero-domain observation is a useful weak signal, not a complete census: IPv6 services may lack indexed domains, sit behind other networks or be invisible to the vendor's method.

The commercially important question remains unanswered: what service can an external customer buy, under what terms, on what equipment? No public source found in this review answers it.

AS142282 complicates identity but does not create a hosting group

The operator associates AS142130 with AS142282 in his CV. APNIC's RDAP record for AS142282 names the network NICHONET-NG, lists Nicholas Wang as administrative and technical contact, and records a different registrant: Wuhan LSHIY Network Technology Co., Ltd. The record is active and dates from May 2021. These facts demonstrate common technical administration; they do not, by themselves, demonstrate common corporate ownership.

The relationship matters because one of the five prefixes now originated by AS142130, 2404:f4c0:fa80::/44, is registered by APNIC under the name NICHONET-NG. The address record identifies Nicholas Wang in the technical and administrative roles. On 15 July 2026, RIPE RIS saw AS142130 originating that block, and the RIPEstat route-origin validation returned a valid authorization for AS142130.

This is a good example of why address registration, route origination and organisation ownership must remain separate. The prefix's registration name links it to the “next generation” network. A valid route-origin authorization permits AS142130 to originate it. Neither fact says where the equipment is, whether the prefix is used for customers, whether the resource is leased or assigned under another agreement, or whether the two registered organisations have a legal relationship beyond shared technical administration.

The same restraint applies to AS-set membership and downstream references. The operator says he provides IPv6 transit to one downstream network, but does not identify it in the CV. Some routing directories display many peers or AS-set members. A peer exchanges routes; a downstream receives transit; an AS-set is a routing-policy entity. None automatically becomes a subsidiary, customer with a paid contract or part of a hosting fleet.

For dependency analysis, the common operator is material. A single person administering both autonomous systems can create shared operational risk even when the registry holders differ. For corporate analysis, common operation is not enough. Contracts, filings or direct disclosure would be needed before drawing an ownership structure.

Route authorization is not resilience certification

Three of the five observed origins had valid route-origin authorization in the RIPEstat RPKI checks: 2404:f4c0:fa80::/44, 2a0e:b107:1200::/48 and 2a0e:b107:1204::/48. The two 2602:feda prefixes returned “unknown” because no validating authorization was found. Unknown is not invalid. It means route-origin validation does not provide an affirmative cryptographic answer for those announcements.

RPKI is valuable because it lets a resource holder authorize which autonomous system may originate a prefix. The architecture defined in RFC 6480 is about routing security and authorization. A valid result does not certify that packets reach a healthy server, that the route is short, that the power remains on, that a backup exists or that customer data can be restored. An unknown result does not prove a hijack or outage.

The split result creates an operational watchpoint. If networks increasingly reject invalid routes and prefer validated policy, maintaining complete and correct authorizations reduces avoidable reachability risk. NICHONET's two unknown prefixes are not currently invalid, but their protection is weaker in this dimension than the three valid origins. The public record does not disclose who maintains the authorizations, how changes are reviewed or what rollback procedure exists after a mistaken update.

Route visibility has a similar limit. Seeing an origin from nearly every RIS IPv6 peer is strong evidence that the control plane has propagated globally. It does not measure packet loss, latency, jitter or application success. A route can remain visible while the host behind it fails. Conversely, a route can disappear from one collector while end users elsewhere retain service. A serious availability claim needs both control-plane and data-plane evidence over time.

No public NICHONET service-level commitment, historical uptime series or independent probe set was found. The network is visible now; its reliability distribution and recovery performance remain unknown.

Logical upstream diversity can still share one physical failure

The current neighbour data is better than a single-upstream picture. AS20473, AS53667 and AS58057 appeared as observed neighbours in RIPEstat, while sampled paths showed the first two carrying NICHONET origins. Multiple upstream autonomous systems can reduce exposure to one provider's routing-policy error, maintenance event or commercial termination. They can also offer alternate propagation paths when one session fails.

But the physical question is not how many AS numbers appear. It is where each session terminates and what it traverses before reaching the origin router. Two tunnels can start on the same virtual machine. Two transit providers can enter the same host over one interface. Separate exchange sessions can depend on one broadband circuit. Providers can share a metro fibre, building entrance, switch, remote-peering carrier, hypervisor or electricity supply. Nothing in the AS path exposes those common points.

The public records also do not show whether all prefixes are announced through all upstreams. Sampled paths differed by prefix and collector. The 2a0e:b107:1200::/48 origin included repeated AS142130 entries in some paths, consistent with AS-path prepending used to influence route choice. That is routing policy, not additional physical distance or equipment. A longer displayed path can be deliberate control-plane signalling.

The network's tunnel-based design introduces another underlay dependency. A tunnel gives an operator flexibility to appear on a remote Layer 2 fabric without installing a router there. It also means the peering session depends on the ordinary internet path carrying the tunnel. If that underlay fails, the overlay port may vanish even though the exchange switch and route server remain healthy. If several tunnels share the same access connection or hosting provider, nominally separate exchange locations may fail together.

No topology diagram, circuit inventory, provider contract or path-disjointness test is public. Therefore the strongest supportable statement is “logical multi-upstream visibility.” “Physically diverse transit” and “intercontinental redundancy” are unverified.

The capacity chain has no public beginning

A hosting service begins with a chain of commitments. Someone controls space in a facility or another provider's platform. Power is installed and backed up. Network ports and transit are contracted. Servers and storage are installed. Capacity is reserved for operations, failures and customer growth. A support function can replace failed hardware and restore service. Terms define who bears loss when any link breaks.

For NICHONET, the public evidence begins near the network layer and stops there. There are address resources, an ASN, route visibility, exchange records and upstream paths. There is no disclosed first link to compute or storage. Asset ownership is unknown. Colocation tenancy is unknown. Server ownership is unknown. The power arrangement is unknown. Hardware inventory and replacement stock are unknown. The operating system and virtualisation layer are unknown. Backup media, retention and restore testing are unknown. Customer count and concentration are unknown.

That makes “available capacity” impossible to calculate. Design capacity is not published. Installed capacity is not published. Powered capacity is not published. Operational capacity is not published. Sold and reserved capacity are not published. The service's ability to continue during a failure is not published. A nominal exchange port is the only conventional capacity unit visible, and it belongs to the interconnection layer, where it cannot answer any of those questions.

There is also no public pricing evidence. Price is important because it reveals the commercial unit: per virtual CPU, per gigabyte, per rack unit, per megabit, per tunnel or per project. Without a product and billing unit, “hosting” in the registered name has no defined economic surface. It may be historical branding, an aspiration, a private arrangement or simply a name for an experimental network.

This negative finding should not be embellished into a failure allegation. No evidence reviewed here shows that NICHONET promised a customer capacity and failed to deliver it. The evidence shows something more basic: a public buyer cannot verify that a hosting offer exists.

Hosting economics remain unobservable

The phrase “hosting economics” normally invites a familiar calculation: facility and power cost, hardware depreciation, bandwidth commit, support labour, utilisation, price and churn. None of those inputs is public for NICHONET. Trying to estimate them from the ASN would create false precision.

There is a plausible low-cost model for a network of this kind. A personal ASN can run on one or more virtual machines, inexpensive servers or small routers. Tunnelled exchange access may lower the need for physical cross-connects. IPv6 resources can be sponsored or assigned through providers. Open peering can exchange selected routes without a conventional paid-transit relationship on every link. The operator can contribute his own labour. This architecture can sustain valuable learning, research and personal connectivity at a scale far below a commercial data-centre budget.

Plausibility is not evidence of NICHONET's actual bills. The public record does not disclose whether the network pays retail hosting rates, receives donated services, uses academic connectivity, relies on residential access, buys transit, exchanges reciprocal transit, or combines several arrangements. The operator's CV confirms the overlay design and purpose, but not the vendors, invoices or resource terms. Even the APNIC sponsor relationship is administrative evidence; it does not reveal the fee or service bundle.

Revenue is still less visible. One downstream may receive IPv6 transit, yet the CV does not say whether that relationship is paid, reciprocal, experimental or offered to a friend. Exchange peers are not customers merely because routes are exchanged. Responsive addresses are not billable instances. An AS-set is not a sales list. Without a published offer or contract, no public number can support annual recurring revenue, utilisation, gross margin or customer concentration.

This distinction changes how a failure would propagate economically. In a commercial platform, an outage can trigger service credits, churn, lost transactions and support costs. In a personal research network, the direct financial effect may be small while the technical effect on experiments or dependent connectivity is meaningful. NICHONET's public evidence supports the latter context more clearly. Assigning enterprise-hosting economics would exaggerate both capacity and liability.

There is also no basis for a valuation of the address resources as operating assets. IPv6 prefixes are registered or assigned under policy and provider arrangements; the expanded count of addresses is not an inventory of saleable property. The relevant asset is the working configuration, relationships, operational skill and continuity of access to the resources. Most of that value is concentrated in the operator and cannot be measured from route tables.

For a buyer, the missing economics translate into contract questions. Who invoices? What service unit appears on the invoice? Which entity owns the equipment or has the right to resell it? What upstream and facility costs could force repricing or termination? Is there a refund, credit or notice period? What happens to addresses and data when the arrangement ends? Until those answers exist, the network should not be modelled as a conventional hosting supplier.

Procurement must test the service, not the name

A prospective user can resolve most of the uncertainty without demanding trade secrets. The first request should be a one-sentence product definition. “IPv6 transit delivered over a tunnel,” “a virtual machine on a named third-party platform,” “managed hosting on operator-owned hardware” and “experimental access with no service commitment” are materially different products. Each has a different asset boundary and failure path.

The contracting party should then match the registration evidence. APNIC names NICHONET as an organisation of type OTHER and one individual as its technical and administrative contact. If a contract names another company, the seller should explain its authority to use AS142130, allocate addresses and support the workload. If the arrangement is personal, that should be explicit so the customer does not assume corporate continuity that has not been offered.

Location should be answered at the workload layer. An exchange label is limited public evidence. A useful response identifies the country and facility or infrastructure provider where compute and storage run, the locations of replicas and backups, and the jurisdictions from which administrators can access them. If the product is only transit, the answer should identify tunnel endpoints and underlay providers instead of implying that data is stored at the exchange.

Capacity should be stated in customer units and measured limits. For a virtual server, that means cores, memory, storage, network shaping and any oversubscription policy. For transit, it means committed rate, burst, packet size assumptions, tunnel overhead and expected path. For colocation, it means rack units, power and cross-connects. A PeeringDB port speed cannot substitute for any of these.

Continuity questions should cover both technology and people. The customer should ask which failures trigger an alternate upstream, whether the alternate uses a different host and access circuit, who can recover credentials, how configurations are backed up, and how quickly failed hardware or virtual infrastructure can be replaced. A demonstration of failover is more persuasive than a list of AS numbers.

Finally, the exit route should be known before deployment. Data export format, DNS control, address renumbering, termination notice and backup retrieval determine whether a small provider failure becomes a lasting customer failure. No such migration terms are public for NICHONET. That does not make a private arrangement unusable; it means the user must obtain and evaluate the terms directly rather than borrowing confidence from the network's globally visible name.

Failure paths begin with the single-operator model

The operator's first-person account is unusually useful because it identifies a clear control surface. He is the sole operator of both named autonomous systems. That can make a small experimental network coherent: one person understands the design, can change policy quickly and bears little coordination overhead. It also concentrates credentials, operational knowledge, monitoring response and recovery decisions.

If the operator is unavailable, the unanswered questions are immediate. Is there another person with console access? Are configurations backed up outside the running hosts? Can a sponsor or upstream authenticate an emergency change? Are domain, RPKI, registry, route-server and server credentials separated and recoverable? Is there a documented process for hardware replacement or abuse handling? Public sources offer no answers.

The home-network description adds possible failure modes without proving a specific topology. If an origin router or tunnel endpoint actually sits at a residence, local power, consumer access and premises equipment could become dependencies. The CV does not say every router is at home; it says the networks are used for the home network and personal IPv6 access. A hosted endpoint may carry some or all routes. The correct conclusion is that residential dependency is plausible and unresolved, not established for every prefix.

At the routing layer, an upstream session can fail, a tunnel can drop, an exchange route server can de-peer an inactive member, a route filter can reject a changed prefix, or an authorization error can make an origin invalid. At the service layer, a virtual machine, disk or application can fail while BGP remains healthy. At the administrative layer, sponsorship, billing, domain renewal or abuse escalation can interrupt an otherwise functional design.

Recovery evidence is absent. There are no published recovery-time or recovery-point objectives, no failover test, no restore report and no public incident history tied to a NICHONET hosting service. The operator says the network has operated stably since 2020, but AS142130 itself was registered in April 2021. The statement may refer to the broader project or earlier network work. It is first-party experience evidence, not a measured uptime percentage for this exact ASN.

Who could be affected

The most clearly exposed user is the operator himself. The CV says the network provides his home IPv6 access and supports experimental technologies. A sustained failure could therefore affect his own connectivity, research environments or personal services. The public site demonstrates that his work extends beyond routing, but it does not disclose which applications depend directly on AS142130.

The second visible dependency is one unnamed downstream network that, according to the same CV, receives IPv6 transit. Transit means NICHONET can sit in that network's path to the wider IPv6 internet. If the downstream has no independent route, loss of AS142130 or its underlay could remove its reachability. If it is multihomed, the effect may be smaller. The downstream's identity, prefixes, contract, use case and alternate paths are not disclosed, so impact cannot be quantified.

Exchange peers may also notice route changes, but peering does not mean they depend on NICHONET for general connectivity. A route-server session can exchange only the prefixes each party chooses to announce. Losing that session may remove a direct path while traffic shifts to transit. The number of displayed peers must not be converted into a customer count.

No evidence identifies paying hosting customers, hosted domains, enterprise workloads or regulated data on the ASN. Consequently, there is no support for claims about affected customer totals, data loss exposure, revenue impact or sector concentration. The absence of visible domains at IPinfo is consistent with a small experimental network, but it cannot rule out private services or IPv6 endpoints that the vendor does not index.

For a prospective user, the practical implication is due diligence before dependency. Ask for the exact service entity, contract, deployment location, upstream design, support contact, backup terms and exit path. If the answer is a tunnel or transit service rather than hosting, evaluate it as such. If the answer is an informal experimental arrangement, match expectations and data sensitivity to that reality.

Data location cannot be inferred from registry country or exchange city

The Overview classifies the report in a global region because the network's routes are globally visible and its name claims an intercontinental scope. That does not establish a global service area. PeeringDB itself leaves geographic scope undisclosed. APNIC's United States country field reflects the registered resource context. It does not say where every packet is processed or where stored data rests.

Similarly, an exchange city is the location or label of a peering fabric, not necessarily the member router. EVIX explicitly supports remote tunnels. TOHU IX, ZXIX Wuhan (L) and MoeIX SEA provide peering addresses but no NICHONET facility association. An overlay can make a router logically adjacent to a remote exchange while the hardware remains in another city or country.

Commercial IP geolocation adds another layer of uncertainty. IPinfo's AS142130 page reported responsive addresses measured from Chicago and assigns the ASN to the United States. Such measurements can help test reachability and latency. They cannot locate a tunnel endpoint precisely, prove a server's legal jurisdiction or identify where customer data is stored. Anycast, proxying, stale location files and provider defaults can all separate an inferred city from the physical host.

The two RIPE-registered prefixes carry descriptive names “NICHONET-US-EAST” and “NICHONET-US-IL.” The 2a0e:b107:1204::/48 record says US and IL; the 2a0e:b107:1200::/48 record says US-EAST. These are useful operator-supplied labels. They are not audited coordinates, facility contracts or proof of data residency.

Therefore no customer should infer sovereignty or locality guarantees from the public network metadata. A valid answer would require the service's actual compute and storage locations, subcontractors, replication paths, support access locations, governing contract and deletion process. None is public.

What evidence would change the assessment

The present conclusion is deliberately reversible. NICHONET could demonstrate a hosting operation with ordinary, concrete evidence. A dated service catalogue would define what is sold. Terms and an accountable legal entity would define the contracting party. Facility letters or provider attestations could establish where racks or virtual infrastructure are located and whether NICHONET owns, leases or resells them. Circuit records and topology could distinguish remote peering from physical presence.

Capacity evidence would need units and states. For compute, that could include installed server models, usable cores and memory after operational reserve, virtualisation limits and current sold allocation. For storage, it could include raw and usable capacity, replication overhead, backup separation and restore tests. For network, it could include transit commits, measured utilisation, tunnel bottlenecks, packet-loss history and failure tests. For power, it could include contracted kilowatts, A/B feeds, generator coverage and maintenance responsibility.

Resilience claims would need proof of independence. Two upstream names are not enough; NICHONET would need to show separate termination points, carriers, paths, devices and power domains, or disclose where those paths converge. A recovery exercise should show that a service moves or restores within a stated objective. A support roster and escalation policy would address single-operator risk.

Customer and status evidence could remain privacy-preserving. Aggregate active-service counts, independently monitored endpoints, a public status history and anonymised recovery results would be more informative than naming users. A clear statement that the network is non-commercial and experimental would also resolve the ambiguity, though in the opposite direction: it would confirm that hosting-company expectations are misplaced.

Until such evidence appears, buyers and researchers should keep three labels separate. AS142130 is an active IPv6 autonomous system. NICHONET is the registered organisation name associated with it. A commercial intercontinental hosting fleet is not publicly demonstrated.

A small network can be real without being what its name implies

NICHONET deserves credit for what the evidence shows. Running an autonomous system, maintaining five IPv6 origins, arranging multiple upstream paths, participating on exchange fabrics and keeping route authorization valid for three origins require technical work. The network's visibility on 15 July 2026 was broad. The operator's willingness to describe the home-network and experimental purpose provides unusually candid context.

That same context closes the door on an inflated reading. The name is not a capacity statement. Five prefixes are not five sites. Four exchange records are not four facilities. Three observed neighbours are not three disjoint fibre routes. A 10 Gbps profile field is not 10 Gbps of available customer throughput. A valid route-origin authorization is not an uptime certificate. A US registry country is not a data-residency guarantee.

The evidence grade for the network itself is strong enough to call it active. The evidence grade for customer-facing hosting is negative: the most authoritative first-party description says personal and experimental use, while the public record supplies none of the assets, products, contracts, capacity states or recovery commitments expected of a hosting operator.

For NICHONET, the infrastructure story is therefore not about a hidden miniature cloud waiting to be quantified. It is about how an IPv6 overlay can acquire global routing visibility and geographically suggestive interconnection labels without acquiring a documented physical hosting footprint. That is a legitimate network-engineering achievement. It is also exactly why routing evidence must not be asked to prove more than it can.