AS134772 makes Dongguan's dual-stack routing surface visible while metropolitan delivery remains unproved

Summary

APNIC records identify AS134772 as ChinaNet-Guangdong-Dongguan-MAN, with active status and CHINANET Guangdong province Dongguan MAN network as the registry description.
A captured routing snapshot lists six IPv4 and 49 IPv6 announcements, while visibility counters show all 328 sampled IPv4 peers and all 323 sampled IPv6 peers seeing the origin at the query time.
The six IPv4 routes cover 18,432 addresses, and the IPv6 announcements represent 98,309 /48 units in routing arithmetic; neither measure is a subscriber, traffic, sold-capacity or utilisation figure.
One observed routing neighbour, AS4134, is visible in the bounded dataset, but the evidence does not establish an exclusive upstream, a physical interconnection, contractual topology or tested recovery path.
The public record does not prove fibre ownership, access coverage, facilities, customer count, power design, internal topology, service quality, uptime, resilience or the legal boundary between the directory label and wider China Telecom operations.

A metropolitan network identity appears first as a routing object

The name CHINANET Guangdong province Dongguan MAN network sounds physical. It evokes a metropolitan system, a city-scale service area and a relationship to the larger CHINANET organisation. The strongest public evidence in the frozen source set, however, begins somewhere more precise and more limited: AS134772. An autonomous-system number is a routing identifier. It provides a stable point from which an observer can examine registration, announced prefixes and visible relationships without assuming what the network looks like on the ground.

APNIC's registration describes the resource as ChinaNet-Guangdong-Dongguan-MAN and records country code CN. The public directory profile uses the longer CHINANET Guangdong province Dongguan MAN network label. The two descriptions are close enough to bind the directory identity to the number-resource surface examined here. That binding is not a corporate-law finding. It does not establish that the directory label is separately incorporated, nor does it settle how responsibility is divided among a national carrier, provincial operations and a city network.

The value of the ASN is that it lets the analysis remain attached to an observable control surface. AS134772 was announced in the captured RIPEstat overview, and the routing-status response recorded both IPv4 and IPv6 visibility. The number is therefore not merely a dormant registry line. It is associated with routes that collectors could see at a dated query time. That connection between a registry entry and running routing behaviour is the article's evidentiary centre.

The same connection also sets the boundary. An ASN does not describe ducts, cables, aggregation sites, exchange ports, customer circuits or field-repair teams. A city name inside an AS description does not turn a BGP observation into a service map. The public object can be discussed as a routing and number-resource identity while the physical metropolitan delivery system remains unproved.

This distinction matters because infrastructure coverage often starts with the most concrete-sounding label and then fills in the missing engineering details by implication. Here, the evidence supports the opposite method. Begin with the exact records, state what they establish, and keep every missing layer visible. AS134772 shows that a dual-stack routing object exists. It does not, by itself, show what must continue working for a household, business or public service in Dongguan to stay connected.

The APNIC record is an accountability ledger, not a service certificate

Regional Internet registries coordinate unique number resources and publish records that help networks identify one another. APNIC's AS134772 record performs that ledger function. It identifies the autonomous system, records active status, supplies a description and exposes administrative and technical contact context. These are operationally useful facts because routing coordination depends on stable identifiers and reachable responsibility records.

The registration history adds a limited chronology. The source capsule records an October 2015 registration and a last-change date in May 2020. Those dates show when the public record entered the registry and when it was last altered in the captured view. They do not prove that the network began commercial service in 2015, remained unchanged after 2020 or delivered continuous service between those dates. Registry chronology and service chronology are different evidence classes.

The listed Chinanet Hostmaster contact surface is also narrower than it may appear. A technical or administrative contact gives another operator somewhere to direct a routing or resource question. It does not reveal staffing coverage, escalation authority, response time or which team controls the equipment behind a particular route. Contact publication lowers coordination friction; it does not guarantee operational recovery.

