Haraguroicha Internet Service makes a local connectivity bill depend on upstream routes and field repair

Summary

• Haraguroicha Internet Service is publicly visible as AS57429 and the older AS212359. Both sit in the same RIPE as-set, originate IPv6 space and are presented as educational or research networks; that is solid evidence of an operated routing domain, not evidence of a household broadband business.
• The operator advertises tunnel origins in New Taipei, Taipei, Taichung and Tokyo using WireGuard, GRE or IPsec. PeeringDB records no interconnection facility for either AS. Those facts support a virtual, underlay-dependent topology rather than owned fibre between four physical sites.
• Recent routing observations show the clearest path to AS57429 passing through Walks Cloud's AS38856, while the clearest AS212359 paths pass through AS57429. Registered policy names more than one possible counterparty, but current physical and commercial diversity is not demonstrated.
• Port labels ranging from 100 Mbps at the Taiwan origins to 10 Gbps in Tokyo, plus 1 Gbps and 500 Mbps exchange attachments, must not be added together as customer capacity. The operator's self-reported traffic band is only 20-100 Mbps, and tunnel throughput remains bounded by access, transit, host, encryption and congestion constraints.
• No public tariff, order page, subscriber count, service-level commitment, access-plant inventory, tower or pole schedule, field crew, spare stock, backup-power specification or tested recovery result was found. The appropriate assessment is therefore a functioning small routing network with unverified retail and last-mile status.

The name resolves to a network, not yet to a retail carrier

The most concrete public meaning of Haraguroicha Internet Service is a pair of autonomous-system numbers. PeeringDB identifies AS57429 under that name, assigns it a regional geographic scope, and classifies its network type as educational or research. A second PeeringDB record identifies AS212359 as Haraguroicha Legacy Internet Service, also educational or research, with an Asia-Pacific scope. The operator's own public profile and peering page lists both numbers and invites peering contact.

That is meaningful operating evidence. An autonomous system is not simply a web-domain registration. It is an administrative identity used to exchange reachability with other networks through the Border Gateway Protocol. Haraguroicha has maintained two such identities, registered routing policy, delegated address space, exchange records and observable routes. Packets can be originated under its numbers. Other networks have a basis on which to accept or reject those announcements.

It is not, however, evidence of a conventional regional broadband provider. The same public pages do not publish a residential or business tariff, installation terms, a coverage checker, customer-premises equipment, support hours, an acceptable-use policy for subscribers, a service-level commitment or a network-status page. PeeringDB's educational or research classification cuts against reading the word "Service" as proof of a mass-market offering. The name may describe the service of running and interconnecting an experimental network rather than selling local internet access.

Taiwan's current regulatory boundary makes that distinction material. The amended Telecommunications Management Act says providers that offer subscribers internet access are to register as telecommunications enterprises. An ASN, an IPv6 allocation or an exchange port does not by itself answer whether an operator has subscribers within that statutory meaning. No claim is made here that Haraguroicha is or is not registered under another legal name. The narrower point is that the public network records do not settle the question.

This profile therefore uses "regional ISP" as a useful infrastructure category, not as a conclusion about commercial scale. Haraguroicha is demonstrably a small routed network associated with Taiwan. It may carry the operator's own systems, research traffic, selected peers or private users. There is not enough evidence to count households, businesses or public institutions behind it. That limit matters whenever the analysis turns from routes to customers, revenue or local economic impact.

One operator, two autonomous systems and one routing set

The registry history begins with AS212359. The RIPE Database object for AS212359 was created in November 2020 and describes Haraguroicha Internet Service. AS57429 followed in March 2022; its RIPE object uses the name HARAGUROICHA-AS. Both point to the same resource-holder organisation, ORG-MA1764-RIPE, which names Ming-Ray Hsu in Taiwan and is typed as "OTHER" rather than as a company. The public website is a personal professional profile, not a corporate storefront.

