Summary

  • Registered responsibility, routing-level control and end-to-end service continuity are separate claims. Evidence at one layer cannot substitute for evidence at the next.
  • Public measurements can identify plausible failure mechanisms and recovery signals, but the current record does not establish a specific outage, operator identity, internal response or physical redundancy for AS210057.

The public record around INFINITYWIFI and AS210057 is easiest to misunderstand when several distinct questions are compressed into one. A registry entry may identify a responsible organisation or maintainer. A route may be authorised and visible from external collectors. A customer may still be unable to authenticate, resolve a name, reach an application or use an access network. Those are related events, but they are not the same evidence claim.

Prior coverage established that the directory entity INFINITYWIFI has not been independently linked to Comcast’s Xfinitywifi service. This investigation asks a narrower operational question: what would public evidence need to show before an observer could responsibly distinguish registered control, routing-level operational control and actual subscriber continuity?

The first plane: registered responsibility

The RIPE NCC RDAP record and aut-num object are the starting points for identifying the registered status of AS210057, linked organisation records, contacts, maintainers, routing-policy declarations and event dates. The current records should be read as a chronology, not as a complete operating chart (RIPE RDAP; RIPE aut-num object).

A maintainer authorised to change a database object has authority over that registry record. That does not, by itself, prove access to production routers, control of BGP sessions, responsibility for customer support or ownership of the physical network. An organisation handle may also differ from a trading name. The corporate-register search is therefore a cross-check for identifiers such as a legal name, company number or address, not a shortcut from name similarity to operational attribution (OpenCorporates search).

This distinction matters for INFINITYWIFI. A directory label can be a useful lead, but it is not a substitute for a durable identity bridge. Until registry identifiers, corporate records and operational evidence converge, the responsible conclusion remains limited: the public record contains an unresolved identity question.

The second plane: routing-level control

Routing evidence can be stronger than a name. Repeated origination of the same prefixes by AS210057, matching route objects, valid Route Origin Authorisations and consistent observed paths would jointly support an inference that someone exercises meaningful control over the routing plane. None of those signals individually identifies the person with privileged access or proves that the control is durable.

The RIPE inverse-origin search can expose route and route6 objects that declare AS210057 as origin. Such objects are useful policy artefacts: their maintainers indicate who is authorised to maintain the declarations, while agreement with RPKI and observed BGP origins strengthens the attribution of address space to the ASN (RIPE route-object search). But IRR objects can be stale, incomplete or absent in one database even when routes are visible elsewhere.

RPKI adds a cryptographic authorisation layer. A valid ROA linking a prefix to AS210057 means that the address-resource holder authorised that ASN to originate the prefix. It is an important preventive control against unauthorised origin announcements. It is not an availability guarantee. A route can be RPKI-valid and still be withdrawn, leaked, misconfigured or unreachable; an invalid route can be rejected selectively by validating networks (RIPE RPKI coverage).

Observed BGP data supplies another layer. RIPEstat can show prefixes, origins and paths visible to RIPE RIS collectors, while neighbour data can reveal ASNs appearing adjacent to AS210057 (RIPE BGP state; RIPE ASN neighbours). BGP aggregation services and CAIDA’s AS-rank view can provide comparison points, but they remain secondary analytical views rather than authoritative proof of a commercial relationship (bgp.tools; CAIDA AS Rank).

A visible neighbour is not automatically a paid transit provider. Several neighbours suggest logical multihoming, but they do not prove independent fibre, facilities, routers, power or wholesale carriers. PeeringDB may add self-reported information about facilities, exchanges, policy and contacts, but its entries are not an authoritative account of legal or physical control (PeeringDB).

The failure mechanisms that can be observed

The relevant continuity risks are not hypothetical abstractions. A complete withdrawal of AS210057’s prefixes, the loss of all functioning external BGP sessions, upstream filtering or an RPKI-invalid announcement can create broad or selective routing loss. Routing history can help establish when prefixes disappeared from RIPE RIS observation and whether origins or paths changed (RIPE routing history). RouteViews provides an independent archive for comparison, reducing the chance that a single collector gap is mistaken for an operator outage (RouteViews archive).

The evidence package does not establish a specific AS210057 outage interval. A short event may be missed or aggregated in a high-level view. A collector can also have its own maintenance or coverage limitation. The correct conclusion is therefore conditional: simultaneous disappearance across independent collectors would be evidence consistent with a routing outage, not conclusive proof of its cause or customer impact.

Why stable BGP is not stable service

The most important boundary is between routing and service. BGP can remain visible while power systems, transport links, DNS, authentication, applications or subscriber access fail. RIPE Atlas can contribute probe-based reachability measurements, and IODA can provide an external signal for network-level disruption, but neither turns route visibility into a complete service-level observation (RIPE Atlas; IODA).

A customer-facing continuity claim requires measurements closer to the user: DNS resolution, authentication success, application reachability, access-network health and restoration time. The present evidence package contains no direct service-endpoint measurements. Nor does it contain an operator-specific incident report, status-page history or postmortem that could substantiate internal alerting, escalation, root cause or repair procedures.

This is why a provider change or restored route should be treated as an external outcome rather than a completed remedy. It shows that visibility changed. It does not reveal who detected the problem, which decision-maker authorised the repair, whether the failure mode was eliminated or whether the same dependency remains.

What durable continuity would require

A credible continuity case would combine several layers over time: persistent visibility after an incident through independent upstream paths; valid and maintained RPKI; accurate IRR objects; repeated observations from multiple BGP collectors; tested failover; and separate service-layer measurements. The requirement is not that every public record be perfect. It is that recovery be observable across independent signals and remain stable after the immediate event.

Physical diversity requires more than counting ASNs. Public topology can suggest logical alternatives, but facility, contract or engineering evidence is needed to establish whether circuits share a building, router, fibre route, power source or wholesale carrier. A network can be multihomed in routing policy while remaining concentrated in one physical or commercial dependency.

The public record also cannot establish the incentive structure behind these controls. It does not show who owns incident command, who approves ROA and IRR changes, who bears customer obligations or who signs off a postmortem. Those are governance questions that require identified parties and primary documentation.

Bounded conclusion

For INFINITYWIFI and AS210057, the evidence supports a disciplined separation of questions rather than a dramatic attribution. Registry records can help identify registered responsibility. IRR and RPKI can show elements of routing authorisation. BGP archives can show external visibility, withdrawal and recovery. Measurement systems can add reachability signals. None of these alone proves the current operator, internal router access, subscriber continuity or physical redundancy.

The next meaningful evidence would be a timestamped, independently reproducible prefix and origin inventory; corroborated observations across at least two BGP archives; current RPKI and IRR records; service-layer measurements; and an authoritative identity bridge linking the relevant registry, corporate and operational actors. Until those records converge, the responsible assessment is not that continuity failed or succeeded, but that its control surface remains only partly observable.

Sources and evidence boundaries

The source records used for this assessment include the RIPE membership directory, MANRS participants directory, Cloudflare Radar routing view, RIPE RIS data, and the announced-prefixes endpoint. These sources were preserved as research artefacts. Current endpoint values and dated AS210057 events were not asserted where live retrieval was unavailable.