RIPE NCC Tahsisleri: IPv4, Transfer ve IPv6

RIPE NCC IP Tahsisleri: IPv4 Kıtlığı Neden Önemli?

Yeni bir ağ, hosting hizmeti veya SaaS projesi için adres planlarken üç konuyu ayırmak gerekir: RIPE NCC’den ilk IPv4 tahsisi, mevcut kaynakların transferi ve IPv6 kapasitesi. RIPE NCC’nin normal IPv4 havuzunun tükenmesi 25 Kasım 2019’da duyuruldu. Bu yazı, LIR’lerin ve hosting müşterilerinin kullanabileceği güncel politika ve planlama çerçevesini açıklar.

Bu makalede, RIPE NCC IP tahsislerindeki temel başlıkları 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. Amacımız; IPv4 kıtlığı ve IPv6 geçişi bağlamında önümüzdeki 3–5 yılı planlamak için bir çerçeve sunmak. Tahsis veya transfer başvurularında bu özetin yerine ilgili güncel politika metinlerini esas almalısınız. Politika kontrolü: 4 Kasım 2026. Temel IPv4 politikası RIPE-826, 20 Haziran 2024; transfer politikası RIPE-807, 30 Ekim 2023 tarihlidir ve ikisi de bu makalenin 25 Aralık 2025 tarihli ilk yayınından önce mevcuttu. Aşağıdaki 29 Eylül 2026 tarihli ek LIR hesabı kısıtı ise ayrıca tarihlendirilmiştir.

RIPE NCC ve IP Tahsis Süreci

Ö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. Politikaları açık ve topluluk temelli süreçle RIPE topluluğu geliştirir; RIPE NCC uygular ve kayıtları yönetir. 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 kıtlığı, IPv4 tükenmesi ve fiyat dinamikleri ile birlikte kapasite planlamasının bir parçasıdır. Fiyatların her dönemde arttığını varsaymadan şu üç ayrı başlığı inceleyin:

• Uygun LIR hesapları için bekleme listesinden tam bir /24 IPv4 tahsisi,
• Geri dönen adreslerin sıralı dağıtımı ve belirsiz bekleme süresi,
• Kaynak türüne bağlı transfer koşulları ile üyelik ve ek LIR hesabı işlemleri.

IPv4 kıtlığı, IPv6’yı kapasite planlamasının önemli bir parçası haline getiriyor. Yeni LIR’ler, operatörler ve hosting şirketleri, projelerinde “IPv6-first” yaklaşımını uygulama ve erişim ihtiyaçlarıyla birlikte değerlendirebilir. 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.

RIPE NCC IP Tahsislerinde Temel Başlıklar

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) IPv4 Tahsisi: Kim Bir /24 Alabilir?

RIPE-826, bölüm 5.1 uyarınca tahsis büyüklüğü tam olarak bir /24, yani 256 IPv4 adresidir. RIPE NCC’nin tek bir LIR’ye yaptığı tahsislerin toplamı 256 adresle sınırlıdır; bu sınıra ulaşan veya geçmişte aşan LIR yeniden tahsis isteyemez. Bekleme listesi uygulama rehberi, hesabın RIPE NCC’den daha önce herhangi bir IPv4 tahsisi almamış olmasını ister. Bu sınır, transferle edinilenler dâhil toplam IPv4 varlığı için genel bir /24 tavanı değildir.

Bu ne demek?

• Üyelik/LIR açılışı tamamlanmış, daha önce RIPE NCC IPv4 tahsisi almamış uygun hesap başvurabilir; yeni hesap açmak tahsis tarihini garanti etmez.
• Tahsis, son kullanıcılara veya altyapıya atamalar yapmak için kullanılmalı; ağın RIPE NCC hizmet bölgesinde en az bir aktif unsuru bulunmalıdır.
• Daha büyük IPv4 ihtiyacı mevcut envanter, uygun transfer veya sağlayıcıdan alınan hizmetle karşılanabilir. Hosting müşterisinin kendi LIR hesabını açması her proje için gerekli değildir.

IP envanteri planlamasında, olası bir /24 tahsisini ana büyüme kaynağı yerine sınırlı bir tampon olarak değerlendirmek; mevcut blokların verimli kullanımını ve IPv6 geçişini birlikte planlamak daha temkinli bir yaklaşımdır.

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

