Summary

  • APNIC records bind CHARLIEBOY NETWORK PRIVATE LIMITED to AS151145 and the active portable IPv4 allocation 103.249.196.0/23, a block containing 512 addresses.
  • Public routing data shows the /23 expressed as two /24 announcements, 103.249.196.0/24 and 103.249.197.0/24, with 329 of 330 observed IPv4 peers seeing the origin at the captured query time.
  • Both sampled /24 origin pairs were RPKI-valid under a 103.249.196.0/23 ROA whose maximum length is /24, but that narrow result is not a universal security verdict.
  • The public record does not establish last-mile reach, subscriber numbers, physical routes, capacity, uptime, recovery procedures, or whether every service follows the same network path.

A small routing footprint with a clear public outline

The easiest way to misunderstand a regional network is to begin with the company description and work backwards toward infrastructure. The more reliable starting point is the public control surface. For CHARLIEBOY NETWORK PRIVATE LIMITED, that surface begins with AS151145. An autonomous-system number is not a claim about market size or service quality. It is a routing identifier used when the network originates or exchanges reachability information. Its value here is evidentiary: it lets an outside observer separate the registered network identity from the broader promises that a commercial name might imply.

APNIC's autonomous-system registration identifies the resource as AS151145 and associates it with the handle CHARLIEB-AS-IN. The record is active and sits in the Indian portion of the APNIC service region. Those facts provide a stable lookup point. They are stronger than an unverified marketing page because they are part of the operational registry used by network operators. They are also narrower. A registry entry records responsibility for a number resource; it does not certify the scale, topology, customer base, legal licence scope, or day-to-day performance of the services offered under the same company name.

The accompanying IPv4 record adds a second piece of the outline. APNIC lists 103.249.196.0/23 as an active portable allocation associated with the same operating surface. A /23 contains 512 IPv4 addresses. That arithmetic describes address space, not subscribers. Some addresses may be reserved for infrastructure, assigned to customer-facing systems, routed internally, left unused, or managed under arrangements that public records do not disclose. Treating the address count as a customer count would turn a precise registry fact into a false commercial metric.

Public routing observations show that the aggregate is not merely a dormant line in a registry. At the captured query time, AS151145 was visibly originating 103.249.196.0/24 and 103.249.197.0/24. Together, those two /24s cover the same 512-address span as the registered /23. This relationship is useful because it connects the administrative allocation to running routing behaviour. The allocation says who is recorded as holding the resource; the announcements show how that resource was being presented to the global routing system at a specific moment.

The distinction between outline and operation matters throughout this assessment. The available evidence supports a real, active number-resource identity. It does not provide a physical map. No public source in the frozen set identifies fibre routes, towers, aggregation sites, power arrangements, customer premises, spare capacity, or maintenance teams. The network is visible where the Internet requires it to be visible: in the registries and routing tables. Everything beyond that boundary must be stated as unknown rather than inferred from the clarity of the routing record.

The registry is a ledger, not a service certificate

Number registries are often treated as if they were licensing authorities, ownership courts, or service-quality auditors. Their practical role is more limited and more useful. They maintain unique identifiers, record resource status, publish contact and responsibility data, and give operators a common reference for coordination. APNIC's records for AS151145 and 103.249.196.0/23 perform that ledger function. They make the network addressable as an accountable technical entity without certifying every commercial or operational claim that might be attached to it.

The AS record contains registration and contact fields that help an operator or incident responder identify the responsible network. The associated technical and abuse entities create channels through which routing, security, or abuse questions can be directed. These details matter because a routable network without current contact data imposes costs on everyone who has to diagnose or contain a problem. Yet contact publication is not proof that a message will receive a rapid response, that the listed team controls every relevant system, or that the company can restore service under stress.

The IPv4 allocation is marked portable. Portability describes the resource category and its administrative relation to the holder; it does not reveal how the addresses are physically delivered. A portable allocation may support flexibility in upstream relationships because it is not simply an address range borrowed from one provider. That possibility should not be converted into a claim that the network has multiple upstreams, seamless failover, or independent transport. Those outcomes depend on routing policy, contracts, equipment, facilities, and operating practice that the registry does not describe.