The AS-HARAGUROICHA registry object contains both AS57429 and AS212359. An as-set lets the operator and counterparties refer to a maintained group when building routing filters. In practical terms, the two numbers are presented as one administrative routing family. The as-set does not prove that every prefix is always announced, that every upstream accepts the same members, or that the two systems are physically diverse.

The newer number appears to be the principal public edge. PeeringDB uses the unqualified service name for AS57429 and calls AS212359 "Legacy". Recent route paths put AS57429 immediately in front of AS212359 for much of the older system's visible space. The operator nevertheless continues to list both numbers, the as-set still contains both, and AS212359 still originates routes. "Legacy" should consequently be read as a role label, not as proof that the older system is retired.

There is an important ownership boundary inside these records. RIPE's sponsoring organisations help administer number resources. The counterparties named in import and export policy describe intended routing relationships. The companies supplying a virtual server, a tunnel, an access circuit or a physical cross-connect may be different again. A sponsoring organisation is not necessarily a transit provider; a registered transit policy is not necessarily a live session; and a live session does not reveal who owns the fibre below it.

The operator's professional profile adds a relevant but carefully bounded fact. It says Ming-Ray Hsu is a co-founder and chief technology officer of Walks Cloud Inc. and separately lists management of AS57429 and AS212359. RIPE routing policy names Walks Cloud's AS38856 for both Haraguroicha systems. Those records make the current path intelligible, but they do not merge Haraguroicha's assets, customers or obligations with Walks Cloud's. The public evidence shows shared operational context and routing contact, not a published ownership agreement.

The location table describes tunnel origins

Haraguroicha's own page lists four origins. New Taipei, Taipei and Taichung are each labelled 100 Mbps. Tokyo is labelled 10 Gbps. The permitted services are WireGuard, GRE and IPsec in varying combinations. The wording is more informative than a generic regional map because it reveals how the points are reached: they are tunnel endpoints.

Each listed technology creates a logical path over an existing network. WireGuard encapsulates IP packets over UDP, using authenticated encryption between configured peers. GRE wraps one network-layer packet inside another but does not itself provide the physical circuit or encryption. IPsec's architecture secures IP traffic between defined security endpoints. In every case, an underlay must already carry the outer packets.

That makes the location table a map of reachable origins, not an inventory of owned access plant. A New Taipei origin might be a router in an office, a small server at home, a hosted virtual machine, a colocated appliance or a port delivered remotely from somewhere else. The same range applies to Taipei, Taichung and Tokyo. The page publishes no street-level facility, rack, building owner, cross-connect, access-carrier or circuit identifier for any origin. PeeringDB lists no interconnection facility for either AS.

The physical footprint that can be stated with confidence is therefore narrow. The resource holder is associated with New Taipei City. The operator advertises tunnel entry points in three Taiwanese cities and Tokyo. AS57429 is visible at an exchange listed in Fremont, California, and AS212359 is listed at an exchange in Zurich, Switzerland, but neither exchange record proves that Haraguroicha owns or colocates a router in those cities. Remote Layer 2 delivery and tunnelling can place an AS on an exchange fabric without a local rack.

There is no public evidence of Haraguroicha-owned fibre between New Taipei, Taipei and Taichung, no tower or pole schedule, no fixed-wireless sectors, and no customer drop cables. There is also no evidence that the operator owns the Taiwan circuits on which its tunnels begin. The prudent topology is an overlay across third-party internet, hosting and exchange infrastructure. That architecture is entirely capable of carrying real traffic. It simply inherits more of its physical resilience from suppliers than a map of four labels might suggest.

A visible IPv6 network, with less address space than the labels imply

Recent global routing observations confirm activity. The RIPEstat announced-prefix view for AS57429 showed four IPv6 announcements during the observation window used for this profile. Three were 2a06:a005 /44s listed on the operator's page; the fourth was 2a0f:607:1024::/48. The corresponding AS212359 view showed five IPv6 announcements.

This is better evidence than a dormant registration. It indicates that route collectors recently received Haraguroicha origins from multiple vantage points. Cloudflare's AS57429 overview and AS212359 routing page also recognise the names and expose current routing views. The network is not merely an abandoned ASN entry.

