AS134204 links Business Network to routes and four declared excha

Summary

APNIC RDAP identifies Business Network as the organisation behind active autonomous system AS134204, giving the exact directory entity a public number-resource identity without resolving every legal, ownership or licence question.
RIPEstat returns 36 route entries for the captured window—19 IPv4 and 17 IPv6—and sampled RPKI checks validate one IPv4 and one IPv6 origin-prefix combination, but overlapping aggregates and more-specifics cannot be read as customers, sites or physical capacity.
PeeringDB lists four declared exchange attachments and RIPEstat observes two neighbours; both are useful control-plane signals, not proof of contracts, traffic, path diversity, uptime, resilience or the operator's physical delivery footprint.

A generic company name becomes checkable through AS134204

“Business Network” is broad enough to describe a product, a category or a company. AS134204 makes the name materially more specific. APNIC’s public RDAP record labels the autonomous system BUSINESSNETWORK-AS-AP, associates it with Bangladesh and marks it active. The existing BTW directory route binds the same network identity to one exact company entry. Together, those records create a reference point that can be compared with routing and interconnection data instead of relying on the ambiguity of a generic brand name.

An autonomous-system number is a coordination identifier. It gives other networks a stable value around which routes, origin authorization and observed adjacencies can be recorded. It does not describe every organisation using the brand or every service sold under it. It also does not establish that a single company owns every physical component behind the routes. The identifier answers a narrower but important question: which public network identity is attached to the route-origin activity visible under AS134204?

That distinction prevents a familiar category error. A company page may describe broadband service, packages and support. A registry page may identify a holder, address and contact roles. A route collector may show origin and neighbour observations. Each surface describes a different part of reality. Combining them can produce a useful operating picture only if their limits remain intact. The name match is strong enough to connect the directory entity with the ASN. It is not strong enough to turn registry and route metadata into a complete corporate or physical-network profile.

The control surface is nevertheless substantial. AS134204 can be followed across APNIC, RIPEstat and PeeringDB. Prefixes can be compared with origin authorization. Declared exchange attachments can be separated from observed neighbours. Changes can be dated and checked. The records allow scrutiny of whether public administrative identity and running routes remain aligned, even when the customer-facing delivery chain stays opaque.

For Business Network, that is the publishable boundary. The evidence supports an exact technical identity, active number-resource records, visible dual-stack announcements and declared interconnection points. It does not support claims about market share, customer dependence, physical ownership, route diversity or service quality. A useful account begins with the ASN because it is the part of the operator that the public record can actually test.

APNIC names the holder but does not map the operating company

The APNIC autonomous-system record is the clearest administrative anchor. It names AS134204, records BUSINESSNETWORK-AS-AP, assigns country code BD and presents active status. The linked organisation handle ORG-BN4-AP resolves to Business Network and publishes contact information in South Banasree, Khilgaon, Dhaka. The registration history dates the autonomous-system record to May 2015, while later change dates show that the records have continued to be maintained.

These fields matter because number resources need a responsible identity. A route-origin dispute, registry correction or security contact cannot be handled if the resource is detached from a holder. The organisation handle supplies continuity across records even if human contacts change. The autonomous-system handle gives routing observers a stable value even if a marketing name or website changes. Registry maintenance is therefore part of operational coordination, not decorative company information.

The registry is not a corporate registry, however. The public fields do not establish a complete legal name, shareholding structure, beneficial ownership or the relationship between every service brand and the resource holder. An address in the organisation record is a contact surface, not evidence of a network operations centre, exchange presence, data centre or customer footprint. The country code provides registry context; it does not prove that every announced route serves users only in Bangladesh.

The same restraint applies to status. “Active” means the RDAP entity is active in the registry. It does not certify that every route is currently visible, every service is commercially available or every contact responds. The IRT record associated with the organisation includes a recent note that an abuse email was invalid when checked. That is an operational metadata warning inside the registry, not proof that abuse is ignored, that the company is inactive or that current delivery has failed. It is a specific record-quality issue whose present resolution would need separate verification.

The correct reading treats APNIC as a ledger and recordkeeper. It preserves identity, uniqueness, contact roles and change history around AS134204. It gives Business Network an auditable administrative surface. It does not govern all physical or commercial facts about the network. Running routes, interconnection observations, legal documents and field evidence must supply those other layers.

