Summary

  • LACNIC records bind active AS271796, 179.51.204.0/24 and 2803:7fe0::/32 to the exact Fly Internet registrant.
  • RIPEstat observed AS271796 originating two IPv4 /24 routes, while the reviewed routing snapshot showed no IPv6 announcement.
  • All 676 captured BGP paths placed AS64123 immediately before AS271796, a visible handoff that does not establish a commercial contract or exclusive upstream.
  • RPKI validation was valid for 179.51.204.0/24 and unknown for 38.255.0.0/24; unknown is not invalid and is not evidence of a hijack.
  • The public evidence establishes a number-resource and routing boundary, but not Fly Internet's fibre footprint, coverage, capacity, uptime, redundancy or restoration performance.

1. A Local Access Brand With a Verifiable Routing Identity

Fly Internet's public website describes a business built around Internet access. It advertises residential and business service, fibre-to-the-home, fibre-optic connections and wireless delivery in and around Capilla del Senor. That positioning matters because it places the company in the access-provider category rather than the data-centre or colocation frame attached to the original planning row.

Marketing language, however, is only one evidence layer. It tells readers how an operator wants its service understood. It does not independently verify where fibre is installed, which addresses can order a connection, how many customers are active, what speeds are consistently delivered or how the network behaves during a failure. Those questions require other records or direct measurement.

The stronger public anchor is AS271796. LACNIC's registration identifies the autonomous system with COLOMBO ALEJANDRO MAURICIO (FLY INTERNET), matching the exact BTW directory entity. The ASN gives the business a visible control-plane identity: other networks can observe routes that terminate at that origin and compare those routes over time.

That visibility is valuable but bounded. An autonomous system is an administrative routing identity, not a map of ducts, poles, radios, switches or customer premises. The public evidence establishes an Internet edge while leaving physical delivery questions open where the sources do not answer them.

2. The Exact Entity Boundary Comes Before Network Interpretation

Company research becomes unreliable when a trading name is allowed to stand in for an unverified legal or directory identity. Here, the public directory route renders the exact name COLOMBO ALEJANDRO MAURICIO (FLY INTERNET) at its Argentina-specific slug. The corresponding authoritative directory record is a single published company entity. A same-name entry without the country suffix is archived and is excluded from the research boundary.

LACNIC provides an independent identity chain. The AS271796 record uses registrant handle AR-FLIS-LACNIC, and the organization name matches the directory entity. The same record identifies Alejandro Mauricio Colombo as the administrative, technical and abuse contact. Private contact details are unnecessary to the public thesis; the material point is that the registry identity closes on the same named operator.

This exact match prevents several kinds of drift. It avoids attaching a route to another company with a similar brand, treating an archived directory alias as a second active operator or confusing a network-resource holder with a hosting business. It also makes future monitoring reproducible because the entity, ASN and canonical directory path are fixed.

The identity match does not prove every statement on the operator's website. Nor does it establish that every route observed under AS271796 is owned as a registered allocation by the same entity. Identity closure defines the object of research; each resource and operational claim still needs its own evidence.

3. LACNIC Acts as a Ledger for the Autonomous System

The LACNIC RDAP record marks AS271796 as active and dates its registration to 14 September 2020. That record is best understood as a ledger entry: it identifies the holder and the resource, provides operational contacts and preserves a current administrative record. It does not grant the registry a view into every router or commercial arrangement behind the ASN.

This distinction reflects a practical hierarchy. Registry data answers who is recorded as responsible for a number resource. Running routing data answers whether, where and how collectors observe announcements from that resource. Neither layer alone establishes physical ownership, commercial service quality or a complete network topology.

The ASN nevertheless creates accountability. A route originated by AS271796 can be checked against the registered organization, compared with route-origin authorization data and monitored for changes in prefixes or adjacent autonomous systems. If the public routing state later changes, the stable registry identity provides a reference point for asking what changed and who can explain it.

