Summary

  • RIPE NCC's statistics service records AS211392 as held by softbank DREAM CLOUD INNOVATION LIMITED, draws the number from the 32-bit block 211356–212379 described as assigned by RIPE NCC, and reports the AS as announced across a query window ending 2026-10-18T16:00:00.
  • The same service counts 19 IPv4 prefixes covering 4,864 addresses and zero IPv6 prefixes, so the mean announced prefix is 256 addresses and no single announcement in the set can be as large as a /19.

What the registry record actually certifies

The AS-overview response for AS211392 is a short and unusually specific document. It states the resource, the block the number was drawn from, the description string "Assigned by RIPE NCC", the registry name, the holder string "softbank DREAM CLOUD INNOVATION LIMITED", an announced field set to true, and a query window that begins and ends at 2026-10-18T16:00:00 (RIPE NCC AS overview for AS211392, retrieved 18 October 2026).

Read carefully, that record certifies three things and no more: a number exists, a named holder is attached to it, and at the stated moment an observer could see something announced from it. It does not certify customers, capacity, product, billing or corporate control. The holder field is a registration string. A name that resembles a large group is a reason to go looking for a corporate filing, not a finding about who owns what.

Two counts that are not the same count

The routing-status response is where the arithmetic sits. Under announced space it reports an IPv4 object of 19 prefixes and 4,864 addresses, and an IPv6 object of zero prefixes (RIPE NCC routing status for AS211392, window ending 18 October 2026).

Those two integers get collapsed in summaries all the time: "19 prefixes" is written down as "19 networks" and then read as a measure of size. They are different quantities. A prefix count counts announcements. An address count measures space. The same 4,864 addresses could be announced as one prefix or as fifty, and the impression a reader forms would differ in each case while the addresses did not change by a single one.

Here the arithmetic is tight enough to be useful. 4,864 divided by 19 is exactly 256. The mean announced prefix in this set is therefore 256 addresses, the size of one /24. That figure is my computation from the two reported integers, not a field in the response.

What the mean rules out

A mean of 256 addresses is more restrictive than it looks once it is read against the reported total. One /19 holds 8,192 addresses; one /16 holds 65,536. The entire reported IPv4 space is 4,864. So no announcement in this set can be as large as a /19, because a single such prefix would on its own exceed the total that the response reports. Whatever the 19 entries are, none of them is a large contiguous block.

The retained excerpt of the announced-prefixes response names two of them, and both fit that constraint. 169.40.150.0/24 and 154.83.23.0/24 are /24s of 256 addresses each, and each carries a visibility timeline running from 2026-10-04T16:00:00 to 2026-10-18T16:00:00 (RIPE NCC announced prefixes for AS211392, retrieved 18 October 2026). Two of the 19 entries account for 512 of the 4,864 addresses. The two timelines are identical across the fourteen days retained, which describes a steady announcement inside this window rather than a short-lived or flapping one.

That shape — nineteen small units rather than one aggregate — is worth naming for what it is and for what it is not. It is consistent with a holder assembling scattered small allocations. It is not evidence of why that happened, and it is not evidence of what runs behind the addresses.

The zero IPv6 target

The IPv6 side of the same response reports zero prefixes. That is a dated observation and not a capability statement. Zero prefixes in this dataset at this window says nothing about whether the holder could originate IPv6 next week, and nothing about IPv6 announced anywhere else.

The layer that could not be read

An announcement is not an authorisation. Whether AS211392 is entitled to originate what it originates is recorded in a separate instrument, and here that instrument is missing rather than clean: the RPKI validation query for this origin returned no readable payload in this review (RIPE NCC RPKI validation query for AS211392, retrieved 18 October 2026).

It matters that this is recorded as a boundary and not as a finding. An empty answer from one endpoint is not evidence that route-origin attestations do not exist; it is evidence that this reviewer did not read them. Treating an unread authorisation layer as a clean one is the single easiest mistake to make with a record like this, because the numbers look complete without it. The document class that would settle the question is a published attestation listing that names AS211392 as the origin for these prefixes, or the registry's own route objects for them.

What would change this reading

Four documents would move the conclusion, and each moves a different layer. An attestation covering these prefixes would convert the authorisation gap into a stated position, in whichever direction it pointed. A routing-history record over a stated period would show whether 19 is a floor, a ceiling or a moment in a rise, and whether the small-unit pattern is old or new. A corporate filing or registry organisation object naming the holder would settle the control question that the registration string cannot.

And an IPv6 announcement observed in a later window would not contradict the IPv4 arithmetic here at all, but it would retire the description of this footprint as IPv4-only.

How to read a record like this

When a vendor list, a market map or a research note counts "networks", ask which of the two quantities it counted. Nineteen prefixes and 4,864 addresses describe the same autonomous system and support opposite impressions of its size. The registry is a reliable source for the assignment and the observation, and it is silent on the two things buyers usually want to know: whether the announcements are authorised, and what is behind them.