Acceptable Use Policy (AUP) — 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

This Acceptable Use Policy (AUP) sets out the technical and organisational rules for using the frankonIX infrastructure. Breaches of this AUP may lead to restrictions, suspension or termination of participation in accordance with the frankonIX Terms of Service (ToS).

This AUP is aligned with common industry best practices as applied, among others, by Euro-IX and comparable Internet Exchange Points.

Section 1 — Permitted Use

(1) The port provided may be used exclusively for the exchange of IP traffic (peering).

(2) Permitted Ethernet frame types: Only the following Ethernet frame types may be used:

a) 0x0800 — IPv4, b) 0x0806 — ARP (for IPv4 address resolution only), c) 0x86DD — IPv6.

(3) All other Ethernet frame types are not permitted and are filtered by the Operator. The following are expressly not permitted:

a) 802.1Q-tagged frames (VLAN tagging) on the peering port, unless expressly agreed, b) MPLS frames (0x8847, 0x8848), c) PPPoE frames (0x8863, 0x8864), d) all other protocols not explicitly permitted.

(4) VLAN obligation for resale and Marketplace: Where the Participant acts as a Reseller or uses the Marketplace to distribute services to other participants (end peers), this may be done exclusively via separate VLANs assigned by the Operator. In detail:

a) One VLAN per service: Exactly one (1) additional VLAN ID assigned by the Operator must be used for each individual service provided. Using the same VLAN ID for more than one service is not permitted. b) Applies also to several services to the same end peer: The rule under (a) applies irrespective of whether the services are provided to different end peers or to the same end peer. If, for example, the Reseller or Marketplace participant distributes two BGP sessions to the same end peer, two separate VLANs must be booked; if a backup service (e.g. a backup VLAN) is additionally provided, a further, third VLAN must be booked. The same applies accordingly to every further service. c) Assignment: VLAN IDs are assigned exclusively by the Operator. Choosing or changing VLAN IDs unilaterally, as well as passing assigned VLAN IDs on to third parties, is not permitted. Booking takes place via the customer portal or the IXP Manager, or by support ticket. d) No QinQ: The use of QinQ or VLAN stacking (IEEE 802.1ad, double-tagged frames) within or above the assigned VLANs is not permitted. Within an assigned VLAN, only the Ethernet frame types permitted under paragraph (2) are allowed. e) The assignment of a VLAN under this paragraph is deemed an express agreement within the meaning of paragraph (3)(a). In all other respects, the use of tagged frames remains impermissible. f) VLANs that are no longer required must be reported to the Operator for return without undue delay.

Section 2 — Unicast Requirement and Traffic Restrictions

(1) Only unicast traffic may be transmitted via the peering port.

(2) The following traffic types are not permitted on the peering LAN:

a) Broadcast: No IP broadcast other than ARP requests strictly necessary for address resolution, b) Multicast: No IP multicast unless expressly approved by the Operator, c) Proxy ARP: The use of proxy ARP is expressly prohibited, d) Gratuitous ARP: Gratuitous ARP packets are permitted only for the IP addresses assigned to the Participant, e) DHCP: No operation of a DHCP server on the peering LAN, f) Spanning tree (STP/RSTP/MSTP): No spanning tree BPDUs, g) Discovery protocols: No CDP, LLDP, MNDP or comparable protocols unless requested by the Operator.

Section 3 — MAC Addresses

(1) Exactly one (1) MAC address is permitted per physical port, unless expressly agreed otherwise with the Operator.

(2) For LAG connections (link aggregation), one (1) MAC address is permitted per LAG group.

(3) The MAC address used must be communicated to the Operator upon port setup or upon any change, without undue delay, and recorded in the IXP Manager database.

(4) The Operator is entitled to use MAC address filters (port security). Frames with unregistered MAC addresses may be discarded without prior notice.

(5) Resellers and Marketplace participants: Where the Participant, acting as a Reseller or Marketplace participant, carries several End Customers over its port — that is, where several End Customers obtain their peering access to frankonIX via that Participant's port — the following applies in addition:

a) For each individual End Customer, or for each VLAN assigned under Section 1 paragraph (4), exactly one (1) router MAC address must be nominated to the Operator, namely the MAC address of the End Customer router peering via the respective VLAN. b) The nomination is made via the IXP Manager before the respective service goes into operation. Changes must be communicated in advance, or at the latest without undue delay, and recorded in the IXP Manager. c) To that extent a deviation from paragraph (1) is deemed expressly agreed; per assigned VLAN, exactly one (1) MAC address remains permitted. d) Paragraph (4) applies accordingly per VLAN: frames with unregistered MAC addresses may be discarded without prior notice. e) The Reseller remains responsible towards the Operator for the accuracy and currency of the MAC addresses reported for its End Customers.

Section 4 — Broadcast Storm Protection

(1) The Operator implements broadcast storm control mechanisms to protect the peering platform as a whole.

(2) If the broadcast or multicast traffic of a Participant port exceeds a threshold determined by the Operator, the port may be automatically rate-limited or temporarily disabled.

(3) The Participant is obliged to configure its own network in such a way that no excessive broadcast or multicast traffic enters the peering LAN.

Section 5 — IPv6 Requirements

(1) frankonIX supports both IPv4 and IPv6 as equivalent protocols on the peering LAN.

(2) Participants are encouraged to set up IPv6 peering in addition to IPv4 peering.

(3) The same rules apply to IPv6 peering as to IPv4, in particular with regard to RPKI, route filtering and prefix limits.

(4) Neighbor Discovery Protocol (NDP) for IPv6 is permitted only for the IPv6 addresses assigned to the Participant. Router Advertisements (RA) by Participants on the peering LAN are not permitted.

