Summary

  • APNIC RDAP identifies AS45637 as the active UNIFONENETWORKS-AS-AP autonomous-system record for UniFone New Zealand Ltd in New Zealand.
  • RIPEstat reported AS45637 as announced at 2 August 2026 16:00 UTC and listed three IPv4 prefixes and two IPv6 prefixes in the dated observation.
  • The five visible prefixes were 182.54.160.0/20, 123.253.56.0/22, 103.91.172.0/22, 2402:ff00::/32 and 2001:df5:b000::/48.
  • All 328 IPv4 and 321 IPv6 RIS full-feed peers represented in the routing-status response saw AS45637, establishing strong visibility within that captured peer population.
  • RIPEstat counted 17 observed neighbours, 6,144 IPv4 addresses and 65,537 IPv6 /48 equivalents, but those figures do not reveal traffic, capacity, customer relationships or physical paths.
  • PeeringDB identifies the same AS and declares IPv6, unicast support and a selective peering policy, but its fields are maintained by the operator rather than independently measured.
  • UniFone says it operates more than 100 wireless sites, covers much of Otago through its WiFi network and offers fibre and fixed-wireless access; those descriptions remain operator claims.
  • Public routing visibility does not prove access availability, local power continuity, universal reachability, successful failover, customer uptime or the resilience of any particular service.

Generic regional network edge linking routed infrastructure to a wireless access relay across hilly terrain

Editorial illustration of a public routing edge meeting a separate regional access path; it does not depict a UniFone facility, tower, route, coverage area, outage, customer network or measured resilience outcome.

The number-resource identity is precise

AS45637 supplies a stable public identifier for UniFone New Zealand Ltd. APNIC RDAP records the autonomous-system number under the name UNIFONENETWORKS-AS-AP, marks it active and assigns the country code NZ. The associated organisation record names UniFone New Zealand Ltd. Network-administration and incident-response records use matching UniFone identities and Dunedin postal details, strengthening the administrative connection between the company name and the number resource.

That connection is more exact than a brand reference. It links a specific legal company name to a specific autonomous-system number within the APNIC service region. Future routing observations can therefore be attached to AS45637 without guessing which similarly named provider or website is involved. Administrative contacts also preserve points of coordination for the resource.

An active RDAP status has a limited meaning. It establishes that the autonomous-system registration is active in the registry layer. It does not indicate whether a router is exporting a route, whether another network accepts it, whether packets traverse it or whether a subscriber can reach the internet. Administrative state and running network state must be examined separately.

The record also provides no basis for claims about beneficial ownership, licences, facilities, contracts or customer numbers. A registry can accurately preserve the identity attached to a resource without describing the company’s wider legal or commercial structure. Its authority is strongest where uniqueness, recorded responsibility and administrative continuity are concerned.

This makes APNIC the correct starting point, but not the final answer. The registered identity tells which organisation is named against AS45637. RIPEstat then tests whether that identifier appears in observed public routing. PeeringDB records what the operator declares about its interconnection posture. UniFone’s own pages describe the access network from the operator’s perspective. Each layer adds information without inheriting the authority of the others.

A dated view of the running network

RIPEstat reported AS45637 as announced at 2 August 2026 16:00 UTC. Its routing-status response showed three IPv4 prefixes and two IPv6 prefixes, with 17 observed neighbours. The response also recorded 6,144 IPv4 addresses and 65,537 IPv6 /48 equivalents within the announced space represented there.

This is running-state evidence rather than administrative continuity. A route collector receives and organises information propagated through BGP. When an autonomous system and its prefixes appear in that view, the observation shows that the public routing signal reached the relevant collectors through the paths available to them.

The timestamp is indispensable. Route visibility can change, and a routing observation is not a permanent certificate. The accurate statement is that AS45637 was announced in the captured RIPEstat view at the recorded time. A later query could show the same prefixes, a different set or no current announcement. None of those later possibilities changes what the dated response contained.

RIPEstat records AS45637 as first seen on 4 August 2011 at 16:00 UTC and last seen at the 2 August 2026 observation time. The long span between those fields adds chronology to the identifier, but it does not prove uninterrupted visibility throughout every intervening moment. First-seen and last-seen timestamps mark observed boundaries, not a continuous availability measurement.

The route observation is also narrower than service delivery. A public BGP signal can be visible while a local access path is unavailable, and a customer service may rely on components that do not appear in an AS-level summary. Routing data cannot see a subscriber’s mains power, the condition of an access radio, a local obstruction, equipment at an address or the success of a particular operational response.

AS45637 is consequently visible in a meaningful but bounded sense. Its public routing footprint can be inspected at the autonomous-system and prefix layers. The observation says nothing by itself about traffic volume, utilisation, latency, loss, customer experience or the physical route taken by packets.

Five prefixes define the visible routed edge

The dated announced-prefixes response listed five networks originated through AS45637: 182.54.160.0/20, 123.253.56.0/22, 103.91.172.0/22, 2402:ff00::/32 and 2001:df5:b000::/48. The first three are IPv4 prefixes. The final two are IPv6 prefixes.

