Summary

  • FIBERNET ARGENTINA S.R.L. is bound to the exact published BTW directory entity and to public network identity AS269912.
  • RIPEstat observed three IPv4 /24 announcements originated by AS269912 during the reviewed 14-28 July 2026 window, but its announced-prefix response did not show an IPv6 route.
  • LACNIC binds 2803:1ce0::/32 to the exact company, while RPKI validation reports valid origin authorization for that IPv6 block and the three reviewed IPv4 routes.
  • ENACOM Resolution 4531/2019 grants an ICT services licence whose wording expressly permits service with or without the licensee's own infrastructure.
  • The public evidence exposes registry, authorization and routing responsibility; it does not prove physical access-network ownership, coverage, capacity, redundancy, uptime or restoration performance.

1. The Useful Question Is Smaller Than the Company Profile

The strongest public evidence about Fibernet Argentina is not a broad description of its business. It is a set of narrow records that identify an operator at specific layers of the Internet. A directory entity names the company. A licence records permission. A regional registry associates number resources with the organization. Route collectors observe announcements. RPKI records origin authorization.

Those layers answer different questions. The directory asks which existing company entity the research concerns. The licence asks what public permission was granted. LACNIC asks who is recorded against an address block. RIPEstat asks what participating collectors received. RPKI asks whether a particular origin and prefix length fit published authorization.

None of those questions is identical to “what network does Fibernet own?” Ownership of ducts, fibre, towers, cabinets, customer-premises equipment and backhaul contracts is a physical and legal matter that the accepted records do not map. An operator can deliver service through owned, leased, shared or wholesale infrastructure while retaining the same ASN and company name.

The same restraint applies to performance. A route can be visible while a local access segment is unavailable. A valid ROA can remain published while a circuit is down. A licence can remain in force without revealing capacity, congestion, staffing or repair arrangements. Public control-plane evidence is valuable precisely because it is observable, but its value depends on respecting its scope.

Fibernet Argentina therefore offers a concrete case in layered accountability. The organization is visible enough to support a factual account of registry identity, authorization and routing. It is not visible enough to support claims about subscriber experience or operational resilience. The difference is the central finding, not a gap to be filled with inference.

2. The Exact Directory Entity Prevents a Name Match From Becoming a Guess

Company names can repeat across databases, historical records and regional suffixes. The relevant BTW directory entity is the exact published company entity fibernet-argentina-s-r-l-ar. A production read-only check resolved that row as the sole PUBLISHED COMPANY entry for the exact name. A same-name row without the regional suffix is archived. That status distinction matters. Research tied to an archived or similarly named row could point readers to the wrong entity even when the prose looks accurate. The directory link anchors the work to the current entity identity before the technical evidence is interpreted. It is a reference boundary rather than an assertion that every external record is automatically the same company.

The precheck also found no existing ArticleEntity link or local research-article claim for the published row. It found no existing title match for the subject. Those zero counts are collision facts, not evidence of uniqueness across the entire public Internet. They show that this exact directory entity had no linked research article in the checked production relationships.

The category and topic are similarly bounded. Regional ISP is the active leaf selected for the company-focused network account. Network-resource evidence is the controlled topic that describes the durable monitoring entity. Neither label proves a service footprint. They organize the published research under the site's existing taxonomy.

Starting with the exact entity keeps the later technical records in proportion. AS269912 is evidence about Fibernet Argentina because the accepted sources connect that number-resource surface to the exact company. The ASN does not replace the company entity, and the company entity does not transform every route seen under the ASN into a physical asset.

3. The Public Directory Route Is a Real Profile, Not a Soft-404 Shell

The public directory route returned HTTP 200, but status alone was not enough. A valid gate also required the exact canonical URL, index-and-follow robots settings, the expected company name, and real profile content. The response contained the directory card, Basic information, and Registry and related records for FIBERNET ARGENTINA S.R.L. A generic “Page not found.” string also appeared in the response. Current-byte review located it in Next.js fallback flight data rather than the rendered company profile.

