Summary

  • AFRINIC RDAP names The Phoenix Quest II cc as the registrant associated with active autnum AS328334, while RIPEstat reported the ASN announced with visible IPv4 and IPv6 prefixes in its 29 July 2026 query window.
  • The records establish a public identity, number-resource assignment and routing signal. They do not establish the infrastructure, service relationships or recovery arrangements behind those announcements.
  • AS328334 illustrates the difference between a registry acting as an accountable ledger and running routing activity providing a limited view of operational reality.

A precise record with a deliberately narrow meaning

AS328334 is a compact example of how the internet’s public accountability layer can be both precise and incomplete. The Phoenix Quest II cc appears in a public company directory, in an AFRINIC registration entry and in route-observation data associated with the same autonomous system number. Those records allow an outside reader to identify a named organisation, a numbered routing identity and a set of prefixes that were visible to public collectors. They do not expose the entire operating system behind those facts. The distinction is not a technical footnote. It determines which conclusions the evidence can sustain.

The public directory establishes the subject boundary. Its canonical identity is cmqhy3o130007me6be0b9yvw2, and its exact directory slug is the-phoenix-quest-ii-cc-the-phoenix-quest-ii-cc. The displayed subject string, The Phoenix Quest II cc - The Phoenix Quest II cc, includes the duplicated name and should be treated as an identifier rather than interpreted as evidence of a second organisation, parent company or affiliated brand. The directory entry gives readers a stable point from which to examine the company. It does not turn the company entry into a complete operational description.

AFRINIC RDAP provides the strongest public link between that company identity and AS328334. The autnum response identifies the handle as AS328334, lists both the starting and ending autonomous system number as 328334, marks the status active and names The Phoenix Quest II cc as the registrant. It records a registration timestamp of 9 July 2018 at 12:35 UTC and a last-change timestamp of 6 December 2019 at 08:01 UTC. The organisation identifier shown in the registration material is ORG-TPQI1-AFRINIC.

Those fields matter because autonomous system numbers must remain uniquely attributable within the coordination system. When another operator sees AS328334 in routing information, the registry supplies a public answer to the first accountability question: which registered organisation is associated with this number? That answer is narrower than a description of how the organisation conducts its business, but it is still essential. Without a reliable association between numbers and responsible entities, fault investigation, routing coordination and abuse escalation become more ambiguous.

RIPEstat adds a different kind of observation. Its AS overview identifies the holder as The Phoenix Quest II cc - The Phoenix Quest II cc and marked AS328334 as announced during the query window on 29 July 2026. Its announced-prefixes data showed publicly visible IPv4 and IPv6 entries associated with that origin. This moves the evidence beyond a number that exists only in a registry entry. It shows the number appearing in running routing activity visible to the data service at that time.

The difference between those two layers is fundamental. AFRINIC records who is associated with the number-resource registration. RIPEstat reports what route collectors could observe. The first is a ledger function; the second is a partial view of running code and routing state. Neither layer should be asked to prove facts that belong to another domain. A registration entry cannot show the path packets took. A collector observation cannot, by itself, explain every commercial, physical or organisational dependency behind a route.

PeeringDB supplies a more limited corroborating signal. The public ASN page resolves to a title associating AS328334 with Phoenix Quest. That pairing is useful as an additional identity clue, but it does not establish a location, an exchange relationship or a particular interconnection arrangement. The mere presence of an ASN in an interconnection directory cannot be expanded into claims about where traffic is exchanged or how many independent paths exist. Its value here is auxiliary: the ASN and the Phoenix Quest name appear together on another public network-information surface.

Taken together, the records support a clear thesis. The Phoenix Quest II cc is publicly named in connection with AS328334, and the autonomous system had visible IPv4 and IPv6 announcements during the observed window. That is sufficient for a number-resource accountability story. It is not sufficient for a complete company operating profile. The operating boundary remains outside the route table because the available records do not identify the physical chain, contractual chain or human repair authority behind the observed routes.