Normal IPv4 havuzu tükendikten sonra dağıtım, RIPE NCC’ye geri verilen veya kapanan üyelerden geri alınan adreslerle devam eder. Kurtarılan adresler yeniden kullanım öncesi karantinadan geçer. Bekleme listesi rehberinin temel işleyişi şöyledir:

• Uygun LIR hesabı IPv4 isteğini LIR Portal üzerinden iletir ve ilk gelenin önce işlendiği listeye eklenir.
• Yeterli bitişik adres hazır olduğunda sıraya göre tam /24 tahsis edilir; bekleme süresi için garanti verilmez.
• RIPE-826 bölüm 5.2, IANA’ya iade edilmeyip RIPE NCC tarafından yeniden dağıtılacak dönen adreslere uygulanır. Bu kapsamda IXP havuzundan dönen adresler yine IXP havuzuna ayrılır. Diğer dönen /24 ve daha büyük bloklar genel kurala, daha küçük bloklar IXP havuzuna gider; her geri dönüş bekleme listesini beslemez.

Gerçek hayatta bu ne anlama geliyor? Bir projeye altı ay sonra başlayacağınızı biliyorsanız, IP planını şimdiden ele almak yararlıdır; ancak altı ay önceden başvurmak tahsis tarihini garanti etmez. “Sunucu hazır, IP’yi yarın alırız” varsayımıyla hareket etmek, özellikle bekleme listesinden tahsise bağımlı projelerde gecikme riski yaratır. Büyük projelerde IP ihtiyacı kapasite planının başında ele alınabilir; uygun durumlarda kademeli devreye alma, IP kullanımını zamana yaymaya yardımcı olabilir.

3) IPv4 Transferlerinde Dikkat Edilecek Noktalar

IPv4’ün ikincil piyasada el değiştirmesi ile RIPE kayıtlarının resmen aktarılması aynı işlem değildir. Sözleşme imzalamadan önce RIPE-807 transfer politikasını, kaynağın statüsünü, kayıtlı sahibini ve başvurudaki tarafların uygunluğunu kontrol edin. Tahsis edilmiş kaynaklar RIPE NCC üyesine aktarılır; PI kaynaklarda uygun sponsor ilişkisi de mümkün olabilir.

• 24 ay: IPv4 ve 16 bit ASN gibi kıt kaynaklar, mevcut sahibinin kaynağı aldığı tarihten itibaren 24 ay transfer edilemez. Bu, yalnız ilk tahsise değil transfer veya birleşme/devralma yoluyla edinmeye de uygulanır. Ancak bu 24 ay içinde başka bir birleşme/devralma nedeniyle aktarımı engellemez.
• Ayrı kısıtlar: Aynı üyenin LIR hesapları arasında, mevcut bekleme kısıtı sona erdikten sonra yapılan sonraki transferler yeni bir süre başlatmaz (RIPE-831, bölüm 3.5). İade edilmesi zorunlu kaynaklar veya gönüllü transfer kilidi bulunan kaynaklar ayrıca değerlendirilir. 24 ay kuralını bütün IPv6 ve ASN kaynaklarına genellemeyin.
• Kayıt ve sorumluluk: Transfer RIPE Database’e yansıtılmalıdır; tamamlanana kadar kaynak sorumluluğu önceki sahibindedir. Geçici transferlerde kaynak döndüğünde sorumluluk geri geçer.
• Bölgeler arası işlem: Karşı RIR politikaları da önemlidir. İhtiyaç temelli politika isteyen bir bölgeden RIPE’ye transferde, kaynakların en az %50’sini beş yılda kullanma planı gerekir; bu bütün RIPE içi transferlerin genel şartı değildir.

Ek LIR hesapları ayrı bir üyelik konusudur. Güncel üyelik sayfası, 29 Eylül 2026’dan itibaren mevcut üyelerin ek LIR hesabı edinmesinin ikinci duyuruya kadar geçici olarak kısıtlandığını, hâlihazırda birden fazla hesabı olanların bunları kapatmasının gerekmediğini belirtir. Bu tarihli üst duyuru, sayfanın aşağısındaki genel çoklu hesap açıklamasından önce dikkate alınmalıdır. Her /24 sınırı LIR hesabı düzeyindedir; bunu geçmişten beri geçerli evrensel bir çoklu hesap yasağı gibi okumayın. Diğer bölgeyle karşılaştırma için ARIN tahsis ve transfer rehberini kullanın; kuralları bölgeden bölgeye taşımayın.

