ARIN IP transfer politikaları güncelleniyor: Operasyonel dersler

Pager’ı Uyandıran Gece ve ARIN IP Transfer Gerçeği

ARIN IP transfer politikaları son dönemde yeniden gündeme gelirken, benim aklıma hep aynı gece geliyor. Saat 02:37, telefon titriyor, Slack kanalında kırmızı bir flood: “Prod-US-Edge: /24 reachability issues – potential BGP leak”. Ekip yarı uykulu, ilk refleks: “Yine mi transit sağlayıcı?”. Ama bu sefer hikâye farklıydı. Haftalardır süren bir IP blok transferi ve ARIN tarafındaki kayıt güncellemeleri, RIPE bölgeli bir partner ile yapılan peering ve aceleyle değiştirilen route objeleri, hepsi aynı potada karışmıştı.

Sonuç? Kimi lokasyonlardan site açılıyor, kimilerinden açılmıyor. DNS çözülüyor ama trafik yanlış ASN’e gidiyor. Sertifika doğru ama kullanıcı yanlış edge node’a düşüyor. Klasik “her şey çalışıyor gibi ama kullanıcı hata alıyor” kabusu. İşte ARIN’in IP tahsisi ve transfer politikalarındaki en ufak bir değişiklik bile, özellikle global ayak izi olan ekipler için bu tür geceleri tetikleyebiliyor.

Şu anda siz de benzer şeylerle boğuşuyor musunuz? ARIN’den devraldığınız bir IPv4 bloğunu veri merkezinden buluta taşırken, route obje güncellemelerinde veya RPKI kayıtlarında takılıp mı kaldınız? DNS TTL’leri, BGP anonsları ve IPAM’deki kayıtlar arasında Excel maratonu mu yapıyorsunuz? Ya da hukuki birimin masasına düşen bir policy update PDF’i yüzünden, “bu bizi etkiliyor mu?” sorusuna yanıt arayan tek kişi siz misiniz?

Bu yazıda sana, ARIN IP transfer politikalarındaki güncellemelerin operasyonel dünyada ne anlama geldiğini, gerçek incident hikâyeleri, runbook örnekleri ve ölçülebilir metriklerle anlatacağım. Önce bu politikaların neden bu kadar kritik olduğunu konuşacağız. Sonra mimari ve operasyonel etkilerini, ardından da sahada uyguladığımız bir “veri merkezi + bulut + ARIN” projesinin perde arkasını paylaşacağım. Son bölümde ise, ekibinle birlikte hemen yarın uygulayabileceğin bir hazırlık runbook’u bırakacağım.

ARIN IP Transfer Politikaları Neden Bu Kadar Kritik?

IP Adresleri Artık Sadece Networkçünün Sorunu Değil

İlk yıllarımda IP adresleri neredeyse sadece network ekibinin derdiydi. Birkaç /24, veri merkezinde bir iki VLAN, firewall’da birkaç kural… Bitti gitti. Son 10–15 yılda ise tablo tamamen değişti. Bugün IP adresleri:

– SLA’lerin içine girmiş durumda (“/24’ünüz route edilebilir olacak” diye sözleşme maddesi gördüm).
– Müşteri sözleşmelerinde, hatta bazı regülasyonlarda isim isim geçiyor (“trafik X ülke dışına çıkmayacak” gibi).
– DevOps ekiplerinin CI/CD boru hatlarında, Terraform state’lerinde, Kubernetes ingress tanımlarında birebir kullanılıyor.

ARIN, RIPE, APNIC gibi RIR’ların (Regional Internet Registry) transfer ve tahsis politikaları güncellendikçe; sadece WHOIS çıktısı değişmiyor. Sizin route policy dokümanlarınız, IPAM otomasyonlarınız, hatta müşteri bağlantı şemalarınız da etkileniyor.

ARIN’in Rolü: WHOIS Kaydı Değişir, Operasyon Sallanır

ARIN tarafında IP transfer politikaları; özellikle şu alanlara dokunuyor:

– Kaynak doğrulama: Hangi şirket hangi IP bloğunun yasal sahibi?
– Transfer şartları: Hangi koşullarda, hangi ihtiyaç ispatlarıyla blok devri yapılabilir?
– Inter-RIR transferleri: ARIN’den RIPE veya APNIC bölgesine (ya da tersi) geçişte ne istenir?
– IPv4 / IPv6 ilişkisi: IPv4 transferi yaparken, IPv6 tarafında ne teşvik ediliyor veya bekleniyor?

Buradaki küçük bir kural değişikliği, mesela “organizasyonlar arası transferde ihtiyaç ispat süresi” veya “şirket birleşmelerinde dokümantasyon gereksinimi” gibi maddeler; sizin proje planlarınızı kaydırabilir. Hukuk birimiyle imzalanmış bir M&A (birleşme & satın alma) anlaşmasında IP bloklarının geçiş tarihi sabitken, ARIN tarafındaki onay süreci iki hafta uzarsa; prod trafik geçiş planınız da kayar. Sonra ne olur? Bir Cuma gecesi migration planı iptal, pazartesi sabahı herkes size bakar.

“Policy” Dediğin Şey Sonunda Latency’e Dokunuyor

Bu politikaların operasyonel metriklere etkisini görmezden gelmek kolay. Ama gerçekte; ARIN seviyesinde alınan kararlar, sizin şu metriklerinize kadar iniyor:

– Mean Time To Recovery (MTTR): BGP incident’larında route objeleriniz ve RPKI kayıtlarınız güncel değilse, MTTR dakikalardan saatlere kayabilir.
– Change Failure Rate: IP taşıma, ASN değişikliği ve prefix güncellemeleri sırasında; doğru policy’ye göre planlama yapmadığınızda roll-back oranınız artar.
– Availability (SLA): Transfer sürecinde çift anons, yanlış ROA, eksik IRR kaydı gibi hatalar; %99.95 uptime sözünüzü boşa çıkarabilir.

Benim sahada gördüğüm en kritik nokta şu: Politika değişiklikleri her zaman teknik ekiplerin radarına zamanında girmiyor. Genelde ilk e-posta hukuka veya yönetici ekibe düşüyor, onlar da “bir ara bakarız” diye etiketliyor. Sonra bir gün bir bakıyorsunuz; ARIN’e göre sahibi değişmiş bir blok, sizin prod edge router’ınızda hâlâ eski ASN adına anons ediliyor.

Yeni ARIN IP Transfer Politikalarının Teknik Etkileri

Needs-Based Justification, IPv4 Açlığı ve Gerçek Dünyadaki Yansıması

Uzun yıllardır ARIN tarafında temel prensiplerden biri, “ihtiyaç bazlı tahsis” (needs-based justification) oldu. Yani bir IP bloğunu isterken ya da transfer ederken, gerçekten bu IP’lere ihtiyacınız olduğunu ispatlamanız bekleniyor. IPv4 tamamen bitme noktasına geldikçe, bu konu daha da sıkı takip edilir hale geldi.

Son dönemde yapılan ve taslaklarda tartışılan politika güncellemelerinde, özellikle şu başlıklar öne çıkıyor:

– Bazı transfer türlerinde daha net ihtiyaç ispat kriterleri konulması.
– Organizasyon birleşmeleri, bölünmeleri ve marka değişikliklerinde daha detaylı dokümantasyon istenmesi.
– Inter-RIR transferlerinde, ARIN ile diğer RIR’lar arasında uyumlaştırılmış kurallar için adımlar atılması.

Bu, pratikte sizin için ne demek? Örneğin, bir bulut sağlayıcıdan başka bir sağlayıcıya migration planlıyorsanız ve kendi IP bloklarınızı da taşıyacaksanız, ARIN tarafındaki transfer onayı geciktiği için haftalarca two-homed, çift anonslu bir yapı tutmak zorunda kalabilirsiniz. Bu da hem maliyeti artırır, hem de konfigürasyon karmaşıklığını.

RPKI, IRR, Route Objeleri: Sadece Kağıt Üstünde Kalmayan Detaylar

ARIN politikalarındaki en küçük değişiklik bile, aşağıdaki alanlarda yeniden gözden geçirme gerektiriyor:

– RPKI ROA kayıtları: Hangi ASN hangi prefix’i anons edebilir?
– IRR (Internet Routing Registry) objeleri: Route, route6, as-set tanımlarınız güncel mi?
– WHOIS kayıtları: Organizasyon isimleri, iletişim bilgileri ve abuse contact’lar doğru mu?