Active registry status should be read in the same disciplined way. It supports the conclusion that AS134772 is a current recorded resource in the captured APNIC data. It is not a licence audit, an ownership judgment or a quality mark. The status does not establish that every service associated with the broader CHINANET brand is active, nor that every prefix visible under the ASN is delivered through the same organisation or physical system.

The registry's authority is strongest where the record is designed to be authoritative: uniqueness, allocation context, identifiers and responsibility metadata. It becomes weaker when used as a proxy for physical operation. Treating the registry as a ledger rather than a sovereign description of the network preserves both its usefulness and its limits. The record tells outsiders which routing object they are looking at. It does not certify the metropolitan network behind it.

Six IPv4 announcements make a bounded public footprint

The announced-prefixes response lists six current IPv4 routes associated with AS134772: 211.148.128.0/20, 45.249.212.0/22, 202.173.224.0/20, 202.173.240.0/20, 211.148.144.0/20 and 103.218.216.0/22. Together, the routing-status arithmetic counts 18,432 IPv4 addresses. That is a substantial public address-space footprint, but it is still only a measure of announced address space.

The prefixes differ in size and address range. Three /20 announcements each contain 4,096 addresses, while the two /22s each contain 1,024. Their appearance under one origin gives an observer a set of route objects that can be monitored over time. It does not show whether the prefixes serve residential access, enterprise circuits, infrastructure systems, customer delegations or internal services. Public routing data does not expose that allocation detail.

Nor does the total translate into customers. Carrier-grade address sharing can place many users behind fewer public addresses. Dedicated services can consume addresses without representing large subscriber counts. Some space may be reserved, sparsely used or assigned for functions that are invisible to an external observer. The number 18,432 is exact within the route arithmetic and misleading if converted into a business metric.

The route list does establish a useful baseline. A future disappearance, origin change, more-specific announcement or unexpected additional prefix would be a concrete event to investigate. Such a change could result from planned engineering, a registry update, traffic policy, a route leak, a measurement difference or an outage. The baseline helps identify change; it cannot identify cause without additional evidence.

The six routes also resist a simple geography claim. Nothing in the route objects proves that every address terminates in Dongguan. Networks can originate space used across facilities or service areas, and routing policy may aggregate resources whose physical endpoints differ. The exact supported statement is that AS134772 originated these six IPv4 prefixes in the captured public view. A citywide coverage map would require evidence that the source set does not contain.

Forty-nine IPv6 routes show scale without revealing use

The IPv6 footprint is numerically larger. RIPEstat lists 49 IPv6 announcements under AS134772 and calculates 98,309 /48 units in the announced-space summary. The routes include aggregates and more-specifics at several lengths under 240e:: address space. This establishes a visible IPv6 routing surface rather than a merely theoretical dual-stack capability.

IPv6 arithmetic requires particular care. A count of /48 units is a way of normalising prefixes for comparison. It is not a count of networks in production, customers served or sites connected. An IPv6 allocation can be deliberately spacious so that addressing remains hierarchical and operationally manageable. Large numerical capacity is a feature of the protocol and assignment architecture, not proof of commercial scale.

The 49 announcements likewise do not reveal why the network uses those prefix lengths. More-specific routes may reflect policy, aggregation boundaries, customer arrangements, migration or traffic engineering. The frozen evidence does not state the design intent. Describing a route pattern is legitimate; assigning an engineering purpose without operator documentation would be speculation.

What the IPv6 view does provide is a second family of observable continuity signals. An external monitor can watch whether the IPv6 prefixes remain visible, whether their origin changes and whether the mix of aggregates and more-specifics shifts. Comparing those changes with the six IPv4 announcements may help distinguish a family-specific routing event from a wider origin failure. Even then, collector data alone cannot show customer impact.

The dual-stack footprint is therefore important because it broadens the public control surface. It does not settle the service question. The source set contains no verified account of which customers receive IPv6, whether access products are dual-stack, how address assignments are managed or how IPv4 and IPv6 paths differ physically. The routes are visible. The delivery architecture behind them is not.

