Summary

  • RIPE RDAP records active AS215747 under the AS name NubaCloud and links it to ORG-NB209-RIPE, whose public name is NubaCloud B.V. in Eindhoven.
  • RIPEstat sees AS215747 originate 185.189.181.0/24, 185.189.182.0/24, 185.189.183.0/24 and 2a0b:f380:3e8::/48, giving the company a compact dual-stack control-plane identity.
  • The sampled IPv4 route was visible to 328 of 329 full-table IPv4 RIS peers, while the IPv6 origin was visible to 324 of 324 IPv6 peers. Those are propagation observations, not uptime or customer-reach measurements.
  • The RIPE address object for 185.189.181.0/24 names Connect-to-cloud, not NubaCloud B.V. That distinction blocks any unsupported claim that NubaCloud owns the address block, facilities or customer infrastructure behind it.
  • RIPEstat observed one routing neighbour, AS49544, and returned RPKI valid for the sampled /24 origin. Neither fact proves commercial role, physical diversity, cloud capacity, security or continuity.

One autonomous system anchors the exact company identity

The clearest public link between NubaCloud and Internet infrastructure begins with a number rather than a product description. RIPE's RDAP response identifies autonomous system 215747 by the AS name NubaCloud. Among the registrant entities is ORG-NB209-RIPE, whose public name is NubaCloud B.V. and whose registry address is in Eindhoven, Netherlands. The name, organisation handle and unique ASN form a precise identity chain.

That precision matters because the company name is repetitive in the public record: NubaCloud NubaCloud B.V. A reader could reasonably wonder whether the repetition indicates a brand, a legal-name formatting issue or two separate organisations. The ASN record narrows the question. It does not solve every corporate relationship, but it binds one active routing identifier to one named Dutch organisation in the registry.

An ASN is globally unique within interdomain routing. Other networks use it to identify an origin and express routing policy. Monitoring systems use it to group observed routes. Operators can compare it with holder records and origin authorisations. Those functions make the ASN more useful for accountability than a generic statement that a company offers cloud or hosting services.

The RDAP chronology is administrative. The autnum object records registration on 3 September 2025 and a last change on 15 December 2025. Those dates do not reveal when the company began trading, when equipment entered service, when its first route appeared, or when any customer began using a platform. Registry events and operating events are different clocks.

The exact conclusion is therefore limited but strong: a current public record associates AS215747 with NubaCloud B.V. It does not establish the company's ownership structure, staff, facilities, products or commercial reach. It does create a stable number-resource surface against which routing and security metadata can be tested.

Three IPv4 routes define a compact visible surface

RIPEstat's announced-prefixes response lists three IPv4 routes for AS215747: 185.189.181.0/24, 185.189.182.0/24 and 185.189.183.0/24. Each /24 contains 256 addresses, so the three routes cover 768 IPv4 addresses in the sampled view. Routing status independently reports the same total of three prefixes and 768 addresses.

This is a compact public origin set. An observer can enumerate it without reconstructing a large collection of more-specifics. Each route has a clear prefix length, and changes to the set can be detected by comparing future snapshots. That simplicity makes the external control surface measurable.

The address count is not a capacity measure. One address can identify a router interface, a virtual machine, a shared gateway, a hosted service or unused inventory. Network address translation can place many users behind a small public range. Conversely, a block can be reserved without supporting a current customer service. There is no reliable conversion from 768 addresses to subscribers, servers, bandwidth, revenue or geographic reach.

The prefix count also says nothing about the private topology. Three /24s could be routed through one edge, several routers, several sites or infrastructure supplied by another operator. They could support separate services or share one failure domain. Global BGP shows the origin relationship, not the internal design.

The announced-prefixes endpoint carries its own visibility threshold. Its response says that routes seen by fewer than ten RIS full-feed peers are excluded. The returned set is therefore a strong view of visible origins, not a promise that no low-visibility or transient route exists elsewhere.

The defensible statement is narrow: at the captured interval, AS215747 visibly originated three IPv4 /24s containing 768 addresses. The result provides a monitoring baseline. It does not prove how the addresses are assigned, where systems sit, what customers receive, or whether the private network is simple, distributed or resilient.

