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 4.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. 3C1B IX Route Sharing (RS3)

This service will be available soon.

RS3 is a third route server operated on the RegPEX infrastructure, established to distribute — free of charge — the routes that 3C1B (AS6823) learns from its external IX fabrics to RegPEX members.

3.1 Service Model

• RS3's ASN is AS199911 — like RS1 and RS2, it operates under the RegPEX route server ASN. 3C1B (AS6823) is a participant that provides routes to RS3; members open eBGP sessions to RS3 (AS199911) and observe AS6823 in the AS-path.
• Asymmetric flow: RS3 distributes 3C1B's IX-learned routes to members; routes received from members are forwarded only to 3C1B and are not advertised to other members.
• Member → 3C1B → external IXs: If a member announces its own prefixes to RS3, 3C1B may re-advertise those prefixes to its IX peerings, allowing the member's traffic to reach 3C1B's IX peers.
• Relationship with RS1/RS2: RS1 and RS2 are for member↔member peering; RS3 is for member↔3C1B route sharing. The three RSs operate independently and do not feed each other.

3.2 Eligibility and Activation

• Connecting to RS3 is optional — a separate BGP session is opened on request.
• For connection details see Technical Requirements §6.1.
• Activation request: peering@regpex.tr — include "RS3 activation request" and ASN in the subject line.

3.3 Route Sources and Community Tagging

• Every route entering RS3 is tagged with communities carrying source-IX information.
• The community scheme is defined in BGP Large Community Policy §5.
• IX sources are identified by PeeringDB IX IDs; the community list is automatically updated when new IXs are added.

3.4 Member Obligations

• Routes received from RS3 may not be re-advertised to the member's own transit relationships; no-export is mandatory.
• Members may only announce prefixes belonging to their own ASN to RS3.
• 3C1B makes no guarantee regarding the content, scope, or continuity of announced routes; changes in peering relationships may affect the advertised route set.

3.5 Service Continuity and Changes

• 3C1B reserves the right to terminate all or part of the RS3 service; policy changes are announced 60 days in advance.
• Addition or removal of individual IX sources may be applied without the 60-day notice period; such changes are published on the BGP Large Community Policy page.

4. Route Server Usage Rules

4.1 Route Announcement Rules

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

4.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.
• RS3 transit communities — applied to RS3 routes only, carrying source IX and region metadata.

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

4.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

5. Member Obligations

5.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

5.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

6. 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

7. Violations and Sanctions

The following process applies to peering policy violations:

Emergency action — In cases threatening network security (e.g., routing hijacks, abuse, DDoS), RegPEX reserves the right to disable a port without prior notice.

8. 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)

9. Contact

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