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 shared VLAN 100 peering fabric:

• 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 via VLAN 100 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 VLAN 100; 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.

3C1B Free Route Announcement Commitment:

To enhance the value of the private VLAN service and provide additional connectivity options to RegPEX members, 3C1B Telekomünikasyon A.Ş. makes the following commitment:

When any RegPEX member establishes a private VLAN connection with 3C1B, 3C1B will announce, free of charge, the routes it learns from its own IX fabric participations and its established private peering relationships to that member. This announcement:

• Is activated on member request; it is disabled by default.
• Does not cover 3C1B's own transit or upstream connections — only routes learned from IX fabrics and bilateral peerings in which 3C1B participates.
• No-export is mandatory — the member may not re-announce these routes to its own downstream networks or any third party.
• 3C1B makes no guarantee regarding the content, scope, or continuity of announced routes; changes in peering relationships may affect the route set.
• This service incurs no additional charge; its continuation is at 3C1B's discretion and any change in this policy will be announced with 60 days' notice.

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 operates under AS6823 (3C1B) — unlike RS1 and RS2, it is not announced under the RegPEX AS. Members open eBGP sessions to RS3 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)
• 24/7 NOC contact — Members must maintain 24/7 reachability for RegPEX NOC (contact details must be kept current)

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 — At least 72 hours advance notice to RegPEX NOC for planned maintenance
• 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

• Changes to this policy are announced at least 30 days in advance
• Notifications are sent via the RegPEX website and member email distribution list
• Security exceptions — Changes addressing critical security issues may be implemented immediately

9. Contact

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