RegPEX Peering Policy

1. Introduction

This document defines the rules, conditions, and technical requirements governing peering conducted over the RegPEX (Regional Peering Exchange) infrastructure.

RegPEX operates as a carrier-neutral Internet Exchange Point (IXP), facilitating efficient and reliable traffic exchange among its members. The policy ensures consistent, secure, and transparent peering practices across the exchange. The operating entity (3C1B Telekomünikasyon A.Ş.) is also a founding member and inter-POP carrier; these multiple roles and the associated neutrality safeguards are detailed in the Functional Independence and Neutrality Policy.

2. Peering Types

2.1 Multilateral Peering (Route Server Based)

RegPEX offers multilateral peering through its route server infrastructure (RS1 and RS2):

• BIRD2-based route server — RegPEX operates route servers built on the BIRD2 routing daemon
• Free of charge — Route server peering is available to all members at no additional cost
• RPKI + IRRDB filtering — All route announcements are validated against RPKI (Route Origin Authorizations) and IRRDB (Internet Routing Registry Database) records
• BGP community support — Members may use BGP Large Communities for granular traffic control (see Section 3.2)
• Dual-stack — separate BGP sessions for IPv4 and IPv6

Multilateral peering establishes automatic BGP sessions between participating members via the route server, reducing operational overhead compared to establishing numerous bilateral sessions.

2.2 Bilateral Peering

Members may establish direct point-to-point BGP sessions over the RegPEX peering LAN (via peering IP addresses). Each participant is allocated its own connection VLAN; participant VLANs are joined in the RegPEX peering LAN, where peering IPs, route server sessions and bilateral BGP sessions reside:

• Direct BGP — Point-to-point BGP sessions between members without route server mediation
• Member-managed — Bilateral peering arrangements are entirely managed by the involved members; RegPEX does not participate in session configuration or route policy
• RegPEX facilitation — RegPEX provides connectivity to the peering LAN and maintains current contact information on PeeringDB

2.3 Private VLAN (Same-Location Dedicated Interconnect)

Two members connected at the same RegPEX POP may request a dedicated Private VLAN between them. This service provides an exclusive Layer 2 segment, independent of the shared route server fabric, over which a bilateral BGP session can be established.

Conditions:

• Both parties must be active RegPEX members.
• Both member ports must be in the same RegPEX POP location (same-city requirement). Private VLAN extension across different POPs is not offered.
• Traffic on the private VLAN must remain within each member's existing port capacity; a port upgrade is required if capacity would be exceeded.
• Since all ports operate in trunk mode, the private VLAN rides the same physical fibre as the member's connection VLAN; no additional cross-connect is needed.

Operation:

• IP addressing, BGP configuration, and routing policy within the private VLAN are entirely the members' responsibility.
• RegPEX provides no route server, filtering, or monitoring service on the private VLAN.
• Multiple private VLANs may be assigned to a single port, subject to port capacity.
• Request via peering@regpex.tr — include both ASNs and POP location in the subject line.

2.4 Open Peering Condition (Participants Receiving an Incentive)

RegPEX aims to build an open peering community in Türkiye. A participant that benefits from an incentive under Annex 5 of the Participation Agreement is expected to do one of the following:

• maintain an established BGP session, announcing prefixes, with at least one RegPEX route server in at least one address family (IPv4 or IPv6), or
• accept bilateral peering requests sent by e-mail to the peering contact address listed on RegPEX within ten (10) business days of the request date.

If a participant does not meet this condition, RegPEX gives written notice stating the condition and its basis. If the participant meets the condition within thirty (30) days of the notice, the incentive continues; otherwise the incentive ends and the standard tariff applies. This condition does not restrict the participant's freedom to peer or not to peer; it is a condition of the incentive only.

This section is informational. The binding text is Annex 5, Article 4.5 of the Participation Agreement; in case of conflict Annex 5 prevails. For amounts see Pricing.

