Summary

  • An ARIN direct allocation for 204.235.252.0/22 names PingPush LLC, but ARIN's organisation record attaches no autonomous system to the company, and the only route object covering the block belongs to AS5650.
  • A BGP monitor shows AS5650 and AS53356 announcing the prefix at the same time, renders the AS53356 route IRR-invalid and ROA-signed-invalid, and labels the registrant with a third name, SixtyNet LLC.
  • Nothing inspected links PingPush LLC to Free Range Cloud Hosting Inc, which operates AS53356; a lease or private arrangement between them would be ordinary, and the public records would look the same either way.

A registry line is the cheapest piece of due diligence in the IPv4 market, and the least conclusive. Pull the records for 204.235.252.0/22 today and you get three documents that cannot all be describing the same network: an ARIN allocation naming a Virginia company, a route object naming a different autonomous system, and a live routing table in which two systems announce the block at once — one of them failing every origin check a border router can perform.

Start with the registry, because that is where a buyer starts. ARIN organisation handle PL-1212 belongs to PingPush LLC at 803 Franklin St. Suite 801, Arlington, VA 22314, created on 18 August 2022 and last updated on 4 June 2026 (ARIN organisation record). The organisation's related-network listing returns exactly one entry, PINGPUSH-NETWORK, covering 204.235.252.0 through 204.235.255.255 (related networks). The network record itself, NET-204-235-252-0-1, states a /22, network type Direct Allocation, organisation PingPush LLC, registration date 11 April 2024 and a last update of 3 August 2026 (network record). That is a clean record — the profile of a company that went to the registry and obtained its own block rather than inheriting one from a provider.

Then the clean record stops being complete. ARIN's listing of autonomous systems related to the organisation returns HTTP 404 rather than a number (related ASNs). An autonomous system is a network under a single routing policy, identified by a number, and that number is the routing identity other networks actually see: it is what a filter checks before accepting a route. PingPush LLC appears in the registry as an address holder with no routing identity attached. Those are two different roles in the same industry, and the registry only testifies to the first.

The routing-policy layer says something else again. RIPE Stat's routing status for the prefix records a first observation from origin AS53356 on 16 April 2024 at 16:00, and a most recent observation from origin AS5650 on 11 November 2026 at 16:00; the route objects covering the block are listed only for AS5650, registered under ARIN (RIPE Stat routing status). A route object is a separate registration, kept in an Internet Routing Registry rather than the address registry, stating which autonomous system is authorised to originate a prefix. AS5650's own routing record is public (AS5650). For PingPush's block that authorisation exists in exactly one place, and it names a network the organisation record never mentions.

The live table is where the divergence becomes operationally visible. A BGP monitor page for 204.235.252.0/22 shows both AS5650 and AS53356 announcing the prefix. It renders the AS5650 route IRR-valid and ROA-signed-valid, and the AS53356 route IRR-invalid and ROA-signed-invalid (BGP view of the prefix). A ROA is a signed statement, under the Resource Public Key Infrastructure, naming which autonomous systems may originate a block; a route contradicting it is rendered invalid, while IRR validity is the older and softer equivalent. The same page labels the registrant as SixtyNet LLC, a name that matches neither the ARIN network record above nor anything else in this file. A second routing directory lists the same two origins and flags the prefix as multi-origin with a conflict marker (second directory).

Multi-origin routing is not automatically a fault; large networks announce one prefix from several places by design. It is the combination that matters here: two origins, one route object, and an additional announcement that both validation systems reject.

The unregistered origin belongs to a hosting company. PeeringDB identifies AS53356 as Free Range Cloud Hosting Inc, also known as Free Range Cloud, a business selling VPS services, with peering information last updated on 24 September 2026 (PeeringDB AS53356). Nothing in the public record inspected for this article connects that company to PingPush LLC — no lease, no transfer, no reassignment, no agreement. That gap is a limit of this file, not a finding about either business. A legitimate arrangement between them is an entirely ordinary possibility, and the records as published would look much the same either way.

The timing is what makes the file worth keeping. ARIN registered the allocation on 11 April 2024. The first announcement anyone observed came from AS53356 on 16 April 2024 — five days later, from the origin that carries no route object. A fresh allocation usually reaches the table quickly; what it rarely does is arrive first from a network the registry has never named.

The holder's own public footprint is thinner than its registry entry suggests. pingpush.net did not answer: the request timed out or returned HTTP 502 (pingpush.net). An indexed copy roughly 4.2 years old describes programmable physical spaces with hardware anchor beacons, a cloud dashboard, digital-twin features, retail and asset tracking, REST and JavaScript APIs, VPN connectivity, and developer, small-business and enterprise tiers, at the same Arlington address. That copy describes no GPU rental, no compute service and no hosting product, and at four years old it is evidence of what the company said once rather than what it sells now. A geolocation database attributes 204.235.254.216, an address inside the block, to PingPush LLC and pingpush.net in Arlington, Virginia, with AS5650 (geolocation record) — a database attribution, not proof of a facility or a customer relationship.

Two retrieval limits belong beside those facts rather than at the end of them. The RDAP representation of the organisation was served as application/rdap+json and could not be parsed by our tooling, so every registry figure here comes from ARIN's Whois-RWS pages (RDAP entity). And the Cloudflare RPKI portal returned no per-origin validity for the prefix (RPKI lookup), so the ROA verdicts in this article are reported as the BGP monitor renders them, not as read from a primary repository.

What BTW concludes from the pattern is narrower than the alarm it could support. The three layers that are supposed to agree — registry, route object, live table — do not enforce one another, and nobody in this file is accused of anything. Uniqueness coordination, as we read the principle, asks of a record that it be unique, accurate and usable. The /22 is unique and the records are silent on the other two. An allocation with no route object for its real origin is an asset a company can hold and cannot reliably route, and on any given day it is the internet's filtering behaviour, not the registry, that decides which of the two it is.

Two things would settle the file. A route object filed for whichever origin is genuinely authorised, or a ROA naming it, would replace the question with an answer; so would ARIN's own position on the divergence. Until one of those appears, anyone pricing, leasing or acquiring this block is working from a document that names an owner, alongside three records that cannot all be right and two networks announcing a prefix that only one of them has registered authority to announce. The entity's own public record is collected in our PingPush LLC directory entry.