RIPE NCC IP Tahsislerinde Yeni Kurallar: IPv4 Kıtlığı ve IPv6 Stratejisi Nasıl Yeniden Şekilleniyor?

RIPE NCC IP Tahsislerinde Yeni Dönem: Neden Bu Kadar Önemli?

Ağ tasarımı, kapasite planlama veya maliyet analizi yaptığınız her toplantıda aynı soru artık daha sert biçimde karşımıza çıkıyor: “Yeni projeler için nereden IP bulacağız ve bu bize ne kadara mal olacak?” Avrupa, Orta Doğu ve bazı Orta Asya ülkelerini kapsayan bölgesel adres kayıt otoritesi RIPE NCC, tam da bu baskıların ortasında IP tahsis kurallarını son yıllarda ciddi şekilde sıkılaştırdı. Özellikle IPv4 adresleri neredeyse tamamen tükendiği için, bugün artık IP bloğu almak birkaç form doldurup beklemekten çok daha karmaşık bir sürece dönüşmüş durumda.

Bu makalede, RIPE NCC IP tahsislerindeki yeni kuralları sade bir dille özetleyip; LIR’ler (Local Internet Registry), hosting şirketleri, kurumsal ağlar ve SaaS projeleri açısından ne anlama geldiğini netleştireceğiz. DCHost tarafında kendi altyapımızı planlarken ve müşterilerimize IP hazırlığı yaparken yaşadığımız pratik deneyimleri de araya serpiştirerek konuşacağız. Amacımız; “politika metni” okumak zorunda kalmadan, IPv4 kıtlığı ve IPv6 geçişi bağlamında önümüzdeki 3–5 yılı mantıklı biçimde planlayabilmenizi sağlamak.

RIPE NCC ve IP Tahsis Sürecinin Yeni Gerçeği

Önce tabloyu netleştirelim: RIPE NCC, bölgemizdeki IP adreslerini ve AS numaralarını dağıtan bölgesel internet kayıt kurumu (RIR). Üyeleri genellikle LIR statüsündeki operatörler, ISP’ler, veri merkezi ve hosting sağlayıcıları ile büyük kurumsal ağlar. Yani siz de bir hosting müşterisi, kurumsal IT ekibi veya SaaS geliştiricisi olarak, aslında bu zincirin bir parçasısınız.

IPv4 adresleri uzun süredir “tükeniyor” diyoruz; ama RIPE bölgesinde bu artık teorik bir risk değil, pratik bir gerçek. IPv4 adreslerinin kıtlığı ve IPv4 fiyatlarının hızla artması yüzünden RIPE NCC, tahsis politikasını üç ana eksende sıkılaştırdı:

• Yeni IPv4 tahsisleri için çok sınırlı ve küçük bloklar (tipik olarak tek bir /24),
• Bekleme listesi ve tahsis önceliğinin yeniden tanımlanması,
• Transfer ve çoklu LIR açarak “adres avcılığı” yapılmasını önlemeye dönük kurallar.

Buna paralel olarak IPv6 tarafında ise teşvik edici, hatta bazı durumlarda fiilen zorlayıcı diyebileceğimiz adımlar görüyoruz: Yeni LIR’lerin IPv6 bloğu almadan ağ kurması pratikte anlamsız hale geliyor; operatörler ve hosting şirketleri ise projeleri giderek “IPv6-first” düşünmeye zorlanıyor. Bu eğilimin daha geniş resmini merak ediyorsanız, IPv6 benimseme oranlarındaki artışın performans ve maliyet dengesine etkilerini anlattığımız yazımız iyi bir tamamlayıcı olacaktır.

Yeni RIPE NCC IP Tahsis Kurallarının Ana Hatları

Politika dokümanlarının tüm maddelerini tek tek saymak yerine, sahada gerçekten işinizi değiştiren başlıklara odaklanalım.

1) Yeni IPv4 Tahsisleri: “Son /24” Mantığı

