RegPEX Peering Politikası

1. Giriş

Bu belge, RegPEX (Regional Peering Exchange) altyapısı üzerinden gerçekleştirilen peering (eşleme) işlemlerinin kurallarını, koşullarını ve teknik gereksinimlerini tanımlar.

RegPEX, tüm üyelere eşit ve ayrımcı olmayan koşullarda hizmet sunan bir Internet Exchange Point (IXP) olarak faaliyet göstermektedir. RegPEX'i işleten tüzel kişi (3C1B Telekomünikasyon A.Ş.), aynı zamanda kurucu üye ve inter-POP taşıyıcısı konumundadır. Bu çok rollü yapı ve tarafsızlık güvenceleri İşlevsel Bağımsızlık ve Tarafsızlık Politikası belgesinde ayrıntılı olarak açıklanmaktadır.

2. Peering Türleri

2.1 Multilateral Peering (Route Server)

RegPEX, BIRD2 tabanlı route server hizmeti sunar (RS1 ve RS2).
Route server üzerinden yapılan peering, tüm katılımcı üyeler arasında otomatik BGP oturum kurulumunu sağlar.
Route server kullanımı ücretsizdir ve tüm üyelere açıktır.
Route server'lar RPKI doğrulaması ve IRRDB filtreleme uygular.
Üyeler, route server üzerinden belirli peer'lara community tag'leri ile trafik kontrolü yapabilir.
IPv4 ve IPv6 için ayrı BGP oturumları kurulur (dual-stack).

2.2 Bilateral Peering

Üyeler, RegPEX peering LAN'ı üzerinde (peering IP adresleri aracılığıyla) doğrudan (point-to-point) BGP oturumu kurabilir; bu düzenleme tamamen üyeler arasında yürütülür.
Her katılımcıya kendi bağlantı VLAN'ı tahsis edilir; katılımcı VLAN'ları RegPEX peering LAN'ında birleşir. Peering IP'leri, route server oturumları ve ikili BGP oturumları bu peering LAN üzerindedir.
RegPEX, bilateral peering için PeeringDB üzerinden güncel iletişim bilgilerini sağlar.
Bilateral BGP oturumunun kurulması, idamesi ve rota politikaları üyelerin sorumluluğundadır.

2.3 Private VLAN (Aynı Lokasyonda İkili Özel Bağlantı)

Aynı RegPEX POP'unda bağlı iki üye, birbirleriyle münhasır bir private VLAN tahsisi talep edebilir. Bu hizmetin esas amacı, route server fabric'ından bağımsız, ikili ve özel bir katman-2 segment üzerinde bilateral BGP session kurulmasına imkân vermektir.

Koşullar:

Her iki tarafın aktif RegPEX üyesi olması zorunludur.
Her iki üye portu aynı RegPEX POP lokasyonunda bulunmalıdır (aynı il koşulu). Farklı POP'lar arası private VLAN extend hizmeti sunulmaz.
Private VLAN trafiği, her üyenin mevcut port kapasitesi içinde kalmalıdır; kapasite aşımı halinde port yükseltimi gerekir.
Port'lar trunk modda çalıştığından private VLAN, üyenin bağlantı VLAN'ı ile eş zamanlı taşınır; ek fiziksel bağlantı gerekmez.

İşleyiş:

Private VLAN içindeki IP adreslemesi, BGP yapılandırması ve rota politikaları tamamen üyelerin sorumluluğundadır.
RegPEX bu VLAN üzerinde route server, filtreleme veya izleme hizmeti sunmaz.
Bir port üzerine birden fazla private VLAN atanabilir; port kapasitesi aşılmamak koşuluyla sayı sınırlaması uygulanmaz.
Talep: peering@regpex.tr — konu satırında her iki tarafın ASN'i ve lokasyon belirtilmelidir.

2.4 Açık Peering Koşulu (Teşvikten Yararlanan Katılımcılar)

RegPEX'in amacı Türkiye'de açık bir peering topluluğu oluşturmaktır. Katılım Sözleşmesi Ek-5 kapsamındaki teşvikten yararlanan katılımcıdan şunlardan biri beklenir:

RegPEX route server'larından en az biriyle, en az bir adres ailesinde (IPv4 veya IPv6) kurulu ve prefix anons eden bir BGP oturumu bulundurması, ya da
RegPEX'te tanımlı peering iletişim adresine e-postayla gelen ikili peering taleplerini, talep tarihinden itibaren on (10) iş günü içinde kabul etmesi.