One IPv6 /48 makes the origin dual stack

The same announced-prefixes response lists 2a0b:f380:3e8::/48. Routing status counts one IPv6 prefix and one /48-equivalent, while the visibility field says 324 of 324 sampled IPv6 RIS peers saw the AS215747 origin. Within the captured control-plane view, the autonomous system is therefore dual stack.

That finding is operationally useful because it is specific to the ASN. A company may mention IPv6 without originating a route, or may receive IPv6 through another network. Here, a globally visible /48 appears under the same autonomous system that originates the three IPv4 /24s. The route can be checked and monitored independently.

A /48 is an address-planning boundary, not a count of active endpoints. IPv6 contains an enormous address space, and operators commonly allocate subnets without filling every address. Turning a /48 into a server count, customer count or scale estimate would be meaningless. The prefix length describes routing and allocation structure rather than utilisation.

Full sampled visibility does not prove that applications are reachable over IPv6. DNS may not publish an AAAA record. A firewall may block traffic. Hosts can be absent or misconfigured. Path MTU, peering policy or application behaviour can fail even while the BGP route remains visible. Control-plane propagation and service-level operation must be tested separately.

The IPv6 route also does not prove parity with IPv4. The two protocols may terminate on different equipment, follow different external paths or support different services. The source set contains no traffic measurement, latency test, address inventory or customer configuration. It cannot support a claim of equal performance or coverage.

What the /48 adds is a second observable protocol surface. If it disappears while IPv4 remains, the change would be protocol-specific. If the origin changes, the responsibility boundary changes. If visibility falls, investigators can ask whether the event is collector-specific, policy-driven or operational. The current snapshot establishes the baseline without pretending to answer those later questions.

The visibility ratios describe propagation, not availability

RIPEstat reports that 328 of 329 full-table IPv4 RIS peers saw the AS215747 origin at the captured query time. For IPv6, 324 of 324 peers saw it. These ratios show broad propagation across the sampled route collectors. They add running-code evidence to the registry record.

The denominator matters. RIS peers are observation points in the routing system. They are not every broadband user, enterprise, resolver, firewall, transit path or application. A route can be visible to almost every sampled peer while packets encounter loss, congestion, filtering or host failure. Conversely, a collector anomaly can affect a visibility ratio without causing widespread customer impact.

Neither ratio can serve as an uptime percentage. The values describe a captured control-plane state, not continuous service over a month or year. They do not test every address, measure response time or establish that workloads were functioning. Writing "328 of 329" as "99.7 per cent availability" would confuse different measurements.

The IPv4 gap of one peer should also be handled carefully. It could reflect policy, filtering, collector state or a transient condition. The source does not identify a customer outage or failed interconnection. The missing observation is a reason to preserve the exact numerator and denominator, not to invent a cause.

The value of the ratios is comparative. A future snapshot can show whether IPv4 remains near-universal in the sample, whether IPv6 stays fully visible, or whether one protocol changes independently. Such changes create questions for further investigation. They do not automatically provide answers about users or infrastructure.

For NubaCloud, the visibility data supports a clear conclusion: its compact dual-stack origin set was broadly visible in the RIPE RIS sample. That is stronger than registry presence alone. It remains weaker than proof of cloud-service availability, end-to-end reachability, workload continuity or customer experience.

The address record introduces a material identity discrepancy

The RIPE address object for 185.189.181.0/24 does not name NubaCloud B.V. Its netname is connect-to-cloud, and its public organisation identity is Connect-to-cloud. The active range runs from 185.189.181.0 through 185.189.181.255, with country code NL. This is not a minor formatting difference.

At the same time, RIPEstat sees AS215747 originate the /24 and names the ASN holder NubaCloud NubaCloud B.V. The two records describe different dimensions. The address record concerns the registered network range. The routing data concerns the observed origin. Agreement on the origin does not erase the difference in registered organisation names.