The figures on PeeringDB need interpretation. Both network records state six IPv4 prefixes and 50 IPv6 prefixes. In interconnection directories, those fields are commonly used as prefix limits that a peer should expect, not as a certified count of currently originated blocks. They should not be multiplied by address size or treated as customer inventory. The route collectors show four and five recent IPv6 announcements, while no Haraguroicha-originated IPv4 prefix appeared in the same result.

IPv4 addresses on an exchange fabric do not change that conclusion. AS57429 has an IPv4 peering-LAN address at Lambda-IX, and AS212359 has one at 4b42. A peering-LAN address lets routers speak to each other on that exchange. It is not the same as announcing an IPv4 customer block to the global table. Haraguroicha's public routing identity is currently much more clearly IPv6 than IPv4.

The address blocks also reveal supplier dependence. The operator attributes several /44s to Route48 and other prefixes to TunnelBroker.ch, FREETRANSIT, RHE-NET and Nato Internet Service. Those attributions are self-published and may lag later resource arrangements, but they show that address stewardship is not synonymous with owning the covering allocation. If a sponsor changes policy, retires a service, withdraws permission or stops maintaining route objects, the operator may need to renumber, replace a route authorisation or find another sponsor even while its routers and tunnels remain intact.

Current origin validation is mixed but mostly positive. Direct RIPEstat checks on the nine recently observed announcements returned seven valid results and two unknown results on 10 July 2026. Unknown does not mean invalid; it generally means the validator did not find a route-origin authorisation that covered the exact origin and prefix. The distinction still matters because networks that enforce route-origin validation can reject an invalid route, while an unknown route receives policy treatment chosen by each network. Maintaining authorisations is part of keeping sponsored space usable.

The clearest route still narrows through Walks Cloud

The registry describes more diversity than the recent route paths demonstrate. AS57429's RIPE object accepts routes from AS41378 and AS38856. AS212359's object names AS38856 and AS20473. Those are declared import and export policies: statements of intended or permitted exchange. They are useful for filtering and contact, but they are not proof that all sessions are active, independently delivered or able to carry full traffic at the same time.

Recent RIPE RIS paths present a simpler structure. For each of AS57429's four clear announcements, the immediately preceding AS in the observed paths was AS38856, Walks Cloud. For the clearest AS212359 announcements, the immediately preceding AS was AS57429. A representative BGP-state view of 2a0f:607:1024::/48 shows the Walks Cloud-to-Haraguroicha edge; a representative AS212359 prefix view shows AS57429 immediately before AS212359.

Route collectors see only what their peers announce, and paths can vary by prefix, time and policy. These observations cannot prove there is one cable. They do establish that the globally visible route, during the measurement window, converged on one immediate upstream pattern. A second name in a registry does not yet establish usable failover.

Physical diversity requires a harder set of facts. Are two upstream sessions delivered by different carriers? Do they enter different buildings? Are they on separate ducts or poles? Do they terminate on different routers, power feeds and virtual hosts? Can each carry the full normal load when the other disappears? Does failover preserve the same origin authorisation and route filters? None of those details is public for Haraguroicha.

The AS212359 arrangement adds another layer of concentration. If its routes reach the world through AS57429, and AS57429 reaches the world through AS38856, then a fault at the AS57429 border affects both identities. Two autonomous-system numbers can improve experimentation, policy separation or migration. They do not create two failure domains when one sits behind the other.

The same reasoning applies to the human relationship. Walks Cloud may be a convenient and technically close upstream because the Haraguroicha operator also reports a leadership role there. That can make configuration and recovery faster. It can also concentrate escalation in the same small group. Organisational familiarity is valuable, but it does not substitute for an independently contracted path and a second repair organisation.

Exchange ports are options, not a sum of bandwidth

Haraguroicha has more public interconnection than its small traffic band might imply. The current PeeringDB data for AS57429 lists a 1 Gbps attachment to Lambda-IX as operational and a 500 Mbps attachment to Poema IX as not operational. The AS212359 record lists an operational 4b42 exchange attachment but declares no usable port speed. These are valuable clues, but none should be read as a guaranteed internet uplink.

