Zusammenfassung

  • LACNIC-Datensätze ordnen das aktive AS271796,179.51.204.0/24und2803:7fe0::/32dem exakten Fly Internet-Registranten zu.
  • RIPEstat beobachtete, dass AS271796 zwei IPv4-/24-Routen als Ursprung signalisierte, während der geprüfte Routing-Snapshot keine IPv6-Ankündigung zeigte.
  • Alle 676 erfassten BGP-Pfade setzten AS64123 unmittelbar vor AS271796, eine sichtbare Übergabe, die keinen kommerziellen Vertrag oder ein exklusives Upstream-Verhältnis belegt.
  • Die RPKI-Validierung war für179.51.204.0/24validund für38.255.0.0/24unknown; unknown ist nicht invalid und kein Hinweis auf einen Routen-Hijack.
  • Der öffentliche Nachweis setzt eine Grenze für Number-Resource und Routing, aber nicht für Fly Internets Glasfaser-Footprint, Abdeckung, Kapazität, Verfügbarkeit, Redundanz oder Wiederherstellungsleistung.

1. Eine lokale Zugangsmarke mit überprüfbarer Routing-Identität

Die öffentliche Website von Fly Internet beschreibt ein Geschäftsmodell rund um Internetzugang. Sie wirbt mit privaten und geschäftlichen Tarifen, Fiber-to-the-Home, Glasfaserverbindungen und Wireless-Angeboten in und um Capilla del Senor. Diese Positionierung ist relevant, weil sie das Unternehmen in die Kategorie Access-Provider statt in den ursprünglichen Planungsrahmen für Rechenzentrum/Colocation einordnet.

Marketing-Sprache ist jedoch nur eine Evidenzebene. Sie zeigt, wie ein Betreiber von seinem Service verstanden werden möchte. Sie bestätigt jedoch nicht eigenständig, wo Glasfaser verlegt ist, welche Adressen einen Anschluss bestellen können, wie viele Kunden aktiv sind, welche Geschwindigkeiten konsistent geliefert werden oder wie das Netz bei einem Ausfall reagiert. Diese Fragen erfordern andere Datenquellen oder direkte Messungen.

Der stärkste öffentliche Anker ist AS271796. Die LACNIC-Registrierung identifiziert das autonome System mit COLOMBO ALEJANDRO MAURICIO (FLY INTERNET), passend zum exakten BTW-Verzeichniseintrag. Die ASN gibt dem Unternehmen eine sichtbare Control-Plane-Identität: Andere Netze können Routen beobachten, die bei diesem Ursprung enden, und diese Routen über die Zeit vergleichen.

Diese Sichtbarkeit ist wertvoll, aber begrenzt. Ein autonomes System ist eine administrative Routing-Identität, kein Kartenbild von Schächten, Masten, Switches oder Kundenanschlüssen. Der öffentliche Nachweis stellt eine Internet-Kante her und lässt physische Bereitstellungsfragen offen, wenn die Quellen diese nicht beantworten.

2. Die exakte Entitätsgrenze kommt vor der Netzinterpretation

Unternehmensrecherche wird unzuverlässig, wenn ein Handelsname für eine nicht verifizierte rechtliche oder Verzeichnis-Identität steht. Hier zeigt die öffentliche Verzeichniseintragung den exakten Namen COLOMBO ALEJANDRO MAURICIO (FLY INTERNET) auf dem argentinenspezifischen Slug. Der zugehörige verbindliche Verzeichniseintrag ist ein einziger veröffentlichter Unternehmenseintrag. Ein gleichnamiger Eintrag ohne Ländersuffix ist archiviert und nicht Teil der Untersuchungsgrenze.

LACNIC liefert eine unabhängige Identitätskette. Der AS271796-Datensatz nutzt den Registranten-HandleAR-FLIS-LACNIC, und der Organisationsname passt zur Verzeichnis-Entität. Derselbe Datensatz benennt Alejandro Mauricio Colombo als administrativen, technischen und Abuse-Kontakt. Personalisierte Kontaktdaten sind für die öffentliche These unnötig; der Materialpunkt ist, dass die Registry-Identität auf denselben benannten Operator schließen lässt.

Diese exakte Übereinstimmung verhindert mehrere Drift-Arten. Sie verhindert, eine Route einem anderen Unternehmen mit ähnlicher Marke zuzuordnen, ein archiviertes Verzeichnis-Alias als zweiten aktiven Betreiber zu behandeln oder einen Inhaber von Netzwerkressourcen mit einem Hosting-Geschäft zu verwechseln. Sie macht künftiges Monitoring reproduzierbar, weil Entität, ASN und kanonischer Verzeichnispfad fest sind.

Die Identitätsübereinstimmung beweist nicht jede Aussage auf der Betreiber-Website. Sie beweist auch nicht, dass jede unter AS271796 beobachtete Route als registrierte Zuteilung desselben Unternehmens geführt ist. Die Identitätsgleichheit definiert das Untersuchungsobjekt; jede Ressource und jede operative Behauptung benötigt weiterhin ihren eigenen Nachweis.

3. LACNIC wirkt als Register für das autonome System

Der LACNIC-RDAP-Datensatz markiert AS271796 als aktiv und datiert die Registrierung auf den 14. September 2020. Dieser Datensatz ist als Registereintrag zu lesen: Er identifiziert Inhaber und Ressource, liefert operative Kontakte und bewahrt einen aktuellen Verwaltungsdatensatz. Er gibt der Registry keine Einblicke in jeden Router oder jedes kommerzielle Arrangement hinter dem ASN.

Diese Unterscheidung spiegelt eine praktische Hierarchie wider. Registry-Daten beantworten, wer als Verantwortlicher für eine Nummernressource geführt wird. Laufzeitdaten beantworten, ob, wo und wie Messstellen Ankündigungen dieser Ressource beobachten. Keine dieser Ebenen allein belegt physische Eigentümerschaft, kommerzielle Servicequalität oder ein vollständiges Netzwerk-Topology-Bild.