Artık RIPE NCC’den yeni IPv4 bloğu istemek, “gereksinim formu doldurup /22 almak” gibi eski düzen değil. Son dönemde uygulanan yaklaşım, LIR başına en fazla tek bir küçük blok mantığıyla ilerliyor; pratikte bu genellikle bir /24 (256 IP) anlamına geliyor. Bunun da adı üzerinde “son” tahsis olduğu açıkça belirtiliyor; yani “biraz daha büyüdük, ikinci /24 gelir mi?” beklentisi gerçekçi değil.

Bu ne demek?

• Yeni kurulan LIR’ler, sadece küçük ölçekli bir IPv4 bloğuna sahip olabiliyor.
• Büyük projeler için gereken IPv4 adresleri, ya ikincil piyasa (transferler) ya da mevcut blokların optimize edilmesiyle sağlanmak zorunda.
• Hosting müşterisi olarak doğrudan RIPE’den blok almak yerine, çoğu zaman sağlayıcınız üzerinden IPv4 kiralama yoluna gideceksiniz.

DCHost olarak biz de kendi IP envanterimizi planlarken, yeni /24 tahsislerini “stratejik tampon” gibi değerlendiriyor, asıl kapasiteyi ise elimizdeki blokların verimli kullanımı ve IPv6’ya agresif geçişle çözüyoruz.

2) Bekleme Listesi ve Kıtlık Yönetimi

IPv4 stoğu bitmiş bir kaynak olduğu için RIPE NCC, zaman zaman geri dönen (geri verilen veya iptal edilen) blokları yeniden dağıtmak zorunda kalıyor. Bu dağıtım da bekleme listesi üzerinden yapılıyor. Temel mantık şöyle:

• Yeni (veya bazı durumlarda daha önce tahsis almamış) LIR’ler başvuru yaptıktan sonra sıraya giriyor.
• Boşa çıkan küçük IPv4 blokları, bu sıradaki LIR’lere belirlenmiş kurallar çerçevesinde tahsis ediliyor.
• Bekleme süresi; başvuru yoğunluğu, geri dönen adres miktarı ve bölgesel talebe göre değişiyor.

Gerçek hayatta bu ne anlama geliyor? Bir projeye altı ay sonra başlayacağınızı biliyorsanız, IP planını da altı ay önceden düşünmek zorundasınız. “Sunucu hazır, IP’yi yarın alırız” yaklaşımı artık işlemez hale geldi. Biz DCHost tarafında, büyük projeler için kapasite planlarken IP ihtiyacını en baştan konuşuyor; gerekirse projeyi kademeli devreye alarak IP kullanımını zamana yayıyoruz.

3) Transfer Kurallarının Sıkılaşması ve Spekülasyon Engeli

IPv4 kıtlığı ortaya çıktığında, piyasada doğal olarak “IP ticareti” canlandı. Bazı aktörler sadece adres alıp satarak gelir elde etmeye çalıştı. RIPE topluluğu, bu tür spekülasyonu sınırlamak için transfer kurallarını sıkılaştırdı. Ana maddeleri sadeleştirirsek:

• Tahsis edilmiş bir IPv4 bloğunu hemen transfer etmek mümkün değil; belirli bir elde tutma süresi (holding period) söz konusu.
• Sırf daha fazla IPv4 kapmak için aynı kişi veya kurumun birden fazla LIR açarak sistemi “bypass etmesi” politikalarla açıkça hedefleniyor.
• Transferlerde şeffaflık, kayıtların doğru tutulması ve RIPE Database üzerinde güncel whois bilgilerinin olması zorunlu.

Bu kurallar, bir anda “hadi başka bir LIR açıp ikinci /24’ü kapalım” gibi planları büyük oranda anlamsız hale getirdi. Uzun vadede IP’yi “finansal yatırım aracı” değil, ağ kaynağı olarak görmeye zorlayan bir yaklaşım bu. IPv4 transfer piyasasının işleyişini ve diğer RIR bölgesindeki (örneğin ARIN) yaklaşımları merak ediyorsanız, ARIN IP tahsis değişikliklerini anlattığımız yazı karşılaştırma yapmak için faydalı olabilir.

4) IPv6 Tahsisleri ve “Artık Kaçış Yok” Noktası