Route visibility is a snapshot, not an availability percentage

At the query time, RIPEstat reported all 328 sampled IPv4 peers seeing AS134772 and all 323 sampled IPv6 peers seeing it. Within that collector view, the origin had broad visibility in both address families. The result is stronger than a bare assertion that the ASN was announced because it records the observed numerator and denominator for each family.

Those ratios should not be converted into uptime. A 328-of-328 observation is not a 100 per cent availability measurement, and 323-of-323 is not a service-level result. Availability requires a time interval, a defined endpoint, a sampling method and a rule for what constitutes success. The routing snapshot represents one control-plane view at one moment.

The peer set is also not the whole Internet. RIPE RIS collectors observe routes through particular sessions and locations. Their view is broad and operationally useful, but it remains a sample. A network or region outside that sample may receive a different route, apply a different policy or experience a problem that does not appear in the aggregate counters.

Most importantly, route visibility and service delivery can diverge. A prefix may remain visible while an access ring, aggregation switch, DNS dependency, power feed or customer circuit has failed. A route can be present even when packets are dropped deeper in the network. Conversely, some local services may continue during a wider control-plane disturbance. BGP is one layer in the dependency chain.

The correct conclusion is precise: AS134772 was fully visible to the sampled IPv4 and IPv6 peers represented in the captured response. That fact supports a real, globally observable routing presence. It does not establish historical uptime, universal reachability, low latency, service quality or resilience. Repeated snapshots and service-layer measurements would be required to answer those questions.

One visible neighbour identifies a relationship, not the contract

The neighbour dataset reports one observed neighbour, AS4134, on the left side of the captured path view. AS4134 is therefore part of the visible routing context around AS134772 in this bounded source. The observation gives researchers a concrete relationship to monitor, but it does not reveal the commercial or physical arrangement behind it.

Terms such as upstream, transit provider, peer, customer and backup have meanings that cannot be assigned safely from one observed adjacency. BGP paths reflect selection policy and collector position. A route server, selective announcement or unobserved alternate path can make the public graph incomplete. The data does not describe contract terms, payment, responsibility or exclusivity.

The single observed neighbour is not proof that the Dongguan network is single-homed. Other adjacencies may be private, absent from the selected collectors or not chosen into visible paths at the query time. It is equally not proof of redundancy. One visible relationship does not show separate circuits, diverse conduits, independent power, alternate facilities or tested failover.

AS4134's appearance is nevertheless operationally relevant. If the observed relationship disappears while AS134772's routes change or vanish, the coincidence may guide investigation. If new neighbours become visible, the baseline can document an altered routing surface. Those observations remain clues until matched with operator statements, facility evidence or incident records.

The responsible wording is therefore narrow: AS4134 was the one neighbour observed in the captured RIPEstat neighbour response. The evidence does not establish that it is the exclusive upstream, the only external dependency or a physically diverse recovery path. A routing relationship is visible; the delivery and contractual boundaries remain undisclosed.

Dual-stack visibility does not prove dual-stack customer service

It is tempting to infer that a network with visible IPv4 and IPv6 routes provides dual-stack access across its metropolitan footprint. The evidence supports a weaker statement. AS134772 originates routes in both address families. The source set does not connect those origins to a product catalogue, customer configuration or verified service endpoint.

IPv6 could be available across access services, limited to infrastructure, used by selected customers or delivered through arrangements not described publicly. IPv4 may also be delivered differently across customer types. Without configuration evidence or a tested endpoint, the presence of both route families at the origin cannot establish how they reach users.

The distinction matters for failure analysis. IPv4 and IPv6 may share the same router, circuit and power dependency, or they may diverge at some point in the path. A family-specific routing incident can affect one while the other remains visible. A shared access failure can affect both while the external routes remain stable. The public data cannot reveal which architecture applies.

A useful operational disclosure would identify the service classes that receive both protocols, the aggregation points involved and the policy used when one family loses reachability. Customer-side measurements from multiple locations could then test whether the public origin view corresponds to delivered service. None of that evidence appears in the frozen capsule.