The registration timestamps add chronology but not continuity. They show when records were created or changed. They can help distinguish an abandoned historical entity from a recently maintained one. They cannot show that every underlying service was continuously available between those moments. Operational continuity is an empirical property of systems, people, facilities, and dependencies. Registry maintenance contributes to that continuity by preserving accurate coordination data, but it is only one layer.

This is why the public record should be read as a stack of claims with different strengths. The exact entity, ASN, address block, status, and contacts are strong administrative facts. The observed announcements are strong point-in-time routing facts. Physical design, resilience, customer experience, and recovery performance remain unproved. Keeping those layers separate is not excessive caution; it is the only way to preserve the usefulness of the evidence without making the registry say more than it does.

Two /24s express one portable /23

The relationship between 103.249.196.0/23 and the two observed /24s is the central technical fact in the current footprint. In address arithmetic, a /23 spans two adjacent /24 networks. Here, the observed announcements are exactly 103.249.196.0/24 and 103.249.197.0/24. That alignment means the visible route origins fit within the registered allocation rather than extending beyond it. It is a coherent picture of resource registration and route origination at the time of observation.

Announcing two /24s instead of only the covering /23 can have several operational motivations. More-specific routes may support policy control, traffic engineering, or compatibility with filtering practices. The evidence does not identify the operator's reason. It would be wrong to declare a traffic-engineering design solely from the route lengths. The safe conclusion is simpler: the registered /23 was visible as two constituent /24 origins from AS151145.

The two-route view is not a topology diagram. It does not show whether the prefixes leave the network through one router or several, one circuit or several, one facility or several. It does not disclose where packets enter or exit Mumbai, whether the two /24s follow identical paths, or whether any internal segmentation mirrors the public route split. BGP announcements are control-plane statements about reachability. They do not expose the complete forwarding architecture behind those statements.

Nor do the routes reveal utilisation. A prefix can be globally announced while only a fraction of its addresses serve public systems. Conversely, a modest address block can support many users behind address sharing. The count of 512 IPv4 addresses therefore remains a resource measure. It cannot be converted into a subscriber estimate, a capacity figure, a traffic level, or a statement about business scale.

The alignment nevertheless has monitoring value. If a future snapshot shows only one /24, a different origin, a new covering route, or an announcement outside the registered block, the change would be worth investigating. It might reflect planned policy, an upstream issue, a registry update, a route leak, or a measurement limitation. The present record establishes a baseline against which such changes can be compared; it does not pre-judge their cause.

Visibility is broad at one moment, not an uptime guarantee

RIPEstat's routing-status view reported 329 of 330 observed IPv4 peers seeing AS151145 at the captured query time. That is broad visibility within that measurement system. It indicates that the origin was not confined to a small or obviously isolated portion of the observed routing table. The figure is useful because it converts the statement "the ASN is announced" into a more specific point-in-time observation about how widely the route was visible among the participating peers.

The numerator and denominator must remain attached to the observation. They describe the RIPE RIS peer set represented in that response, not every router on the Internet. A peer may temporarily miss a route because of its own policy or session state. Measurement collectors have particular locations and relationships. The visibility number is therefore a view through a large observational window, not a universal census of reachability.

It is also not availability percentages. A 329-of-330 snapshot cannot be read as 99.7 per cent uptime. Uptime requires a time series, a defined service endpoint, a sampling methodology, and an agreement about what counts as available. The routing snapshot supplies none of those elements. It says that the origin was broadly visible when queried. It says nothing about the preceding hour, the following day, application responsiveness, packet loss, latency, or customer experience.

Broad route visibility also does not prove that the access network was functioning. A prefix can remain in BGP while a downstream link, customer aggregation system, DNS service, power feed, or application has failed. Conversely, a local service may continue for some users during a wider routing disruption. The public control plane is one layer of the dependency chain. The delivery surface includes facilities, transport, local access, power, equipment, and operations that are absent from the available sources.

The correct use of the 329-of-330 figure is comparative. Repeated observations can show whether the route remains broadly visible, becomes partially obscured, or disappears. Correlated data could then narrow a diagnosis. In isolation, the number is a high-quality routing fact with a narrow scope. It should increase confidence that AS151145 had a real global routing presence at the observation time, not confidence in an unmeasured service-level promise.

