Vertragsdokument · frankonIX

Peering-Policy

Version 1.0 · Stand 1. November 2026 · frankonIX

§ 1 Grundsatz: offene Policy

(1) Der frankonIX ist ein neutraler Internet Exchange Point (IXP) in der Metropolregion Nürnberg, betrieben von der handily networks GmbH (nachfolgend „Betreiber"). Seine Peering-Policy ist offen: Jedes Netz, das die Voraussetzungen nach § 2 erfüllt, kann teilnehmen — unabhängig von Größe, Geschäftsmodell oder Sitz des Unternehmens.

(2) Ein Mindest-Traffic wird nicht verlangt. Der Betreiber schreibt den Teilnehmern nicht vor, mit wem sie peeren; über bilaterales Peering entscheiden die Teilnehmer untereinander.

(3) Diese Policy ergänzt die Nutzungsbedingungen (ToS) und die Acceptable Use Policy (AUP). Bei Widersprüchen gehen die ToS vor.

§ 2 Teilnahmevoraussetzungen

(1) Teilnehmen kann, wer

a) eine eigene, öffentlich zugeteilte Autonomous System Number (ASN) besitzt,
b) über einen dedizierten Router verfügt, der die Sessions zum frankonIX terminiert,
c) eine Singlemode-Glasfaseranbindung mit LR-Optik (10G, 40G oder 100G) an einem Standort des frankonIX herstellen kann und
d) einen physischen Anschlusspunkt in der Metropolregion Nürnberg hat.

(2) Die Standorte des frankonIX sind nLighten Nürnberg und Hetzner Nürnberg. Ein Port an einem Standort verbindet den Teilnehmer mit allen Teilnehmern des gesamten Fabrics.

(3) Privatpersonen und Hobbynetze ohne eigenen physischen Anschluss verweist der Betreiber an den kostenfreien Virtual Data Exchange (VDX), siehe § 8.

(4) Der Teilnehmer pflegt einen aktuellen Eintrag in der PeeringDB mit erreichbaren technischen Kontakten und hält ein NOC für Störungsmeldungen erreichbar.

§ 3 Route-Server-Peering

(1) Der frankonIX betreibt redundante Route-Server unter AS214591. Die Adressen stehen auf der Website des frankonIX. Die Teilnahme am Route-Server-Peering ist freiwillig und kostenfrei; empfohlen wird eine Session zu jedem Route-Server über IPv4 und IPv6.

(2) Die Route-Server filtern die angenommenen Präfixe nach § 6. Präfixe, deren RPKI-Validierung „invalid" ergibt, werden verworfen.

(3) Die Route-Server vermitteln nur die Routen; der Verkehr selbst fließt direkt zwischen den Teilnehmern über das Peering LAN.

(4) Soweit die Route-Server BGP-Communities zur Steuerung der Verteilung unterstützen, veröffentlicht der Betreiber die unterstützten Communities.

§ 4 Bilaterales Peering

(1) Teilnehmer dürfen über das Peering LAN bilaterale BGP-Sessions miteinander vereinbaren. Anfragen richten sich direkt an den jeweiligen Teilnehmer; die Kontaktdaten stehen in der PeeringDB.

(2) Der Betreiber vermittelt keine bilateralen Vereinbarungen und ist an ihnen nicht beteiligt.

§ 5 Technische Anforderungen an den Port

(1) Je Port ist genau eine MAC-Adresse zugelassen; sie wird bei der Bereitstellung registriert. Weitere MAC-Adressen werden verworfen.

(2) Im Peering LAN sind nur die Protokolle und Verkehrsarten erlaubt, die die AUP zulässt. Insbesondere sind Discovery-Protokolle, Spanning Tree und DHCP unzulässig.

(3) Der Teilnehmer verwendet im Peering LAN ausschließlich die ihm vom Betreiber zugewiesenen IPv4- und IPv6-Adressen.

§ 6 Präfix-Filterung, IRR und RPKI

(1) Teilnehmer dürfen nur Präfixe ankündigen, für die sie selbst oder ihre Kunden berechtigt sind. Die Präfixe müssen in einer öffentlichen Routing-Registry (IRR) über das AS-SET bzw. die AS-Nummer des Teilnehmers dokumentiert sein.

(2) Der Betreiber empfiehlt, für alle angekündigten Präfixe gültige ROAs zu pflegen. Ankündigungen, die laut RPKI ungültig sind, filtern die Route-Server aus.

(3) Präfixe aus privaten oder nicht zugeteilten Adressbereichen (Bogons) und das Peering LAN selbst dürfen nicht angekündigt werden. Der Betreiber kann an den Route-Servern weitere Filter anwenden, um das Routing zu schützen.

(4) Der Next-Hop muss die im Peering LAN zugewiesene Adresse des ankündigenden Teilnehmers sein.

§ 7 Kein Back-Haul, regionaler Charakter

(1) Der frankonIX ist ein regionaler Exchange. Der Betreiber verzichtet bewusst darauf, Teilnehmer aus anderen Regionen über Fernstrecken in das Peering LAN zu führen (Back-Haul), damit die Latenz im Metro-Netz gleichmäßig niedrig bleibt.

(2) Teilnehmer dürfen ihren Port nicht nutzen, um Dritten ohne eigene Teilnahme Zugang zum Peering LAN zu verschaffen. Ausgenommen sind ausdrücklich vereinbarte Reseller-Modelle nach den Reseller- und Marketplace-Bedingungen.

§ 8 Trennung von frankonIX und VDX

(1) Der Virtual Data Exchange (VDX) ist ein eigenes, vom frankonIX strikt getrenntes Fabric. Zwischen beiden besteht kein Layer-2-Übergang und keine gemeinsame Broadcast-Domäne.

(2) Die Teilnahme an beiden Fabrics ist möglich; sie erfordert jeweils eigene Sessions.

§ 9 Änderungen der Policy

(1) Der Betreiber kann diese Policy anpassen, wenn technische Entwicklungen, die Sicherheit des Peering LAN oder gesetzliche Vorgaben es erfordern. Die Teilnehmer werden über Änderungen mindestens vier (4) Wochen vor Inkrafttreten per E-Mail informiert.

(2) Kurzfristige Änderungen sind zulässig, soweit sie zur Abwehr einer Gefahr für das Peering LAN erforderlich sind. Der Betreiber informiert die Teilnehmer in diesem Fall unverzüglich.