The page did not contain the candidate-specific “Network profile not found” or “Directory profile not found” message that identifies a soft-404 shell.

That distinction prevents two opposite errors. Treating every HTTP 200 as a pass would allow an empty shell to enter writing and admission. Treating every generic fallback string as a failure would reject valid profiles because modern applications ship route fallbacks in their client data. The meaningful test is the complete current response, not one token.

The route gate is still narrow. It proves that readers can reach the expected directory entity and that the page identifies the company. It does not prove that all business data is current, that every external resource belongs to the entity, or that the route can substitute for independent technical sources.

For this subject, the route gives the network evidence a stable public home. The article can link back to a real company record rather than constructing a new entity from routing data. That preserves the directory as the identity authority and keeps the network records in their proper role as supporting evidence.

4. An ICT Licence Records Permission, Not the Shape of the Access Plant

Argentina's official bulletin identifies ENACOM Resolution 4531/2019 for FIBERNET ARGENTINA S.R.L. The resolution grants a licence for Information and Communications Technology services and records the company in the relevant service register. That is meaningful legal evidence tied to the exact name.

The wording is unusually useful for setting a boundary. It covers fixed or mobile, wired or wireless, national or international services, and says they may be provided with or without the licensee's own infrastructure. The record therefore anticipates more than one delivery model instead of equating licensed service with owned plant.

That qualification blocks a common shortcut. A licence cannot be used to claim that Fibernet owns the fibre, radio sites, poles, ducts, aggregation equipment or long-haul circuits involved in service. It also cannot identify where service is available. The permission is broad; the physical implementation remains unproved.

The record does not publish customer counts, bandwidth, coverage maps, outage history, wholesale suppliers or restoration commitments. It does not say whether a particular route is carried over owned or contracted transport. Those questions require different evidence, such as asset records, agreements, measured service data or direct operator disclosure.

The licence belongs in the account because it proves a formal service permission and an exact legal-name match. Its own text also warns against overreach. Fibernet can be described as a licensed ICT service provider, but the licence cannot be converted into a picture of the network that delivers the service.

5. AS269912 Is a Public Routing Handle, Not a Measure of Company Scale

An autonomous system number identifies a routing-policy domain. In public BGP data, AS269912 appears as the origin for the reviewed Fibernet Argentina routes. That makes it a useful handle for observing announcements, validating origin authorization and comparing path changes over time.

The number says nothing direct about subscriber scale. A small regional provider can operate its own ASN, while a large service business can rely on another operator's routing domain. Counting autonomous systems or prefixes is therefore not a reliable way to infer revenue, customers, market share or geographic reach.

The ASN also does not define the physical boundary of the company. Routing policy can cover addresses transported over leased circuits, shared infrastructure or services bought from other networks.

Conversely, equipment owned by the company may support functions that never appear as a separate public route.

What the ASN does provide is an accountability coordinate. When a route is observed, other networks can identify the declared origin. When an authorization changes, the origin can be compared with the relevant ROA. When a path changes, the terminating ASN remains a reference point for investigation.

That is enough for a substantive research angle. AS269912 places Fibernet Argentina on a visible control surface where registry data and running routing state can be compared. It is not a proxy for the size, quality or ownership structure of the access network beneath that surface.

6. LACNIC's IPv6 Record Establishes a Registered Resource Boundary

LACNIC RDAP binds 2803:1ce0::/32 to registrant handle AR-FASR18-LACNIC and the exact organization name FIBERNET ARGENTINA S.R.L. The range begins at 2803:1ce0:: and extends through the full /32 boundary. The record dates registration and its listed last change to 20 January 2020. The response also assigns administrative, technical and abuse roles to a contact handle. Those roles matter because number resources require a path for coordination. Unexpected routing, harmful traffic or stale registration data often crosses organizational boundaries, and a public role record indicates where another operator should begin.

The existence of the /32 does not show how much of it is used. IPv6 allocation size reflects address architecture and registry policy, not traffic capacity. A registered block can contain active assignments, reserved plans, internal addressing or unused space without the RDAP response distinguishing among them.