The 36-entry route snapshot is broad but overlapping

RIPEstat’s announced-prefixes response returns 36 entries for AS134204 in the captured two-week window. Nineteen are IPv4 and 17 are IPv6. At first glance, that is a large enough list to tempt a simple footprint claim. The structure of the list shows why that would be misleading. It includes aggregates and their more-specific routes, so many entries describe overlapping address space rather than separate holdings or independent service areas.

The IPv4 side includes 103.58.72.0/22 together with component /24s. It also includes 203.76.220.0/22 and its component /24s, plus additional blocks such as 103.122.46.0/24, 103.122.47.0/24, 103.138.122.0/24, 103.138.123.0/24, the 103.211.28.0/24 through 103.211.31.0/24 group and 138.252.84.0/24. The entries establish route visibility under AS134204 in the sampled data. They do not say how the addresses are allocated within the operator or what service, customer or device uses them.

The IPv6 list follows a similar pattern. It includes aggregate 2400:4d40::/32 and sixteen /36 entries. The aggregate and more-specific routes are not seventeen disjoint networks. They are different routing statements within related address space. Their presence can reveal how an operator chooses to expose more-specific reachability or policy. It cannot be converted into seventeen locations, sixteen customers, sixteen independent paths or a quantified deployment footprint.

Route entries are also time-bound. A collector records what its vantage points see during a query window. Announcements can appear, disappear, aggregate or become more specific. A route visible in one period may reflect traffic engineering, maintenance, policy or upstream propagation rather than a permanent architecture. The snapshot is useful precisely because it can become a dated baseline. It should not be treated as a timeless inventory.

The safest quantitative statement is therefore the one the response actually supports: 36 prefix entries, divided into 19 IPv4 and 17 IPv6 entries, were returned for AS134204 in the captured window. Any stronger aggregation requires address-space normalization and a clear question. Even then, address counts would remain control-plane quantities, not measures of customers, traffic, capacity or geographic reach.

That boundary matters for accountability. Inflated route counts can make a network appear larger or more diverse than the evidence supports. Ignoring more-specific routes can hide operational choices. Preserving both the count and the overlap allows the public record to remain useful without turning routing mechanics into a business ranking.

The IPv4 view reveals several visible blocks without exposing topology

The IPv4 entries show that AS134204 originates more than one public address block in the sampled view. The presence of aggregates and more-specifics indicates a routing policy with multiple visible entities, not a single isolated /24. That is stronger running-code evidence than a registry record alone because route collectors are observing announcements associated with the ASN. Other networks must process some version of those announcements for them to appear.

Visibility does not reveal the internal topology behind the origin. A /22 could support network infrastructure, customer assignments, services, management systems or a mixture. Its component /24s might be announced for policy control, propagation, traffic engineering or operational convenience. Public BGP data does not reveal which router originates the route, which physical link carries it, where equipment is located or how traffic is distributed after reaching the autonomous system.

Nor does a collection of prefixes prove diversity. Multiple blocks may share the same upstream, exchange fabric, fibre corridor, powered room or operational team. Conversely, a small number of public routes may sit behind a complex and redundant physical system. The route table describes reachable address entities and path attributes. It cannot directly measure ducts, power domains, equipment spares, field access or restoration capability.

The IPv4 list can still anchor specific questions. Are the aggregates and more-specifics originated consistently by AS134204? Do sampled authorizations cover the intended route lengths? Do observed neighbours change when more-specifics appear? Are withdrawals short-lived or sustained? Each question can be tested over time without guessing what product uses the addresses.

This is the value of running-code primacy. A company description may remain unchanged while routes move. Registry records may remain stable while an announcement disappears. Observed routing does not replace those records, but it reveals whether the public control plane is doing what the administrative identity permits. For Business Network, the current IPv4 view establishes substantial route activity while leaving the physical and commercial system behind it unproved.

IPv6 visibility makes the dual-stack boundary inspectable

AS134204’s IPv6 presence is visible in the captured announced-prefixes data. Aggregate 2400:4d40::/32 appears alongside sixteen /36 entries. This distinguishes Business Network from cases where an IPv6 allocation exists only in a registry and no current route is visible. Here, the public route view supplies running-code evidence that at least part of the IPv6 resource is being announced.