4) IPv6 Tahsisleri ve Büyüme Planlaması

IPv6 için ayrı politika geçerlidir: RIPE-738, ilk tahsis isteyen LIR’nin iki yıl içinde alt tahsisler ve/veya son kullanıcı atamaları yapma planı olmasını ister. Uygun LIR /32’den /29’a kadar ilk tahsisi ek büyüklük gerekçesi sunmadan alabilir; /29’dan büyük alan için belgeyle gerekçelendirme gerekir. Bu, her hosting müşterisine aynı blok büyüklüğünün verilmesi demek değildir.

Son kullanıcı atamasının büyüklüğünü LIR/ISP, ihtiyaca göre /64’ün katları olan alt ağlarla belirler; /48 ve /56 gibi seçenekler adres planında kullanılabilir. Tek bir son kullanıcı tesisine (End Site) /48’den büyük atamalar veya toplamı /48’i aşan ek atamalar, adres kullanımı ya da ek atamaların farklı yönlendirme gereksinimleriyle gerekçelendirilmelidir. Büyük adres alanına sahip olmak bağlantının hazır olduğunu göstermez. IPv6’yı hizmete almadan önce uçtan uca doğrulama gerekir:

• Router, sunucu, upstream ve dönüş yolunda IPv6 yönlendirmesi,
• IPv6’yı kapsayan firewall, erişim denetimi ve gerekli ICMPv6 işleyişi,
• Bağımsız ağlardan erişim, TLS ve uygulama testleri başarılı olduktan sonra ilgili genel hizmetin AAAA kaydı,
• IPv6’yı doğru işleyen loglar, rate-limit, izleme ve geri dönüş planı.

Yeni projelerde alt ağ şeması önce IPv6 için tasarlanabilir; IPv4 ihtiyacı ise uygulamaların erişilebilirlik gereksinimlerine göre, uygun yerlerde NAT ve paylaşımlı kullanım seçenekleriyle değerlendirilebilir. 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

Tahsis ve transfer süreçleriyle birlikte ele alınması gereken bir diğer eksen de şeffaflık ve yönlendirme güvenliği. Operasyonel planlamada şu başlıkları değerlendirin:

• IP ve ASN kaynak kayıtlarında aralık, statü, sorumlu kuruluş ve iletişim bilgisini güncel tutun.
• abuse-c, kötüye kullanım e-postası içeren role nesnesine bağlanır. Alt IP nesneleri üst nesneden kapsama alabilir; her alt blok için ayrı bir kişi/nesne oluşturmak şart değildir.
• ROA ile hangi origin AS’nin hangi prefix ve azami prefix uzunluğu için yetkili olduğunu yayımlayın. ROA, BGP duyurusunu kendisi yapmaz veya tüm ağlarda zorla filtrelemez.
• route/route6 IRR nesneleri, kaynak kayıtları, abuse irtibatı ve RPKI farklı görevler görür; upstream’in filtreleme gereksinimlerini ayrı doğrulayın.

RPKI origin doğrulamasının etkisi, yönlendiricinin aldığı veriye ve uyguladığı ROV politikasına bağlıdır. ROA, tam AS yolunu doğrulamaz ve DDoS trafiğini temizlemez. Transferde kuruluş/sertifika değişince mevcut ROA’ların kaldırılıp yeniden oluşturulması gerekebilir; yönlendirme geçişini kayıt işlemiyle koordine edin. Ağ ve sunucu güvenliği yol haritasındaki erişim, yedekleme ve saldırı müdahalesi kontrollerini ayrı yürütün.

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 koşullar pratikte ağ mimarisi, maliyet ve iş planlaması açısından ne ifade ediyor?

IPv4 Adresi Artık Stratejik Bir Kaynak

Her küçük hizmet için ayrı genel IPv4 ayırmak, sınırlı envanteri gereksiz tüketebilir. Ancak adres birleştirme de protokol, müşteri izolasyonu, e-posta itibarı ve sözleşme ihtiyaçlarına bağlıdır. IPv4 fiyatlarını ele alan yazı piyasa bağlamı sunar; bugünkü teklifi veya sürekli fiyat artışını kanıtlamaz. Bütçede güncel ve tarihli sağlayıcı/transfer tekliflerini esas alın.

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ü?