Several explanations are possible: a lease, assignment, service arrangement, corporate relationship or historical resource configuration. The eight public sources do not establish which explanation is correct. Selecting one would turn an observed discrepancy into an unsupported legal or commercial claim.

The discrepancy therefore becomes part of the control boundary. NubaCloud can be described as the observed route origin through AS215747. Connect-to-cloud can be described as the organisation named on the sampled address object. Ownership, right of use, delegation and operational control beyond those exact statements remain unproved.

This separation protects readers from a common infrastructure error. Routing a prefix does not necessarily mean owning it. Holding a registry object does not necessarily mean operating every router that announces it. Supplying a service does not necessarily mean owning the facility or transport that carries it. Each relationship can be valid while remaining distinct.

The gap also creates a concrete due-diligence question. Which agreement allows AS215747 to originate the Connect-to-cloud range, and which party is responsible for changes, abuse handling and continuity? The public records identify the parties and the observed route. They do not expose the agreement. Responsible analysis should show the question without manufacturing the answer.

Prefix overview confirms the origin, not the contract

RIPEstat's prefix-overview response maps 185.189.181.0/24 to AS215747, names the holder NubaCloud NubaCloud B.V., marks the prefix announced and reports no related more-specific prefixes in that response. This alignment supports the narrow claim that the exact /24 was observed under the NubaCloud ASN.

The absence of related more-specifics simplifies the sampled public view. An observer does not need to decide which subordinate route carries traffic for the block. The /24 is the unit exposed at the interdomain boundary. A future more-specific could be identified as a new event.

No more-specific in this response does not mean no internal subnetting. Operators divide address space inside their networks without announcing each subnet globally. Private routes, virtual networks and customer allocations are invisible to this endpoint. The result describes the public BGP surface, not the internal address plan.

The holder field also does not supersede the RDAP address registration. Prefix overview derives an observed origin relationship and associates it with the ASN holder. It is not a contract database. It cannot determine whether the origin is based on ownership, lease, delegation or another authorised arrangement.

Nor does a clean origin prove correct forwarding. Packets can reach the ASN and then fail because of routing policy, firewall rules, host state, DNS or application problems. BGP identifies the destination network at one layer; it does not validate every service behind it.

The prefix overview is most valuable as corroboration. Announced-prefixes lists the /24, routing status counts it, and prefix overview maps it to AS215747. RPKI then tests whether that origin is authorised. The convergence creates a strong control-plane record. It does not disclose the commercial and physical layers hidden behind the record.

For future monitoring, the exact fields should remain separate: prefix, origin ASN, announced status, related-prefix count, holder name and query time. A change in one field need not imply a change in all the others.

One observed neighbour shows an edge without mapping the network

RIPEstat's AS-neighbours response records one observed left-side neighbour for AS215747: AS49544. Routing status independently counts one observed neighbour. The snapshot therefore exposes one adjacent routing domain in the collected paths.

The relationship should be described as observed, not defined. BGP path data does not publish the commercial contract. AS49544 might be acting as a provider, peer, customer or another form of routing counterpart depending on direction and policy. The endpoint does not reveal price, service level, port speed or contractual responsibility.

One ASN relationship also does not equal one physical circuit. Several links, devices or sites can support the same relationship. A backup may remain hidden until used. Conversely, two logical sessions can share one duct, power feed or building. The public control plane cannot demonstrate physical diversity.

The observed neighbour therefore identifies a handoff question rather than a resilience answer. Where does the exchange occur? Which party supplies transport? Are multiple ports or locations involved? Can another path carry full load? Has failover been tested? No captured source answers these questions.

The compact neighbour set may still matter during a change. If AS49544 disappears from future observations, a new neighbour appears, or the prefix origin becomes less visible, investigators have a dated baseline for comparison. They should not assume that a change reflects an outage, contract termination or migration without corroborating evidence.

The same restraint applies to continuity. A stable BGP neighbour can coexist with application failure. A neighbour change can occur without customer disruption. Route collectors see path information, not workloads. Their value lies in identifying a public edge that can be watched.