The record also does not prove a public IPv6 route. Registration and route visibility are separate layers. A holder may prepare address resources before announcement, withdraw a route, use another routing arrangement, or expose only part of its deployment to public collectors.

LACNIC's role is best understood as recordkeeping. The registry preserves a unique allocation and responsible organization. It does not become the operator of the network, guarantee service, or certify physical ownership. The /32 makes an IPv6 resource boundary visible; it does not make the IPv6 service visible.

7. Three IPv4 Announcements Move the Evidence From Records to Running Code

RIPEstat's announced-prefixes response for AS269912 covers a two-week window from 14 July to 28 July 2026. It lists three IPv4 announcements: 45.190.15.0/24, 187.62.110.0/24, and 187.62.111.0/24. Each timeline spans the reviewed query window.

This is different from an allocation record. Participating collectors were receiving routes originated by AS269912. The network identity was active in the captured routing view rather than existing only as a registry entry. Running announcements provide evidence of configured interdomain routing policy.

Three prefixes do not mean three independent networks. The routes might share routers, transport, power, facilities or an upstream dependency.

More-specific announcements can be used for policy, traffic engineering or administrative separation without corresponding to distinct physical failure domains.

The route count also says nothing about customer location. A /24 can serve infrastructure, customers, address translation, internal services or other purposes not revealed by the announcement. A public collector sees the prefix and path attributes, not the access technology or the endpoints behind it.

The three routes are nonetheless a clear operational fact. They establish a dated baseline against which future changes can be compared. A withdrawal, new prefix or changed origin would be observable. The baseline supports monitoring without turning route visibility into a claim about physical coverage.

8. The Captured Prefix Set Did Not Show IPv6, but Absence Has a Scope

The same announced-prefixes response that listed three IPv4 routes did not list an IPv6 prefix. That creates a visible difference between the registered 2803:1ce0::/32 resource and the collector data captured for AS269912.

The difference is evidence, but it is not a universal negative. RIPEstat reports what its data sources observed for the requested resource and time. It cannot prove that no IPv6 service exists behind another arrangement, that no route was visible elsewhere, or that the operator has never announced the block.

Several explanations could fit the same public snapshot. Deployment may be pending, limited, withdrawn, filtered or carried through a different public identity. The sources do not choose among those explanations. Assigning one would turn a measurement boundary into speculation.

The registered /32 and its valid ROA still matter. They show that the holder has an IPv6 resource and has published origin authorization. Those are prerequisites for one form of public deployment, but prerequisites are not observations of the completed service. The defensible statement is therefore asymmetric. Fibernet Argentina has a registered IPv6 /32 with valid authorization, while the reviewed announced-prefix response showed only three IPv4 routes. This is a monitorable gap between registry preparation and captured routing visibility, not proof of absent IPv6.

9. The BGP-State Capture Exposes a Dominant Visible Neighbour

The captured RIPEstat BGP-state response contains 1,029 observations over the three IPv4 prefixes. Those observations came from 343 unique collector source identifiers. In 1,028 paths, AS263244 appeared immediately before the origin AS269912. One path contained only AS269912.

That distribution supports a precise observation: in this captured public view, AS263244 overwhelmingly occupied the penultimate position before Fibernet's origin.

It does not establish the legal or commercial nature of the relationship. A BGP adjacency pattern is not a contract.

Terms such as upstream, transit, customer or peer require context beyond the path itself. Route-server behavior, policy, aggregation and collector placement can affect how an AS path appears. The response does not disclose prices, commitments, capacity, restoration priority or ownership of the transport.

The dominant pattern also does not prove a single physical dependency. Multiple circuits can share one ASN relationship, while apparently different AS paths can converge on common infrastructure. Public path diversity and physical diversity are related only when additional evidence maps the failure domains.