Kapasite belgenize CPU, RAM, depolama ve trafik yanında bir IP bütçesi ekleyin. Adres ihtiyacını hizmet ve lokasyona göre ayırın; gerçekten ayrılmış adres isteyen işlevleri, paylaşılabilecek uçları ve büyüme rezervini yazın. IP’nin her projede en pahalı kaynak olduğunu varsaymak yerine aynı dönem için toplam maliyeti karşılaştırın.

IPv4 Maliyetini Bütçeye Nasıl Eklemeli?

Adresin transfer bedeli veya hizmete eklenen aylık IP ücreti, toplam maliyetin yalnız bir kısmıdır. Satın alma ve kiralama tekliflerinde kapsamı, yenileme koşullarını ve taşıma giderlerini karşılaştırın. Kendi LIR hesabınızı işletiyorsanız şu kalemleri de hesaba katın:

• 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.

IPv6 adres bolluğu, IPv4 kapasite baskısını azaltabilecek bir tasarım alanı sağlar; fakat IPv6 işletimi ücretsiz değildir. Upstream desteği, donanım/yazılım uygunluğu, test, eğitim, güvenlik ve çift yığın işletim emeğini hesaba katın. Uzun vadeli büyümeyi IPv6 uyumlu planlarken IPv4-only istemcilerin ve ortak sistemlerin erişimini koruyun; dual-stack tek başına kullanılan IPv4 sayısını azaltmaz.

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 özel IPv4 ve uygun IPv6 planı: RFC1918 veya IPv6 ULA doğrudan küresel internette yönlendirilmez; genel erişim için uygun gateway, proxy veya yönlendirilebilir IPv6 adresi gerekir.

Bu yöntemleri otomatik performans veya güvenilirlik artışı olarak değerlendirmeyin. NAT bağlantı durumunu ve port kapasitesini, proxy TLS/CPU maliyetini, istemci IP bilgisini ve tek hata noktalarını etkiler. Protokol uyumluluğu, gelen bağlantılar, gözlemlenebilirlik ve yüksek erişilebilirlik testlerini tamamlayın. IPv4 NAT, tek başına IPv6-only istemci ile IPv4-only hizmet arasında çeviri sağlamaz; böyle bir ihtiyaç için uygun çeviri/proxy mimarisi ayrıca tasarlanır.

IPv6 Geçişini Nasıl Planlamalısınız?

IPv4 kıtlığı ile IPv6’nın geniş adres alanı birlikte değerlendirildiğinde, uygulama ve ağ hazırlığını erkenden yapmak yararlıdır. Burada anlatılan genel tahsis politikası bütün hosting müşterilerine tek bir IPv6 geçiş tarihi koymaz. Mevcut bağımlılıkları ve kullanıcının erişebildiği protokolleri ölçerek aşamalı ilerleyin.

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. Envanterde araştırılabilecek örnekler şunlardır; bunlar belirli bir müşteride ölçülmüş bulgular değildir:

• 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ılmadığı düşünülen IP’leri log, DNS, allowlist, felaket kurtarma rezervi ve hizmet sahibiyle doğrulayın; sözleşme ve kaynak statüsüne göre kontrollü iade veya yeniden kullanım planlayın.
4. Gereğinden geniş subnet’lerde yeniden numaralandırma, yönlendirme ve müşteri etkisini test ederek bölme seçeneğini değerlendirin.

Geri kazanılabilecek adres sayısı envantere bağlıdır; sabit bir geri kazanım yüzdesi yoktur. Önce atanmamış kapasiteyi, gerçekten kullanımdan kalkmış adresleri ve operasyonel rezervi ayrı raporlayın. Düşük kullanım tek başına bütün RIPE tahsislerinin otomatik geri alınması anlamına gelmez; kaynak statüsüne ait politika, kayıt geçerliliği ve sözleşmeler birlikte uygulanır.

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