The current dual-stack record should still be treated as a meaningful positive fact. It gives the network a larger and more modern public routing surface than an IPv4-only origin would have. The limitation is not that the routes lack value; it is that route visibility belongs to the control plane. Customer service requires proof from the access and forwarding layers as well.

Registry descriptions should not be stretched into corporate structure

The APNIC description and directory name both include CHINANET, Guangdong, Dongguan and MAN network language. That alignment supports the technical identity used here. It does not provide a complete legal-entity map. Large telecommunications groups often separate national, provincial, municipal and operational responsibilities in ways that a routing label does not capture.

The record names Chinanet Hostmaster in contact context, but a hostmaster role is not an incorporation document. It can identify an administrative function without specifying which company owns equipment, signs customer contracts or carries liability. The source set contains no corporate filing that resolves those questions for the directory label.

This boundary affects the article's language. It is accurate to say that APNIC records AS134772 as ChinaNet-Guangdong-Dongguan-MAN and that the BTW directory object uses the corresponding CHINANET Guangdong province Dongguan MAN network name. It would be stronger than the evidence to declare the object an independent company or to assign all broader China Telecom assets and obligations to it.

The same caution applies to ownership. A route origin can be operated under delegated authority, shared administration or organisational arrangements that are not visible in RDAP. The public route does not show who owns fibre, buildings, routers or power systems. It records the ASN that originates reachability and the contacts attached to the resource.

For readers, the result is a technical profile rather than a corporate profile. The object is defensible as a network-resource identity with a city and provincial label. Its legal and operational perimeter remains an explicit research gap. Future work should rely on current corporate filings, licences or operator documentation before making ownership claims.

The physical metropolitan network is the largest missing layer

The phrase MAN network refers to a metropolitan-area network, but the source capsule does not contain a physical topology. There are no verified fibre routes, aggregation sites, exchange locations, street cabinets, access nodes, towers or customer-premises systems. The article therefore cannot map the network or state which assets are controlled by the directory object.

That absence is central rather than incidental. Physical infrastructure determines how a service fails. A route origin can remain stable while a feeder fibre is cut, an aggregation site loses power or a local configuration change isolates customers. The public routing layer may show no change during a severe access-layer incident.

Capacity is also missing. Prefix counts and address-space arithmetic do not reveal installed optical capacity, lit capacity, sold capacity or usable headroom. A /20 route can carry almost no traffic or support a major service population. Forty-nine IPv6 prefixes can represent careful addressing without indicating bandwidth. No evidence in the capsule supports a throughput figure.

Redundancy cannot be inferred from route multiplicity. Six IPv4 routes and many IPv6 routes may share the same physical dependencies. Even multiple external adjacencies would not prove conduit, facility or power diversity. Redundancy becomes credible only when failure paths are documented or tested and the supposedly independent elements do not fail together.

The physical gap defines the next evidence priority. Useful records would include fibre or facility disclosures, interconnection sites, power arrangements, access technologies, maintenance boundaries and incident reports. Until those exist, AS134772 should be treated as an observable routing surface whose metropolitan delivery system remains outside the public view.

The city label is not a coverage map

Dongguan appears in both the directory object and the AS description. That supports the association between the routing identity and the city. It does not establish the geographic extent of service. A metropolitan label can describe administrative responsibility, an origin context or a network function without defining every location reached by customer access.

The announced prefixes also lack geographic termination data. An IP address can be used far from a registry contact or organisational label. Geolocation databases are estimates and are not part of the frozen source set. The routes do not reveal whether all endpoints are inside Dongguan, distributed across Guangdong or used for infrastructure elsewhere.

Coverage claims require different evidence: verified service-area documentation, address qualification, licences, facility records or direct measurements tied to known locations. None appears here. A map derived from the city name and prefix set would create a visual certainty that the sources do not support.

