Summary

  • RIPE associates Protelecom LLC with one IPv4 /22 allocation, one IPv6 /29 allocation and two autonomous systems, AS60953 and AS61034.
  • In RIPEstat’s bounded view on 5 September 2026, each ASN originated 512 distinct IPv4 addresses, but two ASNs and reciprocal policy declarations do not demonstrate two independent failure domains.

The RIPE NCC member entry places Protelecom LLC in Kyiv and lists Ukraine as its service area. The organisation object identifies ORG-PL187-RIPE as an LIR and records PROTELE-MNT as a maintainer. An inverse organisation search associates that organisation with 185.20.216.0/22, 2a04:1800::/29, AS60953 and AS61034. It also returns a nested 185.20.218.0/23 assignment named TechExpert.

The two aut-num records add an important but limited clue. AS60953 is named PROTEX-AS and AS61034 is named PROTELE-AS. Both link to ORG-PL187-RIPE, and their declared policies include reciprocal acceptance and announcement of ANY. Those lines are registry statements. They do not establish that traffic follows the declared relationship, that failover works, or that the two systems use separate facilities, equipment, power or upstream paths.

RIPEstat’s dated observations show how the address space was presented to its collectors. At 16:00 UTC on 5 September, the AS60953 routing-status view and the AS61034 view each reported two IPv4 prefixes covering 512 distinct addresses. Neither showed an IPv6 announcement, and each was visible to all 327 IPv4 RIS peers listed in the response. That is a bounded visibility result, not a service-level or global-reachability guarantee.

The two-week prefix records expose the division. AS61034 continuously originated 185.20.216.0/24 and 185.20.217.0/24. AS60953 continuously originated 185.20.218.0/23 and the overlapping, more-specific 185.20.218.0/24. The registered /22 therefore appeared through two organisation-linked origins, while one half also carried an aggregate and a more-specific route.

That pattern makes two questions material: who is authorised to change each announcement, and which components are genuinely independent. The public evidence answers neither. It does not show the physical topology, active failover, customer arrangements, traffic, outage history or restoration performance. The defensible conclusion is narrower: counting ASNs is not the same as mapping failure domains.