Yeni bir uygulama için “IPv6’yı sonradan ekleriz” varsayımı yerine, ilk tasarımda destek gereksinimlerini belirleyin. DCHost dâhil değerlendirdiğiniz sağlayıcıda ürün ve lokasyonun gerçek IPv6 kapsamını yazılı olarak doğrulayın. Uygulanabilecek adımlar:

• Seçtiğiniz VPS veya dedicated sunucu için atanacak IPv4/IPv6 aralığını, gateway’i ve yönlendirme desteğini doğrulayın.
• Genel hizmeti IPv6 üzerinden dış ağlardan test ettikten sonra A kaydını ihtiyaç sürdükçe koruyup AAAA yayımlayın.
• Uygulama loglarının IPv6’yı kesmeden sakladığını ve güvenilir proxy başlıklarını doğru kullandığını test edin.
• Firewall ve WAF kapsamını IPv6 için ayrı kontrol edin; veritabanı ve yönetim portlarını sırf IPv6 mevcut diye internete açmayın.

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 alanlarını ve sürücü/ORM davranışını kontrol edin: VARCHAR(15) genel IPv6 gösterimleri için yeterli değildir. Veri tipi motor ve sürüme bağlıdır; örneğin PostgreSQL’in inet tipi IPv4 ve IPv6’yı destekler. Evrensel bir INET6 dönüşümü varsaymayın; indeksleri, karşılaştırmaları ve göçü test edin.
• IP bazlı rate-limit ve güvenlikte tek adres, prefix ve hesap/oturum bağlamını birlikte değerlendirin; bütün müşterilere tek bir IPv6 prefix uzunluğu uygulamayın.
• Log analizi ve raporlamada sıkıştırılmış gösterimler, IPv4-mapped IPv6, ağ maskeleri ve normalizasyonu doğrulayın.

Bu dönüşümü aşamalı yapabilirsiniz: önce test ortamı ve kontrollü pilot hizmet, ardından ölçümlere göre genel uçlar. Yönetim panellerini ve veritabanlarını mevcut VPN/özel ağ ve erişim denetimi sınırları içinde tutun. Her aşamada yetkilendirme, loglar, bağlantı başarısı ve geri dönüş yolunu test edin; IPv6’ya geçiş için yönetim arayüzünü halka açmak gerekmez.

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

IP kaynaklarına erişim ve işletim koşulları sadece adres seviyesinde değil, veri merkezi ve hosting stratejinizde de etkili olmalı. Burada üç temel senaryo öne çıkıyor:

• VPS ve bulut: IPv6 desteğini, verilen IPv4 sayısını, ek adres ücretini ve özel ağ seçeneklerini ürün/lokasyon bazında inceleyin.
• Dedicated sunucu: Tek sunucu ile çoklu sunucu + load balancer seçeneklerini kapasite, arıza alanı, maliyet ve bakım becerisine göre kıyaslayın. IPv6 tek başına yatay ölçeklenme veya yüksek erişilebilirlik sağlamaz.
• Colocation: Kendi ASN ve kaynaklarınız için BGP, IRR, ROA, transit ve registry işlemlerinin hangi tarafça yürütüleceğini sözleşmeye yazın; veri merkezine taşınmak bu sorumlulukları otomatik devretmez.

Bu konularda daha genel bir çerçeve çizmek isterseniz, RIPE NCC hizmetleri ve IP altyapısını ele alan makale ve “Dedicated sunucu mu VPS mi?” karar rehberimiz birlikte okunmaya değerdir.

LIR ve Hosting Müşterileri İçin Kontrol Listesi

Politika koşullarını şirketinizin adres planına çevirirken aşağıdaki kontrolleri görev sahibi ve tamamlanma tarihiyle kaydedin. Liste, tüm kaynak türlerinin aynı kurallara tabi olduğu anlamına gelmez; tahsis, müşteriye atama ve transferi ayrı iş akışları olarak yönetin.

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

• Müşteriye adres kullanım süresini, amacını, varsa alt kullanım koşullarını, iade ve yeniden numaralandırma yükümlülüklerini açıklayın. PA alanında sağlayıcı değişince adresin iadesi/renumbering gerekir; bunu PI ile karıştırmayın.
• AUP, abuse bildirimine yanıt, irtibat ve kayıt güncelleme sorumlularını belirleyin. Her atama RIPE Database’de uygun biçimde kayıtlı olmalı; AGGREGATED-BY-LIR kayıtlarında denetim için atama sayıları gösterilebilmelidir.
• Transferde kaynak sahibi, edinim tarihi, 24 ay kısıtı, olası birleşme/devralma istisnası, gönüllü kilit ve karşı RIR koşullarını kontrol eden prosedür hazırlayın.

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