This is especially important for a large urban and industrial area. Different neighbourhoods, business districts and industrial parks can depend on different access systems and upstream paths. A network may have a strong presence in one segment and little or none in another. A single metropolitan label hides that variation.

The article therefore uses Dongguan as part of the recorded identity, not as a claim of citywide reach. The public evidence supports a network object associated with Dongguan and Guangdong. It does not support a boundary line, subscriber footprint or statement that the visible routes terminate exclusively within the municipality.

Public contact data creates a coordination surface

Operational networks need a way for other networks to reach the responsible team. APNIC's registration provides administrative and technical contact context through Chinanet Hostmaster. That creates a coordination surface for resource, routing or abuse questions and helps tie communication to the exact ASN under review.

The contact surface is valuable because failures often cross organisational boundaries. A route leak, abuse report or misconfiguration may need cooperation between networks that have no commercial relationship. Registry contacts reduce the cost of finding the correct destination and preserve a record that can be checked over time.

Publication does not prove responsiveness. The source set does not show whether messages are monitored continuously, which team receives them, what escalation process applies or how quickly changes can be authorised. A contact can be technically valid while operational handling remains slow or fragmented.

The role also should not be stretched into an ownership claim. A hostmaster may administer resources for a broader organisation without owning the physical systems that use them. The record does not resolve responsibility for local fibre repair, customer support, power restoration or facility access.

The defensible conclusion is that AS134772 has a public registry coordination surface. That is better than an uncontactable routing object, but it is not evidence of support quality or recovery performance. Incident-response claims would require dated cases showing how the organisation acted when the network was under stress.

Registration and routing dates describe different clocks

The public record contains several dates: registration in October 2015, a last registry change in May 2020, first visibility in the routing-status data in February 2017 and a latest observed route at the July 2026 query time. These timestamps describe different systems and should not be collapsed into one operational timeline.

Registration establishes when the number-resource record entered the captured registry history. It does not necessarily mark commercial launch. First visibility records the earliest route observation represented by the service response, not the first packet delivered to a customer. A last-change field may reflect administrative maintenance without any network redesign.

The gap between registration and first observed visibility can have many explanations: provisioning, measurement scope, changed origin policy or historical data coverage. The sources do not identify the cause. Presenting the interval as a construction or commissioning period would invent a physical narrative.

The latest observed route shows that the routing object remained visible at the captured query time. It does not prove uninterrupted continuity since 2017. Outages, withdrawals or policy changes could have occurred between snapshots. A time series would be needed to describe stability.

Keeping the clocks separate improves future monitoring. Registry changes can be compared with route changes without assuming that one caused the other. Operational events can be added when independently documented. The current evidence supports a dated administrative and routing baseline, not a complete service history.

A widely visible origin can still depend on narrow failure points

Broad collector visibility may coexist with concentrated physical dependencies. If multiple prefixes leave through the same router, facility, power feed or conduit, they can fail together even when the route table normally appears diverse. The source set does not show whether AS134772 has such shared components.

The observed AS4134 relationship could represent an important external dependency, but its physical form is unknown. One logical adjacency may use multiple circuits, or several logical paths may share one conduit. BGP data cannot distinguish those cases. Commercial and facility evidence is needed to assess concentration.

Access delivery adds another layer. A metropolitan network may depend on local fibre rings, aggregation equipment, customer power, field crews and third-party poles or ducts. None of those dependencies appears in the routing records. Their absence prevents a claim that the visible dual-stack origin translates into resilient service.

Recovery is equally unproved. There are no dated failover tests, mean-time-to-repair records, spare inventories or incident reports in the capsule. Without those facts, redundancy should be treated as a question rather than a property. A design diagram alone would still not prove that recovery works under pressure.

The public routing surface remains valuable because it identifies what an external monitor can watch during an incident. Changes in prefix visibility, origin or neighbour observations can narrow the search. They cannot replace evidence from the physical, power and operational layers where many customer-impacting failures occur.

The prefix set is a monitoring baseline, not a topology model