What AFRINIC’s ledger establishes

An autonomous system number is not a certificate of engineering quality. It is a unique identifier used in interdomain routing and recorded within a regional number-resource system. AFRINIC’s entry for AS328334 establishes that the number has an active registration status and is associated with The Phoenix Quest II cc. This is a meaningful public fact because it places an accountable name beside a resource that can appear in routing exchanges. It does not certify how that resource is operated at every moment.

The registration dates also require careful interpretation. The 2018 registration timestamp establishes when the record says the autnum was registered. The 2019 last-change timestamp reports the most recent change exposed by the RDAP response. Neither timestamp proves that the organisation’s operational arrangements remained unchanged after that date. Registry data can remain accurate even when equipment, contracts or routing policies change, but the dates alone cannot establish that continuity. They describe the history of the public record, not the full history of the system associated with it.

The active status has similarly bounded meaning. It indicates that the registration is presented as active by the registry service. It should not be translated into a claim that every associated route is reachable at every moment or that every service connected with the organisation is functioning. Administrative status and live reachability are different observations. In this case, RIPEstat supplies a separate routing signal, but even that signal represents a query window rather than permanent availability.

RDAP also exposes South African contact and address signals associated with the registrant, including references around Boksburg and the address string 224 Rondebult Road, Libredene, Boksburg South. These details strengthen the accountable South African identity attached to the autnum. They do not reveal where packets enter or leave a network. An administrative address may be relevant to correspondence or organisational identification without corresponding to an equipment location, traffic handoff or service footprint.

That distinction protects against a common category error. Public network records frequently mix resource identifiers, administrative contacts and geographic address fields. Readers may be tempted to combine them into a physical map. Yet each field answers a different question. A registrant name answers who is recorded. A contact field indicates where a communication may be directed. An address supports jurisdictional or organisational context. None of those fields alone describes the path followed by traffic.

The contact information nevertheless has real operational value. Internet coordination depends on the ability to associate routing identifiers with responsible organisations and communication channels. During a route leak, suspected hijack, persistent misconfiguration or abuse incident, other parties need a way to identify the registered holder and seek a response. A contact record does not guarantee that a message will receive a timely answer, but its presence creates an auditable starting point. That is one reason accuracy and maintenance of number-resource metadata matter.

The ledger function should therefore be neither dismissed nor exaggerated. It is not sovereign over operational reality: a registry entry does not make packets move and cannot determine the topology behind an announcement. But it provides the naming structure that allows independent actors to discuss the same resource without ambiguity. AS328334 refers to a particular autonomous system number, and AFRINIC associates that number with The Phoenix Quest II cc. That shared reference point is a prerequisite for accountable coordination.

This is the practical meaning of treating the registry as a recordkeeper rather than as a complete authority on network operations. The record is authoritative within its field: it tells readers what AFRINIC publishes about the autnum and registrant. It should not be treated as authoritative about facts it does not contain. The record does not reveal upstream contracts, traffic volumes, maintenance procedures or the location of active equipment. Its silence on those subjects is a boundary, not evidence for either a positive or negative conclusion.

The organisation identifier ORG-TPQI1-AFRINIC adds another consistency point. It links the autnum entry to an organisation object within the registry context, while the registrant name provides the human-readable company identity. That relationship helps keep the number-resource trail coherent. It still does not justify inventing a trade name, subsidiary or operating affiliate. The safest identity statement is the exact one supported by the records: AFRINIC names The Phoenix Quest II cc in connection with AS328334.

Preserving the exact identity also matters because the directory and RIPEstat display the duplicated company string. It would be easy to tidy that presentation into a new canonical name or infer that the repetition has legal significance. Neither step is warranted. The duplicated string can be reported as it appears while the company name in the AFRINIC registrant field remains The Phoenix Quest II cc. The exact entity identifier and directory slug anchor the subject without adding an unsupported alias.

What the route view shows

