AS9245 Shows the Dual-Stack Routing Footprint Behind Compass, Not Its Service Resilience

Summary

• APNIC RDAP identifies AS9245 as the active COMPASS-NZ-AP registration and names Compass Communications Ltd as its registrant.
• RIPEstat marked AS9245 announced at 3 August 2026 00:00 UTC, with full visibility across the IPv4 and IPv6 RIS peer totals in its dated response.
• The same routing response summarized 12 IPv4 prefixes covering 25,600 addresses, one IPv6 prefix representing 65,536 /48s, and eight observed neighbours.
• A bounded two-week prefix view returned 13 announcements, including 2405:8400::/32 and twelve IPv4 blocks from /24 through /19.
• PeeringDB's operator-maintained row describes AS9245 as a Cable/DSL/ISP network with Asia-Pacific scope and an open general policy.
• Compass describes a wider access, voice, managed-service and data-centre business, but its service claims do not independently establish AS9245 capacity, topology or performance.
• A public routing footprint proves that an origin is visible through the represented control plane. It does not prove that a subscriber can reach a service or that a failover design will work.
• The useful control surface is the separation between recorded identity, observed route execution, operator declarations and customer-facing service evidence.

Generic editorial illustration of dual-stack route visibility meeting a service-evidence boundary; it does not depict Compass infrastructure, topology, access quality, capacity, customer service or resilience.

AS9245 provides a precise network identity

An autonomous-system number is useful because it gives routing policy a stable public identifier. In this case, APNIC RDAP records AS9245 under the name COMPASS-NZ-AP, marks it active and assigns the country code NZ. The record is not merely a search result that happens to contain the word Compass. It is the administrative object for the number that appears as an origin in public routing observations.

The registrant vCard names Compass Communications Ltd. A separate technical and administrative contact is labelled Network Operations, while the abuse role uses IRT-COMPASSCOM-NZ. Together, those fields create a recorded responsibility surface. They offer an operator name, an operational contact function and an incident-response identity that can be compared with the behaviour of the number over time.

That precision matters because the public directory uses the network-facing label COMPASS-NZ-AP COMPASS. The directory label, APNIC handle and legal registrant name are related, but they are not identical strings. Treating them as layers of one bounded network identity is more accurate than pretending that an alias, a registry object and an incorporated name are interchangeable.

The registration also has a narrow authority. It records the allocation and administration of AS9245. It does not certify every claim made on a commercial website, establish beneficial ownership, prove the scope of a telecommunications licence or identify the physical assets used to deliver a service. Its strength lies in uniqueness, traceability and continuity of recorded responsibility.

The word active must be kept inside that boundary. It means the APNIC object is active. It does not by itself mean that every prefix is announced, every route is accepted, every customer circuit is working or every operational contact is responding. A registry status and a service status answer different questions.

For infrastructure monitoring, that distinction is constructive rather than limiting. The stable administrative identity makes it possible to ask whether AS9245 is currently visible, which address families appear, what prefixes are observed and how that footprint changes. The registry provides the recorded anchor for those questions without claiming to answer them all.

Public routing shows execution at a dated moment

RIPEstat's overview marked AS9245 announced at 3 August 2026 00:00 UTC. That is a running-system observation rather than a company description. It means the data service saw AS9245 functioning as an origin in the public routing information represented by its collectors at the query time.

The timestamp is part of the finding. BGP is a changing control plane, and an observation made at midnight UTC is not a timeless certification. A later query can show the same footprint, a larger or smaller one, or no announcement at all. The evidence is strongest when the time travels with the number.

An announced AS is still not equivalent to an available service. BGP distributes path information between networks. A route can be present while an application fails, an access link is congested, a customer is misconfigured or a facility has a local problem. Conversely, some private services and internal paths may operate without appearing as a separate public origin in the same way.

The announced flag also does not establish why the routes exist. It cannot identify the commercial product, customer group, location or physical circuit behind an announcement. It does not say whether a prefix supports broadband access, voice, hosting, management traffic or another function. Those assignments require evidence beyond an origin number.

What the public signal provides is a measurable control point. It can be compared with APNIC's administrative identity and with later route observations. That comparison can reveal continuity, a withdrawal, a protocol-family change or a shift in the prefix set without inventing a service narrative.

The operating discipline is simple: use the registry to identify the number and the route collector to observe execution. Do not ask the registry to prove execution, and do not ask BGP to prove legal identity or customer experience. AS9245 is legible because both layers can be held together without collapsing them.