The value of the capture is comparative. If later observations show a different penultimate ASN, additional paths or broad withdrawals, the change can be dated and investigated. For the current account, AS263244 is a collector-visible neighbour pattern, not an asserted exclusive provider.

10. Collector Counts Describe Observation, Not Universal Reachability

RIPEstat aggregates routes from participating public collectors. The 1,029 BGP-state entries and 343 source identifiers show that the reviewed prefixes were visible across many vantage points. They do not represent every autonomous system, every user or every customer of Fibernet Argentina. Collector feeds are shaped by session policy and location. One source can receive a route that another filters or prefers differently. A path can be present at the control plane while the destination service is unreachable because of problems below the routing edge.

The reverse is also possible. A route absent from a particular collector is not automatically absent from the Internet. Private interconnection, limited export and temporary session conditions can produce partial views. The data is a measurement system with known boundaries, not an omniscient map.

This matters when discussing availability. Persistent route visibility does not establish uptime for customer access. It does not test last-mile links, authentication, DNS, power, congestion or application delivery. A routing baseline is one layer of operational evidence.

The collector count should therefore be read as breadth of observation. It makes route changes easier to detect and compare. It does not turn AS269912 into a globally measured service-level report.

11. RPKI Validity Answers an Authorization Question

RIPEstat reports 45.190.15.0/24 as valid for origin AS269912 under a matching /24 ROA with maximum length 24. The result indicates that the tested origin and route length align with published cryptographic authorization.

For 187.62.110.0/24 and 187.62.111.0/24, validation points to a covering 187.62.110.0/23 ROA. Its origin is AS269912 and its maximum length is 24. The authorization therefore accommodates the two reviewed /24 announcements within that aggregate.

The IPv6 resource 2803:1ce0::/32 also validates for AS269912, with maximum length 48.

That means more-specific routes down to /48 can fit the reviewed authorization. It does not mean that any such route was observed in the announced-prefix response.

RPKI validity narrows one risk: it helps relying networks distinguish an origin that matches published authorization from one that does not. It does not guarantee that the route is available, stable, well engineered or free from other forms of routing error.

Authorization metadata and route observation should be compared rather than collapsed. The IPv4 evidence shows both valid authorization and visible routes. The IPv6 evidence shows valid authorization without a visible route in the captured prefix list. Each combination supports a different, bounded conclusion.

12. Security Metadata Does Not Prove Resilience

A valid ROA is useful security metadata, but resilience depends on more than origin authorization. Power, transport, equipment, software, staffing, spare capacity and restoration authority all affect whether service continues during a failure. RPKI does not reveal those systems. It does not show whether two links share a conduit, whether edge routers share a power feed, or whether the same upstream path carries every prefix. It cannot measure congestion, packet loss, latency or repair time.

The BGP paths add visibility but not the missing physical map. Even if multiple paths were observed, they could converge on one cable or facility. Even if one path dominates, hidden backup arrangements could exist. Public control-plane data is not a substitute for failure-domain evidence.

The licence is equally limited. Permission to provide service does not disclose operational design. Its express allowance for service without the licensee's own infrastructure makes any inference about owned redundancy especially unsafe.

The accepted sources support a routing-security account: Fibernet's tested resources have valid origin authorization, and three IPv4 announcements are visible. They do not support a resilience rating. That conclusion must remain open until physical and operational evidence exists.

13. Number Resources Are Records of Responsibility

Internet number resources need uniqueness. Two networks cannot safely originate the same address space without routing consequences, and an ASN needs a stable identity if other operators are to interpret its announcements. Registry records provide the ledger that coordinates those assignments.

Accuracy matters because operations cross company boundaries. When an unexpected origin appears, a network operator needs to identify the recorded holder. When abuse is reported, contacts need to point toward an accountable organization. When resources transfer or operational responsibility changes, the record needs to follow.

The ledger is not sovereign. It does not own the company's routers or determine every route. It records allocation and responsibility within a shared coordination system. Running code in BGP supplies a separate view of what networks are actually announcing.

