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.

2. Peering Types

2.1 Multilateral Peering (Route Server Based)

RegPEX offers multilateral peering through its route server infrastructure:

• 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 standard BGP communities for granular traffic control (see Section 3.2)

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. Route Server Usage Rules

3.1 Route Announcement Rules

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

3.2 BGP Community Support

The RegPEX route server supports the following BGP communities for traffic control:

RegPEX also attaches informational location communities to all accepted routes covering three dimensions:

These communities can be used for traffic engineering. For the full list, POP/city ID mappings 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)
• 24/7 NOC contact — Members must maintain 24/7 reachability for RegPEX NOC (contact details must be kept current)

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 — 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

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

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.

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

8. Contact

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