The missing IPv6 view is a question, not a verdict

The same routing-status response showed zero visible IPv6 prefixes for AS151145 and zero of 324 observed IPv6 peers seeing an IPv6 origin from the ASN. The announced-space summary likewise reported no IPv6 prefixes in that captured dataset. These are meaningful observations about the public routing view. They do not establish that the operator has no IPv6 capability.

Several boundaries matter. IPv6 service can be provided through a different origin ASN, delegated through an upstream, used internally, tested without global advertisement, or absent from the measurement window. The source set does not resolve those possibilities. It contains no customer configuration, peering policy, network diagram, or service catalogue that can tie an IPv6 offer to AS151145.

The absence is still operationally relevant because the ASN is the visible identity under review. If the company presents AS151145 as the network through which it delivers Internet service, the lack of a visible IPv6 origin raises a concrete question about dual-stack delivery. That question should be asked of the operator rather than answered by assumption: which ASN or prefix carries IPv6, which services receive it, and how is continuity managed when IPv4 and IPv6 paths differ?

IPv4 scarcity makes this more than a standards-compliance question. An operator with 512 portable IPv4 addresses may use address sharing, selective public assignments, upstream space, or other designs. Public evidence does not show which. A documented IPv6 deployment could reduce some pressure and change the failure surface. But the current evidence does not establish that every service is dual-stack, or that no service is.

Monitoring should therefore preserve the distinction between "no visible IPv6 origin in this snapshot" and "no IPv6 network." The former is supported. The latter is not. That wording leaves room for the evidence to change without forcing a correction to an overconfident claim, and it directs attention to the exact operational disclosure that would close the gap.

RPKI validates the sampled origins within a precise scope

The sampled RPKI checks provide the clearest security-metadata result in the source set. RIPEstat reported both 103.249.196.0/24 and 103.249.197.0/24 as valid when originated by AS151145. Each result referenced a route-origin authorisation covering 103.249.196.0/23 with AS151145 as the authorised origin and maximum length /24.

That maximum length matters. A ROA covering the /23 without an appropriate maximum length could leave the two constituent /24 announcements invalid. Here, maximum length /24 matches the observed route granularity. The sampled origin-prefix pairs therefore align with the published authorisation. This is stronger than merely saying that "RPKI exists"; it identifies the authorised origin, covering prefix, permitted specificity, and validation outcome.

The result narrows one class of ambiguity. A validating network receiving either sampled /24 can see that the origin ASN is authorised by the relevant ROA. That can support route-origin validation policy and reduce exposure to some accidental or unauthorised origin announcements. The effect depends on the receiving network actually validating and enforcing a policy. The ROA does not compel every network to reject an invalid route.

It is not a universal security verdict. RPKI origin validation does not prove the path after the origin, prevent every route leak, authenticate business ownership, secure routers, stop denial-of-service attacks, or demonstrate incident response. A valid route can still carry malicious traffic or traverse fragile dependencies. The two sampled checks also do not prove that every possible announcement associated with the organisation is valid.

The security value is nevertheless real. Accurate route-origin metadata reduces uncertainty at a critical coordination layer. It gives other operators a machine-readable basis for deciding whether AS151145 is authorised to originate the two /24s. That is an example of a registry functioning as operational infrastructure: its legitimacy comes from accurate, usable records and their relation to running code, not from a broad claim to control the network.

One observed neighbour does not disclose the commercial path

RIPEstat's neighbour view showed one observed neighbour, AS55879, in the captured data. The observation indicates a visible BGP adjacency or path relationship in the measurement view. It gives an outside observer a clue about the route's surrounding graph. It does not reveal the contract behind that relationship.

The terms customer, provider, peer, transit supplier, backup, and upstream carry commercial and operational meanings that cannot be assigned from a single public adjacency observation. BGP paths can be affected by route-server arrangements, selective visibility, collector location, and policy. A neighbour present in one dataset may be absent from another without the underlying contract changing. The available source does not identify an exclusive provider, a paid transit relationship, or a recovery path.