The record should not be overstated as certification. Registration does not verify the operator's coverage, ensure that abuse contacts respond, guarantee route security or demonstrate continuity. Its value is more basic and more durable: uniqueness, recorded responsibility and a common identifier through which other evidence can be connected.

4. One IPv4 Block Is Registered Directly to Fly Internet

LACNIC's RDAP service binds 179.51.204.0/24 to the same Fly Internet registrant handle. A /24 contains 256 IPv4 addresses. The record establishes an active registered allocation and links it to the exact entity already identified through AS271796.

This is the cleanest address-space claim in the source set. The registry holder, the autonomous-system holder and the observed origin align. RIPEstat also sees AS271796 originating the prefix. That three-layer agreement supports a narrow statement: Fly Internet is the registered holder of the block and was visibly originating it during the captured observation period.

The number 256 should not be turned into a customer count or capacity estimate. Public IPv4 addresses can support infrastructure, address translation pools, customer assignments, management systems or other uses. One address can represent many users behind carrier-grade NAT, while some addresses may be reserved or unused. Address count and subscriber count are different measures.

The allocation also says nothing about where traffic enters or leaves the physical network. It does not identify fibre routes, tower locations, points of presence, power dependencies or customer equipment. It is a precise number-resource fact, useful because it is precise, not because it reveals everything around it.

That narrow precision is the right basis for comparison if the registered holder, prefix status or visible origin later changes.

5. A Registered IPv6 Block Is Not the Same as an Announced IPv6 Route

LACNIC separately records 2803:7fe0::/32 as an active IPv6 allocation for the same registrant. The allocation is substantial in address terms, as IPv6 blocks are designed to be, but the important fact is administrative: the resource exists in the registry and is associated with Fly Internet.

The reviewed RIPEstat routing-status response reported no announced IPv6 prefixes for AS271796. The RPKI query for the registered /32 returned unknown. Those observations do not erase the registration. They show that the captured public routing view did not establish an IPv6 announcement from the ASN at that time.

Registration and use can diverge for many legitimate reasons. An operator may reserve an allocation for a later deployment, announce it only through a different arrangement, use more-specific routes not visible in the reviewed response or operate IPv6 internally without originating the aggregate under the queried ASN. The frozen evidence cannot choose among those possibilities.

It would therefore be inaccurate to describe Fly Internet as a publicly visible dual-stack origin based on this source set. It would also be inaccurate to claim that the operator has no IPv6 capability. The defensible statement is narrower: a /32 is registered, while no IPv6 origin announcement was observed in the captured routing status.

6. Two IPv4 Origin Announcements Were Visible

RIPEstat's announced-prefixes response for AS271796 covers the observation interval from 14 to 28 July 2026. It lists two IPv4 /24 routes: the registered 179.51.204.0/24 and 38.255.0.0/24. Together they represent 512 addresses in the public routing view.

The routing-status response adds context. It records first visibility on 24 September 2020 and last visibility on 28 July 2026. It reports two announced IPv4 prefixes, no announced IPv6 prefix and one observed neighbour. All 329 queried IPv4 RIS peers saw the network in that snapshot.

These are control-plane measurements, not traffic measurements. A route can be visible even if no customer traffic is flowing, and a service can be impaired while its BGP announcement remains stable. Conversely, a route can disappear from some collectors without every customer losing service. Visibility is an important operational signal, but it is not a direct availability metric.

The two-prefix footprint is still a useful baseline. Future captures can detect a new prefix, a withdrawal, an origin change, a different immediate neighbour or the appearance of IPv6. The value comes from dated comparability rather than from pretending the snapshot is a complete operational audit.

7. The Second IPv4 Route Has a Different Registry Boundary

The route 38.255.0.0/24 requires more caution than the first /24. A LACNIC RDAP request referred the query to ARIN. The captured ARIN response identifies Cogent's parent allocation 38.0.0.0/8; it does not provide an exact Fly Internet registration for the /24.