The evidence still falls short of customer-facing IPv6 service. A public announcement does not reveal whether residential or business users receive native IPv6, whether customer equipment supports it, whether the operator uses the space only for infrastructure, or whether reachability is consistent across all destinations. It says that the route objects are visible through the collectors in the query window. It does not establish end-to-end delivery.

The /36 entries are particularly easy to overread. Sixteen more-specifics might reflect policy segmentation, regional routing, security controls or operational planning. The public response does not label their purpose. It does not map them to sites, exchanges, customers or independent paths. Treating each /36 as a separate service region would invent geography that the data does not contain.

The visible aggregate and more-specifics do create a useful monitoring baseline. Future snapshots can test whether the same set remains visible, whether origin changes, whether the aggregate is withdrawn while more-specifics persist, or whether authorization changes. Such changes may warrant investigation. They do not carry an automatic explanation. Maintenance, route policy, collection differences and operational incidents can all alter the view.

The responsible conclusion is narrow and positive: Business Network has a publicly visible dual-stack routing surface under AS134204 in the captured data. That is a meaningful technical fact. It is not a claim that every service is dual-stack, that IPv6 performance is equivalent to IPv4, or that the physical network has distinct IPv6 infrastructure. The route layer proves visibility, not the entire delivery layer.

Sampled RPKI validity narrows origin uncertainty

Two RIPEstat validation checks were captured for AS134204. The IPv4 sample pairs the ASN with 103.58.72.0/24 and returns valid. The validating ROA covers 103.58.72.0/22, allows maximum length /24 and names origin AS134204. The IPv6 sample pairs the ASN with 2400:4d40::/32 and also returns valid, backed by an exact /32 authorization for the same origin.

These results matter because route-origin authorization is designed to reduce one form of routing ambiguity. A network evaluating the sampled announcements can compare the origin ASN and prefix length with published ROA data. A valid result indicates that the combination conforms to the authorization known to the validator. It provides security metadata that can support routing policy and incident diagnosis.

The samples do not certify all 36 route entries. One IPv4 /24 and one IPv6 /32 were checked. More-specifics, other aggregates and future announcements may have different validation outcomes. A broad claim that the entire AS134204 route set is RPKI-valid would require a complete current validation inventory. The two samples support a narrower finding: the selected IPv4 and IPv6 origin-prefix combinations were valid at capture time.

Validity also does not prove reachability. A correctly authorized route can be withdrawn, poorly propagated or affected by failures. It does not prove that upstreams enforce route-origin validation, that routers are securely configured or that keys and registry credentials are well protected. It does not establish filtering quality, resistance to route leaks, denial-of-service mitigation, uptime or recovery performance.

The control remains valuable when described precisely. Registry accuracy, origin authorization and route visibility can be compared. If the origin changes, observers can ask whether the ROA changed first. If a more-specific appears, they can check whether maximum-length rules authorize it. If an announcement becomes invalid, they can distinguish a registry or authorization mismatch from a physical outage. Those are concrete accountability questions.

Business Network’s sampled results therefore support an authorization layer, not a generalized security label. The RPKI records make intended origin more inspectable. They do not settle the condition of the network, the quality of service or the resilience of the delivery system.

Two observed neighbours describe a measurement, not two contracts

RIPEstat’s neighbour response lists AS58629 and AS58717 on the left side of AS134204 in the captured dataset. The response includes observation-side power and peer-count fields for those neighbouring networks. This is a useful relational signal: public route collectors saw paths that place those autonomous systems next to Business Network’s ASN in the sampled data.

An observed adjacency is not a signed agreement. It may arise from customer-provider transit, settlement-free peering, a route server, an exchange fabric or another routing arrangement. The response does not disclose commercial terms, physical circuits, service levels or which organisation can repair a link. It cannot establish that the two ASNs are the only external connections or that both are continuously active.

The distinction is especially important for resilience. Two observed neighbours may look like diversity, but logical diversity can share physical dependencies. Both paths might traverse the same building, fibre route, power system or operational team. The reverse is also possible: private or unobserved interconnections may exist beyond the collector’s view. Counting neighbours is not equivalent to counting independent failure domains.