IPv4 tarafı sıkılaşırken, IPv6 için tablo farklı: RIPE NCC IPv6 adreslerini oldukça cömert ve geleceğe dönük şekilde tahsis ediyor. Yeni kurallar ve pratik uygulama şu mesajı veriyor: “Gerçek büyümeyi IPv6 üzerinde planlayın.”

Tipik olarak bir LIR, tek bir IPv6 bloğu ile milyonlarca, hatta milyarlarca son kullanıcı cihazını numaralandırabilecek kadar geniş bir adres alanı alabiliyor. Buradaki kritik nokta; IPv6 bloğuna sahip olmanın tek başına yeterli olmadığı, operasyonel olarak IPv6’yı gerçekten yayına almanız gerektiği. Yani:

• Sunucularınızda ve router’larınızda IPv6 konfigürasyonu,
• Firewall kurallarınızın IPv6’yı kapsaması,
• DNS’te AAAA kayıtlarının açılması,
• Uygulama katmanında IPv6 farkındalığı (log formatları, rate-limit, erişim kontrolü vb.).

DCHost altyapısında yeni projeleri tasarlarken, artık subnet şemasını önce IPv6 için kuruyor, IPv4’ü ise çoğu zaman NAT ve paylaşımlı kullanım senaryoları üzerinden düşünüyoruz. Benzer bir yolu sizin ağınız için de çizmek istiyorsanız, daha teknik bir başlangıç noktası olarak VPS sunucunuzda IPv6 kurulum ve yapılandırma rehberimize göz atabilirsiniz.

5) RIPE Database, RPKI ve Şeffaflık Beklentisi

Yeni tahsis ve transfer kuralları kadar önemli bir diğer eksen de şeffaflık ve yönlendirme güvenliği. RIPE NCC ekosisteminde artık şu beklentiler standart hale geliyor:

• IP ve ASN kayıtlarının RIPE Database üzerinde güncel tutulması,
• Her blok için doğru abuse-c ve iletişim bilgilerinin tanımlanması,
• BGP’de IP’nizi kimin hangi AS ile anons edebileceğini belirleyen RPKI (ROA kayıtları) kullanımı,
• Route object’lerin yaratılması ve düzenli güncellenmesi.

Güvenlik denetimleri ve siber saldırılardaki artış da bu eğilimi güçlendiriyor. Özellikle DDoS ve BGP hijacking gibi tehditler bağlamında, RIPE NCC’nin de teşvik ettiği RPKI süreçleri giderek “opsiyonel iyi uygulama” olmaktan çıkıp fiili bir gereklilik haline geliyor. Bu yönüyle bakınca, ağ ve sunucu güvenliği için gerçekçi yol haritasını anlattığımız yazıdaki tavsiyelerle RIPE tarafındaki beklentiler aslında aynı noktada buluşuyor.

IPv4 Kıtlığı, Maliyet Baskısı ve Operasyonel Etkiler

Politika başlıklarını anladık; şimdi işin can yakan kısmına gelelim: Bu değişiklikler pratikte ağ mimarisi, maliyet ve iş planlaması açısından ne ifade ediyor?

IPv4 Adresi Artık Stratejik Bir Kaynak

Eskiden birçok projede IP adreslerini neredeyse sınırsızmış gibi dağıtıyorduk: Her servise ayrı IP, her küçük müşteri grubuna /29, kimi zaman boşta duran onlarca IP… IPv4’ün fiilen tükenmesi ve IPv4 adres fiyatlarının rekor seviyelere çıkması ile bu rahat dönemin kapandığını kabul etmek zorundayız.

Bugün orta ölçekli bir proje planlarken bile şu soruları sormamız gerekiyor:

• Gerçekten her node için ayrı public IP’ye ihtiyacımız var mı?
• Load balancer ve reverse proxy mimarisiyle tek IP üzerinden birden çok servisi sunabilir miyiz?
• CGNAT veya 1:N NAT ile son kullanıcıları daha az public IP ile dışarı çıkarabilir miyiz?
• Mail, web ve API trafiğini aynı IP üzerinde yönetmek mümkün mü?