Section 6 — BGP Requirements

(1) Participants must use BGP-4 (RFC 4271) for the exchange of routing information.

(2) RPKI obligation: All announced prefixes must have valid ROAs (Route Origin Authorizations). Routes with the RPKI state "Invalid" are discarded by the route servers.

(3) Best Current Practices (BCP): Participants are obliged to comply with the following BCPs:

a) BCP38 / RFC 2827 (Network Ingress Filtering): Participants must ensure that no traffic with forged source addresses (spoofing) is sent via the IXP port. b) BCP84 / RFC 3704 (Ingress Filtering for Multihomed Networks): Participants with several upstream providers must implement appropriate anti-spoofing measures.

(4) Participants may not use IP addresses as next hop on the frankonIX peering LAN that have not been assigned to the Participant by the Operator.

(5) The use of static routes pointing to IP addresses of the peering LAN is permitted only for bilaterally agreed peering.

Section 7 — Prohibited Use

(1) In particular, the infrastructure may not be used for:

a) unlawful, abusive or harmful purposes, b) activities that impair the integrity, security or availability of the Internet Exchange infrastructure, c) any conduct that leads to operational disruption, instability or an increased risk for other Participants, d) IP spoofing or sending traffic with forged source IP addresses, e) carrying out DDoS attacks or knowingly forwarding attack traffic, f) intercepting, recording or manipulating the traffic of other Participants, g) operating open resolvers (DNS, NTP, SNMP) on the peering LAN.

Section 8 — Transceivers and Modules

(1) The transceiver modules used on the Operator's switch side are provided and operated exclusively by the Operator.

(2) The Participant equips its own end of the link only. In doing so, it must fit a module matching the specification agreed for its port.

(3) Introducing Participant-owned transceiver modules into the Operator's infrastructure is not provided for. Modules are not shipped to the points of presence.

(4) The Operator works with single-mode fibre exclusively. Multi-mode is not supported.

(5) The Operator publishes the supported module types and their specifications; they are available via the customer portal.

(6) Contact: support@frankonix.net

Section 9 — Commercial IP Services

(1) The sale of IP-based services via frankonIX is subject to restrictions in order to ensure proper operation in the interest of all Participants.

(2) Participants intending to offer services as an IP carrier via frankonIX must contact the Operator in advance.

(3) This concerns 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 distribution or brokerage of direct connections or cloud connectivity services.

Section 10 — Resale and Marketplace

(1) Mandatory supplementary agreement: Where the Participant acts as a Reseller (resale, brokerage or incorporation of frankonIX services vis-à-vis End Customers) and/or uses the Marketplace, it must accept the annex "Reseller and Marketplace Terms of Service" (RMToS) in its version applicable from time to time. The details are governed by Section 7 of the Terms of Service (ToS).

(2) Without validly accepted RMToS, use of the Reseller and Marketplace functions is not permitted; the Operator may block such functions technically.

(3) All provisions of this AUP continue to apply unchanged to Resellers and to their End Customer traffic. The Reseller ensures that the End Customer traffic carried over its port meets the requirements of Sections 1 to 7.

(4) The Reseller records the ASNs, prefixes and technical contacts of its End Customers in the IXP Manager and keeps this information up to date.

(5) Breaches by End Customers of a Reseller are deemed breaches by the Reseller and are dealt with under Section 13 of this AUP and Section 9 of the ToS.

(6) For technical implementation, the VLAN obligation under Section 1 paragraph (4) applies in particular — a separate VLAN assigned by the Operator for each service, no QinQ — as does the obligation to nominate one router MAC address per End Customer or per VLAN under Section 3 paragraph (5). Any deviating configurations beyond this require express prior agreement with the Operator.

Section 11 — Operational and Service Notes

(1) The exchange of traffic between the frankonIX points of presence is provided, as a matter of principle, without any guarantee as to:

a) availability, b) throughput, c) latency.

(2) Where a separate Service Level Agreement (SLA) has been agreed, its provisions apply.

Section 12 — Faults and Reporting

(1) Technical faults or anomalies must be reported to the Operator without undue delay.

(2) Contact: support@frankonix.net

Section 13 — Sanctions for Breaches

(1) In the event of breaches of this AUP, the Operator proceeds according to the following graduated catalogue of measures:

a) Notification: The Participant is informed of the breach and requested to remedy it within a reasonable period (as a rule 24 hours for technical breaches, 5 working days for organisational breaches). b) Rate limiting / filtering: In the event of a continued breach or of traffic-based breaches, the Operator may rate-limit or filter the affected traffic. c) Port deactivation: In the event of serious or repeated breaches, the Operator may temporarily disable the Participant's port. d) Termination of contract: In the event of particularly serious or repeated breaches, the contractual relationship may be terminated extraordinarily in accordance with the ToS.

(2) Where there is an immediate threat to platform stability (e.g. broadcast storm, massive spoofing, BGP hijacking), the Operator is entitled to disable the affected port immediately and without prior notice.

(3) A disabled port is reactivated only after the breach has been remedied and confirmed by the Participant.

(4) In the event of breaches in connection with resale or the Marketplace, the Operator may additionally deactivate the Participant's Reseller and Marketplace functions.

Section 14 — Compliance

(1) Participants are obliged to comply with all technical requirements and guidelines under this Acceptable Use Policy, the Terms of Service (ToS) and — where applicable — the Reseller and Marketplace Terms of Service (RMToS).

(2) The Operator is entitled to monitor compliance with this AUP by appropriate technical means (e.g. MAC filtering, traffic analysis, prefix monitoring).

Contact

Operator: handily networks GmbH IXP support: support@frankonix.net General support: support@handily.network