Lambda-IX's PeeringDB record places its exchange fabric in Fremont and lists a physical facility there. Haraguroicha's own origin list does not mention Fremont, and its PeeringDB network record lists no facility. The 1 Gbps label therefore states the logical exchange-port rate, not the route, latency or capacity of whatever service reaches that port. A remotely delivered 1 Gbps exchange interface can be constrained by a 100 Mbps tunnel or a congested virtual host.

Poema is even more explicit about the distinction. Its own explanation of a virtual IXP says hobby or research networks commonly use virtual machines and tunnels over professional ISPs rather than their own fibre, and that such an exchange does not increase the underlying network's total throughput. Its joining rules describe non-commercial participation, tunnel or virtual-machine access and mandatory route-server peering. Haraguroicha's 500 Mbps Poema label is therefore evidence of experimental interconnection potential, not paid transit or a 500 Mbps local access network. PeeringDB currently marks the connection non-operational, which further prevents treating it as available redundancy.

The older AS's attachment in Zurich has similar ambiguity. 4IXP says that participants can connect by cross-connect, VLAN or tunnel and that it offers EoIP, GRE tap and VXLAN options. PeeringDB marks Haraguroicha's exchange record operational but supplies no positive port rate. The exchange can widen the set of reachable peers and offer route-server learning. It does not establish a physical Haraguroicha presence in Switzerland or an independent path from Taiwan.

Peering and transit also perform different jobs. At an exchange, a network reaches the routes that other participants agree to advertise. Transit is the service of carrying traffic onward to the rest of the internet. An open peering policy reduces the contractual barrier to direct exchange, but it does not force large networks to peer, provide a default route or carry traffic beyond their own customers. A network still needs reliable transit for destinations not covered by peers.

The arithmetic is consequently non-additive. A 1 Gbps exchange port, a 500 Mbps exchange port, three 100 Mbps Taiwan origins and a 10 Gbps Tokyo origin do not produce 11.8 Gbps of customer capacity. Some labels describe interfaces, some describe tunnel offers, and some may share the same underlay. Traffic may traverse two or more of them in series. The slowest congested or failed dependency governs the usable path.

Installed, reachable and usable are different capacities

PeeringDB places both Haraguroicha systems in a self-reported traffic band of 20-100 Mbps. That is consistent with a small network and far below the largest interface labels. The band is not an audited traffic graph, however, and the identical values on both records may describe the combined environment rather than two independent loads. It should be treated as an order-of-magnitude statement.

Installed capacity is the negotiated line rate of an interface or the nominal limit of a circuit. Reachable capacity is what can pass after the tunnel, underlay and remote endpoint are working. Usable capacity is what remains after protocol overhead, packet size, encryption work, traffic contention, routing policy and resilience reserve. Customer-available capacity would be smaller again if the network sold access and had to aggregate many users. Public records expose fragments of the first two categories and almost none of the last two.

Tunnels add specific constraints. The outer packet consumes bytes, which reduces the space available for the inner packet before fragmentation. A mismatch in maximum transmission unit can produce poor performance that looks like random application failure. Encryption consumes CPU and may become the ceiling on a small virtual machine or router. UDP-based transport can cross many networks effectively, but it remains exposed to loss, reordering and congestion on the underlay. GRE has less security overhead but requires separate protection when confidentiality or authentication is needed.

A 10 Gbps interface in Tokyo is therefore a ceiling at one point, not a promise between Taiwan and Tokyo. The virtual host may have a shared vCPU, the access circuit into a Taiwan origin may be 100 Mbps, or the internet path between endpoints may vary at busy hour. If three Taiwan origins each depend on consumer or small-business access, their upstream rates and contention policies may be more important than the nominal Tokyo port.

