Acceptable Use Policy (AUP) — frankonIX

handily networks GmbH Hauptstraße 37, 91227 Leinburg HRB 41496 Amtsgericht Nürnberg Geschäftsführer: Felix Schroeder USt-IdNr.: DE361522226 www.handily.network | support@handily.network | Tel. +49 9120 4179960

Stand: Juli 2026 Dokumentversion: 2.1

Diese Acceptable Use Policy (AUP) beschreibt die technischen und organisatorischen Regeln für die Nutzung der Infrastruktur des frankonIX. Verstöße gegen diese AUP können gemäß den Nutzungsbedingungen (ToS) des frankonIX zu Einschränkungen, Sperrung oder Beendigung der Teilnahme führen.

Diese AUP orientiert sich an branchenüblichen Best Practices, wie sie unter anderem von Euro-IX und vergleichbaren Internet Exchange Points angewendet werden.

§1 Zulässige Nutzung

(1) Der bereitgestellte Port darf ausschließlich für den Austausch von IP-Datenverkehr (Peering) verwendet werden.

(2) Erlaubte Ethernet-Frame-Typen: Es dürfen ausschließlich folgende Ethernet-Frame-Typen genutzt werden:

a) 0x0800 — IPv4, b) 0x0806 — ARP (nur für IPv4-Adressauflösung), c) 0x86DD — IPv6.

(3) Alle anderen Ethernet-Frame-Typen sind unzulässig und werden vom Betreiber gefiltert. Insbesondere unzulässig sind:

a) 802.1Q-getaggte Frames (VLAN-Tagging) auf dem Peering-Port, sofern nicht ausdrücklich vereinbart, b) MPLS-Frames (0x8847, 0x8848), c) PPPoE-Frames (0x8863, 0x8864), d) alle weiteren nicht explizit erlaubten Protokolle.

(4) VLAN-Pflicht bei Wiederverkauf und Marketplace: Tritt der Teilnehmer als Wiederverkäufer auf oder nutzt er den Marketplace, um Dienste an andere Teilnehmer (End-Peers) zu vertreiben, so darf dies ausschließlich über gesonderte, vom Betreiber zugeteilte VLANs erfolgen. Es gilt im Einzelnen:

a) Ein VLAN je Dienst: Für jeden einzelnen erbrachten Dienst ist genau eine (1) zusätzliche, vom Betreiber zugeteilte VLAN-ID zu nutzen. Die Mehrfachnutzung derselben VLAN-ID für mehrere Dienste ist unzulässig. b) Geltung auch bei mehreren Diensten an denselben End-Peer: Die Regelung nach Buchstabe a) gilt unabhängig davon, ob die Dienste an unterschiedliche oder an denselben End-Peer erbracht werden. Vertreibt der Wiederverkäufer oder Marketplace-Teilnehmer beispielsweise zwei BGP-Sessions an denselben End-Peer, sind hierfür zwei getrennte VLANs zu buchen; wird zusätzlich ein Backup-Dienst (z. B. ein Backup-VLAN) erbracht, ist hierfür ein weiteres, drittes VLAN zu buchen. Für jeden weiteren Dienst gilt dies entsprechend fort. c) Zuteilung: VLAN-IDs werden ausschließlich durch den Betreiber vergeben. Die eigenmächtige Wahl oder Änderung von VLAN-IDs sowie die Weitergabe zugeteilter VLAN-IDs an Dritte sind unzulässig. Die Buchung erfolgt über das Kundenportal bzw. den IXP Manager oder per Support-Ticket. d) Kein QinQ: Die Nutzung von QinQ bzw. VLAN-Stacking (IEEE 802.1ad, doppelt getaggte Frames) innerhalb der oder oberhalb der zugeteilten VLANs ist nicht zulässig. Innerhalb eines zugeteilten VLANs sind ausschließlich die nach Absatz (2) erlaubten Ethernet-Frame-Typen zulässig. e) Die Zuteilung eines VLANs nach diesem Absatz gilt als ausdrückliche Vereinbarung im Sinne von Absatz (3) Buchstabe a). Im Übrigen bleibt die Nutzung getaggter Frames unzulässig. f) Nicht mehr benötigte VLANs sind dem Betreiber unverzüglich zur Rückgabe zu melden.

§2 Unicast-Pflicht und Traffic-Einschränkungen

(1) Über den Peering-Port darf ausschließlich Unicast-Verkehr übertragen werden.