The single observed neighbour also cannot be treated as proof of single-homing. The measurement may not expose every adjacency. Private interconnections and paths not selected by collectors can remain invisible. Equally, it cannot be treated as proof of diversity. Seeing AS55879 says nothing about physically separate circuits, independent conduits, distinct power domains, or tested failover.

For continuity analysis, the right questions are concrete. How many external sessions can carry the two /24s? Which facilities and circuits support them? Are alternate sessions physically diverse? What policy changes occur during failure? How often is failover tested? None of those answers appears in the source set. Naming the observed neighbour is useful only if the boundary around it remains explicit.

This is a recurring feature of routing evidence: it exposes relationships without fully explaining them. The graph tells observers where to ask questions. It does not replace contracts, topology, or incident records. AS55879 should therefore be recorded as an observed routing neighbour at the query time, not promoted into an unverified statement about Charlieboy Network's permanent upstream or resilience design.

Contacts create an accountability surface, not a response guarantee

The APNIC records expose technical and abuse-contact entities associated with the network resources. That is operationally important. When a route anomaly, abuse complaint, or security incident occurs, other networks need a current place to send evidence and request coordination. A published contact surface reduces the search cost and helps bind a complaint to the responsible resource record.

Contact records are also part of security metadata. Stale or unreachable contacts can prolong incidents even when the routing system itself continues to function. The existence of named handles and contact methods suggests that the resource has not been left entirely without administrative context. The update history can be monitored for signs that responsibility is being maintained.

Yet the records do not measure responsiveness. They do not reveal staffing hours, escalation procedures, tooling, language coverage, or authority to make changes. A listed abuse mailbox might be monitored continuously, periodically, or inconsistently. A technical contact may coordinate routing but not customer access or physical repair. The evidence provides channels; it does not promise outcomes.

Nor should the contact addresses be used to infer headquarters, facility locations, or service coverage. Registry contact geography can reflect administration rather than network footprint. The company name and Indian resource registration support an India-related identity, while the frozen source material associates the directory entity with Mumbai. They do not map the access network within the city or beyond it.

Accountability improves when records can be tested. A future review can check whether the handles remain active, whether contact fields change, and whether reported issues receive documented responses. That kind of evidence would strengthen an assessment of operational continuity. Until then, the correct conclusion is that a public coordination surface exists, while the quality and speed of the response process remain unproved.

The access network is the largest missing layer

The public record is strongest at the boundary where Charlieboy Network meets global coordination systems. It is weakest where service reaches users. No frozen source identifies last-mile technology, access nodes, radio sites, fibre routes, buildings served, customer equipment, or the boundary between the company's network and third-party infrastructure.

That gap matters because access failures often occur far from the route origin. A globally visible /24 can coexist with a failed local link, a damaged fibre segment, a powerless aggregation point, or a configuration fault affecting only part of the customer base. The BGP view may remain stable while delivery degrades. Without access-layer evidence, route continuity cannot stand in for service continuity.

The same limitation applies to geographic coverage. A registered address, company name, or directory region cannot define where service is commercially available. Coverage requires verified service areas, facility records, licence information, or operator disclosures tied to current delivery. None is present in the source set. A map based on the available evidence would be illustrative, not documentary.

Capacity is equally opaque. The address block does not reveal link speed, installed capacity, sold capacity, contention, or usable headroom. The number of routes does not reveal traffic volume. The observed neighbour does not reveal circuit size. Claims about scale would therefore be speculative even if the public routing footprint is technically coherent.

This missing layer should shape future research rather than invite filler. The next useful evidence would identify the actual access technologies, the points where customers depend on third parties, the power and transport dependencies at aggregation sites, and the process used to restore service. Those facts would connect the visible number-resource surface to the physical dependency chain that users experience.

Portability offers administrative flexibility, not proven resilience

The portable status of 103.249.196.0/23 deserves careful treatment because it is easy to overstate. Provider-independent or portable resources can remain associated with the holder when external connectivity arrangements change, subject to registry policy. That can reduce one administrative dependency: the addresses are not simply a sub-allocation that must disappear when one upstream contract ends.

Administrative portability can support operational options. The holder may be able to announce the same space through a replacement or additional provider, assuming routing policy, contracts, equipment, and registry data are in order. The RPKI authorisation for AS151145 further aligns the visible origin with that resource. These are useful building blocks for continuity.