Full represented-peer visibility is broad, not universal

The RIPEstat routing-status response reported 329 of 329 represented IPv4 RIS peers seeing AS9245. It also reported 321 of 321 represented IPv6 peers seeing the autonomous system. Within that dated collector view, the origin was not marginal or confined to a small fraction of the listed full-feed peers.

The denominators make the statement auditable. Saying that a network was globally visible would be too broad because no collector system represents every router and every private interconnection. Saying that all represented peers in the response saw the origin preserves both the strength of the observation and its limit.

Broad collector visibility usually indicates that the control-plane information propagated across the public routing system covered by those feeds. It does not show whether traffic followed every advertised path, whether reachability was symmetric or whether an end user received acceptable latency and loss. The collector sees routing information, not the complete data-plane experience.

The distinction becomes important when resilience language appears elsewhere. A route visible to every represented peer may still depend on shared fibre, common power, one facility or one operational process. The routing response contains no physical-path inventory and no failure-domain analysis. Visibility cannot fill those missing layers.

Nor does the response identify the nature of the eight observed neighbours listed for AS9245. A path neighbour can reflect a customer, provider, peer, route-server relationship or another routing adjacency visible in collected paths. It does not automatically reveal contract terms, physical cross-connects or traffic exchange.

The result is therefore a strong statement about public control-plane presence at one time. AS9245 was broadly visible across the represented IPv4 and IPv6 peer sets. The same result must remain silent on universal reachability, private paths, user experience and the independence of the infrastructure that carried the routes.

The IPv4 footprint has measurable size but unknown use

RIPEstat summarized 12 IPv4 prefixes and 25,600 addresses for AS9245. The bounded announced-prefixes view returned twelve IPv4 blocks: two /19s, one /21, six /22s, one /23 and two /24s. This creates a concrete public footprint that can be inspected rather than guessed from a company description.

The two largest blocks in the captured list are 182.48.128.0/19 and 203.152.96.0/19. The remaining prefixes include 202.90.56.0/21, several /22 networks and smaller /23 and /24 announcements. Their presence supports an origin-level account of AS9245, not a claim about which product or customer each block serves.

Address count is often mistaken for capacity. Twenty-five thousand six hundred IPv4 addresses do not reveal bandwidth, subscriber totals, utilisation, revenue or traffic. A prefix can support many forms of service, reserve space for future use or contain addresses with very different roles. BGP exposes reachability aggregates, not a commercial inventory.

The list also does not prove exclusive operational control of every address at every moment. APNIC administration, route origin and downstream use are related but separate. More specific routes, delegated functions, customer arrangements or changes outside the query window can alter what is seen without changing the broad operator identity.

Geography is similarly unresolved. The APNIC country field and operator context point to New Zealand, but an announced prefix does not carry a complete physical map. Routing may involve regional and international facilities, transit paths and remote services. A prefix cannot be placed in a city or data centre without additional evidence.

The IPv4 set is most useful as a baseline. Future observations can record additions, withdrawals or changes in prefix length. Those changes may prompt operational questions, but they should not be assigned a cause without a verified statement. The footprint is evidence of public routing, not a substitute for service or topology documentation.

One IPv6 aggregate changes the scale of interpretation

The same RIPEstat response summarized one IPv6 prefix and expressed its size as 65,536 /48 equivalents. The announced-prefixes view identifies that aggregate as 2405:8400::/32. This confirms that AS9245's public footprint is dual-stack in the dated observation.

IPv6 scale is easy to misread when it is translated into familiar address-count language. A /32 contains an enormous number of individual addresses, but that arithmetic does not describe users, traffic, deployed interfaces or service coverage. The /48-equivalent measure is a routing and allocation scale, not evidence that every possible subnet is active.

The single aggregate also says nothing about adoption inside the operator's access network. A visible IPv6 origin can support production services, infrastructure, customers or future deployment, but the route itself does not distinguish among them. It proves the aggregate is announced from AS9245 in the observed control plane.

Visibility across all 321 represented IPv6 peers in the response indicates broad propagation of that routing information. It does not prove successful end-to-end IPv6 connectivity from every subscriber or application. DNS, host configuration, filtering, access equipment and upstream paths can all affect a user's experience beyond the origin announcement.

The contrast with twelve IPv4 prefixes is informative without implying a hierarchy. IPv4 appears as several blocks while IPv6 appears as one aggregate. That may reflect address-management and routing practices, but no operational rationale is stated. The difference should be recorded rather than explained by speculation.