Fibernet Argentina illustrates why the layers should be checked together. The exact company appears in the IPv6 RDAP record. AS269912 appears in the route data. RPKI aligns the tested resources with that origin. The official licence supplies a separate legal permission layer.

The result is stronger than a generic company profile because each statement attaches to a defined control surface. It is also narrower. Registry responsibility does not expand into physical ownership, and routing visibility does not expand into service quality.

14. Contact Roles Support Coordination Without Promising Response

The LACNIC IPv6 record lists administrative, technical and abuse roles through a contact handle. These roles define expected channels for questions about registration, routing and harmful traffic. They are part of the operational value of accurate number-resource data.

Public contact records should not be mistaken for a full incident process. They do not reveal on-call schedules, staffing, escalation authority or response targets. A listed role can be accurate while a particular message still requires internal routing.

Nor should personal details be reproduced unnecessarily. The publishable point is that the registry associates coordination roles with the resource. Individual telephone numbers, addresses and email details add little to the network-accountability thesis and can become stale.

Contact accuracy becomes important when the technical evidence is ambiguous. A changed path may be planned maintenance, a provider transition or an incident. Public collectors cannot explain intent. A responsible organization must be reachable to add context.

The record therefore supports continuity at the coordination layer. It does not prove performance during an outage. The distinction keeps a useful operational fact without turning a directory entry into a service-level promise.

15. The Licence and the ASN Describe Different Boundaries

ENACOM's licence concerns permission to provide ICT services. AS269912 concerns public routing policy. The two records overlap at the company name but do not describe the same thing.

The licence can remain stable while routing changes. The company could add, withdraw or renumber prefixes without changing the permission itself. It could alter suppliers or transport arrangements while retaining both its licence and ASN.

The ASN can also remain stable while the service model changes. A network may move between owned and contracted infrastructure, add wholesale access or reorganize customer delivery. Public BGP would not disclose every commercial or physical change.

Keeping the records separate prevents a circular inference. The licence does not prove that the ASN carries every licensed service. The ASN does not prove that every route corresponds to a licensed retail product. Each source supports only its own layer.

Their combination is still informative. Fibernet Argentina is not merely a name in a route table or a name in a legal register. The same exact company appears across service permission, number-resource and routing evidence. The combined identity is strong even though the delivery boundary remains unresolved.

16. Public Paths Cannot Identify the Last Mile

BGP paths describe autonomous systems, not street-level access. The path ending at AS269912 does not reveal whether a customer connects by fibre, fixed wireless, leased line, another carrier's access network or a mixture of technologies.

The official licence deliberately leaves those possibilities open. Wired and wireless services, with or without owned infrastructure, fit its wording. No accepted source narrows the actual implementation for a specific location or customer group.

This is why a coverage map would be inappropriate. A route can be originated from infrastructure that serves multiple areas, or address space can support services unrelated to a residential footprint. Prefix geography is not a reliable substitute for access geography.

The generated image follows the same boundary. It is a generic editorial illustration of registry, authorization, routing and handoff layers. It does not show a Fibernet facility, real fibre route, tower, coverage area or customer installation.

The last mile remains an evidence gap, not a blank canvas. The public material can support questions for the operator, but it cannot answer them. Any future claim about access technology or footprint needs a source that speaks directly to that physical layer.

17. A Route Snapshot Is a Baseline, Not an Uptime Record

The three IPv4 routes were present throughout the timelines returned for the reviewed two-week query. That continuity is a property of the captured route dataset. It is not a measured uptime percentage for the service.

Route presence and user experience can diverge. Customer access can fail while prefixes remain announced. An origin can withdraw briefly between sampling points. DNS, power, authentication or local transport problems can affect service without changing the public route.

The response also cannot establish restoration performance. It does not show ticket timestamps, field dispatch, spare equipment, escalation decisions or contractual targets. Those are the records needed to judge how an operator responds to failure.

What the timeline provides is a reproducible reference. Later captures can be compared with the three-prefix set and the observed path pattern. A change can be identified before its cause is known.