Together they make the public routed edge more concrete than the AS number alone. An autonomous-system identifier states which routing domain is involved; the prefixes identify the address blocks visible as announcements from that domain in the captured data. The combination supports repeatable comparison across later observations.

The IPv4 set contains differently sized blocks. The /20 and two /22 entries account for the 6,144 IPv4 addresses reported in the routing-status response. That arithmetic describes address space represented by the visible prefixes. It does not reveal how many addresses were assigned, active, reachable, occupied by customers or carrying traffic.

The IPv6 result requires similar restraint. RIPEstat expressed the two visible IPv6 prefixes as 65,537 /48 equivalents. That is a way of normalising the scale of the routed IPv6 space. It is not a count of customers, interfaces, active subnets or working access links. IPv6 address-space scale cannot be converted into delivered network scale without separate evidence.

Nor can an individual prefix be mapped to a particular customer service, tower, city, data centre or interconnection. The captured facts establish that the five prefixes were visible as announcements associated with AS45637. They do not reveal the internal allocation of the address space or the physical infrastructure behind any route.

The value of naming all five prefixes lies in auditability. A later observation can ask whether each prefix remains visible, whether one has disappeared, whether a more-specific route appears or whether a new prefix joins the set. Such changes would alter the public routing footprint. They would not, without additional operational evidence, explain why the change occurred or what effect it had beyond the routing layer.

Prefix precision prevents a vague statement such as “UniFone is on the internet” from carrying too much meaning. What is actually visible is a dated set of three IPv4 and two IPv6 announcements under AS45637. That is strong evidence of a dual-stack public edge, not a comprehensive account of the network behind it.

Dual-stack visibility is a capability signal

The simultaneous appearance of IPv4 and IPv6 prefixes establishes dual-stack visibility in the RIPEstat observation. AS45637 was not represented only by legacy IPv4 space or only by IPv6. Both protocol families reached the routing view through the autonomous system’s public announcements.

PeeringDB’s operator-maintained entry also declares IPv6 and unicast support. This is consistent with the observed presence of the two IPv6 prefixes, although the two records play different roles. RIPEstat supplies dated route visibility. PeeringDB preserves the operator’s declared network characteristics. Agreement between them makes the dual-stack identity coherent without turning every PeeringDB field into a measurement.

Visible IPv6 announcements matter because IPv6 cannot be inferred from an IPv4 route or a company description. The two IPv6 entries provide direct evidence that AS45637 originated publicly visible IPv6 space in the recorded view. The IPv4 prefixes independently establish the other side of the dual-stack footprint.

Even so, dual-stack visibility does not prove dual-stack service at every customer endpoint. A provider can announce IPv6 while a particular access product, address, device or downstream path lacks working IPv6. BGP shows that a route was visible to collectors; it does not test application connectivity from individual premises.

The same boundary applies to reachability. An announcement can be accepted broadly without proving that every address inside the prefix responds or that return paths work under every condition. Routing establishes a control-plane path to address space. End-to-end operation also depends on forwarding, filtering, local configuration, access equipment and conditions outside the collector’s view.

Dual-stack should therefore be read as an observable network capability at the routed edge. It is a substantive fact, not a marketing inference. Its limitations are equally substantive: the observation does not certify universal IPv4 or IPv6 availability, parity between the two protocol families or continuity through failures.

Complete sampled-peer visibility, carefully stated

RIPEstat’s routing-status response recorded 328 of 328 IPv4 RIS full-feed peers seeing AS45637 and 321 of 321 IPv6 peers seeing it. Within the peer populations represented in that response, visibility was complete for both protocol families.

That result is stronger than a route seen by only a small fraction of sampled peers. It shows that the AS reached every represented full-feed peer in each family at the observation point. For a public routing footprint, this is evidence of broad propagation across the captured RIS view.

The denominator must travel with the conclusion. “All peers saw the AS” is accurate only when it means all 328 IPv4 and all 321 IPv6 peers counted in this particular response. The result does not enumerate every BGP speaker, transit network, access provider or routing perspective on the internet.

Collector populations are observational instruments. Their coverage is broad enough to make the result meaningful, but no collector system is identical to the entire network. A route can be visible to every represented peer while policy, filtering, forwarding or local access conditions differ elsewhere.

Complete visibility also does not establish path quality. The peer counts contain no measurement of latency, loss, jitter, available bandwidth or congestion. They do not show whether every peer selected the same path or whether traffic followed any particular interconnection. The metric concerns whether the AS was visible, not how well packets moved.

Nor does the result guarantee persistence. The peer counts describe the dated response. They are not an uptime percentage and cannot show that the same visibility remained continuous before or after the query. Repeated observations would be needed to document a time series, and even a stable time series would remain a routing measurement rather than an access-service guarantee.

The proper conclusion is nevertheless significant. At 2 August 2026 16:00 UTC, AS45637 had complete IPv4 and IPv6 visibility among the RIS full-feed peers represented in the response. That makes its public route signal highly observable. It does not collapse the distance between a visible route and a working connection at a home, farm or business.