For future monitoring, the IPv6 aggregate supplies a clear reference. A withdrawal, a more-specific announcement or a change in represented-peer visibility would be measurable. The current snapshot establishes dual-stack presence while preserving the gap between address-family visibility and service quality.

The prefix window establishes continuity, not permanence

The announced-prefixes query covered 20 July through 3 August 2026. Each of the thirteen returned prefixes carried a timeline spanning the bounded window. That consistency supports a statement that the observed set persisted through the queried period, rather than appearing only at the final instant.

A two-week window remains short in the life of a network. It cannot establish years of continuity or the absence of brief changes that the summarized response does not expose. It is a practical monitoring interval, not a lifetime availability record.

RIPEstat's routing-status data adds a much longer historical marker. The first recorded observation for AS9245 was 203.98.24.0/24 on 18 August 2000. The latest field at the current query time used 202.90.56.0/21. These endpoints show a long public routing history but not a continuous list of everything announced between them.

First seen is not the same as a corporate launch date. It reflects the observation available to the routing data service. The network or company may have existed earlier, and collector coverage may have changed. The value should not be turned into a business anniversary or a claim about the first packet carried.

Latest seen is not a service-health verdict either. It identifies a route observed at the query time. It does not mean that every historical block remained unchanged or that no route flap occurred. A continuous operational account would require a more granular time series.

The combination is still valuable. It places the current dual-stack footprint within a history that reaches back more than two decades. The correct conclusion is continuity of observable network identity across time, not permanence of topology, performance or service conditions.

PeeringDB records an operator declaration, not a measurement

PeeringDB's network response names Compass Communications Ltd, assigns ASN 9245 and classifies the network as Cable/DSL/ISP with Asia-Pacific scope. The general policy is listed as open. These fields help other networks understand how the operator presents itself in an interconnection directory.

The entry declares 50 IPv4 prefixes and 50 IPv6 prefixes. Those figures are not the same as RIPEstat's dated count of twelve IPv4 prefixes and one IPv6 aggregate. The difference does not necessarily indicate an error because the systems record different things using different methods and update cycles.

PeeringDB is operator-maintained. Its fields can describe policy, expected footprint or information supplied for interconnection coordination. RIPEstat derives observations from route collectors. One should not be used to silently overwrite the other, and agreement should not be assumed where the definitions differ.

The open-policy field also has a limited meaning. It may indicate a general interconnection posture, but it does not prove that a particular peer was accepted, that a session exists, that traffic is exchanged or that terms are settlement-free. Policy is an invitation to inquiry, not evidence of execution.

The Cable/DSL/ISP label supports the broader access-provider context visible on Compass's own site. It does not bind a particular broadband line, voice service, cloud system or data-centre customer to AS9245. The network identity remains exact while the product mapping remains open.

The most useful reading treats PeeringDB as another coordination record. It helps connect the AS number to the operator's declared role and interconnection posture. Its claims gain operational meaning only when compared with current routing and other direct evidence, and they should remain attributed to the operator-maintained record.

The company describes a wider service portfolio

Compass says it began in 1995 and describes itself as a New Zealand-owned independent internet and telecommunications provider. Its public material lists fibre, VDSL and ADSL access, rural connectivity, voice products, cloud PBX, hosted services, managed services and data-centre offerings.

This portfolio provides business context for the network identity. It explains why an autonomous system and a set of public prefixes may sit behind a company that operates across access and enterprise services. The site does not, however, identify which product uses which AS9245 prefix or path.

The phrase nationwide network is an operator claim rather than an independently mapped topology. It can be quoted as the company's description, but it does not reveal nodes, fibre routes, leased segments, access partners or failure domains. A national commercial reach can also depend on wholesale arrangements that are not visible in BGP.

The list of access technologies should not be converted into a coverage map. Fibre, VDSL, ADSL and rural services have different physical and wholesale dependencies. The public page does not establish availability at a specific address, subscriber count, access speed or the proportion of service carried on owned infrastructure.

Voice and hosted services add another layer. A telecommunications provider can operate applications and managed platforms that depend on routing but are not described by an AS-level prefix list. Their continuity depends on systems, data, power, configuration and suppliers beyond the public origin.

The portfolio therefore gives AS9245 commercial context without turning it into proof. Compass is not merely a name attached to a dormant record; it presents an active service business. The routing footprint shows a visible control-plane identity. The connection between specific services and specific routes remains unproven.

Named interconnections do not reveal active sessions