For NubaCloud, one observed neighbour adds a visible external dependency to the ASN record. It does not describe the complete topology, the physical route, the cloud platform or the customer path. That distinction prevents a single adjacency from becoming a false claim of either fragility or redundancy.

Valid RPKI binds one origin at one point in time

The bounded RIPEstat RPKI query for 185.189.181.0/24 originated by AS215747 returns valid. Its validating list contains an exact /24 Route Origin Authorisation with origin 215747 and maximum length 24. Prefix, origin and authorisation align in the captured validator response.

This is meaningful security metadata. Route Origin Validation lets relying networks compare a BGP origin with a cryptographically signed authorisation connected to the address resource. An exact maximum length of 24 authorises this route length without granting permission for more-specific origins under the same record.

The scope is precise. RPKI validates the origin relationship, not the complete AS path. It does not prove that forwarding is correct, that hosts are secure, or that customer workloads are protected. It does not certify company governance, support processes or physical infrastructure.

A valid route can still fail. The authorised ASN can withdraw it, lose transport, misconfigure forwarding or depend on a failed supplier. DNS and applications can break while the route remains valid and visible. Origin authorisation and service availability are separate signals.

The result also applies to the sampled /24, not automatically to every route in the four-prefix set. Each prefix-origin pair needs its own current validation result. Extending one valid response to all IPv4 and IPv6 space would exceed the bounded query.

The address-registration discrepancy does not disappear either. A valid ROA says that AS215747 is authorised to originate the prefix under the relevant resource certification chain. It does not disclose the commercial agreement or prove corporate ownership. Authorisation is a control fact, not a title deed.

The useful conclusion is that one visible NubaCloud-originated /24 had positive origin-authorisation metadata at the captured time. Future monitoring can distinguish valid, invalid and unknown, while separately tracking route visibility and holder records. Keeping those fields apart makes the evidence more operationally valuable.

A cloud-service category is not a facility inventory

NubaCloud is classified under cloud service for navigation and subject framing. That category points to relevant questions about hosted workloads, network access, support and continuity. It does not prove that the company owns a data centre, leases racks, operates servers or sells a current cloud product.

The public source set used here is entirely about registry and routing surfaces. It contains no facility list, hardware inventory, service catalogue, customer contract, support policy, storage architecture, orchestration platform, power design or recovery test. A cloud-service story that filled those gaps from the category would be speculation.

Even the address netname connect-to-cloud should not be treated as product proof. A registry label can describe an administrative purpose or historical assignment. It does not verify a live service, pricing, capacity or customer availability. The name is useful for identity comparison, not as a substitute for operational evidence.

Several delivery models could sit behind the observed ASN. NubaCloud could operate equipment directly, use leased infrastructure, rely on a partner, provide network access to a platform, or support a service whose physical assets belong elsewhere. The current records do not choose among these possibilities.

This uncertainty does not make the network data irrelevant. On the contrary, the ASN and prefixes define one part of the service chain that would matter to any hosted workload. If the routes change, access to systems behind them may be affected. But whether a particular customer or workload depends on those routes requires separate proof.

The responsible framing is therefore a cloud-service company with a measurable dual-stack routing identity. The visible surface supports questions about route origin, number-resource accountability and external dependency. Facilities, racks, servers, capacity, customers and recovery arrangements remain outside the evidence.

That boundary keeps the analysis useful to operators and customers. It identifies what can be monitored now and what must be requested during due diligence, without turning a navigation label into a technical architecture.

Registry chronology and routing chronology answer different questions

The autnum object records registration on 3 September 2025 and a last change on 15 December 2025. Routing status, however, lists a first-seen event involving an IPv6 route on 16 January 2024. The dates do not form a simple company timeline.

Public registry and routing systems can preserve different histories. Objects may be recreated, transferred, renumbered or updated. Collector history may refer to an ASN-origin relationship that predates the current registry object's recorded registration event. The sources do not explain the administrative sequence.

That mismatch should be preserved rather than smoothed into one launch date. The registry date says when the current RDAP object records registration. The collector date says when RIPEstat first saw an origin associated with the resource in its data. Neither date proves when NubaCloud began operating, when a customer service launched or when equipment was installed.

