This document defines the permitted and prohibited uses of the RegPEX peering fabric and associated services. All Members must comply with this policy as a condition of participation.
1. Permitted Use
The following uses of the RegPEX infrastructure are expressly permitted:
| Category | Details |
|---|---|
| IPv4/IPv6 Unicast | Exchange of unicast IPv4 and IPv6 traffic between peering parties |
| BGP | BGP-4 and MP-BGP for routing table exchange |
| ICMP | Internet Control Message Protocol for connectivity testing |
| BFD | Bidirectional Forwarding Detection for fast failure detection |
2. Prohibited Use — Traffic
The following traffic and behavior are prohibited on the RegPEX fabric:
| Prohibition | Description |
|---|---|
| Transit | Providing transit (access to third networks) to, or obtaining transit from, another PARTICIPANT over RegPEX; for this purpose giving or receiving a default route, a full routing table, or routes other than the prefixes of the PARTICIPANT itself and of its customers. A PARTICIPANT announcing its own customers' prefixes, bilateral BGP sessions and peering via the route server are outside this prohibition. What is restricted is the use of the RegPEX platform for transit traffic; providing transit services to the PARTICIPANT's own customers outside RegPEX is not restricted (Participation Agreement Annex 2.5 and 2.7) |
| Private carriage of traffic | Use of the RegPEX infrastructure, outside the shared peering broadcast domain, as a Layer-2 connection dedicated between two points (including POPs) or specific PARTICIPANTs (point-to-point transport, private VLAN, closed circuit). Bilateral peering over the shared peering broadcast domain is not private carriage; however, a PARTICIPANT's carrying its own traffic between its own connection points (including its ports at different POPs) over the shared broadcast domain is also private carriage. The OPERATOR does not offer private VLAN or point-to-point transport services on RegPEX (Participation Agreement Annex 2.7) |
| Default Route | No advertisement of default (0.0.0.0/0 or ::/0) routes |
| Proxy ARP/NDP | No proxy ARP or Neighbor Discovery Proxy |
| DHCP | No DHCP server or relay services |
| STP | No Spanning Tree Protocol or similar layer-2 loop-prevention protocols |
| Broadcast Storm | No excessive broadcast, multicast, or unknown-unicast flooding |
| MAC Flooding | No MAC address table exhaustion attacks |
3. Prohibited Use — Security
The following security-related activities are strictly prohibited:
| Prohibition | Description |
|---|---|
| IP Spoofing | No transmission of traffic with forged source IP addresses |
| ARP Spoofing | No ARP cache poisoning or spoofed ARP/NDP advertisements |
| DDoS | No participation in or origination of distributed denial-of-service attacks |
| Port Scanning | No unauthorized port scanning or reconnaissance against other Members |
| Unauthorized Access | No attempts to gain unauthorized access to systems or networks |
| BGP Hijacking | No advertisement of routes for address space not legitimately assigned to the advertiser |
4. Legal Compliance
All Members must comply with applicable laws, including:
- Turkish Law — Full compliance with Turkish legislation governing telecommunications and data communications
- Copyright — No transmission of infringing or pirated content
- Spam — No unsolicited bulk messaging; compliance with anti-spam regulations
5. Ethernet Frame Requirements
Frame Size
| Type | Size |
|---|---|
| Standard | 64–1500 bytes |
| Jumbo | Up to 9000 bytes (where explicitly supported) |
Allowed EtherTypes
| EtherType | Protocol |
|---|---|
| 0x0800 | IPv4 |
| 0x86DD | IPv6 |
| 0x0806 | ARP |
VLAN Restrictions
- 802.1Q — No 802.1Q tagged frames on access ports; untagged/access mode only unless otherwise agreed
6. BGP Security Requirements
Members must implement the following BGP security measures:
| Requirement | Description |
|---|---|
| MD5 / TCP-AO | Session authentication using MD5 or TCP-AO |
| GTSM | Generalized TTL Security Mechanism (recommended) |
| max-prefix | Prefix limit configured as per RegPEX guidelines |
| Graceful Restart | Graceful restart capability recommended |
7. Monitoring
RegPEX monitors the peering fabric for operational and security purposes:
| Aspect | Policy |
|---|---|
| sFlow / NetFlow | Traffic sampling may be used for aggregate statistics |
| Aggregate Only | Sampled data is used for aggregate statistics and platform security; it is not used for charging |
| No Content Inspection | RegPEX does not inspect payload content. Transit and private-carriage reviews rely only on route-server data and the header fields of sampled flow data (MAC addresses, ethertype, IP addresses and prefixes, byte counts) |
| Indicators | Transit and private-carriage indicators only initiate a review and warning; they are not in themselves a breach and do not give rise to automatic sanctions. The PARTICIPANT's explanation is taken into account in the review, and this warning is not one of the intervention tiers in Annex 2.6 (Participation Agreement Annex 2.7) |
8. Breach Procedure
Intervention Tiers (Participation Agreement Annex 2.6)
| Tier | Situation | Intervention | Notice |
|---|---|---|---|
| 1 | Active threat to platform integrity (loop, broadcast storm, DDoS-driven flooding) | Immediate suspension of the port | Simultaneously or immediately afterwards |
| 2 | Technical rule breach that does not pose a threat | Written warning, five (5) business days to cure | In advance |
| 3 | Uncured breach | Suspension of the port | In advance |
| 4 | Repeated or serious breach | Termination of the Agreement | In accordance with the provisions of the main Agreement |
Emergency Rights
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).
For transit or private carriage, the indicators do not in themselves give rise to a sanction. If a breach is proven in the review, the tiers in Annex 2.6 apply: as a rule starting with Tier 2 (written warning, five business days to cure); if not cured, Tier 3 (suspension), and if repeated or serious, Tier 4 (termination — main Agreement Article 10.3). If the breach poses an active threat to platform integrity, Tier 1 and main Agreement Article 7A apply (Participation Agreement Annex 2.7).
Abuse Reporting
Report suspected policy breaches to: peering@regpex.tr or call +90 (312) 988 00 00
This policy is subject to change. Members will be notified of material updates in advance.