Seventeen neighbours do not form a customer map

The same RIPEstat response counted 17 observed neighbours for AS45637. A neighbour in this context is a routing adjacency visible through the available BGP data. The number adds structure to the public routing picture, but it does not disclose the commercial or physical nature of each relationship.

A BGP neighbour can be visible because routing information passes between autonomous systems. The observation does not label the relationship as customer, provider, peer or backup in a contractual sense. Routing policy may suggest patterns, but the frozen count alone does not establish commercial terms.

The figure also cannot be read as 17 interconnections at 17 physical locations. A logical routing adjacency is not a facility record. Multiple sessions can have relationships to locations and equipment that the aggregate count does not expose, while a single observed neighbour says nothing about where packets meet.

Likewise, 17 neighbours do not indicate 17 customer networks or 17 suppliers. The number describes observed routing relationships, not subscribers, contracts or counterparties. Assigning business roles would require evidence beyond the aggregate response.

What the count does provide is a monitoring baseline. A later response could show more, fewer or the same number of observed neighbours. Such a change would be worth recording alongside prefix and peer visibility. It would not explain itself. A difference could reflect routing changes, collector visibility or other conditions that the aggregate field does not identify.

The restraint is especially important when discussing resilience. Multiple visible neighbours may look like diversity, but neighbour count alone cannot prove independent physical paths, failover readiness or the absence of shared dependencies. Logical plurality is not the same as tested operational redundancy.

AS45637’s 17 observed neighbours therefore belong to the auditable public edge. They show that the autonomous system was not visible as an isolated identifier. They do not reveal customer topology, contracts, facility ownership, exact traffic paths or the performance of any alternative route.

PeeringDB records a declared posture

PeeringDB’s network entry names UniFone New Zealand, associates it with AS45637 and links it to the operator’s website. It identifies the IRR set APNIC::AS-UNIFONENZ, classifies the network as Cable/DSL/ISP, assigns an Asia-Pacific scope and records a selective peering policy.

The entry also declares IPv6 and unicast support. Those fields fit the dual-stack route observation, while the IRR-set name provides another network-facing identifier associated with UniFone’s routing posture. The alignment among the company name, AS number and operator website is useful for identity.

PeeringDB remains an operator-maintained service. Its records are supplied and updated by participating networks rather than produced by an independent route collector. The entry can accurately communicate how UniFone presents its network, but its presence does not prove that every declaration was operationally realised at the query time.

A selective peering policy is a statement about the operator’s general approach. It does not establish a session with any particular network, an agreement, a route preference or a contractual relationship. It also does not show which paths carried traffic in the RIPEstat observation.

The same restriction applies to traffic, facility, exchange and prefix-count fields in the entry. Those fields must not be promoted into measured capacity, independently confirmed topology or facility ownership. A declared presence and an observed BGP path are different forms of evidence, even when they are compatible.

PeeringDB is most valuable here as a middle layer. APNIC answers who is registered against AS45637. RIPEstat shows the dated public routing signal. PeeringDB preserves the operator’s declared interconnection identity and policy. None should be made to answer questions assigned to another.

The declaration can also change independently of routing. UniFone could update a policy or network characteristic without changing the five visible prefixes. Conversely, route visibility could change while the PeeringDB entry remains untouched. Comparing their dates and roles is more informative than treating one as confirmation of every field in the other.

The autonomous-system edge is not the access network

UniFone’s public descriptions place AS45637 beside a regional access business, but the two layers should not be fused. The autonomous system represents a public routing domain. Customer access begins farther out, through fibre, fixed-wireless or the operator-described WiFi network.

UniFone describes itself as based in Dunedin and Balclutha and says it has more than 100 wireless sites in the South Island. Its personal-service material says the company owns and operates a WiFi network covering much of Otago, alongside fibre and fixed-wireless access options.

Those statements identify the access technologies and regional footprint claimed by the operator. They do not independently establish the location, status, ownership or performance of each site. “More than 100” remains an attributed figure, not a surveyed inventory.

The access layer introduces conditions absent from an AS-level routing response. A fixed-wireless connection can depend on radio conditions, equipment, site power and the path from the access network towards upstream interconnection. Fibre has different local characteristics but still relies on equipment, power and a working route through the wider network.

Public visibility of the five prefixes begins to matter only after those access components deliver packets to the routed edge. A customer can have a functioning local link while a wider route is impaired, or a broadly visible route while the local access path is unavailable. The two states are related but not interchangeable.

This is why AS45637 cannot serve as a shorthand for every UniFone service. The AS makes the public network identity and announced address space auditable. It does not identify which access method serves an address, which infrastructure is involved or whether a particular connection is operational.

The distinction also prevents regional language from becoming a universal promise. Coverage of much of Otago, as described by UniFone, is not coverage of every location. A public route to AS45637 cannot fill geographic or technical gaps in the access layer.