RIPEstat nevertheless observed AS271796 as the origin. That establishes a running-code fact: collectors saw the route terminate at Fly Internet's ASN during the captured interval. It does not establish why the address space was available to the operator or what legal and commercial arrangement governs it.

Address space can be delegated, leased, reassigned within a larger allocation or announced under a customer or partner arrangement. The parent record alone cannot distinguish among those possibilities. Calling the /24 “owned by Fly Internet” would therefore exceed the evidence.

The distinction is not pedantic. Registry provenance affects incident response, abuse handling, transfer records and questions about who can authorize or revoke use. For this route, the correct public description is “an observed AS271796 origin announcement.” Any stronger allocation claim needs an exact registration or another authoritative delegation record.

8. Broad Collector Visibility Does Not Equal Customer Uptime

RIPEstat reported that all 329 queried IPv4 RIS peers saw AS271796. This indicates broad propagation across the responding collector set. It supports the view that the two routes were not isolated announcements visible from only a small corner of the Internet.

The denominator matters. RIS peers are measurement vantage points, not Fly Internet customers, access nodes or service locations. Their view describes routing reachability from participating networks. It does not measure whether a household's optical terminal is online, whether a wireless tower has power or whether congestion affects an evening connection.

A route can remain globally visible while a local fibre cut disconnects part of an access network. It can also remain visible when an operator blackholes traffic internally, loses a customer aggregation switch or suffers a domain-name service issue. BGP persistence at the edge cannot see those internal conditions.

The 329-of-329 result should therefore be used as a bounded baseline: the ASN had broadly visible IPv4 announcements at the reviewed time. It must not become a percentage uptime statement, a service-level guarantee or proof of customer availability.

9. The BGP Snapshot Reveals One Consistent Immediate Handoff

The captured BGP-state response contains 676 collector observations across the two IPv4 prefixes. In every one, AS64123 appears immediately before origin AS271796. That consistency makes the adjacency the most prominent topology feature in the public snapshot.

An immediate pre-origin ASN is the last visible autonomous-system hop before the route reaches the origin. It identifies a control-plane handoff. It does not, by itself, label the commercial relationship. AS64123 could represent transit, wholesale access, peering, aggregation or another arrangement not disclosed in BGP.

The observation is also dated. Routing preferences change, sessions fail, new adjacencies appear and collectors select different paths. A later snapshot may show another neighbour without making the earlier capture wrong. Public topology should always be presented with the time boundary attached.

For continuity analysis, the result creates a focused question: what operational arrangements support the AS64123-to-AS271796 handoff, and what happens if that path becomes unavailable? The sources identify the boundary but do not answer the resilience question.

No route collector can answer that question without evidence from the delivery layer behind the ASN boundary.

10. Repeated AS64123 Values Are Not Multiple Independent Upstreams

Some captured AS paths contain repeated values. BGP paths can include prepending, where an autonomous system repeats its own number to influence route selection. Those repetitions should not be counted as separate organizations, circuits or upstream relationships.

Across the observations, the immediate pre-origin identity remains AS64123. The repetition changes path length as represented in the control plane, not the number of independently verified physical connections. Treating each repeated ASN token as a distinct route would exaggerate diversity.

Even distinct AS paths do not automatically prove physical independence. Two sessions can traverse the same building, conduit, power source or transport provider. Conversely, two links between the same ASN pair can be physically diverse while appearing identical in an AS path. Logical and physical diversity must be evaluated separately.

The snapshot is therefore useful for topology-relative monitoring, not for certifying redundancy. It supports a consistent observed handoff and a measurable baseline. It does not reveal circuit count, site count, contractual exclusivity or common failure domains.

11. A Single Visible Neighbour Leaves Several Possibilities Open