The last-seen field provides another layer. Routing status records 185.189.181.0/24 under AS215747 at midnight UTC on 29 July 2026, while the query snapshot is dated 28 July. The different timestamps reflect the way the service reports observations. They are useful for monitoring but not precise evidence of continuous operation.

Chronology becomes safer when each event retains its source and meaning. Registry registration, last change, first route observation, latest route observation and query time should not be collapsed into one date. A later change can then be compared against the correct baseline.

The mismatch also creates a due-diligence question about continuity of control. Did the resource relationship exist before the current organisation record, or does the collector's earliest event reflect another configuration? The current evidence cannot answer. It can identify the question and prevent an incorrect origin story.

This method follows running code without treating it as sovereign. The route history shows what collectors observed. The registry shows what the recordkeeper currently maintains. Operational and legal conclusions require additional evidence where the two clocks do not align.

Address stewardship and routing control are separate responsibilities

The difference between Connect-to-cloud on the address object and NubaCloud on the ASN origin illustrates a broader Internet governance principle. Address stewardship and route origination can belong to different parties or be connected through contracts that are not public. Both responsibilities matter, but they are not interchangeable.

The address-side responsibility includes accurate registration, delegation, abuse contacts and transfer or assignment records. The routing-side responsibility includes announcing the correct prefix, maintaining policy, avoiding leaks and coordinating changes. A service operator may participate in both, one or neither depending on the arrangement.

When an incident occurs, this separation affects escalation. A route-origin problem may need the ASN operator. An abuse complaint may follow the address object's contact. A contractual dispute may involve a supplier not named in either public record. Treating one holder field as the complete chain can send reports to the wrong place.

The records used here provide some handles but not the agreement between them. They do not disclose who can revoke the route, who controls the ROA, who assigns addresses to systems, or who must restore connectivity. Those are material continuity questions for any hosted service.

They also do not prove that the discrepancy is a problem. Shared resources, assignments and delegated origins can be legitimate. The analytical task is not to accuse either party. It is to make the boundary visible so that readers understand which claims have public support and which require confirmation.

For due diligence, the next evidence should include a current statement of resource authority, the relevant service or delegation agreement, escalation contacts and change-control procedures. Independent route monitoring can then be connected to accountable owners.

The public baseline remains valuable even without those documents. It shows the exact ASN, exact sampled prefix, two organisation names, an observed origin and a valid authorisation. That is enough to ask precise questions without claiming more than the evidence can bear.

Operational continuity depends on hidden layers

A stable route is only one condition for service continuity. Traffic must also cross functioning links, routers, firewalls, load balancers, hosts, storage systems, power systems and software. People must detect failures, coordinate suppliers and restore service. None of those layers is described by the eight public sources.

The route set could remain visible while a workload is unavailable. An edge router may continue announcing prefixes even when servers fail. DNS can point to an unreachable address. Authentication or storage can fail behind a healthy network. Broad RIS visibility would not distinguish these cases.

The reverse is also possible. A route collector may stop seeing one path while customers continue to reach services through another route or policy. A prefix may move to another ASN during a planned migration. Public route change is a signal for investigation, not a self-explanatory outage record.

Physical continuity is especially opaque. The source set names no data centre, rack, power feed, fibre route, exchange or carrier. One observed BGP neighbour cannot prove path diversity. Multiple logical origins would not necessarily prove separate physical failure domains.

Organisational continuity is also hidden. Registry contacts can become stale. A supplier can change. A small operations team can be overloaded. A contractual dependency can delay repair. These risks matter but cannot be scored from the ASN record alone.

The correct use of the public data is to define a monitored outer boundary. Operators can watch the four-prefix set, visibility ratios, neighbour and RPKI state. Customers can ask how those external signals connect to tested internal recovery arrangements. The two evidence sets should complement rather than replace each other.

For NubaCloud, the dual-stack origin establishes a real operational surface. It does not establish end-to-end continuity. Any claim about resilience requires topology, supplier, capacity, failover and recovery evidence that the current records do not provide.