The neighbour data can still guide monitoring. A future disappearance, new adjacency or path shift can be compared with the current pair. The change should be confirmed across time and sources before it is interpreted as a lost upstream, new contract or outage. Collector visibility, routing policy and temporary maintenance can all change the observed set.

For the present record, the exact statement is enough: AS58629 and AS58717 were observed as left-side neighbours of AS134204 in the captured RIPEstat response. That statement exposes part of the routing handoff while preserving the uncertainty around contracts, traffic, physical paths and operational continuity.

PeeringDB lists four declared exchange attachments

PeeringDB adds a self-maintained interconnection layer. Its network record identifies Business Network, gives the alias BNET, classifies the network as an NSP and links the operator’s domain. It records 19 IPv4 and 16 IPv6 prefixes and marks the general peering policy as selective. The update date shows that the record was maintained in May 2026, making it a current declaration rather than a long-abandoned entry.

The attached netixlan response lists four exchange rows: BDIX, AIX-BD, ISPAB-NIX and KTL-IX. Each row names an exchange and supplies an IPv4 address. Three also supply an IPv6 address. The rows present configured speeds of 40,000 Mbps at BDIX, 10,000 Mbps at AIX-BD, 40,000 Mbps at ISPAB-NIX and 100,000 Mbps at KTL-IX. Their operational flags are set in the PeeringDB data.

These are declared inventory fields, not observed traffic. PeeringDB depends on networks, exchanges and maintainers to keep records accurate. A listed attachment does not prove that traffic was flowing at capture time, that the port belonged exclusively to Business Network or that the configured speed was available end to end. It does not reveal utilization, congestion, contract status, maintenance condition or whether a cross-connect shares a failure point with another path.

The four rows nevertheless improve the public picture. They indicate that Business Network presents itself as connected at several Bangladesh exchange environments. The presence of both IPv4 and IPv6 addresses on three rows aligns with the dual-stack route surface seen in RIPEstat. The AIX-BD row has no IPv6 address in the response, which is a precise inventory difference rather than proof that IPv6 can never traverse that environment.

The selective policy field also requires caution. It describes the declared approach to interconnection, not an obligation to peer with a particular network. It does not reveal technical requirements, commercial exceptions or current sessions. A policy label helps counterparties understand intent, while the actual relationship depends on configuration and agreement.

Read together, the PeeringDB records expose declared attachment points that can be checked over time. They do not turn a public directory into a live traffic monitor. The correct use is to separate declared interconnection inventory from observed routing relations and from the physical paths that neither dataset proves.

Configured port speed is not delivered capacity

Speed fields attract attention because they look like a direct measure of scale. The four PeeringDB rows contain values ranging from 10,000 to 100,000 Mbps. Those numbers are part of the self-maintained attachment records. They may describe a configured or declared port characteristic. They do not show average traffic, peak load, committed information rate, available headroom or customer throughput.

Even an accurate port rate does not describe an end-to-end service. Traffic may traverse routers, upstreams, shared fabrics, access links and customer equipment with different constraints. A high-speed exchange port can coexist with a narrow access network or unused capacity. A lower-speed port may support critical peering traffic efficiently. Without utilization and path data, ranking the attachments by operational importance would be speculation.

The values also do not establish ownership. A port, cross-connect or exchange relationship can be supplied under different commercial and operational arrangements. PeeringDB does not prove who owns the fibre, optics, router chassis or building. It does not identify maintenance responsibility or restoration commitments. Those facts would require exchange confirmation, contracts or operator disclosures.

The disciplined phrasing is “configured speed recorded in PeeringDB,” not “capacity delivered by Business Network.” This keeps the inventory useful. A change from one declared value to another could signal an upgrade, correction or record maintenance. It would still need corroboration before supporting a claim about traffic growth, customer demand or resilience. Preserving that distinction avoids converting a coordination field into promotional copy. Interconnection metadata can illuminate where a network says it is present, but it cannot substitute for observed traffic, service tests or physical-infrastructure evidence.

Registry, route and interconnection records answer different questions

The evidence around AS134204 falls into three layers. APNIC describes administrative identity around the number resource. RIPEstat records selected views of running routes, origin validation and observed adjacency. PeeringDB records declared interconnection inventory and policy. The layers overlap, but no one layer governs the others.