RIPEstat's routing status reports one observed neighbour, matching the BGP-state pattern. It is tempting to interpret that as a single-upstream network. The evidence supports “one neighbour was visible,” not “only one upstream exists.”

A backup session may remain dormant, export a route only during failure or be hidden because collectors prefer another path. The operator may also connect to multiple circuits delivered by the same ASN. Public BGP would compress those physically different links into the same immediate autonomous-system sequence.

The opposite possibility also matters: the observed relationship may indeed be highly concentrated. If every external route depends on one commercial and physical path, an incident at that boundary could have wide consequences. The current records cannot calculate that exposure.

The responsible conclusion is an open operational question, not a resilience score. Evidence about contracts, points of presence, interface diversity, transport routes, power and tested failover would be needed before describing the handoff as redundant or fragile.

12. Route-Origin Validation Is Uneven Across the Two IPv4 Routes

RIPEstat's RPKI validation response reports valid for AS271796 originating 179.51.204.0/24. The validating route origin authorization permits the origin and a maximum prefix length of /24. That result aligns the registered block, the observed origin and the security metadata used by route-origin validation.

For 38.255.0.0/24, the same service reports unknown and no validating ROA. The contrast is material because the two routes share an origin ASN but not the same observed authorization state. A monitoring system should keep the results separate rather than assigning one status to the whole network.

RPKI validity is not an endorsement of service quality. A valid route can still suffer leaks, misconfiguration, congestion or physical failure. It says that the tested origin-prefix pair is authorized by the applicable metadata. It does not certify the path, customer experience or internal controls.

The uneven state does create a concrete accountability surface. The registered /24 has a positive authorization signal. The second observed /24 lacks one in the captured validation result. Future checks can determine whether the unknown state changes without turning the present gap into an allegation.

13. Unknown Is Not Invalid

RPKI terminology carries specific meanings. Valid means an applicable authorization permits the observed origin and prefix length. Invalid means an applicable authorization exists but the announcement conflicts with it. Unknown generally means the validator found no applicable authorization for the tested route.

The 38.255.0.0/24 result is unknown, not invalid. It does not show that AS271796 hijacked the route, that the route is universally rejected or that Fly Internet acted negligently. Networks apply their own routing policies, and many accept unknown routes while filtering or de-prioritizing invalid ones.

The result also does not resolve the allocation boundary. The parent ARIN record and the absence of a validating ROA leave the exact delegation relationship outside the frozen evidence. That is a reason to preserve uncertainty, not a licence to fill the gap with suspicion.

The operationally useful statement is modest: the route was visible, its origin was AS271796 and the reviewed validator returned unknown. That combination can be monitored and investigated further if the origin or availability changes.

14. The IPv6 RPKI Query Also Returned Unknown

The RPKI query for 2803:7fe0::/32 returned unknown. In isolation, that means the reviewed validator did not produce a valid authorization result for the registered IPv6 block. The routing-status response simultaneously reported no IPv6 announcement from AS271796.

Those facts describe different layers. The registry establishes the resource holder. The RPKI response describes authorization metadata for a tested origin-prefix pair. The routing snapshot describes what collectors observed. None of the three should be substituted for another.

Because no IPv6 origin was observed, the unknown RPKI result is not evidence of a currently visible unauthorized route. Nor can it establish whether Fly Internet has a planned deployment, an unobserved announcement or no active IPv6 service. The sources stop at the public boundary.

The most useful future signal would be a coordinated change: an IPv6 route appears, collector visibility becomes measurable and an applicable authorization validates the origin. Until then, the registered-but-unseen /32 remains part of the operator's number-resource record rather than proof of delivered dual-stack access.

The absence of that coordinated signal is a monitoring state, not a judgment about the operator's intentions.

15. The Operator's Website Describes Services, Not Measured Delivery

Fly Internet's site uses the language of local access: FTTH, fibre-optic connections, wireless networking, residential plans, business plans and service around Capilla del Senor. Those statements support the classification of the company as an Internet access provider.