They are not proof that continuity has been engineered or tested. Changing an upstream can require new circuits, configurations, filters, letters of authorisation, route-policy changes, and coordination with customers or hosting systems. Physical access to an alternative provider may not exist at the relevant location. A portable prefix cannot repair a severed local cable or restore power to a router.

The current route view shows one observed neighbour, but, as noted, that does not establish single-homing or diversity. Portability should therefore be described as an administrative property that may enable options, not as a resilience claim. The resilience question remains empirical: what alternate paths exist, how independent are they, and what happened during actual or tested failure?

The distinction illustrates a broader principle. Number-resource governance can remove friction and preserve identity across operational changes, but it cannot replace running systems. The registry's job is to keep the record unique, accurate, transferable where policy permits, and secure enough for coordination. The operator's job is to turn those records into working service and to disclose enough evidence for others to assess the result.

What RPKI cannot say about the network behind the origin

Because the sampled RPKI result is clean, it can attract more interpretive weight than it should. A valid origin is one security control at one layer. It says that the published authorisation permits AS151145 to originate the sampled /24s. It does not say that the route took an expected path, that the routers were uncompromised, or that the traffic reached a legitimate application.

RPKI origin validation is deliberately narrow. That narrowness is a strength because the statement can be evaluated consistently by machines. Expanding it rhetorically into "the network is secure" would erase the boundary that makes the evidence trustworthy. Security posture also includes software maintenance, access control, monitoring, key management, DDoS handling, abuse response, DNS integrity, and physical protection.

The sampled nature of the checks matters as well. The two visible /24s were tested, and both were valid. If the network later announces a different prefix or origin, that new pair requires its own validation. A valid result today does not permanently certify all future routing. ROAs can change, expire from the effective dataset, or become inconsistent with operations.

Operational monitoring can make the evidence more useful. A watch can compare the registered /23, visible /24s, origin ASN, maximum length, and validation state over time. A change from valid to invalid or unknown would merit rapid investigation. So would a new origin, an unexpected more-specific route, or disappearance of the covering authorisation.

The present conclusion is appropriately bounded: route-origin security metadata was correctly aligned for the two sampled visible announcements at the captured time. That is a positive operational fact. It should be preserved as such, without turning it into an assurance about every security or continuity layer behind AS151145.

A point-in-time baseline needs a time series

Most of the evidence in this profile is a snapshot. Registries retain historical fields, but the routing observations represent particular query times. A snapshot can establish identity and current state. It cannot establish stability. For that, the same measurements need to be repeated and compared.

A useful time series would track the visibility of both /24s, the origin ASN, RPKI validation, observed neighbours, and contact-record changes. It would also record measurement limitations. If 103.249.196.0/24 remains broadly visible while 103.249.197.0/24 fluctuates, the asymmetry could guide investigation. If both disappear simultaneously, a common dependency becomes more plausible, though not proven.

The route data should be correlated with service-layer checks rather than used alone. DNS resolution, reachable public endpoints, latency from multiple regions, and operator notices can help distinguish route withdrawal from application failure. Customer reports may add local context, but they need careful validation. No single signal should be allowed to carry the entire diagnosis.

Chronology also matters for registry changes. A new contact, status update, ROA change, or prefix transfer may be routine administration or part of a larger operational transition. Comparing effective dates with routing behaviour can reveal whether the public records and running network remain aligned. Misalignment is not automatically misconduct, but it is a reason to ask precise questions.

The current baseline is therefore valuable as a starting point. It records a coherent relationship among an exact entity, AS151145, one portable /23, two /24 origins, broad observed IPv4 visibility, sampled valid ROAs, and one observed neighbour. Its limitations are equally important: it contains no service time series, no physical dependency map, and no verified incident history.

Evidence layers should be compared without being collapsed

The public footprint contains several kinds of evidence, and each answers a different question. The directory entry binds the company identity used for the profile. APNIC records bind number resources and contact handles. RIPEstat observations describe what selected routing collectors could see. RPKI validation compares a route origin with published authorisation. None of those layers is redundant, but none can substitute for all the others.