RIPEstat’s AS overview reported AS328334 as announced during the 29 July 2026 query window. In ordinary terms, public routing data available to the service contained an announcement associated with that autonomous system. This is running activity rather than merely an allocated identifier. It establishes observability at a particular time, but the observation remains bounded by the collectors and processing methods used by the service.

The announced-prefixes response listed the IPv4 aggregate 102.134.88.0/22 alongside the more-specific entries 102.134.88.0/24, 102.134.89.0/24, 102.134.90.0/24 and 102.134.91.0/24. The relationship among those entries is important. The four /24 networks sit within the address range represented by the /22. They must not be added to the aggregate as though they represent separate blocks of saleable address space. The list is a routing visibility set, not an inventory of independent commercial units.

More-specific announcements can exist for many technical reasons. They may support traffic engineering, selective propagation, routing policy or other operational choices. The current evidence does not identify the reason for these particular entries. Nor does it show whether every collector observed the same combination of aggregate and more-specific routes. The defensible statement is simply that RIPEstat listed the aggregate and those more-specific IPv4 routes for AS328334 in the queried view.

The IPv6 data broadens the observable resource surface. RIPEstat listed 2c0f:ef30::/32, along with 2c0f:ef30:10::/44, 2c0f:ef30:20::/44, 2c0f:ef30:30::/44, 2c0f:ef30:40::/44, 2c0f:ef30:50::/44, 2c0f:ef30:60::/44, 2c0f:ef30:70::/44 and 2c0f:ef30:2000::/40. These entries show that the public routing view associated AS328334 with both address families. They do not reveal how IPv6 addresses are delegated or used beyond the observed announcements.

Prefix length should not be mistaken for traffic scale. An IPv6 /32 represents an enormous address range compared with an IPv4 /22, but IPv6 allocation structure is intentionally generous and hierarchical. Its numerical size does not indicate the number of users, devices or services reached. Similarly, the scarcity of IPv4 can make a comparatively small allocation economically significant without revealing the amount of traffic carried through it. Addressing structure and service demand are different measurements.

The route view also cannot prove that every listed prefix was reachable from every part of the internet. RIPEstat notes that routes with very low visibility may be excluded from its announced-prefixes output. That caveat cuts in both directions. The response is not guaranteed to include every marginal observation, and inclusion does not mean universal propagation. A route collector supplies a valuable observation point, not an omniscient view of all paths.

Time is another boundary. The AS overview supplies a snapshot tied to its query window. It does not, on its own, describe behaviour during the preceding months or guarantee what happened afterward. A route visible on 29 July might have been stable for years, recently introduced or intermittently withdrawn; the present material does not decide among those possibilities. Longitudinal conclusions would require observations across multiple periods.

This means the route evidence supports existence in running routing state, not a history of continuity. Observers can say that AS328334 was announced and that the listed IPv4 and IPv6 prefixes appeared in the service’s data. They cannot convert that snapshot into a service-quality assessment. The evidence contains no measurement of latency, packet loss, repair time or sustained reachability. It also contains no comparison of behaviour during faults or maintenance.

The holder string in the RIPEstat overview reinforces the identity connection. It names The Phoenix Quest II cc - The Phoenix Quest II cc, matching the duplicated subject form found in the directory context. That consistency helps bind the routing observation to the correct company subject. It does not resolve why the name is duplicated, nor does it establish any organisation beyond the exact company identified in the available records.

The same reasoning limits what can be inferred from the coexistence of IPv4 and IPv6. Dual-family visibility shows that announcements in both address families were present. It does not prove that applications, end users or access services receive equivalent treatment across the two families. It does not show whether monitoring, filtering or fault response is symmetrical. The public evidence supports an observation about routing, not an assessment of implementation maturity.

Running-code primacy does not mean treating every route observation as a complete truth. It means recognising that operational effects matter more than labels when the question is what the network is doing. AFRINIC’s entry names the resource and registrant; RIPEstat shows that routing activity was observable. The two layers complement each other. Their combination is stronger than either alone, but it still stops before the unobserved operating boundary.