Customer due diligence should follow the dependency chain

A customer evaluating a hosted or cloud-related service needs more than proof that an ASN exists. The public route is a starting point for tracing dependencies. It identifies an origin, a compact prefix set, one sampled neighbour and a difference between the ASN holder and one address registrant.

The first questions should concern authority. Which party permits AS215747 to originate the sampled Connect-to-cloud prefix? Who controls the ROA? Who updates registry contacts? What happens if the resource arrangement ends? The public responses do not supply those answers.

The second group concerns physical delivery. Which facilities and carriers carry the routes? Are IPv4 and IPv6 delivered through the same edge? Do separate circuits share ducts, power or buildings? Can another path carry normal load after a failure? One BGP neighbour cannot settle these questions.

The third group concerns service operation. Which systems use the four prefixes? How are workloads backed up? Which support team owns network incidents? What response and restoration objectives are contractually defined? The ASN does not reveal servers, customers or support obligations.

The fourth group concerns change control. How are prefix, origin and ROA changes reviewed? Is there monitoring for invalid origins or visibility loss? Can customers receive timely notice of maintenance or migration? Registry and routing baselines become more useful when an accountable process exists around them.

The fifth group concerns exit. Can customers move data and addresses? What happens to DNS, certificates and access controls? Does a change in provider require renumbering? The current resource records do not describe portability.

These questions do not presume failure or weakness. They translate the visible boundary into a practical evidence request. A company can answer them with architecture, contracts, tests and operating records. Until then, the public ASN supports a narrow accountability statement rather than a broad assurance of cloud-service continuity.

Abuse handling is another boundary hidden behind the records

The RDAP response includes an abuse-role structure connected to the autnum registrant. The sampled IPv4 object also carries an abuse contact associated with Connect-to-cloud. The two contact paths reflect the same separation seen in the holder records.

An abuse contact is necessary for accountability around spam, scanning, compromise and other harmful traffic. It provides a place to send a report. It does not prove that messages are read, investigated or resolved within a useful time.

The presence of two organisation contexts can complicate escalation. A complaint may concern an address registered to Connect-to-cloud but originated by NubaCloud's ASN. Responsibility could depend on allocation, hosting and customer arrangements that are not visible. A sender may need both parties to coordinate.

Operational quality cannot be inferred from the fields. The records do not show staffing hours, ticket systems, response targets, evidence requirements or outcomes. They cannot support praise or criticism of either organisation's abuse handling.

The public baseline can still improve incident work. It identifies the exact resource and origin, preserves the contact paths and distinguishes the organisations. A report can cite the prefix, timestamp, observed behaviour and relevant registry handles rather than relying on a brand name alone.

For a cloud-related service, abuse response is part of continuity as well as security. Slow handling can affect reputation, filtering and customer access. Overbroad enforcement can also disrupt legitimate users. The balance requires transparent process and accurate resource records.

The current evidence supports only a bounded conclusion: public abuse-role metadata exists on the relevant records. Its effectiveness and the allocation of responsibility between NubaCloud and Connect-to-cloud require observed process evidence or direct confirmation.

Monitoring should keep six fields separate

A useful baseline for AS215747 should not collapse everything into one status. At least six fields deserve separate tracking: ASN registration, prefix set, route visibility, observed neighbour, RPKI status and service-level health. Each changes for different reasons and supports different conclusions.

ASN registration identifies the current holder record. A holder or handle change is administrative evidence. It may accompany a transfer or reorganisation, but it does not prove that routers or services changed at the same moment.

The prefix set records what AS215747 visibly originates. Adding or removing a /24 or /48 changes the public routing surface. It does not reveal whether a customer, facility or product changed.

Visibility ratios show how widely collectors see the origin. A fall may indicate filtering, propagation change, collector state or an incident. It is not an automatic outage percentage.

The observed neighbour records one sampled external path relationship. A change can signal policy or interconnection movement. It cannot, without corroboration, identify the commercial cause or physical impact.

