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 BGP sessions between each other:
- 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 facilitation — RegPEX provides connectivity via the peering VLAN and maintains current contact information on PeeringDB
- Peering VLAN — Bilateral peering is permitted over the RegPEX peering fabric
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:
| Requirement | Description |
|---|---|
| Own/Customer routes only | Only routes belonging to the member's own autonomous system or its downstream customers may be announced |
| Valid IRRDB | All announced routes must have valid IRRDB records (RIPE, ARIN, APNIC, etc.) |
| RPKI Invalid rejected | Routes marked as RPKI Invalid are automatically rejected by the route server |
| No default route | Default routes (0.0.0.0/0 or ::/0) are not permitted |
| No bogons | Bogon prefixes and private/reserved address space (RFC 1918, RFC 6598, etc.) are prohibited |
| Max-prefix limits | Prefix limits are enforced per member based on AS-SET and registered prefix information |
3.2 BGP Community Support
The RegPEX route server supports the following BGP communities for traffic control:
| Community | Description |
|---|---|
RS:0:peer_as |
Announce route to the specified peer AS |
RS:1:peer_as |
Announce route only to the specified peer AS (exclusive) |
RS:0:0 |
Do not announce route to any peer |
RS:1:0 |
Announce route to all peers (default behaviour) |
RS:101:0 |
Prepend AS once for all peers |
RS:102:0 |
Prepend AS twice for all peers |
RS:103:0 |
Prepend AS three times for all peers |
3.3 Filtering Layers
RegPEX route servers apply the following filtering layers in order:
- RPKI — Route Origin Authorization validation (Valid, Unknown, Invalid)
- IRRDB — AS-SET and route object validation against Internet Routing Registries
- Bogon — Filtering of invalid, reserved, and unallocated prefix ranges
- Max-Prefix — Enforcement of per-AS prefix limits to prevent excessive announcements
- 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:
| Stage | Action |
|---|---|
| Warning | First violation: written warning issued to the member |
| Temporary suspension | Repeated violations: port may be temporarily disabled |
| Permanent termination | Serious or sustained violations: membership may be terminated |
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.net
- NOC: noc@regpex.net
- General inquiries: info@regpex.net