APNIC answers who is named around the ASN and organisation handle. It supports uniqueness, accountability and contact continuity. It does not show which routes are active. RIPEstat answers what its collectors and validators see for selected resources and times. It does not establish legal ownership or commercial relationships. PeeringDB answers what entities declare about interconnection presence. It does not prove live traffic or physical independence.

The strongest findings appear where layers align. The ASN name matches the exact directory identity. Visible prefixes originate under AS134204. The sampled RPKI checks authorize the selected origin-prefix combinations. PeeringDB uses the same ASN and operator name. Dual-stack addresses appear in both the route data and several declared exchange rows. Alignment reduces ambiguity without eliminating uncertainty.

The unresolved areas sit between the layers. The registry address is not a facility. An exchange row is not an observed path. A route neighbour is not a contract. A valid ROA is not a service guarantee. A website package is not a route measurement. These gaps are not defects in the datasets; they reflect the questions each system was designed to answer.

Good infrastructure scrutiny uses the systems together while resisting category drift. A route anomaly can be compared with registry identity and authorization. A declared exchange presence can be checked against observed neighbour changes. An operator statement can be tested against public route visibility. None of those comparisons allows unsupported claims about customer impact or physical resilience.

Business Network’s public surface is therefore neither empty nor complete. It is detailed enough to establish an exact technical identity and several current control-plane facts. It remains incomplete where delivery, ownership and continuity depend on evidence outside the public records.

The operator website describes service rather than proving it

Business Network’s website describes broadband for homes and businesses in Dhaka and Bangladesh. It presents service packages and advertised access speeds, along with installation and support language. Those statements are relevant because they show how the operator describes its market role. They are first-party claims, not independent measurements.

The site does not connect each package to a public prefix, exchange attachment or observed neighbour. It does not identify which physical access method serves each area, how capacity is engineered or how many customers share a link. It does not publish a current network diagram, utilization report, outage history or independently tested performance. A package description therefore cannot fill the gaps left by route and interconnection data.

The evidence also runs in the other direction. Public route visibility does not prove that every advertised package is available. An ASN may originate infrastructure and customer address space without revealing product coverage. Exchange presence may support local traffic exchange without showing the quality of an access service. The website and control-plane records should be compared, not merged into a single unqualified claim.

The responsible role for the website is limited. It supports the statement that Business Network presents itself as a broadband operator serving residential and business users. It does not verify geographic breadth, installed footprint, customer count, speed delivery, support performance or continuity. Those questions require current, independent and service-specific evidence.

This boundary keeps the account focused on inspectable infrastructure. Marketing language can provide context, but registry and running-code records carry the technical thesis. Where the website says more than the measurements show, the difference should remain visible rather than being smoothed away.

The legal and ownership boundary remains open

APNIC records Business Network as the organisation attached to AS134204, but the source set is not a complete legal dossier. It does not establish a corporate registration number, current ownership, directors, licence categories or all entities that may trade under the name. The exact BTW directory binding is a technical and editorial identity match, not a substitute for legal due diligence.

This matters because network operations can be distributed. One company may hold number resources while another supplies transport, facilities, field maintenance, customer support or retail billing. Leased fibre can carry routes originated by the resource holder. Exchange ports can sit in third-party sites. A service brand can differ from the legal entity on a licence or contract.

The APNIC organisation address should therefore remain a contact field. It does not prove a network site or office used for delivery. PeeringDB’s organisation id and network record strengthen the continuity of the technical identity, but they do not resolve beneficial ownership. The operator website strengthens the brand match, but it does not supply authoritative legal boundaries.

Without current regulatory and corporate records, claims about licence scope or ownership would be premature. The source set supports a precise formulation: Business Network is the public registry and interconnection name around AS134204. The legal structure and division of operating responsibilities require separate evidence.

Keeping this boundary open is not a weakness. It prevents technical records from being used to overstate corporate certainty. It also identifies what a future source would need to prove: an authoritative registration, current licence, ownership disclosure or contractual statement that matches the same entity and date.

The physical delivery layer is the least visible part

Routes, ROAs and exchange rows expose control-plane coordination. They say little about the equipment and people that turn those records into a working service. Public data does not show which fibre, microwave, access equipment or third-party transport carries Business Network traffic. It does not identify power systems, spares, repair crews or escalation responsibilities.