Das ASN schafft trotzdem Rechenschaft. Eine von AS271796 ausgehende Route kann mit der registrierten Organisation abgeglichen, mit Daten zur Herkunftsautorisierung verglichen und auf Änderungen von Präfixen oder angrenzenden autonomen Systemen überwacht werden. Ändert sich der öffentliche Routing-Zustand später, bietet die stabile Registry-Identität einen Referenzpunkt dafür, was sich geändert hat und wer es erklären kann.

Der Datensatz sollte nicht überhöht als Zertifizierung dargestellt werden. Die Registrierung garantiert nicht die Abdeckung des Betreibers, stellt nicht sicher, dass Abuse-Kontakte reagieren, garantiert keine Routensicherheit und belegt keine Kontinuität. Sein Wert ist einfacher und robuster: Eindeutigkeit, dokumentierte Verantwortung und ein gemeinsamer Identifikator, über den weitere Belege gekoppelt werden können.

4. Ein IPv4-Block ist direkt auf Fly Internet registriert

Der LACNIC-RDAP-Dienst ordnet179.51.204.0/24demselben Fly Internet-Registrierungs-Handle zu. Ein/24umfasst 256 IPv4-Adressen. Der Datensatz stellt eine aktive registrierte Zuteilung fest und verbindet sie mit derselben Entität, die bereits über AS271796 identifiziert wurde.

Das ist die sauberste Adressraum-Aussage im Quellsatz. Der Registryinhaber, der AS-Inhaber und der beobachtete Ursprung decken sich. RIPEstat sieht AS271796 ebenfalls als Ursprung des Präfixes. Diese Dreifach-Übereinstimmung stützt eine enge Aussage: Fly Internet ist registrierter Inhaber des Blocks und hat ihn im erfassten Beobachtungszeitraum sichtbar als Ursprung angekündigt.

Die 256 darf man nicht in eine Kundenzahl oder Kapazität umrechnen. Öffentliche IPv4-Adressen können Infrastruktur, NAT-Pools, Kundenzuweisungen, Managementsysteme oder andere Nutzungen tragen. Eine Adresse kann viele Nutzer hinter Carrier-Grade-NAT repräsentieren, während manche Adressen reserviert oder ungenutzt bleiben. Adressanzahl und Subscriberanzahl sind unterschiedliche Maße.

Die Zuteilung sagt nichts darüber aus, wo Daten in das physische Netz ein- oder ausfliessen. Sie identifiziert weder Glasfaserwege, Mastenstandorte, Points of Presence, Stromabhängigkeiten oder Kundengeräte. Es ist ein präziser Nummernressourcen-Fakt, weil er präzise ist, nicht weil er alles offenlegt.

Diese enge Präzision ist die richtige Basis für Vergleiche, falls registrierter Inhaber, Präfixstatus oder sichtbarer Ursprung später ändern.

5. Ein registrierter IPv6-Block ist nicht das Gleiche wie eine angekündigte IPv6-Route

LACNIC führt2803:7fe0::/32separat als aktive IPv6-Zuteilung für denselben Registranten. Die Zuteilung ist adressseitig groß, wie bei IPv6-Räumen üblich, aber die zentrale Tatsache ist administrativ: Die Ressource existiert in der Registry und ist Fly Internet zugeordnet.

Der geprüfte RIPEstat-Routing-Status-Response meldete keine angekündigten IPv6-Präfixe für AS271796. Die RPKI-Abfrage für das registrierte/32ergabunknown. Diese Beobachtungen heben die Registrierung nicht auf. Sie zeigen nur, dass der öffentliche Routing-Blick im relevanten Zeitraum keine IPv6-Announcement aus dem ASN feststellte.

Registrierung und Nutzung können aus vielen legitimen Gründen auseinanderlaufen. Ein Betreiber kann eine Zuteilung für später reservieren, sie nur über ein anderes Arrangement annoncieren, granularere Routen ausgeben, die im geprüften Response nicht sichtbar sind, oder IPv6 intern nutzen, ohne das Aggregat unter dem abgefragten ASN zu originieren. Die eingefrorenen Daten können diese Möglichkeiten nicht unterscheiden.

Es wäre daher falsch, Fly Internet auf Basis dieses Quellenpakets als öffentlich sichtbaren Dual-Stack-Origin zu bezeichnen. Ebenso falsch wäre es, zu behaupten, der Betreiber habe keinerlei IPv6-Fähigkeit. Die belastbare Aussage ist enger: Ein/32ist registriert, während im erfassten Routingzustand keine IPv6-Origin-Ankündigung beobachtet wurde.

6. Zwei IPv4-Origin-Ankündigungen waren sichtbar

RIPEstats Announcement-Prefixes-Response für AS271796 umfasst das Beobachtungsintervall vom 14. bis 28. Juli 2026. Es listet zwei IPv4-/24-Routen: den registrierten179.51.204.0/24und38.255.0.0/24. Zusammen ergeben sie 512 Adressen im öffentlichen Routingbild.

Die Routing-Status-Antwort ergänzt das Bild. Sie vermerkt erste Sichtbarkeit am 24. September 2020 und letzte Sichtbarkeit am 28. Juli 2026. Sie meldet zwei angekündigte IPv4-Präfixe, kein angekündigtes IPv6-Präfix und einen beobachteten Nachbarn. In diesem Snapshot sahen alle 329 abgefragten IPv4-RIS-Peers das Netzwerk.

Das sind Kontrollplanes-Messungen, keine Verkehrs-Messungen. Eine Route kann sichtbar bleiben, auch wenn kein Kundenverkehr fließt, und ein Service kann gestört sein, obwohl die BGP-Ankündigung stabil bleibt. Umgekehrt kann eine Route bei einigen Beobachtern verschwinden, ohne dass jeder Kunde den Dienst verliert. Sichtbarkeit ist ein wichtiges operatives Signal, aber keine direkte Verfügbarkeitsmetrik.

Der Zweier-Fußabdruck bleibt dennoch eine nützliche Baseline. Künftige Erhebungen können einen neuen Präfix, einen Withdraw, eine Ursprungsänderung, einen anderen direkten Nachbarn oder die Sichtbarkeit von IPv6 erkennen. Der Wert liegt in der datierten Vergleichbarkeit statt in der Behauptung, der Snapshot sei ein vollständiges Betriebs-Audit.

7. Die zweite IPv4-Route hat eine andere Registry-Grenze