DCHost tarafında yaptığımız yeni projelerde, neredeyse her tasarım dokümanında “IP bütçesi” diye ayrı bir bölüm açıyoruz. CPU ve RAM kadar IP adreslerinin de bir kaynak olduğunu, hatta birçok durumda en pahalı kaynak olduğunu kabullenmiş durumdayız.

Fiyat Artışları: Bütçe Planlamasında Yeni Satır

IPv4 transfer piyasasındaki fiyat artışları, doğrudan proje maliyetlerine yansıyor. Eskiden donanım veya lisans kalemleri arasında kaybolan IP maliyeti, artık kendi başına satır açılması gereken bir kalem. Üstelik bu maliyet sadece “adres satın alma” ile bitmiyor:

• RIPE üye (LIR) ücretleri,
• Adres bloklarının yönetimi, audit süreçleri,
• RPKI, route-policy ve güvenlik için ayrılan iş gücü,
• IP temelli rate-limit, siyah liste yönetimi, kötüye kullanım şikayetlerine yanıt.

Buna karşılık, IPv6 tarafında adres maliyeti neredeyse sıfır denecek seviyede. Tam da bu nedenle, uzun vadeli bütçe planlamasında büyümeyi IPv6 üzerinde konumlandırmak neredeyse tek makul seçenek. IPv4 ise “geçiş ve uyumluluk katmanı” gibi düşünülmeli.

Ağ Tasarımında NAT, Proxy ve Çoklu Kiracı Mimariler

IPv4 kıtlığı, ağ tasarımını da değiştiriyor. Daha az sayıda public IP ile daha fazla iş yapmak zorunda olduğumuz için aşağıdaki desenler öne çıkıyor:

• Reverse proxy ve load balancer: Tek IP üzerinden birden fazla domain ve uygulama yayını.
• CGNAT / PAT: Çok sayıda iç IP’nin birkaç dış IP üzerinden internete çıkması.
• Çok kiracılı (multi-tenant) uygulama mimarileri: Tek IP üzerinden yüzlerce müşteri hesabı barındıran SaaS yapıları.
• İç ağda RFC1918 + IPv6, dışa çıkışta minimum IPv4: Özellikle ofis ağlarında ve IoT senaryolarında yaygın bir model.

DCHost altyapısında da, özellikle yoğun trafik alan projelerde “IP başına düşen bağlantı” sayısını artıran bu yaklaşımları tercih ediyoruz. Böylece hem IP maliyetini aşağı çekiyor, hem de yönlendirme tablosunu sade tutarak performans ve yönetilebilirliği artırıyoruz.

IPv6 Zorunluluğuna Doğru: Stratejinizi Nasıl Kaydırmalısınız?

RIPE NCC’nin yeni IP tahsis kurallarının arka planında tek bir büyük hedef var: IPv4’ü verimli kullanırken, gerçek genişlemeyi IPv6’ya taşımak. Peki pratikte ne yapmalısınız?

1) Mevcut IPv4 Envanterinizi Gerçekçi Şekilde Çıkarın

İlk adım, neye sahip olduğunuzu ve nasıl kullandığınızı netleştirmek. Biz birçok firmayla çalışırken şu tabloyu görüyoruz:

• Yıllar önce alınmış ama artık kullanılmayan /29–/28 bloklar,
• Sunuculara atanmış ama hiçbir servisin dinlemediği IP’ler,
• Firewall kurallarında “tarihi nedenlerle” bırakılmış ancak bugün anlamını yitirmiş tanımlar.

Somut bir egzersiz önerisi:

1. Tüm IPv4 bloklarınızı ve VLAN/subnet şemanızı çıkarın.
2. Her IP için: hangi sunucu/servis, hangi portlar, hangi trafiği taşıyor, tek tek etiketleyin.
3. Kullanılmayan IP’leri tespit edip ya geri verin ya da yeni projeler için planlayın.
4. Gereğinden geniş atanmış subnet’leri bölmeyi düşünün.

Bu çalışma genelde toplam IPv4 havuzunuzun %10–20’sini geri kazanmanızı sağlar; yeni bir blok almaktan önce denenmesi gereken en ucuz yöntem budur.