This missing layer is where many service failures occur. A prefix can remain correctly registered while a fibre is cut. A ROA can remain valid while a router fails. Multiple exchange attachments can share a building or metro path. Two observed neighbours can depend on one powered room. Conversely, a network may have private redundancy that public route collectors do not reveal.

The four declared exchange rows do not resolve those questions. An exchange attachment may improve reachability and local traffic exchange, but continuity depends on physical and operational design. The response does not show cross-connect diversity, router redundancy, maintenance windows or failover tests. It cannot demonstrate that one attachment remains available when another fails.

Customer dependency is also absent. The route set does not show which public services, businesses or households rely on the ASN. It does not disclose critical institutions, wholesale customers or downstream networks. Impact cannot be estimated from prefix counts alone because address use and service importance vary widely.

This is why resilience language must remain outside the current finding. Resilience requires evidence about independent failure domains, recovery procedures, tested failover, power, staff and supply chains. The public control-plane surface may support monitoring, but it does not prove the outcome of a disruption.

The boundary can guide better disclosure. An operator could publish high-level continuity architecture without exposing sensitive details. Exchanges could confirm current attachment status. Independent measurements could test reachability over time. Incident notices could document failure and recovery. Until such evidence exists, the delivery layer remains the central unknown behind AS134204.

Operational continuity starts where public metadata stops

Number-resource records need continuity because routing depends on accurate identity. Contacts must be maintained, authorizations updated and prefixes originated consistently. Business Network’s active APNIC record, sampled valid ROAs and visible route set show several pieces of that coordination functioning in the captured window.

Operational continuity is a wider problem. It asks who notices a fault, who can change a route, who can repair the path and how service is restored. None of the captured systems provides a complete answer. An abuse-contact warning may identify a metadata maintenance issue, but it does not reveal the broader escalation chain. An exchange row may identify a handoff, but not the owner of the cross-connect or the recovery target.

The current evidence can support bounded continuity monitoring. Registry changes can be tracked. ROA validity can be checked. Prefix withdrawals and origin changes can be observed. Neighbour and exchange inventory changes can trigger questions. These signals may indicate an event, but they are not enough to diagnose cause or customer impact on their own.

A credible continuity claim would need evidence of independent paths, power arrangements, equipment redundancy, staffing, incident response and tested recovery. It might also need service-specific measurements and current contractual boundaries. Without those sources, words such as resilient, redundant and highly available would function as advocacy rather than analysis.

Business Network’s public records are valuable because they make some continuity inputs inspectable. They do not prove the final outcome. The distinction preserves a reality layer: records and running routes matter, but service depends on operational systems beyond them.

The route set creates a concrete monitoring baseline

The captured prefix list gives future observations a starting point. Monitoring can compare whether 103.58.72.0/22, 203.76.220.0/22, the additional /24 groups and 2400:4d40::/32 remain visible under AS134204. It can also track whether more-specific routes appear or disappear. The purpose is not to treat every change as an incident, but to notice when the public control surface moves.

Origin consistency is one test. If a prefix appears under another ASN, the change should be compared with APNIC records and RPKI authorization. A legitimate transition may involve updated records and planned routing. An unexplained mismatch may indicate misconfiguration, a stale authorization or an event requiring investigation. Timing and corroboration are essential.

Authorization is another test. The current samples for 103.58.72.0/24 and 2400:4d40::/32 are valid. Future checks can ask whether those results persist and whether other visible prefixes validate. A complete route-set inventory would be more informative than projecting two samples across every announcement.

Neighbour changes offer a third signal. AS58629 and AS58717 form the current observed pair in the RIPEstat response. If one disappears or another appears, the shift can be observed without immediately assigning a commercial meaning. Repeated measurements and other sources would be needed to distinguish routing policy, collector visibility, maintenance and an actual connectivity change.

PeeringDB changes provide a fourth comparison. A new exchange row, removed attachment, changed address or updated configured speed may signal record maintenance or an operational change. The declaration should be checked against exchange and route evidence before supporting a stronger conclusion.

Together, these tests turn a static company name into a dated infrastructure baseline. They do not require speculative claims about users or assets. They ask whether identity, authorization, route visibility and declared interconnection remain coherent over time.