• Uygun hizmetlerde aynı genel IP üzerinden birden fazla site/uygulama sunmayı hedefleyin; HTTP yönlendirmesi, SNI/TLS, müşteri izolasyonu ve hata sınırlarını test edin.
• CGNAT veya outbound proxy kullanacaksanız port/durum kapasitesini, gelen bağlantı ihtiyaçlarını ve olay kayıtlarını planlayın.
• İç ağın özel IPv4/IPv6 planını güvenlik sınırlarıyla birlikte tasarlayın; özel adres kullanımı tek başına erişim kontrolü değildir.

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.
• IPv6 erişim ve güvenlik testlerinden sonra ilgili genel hizmetin AAAA kaydını yayımlayın; gereken PTR/rDNS yetkisini sağlayıcıyla doğrulayın.

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

• IP ve ASN kayıtlarında statü, kuruluş, iletişim ve devralınan abuse-c kapsamını doğrulayın.
• Upstream’in kullanacağı doğru origin ve prefix için gerekli route/route6 nesnelerini güncel tutun; bunlar BGP duyurusu oluşturmaz.
• ROA origin ASN ve maxLength değerlerini gerçek duyurularla karşılaştırın; fazla geniş yetki vermeyin. ROV değerlendirmesini ve transfer sonrası ROA geçişini test edin.

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 Teklifinde IP Planı İçin Neleri Netleştirmeli?

DCHost üzerinden hizmet planlıyorsanız, IP ihtiyacını ürün seçimiyle birlikte değerlendirin. Bu rehber bir ürünün her lokasyonda aynı IPv6, BGP veya güvenlik özelliğini sunduğu anlamına gelmez. Teklifte mevcut hizmet kapsamını, görev paylaşımını ve ek maliyetleri açıkça belirlemek planı uygulanabilir kılar.

Teklif ve teknik görüşmede şu noktaları doğrulayın:

• VPS/dedicated: IPv4 adedi, IPv6 prefix’i, bağlantı ve lokasyon desteği; kurulumun hangi kısmının müşteriye ait olduğu.
• Colocation ve kendi kaynaklarınız: BGP oturumu, prefix filtreleri, IRR/ROA, rDNS ve transit sorumluluğu; desteklenen kaynak ve sözleşme türü.
• Adres planı: IPv4 rezervi, adres taşıma/iade şartları, IPv6 subnet şeması ve NAT/proxy ihtiyacı.
• Güvenlik: IPv4/IPv6 DDoS kapsamı, abuse irtibatı, log erişimi ve olay müdahalesi. Bunları tek bir RIPE uyumluluğu etiketiyle eşdeğer saymayın.

Sağlam bir IP planı, bekleme listesindeki /24’ü kesin teslim edilecek kapasite saymaz; mevcut envanteri, transfer koşullarını ve IPv4-only erişimi birlikte hesaplar. IPv6 hazırlığı büyüme seçeneklerini genişletir, fakat maliyet, uyumluluk ve güvenlik testlerinin yerini tutmaz. Resmî kaynakların sürümünü ve tarihli üyelik duyurularını yeniden kontrol ederek planı güncel tutun.

Yeni proje veya taşınma öncesinde hizmet listesini, kullanıcıların protokol desteğini, adres sayısını ve hedef lokasyonları hazırlayıp DCHost’a iletebilirsiniz. Böylece teknik teklifin bu ihtiyaçları nasıl karşılayacağını, kısıtları ve sorumlulukları somut olarak değerlendirebilirsiniz.

Resmî Kaynaklar

• RIPE-831: transfer procedure (2024)
• RIPE-826: IPv4 allocation and assignment (2024)
• RIPE-807: resource transfers (2023)
• RIPE-738: IPv6 allocation and assignment (2020)
• RIPE-705: abuse contact management (2018)
• RIPE NCC: using RPKI
• RFC 6811: BGP origin validation
• RFC 2993: NAT architectural implications
• PostgreSQL: network address types