Resilience consumes headroom. If two 100 Mbps origins each normally carry 70 Mbps, neither can absorb the other's traffic after a failure. Both links are installed and both are active, yet the pair is not fully redundant. A useful capacity statement would publish busy-hour traffic per origin, packet loss, latency, CPU headroom, maximum transmission unit, and the load observed during a failover. Haraguroicha publishes none of those measurements.

The same rule applies to prefixes. The ability to announce nine IPv6 blocks does not show how many are in use, how many services sit behind them or whether they can move between origins. Address capacity is abundant in IPv6. Forwarding, compute, access and labour are scarce. Counting addresses would exaggerate the physical network by an enormous margin.

What a local connectivity bill would actually buy

There is no public Haraguroicha retail bill to analyse. The title instead points to the cost stack required to make this network locally dependable. For a small overlay operator, the recurring bill is not just "bandwidth". It is the sum of underlay access, transit, hosting, remote exchange delivery, equipment, electricity, address-resource administration and the time required to keep them aligned.

The access line at each origin comes first. If a router in New Taipei reaches the wider network through a third-party broadband circuit, that circuit pays for the local pole, duct, fibre, coaxial or radio plant even though Haraguroicha does not own it. Its price and repair terms embody the local physical network. Buying a second service helps only if the second supplier is not leasing the same last-mile facility or returning to the same aggregation site.

Transit pays for global reach. Peering can reduce the distance or cost of selected traffic, but a small network normally cannot replace transit with a collection of experimental exchanges. Hosting adds virtual machines or dedicated routers at remote points. Exchange delivery adds a tunnel, VLAN, virtual machine or cross-connect. Some services may be free or community-supported, but zero price does not mean zero dependency. It can instead mean no contractual restoration time, limited support and a need for the operator to solve more problems directly.

Hardware and power are smaller in quantity but decisive in failure. A compact router, switch, storage device or server needs replacement when a power supply, fan or flash device fails. Batteries need testing and eventual replacement. A virtual machine avoids local hardware but transfers the physical dependency to its host and data centre. The cost is then embedded in rent and in whatever response the provider offers.

Labour is the binding expense in a one-person or very small network. The same engineer may maintain route policy, upgrade systems, renew credentials, answer abuse messages, diagnose a tunnel, coordinate with an access carrier and visit a local device. The operator's public profile demonstrates broad technical experience but does not list a Haraguroicha network operations team or field crew. Skill is visible; staffing depth is not.

This explains why route diversity and field repair belong in the same sentence. A second BGP session is useful only if someone can distinguish a remote routing fault from a dead modem, failed power supply, cut access cable or locked equipment room. A fast routing change cannot repair the underlay on which both tunnels run. Conversely, a field technician can restore a local circuit while a stale route filter keeps the prefix unreachable. The service is the whole chain.

Failure path one: the underlay breaks first

Consider a New Taipei tunnel origin. Its logical interface may be healthy, its cryptographic keys valid and its BGP configuration unchanged. If the access carrier loses a feeder cable, aggregation switch or local power source, the outer packets no longer reach the remote endpoint. The tunnel disappears because the physical network below it has disappeared.

The immediate symptom may look like a Haraguroicha outage even when none of its software failed. Recovery responsibility begins with the owner of the underlay. Haraguroicha can open a fault, move traffic to another origin, replace its own equipment or provide diagnostics. It cannot splice another carrier's fibre, enter a street cabinet without authority or reprioritise the carrier's repair queue.

Three Taiwan origin labels could provide useful geographic separation. New Taipei, central Taipei and Taichung are not the same city. Yet independence is not established by names alone. Two origins can use the same nationwide carrier, the same upstream aggregation network, the same remote virtual host or the same account-level control plane. New Taipei and Taipei can share metropolitan ducts or facilities. A Taichung tunnel can still return to a Taipei hub before reaching transit.

The Tokyo origin may offer a more distant recovery point, but distance introduces another dependency: the international path. Taiwan's Ministry of Digital Affairs has repeatedly emphasised diversified communication systems and backup routes in its submarine-cable resilience work. That national context does not identify Haraguroicha's path. It does show why "Tokyo" cannot be treated as independent merely because it is overseas. If the underlay between Taiwan and Japan converges on one cable system or one carrier edge, the logical tunnel follows that shared risk.