They do not supply an independently measured coverage map. A list of plan types does not show which streets are serviceable, where fibre has been lit, how wireless sectors are engineered or whether a particular address receives the advertised performance. Availability can vary within a nominal service area.

The site also promotes symmetric business connectivity. That is an operator-authored offer, not proof of achieved speed under load, committed information rate, latency, packet loss or repair time. The claim belongs in the operator's positioning and cannot be converted into a performance finding.

This separation protects both readers and the operator. Marketing is represented accurately, but the absence of independent measurements is not filled with invented certainty. The public network records then add a different kind of evidence: an identifiable ASN and visible routes, not a customer-experience benchmark.

16. FTTH Does Not Reveal Who Owns the Physical Plant

The phrase fibre-to-the-home describes a delivery architecture, but it does not identify who owns each asset. An operator may own fibre, lease strands, buy wholesale access, share poles, contract civil works or combine fibre backhaul with wireless last-mile delivery.

The frozen sources do not identify ducts, poles, cabinets, splitters, optical line terminals, towers or customer-premises devices. They provide no route maps, site inventories, concession records or supplier contracts. It would be wrong to draw a physical footprint from the ASN and website alone.

Ownership and operational control can also differ. A provider may control provisioning and customer support while depending on another party for transport, repairs or access to passive infrastructure. Those dependencies shape restoration time and service continuity but are not visible in BGP.

For Fly Internet, the evidence supports a public routing edge and an operator-described fibre and wireless offering. The infrastructure behind that offering remains an open research layer. Answering it would require asset records, field evidence, wholesale disclosures or direct operator documentation.

17. The Data-Centre Frame Must Be Rejected

The original planning language suggested data-centre, colocation, server-room or hosted-infrastructure analysis. None of the frozen sources supports that frame. The operator's own site describes Internet access, and the registry and routing data describe number resources and route origination.

An ASN does not imply a data centre. Many local access providers hold autonomous-system numbers so they can originate address space and exchange routes. A visible BGP handoff may terminate in a provider facility, a partner site or another network environment; the public path does not identify a colocation business.

Similarly, the presence of public IPv4 addresses does not prove servers, racks, power systems or cooling operations. Those are separate physical and commercial facts. Claiming them would turn generic Internet infrastructure into a specific facility story without evidence.

The defensible thesis is therefore an access-network accountability story. It asks what the number-resource and routing layers make visible, then identifies the physical delivery, capacity and continuity questions that remain unanswered.

18. BGP Shows the Edge, Not the Internal Network

External routing compresses an operator's internal complexity into an origin. Collectors see AS271796 announce two routes and receive them through an immediate neighbouring ASN. They do not see the internal links that carry traffic from the edge to access equipment and customers.

Inside the network there may be multiple routers, aggregation points, wireless towers, fibre rings, tree topologies or a much simpler design. Internal routing protocols and private addresses can hide that structure. Nothing in the captured BGP state selects one architecture.

Failure domains are hidden as well. Two customer areas may share the same backhaul, power feed or aggregation switch. Alternatively, identical-looking BGP paths may be supported by diverse transport and equipment. The route string cannot distinguish those cases.

This is why control-plane evidence should be described as an edge boundary. It establishes that a resource is globally reachable through a particular visible handoff. It does not describe the internal path that turns that reachability into a working access service.

19. Route Visibility and Traffic Delivery Are Different Measurements

BGP announces that a network can be reached. It does not measure whether packets complete their journey, whether applications respond or whether customers receive acceptable service. Traffic can fail after reaching the origin, and congestion can degrade performance while the route remains stable.

The source set contains no traffic volume, latency, loss, throughput or DNS measurements. It also contains no outage reports or longitudinal service probes. Any statement about actual service quality would need those additional observations and a clearly defined measurement method.