Monitoring is useful when it avoids premature explanation. The baseline lets researchers say what changed and when it was visible. It does not let them declare an outage, resilience or service quality without corroborating evidence.

18. The Most Important Uncertainty Is the Delivery Boundary

The accepted sources are unusually clear about control-plane responsibility. They identify the company, the ASN, the registered IPv6 resource, three IPv4 announcements and valid RPKI authorization. They also identify a public service licence.

The sources are not clear about delivery. They do not name the physical assets that connect end users, the parties that own those assets, or the contracts that move traffic beyond the origin. They do not reveal whether dependencies share a site, route or power source.

That uncertainty affects every resilience claim. Without a map of failure domains, route count cannot become redundancy. Without measured service data, collector visibility cannot become uptime. Without restoration records, contact roles cannot become recovery performance.

The uncertainty does not make the public records weak. It defines the questions they can answer. Registry and routing data are strong evidence of network identity and origin responsibility. They are weak evidence of access ownership and service experience.

Fibernet Argentina's public profile is therefore best understood as a visible control surface with an opaque delivery surface. That formulation preserves what can be verified and makes the remaining evidence gap explicit.

19. Future Changes Can Be Tested Against the Frozen Baseline

The current source set freezes a dated baseline rather than claiming permanence. It records three IPv4 announcements, a dominant collector-visible penultimate ASN, a registered IPv6 /32 and four valid RPKI tests.

If AS269912 later announces IPv6, the new route can be checked against the registered block and maximum-length authorization. If a new IPv4 prefix appears, its origin and ROA status can be compared with the current set.

Path changes can also be tracked. A different penultimate ASN might reflect a supplier change, new interconnection, policy adjustment or temporary condition. Public data can establish the change, but additional evidence would still be needed to explain the commercial relationship.

Registry changes deserve similar care. A new contact or modified resource record may improve accuracy, reflect an organizational change or correct an error. The ledger records the update; it does not explain every operational consequence.

The baseline turns the subject into a monitorable network identity. It makes future claims testable against exact resources and dates. That is more useful than a static description of the company because it preserves both evidence and uncertainty.

20. Prefix Length Is an Operational Detail, Not Decorative Notation

The difference between a /23, /24, /32 and /48 is not typographic decoration. Prefix length defines the size of the address block being described and, in RPKI, helps determine whether an announcement fits the published authorization. A claim that ignores length can turn a valid aggregate statement into an incorrect conclusion about a more-specific route.

For 45.190.15.0/24, the reviewed validation response is straightforward. The validating ROA names AS269912, covers the same /24 and allows a maximum length of 24. The route being tested therefore matches both the origin and the permitted length in that response.

The two routes inside 187.62.110.0/23 illustrate aggregation. The ROA covers the /23 but permits announcements down to /24. That maximum-length setting allows the reviewed 187.62.110.0/24 and 187.62.111.0/24 routes to validate for AS269912 without requiring a separate ROA record for each /24.

The IPv6 record has a different shape. 2803:1ce0::/32 validates for AS269912 with maximum length 48. The authorization can accommodate more-specific routes within that range, but the captured announced-prefix response did not show one. Authorization and observation remain separate even when the cryptographic record is valid.

This detail matters to operational continuity because incorrect origin or length settings can change how networks applying route-origin validation treat an announcement. It still does not predict whether a route will be reachable, how traffic will perform, or what physical infrastructure carries it. RPKI constrains a routing-security question; it does not certify the service.

Accurate prefix language also protects readers from inflated claims. Saying that the tested routes are valid is supported. Saying that every route Fibernet might announce is authorized would exceed the evidence. The validation results apply to the exact resource, origin and maximum-length combinations reviewed in the frozen source set.

21. The Public Evidence Cannot Resolve Shared Failure Domains

Resilience analysis depends on shared failure domains. Two links that enter a building through one conduit are not fully independent. Two routers connected to one power system can fail together. Separate commercial suppliers can rely on common transport, a common facility or the same upstream parent.