A real underlay test would compare traceroutes and carrier circuit records from each origin, identify the first common aggregation point, map building entrances and power domains, and then fail one access service under load. Public route collectors cannot see the private first mile, and a geographic label cannot replace that test. Until such evidence exists, the four origins should be counted as routing options with unknown physical correlation.

Failure path two: power or a host removes the router

Every origin requires a powered device. At a local site that may be a router and an access modem. At a hosted site it may be a virtual machine running on a server, a top-of-rack switch and the data centre's power train. The public material identifies none of these components for Haraguroicha, so the power analysis must remain conditional.

Taiwan's distribution system is reliable in aggregate but not immune to local failure. Taipower reported in January 2026 that distribution incidents had fallen substantially over thirteen years and that feeder automation had been completed nationwide, while also explaining that natural disasters, external forces and equipment faults can trip local feeders. That power-resilience account supports two conclusions at once: restoration capability has improved, and site-level outages remain possible.

A battery can bridge a short outage only if it powers the complete path. Keeping a router alive while the access provider's street cabinet or building switch goes dark produces no service. Keeping a hosted router alive while the tunnel origin at the other end loses power also produces no end-to-end path. Long-duration resilience needs coordinated runtime across local equipment, access, hosting and transit.

Power diversity also has to be physical. Two virtual routers on one server, two servers behind one rack power distribution unit, or two origins fed from one building service do not survive the corresponding common fault. A generator is useful only if it starts, has fuel, carries the actual load and protects the cooling and access systems required by the equipment. None of those protections is documented for Haraguroicha.

Host failure can resemble power failure. A hypervisor crash, storage fault, network maintenance window, account suspension or capacity pressure can remove a virtual router. The four-origin design may reduce that risk if origins use independent hosts and providers. It may amplify it if the same management credentials, configuration error or automation change touches all nodes. The public page lists endpoints but does not disclose host diversity.

The evidence needed to upgrade the power assessment is concrete: equipment location by facility class, battery runtime at normal load, generator or host commitment, dual-power status, access-device power dependency, alarm path and a recorded failover during a real or controlled outage. In the absence of those facts, power remains an unpriced line in the public description and a potentially dominant line in the reliability bill.

Failure path three: a route exists on paper but not in use

BGP is designed to exchange paths between autonomous systems. Its base specification, RFC 4271, lets each network apply policy to what it learns and announces. That policy flexibility is why a registered import line, a live session and a globally preferred path are different things.

Haraguroicha's registry records name AS41378 and AS38856 for AS57429, and AS38856 and AS20473 for AS212359. If both counterparties in each pair were live, separately delivered and able to carry all prefixes, the network could have useful route redundancy. Recent global views do not demonstrate that state. They show a dominant AS38856-to-AS57429 path and an AS57429-to-AS212359 path.

Several causes could explain the gap without implying fault. A backup session may be configured but idle. It may announce only at a local exchange, carry a subset of prefixes, have lower preference, sit outside the collector view or be reserved for manual activation. The registry may simply be stale. Each possibility has a different operational consequence, which is why a list of AS numbers is not a resilience result.

Route filters add another failure mode. If an upstream builds filters from the AS-HARAGUROICHA set, a missing member or prefix object can block an intended announcement. If a sponsor changes a route-origin authorisation, validation can change. BGP operational guidance in RFC 7454 recommends controls such as prefix filtering and limits precisely because accepting every route is unsafe. Those controls protect the internet, but a small operator must keep its registrations aligned with them.

The current validation result is encouraging rather than complete: seven visible routes were valid, while two were unknown, not invalid. A stronger posture would make every intended origin valid, monitor for unexpected origin changes, and publish a current prefix list. It would also set realistic maximum-prefix limits instead of leaving peers to infer them from a broad 50-prefix allowance.