2) Yeni Projeleri “IPv6-First” Mantığıyla Tasarlayın

Artık yeni bir uygulama veya servis tasarlarken şu soruyu sormak gerekiyor: “Bu sistemi sadece IPv4 ile değil, baştan IPv6 destekli olarak nasıl kurarız?” DCHost ekibi olarak kendi mimarilerimizde şu prensipleri uyguluyoruz:

• Her VPS veya dedicated sunucuya hem IPv4 hem IPv6 adresi atamak.
• DNS tarafında A ve AAAA kayıtlarını birlikte yayınlamak.
• Uygulama log’larını IPv6 adreslerini doğru gösterecek şekilde ayarlamak.
• Firewall ve WAF kurallarını IPv6’yı kapsayacak şekilde tasarlamak.

Eğer IPv6 geçişi size hala “riskli ve karmaşık” geliyorsa, IPv6 benimseme oranları ve işletmeler için gerçekçi yol haritasını anlattığımız yazı aşama aşama plan çıkarmanıza yardımcı olabilir.

3) Uygulama ve Veritabanı Katmanında Hazırlık

IPv6’yı sadece ağ tarafı meselesi gibi görmek büyük hata. Uygulama ve veritabanı katmanında da hazırlık yapmak gerekiyor:

• IP adresi sakladığınız alanların veri tipleri (örneğin VARCHAR(15) yerine INET6 veya daha geniş string alanlar),
• IP bazlı rate-limit ve güvenlik kuralları (IPv6 aralığı çok geniş olduğu için daha akıllı kurallar gerekli),
• Log analizi ve raporlamada IPv6 formatını desteklemek.

Bu dönüşümü parça parça yapmak mümkün. Örneğin önce sadece admin panelini IPv6 üzerinden erişilebilir hale getirip, ardından API ve son kullanıcı trafiğini yavaş yavaş IPv6’ya taşıyabilirsiniz.

4) Hosting ve Veri Merkezi Stratejinizi Gözden Geçirin

IP tahsis kurallarındaki değişiklikler sadece adres seviyesinde değil, veri merkezi ve hosting stratejinizde de etkili olmalı. Burada üç temel senaryo öne çıkıyor:

• VPS ve bulut altyapısı: Yeni açacağınız VPS’lerin IPv6 desteği olup olmadığını ve size ayrılan IPv4 sayısını dikkatle inceleyin.
• Dedicated sunucu: Yüksek trafikli projelerde, tek bir güçlü sunucuya atanmış sınırlı IPv4 yerine; çoklu sunucu + IPv6 + load balancer mimarisi genelde daha esnek olur.
• Colocation: Kendi router ve IP bloklarınızla veri merkezine indiğinizde, RIPE politikaları ve yönlendirme güvenliği sizin sorumluluğunuzda olur; bu da ayrı bir uzmanlık gerektirir.

Bu konularda daha genel bir çerçeve çizmek isterseniz, RIPE NCC veri merkezi genişlemelerinin IP altyapınıza etkisini anlattığımız makale ve “Dedicated sunucu mu VPS mi?” karar rehberimiz birlikte okunmaya değerdir.

LIR’ler, Kurumsal Ağlar ve Hosting Müşterileri İçin Uygulanabilir Kontrol Listesi

Teoriyi pratiğe dökelim. RIPE NCC IP tahsislerindeki yeni kurallara uyum sağlamak ve IPv4/IPv6 dengesini doğru kurmak için kullanabileceğiniz bir kontrol listesi hazırladık.

Adım 1: Politika ve Sözleşmelerinizi Güncelleyin

• IP adreslerinin müşterilere tahsis şartlarını (süre, amaç, alt kiralama yasağı vb.) sözleşmelerinize yazın.
• IP kullanım politikası (AUP) oluşturun ve kötüye kullanım şikayetlerine yanıt sürecini tanımlayın.
• IP transferi yapıyorsanız, RIPE politikalarına uyumlu iç prosedür hazırlayın.

Adım 2: Ağ Tasarımınızı IP Kıtlığına Göre Revize Edin