The distinction is especially important for small regional providers. A globally visible route can make the operator look fully exposed to Internet measurement, while the user experience depends on local fibre, radio conditions, power and repair capacity that global collectors cannot see.

For accountability, the routing baseline is still valuable. When a reported service incident occurs, researchers can compare route visibility with customer reports. If BGP remains stable, attention may shift inward. If routes withdraw, the external handoff becomes a stronger lead. The current evidence establishes that baseline without claiming an incident.

The comparison only becomes diagnostic when route timestamps and service reports are aligned carefully.

20. Registry Contacts Are an Operational Surface, Not a Guarantee

The LACNIC records include administrative, technical and abuse contacts tied to the Fly Internet registrant. Contactability is part of number-resource stewardship because other operators and investigators need a responsible party when routes, abuse reports or registry data require attention.

Personal phone, street and email details are not reproduced. Their role in the evidence is to align the legal-person name with the network-resource record and to confirm that the ASN and allocations have designated operational contacts.

A populated contact field does not prove responsiveness. Addresses become stale, responsibilities change and a nominal contact may not control every operational decision. Measuring contact quality would require outreach and a dated record of the response, which is outside this source set.

The ledger nevertheless creates a starting point. If a route-origin anomaly or abuse issue arises, the registered contact can be compared with the operator's current public support channels. Accurate records reduce ambiguity even when they cannot guarantee a timely operational response.

21. The Membership Register Adds Corroboration, Not a New Claim

An official LACNIC electoral-register PDF was captured with the source set. It can corroborate the presence of the member identity in the registry ecosystem, but its text was not extracted locally for this review.

Because no complete textual extraction was available, the PDF carries no unique factual claim here. The exact ASN and address bindings already come from machine-readable RDAP records, which are stronger and easier to reproduce.

This conservative use illustrates an evidence rule: possessing a file is not the same as validating its contents. A source should contribute only what has actually been reviewed and connected to the subject. Unreadable or partially captured material should not be used to decorate a thesis.

The same rule excludes a Cloudflare Radar request that returned HTTP 403. A failed capture cannot support traffic, popularity or routing claims. Authoritative registration and RIPEstat observations establish the bounded network identity without relying on that request.

22. What the Public Evidence Cannot Establish

The source set contains no subscriber count, revenue figure, market-share estimate or customer mix. It does not establish whether residential or business connections dominate. It provides no independent coverage map, installed fibre length, tower count or list of served addresses.

Capacity is equally opaque. Two /24 routes do not reveal access throughput, upstream commit, peak demand, spare headroom or congestion. The number of BGP observations reflects collector paths, not capacity. The public records do not identify equipment models, interface speeds or oversubscription policies.

Continuity remains unmeasured. There is no documented ring topology, backup power, second upstream, restoration target, spare inventory, field-crew arrangement or outage history. A consistent AS64123 handoff can frame those questions but cannot answer them.

These omissions are not evidence of poor performance. They are boundaries on what can be responsibly said. A reality-based profile distinguishes absence of public proof from proof of absence and keeps uncertainty visible rather than filling it with marketing or suspicion.

23. The Most Useful Customer Questions Begin Where BGP Ends

For a customer, the existence of a registered ASN and broadly visible routes is relevant. It shows that Fly Internet has a distinct public routing identity rather than being represented only by a retail website. The valid ROA for one registered /24 adds a positive route-origin authorization signal.

But purchasing decisions depend on details outside the current evidence. Customers may want to know whether their connection uses fibre or wireless, what equipment and power backup serve the area, whether the business plan includes a committed rate and how quickly faults are repaired.

Business customers have additional continuity questions. They may need diverse access paths, a documented escalation process, static addressing, service-level commitments or a fallback service that does not share the same physical dependency. None of those features can be inferred from the ASN.

The evidence therefore gives customers a sharper vocabulary rather than a verdict. They can distinguish registered resources, visible routing, security metadata, physical access and contractual service terms, then ask the operator for proof at the layer that matters to them.