Fast fault detection helps only after diversity exists. PeeringDB marks BFD support false on the listed AS57429 exchange attachments. Bidirectional Forwarding Detection can detect forwarding-path failure rapidly, but that flag says only what is declared for those exchange sessions; it does not prove BFD is absent elsewhere. Even perfect detection cannot move traffic to a path that shares the same failed underlay or lacks capacity.

Failure path four: congestion survives every routing session

A path can remain up and still fail users. Packet loss, high latency, jitter or reduced maximum transmission unit may leave BGP established while applications stall. Tunnels are especially prone to this split because the control session can survive at low bandwidth even when the data plane is badly congested.

The self-reported 20-100 Mbps traffic band is modest enough that a 100 Mbps origin could become the busy-hour ceiling. If the label is accurate, a single popular download, backup or route offered to another network can materially change utilisation. The absence of a public traffic graph prevents separating average load from peaks and prevents testing whether Tokyo's nominal 10 Gbps port ever becomes the bottleneck relief that its label suggests.

Peering can shorten some paths, but a virtual exchange can also add encapsulation and an indirect route. Poema's own description is unusually candid that its virtual fabric does not create more underlay throughput. If traffic enters Poema over the same local access link it would otherwise use for transit, changing the BGP next hop may alter policy without removing the congested first mile.

Congestion during failover is the more serious test. Spare capacity must exist where traffic lands, not just where it leaves. If the New Taipei origin fails and Taipei absorbs its routes, the surviving tunnel, host and upstream all need headroom. A successful route change followed by 10 percent packet loss is not resilient service.

The operator could settle this question with a small set of public measurements: 95th-percentile traffic by origin, latency and loss to stable targets, interface errors, tunnel overhead, route-change time and performance during a forced failure. Cloudflare Radar exposes aggregate quality views where it has enough observations, but it does not disclose a Haraguroicha service-level record or identify customer access lines. No public evidence currently demonstrates busy-hour or failover performance.

Field repair begins at the ownership boundary

The assignment's phrase "field repair" needs a precise subject. There is no verified Haraguroicha pole line, radio tower or customer drop to repair. The field assets that most plausibly support the network belong to access carriers, building owners, hosting companies and power utilities. Haraguroicha's own field work may be limited to a router, server, modem, cable and power unit at a small number of origins.

That does not make labour irrelevant. It makes coordination the central skill. When an origin fails, someone must determine whether the fault is local equipment, access, power, tunnel configuration, remote host, BGP policy or upstream routing. Each diagnosis leads to a different party and a different restoration clock. A small operator can lose hours proving ownership before repair begins.

The public contact surface appears highly concentrated. The RIPE administrative and technical contacts point to the same person, and the operator's page directs peering enquiries to one identity. A single skilled engineer can run a capable research network. The resilience concern is availability: illness, travel, competing employment, lost credentials or an incident affecting several nodes can turn expertise into a queue.

Spares are the physical counterpart to that queue. A replacement router or power supply stored in New Taipei does not immediately repair a Taichung endpoint. A configuration backup does not help if no one has access to the building. A hosted virtual machine can be rebuilt remotely only if account access, images and route authorisations are available. No public material identifies spare hardware, remote hands, secondary administrators or out-of-band access.

The labour test should therefore follow each asset. Who can enter the site? Who can replace the device? What response time is contractual? Is there a second administrator? Can an upstream change routing when the primary contact is unavailable? Are configurations and keys recoverable without the failed node? These are ordinary operational questions, not demands for a large staff. For a compact network, clear delegation can provide more resilience than another untested tunnel.

Who loses service when the chain fails

The answer cannot responsibly begin with "subscribers" because no subscriber base is public. The first affected party is the operator itself: its prefixes, routers and systems may become unreachable. Services addressed inside the nine visible IPv6 announcements would be exposed to the corresponding origin or upstream failure. Peers that exchange traffic directly may lose that route and fall back to transit if an alternative exists.

AS212359 is a clearly visible downstream dependency in the routing topology. When its paths run through AS57429, a failure at the newer AS's edge can remove reachability for the older system as well. That is a technical dependency, not evidence of a separate customer organisation.