Compass's data-centre page names several access and connectivity providers in the context of interconnection arrangements. Such a list can show the breadth of counterparties the operator says it works with. It cannot establish that every named relationship is active at the query time or that every service uses the same path.

An interconnect agreement is not equivalent to a BGP neighbour visible in a collector. It can cover wholesale access, layer-two transport, voice, data-centre connectivity or another service. The eight observed neighbours in the routing response should not be matched to the names on the company page without direct evidence.

Physical presence is also unresolved. A commercial relationship may involve a local cross-connect, a remote port, leased capacity or access delivered through another network. The page does not provide the circuit identifiers or facility records needed to reconstruct those arrangements.

Resilience cannot be inferred from the number of names. Multiple suppliers can improve optionality, but they can also share ducts, exchanges, power systems, software, operations or upstream dependencies. A list of counterparties is not a failure-domain analysis.

The same restraint applies to geographic claims. A provider name may operate nationally or internationally, yet the relationship could terminate at one location. The evidence considered here does not show where AS9245 peers, where routes enter or leave, or which facilities carry customer traffic.

The operator statement is still relevant. It places Compass within a wider interconnection ecosystem and helps explain why the company's services may involve more than one infrastructure owner. Its value lies in attributed context, not in a reconstructed topology that the page does not publish.

Data-centre descriptions sit beyond the route view

Compass's data-centre material describes facilities in Auckland and Hamilton and presents colocation, hosted and telecommunications services. It also says the data-centre offer uses the company's national network. Those statements connect physical-service language to the wider operator brand.

AS9245's route footprint does not identify a building. An origin announcement can be generated or propagated through many locations, and a data centre can host systems using several networks. No prefix in the bounded list is publicly assigned to a named Compass facility by the evidence considered here.

The word own requires similar care. Commercial pages can use ownership language for infrastructure, service control or branded operation. Without property, corporate or facility records, the claim should remain attributed. It should not be expanded into legal title over buildings, fibre or every component of the service.

Colocation and hosted services have dependencies that BGP cannot expose. Power, cooling, fire protection, access control, server hardware, storage, local switching and operational procedures all affect continuity. Public route visibility can coexist with a local facility incident or an application failure.

Conversely, a route change does not prove a facility problem. Network maintenance, policy adjustment or upstream changes can alter public paths while the physical site remains available. Linking the two requires incident evidence, not proximity in a company description.

The data-centre context therefore marks the boundary of the routing evidence. Compass describes a business that spans physical and digital layers. AS9245 makes one control-plane layer visible. It cannot certify the facilities or the services operating behind it.

A 99.99 percent SLA is a promise with conditions

The data-centre page advertises a 99.99 percent service-level agreement. An SLA is a contractual or commercial commitment defined by scope, exclusions, measurement method, remedies and service boundaries. A percentage on a public page does not reveal all of those terms.

The figure should not be treated as measured historical uptime. It does not show the observation period, incidents, exclusions or whether a particular customer received a credit. Public routing data cannot independently confirm it because route visibility is only one component of an end-to-end service.

Four nines also does not mean zero failures. Even under a fully specified agreement, the permitted interruption depends on the time basis and definition of availability. Without the contract, converting the percentage into an exact outage allowance would create precision that the page does not provide.

The agreement may apply to a data-centre product rather than every Compass service. Broadband access, voice, hosted applications and colocation can carry different terms. AS9245 is an infrastructure identity shared across a broader network surface, not a universal SLA label.

Route collectors cannot test contractual compliance. They can show whether prefixes are visible and how broadly they propagate, but not whether a server responded, a customer circuit met latency targets or an excluded maintenance window applied. Those questions need service-specific telemetry and contract terms.

The disciplined use of the SLA claim is therefore narrow. Compass markets a high-availability commitment for its data-centre offer. The available evidence does not independently measure performance, tie the commitment to AS9245 or prove resilience for any named service.

A status page is a snapshot, not an availability history

Compass operates a public status page that lists service categories and presents current conditions. A captured green state can be useful at a particular moment because it shows what the operator was reporting. It cannot establish that no incident occurred before or after the capture.

Status pages are maintained by operators and depend on their incident-detection and communication practices. They may report only selected systems, use delayed updates or define incidents differently from customers. Their statements should remain attributed rather than treated as independent telemetry.

The page also does not map service categories to AS9245 prefixes. An internet service, voice platform or data-centre component may use the network in different ways. A green label cannot validate the public routing footprint, and a visible route cannot validate the service label.