24. A Monitoring Baseline Can Improve Future Accountability

The captured state provides several reproducible markers: AS271796; registered 179.51.204.0/24; registered 2803:7fe0::/32; observed 38.255.0.0/24; immediate neighbour AS64123; one valid IPv4 RPKI result; one unknown IPv4 result; and no observed IPv6 announcement.

Periodic checks can detect meaningful changes. A new neighbour may indicate additional interconnection or a routing rearrangement. A newly visible IPv6 route may show deployment progress. A change from unknown to valid for the second IPv4 route may reflect new authorization metadata.

Change still requires interpretation. A route withdrawal could be planned maintenance, a measurement gap or an outage. A new path could be backup activation, a provider change or collector selection. Registry and operator evidence should be reviewed before assigning cause.

The baseline is useful because it makes those future questions concrete. It turns a generic company description into a set of observable network facts while preserving the difference between what the Internet exposes and what only the operator can document.

That difference is the central accountability boundary for every later update to this profile.

25. Fly Internet's Public Boundary Is Real but Incomplete

Fly Internet is not merely a brand page in this evidence set. The exact directory entity is tied to active AS271796, a directly registered IPv4 /24, a registered IPv6 /32 and two observed IPv4 origin announcements. Those records establish a current network-resource surface.

The routing snapshot adds a consistent AS64123 handoff and broad IPv4 collector visibility. RPKI adds an uneven authorization picture: valid for the directly registered 179.51.204.0/24, unknown for the observed 38.255.0.0/24, and unknown for the registered but unannounced IPv6 block.

None of that reveals the physical operating boundary behind the service. The sources do not establish fibre ownership, wireless coverage, capacity, redundancy, uptime, restoration performance or an exclusive upstream. They also do not support the data-centre frame suggested by the original plan.

The accurate profile is therefore both concrete and restrained. AS271796 makes Fly Internet visible as a routing operator. The public records show where responsibility begins at the Internet edge, while the access network, service commitments and continuity controls behind that edge remain questions for further evidence.

26. Recorded Resources and Observed Routes Must Stay in Separate Columns

The Fly Internet evidence becomes clearer when administrative records and routing observations are treated as two columns rather than blended into one story. The recorded column contains AS271796, 179.51.204.0/24 and 2803:7fe0::/32, all tied by LACNIC to the exact registrant. The observed column contains the routes and paths reported by RIPEstat during a dated interval.

The columns overlap for 179.51.204.0/24: the block is directly registered to Fly Internet and appears with AS271796 as origin. That alignment provides the strongest claim in the evidence set. It still does not reveal internal deployment, but the resource-holder and running-code identities agree.

The columns diverge for 38.255.0.0/24. The route appears in the observed column, while the frozen registry query reaches Cogent's parent allocation rather than an exact Fly Internet record. The divergence does not make the route illegitimate. It means the public evidence does not disclose the delegation instrument that connects the address space to the origin.

They also diverge for IPv6. The /32 exists in the recorded column, but the reviewed routing status contains no IPv6 announcement. Keeping the columns separate avoids two common errors: treating every registered resource as actively routed and treating every visible route as an owned allocation. The method is more useful than a single headline number because it preserves the evidence type behind each claim.

27. Physical Dependency Questions Need Physical Evidence

Network continuity ultimately depends on equipment, transport, sites, power, people and contractual access. None of those elements can be counted from an autonomous-system record. A responsible resilience assessment would need to identify at least the external handoff locations, the paths from those locations into the access network and the shared failure domains along the way.

For a fibre service, useful evidence could include ring or tree design, route diversity between cabinets and upstream handoffs, pole or duct dependencies, spare fibre, optical equipment and field-repair capability. For wireless service, it could include tower locations, backhaul, spectrum arrangements, power backup, sector capacity and weather exposure. The current records disclose none of that.