Research users, friends, collaborators or private systems may also be affected, but the public record does not identify them. Nor does it show that a hospital, school, local business or household relies on Haraguroicha for primary access. Naming such users would manufacture social impact that the evidence cannot support.

The absence of verified customers changes the scale of harm, not the engineering. A research network can host authoritative DNS, monitoring, software services or experiments whose interruption matters to their operators. It can also serve as a training environment where safe failure is part of the purpose. Without a service catalogue, the correct description is reachability loss to systems and peers using the Haraguroicha routing domain.

If retail access does exist, the ownership boundary would determine the user experience. A customer behind a third-party last mile could remain physically synced to the access carrier while losing Haraguroicha routing. Another customer could lose the local circuit while Haraguroicha's global routes remain visible. Support would need to distinguish those cases and explain which repair queue applies. No public terms show how that responsibility would be divided.

What would establish real redundancy

The most valuable evidence would not be another city name or exchange badge. It would be a dependency map that separates physical site, access carrier, tunnel endpoint, host, power source, router, upstream and route policy for each origin. A redacted version could protect security while showing whether two paths share a failure domain.

Upstream diversity needs a live test. Each intended transit should announce the same authorised prefixes through a separately delivered circuit. Either path should carry the full busy-hour load. A controlled withdrawal should move traffic within a stated interval, with loss and latency remaining inside a stated objective. Collector views before and after the test would show whether the backup reached the wider internet.

Origin diversity needs the same discipline. New Taipei, Taipei, Taichung and Tokyo should be tied to actual hosting or equipment boundaries, not just tunnel labels. Independence would mean different underlay carriers where practical, separate host accounts and power domains, no single central tunnel concentrator, and enough spare capacity at every recovery point.

Power evidence should include measured runtime and dependency coverage. A local battery that outlasts the access device is useful; one that protects only the router is not. A hosted origin should disclose whether the provider offers redundant power and remote hands. The network should know which paths disappear when a building or carrier loses electricity.

Repair evidence should identify primary and secondary responders, spare locations, site-access rights and escalation contacts. A simple incident record showing detection, diagnosis, route movement, physical repair and restoration would reveal more than a static network diagram. It would also show whether the operator can recover while the main engineer is unavailable.

Finally, commercial status should be settled separately from technical status. A current tariff, orderable address, subscriber contract, registration record under a disclosed legal name, customer count range or independently verified installation would establish an access business. Without those facts, the network should continue to be described as an educational or research routing operation rather than promoted into a retail carrier by inference.

The responsible conclusion is active overlay, unverified access network

Haraguroicha Internet Service has more substance than a thin company card might suggest. Two ASNs remain registered under one resource holder. Both are grouped in a maintained as-set. Nine IPv6 announcements were recently visible. The newer AS appears at Lambda-IX, the older at 4b42, and the operator publishes four tunnel origins. Most visible routes have valid origin authorisation. These are signs of a functioning small network.

The same evidence draws a firm ceiling. The topology is expressed in tunnels, not owned fibre. The largest exchange and origin labels do not equal usable throughput. Current route observations narrow through AS38856 and AS57429 despite broader registry policy. Exchange participation is remote-capable, and one listed AS57429 attachment is currently marked non-operational. No facility, access plant, power reserve, field team, service-level commitment or customer base is public.

That combination supports a medium network-evidence grade and a weak retail-access claim. Haraguroicha can be analysed as a regional IPv6 routing and peering operation associated with Taiwan. It cannot yet be analysed as though it owns a four-city broadband network or sells a proven local service.

The local connectivity bill is therefore a dependency bill. It pays third parties for the access that carries the tunnels, the hosting that keeps endpoints alive, the transit that reaches destinations peers do not, the power below each device and the people who diagnose which owner must repair what. The number of ASNs and port labels matters, but recovery depends on whether those costs buy genuinely independent routes and reachable hands. Public evidence does not yet show that they do.