Die Route38.255.0.0/24erfordert mehr Sorgfalt als die erste/24. Eine LACNIC-RDAP-Anfrage leitete die Recherche an ARIN weiter. Die erfasste ARIN-Antwort benennt Cogens Parent-Allocation38.0.0.0/8; sie liefert keinen exakten Fly Internet-Eintrag für diese/24.

RIPEstat beobachtete dennoch AS271796 als Ursprung. Das stellt einen laufenden Fakt fest: Beobachter sahen die Route mit Ursprung AS271796 im erfassten Intervall. Es belegt nicht, warum der Adressraum dem Betreiber zur Verfügung stand oder welches rechtliche und kommerzielle Arrangement dies regelt.

Adressraum kann delegiert, gemietet, innerhalb einer größeren Zuteilung neu zugewiesen oder im Rahmen eines Kunden- oder Partner-Arrangements angekündigt werden. Der Parent-Datensatz allein kann diese Möglichkeiten nicht trennen. Die Bezeichnung der/24als „Fly Internet gehört“ wäre daher eine Evidenzüberschreitung.

Der Unterschied ist nicht pedantisch. Registry-Herkunft beeinflusst Incident Response, Abuse-Behandlung, Transfernachweise und die Frage, wer Nutzung autorisieren oder entziehen kann. Für diese Route lautet die korrekte öffentliche Beschreibung: „eine beobachtete AS271796-Origin-Ankündigung“. Jede stärkere Aussage zu Zuweisung braucht eine exakte Registrierung oder einen anderen autoritativen Delegationsnachweis.

8. Breite Collector-Sichtbarkeit ist nicht gleich Kundenausfallszeit

RIPEstat meldete, dass alle 329 abgefragten IPv4-RIS-Peers AS271796 gesehen haben. Das zeigt breite Verbreitung über das respondierende Beobachterset. Es unterstützt die Annahme, dass die zwei Routen keine isolierten Ankündigungen aus nur einem kleinen Teil des Internets waren.

Der Nenner ist entscheidend. RIS-Peers sind Messvantage-Punkte, nicht Kunden von Fly Internet, kein Access-Node und kein Servicestandort. Ihre Sicht beschreibt Routing-Erreichbarkeit aus teilnehmenden Netzen. Sie misst nicht, ob ein Haushaltsendgerät online ist, ob ein Funkmast Strom erhält oder ob Stau lokale Verbindungen beeinträchtigt.

Eine Route kann global sichtbar bleiben, während ein lokaler Glasfaserausfall Teile eines Access-Netzes trennt. Sie kann auch sichtbar bleiben, wenn der Betreiber intern Verkehr blackholet, eine Kundenaggregationsschalte versagt oder ein DNS-Probleme auftreten. BGP-Beständigkeit an der Kante erfasst diese internen Bedingungen nicht.

Das Ergebnis 329 von 329 sollte deshalb als begrenzte Baseline verwendet werden: AS271796 hatte im erfassten Zeitraum breit sichtbare IPv4-Ankündigungen. Es darf nicht zu prozentualer Verfügbarkeitsaussage, SLA-Versprechen oder Nachweis von Endkundenerreichbarkeit werden.

9. Der BGP-Snapshot zeigt eine konsistente unmittelbare Übergabe

Die erfasste BGP-State-Antwort enthält 676 Collector-Beobachtungen für die beiden IPv4-Präfixe. In jeder steht AS64123 unmittelbar vor Ursprung AS271796. Diese Konsistenz macht die Adjazenz zum prominentesten Topologie-Merkmal im öffentlichen Snapshot.

Eine unmittelbare Vorlauf-AS-Nummer ist der letzte sichtbare AS-Hop vor dem Ursprung. Sie bezeichnet eine Control-Plane-Handover-Stelle. Sie bezeichnet nicht automatisch die kommerzielle Beziehung. AS64123 kann Transit, Wholesale-Access, Peering oder eine andere nicht veröffentlichte Struktur sein.

Die Beobachtung ist zudem zeitlich begrenzt. Routing-Präferenzen ändern sich, Sitzungen fallen aus, neue Adjazenzbeziehungen entstehen und Collectoren wählen unterschiedliche Pfade. Ein späterer Snapshot kann einen anderen Nachbarn zeigen, ohne den früheren Befund zu widerlegen. Öffentliche Topologie sollte immer mit der Zeitgrenze dargestellt werden.

Für die Kontinuitätsanalyse ergibt sich eine fokussierte Frage: Welche operativen Absprachen stützen die AS64123-to-AS271796-Übergabe, und was passiert, wenn dieser Pfad nicht mehr verfügbar ist? Die Quellen markieren die Grenze, beantworten aber nicht die Ausfallsituation.

Keine Route-Collector kann diese Frage ohne Belege aus der Bereitstellung hinter der ASN-Grenze beantworten.

10. Wiederholte AS64123-Werte sind keine mehreren unabhängigen Upstreams

Einige erfasste AS-Pfade enthalten wiederholte Werte. BGP-Pfade können Prepending enthalten, bei dem eine autonome Systemnummer wiederholt wird, um die Pfadauswahl zu beeinflussen. Diese Wiederholungen sollten nicht als separate Organisationen, Leitungen oder Upstream-Beziehungen gezählt werden.

In den Beobachtungen bleibt die unmittelbare Vor-Origint-Identität AS64123. Die Wiederholung ändert die Pfadlänge in der Control Plane, nicht die Zahl unabhängig verifizierter physischer Verbindungen. Jede wiederholte ASN-Position als separater Pfad zu behandeln, würde die Vielfalt verzerren.

Auch unterschiedliche AS-Pfade beweisen keine physische Unabhängigkeit. Zwei Sessions können durch dasselbe Gebäude, dieselbe Trasse, dieselbe Stromquelle oder denselben Transportanbieter laufen. Umgekehrt können zwei Leitungen zwischen demselben ASN-Paar physisch verschieden sein und dennoch im AS-Pfad identisch erscheinen. Logische und physische Vielfalt müssen separat bewertet werden.

