Summary

  • RIPE records identify QuickSoft LLC as a Russian LIR and AS62222 as its assigned autonomous system.
  • A bounded RIPEstat response showed four IPv4 /22s and two IPv6 /48s visible for AS62222.
  • QuickSoft's operator-maintained PeeringDB record listed six operational exchange connections across Moscow, Saint Petersburg, Frankfurt and Helsinki.
  • Those records describe administrative and interconnection surfaces, not customer traffic, contractual responsibility, redundancy or recovery performance.

QuickSoft's public footprint offers an appealingly simple story. Its PeeringDB entry lists six operational exchange connections, most with both IPv4 and IPv6 addresses. RIPEstat shows the autonomous system announced, with six visible prefixes. The temptation is to turn those counts into a conclusion about reach or resilience.

That would ask the evidence to do work it cannot do.

The administrative layer is clear. RIPE NCC's member record lists QuickSoft LLC in Russia and gives a Moscow address. The organisation object identifies ORG-QL35-RIPE as an LIR and records registration number 1137746726193. The aut-num object assigns AS62222, named QS-AS, to the company. These records establish a registered identity and control surface. They do not describe a retail product or a service commitment.

The observation layer adds present-tense evidence. At the time reviewed, RIPEstat's AS overview marked AS62222 as announced. Its announced-prefix response returned four IPv4 /22s and two IPv6 /48s. This is stronger than a registration alone: route collectors were seeing prefixes originated by the ASN in the bounded observation.

Even so, the result does not reveal which customer service uses which prefix, how much traffic it carries or what happens when a path fails. A route collector observes control-plane visibility. It does not audit a contract, measure application performance or identify the team accountable for restoration.

The interconnection record is similarly useful and bounded. QuickSoft's PeeringDB network entry describes the network as content-oriented, with an open peering policy, a balanced traffic ratio and support for IPv4 and IPv6. The exchange records list Global-IX, GNM-IX and PITER-IX locations in Moscow, Saint Petersburg, Frankfurt and Helsinki. Five of the six entries show both address families.

PeeringDB is maintained by network participants. Its records are valuable coordination assertions, not independent measurements that every session is established or carrying traffic. Six listed connections could provide several path options. They could also serve different traffic classes, depend on shared transport or change between updates. The public data does not resolve those possibilities.

QuickSoft also appears in RIPE's history of the post-exhaustion address market. A RIPE Labs analysis listed the company with 18 transfers involving 24 blocks and 24,576 addresses in the early dataset studied. That is a historical fact about the analysed transfer records. It is not a current inventory, a measure of revenue or evidence of misconduct.

The historical and current records nevertheless belong in the same diligence conversation. Address transfers can change who holds a resource. Route observations show which ASN appears to originate a prefix at a given time. Exchange records describe asserted interconnection points. None alone establishes the end-to-end chain behind a named customer service.

For a buyer, the useful question is not whether QuickSoft has enough public network objects. It is whether the company can map a contracted service to current origins, upstream or exchange paths, facilities, monitoring boundaries and named escalation owners. The answer should distinguish components QuickSoft operates directly from those supplied by a partner.

A credible recovery claim also needs evidence from outside the registries: incident communications, restoration objectives, failover tests and a clear responsibility matrix. If a route shifts or an exchange session disappears, the buyer should know who detects it, who can reroute, who communicates and which dependencies remain shared.

The public footprint is therefore a starting point, not a verdict. It shows an active autonomous system, a dual-stack route surface and several asserted interconnections. It gives procurement teams precise identifiers to verify. It does not remove the need to verify the service they are actually buying.

Sources

RIPE member record; RIPE organisation object; RIPE AS62222 object; RIPEstat AS overview; RIPEstat announced prefixes; PeeringDB network record; PeeringDB exchange records; RIPE Labs transfer analysis.