An exact directory identity does not prove that every similarly named service or website belongs to the same legal operator. The APNIC records strengthen the binding because they use the company name in an operational number-resource context and associate it with AS151145. Even then, corporate ownership, licensing, and brand use can change through transactions or contracts that are not visible in the frozen sources. The identity is strong enough for the current network-resource profile, while remaining bounded to the recorded entity and resources.

The registry and routing layers can corroborate one another. The registered /23 contains both announced /24s, and the observed origin is the ASN named in the autonomous-system record. This coherence lowers the chance that the profile has combined unrelated resources. It does not prove that every route originated by AS151145 is controlled through the same equipment, staff, or facility. Administrative coherence and physical unity are different propositions.

RPKI adds another comparison rather than a replacement. The valid results show that the sampled announcements fit the published origin authorisation. They do not independently verify the company name, contact responsiveness, or forwarding path. If a future registry record changes while the ROA and routes do not, the layers may temporarily diverge. Such divergence should trigger investigation, not an automatic conclusion about which layer is wrong.

Contact data belongs in the accountability layer. It tells other operators where coordination is supposed to begin. Routing visibility belongs in the running-code layer. It shows what the measurement system saw the network doing. Physical access, power, and repair belong in the delivery layer. Keeping those categories separate makes gaps explicit and prevents a clean administrative record from masking an unobserved operational dependency.

This layered reading also prevents negative evidence from becoming too strong. No visible IPv6 origin from AS151145 is an observation in the routing layer. It is not proof that no IPv6 is offered through another ASN or arrangement. No facility record in the source set is a gap in the evidence, not proof that the company owns no facilities. The absence of a documented incident is not proof that no incident occurred.

The practical result is a more useful accountability model. Observers can state which layer supports each claim, preserve the query time, and identify the exact evidence needed to move an unknown into a supported conclusion. For Charlieboy Network, the number-resource and route-origin layers are relatively strong. The physical delivery and recovery layers remain largely open. That is a sharper finding than either a promotional company profile or a blanket statement that nothing can be known.

Monitoring should focus on changes that alter control or continuity

Not every registry or routing change has the same operational meaning. A revised contact phone number may improve coordination without changing packet flow. A new ROA may improve origin authorisation without changing the visible route. A new neighbour may represent additional transit, a temporary path, or a collector artefact. Monitoring is most useful when it distinguishes routine maintenance from changes that alter control, reachability, or failure exposure.

For the registry layer, the high-value checks are status, holder identity, contact reachability, and resource boundaries. A transfer, deregistration, or unexpected change in the responsible entities would affect the accountability story. A routine timestamp update would not necessarily do so. The evidence should preserve both the old and new values so that a reviewer can see what changed rather than merely being told that the record was updated.

For the routing layer, disappearance of either /24, a new origin ASN, or a sustained reduction in observed visibility would be material. Short-lived changes need context because BGP convergence and collector sessions can create transient observations. Repeated measurements and multiple vantage points reduce the risk of mistaking a measurement event for a network event.

For the RPKI layer, a transition from valid to invalid or not-found would deserve prompt attention. The cause could be an expired or changed authorisation, a new route specificity, or an origin change. The safe response would be to compare the effective ROA, the announced prefix, and the origin before assigning blame. A validation label is the output of that comparison, not an explanation of why the inputs changed.

For continuity, the most valuable new evidence would come from the operator or verifiable incident records: maintenance notices, documented failover tests, service-impact reports, restoration timelines, and disclosure of dependency boundaries. Such material could connect the public control plane to the access network without requiring publication of sensitive topology. It would also allow claims about recovery to rest on observed performance rather than design language.

The monitoring priority is therefore not constant collection for its own sake. It is the detection of changes that affect uniqueness, authorisation, reachability, accountability, or recovery. The current baseline provides the reference values: AS151145, 103.249.196.0/23, the two constituent /24s, sampled valid origin authorisations, broad IPv4 visibility, no visible IPv6 origin in the snapshot, and one observed neighbour. Future evidence should be assessed against those exact facts and their stated limits.

Continuity depends on layers the public record does not expose