Der Snapshot ist daher für topologierelevantes Monitoring nützlich, nicht für Redundanz-Zertifizierungen. Er stützt eine konsistente beobachtete Übergabe und eine messbare Baseline. Er offenbart keine Leitungszahl, Standortzahl, vertragliche Exklusivität oder gemeinsame Ausfalldomänen.

11. Ein einzelner sichtbarer Nachbar lässt mehrere Möglichkeiten offen

RIPEstats Routing-Status zeigt einen beobachteten Nachbarn und stimmt mit dem BGP-State-Muster überein. Es ist verführerisch, dies als Single-Upstream-Netz zu lesen. Der Befund stützt jedoch „Ein Nachbar war sichtbar“, nicht „Es gibt nur einen einzigen Upstream“.

Eine Backup-Session kann passiv bleiben, eine Route nur im Fehlerfall exportieren oder bei Sammlern wegen Präferenzregeln nicht sichtbar sein. Der Betreiber kann außerdem mehrere Leitungen zum gleichen ASN haben. Öffentliches BGP komprimiert diese physisch unterschiedlichen Links in dieselbe unmittelbare AS-Sequenz.

Die Gegenrichtung ist ebenfalls relevant: Die beobachtete Beziehung kann hoch konzentriert sein. Wenn jeder externe Weg über einen einzigen kommerziellen und physischen Pfad läuft, kann ein Vorfall an dieser Grenze weitreichend sein. Die aktuellen Quellen können diese Exposition nicht berechnen.

Die verantwortbare Schlussfolgerung ist eine offene operative Frage statt einer Resilienz-Scorecard. Belege zu Verträgen, Point-of-Presence-Lagen, Schnittstellenvielfalt, Transportwegen, Stromversorgung und getesteter Umschaltung wären erforderlich, bevor die Übergabe als redundant oder fragil bewertet wird.

12. Die Routen-Validierung ist bei den zwei IPv4-Routen uneinheitlich

RIPEstat meldete für AS271796 eine RPKI-Validierung alsvalidfür179.51.204.0/24. Die validierende Route-Origin-Authorisierung erlaubt den Ursprung und eine maximale Präfixlänge von/24. Dieses Ergebnis passt zum registrierten Block, dem beobachteten Ursprung und den Sicherheitsmetadaten, die bei Route-Origin-Validierung verwendet werden.

Für38.255.0.0/24meldet derselbe Dienstunknownund keine validierende ROA. Der Unterschied ist relevant, da die beiden Routen denselben Ursprung-AS teilen, aber unterschiedliche Autorisierungszustände haben. Ein Monitoring-System sollte die Ergebnisse getrennt halten, statt einen Status auf das gesamte Netzwerk zu übertragen.

RPKI-Gültigkeit ist kein Qualitätssiegel. Eine valide Route kann dennoch Leaks, Fehlkonfigurationen, Überlastung oder physische Ausfälle haben. Sie sagt aus, dass das getestete Ursprung-Präfix-Paar von den geltenden Metadaten autorisiert ist. Sie zertifiziert weder Pfad noch Kundenerfahrung noch interne Kontrollen.

Die ungleiche Lage schafft aber eine konkrete Rechenschaftsebene. Das direkt registrierte/24hat ein positives Autorisierungssignal. Das zweite beobachtete/24hat im erfassten Validierungsergebnis keinen solchen Status. Zukünftige Checks können prüfen, ob sich der unknown-Status ändert, ohne aus der aktuellen Lücke einen Vorwurf abzuleiten.

13. Unknown ist nicht Invalid

RPKI-Terminologie ist eindeutig.Validbedeutet: Eine anwendbare Autorisierung erlaubt den beobachteten Ursprung und die Präfixlänge.Invalidbedeutet: Eine anwendbare Autorisierung existiert, aber die Ankündigung widerspricht ihr.Unknownbedeutet typischerweise, dass der Validator für die getestete Route keine passende Autorisierung fand.

Das Ergebnis für38.255.0.0/24ist unknown, nicht invalid. Es zeigt nicht, dass AS271796 die Route hijacked hat, dass die Route universell abgelehnt wird oder dass Fly Internet fahrlässig gehandelt hat. Netzbetreiber wenden eigene Routing-Policies an, und viele akzeptieren unknown-Routen, während sie invalid-Routen filtern oder de-priorisieren.

Das Ergebnis löst auch die Delegationsgrenze nicht. Der Parent-Datensatz bei ARIN und das Fehlen einer validierenden ROA lassen die exakte Delegationsbeziehung im eingefrorenen Datenbestand offen. Das ist ein Grund, Unsicherheit beizubehalten, nicht Anlass für eine Verdachtshypothese.

Die operative, belastbare Aussage ist bescheiden: Die Route war sichtbar, ihr Ursprung war AS271796 und der geprüfte Validator meldete unknown. Diese Kombination ist nachvollziehbar und kann weiter beobachtet werden, wenn sich Ursprung oder Verfügbarkeit ändern.

14. Die IPv6-RPKI-Abfrage ergab ebenfalls unknown

Die RPKI-Abfrage für2803:7fe0::/32ergab unknown. Unabhängig davon bedeutet das, dass der getestete Validator im erfassten Datensatz kein gültiges Autorisierungsergebnis für den registrierten IPv6-Block lieferte. Die Routing-Status-Antwort meldete zeitgleich keine IPv6-Ankündigung aus AS271796.

Diese Tatsachen liegen in verschiedenen Ebenen. Die Registry legt den Ressourceninhaber fest. Die RPKI-Antwort beschreibt Autorisierungsmetadaten für ein getestetes Ursprung-Präfix-Paar. Der Routing-Snapshot zeigt, was Messstellen beobachtet haben. Keine dieser Ebenen ersetzt die andere.

Da keine IPv6-Origin-Ankündigung beobachtet wurde, ist das unknown-RPKI-Ergebnis kein Beleg für eine aktuell sichtbare unautorisierte Route. Ebenso wenig zeigt es, ob Fly Internet eine geplante Bereitstellung, eine nicht beobachtete Ankündigung oder keinen aktiven IPv6-Service hat. Die Quellen enden an der öffentlichen Grenzen.