• IP başına servisi değil, servis başına IP’yi hedefleyin: Reverse proxy ve SNI ile çoklu domain yayımlayın.
• CGNAT veya outbound proxy ile ofis/bayi ağlarını daha az public IPv4 ile dışarı çıkarın.
• İç ağda mümkün olduğunca IPv6 + özel IPv4 (RFC1918) kombinasyonu kullanın.

Adım 3: IPv6 Yaygınlaştırma Planı Hazırlayın

• IPv6 adres planınızı (prefix, site/subnet dağılımı, VLAN eşlemesi) yazılı hale getirin.
• Router, firewall, load balancer ve WAF konfigürasyonlarınızı IPv6 uyumlu hale getirin.
• DNS’te AAAA kayıtlarını ve PTR (reverse DNS) yapılandırmasını unutmayın.

Adım 4: RIPE Database ve RPKI Temizliğini Yapın

• Elinizdeki tüm IP blokları için RIPE Database kayıtlarını gözden geçirin, iletişim bilgilerini güncelleyin.
• Her blok için route object oluşturun veya mevcut olanları güncelleyin.
• RPKI’de ROA kayıtlarını tanımlayın; hangi AS’lerin hangi prefix’i anons edebileceğini açıkça belirleyin.

Adım 5: İzleme, Loglama ve Güvenlik

• IPv4 ve IPv6 trafiklerini ayrı ayrı izleyin; büyüme trendini görün.
• Firewall log’larında ve WAF kurallarında IPv6’yı görünür kılın.
• DDoS ve kötüye kullanım (abuse) durumlarında IP bazlı analiz yapabilecek araçlar kullanın.

DCHost ile Yeni RIPE NCC Kurallarına Uyum: Nasıl Yardımcı Oluyoruz?

Biz DCHost ekibi olarak, RIPE NCC IP tahsislerindeki bu dönüşümü “dışsal bir kısıt” değil, altyapıyı modernleştirmek için bir fırsat olarak görüyoruz. Kendi LIR sürecimiz, IP envanter yönetimimiz ve IPv6’ya agresif geçiş planlarımızı tam da bu yeni kurallara göre şekillendirdik.

Pratikte size nasıl yardımcı olabiliriz?

• IPv6 hazır VPS ve dedicated sunucular: Yeni projelerinizi baştan çift yığın (dual-stack) olarak devreye almanıza yardımcı oluyoruz.
• Colocation ve kendi IP bloklarınız: Kendi ASN ve IP bloklarınızla DCHost veri merkezlerine inmek istiyorsanız, BGP, RPKI ve route-policy tarafında tecrübemizi paylaşıyoruz.
• Adres planlama danışmanlığı: IPv4 envanter temizliği, IPv6 adres şeması ve NAT/proxy mimarisi konularında birlikte tasarım yapabiliyoruz.
• Güvenlik ve uyum: Abuse yönetimi, DDoS senaryoları ve loglama stratejilerinizin RIPE beklentileriyle uyumlu hale gelmesini sağlıyoruz.

Özetle; RIPE NCC IP tahsislerindeki yeni kurallar, IPv4’ün artık “ucuz ve bol” bir kaynak olmadığını açıkça gösteriyor. IPv6 ise hem teknik hem de ekonomik açıdan büyümenin tek gerçekçi adresi. Eğer siz de ağınızı, uygulamalarınızı ve bütçenizi bu yeni gerçekliğe göre yeniden şekillendirmek istiyorsanız, DCHost olarak IP planlamasından sunucu mimarisine kadar tüm katmanlarda yanınızda olmaktan memnuniyet duyarız.

Bir sonraki adım için; ister küçük bir web projesi ister büyük bir SaaS platformu planlıyor olun, altyapı ve IP stratejinizi birlikte gözden geçirmek üzere bizimle iletişime geçebilirsiniz. Böylece RIPE NCC’nin yeni IP tahsis kurallarını sadece “zorunlu bir kısıt” değil, daha dayanıklı, ölçeklenebilir ve sürdürülebilir bir altyapıya geçiş için kaldıraç olarak kullanmış olursunuz.