The six IPv4 and 49 IPv6 announcements can be stored as a dated baseline. A monitoring system can compare future snapshots for additions, withdrawals, origin changes and more-specific routes. This creates a repeatable way to detect changes without claiming to know the internal network.

Not every change is harmful. New prefixes may reflect growth, renumbering or policy. A more-specific route may support traffic engineering. A temporary withdrawal may be maintenance or an incident. The baseline signals that a question should be asked; it does not supply the answer.

The same principle applies to neighbour data. If AS4134 disappears or additional neighbours become visible, the public graph has changed. Collector selection and path preference can also change the view. Multiple data sources and repeated observations are needed before interpreting the operational significance.

Registry records should be monitored alongside routes. A changed contact, status or description may precede or follow a routing transition. Alignment across the layers can strengthen confidence that the public identity remains coherent. Misalignment is a reason for investigation, not automatic proof of error or misconduct.

The baseline's strength is its bounded reproducibility. Anyone can query the same public systems and compare dated results. Its weakness is that it remains outside the network. It sees advertised control-plane state, not internal forwarding, customer reachability, power or repair. A good monitoring programme preserves both facts.

A disciplined comparison should also retain the original response dates and the exact query scope. Prefix sets, peer counts and neighbour observations can change between requests without an underlying failure. A later review should therefore preserve each raw response, compare like with like and identify whether a difference comes from the network, the collector population or the query itself. That procedure does not make the public view complete, but it prevents a measurement change from being presented as an operating event.

IPv4 and IPv6 should be compared without assuming symmetry

The current view shows six IPv4 routes and 49 IPv6 routes, with full sampled visibility for each family. The difference in route count does not mean IPv6 carries more traffic or serves more customers. Addressing architectures and aggregation practices differ between the protocols.

The families may also have different external paths. The frozen neighbour summary does not provide a complete per-family contract or facility map. Even if both families show AS4134 in selected paths, their sessions, filters or physical circuits could differ. The evidence does not resolve that architecture.

Operational monitoring should therefore compare the families but avoid assuming symmetry. A withdrawal affecting only IPv6 may expose a family-specific policy or session issue. Simultaneous loss may point toward a shared origin or external dependency. Customer impact still requires service measurements.

Address-space arithmetic also needs separate interpretation. The 18,432 IPv4 addresses are scarce units with possible sharing and reservation. The 98,309 /48 IPv6 units are a normalised measure of a vastly larger address design. Putting the raw figures side by side as if they were equivalent capacity would mislead.

The supported conclusion is that AS134772 has a visible dual-stack origin surface with distinct route structures. That is enough to justify continued observation. It is not enough to describe product availability, traffic mix, customer migration or the physical independence of the two protocol paths.

The evidence does not establish capacity or utilisation

Infrastructure reporting often looks for a capacity figure. The source capsule does not contain one. Prefix size measures address space. Peer visibility measures observed route propagation. Neighbour count measures a bounded graph view. None is bandwidth, traffic, sold capacity or usable headroom.

Installed capacity would require information about links, equipment and configured rates. Lit capacity would require confirmation that systems are active. Sold capacity would require commercial data. Usable capacity would have to account for contention, failure reserves, protocol overhead, maintenance and downstream bottlenecks. The public records provide none of those layers.

It would also be wrong to infer scale from IPv6. A large allocation is designed to permit hierarchical addressing and long-term operation. The number of possible addresses is not a measure of current use. Sparse utilisation can be entirely appropriate.

Traffic cannot be inferred from route visibility either. A route can be seen globally while carrying little traffic. Conversely, a small number of prefixes can carry large volumes. Public BGP data describes reachability statements, not packet counters.

The absence of capacity evidence is a finding because it identifies a disclosure gap. Readers can see the control-plane outline but cannot assess congestion risk, growth headroom or the effect of a circuit failure. Those questions require operator data or independent measurements, not arithmetic performed on registry fields.

The public record does not document outage and recovery behaviour

No verified outage history appears in the frozen sources. That means the article cannot assess how AS134772 or the associated metropolitan delivery surface behaved during a real failure. Resilience claims require evidence from the moments when dependencies break.