Der nützlichste künftige Hinweis wäre eine koordinierte Änderung: Eine IPv6-Route erscheint, Collector-Sichtbarkeit ist messbar und eine passende Autorisierung validiert den Ursprung. Bis dahin bleibt das registrierte, aber ungesichtete/32Teil des Nummernressourcen-Datensatzes statt eines Belegs für gelieferte Dual-Stack-Nutzung.

Das Fehlen dieser koordinierten Signale ist ein Monitoring-Zustand, keine Aussage zu Betreiberabsichten.

15. Die Website des Betreibers beschreibt Leistungen, nicht gemessene Bereitstellung

Die Website von Fly Internet verwendet die Sprache lokaler Dienste: FTTH, Glasfaserverbindungen, Wireless-Netzwerke, Privatkunden-Pläne, Business-Pläne und Service rund um Capilla del Senor. Diese Aussagen stützen die Kategorisierung des Unternehmens als Internetzugangsanbieter.

Sie liefern keine unabhängig messbare Abdeckungskarte. Eine Tarifliste sagt nicht, welche Straßen versorgbar sind, wo Glasfaser aktiviert wurde, wie Funksektoren dimensioniert sind oder ob eine konkrete Adresse die beworbene Leistung erhält. Verfügbarkeit kann innerhalb eines nominalen Servicegebietes variieren.

Die Seite wirbt außerdem mit symmetrischer Unternehmenskonnektivität. Das ist eine Betreiber-Positionierung, kein Beleg für erreichte Geschwindigkeit unter Last, zugesicherte Information-Rate, Latenz, Paketverlust oder Wiederherstellungszeit. Die Aussage bleibt im Betreiber-Positioning und darf nicht zu einem Leistungsfazit umgedeutet werden.

Diese Trennung schützt Nutzer und Betreiber gleichermaßen. Marketing wird zutreffend dargestellt, die fehlende unabhängige Messung wird aber nicht durch erfundene Sicherheit ersetzt. Die öffentlichen Netzdaten schaffen eine alternative Evidenz: eine identifizierbare ASN und sichtbare Routen, nicht einen Kundenleistungs-Standard.

16. FTTH sagt nicht, wer das physische Netz betreibt

Der Begriff Fibre-to-the-Home beschreibt ein Bereitstellungsmodell, sagt aber nicht, wem jedes einzelne Asset gehört. Ein Betreiber kann Glasfaser besitzen, Stränge mieten, Wholesale-Zugänge kaufen, Masten und Trassen teilen oder Glasfaser-Backhaul mit kabelloser Letztmeter-Lieferung kombinieren.

Die eingefrorenen Quellen identifizieren keine Schächte, Masten, Cabinets, Splitter, Optical Line Terminals, Türme oder Endgeräte beim Kunden. Sie liefern keine Routenpläne, Standortlisten, Konzessionsunterlagen oder Lieferantenverträge. Es wäre falsch, aus ASN und Website auf eine physische Versorgungskarte zu schließen.

Eigentum und operative Kontrolle können auch differieren. Ein Betreiber kann die Provisionierung und den Support steuern, während Transport, Reparaturen oder passiver Netzzugriff von Dritten abhängen. Diese Abhängigkeiten beeinflussen Wiederherstellungszeit und Kontinuität, sind aber im BGP nicht sichtbar.

Für Fly Internet belegen die Daten eine öffentliche Routing-Kante und ein Betreiber-intern beschriebenes FTTH-/Wireless-Angebot. Die Infrastruktur hinter diesem Angebot bleibt eine offene Rechercheebene. Ihre Klärung erfordert Asset-Listen, Feldbelege, Wholesale-Disclosures oder direkte Betreiberunterlagen.

17. Der Rechenzentrum-Rahmen muss verworfen werden

Die ursprüngliche Planungsterminologie legte nahe, Rechenzentrum, Colocation, Serverraum oder Hosted-Infrastruktur zu analysieren. Keine der eingefrorenen Quellen stützt dieses Modell. Der Betreiber beschreibt Internetzugang, und Registry-/Routing-Daten beschreiben Nummernressourcen und Routenherkunft.

Ein ASN bedeutet kein Rechenzentrum. Viele lokale Access-Anbieter halten autonome Systeme, damit sie Adressraum originieren und Routen austauschen können. Eine sichtbare BGP-Übergabe kann in einer Betreiberanlage, Partner-Location oder anderem Netzwerkumfeld enden; der öffentliche Pfad identifiziert kein Colocation-Geschäft.

Auch die Existenz öffentlicher IPv4-Adressen beweist weder Server, Racks, Stromsysteme noch Kühlanlagen. Das sind separate physische und kommerzielle Tatsachen. Eine solche Behauptung würde generische Internetinfrastruktur in eine spezifische Facility-Story überführen, ohne Evidenz.

Die belastbare These ist daher eine Access-Network-Accountability-Perspektive. Sie fragt, was die Nummernressourcen- und Routingebenen sichtbar machen, und benennt danach die physischen, Kapazitäts- und Kontinuitätsfragen, die offen bleiben.

18. BGP zeigt die Kante, nicht das interne Netz

Externes Routing komprimiert die interne Komplexität eines Betreibers auf einen Ursprung. Collector sehen, dass AS271796 zwei Routen annonciert und über ein unmittelbares Nachbar-AS empfängt, aber nicht die internen Leitungen, die Verkehr von der Kante zur Access-Infrastruktur und zu Kunden transportieren.

Intern können mehrere Router, Aggregationspunkte, Funkmasten, Glasfaserringe, Baumtopologien oder ein einfacheres Setup bestehen. Interne Routingprotokolle und private Adressräume können diese Struktur verschleiern. Im erfassten BGP-Zustand werden diese Architekturformen nicht abgegrenzt.

Ausfalldomänen sind ebenfalls verborgen. Zwei Kundensegmente können dieselbe Rückfallebene, Stromzufuhr oder Aggregationsschaltung teilen. Alternativ können identische BGP-Pfade durch sehr unterschiedliche Transport- und Gerätekonfigurationen getragen werden. Die Routenfolge kann diese Fälle nicht trennen.

Deshalb sollte die Kontrollplane-Evidenz als Edge-Boundary beschrieben werden. Sie zeigt, dass eine Ressource über eine erkennbare Übergabe global erreichbar ist. Sie beschreibt nicht den internen Weg, der diese Erreichbarkeit in einen funktionsfähigen Access-Service verwandelt.