Internet delivery depends on a chain of systems. At the top of the visible chain are registry records and route announcements. Below them sit routers, external circuits, facilities, power, access infrastructure, DNS, addressing systems, and operating teams. A failure at any of those layers can affect users even when the higher-level identifiers remain intact.

For AS151145, the registry and routing layers are comparatively transparent. The physical and organisational layers are not. No source identifies whether routing equipment is concentrated in one site, whether power has backup, whether paths share a conduit, or whether replacement hardware is available. No incident record shows recovery time or communications performance.

Redundancy claims require evidence of independence. Two logical sessions on one physical circuit are not two resilient paths. Two circuits in one conduit may share a failure domain. Two facilities can depend on one upstream power or transport system. The public BGP view cannot resolve those relationships, and the generic illustration associated with the profile is not documentary evidence.

Recovery is similarly unproved. A plan is only one part of resilience; operators need authority, access, spares, configuration control, monitoring, and practiced procedures. The public contact surface may help initiate coordination, but it does not show the internal response chain. Without test results or incident evidence, recovery performance remains an open question.

This does not make the visible technical record unimportant. Stable number resources, accurate contacts, valid ROAs, and coherent announcements reduce uncertainty and support coordination during failure. They are necessary pieces of operational continuity. The analysis simply refuses to confuse necessary pieces with the complete system.

Questions that would close the most important gaps

The first set of questions concerns the external edge. Which networks provide reachability for AS151145, and through which facilities and circuits? Is AS55879 one of several current relationships, and what exactly is its role? Are alternate paths physically independent? What route policies and RPKI validation practices apply during normal operation and failure?

The second set concerns access delivery. What technologies connect users, which parts are owned or operated directly, and which depend on third parties? Where are the aggregation boundaries? How are faults distinguished among customer equipment, local access, backhaul, upstream routing, DNS, and application layers? Public answers need not expose sensitive topology, but they can describe dependencies and control boundaries.

The third set concerns IPv6. Does the company provide native IPv6, and if so, under which ASN and prefix? Is it offered to all customers or selected services? Does the IPv6 path share the same external and physical dependencies as IPv4? The current zero-visible-prefix observation should prompt this inquiry, not settle it.

The fourth set concerns continuity. What power backup, spare equipment, configuration recovery, monitoring, and escalation arrangements support the network? When was failover last tested? What service-impact and recovery metrics can be disclosed without compromising security? An incident chronology would be more informative than a general resilience claim.

The final set concerns registry hygiene. How often are APNIC contacts and ROAs reviewed? Who is authorised to update them? What controls protect the relevant accounts and keys? Accurate registry state and route-origin metadata are part of operational security, but their maintenance is a continuing process rather than a one-time achievement.

A defensible reading of Charlieboy Network's public footprint

The evidence supports a precise conclusion. CHARLIEBOY NETWORK PRIVATE LIMITED has an active, coherent public number-resource identity centred on AS151145 and 103.249.196.0/23. The resource was visible as two /24 announcements, and the sampled origin pairs aligned with an RPKI authorisation permitting AS151145 to announce those /24s.

The same evidence supports a point-in-time observation of broad IPv4 routing visibility: 329 of 330 RIPE RIS peers in the returned dataset saw the origin. It supports the observation that no IPv6 prefix was visible from AS151145 in the corresponding snapshot. It records AS55879 as one observed neighbour. Each statement is useful when kept within its measurement boundary.

The evidence does not support a claim about subscriber count, geographic coverage, physical assets, capacity, uptime, redundancy, licence continuity, or recovery performance. It cannot turn 512 IPv4 addresses into 512 customers. It cannot turn one observed neighbour into a contracted exclusive upstream or proven backup path. It cannot turn a valid ROA into comprehensive routing security.

The strongest feature of the footprint is not size but inspectability. The registry, routing, and RPKI layers line up well enough for an outside observer to identify the resource, see how it is announced, and test whether the sampled origin is authorised. That is the reality layer on which further accountability can be built.

The remaining work is to connect that control surface to delivery. Evidence about access technology, external dependencies, physical diversity, IPv6, incident response, and recovery would show whether the network behind AS151145 is as coherent as the public number-resource record. Until then, the operating boundary should remain visible as a boundary rather than being filled with assumptions.

Sources