Stronger service claims require stronger evidence

A claim about geographic coverage would need current service maps, licence boundaries, installation evidence or independently verified availability. The operator website supplies a broad self-description but not enough detail to prove where access is live. Prefixes and exchange rows do not encode customer geography.

A claim about capacity would need observed utilization, contracted rates, equipment limits and path constraints. PeeringDB’s configured speeds are not sufficient. Address-space size is not sufficient. Even traffic measurements at one exchange would not describe every access and upstream segment.

A claim about resilience would need independent failure domains, redundant equipment, diverse paths, power and recovery evidence. Two observed neighbours and four declared exchange rows do not establish physical independence. A route can remain visible through a single vulnerable corridor, and multiple logical paths can share the same operational risk.

A claim about service quality would need measurements of latency, loss, throughput, availability and support outcomes across representative users and times. Marketing package speeds do not supply that proof. Neither do valid ROAs, which address origin authorization rather than performance.

A claim about customer impact would need evidence of who relies on the network and for what. Public prefixes may contain infrastructure, customers, servers or unused space. The route table cannot identify critical services or economic dependency. Any impact assessment would need a separate and carefully sourced record.

These requirements do not make the current findings trivial. They make the boundary explicit. AS134204 exposes a meaningful control plane. Stronger statements about the delivery plane remain possible, but they need different sources designed to answer those questions.

Accuracy in public records is itself an infrastructure concern

The internet’s number-resource system depends on uniqueness and traceability. Autonomous-system numbers and address blocks cannot coordinate routing if identities are ambiguous or authorizations drift. Registry contact data, origin records and change history therefore have operational value beyond administrative compliance.

Business Network’s records show several points of alignment. The same ASN and name recur across APNIC and PeeringDB. Visible routes use AS134204. The selected IPv4 and IPv6 samples validate against ROAs naming that origin. The directory entity resolves publicly rather than falling into a missing-profile shell. These alignments make the control surface easier to audit.

Accuracy also requires acknowledging imperfections. A contact check can fail. A PeeringDB declaration can become stale. A route collector can miss a private path. A website can make claims that are not independently measured. No single source should be treated as sovereign over the operating reality.

The best response to uncertainty is not to discard the records. It is to preserve provenance, dates and scope. A registry field can be cited as a registry field. A route observation can be dated. A PeeringDB row can be labelled self-maintained. An operator statement can remain a first-party claim. The distinctions allow later evidence to confirm, correct or supersede the baseline.

For infrastructure accountability, that discipline is more useful than a polished but unsupported profile. It lets operators, peers, registries and readers see which facts are public and which claims still need proof. It also reduces the risk that coordination metadata will be mistaken for a guarantee.

Business Network is visible at the control plane and opaque at delivery

The combined record supports a clear conclusion. Business Network is not merely a generic name in a directory. It is attached to active AS134204 in APNIC, a 36-entry dual-stack route snapshot in RIPEstat, sampled valid origin authorizations, two observed neighbours and four declared exchange attachments in PeeringDB.

That is a meaningful public infrastructure identity. It can be monitored. Origin and prefix changes can be tested. Declared attachment inventory can be compared over time. The operator’s own service claims can be set beside public routing evidence. These are practical accountability tools.

The same evidence cannot show the complete delivery system. It does not prove legal ownership, licence continuity, facility or fibre ownership, customer coverage, sold capacity, utilization, path diversity, uptime, resilience, incident response or restoration performance. It does not convert configured port speeds into service capacity or observed neighbours into contracts.

Holding both sides of the conclusion is essential. Treating the records as empty would ignore a rich technical surface. Treating them as a complete network map would overstate what coordination data can prove. Business Network’s public identity sits between those extremes: inspectable at the registry and routing layers, uncertain at the physical and commercial layers.

The next useful evidence should narrow that uncertainty rather than repeat broad claims. Current legal and licence records could clarify the operating entity. Independent measurements could test reachability and performance. Exchange confirmation could validate attachment status. Continuity disclosures and incident records could support resilience analysis. Until then, AS134204 remains a strong baseline and a deliberately bounded one.

AS134204 links Business Network to routes and four declared exchanges while the delivery layer remains unproved