19. Routen-Sichtbarkeit und Verkehrsbereitstellung sind unterschiedliche Messungen

BGP zeigt, dass ein Netz erreicht werden kann. Es misst nicht, ob Pakete tatsächlich ans Ziel kommen, ob Anwendungen reagieren oder ob Kunden eine ausreichende Dienstqualität erhalten. Verkehr kann nach Erreichen des Ursprungs scheitern, und Überlast kann Leistung senken, während die Route stabil bleibt.

Die Quelldaten enthalten keine Verkehrsmengen, Latenz-, Verlust-, Durchsatz- oder DNS-Messungen. Sie enthalten auch keine Ausfallberichte oder langfristige Service-Probes. Jede Aussage zur realen Servicequalität braucht zusätzliche Beobachtungen und ein klares Messverfahren.

Die Unterscheidung ist besonders relevant für kleine regionale Anbieter. Eine global sichtbare Route kann den Eindruck umfassender Internetmessung erzeugen, während Nutzererfahrung von lokalem Glasfaserzustand, Funkbedingungen, Stromausfällen und Reparaturkapazität abhängt, die globale Collector nicht sehen.

Für die Rechenschaft bleibt die Routing-Basis dennoch wertvoll. Bei gemeldeten Serviceausfällen können Forscher Sichtbarkeit mit Kundenberichten vergleichen. Bleibt BGP stabil, kann der Fokus auf Innenlagen wechseln. Treten Routenrückzüge auf, wird die externe Übergabe zu einem stärkeren Anhaltspunkt. Der aktuelle Nachweis setzt diese Grundlage ohne Vorverurteilung durchzuführen.

Der Vergleich wird erst diagnostisch, wenn Route-Zeitstempel und Serviceberichte sauber aufeinander abgeglichen sind.

20. Registry-Kontakte sind eine operative Oberfläche, keine Garantie

Die LACNIC-Daten enthalten administrative, technische und Abuse-Kontakte für den Fly Internet-Registranten. Kontaktierbarkeit gehört zur Nummernressourcen-Verantwortung, weil andere Betreiber und Ermittler bei Routenproblemen, Abuse-Meldungen oder Registry-Fragen einen verantwortlichen Ansprechpartner benötigen.

Persönliche Telefonnummern, Straßen- und E-Mail-Daten werden nicht reproduziert. Ihre Funktion im Beleg ist die Verknüpfung von Name mit Netzwerkressourcen-Datensatz und der Nachweis, dass ASN und Zuteilungen über definierte operative Kontakte verfügen.

Ein gefülltes Kontaktfeld garantiert keine Reaktionszeit. Adressen veralten, Verantwortlichkeiten ändern sich und ein nomineller Kontakt muss nicht jede operative Entscheidung steuern. Kontaktqualität verlangt Outreach und dokumentierte Reaktionshistorie, was außerhalb dieses Quellsatzes liegt.

Der Datensatz schafft dennoch einen Ausgangspunkt. Tritt eine Routing-Anomalie oder ein Abuse-Fall auf, kann der registrierte Kontakt mit den aktuellen öffentlichen Support-Kanälen des Betreibers verglichen werden. Präzise Daten reduzieren Ambiguität, auch wenn sie keinen schnellen operativen Antwortnachweis sichern.

21. Das Mitgliedsregister ergänzt den Beweis, ohne neue Behauptungen zu schaffen

Ein offizielles LACNIC-PDF des Electoral Register wurde im Quellsatz erfasst. Es kann die Präsenz der Mitgliedsidentität im Registry-Ökosystem unterstützen, aber der Text wurde für diese Prüfung nicht vollständig extrahiert.

Da keine vollständige textliche Extraktion verfügbar war, trägt die PDF im vorliegenden Review keinen zusätzlichen Faktbeitrag. Die exakten ASN- und Adressbindungen stammen aus maschinenlesbaren RDAP-Daten, die stärker sind und leichter reproduzierbar sind.

Diese Vorgehensweise zeigt eine Evidenzregel: Der Besitz einer Datei ist nicht gleich der Bestätigung ihres Inhalts. Ein Beleg darf nur das beitragen, was tatsächlich geprüft und zur untersuchten Entität verknüpft wurde. Nicht lesbare oder partiell erfasste Quellen sollen nicht zur Profilanreicherung genutzt werden.

Die gleiche Logik gilt für einen Cloudflare-Radar-Request mit HTTP 403. Ein fehlgeschlagener Abruf kann keine Verkehrs-, Popularitäts- oder Routingaussagen stützen. Registrierungs- und RIPEstat-Daten begründen die gebundene Netzwerk-Identität ohne dieses Ergebnis.

22. Was öffentliche Belege nicht festlegen können

Der Quellsatz enthält keine Abonnentenzahl, kein Umsatzniveau, keine Marktanteils-Schätzung und kein Kundenmix. Er klärt nicht, ob private oder gewerbliche Verbindungen dominieren. Er liefert weder unabhängige Abdeckungskarte, Glasfaserlänge, Mastenanzahl noch Liste dienstbarer Adressen.

Kapazität bleibt ebenfalls dunkel. Zwei/24-Routen sagen nichts über Access-Durchsatz, Upstream-Vertrag, Spitzennachfrage, Reservekapazitäten oder Stau aus. Die Anzahl der BGP-Beobachtungen zeigt Collector-Pfade, nicht Kapazität. Die öffentlichen Daten geben keine Gerätemodelle, Interface-Geschwindigkeiten oder Oversubscription-Richtlinien an.

Kontinuität bleibt ungemessen. Es gibt keine dokumentierte Ringtopologie, Ausweichstromversorgung, zweiten Upstream, Wiederherstellungsziel, Ersatzinventar oder Ausfallhistorie. Eine konsistente AS64123-Adjazenz kann diese Fragen rahmen, nicht beantworten.

Diese Lücken sind kein Beleg für schlechte Leistung. Sie sind Grenzen dessen, was verantwortbar gesagt werden kann. Eine realitätsbasierte Profilierung unterscheidet fehlenden öffentlichen Beleg von einem Beleg des Fehlens und hält Unsicherheit sichtbar statt mit Vermutungen oder Verdacht zu füllen.