3. Route Server Usage Rules

3.1 Route Announcement Rules

Members connecting to the RegPEX route servers must comply with the following route announcement requirements:

3.2 BGP Community Support

The RegPEX route servers support the following community families:

• Action communities — member-controlled, for targeting route advertisement and applying AS prepend.
• Informational communities — assigned by the route server, carrying POP/city/country metadata about the originating member.

For the full list of values and usage examples, see BGP Large Community Policy.

3.3 Filtering Layers

RegPEX route servers apply the following filtering layers in order:

1. RPKI — Route Origin Authorization validation (Valid, Unknown, Invalid)
2. IRRDB — AS-SET and route object validation against Internet Routing Registries
3. Bogon — Filtering of invalid, reserved, and unallocated prefix ranges
4. Max-Prefix — Enforcement of per-AS prefix limits to prevent excessive announcements
5. AS-Path — Detection and filtering of invalid or malformed AS path structures

4. Member Obligations

4.1 Technical Obligations

• BGP configuration — Members are responsible for correct BGP configuration on their own router/switch equipment
• Unicast only — Only unicast IPv4 and IPv6 traffic is permitted on the peering port
• No proxy ARP/DHCP/STP — Proxy ARP, DHCP relaying, Spanning Tree Protocol, and other Layer 2 broadcast protocols are prohibited
• Single MAC — Each member may use a maximum of one (1) MAC address (additional MAC addresses require prior approval)
• NOC contact — Members must notify and keep current a NOC contact point reachable during business hours and the contact details of an on-call engineer outside business hours

4.2 Operational Obligations

• PeeringDB updated — PeeringDB records must be kept current at all times
• NOC details — Email and phone contact information must be accurate and accessible
• Planned maintenance (participant) — Participants are asked to notify the RegPEX NOC of their own planned maintenance in advance; the Participation Agreement sets no notice period for this
• Planned maintenance (RegPEX) — RegPEX performs planned maintenance as a rule between 02:00 and 06:00 local time and gives at least five (5) business days' written notice to the technical contact designated by the participant; for emergency maintenance this may be reduced to four (4) hours (Agreement Annex 4.3)
• Security incidents — Security events affecting the peering environment must be reported to RegPEX NOC immediately

5. RegPEX Obligations

RegPEX commits to the following:

• MANRS compliance — Route server operations conform to Mutually Agreed Norms for Routing Security (MANRS)
• High availability (HA) — Peering infrastructure is designed and operated for high availability
• Transparent statistics — Member traffic statistics are provided transparently via the member portal
• PeeringDB maintenance — RegPEX maintains current exchange information on PeeringDB
• Advance notice — Network changes affecting members are communicated in advance where practicable

6. Violations and Sanctions

Note: This page is a summary; in case of conflict, the signed Annex 2.6 and Annex 4.3 prevail.

In case of non-compliance, intervention follows Participation Agreement Annex 2.6:

A Tier 1 intervention may be applied without prior notice in order to protect the integrity of the platform. The OPERATOR notifies the PARTICIPANT in writing of the reason for the intervention and its technical basis within twenty-four (24) hours (Participation Agreement Annex 2.6).

7. Policy Changes

The notice periods in the Participation Agreement take precedence over this policy:

• Any fee change to a participant's disadvantage is published and notified in writing at least three (3) months before it takes effect (Agreement Article 8.7, Annex 5 Article 10)
• Updates to the BGP community scheme are announced thirty (30) days in advance (Annex 2)
• Technical changes are announced with the notice periods set out in Annexes 2 and 3; if a POP is removed, affected participants receive at least ninety (90) days' written notice
• Other changes to this policy are announced via the RegPEX website and the participant e-mail distribution list
• Security exceptions — Changes addressing critical security issues may be implemented immediately (Agreement Article 7A)

8. Contact

• Peering requests: peering@regpex.tr
• NOC: noc@regpex.tr
• General inquiries: info@regpex.tr