A useful incident record would state what failed, which services were affected, when detection occurred, which alternate path was used and how long restoration took. It would distinguish a route withdrawal from an access outage, a power failure from a configuration error and a partial degradation from a full loss.

The current routing snapshot can serve as a reference for future incidents. If prefixes vanish, visibility falls or the origin changes, investigators can compare the event with the baseline. If routes remain stable while customers report loss, attention can shift toward access, forwarding, DNS, power or application layers.

Recovery evidence should also test independence. Two links that share a conduit can fail together. Backup power that has not been tested under load may not sustain a site. Alternate routes that depend on the same facility may not provide meaningful diversity. None of those conditions can be evaluated from AS and prefix data.

The correct present statement is therefore not that the network is resilient or fragile. It is that the public control surface is observable while resilience remains unproved. That formulation leaves space for future incident evidence and avoids converting the absence of a documented failure into evidence of uninterrupted service.

Questions that would close the physical and operational gap

The first set of questions concerns identity and control. Which legal entity operates AS134772 today? How is responsibility divided among national, provincial and Dongguan teams? Who owns the routers, fibre, facilities and customer contracts associated with the directory object? Current filings and operator documentation could resolve those boundaries.

The second concerns topology. Where are the external interconnection points? How many sessions can carry the six IPv4 and 49 IPv6 announcements? Which circuits and facilities support them, and are the physical paths independent? The observed AS4134 relationship gives a starting point but not the answer.

The third concerns access delivery. Which technologies connect customers, which service areas are verified and where do third-party ducts, poles, buildings or power systems become dependencies? How are customer-impacting failures isolated from the public route origin? These facts would connect the routing object to the metropolitan network implied by its name.

The fourth concerns capacity and recovery. What capacity is installed, lit, sold and usable? What headroom is preserved for failure? Which components have tested failover, and what do incident records show about detection and repair? A credible resilience assessment needs dated operational results.

The final questions concern protocol continuity. Which services are dual-stack, how do IPv4 and IPv6 paths differ, and what happens when one family loses reachability? Answers tied to measurements and current topology would turn the visible dual-stack origin into a fuller account of service delivery without asking the registry to prove what it cannot see.

A defensible reading of AS134772's public surface

The public record supports a clear but bounded conclusion. AS134772 is an active APNIC-registered routing identity described as ChinaNet-Guangdong-Dongguan-MAN. At the captured time it originated six IPv4 and 49 IPv6 prefixes, was visible to all sampled peers in both address families and had one observed AS4134 neighbour in the selected dataset.

These facts make the network-resource surface inspectable. They establish a useful baseline for monitoring prefix visibility, origin continuity, neighbour changes and registry maintenance. The IPv4 and IPv6 observations show running routing behaviour rather than a purely administrative record.

The baseline is also actionable without becoming promotional. Network operators can use the identifiers to coordinate, researchers can watch for route changes, and readers can see which conclusions remain unsupported. Its practical value lies in making uncertainty specific: six IPv4 routes, 49 IPv6 routes and one observed neighbour are known; physical paths, service reach and recovery behaviour are not.

They do not reveal the metropolitan delivery system. The evidence does not establish fibre ownership, facilities, geographic coverage, customer count, capacity, traffic, power, internal topology, service quality, uptime, redundancy or recovery performance. It also does not settle the legal boundary between the directory label and wider CHINANET or China Telecom operations.

That gap should not be filled with generic corporate description. The more useful account follows the physical dependency and marks where the evidence stops. Routes depend on routers, circuits, facilities, power, access systems and operating teams. The public sources expose the first layer and leave the rest for further verification.

AS134772 therefore matters as a reality-layer object: a registry ledger linked to visible running code. Its legitimacy as evidence comes from uniqueness, dated records and observable announcements, not from an implied claim to describe the whole network. The metropolitan service boundary remains unproved, and that is the most important fact future reporting should try to close.