23. Die nützlichsten Kundenfragen beginnen dort, wo BGP endet

Für Kunden sind die Existenz eines registrierten ASN und breit sichtbarer Routen relevant. Sie zeigen, dass Fly Internet über eine eindeutige öffentliche Routing-Identität verfügt, statt nur durch eine Retail-Website repräsentiert zu werden. Das gültige ROA für ein registriertes/24liefert ein positives Signal bei der Origin-Autorisierung.

Beschaffungsvorgänge hängen jedoch an Details außerhalb der aktuellen Evidenz. Kunden sollten wissen, ob ihr Anschluss über Glasfaser oder Funk bereitgestellt wird, welche Ausrüstung und Stromreserve im Gebiet vorhanden sind, ob Business-Tarife eine zugesicherte Leitung enthalten und wie schnell Störungen behoben werden.

Business-Kunden haben zusätzliche Kontinuitätsfragen. Sie können diverse Zugangspfade, einen dokumentierten Eskalationsprozess, statische Adressen, Service-Level-Versprechen oder eine Ausweichlösung brauchen, die nicht dieselbe physische Abhängigkeit hat.

Der Nachweis gibt daher eine klarere Begriffswelt statt eines Urteils. Er ermöglicht Unterscheidung zwischen registrierten Ressourcen, sichtbaren Routen, Sicherheitsmetadaten, physischem Zugang und vertraglichen Leistungsbedingungen und damit gezielte Rückfragen auf der für sie relevanten Ebene.

24. Eine Monitoring-Baseline kann künftige Rechenschaft verbessern

Der erfasste Zustand bietet mehrere reproduzierbare Marker: AS271796; registrierter179.51.204.0/24; registrierter2803:7fe0::/32; beobachtete38.255.0.0/24; unmittelbarer Nachbar AS64123; ein valides IPv4-RPKI-Ergebnis; ein unknown IPv4-Ergebnis; und keine beobachtete IPv6-Ankündigung.

Regelmäßige Checks können sinnvolle Veränderungen erkennen. Ein neuer Nachbar kann zusätzliche Interkonnektierung oder eine Routing-Neustruktur anzeigen. Eine neu sichtbare IPv6-Route kann Fortschritt der Bereitstellung bedeuten. Ein Wechsel von unknown zu valid bei der zweiten IPv4-Route kann neue Autorisierungsmetadaten bedeuten.

Veränderung braucht weiterhin Interpretation. Ein Withdraw kann geplante Wartung, Messlücke oder Ausfall bedeuten. Ein neuer Pfad kann Backup-Aktivierung, Providerwechsel oder Collector-Auswahl bedeuten. Registry- und Betreibernachweise sollten vor der Ursachenbenennung geprüft werden.

Die Baseline ist nützlich, weil sie künftige Fragen konkret macht. Sie wandelt eine allgemeine Firmenbeschreibung in beobachtbare Netzwerkfakten und bewahrt die Trennung zwischen externen Internet-Signalen und den Ebenen, die der Betreiber dokumentieren muss.

Diese Trennung ist die zentrale Rechenschaftsgrenze für künftige Aktualisierungen dieses Profils.

25. Die öffentliche Grenze von Fly Internet ist real, aber unvollständig

Fly Internet ist in diesem Belegsatz nicht nur eine Marken-Webseite. Der exakte Verzeichniseintrag ist mit AS271796, einem direkt registrierten IPv4-/24, einem registrierten IPv6-/32und zwei beobachteten IPv4-Origin-Ankündigungen verknüpft. Diese Datensätze schaffen eine aktuelle Netzressourcenfläche.

Der Routing-Snapshot ergänzt dies durch eine konsistente AS64123-Übergabe und breite IPv4-Collector-Sichtbarkeit. RPKI liefert ein ungleiches Autorisierungsbild: valid für den direkt registrierten179.51.204.0/24, unknown für die beobachtete38.255.0.0/24und unknown für den registrierten, aber nicht beobachteten IPv6-Block.

Keines davon offenbart die physische operative Grenze hinter dem Service. Die Quellen legen weder Glasfaser-Eigentum, Funkabdeckung, Kapazität, Redundanz, Verfügbarkeit, Wiederherstellungsleistung noch einen exklusiven Upstream offen. Sie bestätigen auch nicht den Data-Center-Rahmen, den der ursprüngliche Plan vorschlug.

Die präzise Bewertung ist daher sowohl konkret als auch zurückhaltend. AS271796 macht Fly Internet am Routing-Rand sichtbar. Die öffentlichen Daten zeigen, wo Verantwortung am Internet-Edge beginnt, während physischer Zugang, Service-Zusagen und Kontinuitätskontrollen hinter diesem Rand noch offene Gegenstände bleiben.

26. Registrierte Ressourcen und beobachtete Routen müssen in separaten Spalten bleiben

Die Fly Internet-Evidenz wird klarer, wenn administrative und Routingbeobachtungen als zwei Spalten und nicht als gemischte Aussage geführt werden. Die registrierte Spalte enthält AS271796,179.51.204.0/24und2803:7fe0::/32, alle per LACNIC mit dem exakten Registranten verknüpft. Die beobachtete Spalte enthält die Routen und Pfade, die RIPEstat im datierten Intervall berichtete.

Die Spalten überlappen bei179.51.204.0/24: Dieser Block ist direkt bei Fly Internet registriert und erscheint mit AS271796 als Ursprung. Diese Übereinstimmung liefert die stärkste Aussage im Belegsatz. Sie zeigt intern immer noch keine tatsächliche Auslieferung, aber registrierter Inhaber und Laufzeit-Identität stimmen.

Die Spalten weichen bei38.255.0.0/24auseinander. Die Route erscheint in der beobachteten Spalte, während die registrierte Anfrage bei LACNIC nach ARIN und dem Cogent-Parentbereich zeigt statt eines exakten Fly Internet-Eintrags. Die Abweichung macht die Route nicht illegitim. Sie bedeutet lediglich, dass die öffentliche Evidenz den Delegationsmechanismus, der den Adressraum mit dem Ursprung verbindet, nicht zeigt.

