Terms of Service (ToS) — frankonIX
handily networks GmbH Hauptstraße 37, 91227 Leinburg, Germany Commercial register: HRB 41496, Amtsgericht Nürnberg Managing Director: Felix Schroeder VAT ID: DE361522226 www.handily.network | support@handily.network | Phone +49 9120 4179960
Version date: July 2026 Document version: 2.1
Section 1 — Purpose and Scope
(1) These Terms of Service ("ToS") govern participation in frankonIX and the use of the infrastructure and services provided.
(2) The frankonIX Internet Exchange Point provides a physical and logical infrastructure that enables network operators to exchange IP traffic directly or via services offered by the Internet Exchange Point.
(3) These Terms of Service apply to all Participants as well as to the use of ports, VLANs, route servers and other supporting services of frankonIX.
(4) frankonIX is operated by handily networks GmbH (the "Operator").
Section 2 — Order of Precedence
In the event of conflicts between contractual documents, the following order of precedence applies (ascending; a higher number prevails):
- Acceptable Use Policy (AUP) / cross-cutting policies
- Framework agreement (these general terms and conditions)
- Product-specific terms and conditions / special conditions — including the annex "Reseller and Marketplace Terms of Service" (RMToS) pursuant to Section 7 and the Special Conditions for DDoS Scrubbing
- Service Level Agreement (SLA)
- Data Processing Agreement (Auftragsverarbeitungsvertrag, AVV) / NDA
- Individual order / order form
- Individually negotiated agreements (agreed between the parties in writing)
Section 3 — Description of Services
(1) The services provided by frankonIX include, but are not limited to:
Physical infrastructure
- Provision of peering ports based on SFP+, QSFP and QSFP28 Ethernet interfaces
Monitoring and statistics
- Provision of traffic data and other relevant operational and usage statistics via the IXP Manager
Additional services
- VLANs for private peering or transport services
- Route servers and RPKI support
- Access to routing tools and other supporting services
- Marketplace for arranging and ordering services from participating providers (see Section 7)
Open community
- frankonIX is open to Participants holding a valid Autonomous System Number (ASN) who wish to exchange BGP traffic within the Nuremberg metropolitan region
(2) The Operator provides the services on a best-effort basis. Unless a separate Service Level Agreement (SLA) has been agreed, there are no guaranteed availability, throughput or latency figures.
Section 4 — Conditions of Participation
(1) Participants must:
a) hold a valid Autonomous System Number (ASN), b) operate a functioning BGP configuration, c) hold valid entries in the RIPE database (or an equivalent RIR database), d) nominate a technical contact reachable within twenty-four (24) hours.
(2) The Operator reserves the right to reject applications for participation without stating reasons.
Section 5 — BGP Rules and Routing Requirements
(1) Participants may announce via frankonIX only those routes for which they are demonstrably authorised. Authorisation arises from:
a) their own IP prefixes registered with the competent RIR, or b) IP prefixes for which documented authorisation from the holder exists.
(2) RPKI obligation: Participants are required to create and maintain valid Route Origin Authorizations (ROAs) for all announced prefixes. The frankonIX route servers filter routes whose RPKI validation returns the state "Invalid".
(3) Prefix limits: The Operator sets maximum prefix limits for each Participant, which are configured on the respective port or BGP session. The following applies:
a) Default value: If the Participant does not specify otherwise, the Operator uses the prefix limits recorded in the Participant's PeeringDB record, separately for IPv4 and IPv6. b) Deviating values: Deviating values must be communicated to the Operator in text form (Textform) or via the IXP Manager and will be implemented as part of ordinary operations. c) Currency of data: The Participant is obliged to keep their PeeringDB entry up to date and plausible. If the number of announced prefixes is foreseeably going to exceed the configured limit, the Participant must notify the Operator in good time in advance. d) Missing or implausible values: If a PeeringDB entry is missing or the recorded value is manifestly implausible, the Operator is entitled to set an appropriate default value. The Operator will inform the Participant accordingly. e) Headroom: The Operator is entitled to configure an appropriate safety margin on top of the reported value in order to absorb short-term fluctuations. f) Exceeding the limit: If a Participant exceeds the configured prefix limit, the Operator may automatically reset the BGP session or disable the port.
(4) Route filtering: The frankonIX route servers apply the following filters:
a) filtering based on IRR databases (Internet Routing Registry), b) RPKI-based origin validation, c) filtering of bogon prefixes and reserved address ranges, d) filtering of default routes (0.0.0.0/0 and ::/0), e) filtering of prefixes longer (more specific) than /24 (IPv4) or /48 (IPv6) respectively.
(5) Participants peering bilaterally (without route servers) are themselves responsible for applying appropriate filtering rules.
Section 6 — Commercial Use and Carrier Services
(1) The sale of IP-based services via frankonIX is subject to restrictions in order to ensure the proper and fair operation of the Internet Exchange Point in the interest of all Participants.
(2) Participants intending to offer carrier or transit services via frankonIX must contact the Operator in advance.
(3) These restrictions concern in particular:
a) the provision of full internet routing tables (BGP full table, full feed or IP transit), b) the provision of selective BGP routes to tier-1 or tier-2 carriers (partial transit or partial feed), c) the commercial sale or brokerage of direct connections or cloud connectivity services.
Section 7 — Resale and Marketplace
(1) A Reseller within the meaning of these Terms of Service is any Participant who resells, brokers, subcontracts or offers as part of its own services, in whole or in part, services of frankonIX in its own name and/or for its own account to third parties (the "End Customers"). This covers in particular the sale of access to the peering LAN on the basis of the Participant's own physical port (Reseller) as well as the distribution of its own or third-party services on a VLAN basis via the Marketplace (Marketplace Reseller). The details are governed by the RMToS.
(2) The Marketplace is the platform provided by the Operator through which Participants may offer, request or obtain services from other Participants or third parties (e.g. cloud connectivity, transit, remote peering, virtual connections).
(3) Mandatory supplementary agreement: Where the Participant acts as a Reseller and/or uses the Marketplace, acceptance of the annex "Reseller and Marketplace Terms of Service" (the "RMToS") in its version applicable from time to time is a mandatory prerequisite for such use. Acting as a Reseller or using the Marketplace without validly accepted RMToS is not permitted.
(4) The RMToS are accepted in text form (Textform) or electronically via the customer portal or the IXP Manager. The Operator is entitled to withhold activation of the Reseller and Marketplace functions until valid acceptance.
(5) The RMToS supplement these Terms of Service. Within the scope of resale and the Marketplace they prevail over these Terms of Service in accordance with the order of precedence in Section 2; in all other respects these Terms of Service and the AUP remain unaffected.
(6) The Reseller remains the Operator's sole contractual partner. The Reseller is obliged:
a) to pass on the obligations arising from these Terms of Service and the AUP to its End Customers with identical content (back-to-back), b) to be answerable for compliance with these obligations by its End Customers as for its own conduct, c) to disclose the ASNs, prefixes and technical contacts of its End Customers upon the Operator's request and to keep them up to date in the IXP Manager, d) to comply with the technical requirements of the AUP, in particular the VLAN obligation (a separate VLAN assigned by the Operator for each service provided, no QinQ) pursuant to Section 1 paragraph (4) of the AUP as well as the nomination of one router MAC address per End Customer or per VLAN pursuant to Section 3 paragraph (5) of the AUP.
(7) End Customers of the Reseller acquire no direct claims against the Operator. No contractual relationship arises between the Operator and the End Customers.
(8) In the case of contracts concluded via the Marketplace between Participants and/or third parties, the Operator does not become a party to those contracts unless expressly agreed otherwise. The Operator merely provides the platform and gives no warranty as to the services, representations or solvency of the providers acting via the Marketplace.
(9) Breaches of the RMToS are deemed breaches of these Terms of Service and may be sanctioned pursuant to Section 9. In particular, the Operator is entitled to deactivate the Reseller and Marketplace functions.
(10) Section 16 paragraph (1) applies accordingly to amendments of the RMToS.
(11) Section 6 remains unaffected; the prior contact required under Section 6 paragraph (2) is not replaced by acceptance of the RMToS.
Section 8 — Obligations of Participants
(1) Participants are obliged:
a) to comply with the Acceptable Use Policy (AUP) of frankonIX in its version applicable from time to time, b) to report technical faults or anomalies to the Operator without undue delay, c) to keep their contact details and technical information (ASN, prefixes, NOC contact) up to date at all times, d) to notify the Operator in advance of changes to their BGP configuration that may affect IXP operations, e) where they act as a Reseller and/or use the Marketplace, to accept and comply with the RMToS pursuant to Section 7.
(2) Technical faults and support requests are to be directed to support@frankonix.net.
Section 9 — Breaches and Sanctions
(1) In the event of breaches of these Terms of Service, the AUP or the RMToS, the Operator reserves the following graduated measures:
a) Level 1 – Notification: The Participant is informed of the breach and requested to remedy it within a reasonable period. b) Level 2 – Restriction: In the event of a continued or repeated breach, the Operator may restrict the Participant's traffic (e.g. rate limiting, filtering of specific prefixes) or deactivate individual functions (e.g. the Marketplace). c) Level 3 – Suspension: In the event of serious or persistent breaches, the Operator may temporarily disable the Participant's port. d) Level 4 – Termination: In the event of particularly serious breaches or repeated failure to remedy, the Operator is entitled to terminate the contractual relationship extraordinarily and without notice.
(2) Where there is an immediate threat to the stability or security of the IXP infrastructure, the Operator is entitled to take immediate protective measures without prior notice, including the immediate deactivation of the affected port.
(3) The Operator will inform the Participant without undue delay of any measures taken and the reasons for them.
Section 10 — Liability
(1) The Operator is liable without limitation for damage arising from injury to life, body or health based on a negligent or intentional breach of duty by the Operator or its legal representatives or vicarious agents (Erfüllungsgehilfen), for damage covered by liability under the German Product Liability Act (Produkthaftungsgesetz), and for all damage based on intentional or grossly negligent breaches of contract as well as fraudulent intent (Arglist) on the part of the Operator or its legal representatives or vicarious agents.
(2) In the case of slightly negligent breach of material contractual obligations (Kardinalpflichten), the Operator's liability is limited to the foreseeable damage typical for this type of contract. Material contractual obligations are those whose fulfilment makes the proper performance of the contract possible in the first place and on whose observance the Participant may regularly rely.
(3) The Operator's liability for other damage caused by slight negligence is excluded.
(4) The Operator's total liability per damaging event is limited — with the exception of the cases set out in paragraph (1) — to the sum of the remuneration paid by the Participant for the affected service in the twelve (12) months preceding the event giving rise to the damage (liability cap).
(5) Liability for loss of profit, loss of data (insofar as not avoidable by reasonable data backup measures), indirect damage and consequential damage is excluded, with the exception of the cases set out in paragraph (1).
(6) The above limitations of liability also apply for the benefit of the Operator's legal representatives, vicarious agents and employees.
Section 11 — Indemnification
(1) Participants undertake to indemnify the Operator against all third-party claims arising from the Participant's use of the services of frankonIX, including reasonable costs of legal defence.
(2) Resellers shall additionally indemnify the Operator against all claims of their End Customers as well as against third-party claims arising from the use of the services by those End Customers or from the Reseller's use of the Marketplace.
(3) The indemnification obligation does not apply insofar as the Participant is not responsible for the underlying breach.
Section 12 — Data Protection and Monitoring
(1) In the course of operating the IXP, the Operator collects and processes technical metadata, in particular:
a) traffic statistics (aggregated volume data per port), b) BGP session data (peering status, number of announced prefixes), c) MAC addresses and VLAN assignments, d) sFlow/NetFlow data for capacity planning and abuse detection.
(2) This data is processed on the basis of the Operator's legitimate interest pursuant to Art. 6(1)(f) GDPR (operational security, capacity planning, abuse detection) and for the performance of the contract pursuant to Art. 6(1)(b) GDPR.
(3) Personal data of the Participant's contact persons (name, email, telephone) is processed for the performance of the contract and for communication. This applies accordingly to contact persons nominated or disclosed by a Reseller within the scope of Section 7; the Reseller shall ensure that such transfer is permissible under data protection law.
(4) Further information can be found in the Operator's privacy policy at www.handily.network.
Section 13 — Planned Maintenance
(1) The Operator is entitled to carry out planned maintenance. Planned maintenance will be announced to the Participant at least five (5) working days in advance by email or via the customer portal.
(2) Standard maintenance window: Tuesday and Wednesday, 02:00–06:00 CET/CEST. Maintenance outside this window will be announced separately.
(3) Periods of planned maintenance are not taken into account when calculating SLA availability, provided the announced duration is not exceeded.
(4) Emergency maintenance that cannot be deferred may be carried out without observing the advance notice period. The Operator will inform the Participant as early as possible.
Section 14 — Term and Termination
(1) Unless otherwise stipulated in the individual order or in the product-specific terms and conditions, the following applies:
a) Contracts for services in the price list are concluded with a minimum term of at least twelve (12) months. Minimum terms of 12, 24 or 36 months may be selected; the details and the associated tiering of setup fees are governed by the price list. b) Ordinary termination is possible with thirty (30) days' notice to the end of the month, at the earliest, however, as of the expiry of the agreed minimum term. c) After expiry of the minimum term, the contract continues for an indefinite period and may be terminated with the notice period stated under b). No automatic renewal for a further minimum term takes place.
(2) The right to extraordinary termination for good cause remains unaffected. Good cause exists in particular where:
a) a party breaches a material contractual obligation despite a warning and a reasonable grace period, b) insolvency proceedings are opened over the assets of a party or are rejected for lack of assets, c) a party makes a statutory declaration in lieu of an oath (eidesstattliche Versicherung) or enforcement measures are initiated against it.
(3) Notices of termination must be given in text form (Textform); email is sufficient.
(4) Upon termination of the contract, the Participant must return all allocated IXP resources (IP addresses, VLANs, route server configurations) within thirty (30) days. The Operator will disable the port after this period has expired.
(5) Reseller and Marketplace authorisations also end upon termination of the contract. The Reseller is obliged to inform its End Customers of the termination in good time; no claims of End Customers against the Operator arise as a result.
Section 15 — Force Majeure
(1) Neither party is liable for non-performance or delayed performance of its contractual obligations insofar as the non-performance or delay is due to circumstances beyond its reasonable control (force majeure).
(2) Force majeure includes in particular:
a) natural disasters (earthquakes, floods, storms, lightning strikes), b) epidemics and pandemics, c) war, terrorism, civil unrest, sabotage, d) cyber attacks that could not be repelled despite appropriate security measures, e) power outages or failures of public telecommunications networks not attributable to the Operator, f) failures of upstream suppliers or carriers, provided the Operator has for its part taken reasonable redundancy and contingency measures, g) official orders, changes in law, embargoes, sanctions, h) strikes, lockouts (including at third parties).
(3) The affected party shall inform the other party in text form (Textform) without undue delay, and at the latest within three (3) working days, of the occurrence and the expected duration of the event. It shall make all reasonable efforts to minimise the effects of the event.
(4) If the force majeure event lasts longer than ninety (90) consecutive calendar days, either party is entitled to terminate the affected contract extraordinarily with thirty (30) days' notice to the end of the month. Services already rendered and used shall be remunerated on a pro rata basis.
(5) Planned maintenance by the Operator or its suppliers does not constitute force majeure.
Section 16 — Final Provisions
(1) Amendments and supplements to these Terms of Service must be made in text form (Textform). The Operator is entitled to amend these Terms of Service and the RMToS with six (6) weeks' notice. If the Participant does not object within four (4) weeks of receipt of the notice of amendment, the amendments are deemed accepted.
(2) The law of the Federal Republic of Germany applies exclusively, to the exclusion of the UN Convention on Contracts for the International Sale of Goods (CISG).
(3) The place of jurisdiction for all disputes arising from or in connection with these Terms of Service is — insofar as legally permissible — Nuremberg.
(4) Should individual provisions of these Terms of Service be or become wholly or partially invalid or unenforceable, the validity of the remaining provisions shall not be affected. In place of the invalid or unenforceable provision, the valid and enforceable provision shall be deemed agreed whose effects come closest to the economic objective pursued by the parties with the invalid or unenforceable provision.
(5) The transfer of rights and obligations under this contract to third parties requires the prior written consent of the other party.
Annexes
- Acceptable Use Policy (AUP) — frankonIX
- Reseller and Marketplace Terms of Service (RMToS) — binding for Resellers and Marketplace users pursuant to Section 7
- Special Conditions for DDoS Scrubbing — binding for Participants who have booked the premium feature
Contact
Operator: handily networks GmbH Support: support@frankonix.net General: support@handily.network
Version: July 2026 · document version 2.1