Bir projede, ARIN’den devraldığımız bir /20 bloğu yeni bir tüzel kişiliğe taşırken; hukuk tarafı şirket ismini değiştirip tescilini halletmişti ama WHOIS ve RPKI güncellemeleri iki hafta gecikti. Sonuç olarak, bazı upstream sağlayıcılar yeni ASN’den gelen anonslara güvenmedi ve “prefix not allowed” diyerek filtreledi. Monitoring’de şöyle loglar görüyorduk:

[Edge-US1] %BGP-4-BGP_LOG: 203.0.113.0/20 prefix denied: invalid ROA
[Edge-EU2] %BGP-4-BGP_LOG: RPKI: route validation failed for 203.0.113.0/20

Bu tam bir “network her şeyi doğru yaptı ama kayıtlar yanlış” örneğiydi. ARIN tarafındaki transfer tamamlanmış, sözleşmeler imzalanmış ama otomasyonumuz WHOIS ve RPKI tarafını “post-migration step” olarak bırakmıştı. İşte politika değişiklikleri geldiğinde, bu tür bağımlılıkları netleştiren runbook’larınız yoksa, incident’larınız çok daha sık ve karmaşık hale geliyor.

CLI ve IPAM Çıktıları: Sahadaki Karmaşa

Bir gece yaptığımız root-cause analizde, aynı IP bloğu için üç farklı gerçeklik gördük:

# ARIN WHOIS kaydı (henüz güncellenmemiş)
$ whois 203.0.113.0
NetRange:       203.0.113.0 - 203.0.113.255
OrgName:        OldCorp Inc
...

# BGP table (yeni ASN'den anons)
$ birdc show route 203.0.113.0/24
203.0.113.0/24 via 192.0.2.1 on transit1 [bgp-transit1] * (100) [AS65050]

# İç IPAM sistemi (terraform managed)
» 203.0.113.0/24 assigned_to = 'NewCorp-Prod-Edge-US'

Üç farklı sistem, üç farklı “doğru”ya işaret ediyordu. ARIN’in transfer politikalarındaki güncelleme, aslında hukuken sahipliği netleştirmişti; ama bizim toolchain bunu yansıtamamıştı. Buradan aldığımız en büyük ders: IP adresi sahipliği ve anons eden ASN bilgisinin, IPAM ile RPKI/IRR arasında otomatik senkronize edilmesi gerekiyor.

Gerçek Bir Proje: Veri Merkezinden Buluta IP Taşıma ve ARIN

Durum: Eski Veri Merkezi, Yeni Bulut, Ortada ARIN

Birkaç yıl önce, Kuzey Amerika’da büyük bir müşteri için çalışıyorduk. Ellerinde ARIN tahsisli birkaç /21 ve /22 blok vardı. Plan şuydu:

– Eski on-prem veri merkezini kapatacaklardı.
– Trafiğin büyük kısmı iki farklı public cloud’a taşınacaktı.
– Kendi IP bloklarını hem CDN, hem de direct connect bağlantılarında kullanmak istiyorlardı.

İşin zorlayıcı yanı, şirketin ikiye bölünmesi ve bir kısmının satılmasıydı. Yani ARIN tarafında organizasyon bölünmesi + IP bloklarının yeni entitilere transferi söz konusuydu. Tam bu sırada, ARIN tarafında transfer politika dokümanında yapılan güncellemeler, özellikle dokümantasyon ve ihtiyaç ispatı kısımlarını daha net hale getirmişti.

İlk yaptığımız hata, bu değişiklikleri “network policy” gibi görüp, proje planına ciddi bir risk faktörü olarak koymamaktı. Sonuç: Cutover tarihine 10 gün kala, ARIN tarafında hâlâ iki önemli transfer beklemedeydi.

Post-Mortem: Nerede Çuvalladık?

Olay bittikten sonra yaptığımız retrospektifte, beyaz tahtada şu başlıklar vardı:

– ARIN ticket’ları ile proje task’ları arasında bağlantı yoktu.
– Hukuk ekibi ve network ekibi arasında tek bir ortak “IP transfer owner” tanımlanmamıştı.
– Transfer sürecinin IPAM, Terraform ve BGP konfigürasyonlarına etkisi net modellenmemişti.

Bir timeline çıkardık ve şu anı kritik olarak işaretledik:

Day -30: ARIN'e ilk transfer başvuruları yapıldı.
Day -14: ARIN ek doküman istedi. (hukuk ekibinin inbox'ında kayboldu)
Day -7: Change freeze öncesi son hafta, ARIN cevabı hâlâ bekleniyor.
Day -3: Cutover planı revize edildi, bazı servisler eski ASN'de bırakıldı.
Cutover Night: EU kullanıcılarının bir kısmı eski DC'ye, bir kısmı yeni edge'e gitti.

Bu olayda uptime metriklerimiz korkutucu değildi; toplamda yaklaşık 27 dakikalık kısmi erişilebilirlik sorunu yaşandı. Ama teknik borç olarak üzerimizde kalan yük çok daha büyüktü: İki hafta boyunca çift anons, karmaşık firewall kuralları ve DNS yönlendirmeleriyle yaşadık.

Bu Projede Nasıl Çözdük?

İkinci fazda, kalan bloklar için çok daha disiplinli bir yaklaşım benimsedik. Attığımız adımlar kabaca şöyleydi:

– Önce tüm IP bloklarını, ARIN WHOIS, IRR ve RPKI kayıtlarıyla yan yana kıyaslayan bir script yazdık.
– IPAM (biz NetBox kullanıyorduk) içine, her prefix için “arin_org_id”, “rir_status” ve “roa_state” alanları ekledik.
– Terraform modüllerine, prefix objesi oluştururken bu alanları da zorunlu yaptık.

Script’ten bir örnek çıktı şöyleydi:

$ ./check_prefix_compliance.py --prefix 203.0.113.0/24
Prefix: 203.0.113.0/24
ARIN Org:     NEWCORP-US
IPAM Org:     NEWCORP-US
RPKI State:   valid
IRR Route:    present (AS65050)
Status:       OK

$ ./check_prefix_compliance.py --prefix 198.51.100.0/24
Prefix: 198.51.100.0/24
ARIN Org:     OLDCORP-LEGACY
IPAM Org:     NEWCORP-EU
RPKI State:   not_found
IRR Route:    missing
Status:       MISMATCH (action required)

Bu basit check bile, cutover öncesi “kırmızı liste”yi netleştirmemizi sağladı. ARIN tarafında güncellenmemiş bloklar için proje planını baştan revize ettik; bazı servisleri bilinçli olarak “phase 2”ye erteledik.

DevOps Boru Hattına ARIN Gerçeğini Gömmek

En büyük kazanımımız, IP hayat döngüsünü CI/CD’nin doğal bir parçası haline getirmek oldu. Şöyle bir IP lifecycle pipeline tasarladık:

IP Request (Jira) ->
  Approval (Network + Legal) ->
    ARIN/Registry Tasks (if needed) ->
      IPAM Update (NetBox API) ->
        Terraform Plan/Apply ->
          RPKI/IRR Automation ->
            Monitoring Checks

Terraform tarafında da, her prefix için bir “compliance” bloğu tanımladık:

resource "netbox_prefix" "prod_edge_us" {
  prefix      = "203.0.113.0/24"
  status      = "active"
  description = "Prod Edge US"

  custom_fields = {
    arin_org_id = "NEWCORP-US"
    rir_status  = "assigned"
  }
}

resource "rpki_roa" "prod_edge_us" {
  prefix     = "203.0.113.0/24"
  max_length = 24
  asn        = 65050
}

Böylece, ARIN tarafındaki politik değişiklikler geldiğinde; örneğin belirli bir blok için transfer tamamlanmadan ROA oluşturulması gerekiyorsa, bu şartları Terraform tarafında policy as code olarak tanımlayabildik. Pipeline’da “transfer_in_progress” alanına bakarak, belirli resource’ları oluşturmayı engelledik.

Runbook: ARIN IP Transfer Değişikliklerine Nasıl Hazırlanırsın?

1. Organizasyonel Envanteri Çıkar: Hangi IP Kimin?

İlk yapılacak şey, elinizdeki IP bloklarının gerçek bir envanterini çıkarmak. Bunu Excel ile de yapabilirsiniz ama ben her zaman script + IPAM kombinasyonunu öneriyorum. Basit bir başlangıç için, ARIN WHOIS’den ve kendi router’larınızdan veri çekip kıyaslayan bir script yeterli:

$ ./inventory_prefixes.sh --source arin --source bgp --output inventory.csv

Runbook adımı olarak şunu yazın:

• Tüm ARIN tahsisli prefix’leri çek.
• Her prefix için anons eden ASN’i BGP tablosundan tespit et.
• IPAM’deki organizasyon bilgisiyle kıyasla.
• Tutarsızlıkları etiketle (MISMATCH, ORPHAN, LEGACY vb.).

Bu liste olmadan, politika değişikliklerinin sizi nereden vuracağını bilemezsiniz.

2. ARIN Policy Değişikliklerini Teknik Risklere Çevir

ARIN yeni bir transfer politikası yayınladığında veya mevcut olanı güncellediğinde, tipik olarak bir PDF veya web sayfası olarak önünüze düşer. Bunu teknik riske çevirmek için ekiple küçük bir mini-retro yapın. Beyaz tahtaya üç sütun çizin:

– Policy Maddesi
– Teknik Etki
– İlgili Sistem/Runbook

Örneğin, şöyle bir madde olsun (örnekliyorum): “Organizasyon birleşmelerinde, IP blok transferi için ek şirket kayıt belgeleri gereklidir.” Bunu şöyle deşifre edebilirsiniz:

– Teknik etki: M&A sonrası IP cutover tarihleri, minimum +2 hafta buffer ile planlanmalı.
– İlgili sistem: Jira change template’ine “ARIN transfer onayı alındı” checkbox’ı eklenmeli.

3. CI/CD’ye Guardrail Ekleyin: Policy as Code

Benim en sevdiğim kısım burası. IP transfer politikalarını birebir otomasyona çeviremezsiniz ama belirli koruma şeritleri (guardrail) tanımlayabilirsiniz. Örneğin:

• Prod ortamında kullanılacak her yeni prefix için, IPAM’de “rir_status = assigned” zorunlu olsun.
• RPKI ROA kaydı olmayan hiçbir prefix, edge router’larda anons edilmesin (veya en azından bir uyarı üretilsin).
• ARIN tarafında transfer sürecinde olduğu işaretlenen prefix’ler için, Terraform tarafında sadece “staging” tag’li ortamda kullanımına izin verilsin.

Bunu basit bir pre-commit hook veya pipeline aşaması olarak ekleyebilirsiniz:

stage('IP Compliance Check') {
  steps {
    sh './scripts/check_ip_compliance.sh --env prod'
  }
}

Bu aşama, örneğin aşağıdaki gibi bir output verdiğinde pipeline’ı kırmalı:

[ERROR] Prefix 198.51.100.0/24 has rir_status = 'transfer_pending'.
[ERROR] Prod environment cannot use prefixes in transfer_pending state.

4. Monitoring’i Sadece Latency İçin Değil, Kayıt Tutarlılığı İçin de Kullanın

Birçok ekip, monitoring’i sadece latency, error rate ve throughput için kullanıyor. ARIN politikalarındaki değişikliklere uyumda ise “config & kayıt tutarlılığı”nı izlemek de kritik. Biz birkaç projede şunları yaptık:

– Her prefix için, belirli aralıklarla RPKI doğrulama durumunu toplayan bir exporter yazdık.
– WHOIS ve IRR kayıtlarındaki değişiklikleri diff’leyip, Prometheus’a “prefix_mismatch” metriği olarak ittik.
– Grafana’da, IP bloklarının “green/yellow/red” durumunu gösteren bir dashboard oluşturduk.

Örneğin, Prometheus metriği şöyle görünüyordu:

ip_prefix_compliance{prefix="203.0.113.0/24", field="rpkistate"} 1
ip_prefix_compliance{prefix="198.51.100.0/24", field="rpkistate"} 0

Burada 1 = uyumlu, 0 = uyumsuz olarak işliyorduk. ARIN tarafındaki her büyük politika güncellemesinden sonra, bu dashboard’a bakarak hangi blokların riskli olduğunu birkaç dakikada görebiliyorduk.

5. Hukuk, Network, DevOps: Tek Bir Masaya Oturun

Teknik olarak en iyi pipeline’ı da kursanız, ARIN ile yazışan kişi ile BGP router’larını yöneten kişi farklı dünyalarda yaşıyorsa, gecenin bir yarısı yine siz uyanırsınız. Bu yüzden, ben her politika değişikliğinde şu basit ritüeli öneriyorum:

• 30 dakikalık bir “policy review” toplantısı yapın.
• Katılımcılar: Hukuk, Network, DevOps, gerekirse Security.
• Ajanda: Son değişiklik ne, hangi IP bloklarını etkileyebilir, hangi projelerin takvimini kaydırır?
• Çıktı: Jira’da en az 2–3 action item, sahipleri belli.

Bu küçük yatırım, gecenin üçünde atılacak onlarca Slack mesajından çok daha ucuz.

Kapanış: IP Adresleri Sadece Sayı Değil, Süreçtir

Yazının başında anlattığım gibi, bir gece ansızın pager’ınızı uyandıran şey çoğu zaman tek bir hatalı komut değildir. Genelde arkada, haftalarca hatta aylarca biriken küçük ihmal zincirleri vardır: Güncellenmemiş bir ARIN kaydı, bekleyen bir transfer talebi, RPKI tarafında unutulmuş bir ROA, IPAM’de “geçici” diye işaretlenmiş ama prod’a sızmış bir prefix…

ARIN IP transfer politikaları güncellendikçe, riskleriniz de statik kalmıyor. Ama bu kötü bir haber değil; doğru ele aldığınızda, bu değişiklikler aslında IP yönetim süreçlerinizi olgunlaştırmanız için bir fırsat. Çünkü her yeni kural, sizden daha iyi kayıt tutmanızı, daha net sahiplik tanımlamanızı, daha otomatize bir IP lifecycle süreci kurmanızı istiyor.

Ekiplerime hep şunu söylüyorum: “IP adresi, log satırında gördüğün sayıdan ibaret değil; arkasında sözleşme, regülasyon, politika, müşteri beklentisi ve tabii ki senin pager’ın var.” ARIN’den gelen bir politika güncellemesini sadece hukukun konusu olarak görürsen, yarın prod ortamında BGP tablosuyla kavga etme ihtimalin artar. Ama bugün bir runbook yazıp, CI/CD’ye birkaç guardrail ekleyip, IPAM’i tek gerçek kaynak haline getirirsen; o geceyi büyük ihtimalle uyuyarak geçirirsin.

Buradan çıkartabileceğin operasyonel aksiyon maddelerini hızlıca toparlayayım:

• Elindeki tüm ARIN tahsisli bloklar için tek bir envanter oluştur.
• IPAM’i (NetBox, phpIPAM, ne kullanıyorsan) WHOIS, RPKI ve IRR ile uyumlu hale getir.
• Terraform/CI pipeline’ına basit IP compliance kontrolleri ekle.
• Hukuk, Network ve DevOps arasında “IP transfer owner” rolünü netleştir.
• Her büyük ARIN politika güncellemesinden sonra, en azından 30 dakikalık bir teknik değerlendirme yap.

Unutma, ARIN tarafında güncellenen her satır, senin operasyon dünyanda bir değişkeni oynatıyor. Bu değişkeni rastgele değil, tasarlanmış bir sistemin parçası haline getirirsen; IP transferleri senin için kriz değil, sıradan bir change ticket’ı olur. Ve işte o zaman, gece gelen pager’ların sayısı gerçekten azalmaya başlar.

Eğer ekibinle bu süreci kurgularken takıldığınız noktalar olursa, bunu bir retrospektif fırsatı olarak gör; neleri manuel yaptığınıza bakın, nerelerde log tutmadığınızı, nerelerde “söz uçar, IP kalır” dediğinizi yakalayın. Sonra hepsini küçük, ölçülebilir iyileştirmelere çevirin. Birkaç çevirimde, ARIN politika değişiklikleri sizin için stres kaynağı değil, altyapı olgunluk göstergesi haline gelecek.