Sie weichen auch bei IPv6 auseinander. Das/32ist in der registrierten Spalte vorhanden, während der erfasste Routingzustand keine IPv6-Ankündigung meldet. Die Trennung verhindert zwei häufige Fehler: jede registrierte Ressource als aktiv geroutet zu behandeln und jede sichtbare Route als eigene registrierte Zuteilung zu interpretieren. Das Verfahren ist nützlicher als eine einzelne Zahlenüberschrift, weil es die Evidenzart hinter jeder Aussage bewahrt.

27. Physische Abhängigkeitsfragen brauchen physische Belege

Netzkontinuität hängt letztlich von Ausrüstung, Transport, Standorten, Strom, Personal und vertraglichem Zugang ab. Keiner dieser Faktoren kann aus einem autonomen Systemsatz gezählt werden. Eine belastbare Resilienzbewertung müsste mindestens externe Handoff-Standorte, Pfade von dort ins Access-Netz und geteilte Ausfalldomänen entlang dieser Wege benennen.

Für ein Glasfasernetz wären nützliche Belege etwa Rings- oder Baumdesign, Pfaddiversität zwischen Cabinets und Handoffs, Pole- oder Trassenabhängigkeiten, Reservefaser, optische Ausrüstung und Feldservice-Fähigkeit. Für Wireless wären es Turmstandorte, Backhaul, Spektrumregelungen, Backup-Strom, Sektor-Kapazität und Wetterausfallrisiko. Die aktuellen Daten enthalten keine dieser Elemente.

Die gleiche Methodik gilt für AS64123. Seine konsistente Position vor AS271796 zeigt eine Control-Plane-Beziehung, lokalisiert aber keinen Interconnection-Standort und identifiziert nicht den eingesetzten Transport. Eine einzige kommerzielle Beziehung kann über mehrere geschützte Leitungen bereitgestellt werden, mehrere Verträge können am selben physischen Standort enden. Anbieterzahl, ASN-Zahl und Ausfalldomäne sind nicht identisch.

Eine künftige Betreiberoffenlegung könnte solche Fragen beantworten, ohne sensible Details preiszugeben. Sie könnte etwa benennen, ob externe Konnektivität an mehr als einem Standort bereitgestellt wird, ob Access-Bereiche unabhängige Backhaul-Pfade haben oder ob Business-Services separate Wiederherstellungsziele nutzen. Solange dies fehlt, bleiben es offene Fragen statt belastbarer Resilienz-Noten.

28. Sicherheitsmetadaten und Servicekontinuität lösen unterschiedliche Probleme

RPKI hilft, zu bewerten, ob ein autonomes System zu einem Präfix autorisiert ist. Das ist eine wichtige Sicherheitskontrolle, besonders bei der Gegenüberstellung von Registry-Daten und Routing-Ankündigungen. Das valide Ergebnis für179.51.204.0/24liefert ein positives, maschinenprüfbares Signal für genau diese Ursprung-Präfix-Kombination.

Servicekontinuität beantwortet andere Fragen. Eine perfekt autorisierte Route kann dennoch ausfallen, wenn ein Router fehlschlägt, Glasfaser beschädigt wird, ein Standort keinen Strom hat oder ein Upstream-Pfad überlastet ist. Umgekehrt kann eine RPKI-unknown-Route lange zuverlässig Verkehr führen. Der Autorisierungsstatus unterstützt Sicherheitsanalyse, ohne zur Verfügbarkeitskennzahl zu werden.

Diese Trennung verhindert zudem eine „vollständig gesicherte“ Schlussfolgerung aus der einen validen Route. Bei Fly Internet bleibt die zweite beobachtete IPv4-/24im erfassten Ergebnis unknown, und der registrierte IPv6-Block ist im Routing nicht beobachtbar. Das Netzwerk hat mehrere Sicherheitszustände, nicht einen universellen RPKI-Status.

Operative Rechenschaft steigt, wenn jede Ebene mit ihren eigenen Nachweisen bewertet wird. Registry-Güte bezeichnet den verantwortlichen Inhaber. RPKI ergänzt Autorisierungsmetadaten. BGP liefert laufende Ankündigungen und sichtbare Adjazenzdaten. Verkehrsprobes und Betreiberdaten würden Lieferung und Wiederherstellung abdecken. Keine dieser Ebenen sollte zur Beweisführung für die andere genutzt werden.

29. Mehr Offenlegung würde den öffentlichen Baseline-Zustand nutzbarer machen

Die vorhandenen Daten ermöglichen bereits sinnvolles Monitoring, aber gezielte zusätzliche Offenlegung könnte die Nutzbarkeit erhöhen. Ein präziser Datensatz zur Nutzung von38.255.0.0/24würde die Address-Delegationslücke schließen. Eine veröffentlichte ROA, sofern betrieblich passend, könnte den unbekannten RPKI-Status zu valid ändern.

IPv6 ist ein klarer weiterer Hebel. Fly Internet könnte offenlegen, ob der registrierte/32reserviert ist, sich im Rollout befindet oder über ein nicht beobachtbares Arrangement bereitgestellt wird. Das ersetzt keine Messung, hilft aber, Registrierung und beobachtete Ankündigungen einzuordnen.

Kontinuitätsaussagen benötigen stärkere Untermauerung. Wenn der Betreiber unterschiedliche Upstreams, geschützten Transport, Backup-Strom oder Wiederherstellungsziele angibt, sollten diese Aussagen den konkreten Scope und Bereich benennen. „Redundant“ kann zwei Routerports, zwei Leitungen, zwei Standorte oder zwei unabhängige Pfade bedeuten; diese sind nicht gleichwertig.

Das Ziel ist nicht, sensible Topologie zu veröffentlichen. Es geht darum, öffentliche Aussagen mit belastbaren, verständlichen Belegen abzugleichen. Die vorhandenen Daten schaffen eine reale Netzwerkidentität und eine stabile Control-Plane-Basis. Gezielte Offenlegung kann diese Grenze mit den tatsächlichen Bereitstellungs- und Kontinuitätszusagen verknüpfen, die aktuell nicht sichtbar sind.

Quellen

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