RPKI status tests origin authorisation for a specific prefix and ASN. It can become invalid or unknown while the route remains visible. That is a distinct security-metadata event rather than proof of service failure.

Service-level health requires independent tests: DNS, application response, packet loss, latency and workload behaviour. These measurements can fail while BGP remains healthy. They cannot be replaced by routing data.

Keeping the fields separate creates better incident narratives. Investigators can state exactly which layer changed, when it changed and which layers remained stable. For NubaCloud, the current baseline includes an active ASN, four observed origins, broad sampled visibility, one neighbour and one valid sampled ROA. Service health and physical continuity remain unmeasured.

The compact route set is useful for change detection

The current AS215747 origin set is small enough to monitor as a complete named group within the captured threshold: three IPv4 /24s and one IPv6 /48. That makes future change detection straightforward.

If one IPv4 /24 disappears while the others remain, the event is prefix-specific. If all four origins disappear, the event affects the ASN's visible set in the sampled view. If IPv6 changes independently, the event is protocol-specific. Each pattern guides a different initial question.

An origin change would be more significant than a visibility fluctuation. It would alter the public responsibility relationship for a prefix. The RPKI state would then need to be checked against the new origin. Registry holder fields would need separate review.

A new neighbour could indicate an additional path, a policy change or collector visibility. It would not automatically prove redundancy. A disappeared neighbour could reflect route selection rather than a terminated link. Comparison should remain descriptive until operational evidence appears.

The registration discrepancy also deserves monitoring. If the sampled IPv4 object changes from Connect-to-cloud to NubaCloud, that would be a registry event. If it changes to another party, the authority boundary would need fresh review. Neither event should be interpreted without its source date.

Public monitoring is strongest when it preserves exact values and avoids motive. Prefix, ASN, status, holder, timestamp and validation result can be recorded precisely. Causes such as outage, migration, acquisition or contract change require corroboration.

This approach turns a small network identity into an accountability surface without exaggerating it. The current snapshot is not a score. It is a reference point that makes later differences visible and gives operators a disciplined sequence for investigation.

Registry records are a ledger, not a complete operating truth

The NubaCloud records demonstrate why a registry should be treated as a ledger and recordkeeper. It preserves unique numbers, named holders, contacts, status and change events. Those functions support coordination across networks that do not share one owner or legal system.

The ledger is essential because BGP alone carries numbers, not a complete explanation of responsibility. A route path can show AS215747, but the registry connects that number to NubaCloud B.V. The address object connects a prefix to Connect-to-cloud. RPKI adds an authorisation layer.

No single record is sovereign over the physical network. A registry object can be stale. A route can be visible under an authorised origin while the service behind it fails. A contact can exist without an effective response. Running code and maintained records must be compared.

The strongest facts here are the points of convergence: the ASN name, organisation handle, AS overview and observed origin. The most important uncertainty is the point of divergence: the sampled prefix's organisation name. Both belong in the same analysis.

Treating the ledger as complete truth would invite unsupported claims about ownership, cloud delivery and facilities. Ignoring it would discard the identifiers needed to attribute routes and coordinate incidents. The proper position is between those extremes.

Accuracy and continuity are connected. During a staff change, supplier dispute or technical incident, correct holder and contact metadata can reduce ambiguity. It cannot restore a failed service, but it can help the right parties find each other.

For NubaCloud, the public record establishes a real network identity and a measurable route boundary. The private agreements, systems and people that make the service operate remain outside the ledger. A mature accountability model uses the registry to frame those missing questions rather than pretending they have already been answered.

A future evidence package should test the hidden claims directly

The current public sources support an ASN-and-routing analysis, but they cannot support a full cloud-service evaluation. The next evidence should address the layers that the control plane leaves hidden.

Facility evidence should identify the sites used to deliver service, the operator of each site, and whether NubaCloud owns, leases or buys capacity there. Public names and marketing pages are not enough. Contracts, current service records or independently verifiable facility listings would be stronger.