(2) Folgende Traffic-Typen sind auf dem Peering-LAN unzulässig:

a) Broadcast: Kein IP-Broadcast außer ARP-Requests, die zur Adressauflösung zwingend erforderlich sind, b) Multicast: Kein IP-Multicast, sofern nicht ausdrücklich durch den Betreiber genehmigt, c) Proxy-ARP: Die Nutzung von Proxy-ARP ist ausdrücklich untersagt, d) Gratuitous ARP: Gratuitous-ARP-Pakete sind nur für die dem Teilnehmer zugewiesenen IP-Adressen zulässig, e) DHCP: Kein DHCP-Server-Betrieb auf dem Peering-LAN, f) Spanning Tree (STP/RSTP/MSTP): Keine Spanning-Tree-BPDUs, g) Discovery-Protokolle: Kein CDP, LLDP, MNDP oder vergleichbare Protokolle, sofern nicht vom Betreiber angefordert.

§3 MAC-Adressen

(1) Pro physischem Port ist genau eine (1) MAC-Adresse zulässig, sofern nicht ausdrücklich anderweitig mit dem Betreiber vereinbart.

(2) Bei LAG-Verbindungen (Link Aggregation) ist pro LAG-Gruppe eine (1) MAC-Adresse zulässig.

(3) Die verwendete MAC-Adresse ist dem Betreiber bei der Porteinrichtung oder bei Änderungen unverzüglich mitzuteilen und in der IXP-Manager-Datenbank zu hinterlegen.

(4) Der Betreiber ist berechtigt, MAC-Adressfilter (Port Security) einzusetzen. Frames mit nicht registrierten MAC-Adressen können ohne Vorankündigung verworfen werden.

(5) Wiederverkäufer und Marketplace-Teilnehmer: Führt der Teilnehmer als Wiederverkäufer oder Marketplace-Teilnehmer mehrere Endkunden über seinen Port — beziehen also mehrere Endkunden ihren Peering-Zugang zum frankonIX über den Port dieses Teilnehmers —, so gilt ergänzend:

a) Für jeden einzelnen Endkunden bzw. für jedes nach §1 Absatz (4) zugeteilte VLAN ist dem Betreiber genau eine (1) Router-MAC-Adresse zu benennen, nämlich die MAC-Adresse des Endkunden-Routers, der über das jeweilige VLAN peert. b) Die Benennung erfolgt vor Inbetriebnahme des jeweiligen Dienstes über den IXP Manager. Änderungen sind vorab, spätestens jedoch unverzüglich, mitzuteilen und im IXP Manager zu hinterlegen. c) Insoweit gilt eine Abweichung von Absatz (1) als ausdrücklich vereinbart; je zugeteiltem VLAN bleibt es bei genau einer (1) zulässigen MAC-Adresse. d) Absatz (4) gilt entsprechend je VLAN: Frames mit nicht registrierten MAC-Adressen können ohne Vorankündigung verworfen werden. e) Der Wiederverkäufer bleibt für die Richtigkeit und Aktualität der gemeldeten MAC-Adressen seiner Endkunden gegenüber dem Betreiber verantwortlich.

§4 Broadcast-Storm-Schutz

(1) Der Betreiber implementiert Broadcast-Storm-Control-Mechanismen zum Schutz der gesamten Peering-Plattform.

(2) Überschreitet der Broadcast- oder Multicast-Verkehr eines Teilnehmer-Ports einen vom Betreiber festgelegten Schwellenwert, kann der Port automatisch rate-limited oder vorübergehend deaktiviert werden.

(3) Der Teilnehmer ist verpflichtet, seine eigene Netzwerkkonfiguration so zu gestalten, dass kein übermäßiger Broadcast- oder Multicast-Verkehr in das Peering-LAN gelangt.

§5 IPv6-Anforderungen

(1) Der frankonIX unterstützt sowohl IPv4 als auch IPv6 als gleichwertige Protokolle auf dem Peering-LAN.

(2) Teilnehmer werden ermutigt, neben IPv4-Peering auch IPv6-Peering einzurichten.

(3) Für IPv6-Peering gelten dieselben Regeln wie für IPv4, insbesondere hinsichtlich RPKI, Route-Filtering und Prefix-Limits.

(4) Neighbor Discovery Protocol (NDP) für IPv6 ist ausschließlich für die dem Teilnehmer zugewiesenen IPv6-Adressen zulässig. Router Advertisements (RA) durch Teilnehmer auf dem Peering-LAN sind unzulässig.