The same discipline applies to AS64123. Its consistent position before AS271796 shows a control-plane relationship, but it does not locate an interconnection or identify the transport used. One commercial relationship could be delivered over several protected links, while several contracts could still converge on one physical facility. Contract count, ASN count and failure-domain count are not interchangeable.

A future operator disclosure could answer some of these questions without revealing sensitive detail. It might state whether external connectivity is delivered at more than one site, whether access areas have independent backhaul or whether business services have documented restoration targets. Until such evidence exists, these remain questions rather than a defensible resilience grade.

28. Security Metadata and Service Continuity Solve Different Problems

RPKI helps networks evaluate whether an autonomous system is authorized to originate a prefix. That is an important security control, especially when registry records and routing announcements need to be compared at scale. The valid result for 179.51.204.0/24 supplies a positive, machine-verifiable signal for one origin-prefix pair.

Service continuity asks a different set of questions. A perfectly authorized route can still be unavailable because a router fails, a fibre is cut, a site loses power or an upstream path becomes congested. Conversely, an RPKI-unknown route can carry legitimate traffic reliably for years. Authorization state should inform route-security analysis without being turned into an uptime proxy.

This separation also prevents an “all secure” conclusion from the valid route. Fly Internet's second observed IPv4 /24 remains unknown in the captured validation result, and the registered IPv6 block is not observed in routing. The network has several resource states, not one universal RPKI label.

Operational accountability improves when each layer has its own evidence. Registry accuracy identifies the responsible holder. RPKI adds authorization metadata. BGP shows running announcements and visible adjacencies. Traffic probes and operator records would address delivery and recovery. None of these layers should be asked to prove what belongs to another.

29. Better Disclosure Would Make the Public Baseline More Actionable

The current evidence already supports meaningful monitoring, but a small amount of additional disclosure could make it far more useful. An exact record explaining the use of 38.255.0.0/24 would close the address-delegation gap. A published ROA, if operationally appropriate, could change the route-origin validation state from unknown to valid.

IPv6 is another clear disclosure point. Fly Internet could state whether the registered /32 is reserved, under deployment or offered to customers through a routing arrangement not visible under AS271796. Such a statement would not replace measurement, but it would help readers interpret the difference between registration and observed announcements.

Continuity claims would need firmer support. If the operator describes diverse upstreams, protected transport, backup power or repair targets, those claims should identify the layer and scope to which they apply. “Redundant” can mean two router ports, two circuits, two buildings or two independent physical paths; those are not equivalent.

The aim is not to demand publication of sensitive topology. It is to align public claims with evidence that customers and peers can understand. The existing records establish a real network identity and a stable control-plane baseline. Carefully scoped disclosure could connect that edge identity to the delivery and continuity commitments that remain invisible today.

Sources

https://btw.media/en/directory/colombo-alejandro-mauricio-fly-internet-ar https://flyinternet.com.ar/ https://rdap.lacnic.net/rdap/autnum/271796 https://rdap.lacnic.net/rdap/ip/179.51.204.0/24 https://rdap.lacnic.net/rdap/ip/38.255.0.0/24 https://rdap.lacnic.net/rdap/ip/2803:7fe0::/32 https://stat.ripe.net/data/announced-prefixes/data.json?resource=AS271796 https://stat.ripe.net/data/routing-status/data.json?resource=AS271796 https://stat.ripe.net/data/bgp-state/data.json?resource=AS271796 https://stat.ripe.net/data/rpki-validation/data.json?resource=AS271796&prefix=179.51.204.0%2F24 https://stat.ripe.net/data/rpki-validation/data.json?resource=AS271796&prefix=38.255.0.0%2F24 https://stat.ripe.net/data/rpki-validation/data.json?resource=AS271796&prefix=2803:7fe0::%2F32 https://www.lacnic.net/innovaportal/file/7059/1/padron-electoral-comision-electoral-2026.pdf