Historical resilience requires a time series of events, durations, affected components and recovery evidence. One status snapshot supplies none of that. It cannot support an uptime calculation or a claim that failover has been tested successfully.

The page can still help separate current company communication from routing observation. At the capture time, the operator did not present a broad service incident on the visible status surface. At the RIPEstat query time, AS9245 was broadly visible. The two observations coexist without proving causation or completeness.

That relationship is the correct level of interpretation. Operator status describes declared service condition. Route data describes public control-plane condition. Neither is a substitute for end-user measurements, internal telemetry or a verified incident chronology.

Administrative contacts are part of operational continuity

APNIC's technical, administrative and abuse roles do more than decorate the registration. They provide the recorded path for coordination when routes, abuse complaints or resource questions require an operator response. Durable contact metadata is part of the infrastructure that keeps number resources usable.

The Network Operations label indicates an operational function rather than a named individual. That can be valuable because responsibility survives staff changes when the role and contact path are maintained. The record does not show response time or staffing, so it cannot prove that a message will receive prompt action.

The incident-response handle IRT-COMPASSCOM-NZ creates a separate abuse and security surface. It can support reporting and attribution, but it does not certify security posture or incident performance. A published address is an accountability mechanism, not an audit result.

Accuracy matters because stale records increase the cost of coordination. When an origin changes unexpectedly or a prefix is associated with abuse, other parties need to identify the responsible network without relying on brand searches. AS9245's exact registry object supplies that starting point.

Continuity also depends on transfer recording and identity changes. If the operator, contacts or resource status changes, the registry should preserve an auditable administrative state. The current record is a snapshot of that state, not a guarantee that every downstream database has synchronized immediately.

The contact layer reinforces the broader evidence hierarchy. The registry answers who is recorded for the number. BGP answers what route information is visible. Commercial pages answer how the company describes services. None of them alone answers how an incident would unfold.

The directory alias and legal registrant must remain distinct

The BTW directory calls the entity COMPASS-NZ-AP COMPASS, matching the network-facing form visible in registry and routing descriptions. APNIC's registrant vCard uses Compass Communications Ltd. The two labels can be bound for this network analysis because they converge on AS9245, but their different roles should remain visible.

A directory alias may emphasize recognizability in network records. A legal name identifies the incorporated registrant stated by APNIC. Conflating them can produce false precision about contracts, licences, assets or ownership. Keeping both labels allows the network identity to remain exact without pretending the alias is a separate legal person.

The country and region fields also require context. APNIC assigns NZ to the record, PeeringDB uses Asia Pacific, and the directory currently carries a broader region label. These fields belong to different taxonomies. None supplies a full map of infrastructure or customer coverage.

The Compass website reinforces the New Zealand operator context, but commercial self-description does not resolve every corporate question. It does not establish a beneficial ownership chain or the legal holder of each facility, interconnect and service agreement.

For operators following the record, the exact AS number is the bridge. It connects the administrative registrant, route observations and PeeringDB network row without requiring every name field to be identical. The number-resource identity is stable enough for monitoring while the legal boundary stays narrow.

That restraint protects future updates. If a directory label or company name changes, the record can be revised without rewriting the historical observation of AS9245. Identity continuity and corporate naming can evolve on different schedules.

Route visibility cannot establish route correctness

The fact that AS9245 originated a prefix and propagated it broadly does not prove that the origin was authorized or technically correct. BGP observations show what was announced and seen, not whether every routing-policy and resource-authorization check passed.

The bounded evidence does not include a current RPKI validation result for each prefix. No claim should therefore be made that the routes were valid, invalid or not found. Those states require exact route-origin authorization data at a stated time.

Correctness also extends beyond RPKI. A route can be authorized but operationally unintended, or intended but filtered by some networks. A collector can see a path while a customer experiences a different outcome. The observed origin is a starting point for verification, not the end of it.

The eight observed neighbours likewise do not prove policy correctness. A path can include expected adjacencies or unexpected ones, and the response summarized here does not provide the contractual and configuration context needed to judge them.

Security posture remains outside the route count. No firewall design, DDoS protection, monitoring system, change-control process or incident response result can be inferred from broad BGP visibility. The published incident contact is useful, but it is not evidence that controls succeeded.

The operational conclusion is limited and strong: AS9245 was visible as the origin for the captured prefixes. Questions of authorization, intended policy and security require their own current evidence. Refusing to fill that gap keeps the route account accurate.