§6 BGP-Anforderungen

(1) Teilnehmer müssen BGP-4 (RFC 4271) für den Austausch von Routing-Informationen verwenden.

(2) RPKI-Pflicht: Alle angekündigten Präfixe müssen über gültige ROAs (Route Origin Authorizations) verfügen. Routen mit RPKI-Status „Invalid" werden von den Route-Servern verworfen.

(3) Best Current Practices (BCP): Teilnehmer sind verpflichtet, folgende BCPs einzuhalten:

a) BCP38 / RFC 2827 (Network Ingress Filtering): Teilnehmer müssen sicherstellen, dass kein Traffic mit gefälschten Quelladressen (Spoofing) über den IXP-Port gesendet wird. b) BCP84 / RFC 3704 (Ingress Filtering for Multihomed Networks): Teilnehmer mit mehreren Upstream-Anbietern müssen geeignete Anti-Spoofing-Maßnahmen implementieren.

(4) Teilnehmer dürfen auf dem Peering-LAN des frankonIX keine IP-Adressen als Next-Hop verwenden, die nicht dem Teilnehmer vom Betreiber zugewiesen wurden.

(5) Die Verwendung von Static Routes, die auf IP-Adressen des Peering-LANs zeigen, ist nur für bilateral vereinbartes Peering zulässig.

§7 Unzulässige Nutzung

(1) Die Infrastruktur darf insbesondere nicht genutzt werden für:

a) rechtswidrige, missbräuchliche oder schädliche Zwecke, b) Aktivitäten, die die Integrität, Sicherheit oder Verfügbarkeit der Internet-Exchange-Infrastruktur beeinträchtigen, c) jegliches Verhalten, das zu Betriebsstörungen, Instabilität oder einer Risikoerhöhung für andere Teilnehmer führt, d) IP-Spoofing oder das Versenden von Datenverkehr mit gefälschten Quell-IP-Adressen, e) die Durchführung von DDoS-Angriffen oder die wissentliche Weiterleitung von Angriffs-Traffic, f) das Abfangen, Aufzeichnen oder Manipulieren von Datenverkehr anderer Teilnehmer, g) den Betrieb offener Resolver (DNS, NTP, SNMP) auf dem Peering-LAN.

§8 Transceiver und Module

(1) Die auf der Switch-Seite des Betreibers eingesetzten Transceiver-Module stellt und betreibt ausschließlich der Betreiber.

(2) Der Teilnehmer bestückt ausschließlich seine eigene Seite der Verbindung. Er hat dabei ein Modul einzusetzen, das der für seinen Port vereinbarten Spezifikation entspricht.

(3) Die Einbringung teilnehmereigener Transceiver-Module in die Infrastruktur des Betreibers ist nicht vorgesehen. Ein Versand von Modulen an die Anschlusspunkte findet nicht statt.

(4) Der Betreiber arbeitet ausschließlich mit Singlemode-Faser. Multimode wird nicht unterstützt.

(5) Die unterstützten Modultypen und die zugehörigen Spezifikationen veröffentlicht der Betreiber; sie sind über das Kundenportal abrufbar.

(6) Kontakt: support@frankonix.net

§9 Kommerzielle IP-Dienste

(1) Der Verkauf IP-basierter Dienstleistungen über den frankonIX unterliegt Einschränkungen, um einen ordnungsgemäßen Betrieb im Interesse aller Teilnehmer sicherzustellen.

(2) Teilnehmer, die beabsichtigen, als IP-Carrier Dienstleistungen über den frankonIX anzubieten, haben vorab Kontakt mit dem Betreiber aufzunehmen.

(3) Dies betrifft insbesondere:

a) die Bereitstellung vollständiger Internet-Routing-Tabellen (BGP Full Table, Full Feed oder IP Transit), b) die Bereitstellung selektiver BGP-Routen zu Tier-1- oder Tier-2-Carriern (Partial Transit oder Partial Feed), c) den kommerziellen Vertrieb oder die Vermittlung von Direktverbindungen oder Cloud-Connectivity-Diensten.

§10 Wiederverkauf und Marketplace

(1) Zwingende Zusatzvereinbarung: Sofern der Teilnehmer als Wiederverkäufer auftritt (Weiterveräußerung, Vermittlung oder Einbindung von Leistungen des frankonIX gegenüber Endkunden) und/oder den Marketplace nutzt, muss er den Anhang „Reseller and Marketplace Terms of Service" (RMToS) in der jeweils geltenden Fassung akzeptieren. Die Einzelheiten regelt §7 der Nutzungsbedingungen (ToS).