The route observations do not expose those dependencies. The strong AS263244 penultimate pattern is visible, but it does not identify circuits, ducts, sites, power feeds or maintenance authority. Even a second visible autonomous-system path would not establish physical separation without a map connecting the logical and physical layers.

The licence record cannot fill that gap. Its explicit with-or-without-own-infrastructure wording permits arrangements in which service depends on other parties' assets. It does not identify those parties, allocate restoration responsibilities or say which components are shared.

The IPv4 prefix set also cannot stand in for diversity. Three /24s could be announced from one edge. They could share the same transport and disappear together. Alternatively, one public origin could sit behind internal designs that are more diverse than the collector view reveals. Both possibilities fit the accepted evidence.

Operational continuity includes people and permissions as well as equipment. A repair may require access to a site, authority to change routing, replacement hardware, coordination with another carrier and accurate contact data. Public registry roles support coordination but do not show whether those resources are available during an incident.

Evidence strong enough to assess resilience would need to identify independent sites, transport paths, upstream relationships, power arrangements and tested failover behavior. It would also need dated performance or incident records. None of those materials is present here, so no resilience grade is warranted.

This is not an argument that the network lacks resilience. It is a finding that the public control surfaces reviewed here cannot measure it. Keeping that distinction explicit prevents a technically detailed route account from becoming a false assurance about customer continuity.

22. Better Evidence Would Narrow the Delivery Boundary

Several kinds of future evidence could close parts of the current uncertainty without changing the network-identity baseline. A first-party technical statement could identify access technologies, service areas or interconnection policy. It would need to be dated and tied to the exact company rather than a similar brand.

Public PeeringDB data, if an exact current record were established, could add self-reported interconnection context. It would still require clear labelling as voluntary operator data. An exchange listing could show a declared presence or interface, but not a live port, measured traffic, physical diversity or contract.

Time-series routing data could show whether the three IPv4 prefixes remain stable, whether additional origins appear, or whether IPv6 becomes publicly visible. Such changes would strengthen the running-code account. They would not identify the access plant unless paired with physical or contractual evidence.

RPKI changes could also be monitored. A modified maximum length, new ROA or invalid observation would be operationally relevant. The event would need a precise timestamp and exact resource binding. It should not be explained as an incident without corroboration from the operator or other measurements.

For the physical network, asset and facility records would be more probative. Verified route maps, site disclosures, regulatory filings, procurement records or direct operator documentation could establish ownership and location. Even then, capacity and resilience claims would require evidence that the components are active and independent.

Service-quality conclusions need measurement. Latency, loss, congestion, outage and restoration data must be tied to defined endpoints and periods. Marketing claims, route presence and address counts cannot substitute for those measurements.

Until such material exists, the frozen baseline remains useful. It identifies the exact entity and number-resource surface, records what public collectors saw, and names the limits. Future evidence can be added to that structure without rewriting uncertainty as fact.

23. What the Public Record Supports

FIBERNET ARGENTINA S.R.L. is the exact published directory company associated with this research. An official Argentine record grants it an ICT services licence. LACNIC binds an IPv6 /32 to the exact company, and public routing data associates AS269912 with three visible IPv4 announcements.

The reviewed IPv4 routes and registered IPv6 block have valid RPKI authorization for origin AS269912 under the tested prefix-length conditions. The route-state capture also shows a strong collector-visible pattern in which AS263244 appears immediately before the origin.

Those findings establish a credible network identity. They show that number-resource records, authorization metadata and running routing state can be compared. They do not establish a complete topology or the physical systems behind customer service.

The most important legal text reinforces that limit. The licence permits service with or without the licensee's own infrastructure. Public permission and public routing responsibility therefore cannot be used as proof that Fibernet owns the access plant.

The final conclusion is deliberately bounded. AS269912 makes Fibernet Argentina visible at the registry, authorization and routing layers. The access network, IPv6 deployment, capacity, redundancy, uptime and restoration performance remain unproved. That is not a weakness in the account; it is the reality layer the evidence supports.

Sources