Bu koşulu sağlamayan katılımcıya RegPEX, koşulu ve dayanağını gösteren yazılı bildirimde bulunur. Katılımcı bildirimden itibaren otuz (30) gün içinde koşulu sağlarsa teşvik sürer; sağlamazsa teşvik sona erer ve standart tarife uygulanır. Bu koşul, katılımcının peering yapıp yapmama serbestisini kısıtlamaz; yalnızca teşvikin koşuludur.

Bu bölüm bilgi amaçlıdır. Bağlayıcı metin Katılım Sözleşmesi Ek-5 madde 4.5'tir; çelişki hâlinde Ek-5 esastır. Ücret tutarları için bkz. Ücretlendirme.

3. 3C1B IX Route Paylaşımı (RS3)

Bu hizmet yakında kullanıma açılacaktır.

RS3, RegPEX altyapısı üzerinde işletilen üçüncü bir route server olup 3C1B'nin (AS6823) dış IX bağlantılarından öğrendiği rotaları RegPEX üyelerine ücretsiz olarak dağıtmak amacıyla kurulmuştur.

3.1 Hizmet Modeli

RS3'ün ASN'i: AS199911 — RS1 ve RS2 gibi RegPEX route server ASN'i altında çalışır. 3C1B (AS6823), RS3'e rota veren katılımcıdır; üye RS3 ile AS199911 üzerinden eBGP oturumu açar ve AS-path'te AS6823'ü görür.
Asimetrik akış: RS3, üyelere 3C1B'nin IX-learned rotalarını dağıtır; üyelerden gelen rotalar ise sadece 3C1B'ye iletilir ve diğer üyelere gönderilmez.
Üye → 3C1B → dış IX'ler: Üye kendi prefix'lerini RS3'e duyurursa, 3C1B bu prefix'leri kendi IX peering'lerine re-advertise edebilir; böylece üye trafiği 3C1B'nin IX peer'larına akar.
RS1/RS2 ile ilişki: RS1 ve RS2 üye↔üye peering içindir; RS3 ise üye↔3C1B route sharing içindir. Üç RS bağımsız çalışır, birbirlerinden beslenmez.

3.2 Üyelik ve Aktivasyon

RS3'e bağlantı opsiyoneldir — üye talep ederse ayrı bir BGP oturumu açılır.
Bağlantı bilgileri için bkz. Teknik Gereksinimler §3.3.1.
Aktivasyon talebi: peering@regpex.tr — konu satırında "RS3 aktivasyon talebi" ve ASN belirtilmelidir.

3.3 Rota Kaynakları ve Community Etiketleme

RS3'e gelen tüm rotalar, kaynak IX bilgisi taşıyan community'lerle etiketlenir.
Community şeması BGP Large Community Politikası §5 belgesinde tanımlıdır.
IX kaynağı olarak PeeringDB IX ID'leri kullanılır; yeni IX eklendiğinde community listesi otomatik güncellenir.

3.4 Üye Yükümlülükleri

RS3'ten alınan rotalar üyenin kendi transit ilişkilerine re-advertise edilemez; no-export zorunludur.
Üye, sadece kendi ASN'ine ait prefix'leri RS3'e duyurabilir.
3C1B, rotaların içeriğini, kapsamını veya sürekliliğini garanti etmez; peering ilişkilerindeki değişiklikler duyurulan rota kümesini etkileyebilir.

3.5 Kesinti ve Değişiklik

3C1B, RS3 hizmetinin tamamını veya kısmını sonlandırma hakkını saklı tutar; politika değişikliği halinde 60 gün önceden duyuru yapılır.
Bireysel IX kaynaklarının eklenmesi/çıkarılması 60 gün beklemeksizin uygulanabilir; bu değişiklikler BGP Large Community Politikası sayfasında yayımlanır.

4. Route Server Kullanım Koşulları

4.1 Rota Duyurusu Kuralları

Yalnızca üyenin kendisine veya müşterilerine ait rotalar duyurulabilir.
Duyurulan tüm rotaların geçerli bir IRRDB kaydı (RIPE, ARIN vb.) olmalıdır.
RPKI Invalid olarak işaretlenmiş rotalar route server tarafından reddedilir.
Default route (0.0.0.0/0 veya ::/0) duyurusu yapılamaz.
Bogon prefix'ler ve RFC 1918/RFC 6598 adres alanları duyurulamaz.
Maksimum prefix limitleri, her üye için AS kayıt bilgilerine göre belirlenir.

4.2 BGP Community Desteği

Route server aşağıdaki community ailelerini destekler:

Aksiyon community'leri — üye kontrolünde, rota duyurusunu hedefleme ve AS prepend için.
Bilgilendirme community'leri — route server tarafından atanır, rotanın geldiği POP/şehir/ülke bilgisini taşır.
RS3 transit community'leri — sadece RS3 rotalarında, kaynak IX ve bölge bilgisini taşır.

Tam liste, değerler ve kullanım örnekleri için bkz. BGP Large Community Politikası.

4.3 Filtreleme Mekanizmaları

RegPEX route server'ları aşağıdaki filtreleme katmanlarını uygular:

RPKI Doğrulama: ROA (Route Origin Authorization) kontrolü
IRRDB Filtreleme: AS-SET ve route nesnelerinin doğrulanması
Bogon Filtreleme: Geçersiz prefix'lerin engellenmesi
Max-Prefix Kontrolü: Aşırı rota duyurusunun engellenmesi
AS-Path Filtreleme: Geçersiz AS path yapılarının tespiti

5. Üye Yükümlülükleri

5.1 Teknik Yükümlülükler

Üyeler, kendi router/switch ekipmanlarında BGP yapılandırmasını doğru şekilde uygulamakla yükümlüdür.
Peering port'u üzerinden yalnızca unicast IPv4 ve IPv6 trafiğine izin verilir.
Proxy ARP, DHCP, STP ve diğer Layer 2 broadcast protokolleri yasaktır.
Her üye en fazla bir (1) MAC adresi kullanabilir (ek MAC adresleri için onay gereklidir).
Üyeler, mesai saatlerinde ulaşılabilir bir NOC iletişim noktası ve mesai dışında nöbetçi mühendis iletişim bilgisi bildirmeli ve güncel tutmalıdır.

5.2 Operasyonel Yükümlülükler

PeeringDB kayıtlarının güncel tutulması zorunludur.
NOC iletişim bilgileri (e-posta, telefon) her zaman güncel olmalıdır.
Katılımcının kendi planlı bakım çalışmalarını RegPEX NOC'a önceden bildirmesi rica edilir; Katılım Sözleşmesi bu yönde bir süre öngörmez.
RegPEX'in planlı bakımı kural olarak 02:00–06:00 (yerel saat) aralığında yapılır ve katılımcının bildirdiği teknik iletişim noktasına en az beş (5) iş günü önceden yazılı bildirilir; acil bakımda bu süre dört (4) saate indirilebilir (Sözleşme Ek-4.3).
Güvenlik olayları derhal RegPEX NOC'a raporlanmalıdır.

6. RegPEX Yükümlülükleri

Route server'ların MANRS uyumlu şekilde işletilmesi
Peering altyapısının yüksek erişilebilirlikle (HA) sunulması
Üye trafik istatistiklerinin şeffaf şekilde paylaşılması
PeeringDB bilgilerinin güncel tutulması
Ağ değişikliklerinin önceden duyurulması

7. İhlal ve Yaptırımlar

Peering politikası ihlallerinde aşağıdaki süreç uygulanır:

Uyarı: İlk ihlalde yazılı uyarı gönderilir
Geçici Askıya Alma: Tekrarlayan ihlallerde port geçici olarak devre dışı bırakılır
Kalıcı Sonlandırma: Ciddi veya sürekli ihlallerde üyelik feshedilir

Acil durumlarda (ağ güvenliğini tehdit eden durumlar), RegPEX önceden bildirimde bulunmaksızın port'u devre dışı bırakma hakkını saklı tutar.

8. Politika Değişiklikleri

Katılım Sözleşmesi'ndeki bildirim süreleri bu politikadan önce gelir:

Katılımcı aleyhine her ücret değişikliği yürürlük tarihinden en az üç (3) ay önce yayımlanır ve yazılı bildirilir (Sözleşme Madde 8.7, Ek-5 madde 10).
BGP community şemasındaki güncellemeler otuz (30) gün önceden duyurulur (Ek-2).
Teknik değişiklikler Ek-2 ve Ek-3'te öngörülen bildirim süreleriyle duyurulur; POP kaldırılması hâlinde etkilenen katılımcılara en az doksan (90) gün önceden yazılı bildirim yapılır.
Bu politikanın diğer değişiklikleri RegPEX web sitesi ve katılımcı e-posta listesi üzerinden duyurulur.
Güvenlik aciliyeti gerektiren değişiklikler derhal uygulanabilir (Sözleşme Madde 7A).

9. İletişim

Peering İstekleri: peering@regpex.tr
NOC: noc@regpex.tr / +90 (312) 486 01 86
Genel sorular: İletişim Formu