Network evidence should identify upstream and peer roles, port or circuit diversity, shared failure domains and tested failover. The one observed AS49544 relationship is a starting point, not a topology. IPv4 and IPv6 paths should be checked separately.

Resource evidence should explain the Connect-to-cloud prefix relationship. A current delegation or service statement could clarify which party controls assignment, ROA changes, abuse handling and withdrawal. The explanation should preserve the distinction between ownership and authorised use.

Service evidence should document which workloads depend on the four observed origins, how applications are monitored, and what restoration targets apply. End-to-end tests should be separated from BGP visibility.

Customer and portability evidence should explain data export, DNS migration, address changes, access controls and support escalation. These questions determine the cost of failure or exit more directly than prefix count.

Each layer should carry dates and accountable owners. A facility list can become stale. A transit agreement can change. A route snapshot can change within minutes. Evidence is strongest when its time scope is explicit.

Until those materials exist, the public network identity should remain the centre of the claim. NubaCloud is associated with AS215747, a compact dual-stack route set, one sampled neighbour and a valid sampled origin authorisation. The delivery architecture behind that identity remains a subject for verification.

The visible boundary supports accountability without advocacy

The evidence neither proves that NubaCloud is robust nor proves that it is fragile. It provides a set of observable responsibilities and unknowns. That is enough for useful infrastructure analysis.

The company has an exact ASN identity in RIPE. RIPEstat sees three IPv4 /24s and one IPv6 /48 under that ASN. The routes were broadly visible in the sampled peers. One neighbour was observed. One sampled /24 origin was RPKI valid.

The same evidence also limits the conclusion. The sampled IPv4 registry object names Connect-to-cloud. No source establishes ownership of the address block, data centres, racks, servers or access infrastructure. No source identifies customers, capacity, service levels or recovery tests.

These limits are not a weakness to hide. They define the boundary between recordkeeping, running code and service claims. Readers can distinguish what is independently observable from what requires direct evidence.

Advocacy would flatten that distinction. A promotional account might turn broad visibility into reliability or a valid ROA into security. A hostile account might turn one observed neighbour into fragility or the holder discrepancy into wrongdoing. Neither conclusion is supported.

Reality is more specific. The public origin exists. The registry identities differ at one layer. The route has a current authorisation signal. The delivery chain is private. Each statement can be checked against a dated source.

That structure makes the record useful during future change. If the prefix set, neighbour, holder or RPKI state moves, the change can be described precisely. If no control-plane field changes during a service incident, investigators know to look deeper in the application and physical layers.

The result is a measured accountability baseline. It does not replace operational disclosure. It tells NubaCloud, its suppliers and its customers which public facts already exist and which continuity questions remain unanswered.

AS215747 is the beginning of the inquiry, not the end

NubaCloud's public network identity is more substantial than a generic company profile and less complete than a service map. AS215747 provides a unique responsibility anchor. The four observed origins provide a bounded dual-stack surface. Visibility, neighbour and RPKI data make that surface measurable.

The prefix-registration discrepancy prevents a simple ownership story. Connect-to-cloud appears on the sampled address object, while NubaCloud appears as the ASN holder and observed origin. The records can coexist legitimately, but the agreement behind them is not public in the captured set.

That uncertainty should guide the next questions. Who controls the route and ROA? Who assigns the addresses? Which facilities and carriers carry traffic? Which systems and customers depend on the prefixes? How is failover tested? Who restores service when one layer fails?

None of those questions can be answered by counting addresses or peers. Three /24s do not quantify cloud capacity. One /48 does not quantify IPv6 use. Near-complete visibility does not quantify uptime. One neighbour does not quantify physical diversity. Valid RPKI does not certify the platform.

What the data does provide is a disciplined starting point. The registry records the identities. The route collectors show running origins. The validator reports one current authorisation state. Future evidence can be attached to those exact identifiers rather than to a vague brand.

For customers and operators, that is the practical value of AS215747. It makes one part of NubaCloud's external control surface visible while leaving private dependencies clearly marked. Accountability begins where unique records and observed behaviour meet. It remains incomplete until the physical, commercial and service layers are independently demonstrated.

Sources