(2) Ohne wirksam angenommene RMToS ist die Nutzung der Wiederverkäufer- und Marketplace-Funktionen unzulässig; der Betreiber kann entsprechende Funktionen technisch sperren.

(3) Sämtliche Regelungen dieser AUP gelten für Wiederverkäufer und deren Endkunden-Traffic unverändert fort. Der Wiederverkäufer stellt sicher, dass der über seinen Port geführte Endkunden-Verkehr die Anforderungen der §§1 bis 7 erfüllt.

(4) Der Wiederverkäufer hinterlegt die ASNs, Präfixe und technischen Ansprechpartner seiner Endkunden im IXP Manager und hält diese Angaben aktuell.

(5) Verstöße von Endkunden eines Wiederverkäufers gelten als Verstöße des Wiederverkäufers und werden nach §13 dieser AUP sowie §9 der ToS behandelt.

(6) Für die technische Umsetzung gelten insbesondere die VLAN-Pflicht nach §1 Absatz (4) — ein gesondertes, vom Betreiber zugeteiltes VLAN je Dienst, kein QinQ — sowie die Pflicht zur Benennung einer Router-MAC-Adresse je Endkunde bzw. je VLAN nach §3 Absatz (5). Darüber hinausgehende abweichende Konfigurationen bedürfen der ausdrücklichen vorherigen Vereinbarung mit dem Betreiber.

§11 Betriebs- und Servicehinweise

(1) Der Austausch von Datenverkehr zwischen den Anschlusspunkten des frankonIX erfolgt grundsätzlich ohne Garantie hinsichtlich:

a) Verfügbarkeit, b) Durchsatz, c) Latenz.

(2) Sofern ein gesondertes Service Level Agreement (SLA) vereinbart wurde, gelten dessen Bestimmungen.

§12 Störungen und Meldungen

(1) Technische Störungen oder Auffälligkeiten sind unverzüglich dem Betreiber zu melden.

(2) Kontakt: support@frankonix.net

§13 Sanktionen bei Verstößen

(1) Bei Verstößen gegen diese AUP verfährt der Betreiber nach folgendem abgestuften Maßnahmenkatalog:

a) Benachrichtigung: Der Teilnehmer wird über den Verstoß informiert und aufgefordert, diesen innerhalb einer angemessenen Frist (in der Regel 24 Stunden bei technischen, 5 Werktage bei organisatorischen Verstößen) zu beheben. b) Rate-Limiting / Filterung: Bei fortgesetztem Verstoß oder bei Traffic-basierten Verstößen kann der Betreiber den betroffenen Verkehr rate-limiten oder filtern. c) Port-Deaktivierung: Bei schwerwiegenden oder wiederholten Verstößen kann der Betreiber den Port des Teilnehmers vorübergehend deaktivieren. d) Vertragskündigung: Bei besonders schwerwiegenden oder wiederholten Verstößen kann das Vertragsverhältnis gemäß den ToS außerordentlich gekündigt werden.

(2) Bei unmittelbarer Gefahr für die Plattformstabilität (z. B. Broadcast-Storm, massives Spoofing, BGP-Hijacking) ist der Betreiber berechtigt, den betroffenen Port ohne vorherige Ankündigung sofort zu deaktivieren.

(3) Die Reaktivierung eines deaktivierten Ports erfolgt erst nach Beseitigung des Verstoßes und Bestätigung durch den Teilnehmer.

(4) Bei Verstößen im Zusammenhang mit Wiederverkauf oder Marketplace kann der Betreiber zusätzlich die Wiederverkäufer- und Marketplace-Funktionen des Teilnehmers deaktivieren.

§14 Compliance

(1) Teilnehmer sind verpflichtet, sämtliche technischen Anforderungen und Richtlinien gemäß dieser Acceptable Use Policy, den Nutzungsbedingungen (ToS) sowie — soweit anwendbar — den Reseller and Marketplace Terms of Service (RMToS) einzuhalten.

(2) Der Betreiber ist berechtigt, die Einhaltung dieser AUP durch geeignete technische Maßnahmen (z. B. MAC-Filterung, Traffic-Analyse, Prefix-Monitoring) zu überwachen.

Kontakt

Betreiber: handily networks GmbH IXP-Support: support@frankonix.net Allgemeiner Support: support@handily.network