IPv4 Tükenmesi Hosting Planını Nasıl Etkiler?
Bir VPS veya fiziksel sunucu seçerken CPU, RAM ve diskin yanında genel IP ihtiyacını da hesaplayın. Pakete dahil adres sayısı, ek IP ücreti ve adresin hangi hizmetlerde kullanılabildiği toplam bütçeyi değiştirebilir. Bu rehber, mevcut adresleri koruyarak büyümeyi planlamak için teknik ve ticari kontrol noktaları sunar.
IPv4 adres alanı sınırlıdır; ancak tükeniş, mevcut adreslerin çalışmayı bıraktığı ya da fiyatların sürekli yükseldiği anlamına gelmez. Bölgesel tahsis, adres devri ve sağlayıcıdan ek IP alma farklı süreçlerdir. Bir bloğun toplam devir bedeli ile hosting paketindeki aylık adres ücretini ayrı değerlendirin.
Önce tahsis geçmişini ve fiyatı etkileyen koşulları inceleyeceğiz. Ardından e-posta, web, NAT ve IPv6 seçeneklerini iki örnek mimariyle ele alıp sağlayıcıya iletilebilecek bir ihtiyaç listesi oluşturacağız. Tasarruf hedefi, gerekli erişimi ve işletim sorumluluklarını koruyan bir planın sonucudur.
IPv4 Tükenmesi: Tahsis Geçmişi ve Bekleme Listeleri
IPv4, 32 bitlik adres alanıyla yaklaşık 4,3 milyar olası adres içerir. Bu sayı, aynı miktarda kullanılabilir genel sunucu adresi demek değildir: özel kullanım ve ayrılmış aralıklar da vardır. Ayrıca her cihaz ayrı genel IPv4 kullanmaz; özel ağlar ve ortak ağ geçitleri adres paylaşımını mümkün kılar.
IANA’nın serbest havuzu 3 Şubat 2011’de son beş /8 bloğun bölgesel kayıt kuruluşlarına dağıtılmasıyla tükendi. RIPE NCC son /22 tahsisini 25 Kasım 2019’da yaptı. RIPE NCC’nin bekleme listesine göre, daha önce RIPE NCC’den hiç IPv4 tahsisi almamış uygun yerel internet kayıt kuruluşları (LIR) bir /24, yani 256 adres için başvurabilir. Tahsis, geri kazanılan adreslerin bulunmasına ve sıraya bağlıdır; anında erişim veya belirli teslim tarihi garantisi değildir.
Bu geçmişten çıkarılacak üç ayrı sonuç vardır:
- Bölgesel kayıt kuruluşlarının rezerv, bekleme listesi ve uygunluk kuralları birbirinden farklı olabilir.
- İzin verilen devirler ve geri kazanılan adreslerin yeniden tahsisi mevcut adres alanını dolaşıma sokar; yeni adres alanı üretmez.
- Mevcut bir hizmetin çalışması, yeni bir tahsis başvurusunun kabul edilmesinden ayrı bir konudur.
ARIN IP transfer politikaları rehberi devirde kayıt ve işletim görevlerini açıklar. Bir aracıya ödeme yapmak veya kiralama sözleşmesi imzalamak, ilgili kayıt kuruluşunun ve yönlendirme sağlayıcısının kabul koşullarını kendiliğinden yerine getirmez.
IPv4 Fiyatlarını Belirleyen Etkenler
Kıtlık maliyet baskısı yaratabilir; piyasa fiyatı yine de düşebilir. ARIN’de 22 Ocak 2026’da yayımlanan değerlendirme, izlenen transfer piyasasında 2025 boyunca fiyatların düştüğünü bildirir. Bu tarihli gözlem, bugünün ek-IP tarifesi veya her blok için geçerli bir teklif değildir. Kararı güncel, aynı kapsamlı teklifler üzerinden verin.
1. Adres alanı sabit, satışa çıkan miktar değişken
IPv4’ün adres alanı büyümez; buna karşılık kullanılmayan bir blok devredilebilir, kiralanabilir veya kayıt kuruluşunca geri kazanılıp yeniden tahsis edilebilir. Piyasada o anda bulunan miktar, toplam adres alanıyla aynı şey değildir.
Teklifleri değerlendirirken yalnızca “IPv4 kıt” varsayımına dayanmayın. Fiyat ve kullanılabilirlik için şu koşulları birlikte karşılaştırın:
- Blok büyüklüğü, sözleşme süresi, para birimi ve ödeme takvimi.
- Kayıt, yönlendirme, PTR yönetimi ve işlem ücretlerinin kapsamı.
- Yenileme, fesih, geri çağırma ve taşıma koşulları; ihtiyaç duyulan teslim zamanı.
2. Uygulama ve entegrasyon bağımlılıkları
Yeni bir uygulamanın IPv6 desteklemesi bütün bağlantılarının da hazır olduğunu göstermez. Genel IPv4 ihtiyacını, gerçekten kullanılan bağımlılıklara göre belirleyin:
- VPN ve site-to-site tünellerin iki ucundaki protokol ve cihaz desteği.
- Ödeme, kimlik doğrulama veya diğer dış servislerin desteklediği adres aileleri.
- İş ortaklarının sabit IPv4 izin listeleri ve değişiklik süreçleri.
E-posta itibarını kurtarma rehberi adres geçmişinin işletim tarafını açıklar. İtibar tek bir engel listesi sonucuyla ölçülemez; gönderen alan adı, izinli alıcılar, hacim ve alıcı tepkisi de önemlidir. “Temiz” diye satılan bir adres, teslim garantisi vermez.
3. IPv6 geçişinin uygulama maliyeti
IPv6’nın 128 bitlik adres alanı IPv4’ten çok daha büyüktür. Kullanıma geçiş ise yönlendirme, güvenlik duvarı, uygulama, izleme ve destek süreçlerinin birlikte hazırlanmasını gerektirir. Sırf IPv6 adresi almak, bütün servisleri IPv6 üzerinden erişilebilir yapmaz.
IPv6 benimsemesini planlama rehberi bu geçişin aşamalarını ele alır. Başlangıç noktası genel bir benimseme yüzdesi değil, kendi kullanıcılarınızın ve bağımlı sistemlerinizin erişim sonuçları olmalıdır.
4. Fiyat beklentisi ve satın alma zamanlaması
Gelecekteki fiyatı kesin kabul ederek gereğinden büyük bir blok edinmeyin. Kullanım için gerekli adresleri, kapasite yedeğini ve yalnızca fiyat beklentisine dayanan talebi ayrı yazın. Fiyatın yükseldiği, sabit kaldığı ve düştüğü senaryolarda toplam gideri hesaplayın.
IPv4 adres fiyatlarının seyri ve IPv4 maliyetlerini değerlendirme yazıları ilgili kararları genişletir. Tarihî fiyat ifadelerini güncel teklif yerine kullanmayın; bu rehberin devamı adres ihtiyacının nasıl azaltılabileceğine odaklanır.
Hosting Maliyetinde Adresin Payını Hesaplayın
VPS paket bedelinin değişmemesi toplam faturanın sabit kalacağı anlamına gelmez. Adres sayısı, ek hizmetler ve sözleşme koşulları gideri değiştirebilir. Önce hangi ücretin tahsise, hangisinin trafiğe veya yönetilen hizmete bağlı olduğunu ayırın.
1. Paket ve ek IP koşulları
Sağlayıcı tekliflerinde karşılaşabileceğiniz modelleri aynı kabul etmeyin:
- Belirli sayıda genel IPv4 içeren paket.
- Ek IPv4 için ayrı ücret ve tahsis uygunluğu değerlendirmesi.
- Paylaşımlı NAT veya yalnızca IPv6 sunan, gelen bağlantı koşulları farklı hizmet.
Bu modellerin mevcut olup olmadığını ve seçtiğiniz ürün/konumdaki sınırlarını sağlayıcıdan doğrulayın. Ek IP ücreti kadar bağlantı modeli, port erişimi ve adres iadesinde ücretin ne zaman duracağı da kararın parçasıdır.
2. E-posta adresi ve itibar yönetimi
E-posta için ayrı IP ihtiyacını gönderim hacmi ve düzenine göre değerlendirin. Düşük hacimde iyi yönetilen ortak bir gönderim hizmeti uygun olabilir. Her gönderim akışına ayrı IP eklemek, yeterli düzenli hacim oluşturmayı ve itibarı izlemeyi zorlaştırabilir.
- Ayrı adres kararı, işlem ve pazarlama mesajlarının hacim ve itibar gereksinimlerine dayanmalıdır.
- Yeni adreste gönderimi kademeli artırın; geçici ret, kalıcı hata ve şikâyetleri izleyin.
- Engel listesi veya kötüye kullanım sorununun nedenini giderin. Yalnızca adres değiştirmek, ele geçirilmiş hesabı veya izinsiz gönderimi düzeltmez.
SPF, DKIM, DMARC ve rDNS rehberi kimlik doğrulama ve DNS kontrollerini; e-posta itibarı rehberi hata sonrası düzeltmeleri açıklar. IPv6 ile e-posta teslimi rehberi ise ikinci adres ailesindeki koşulları ele alır. Alıcı desteğini ve gerçek teslim sonuçlarını doğrulamadan gerekli IPv4 yolunu kaldırmayın.
3. DDoS ve kötüye kullanımın farklı etkileri
Bir IP’nin DDoS hedefi olması ile o IP’den spam veya kötü amaçlı trafik çıkması farklı olaylardır. İlkinde erişim kapasitesi ve saldırı azaltma, ikincisinde kaynağın durdurulması ve itibar düzeltmesi öne çıkar. DDoS tehditleri rehberi kapasite ve savunma planlamasına yardımcı olur; hedef alınmak tek başına kötü gönderici itibarı kanıtı değildir.
Teklifte DDoS kapsamını, trafik sınırlarını, erişimin kesilmesi veya kara delik yönlendirme koşullarını ve kötüye kullanım bildirimlerinin sorumlusunu sorun. Her ürünün aynı korumayı sunduğunu varsaymayın. Olay müdahalesi ve bildirim yükümlülüklerini sözleşmede netleştirin.
4. Colocation ve dışarıdan adres getirme
Colocation için dışarıdan blok edinmeden önce hangi adres modelinin desteklendiğini doğrulayın:
- Sağlayıcının sunduğu ve hizmete tahsis ettiği adresleri kullanmak.
- Kullanım yetkiniz olan dış bir bloğu, sağlayıcının kabul ettiği yönlendirme düzeniyle getirmek; kendi ASN’niz veya sağlayıcı ASN’si seçimi ayrıca kararlaştırılır.
BYOIP/adres getirme desteğini, kabul edilen önek büyüklüğünü, hizmet/konum sınırlarını ve PTR yönetimini yazılı olarak teyit edin. Duyuracak ASN, yetki belgesi ve gerekli yönlendirme kayıtları önceden belirlenmelidir. ROA kullanılıyorsa origin ASN ve önek uzunluğu uygun olmalıdır; RPKI origin doğrulaması bütün AS yolunu doğrulamaz.
IPv6 ve NAT ile Adres İhtiyacını Azaltma Seçenekleri
Aşağıdaki modeller farklı bağlantı ihtiyaçlarını karşılar. Hangisinin tasarruf sağlayacağı mevcut ücretli tahsise, yedekliliğe ve yeni gateway/proxy giderlerine bağlıdır. Uygulama uyumluluğu doğrulanmadan bir modeli bütün hizmetlere uygulamayın.
1. Dual-stack ile iki adres ailesini işletmek
Dual-stack, IPv4 ve IPv6 erişimini birlikte sunar. IPv6 yönlendirmesini, TLS dinleyicilerini ve güvenlik kurallarını dışarıdan test ettikten sonra AAAA kaydını yayımlayın. İzlemeyi iki adres ailesi için ayrı çalıştırın.
- Destekleyen istemciler, bağlantı koşullarına ve istemci davranışına göre IPv6’yı kullanabilir.
- IPv4 yolu, gerekli istemci ve entegrasyonlar için korunur.
- IPv6 trafik payının artması, mevcut ücretli IPv4 tahsislerini kendiliğinden azaltmaz.
IPv6 benimseme ve geçiş planı için başarı ölçütüne yalnızca trafik payını değil bağlantı hatası, gecikme ve işletim yükünü de ekleyin. Tasarrufu ancak tahsis sayısı veya ücret gerçekten değiştiğinde kaydedin.
2. IPv6 arka uç ve çift protokollü giriş katmanı
Uygun web uygulamalarında giriş katmanı IPv4 ve IPv6 kabul ederken arka uç IPv6 kullanabilir. Bunun için:
- Yük dengeleyici veya ters proxy, istemcilerden iki adres ailesiyle bağlantı alabilmelidir.
- Arka uca giden bağlantılar, sağlık kontrolleri ve gerekli veritabanı/servis bağımlılıkları IPv6 ile çalışmalıdır.
- Arka uç erişimi güvenlik kurallarıyla sınırlandırılmalıdır; IPv6 adresi olması iç servisi herkese açmak anlamına gelmez.
Bu model arka uç başına genel IPv4 tahsisini önleyebilir. Arka uç zaten özel IPv4 kullanıyorsa yalnızca IPv6’ya geçmek aynı tasarrufu doğurmaz. Giriş katmanının adresleri, kapasitesi ve yedekli kurulumu toplam hesapta kalır.
3. NAT64/DNS64: IPv6’dan IPv4 hedeflere çıkış
Yaygın NAT64/DNS64 düzeninde IPv6 istemci, DNS64’ün ürettiği AAAA yanıtı ve NAT64 çeviricisi üzerinden IPv4 hedefe bağlantı başlatır. Bu, IPv4 kullanıcıların IPv6-only web sunucunuza kendiliğinden ulaşacağı anlamına gelmez. Gelen IPv4 erişimi için IPv4 kabul edip IPv6 arka uca bağlanan uygun bir proxy/CDN gibi ayrıca tasarlanmış bir yol gerekir. IPv6-only VPS rehberini bu iki trafik yönünü ayrı değerlendirerek okuyun.
Pilotun kabul ölçütlerini şu noktalara bağlayın:
- Uygulamanın DNS kullanımı, adres ailesi desteği ve IPv4 adresi doğrudan yazılmış bağlantıları test edilmelidir; DNS64 tek başına bütün uygulama uyumsuzluklarını çözmez.
- DNSSEC doğrulaması ile DNS64 sentezinin birlikte çalışma biçimi seçilen resolver düzeninde doğrulanmalıdır.
- Çeviri/proxy kapasitesi, ortak IPv4 adresleri, kayıt tutma ve hizmet ücretleri hesaplanmalıdır; otomatik net tasarruf varsayılmamalıdır.
4. Özel ağ, NAT ve port paylaşımı
Her hizmetin doğrudan genel IPv4 ile erişilmesi gerekmez. Şu iş yükleri uygun adaylar olabilir:
- Erişimi VPN veya yetkili proxy ile sınırlandırılmış geliştirme ve test ortamları.
- Yalnızca dışarıya bağlantı açan servisler.
- Özel ağda birbirine bağlanan iç entegrasyonlar.
Ortak NAT çıkışında eşzamanlı bağlantı ve port kapasitesini, zaman aşımlarını ve arıza etkisini ölçün. Gelen bağlantılarda port yönlendirme ile HTTP alan adı/yol yönlendirmesi farklı yöntemlerdir. Ayrı portlar ve NAT tek başına güvenlik yalıtımı sağlamaz; kimlik doğrulama, filtreleme ve olayın kaynağını belirleyecek zaman/adres/port/protokol kayıtları gerekir.
Kaç Genel IPv4 Gerekiyor? İki Örnek Mimari
Aşağıdaki örnekler doğrulanmış müşteri uygulamaları veya sabit kapasite önerileri değildir. Kendi gereksinimlerinizi yerleştirebileceğiniz varsayımsal taslaklardır. Önce dört soruyu yanıtlayın:
- Hangi alan adları SNI ve sanal sunucularla aynı giriş adresini paylaşabilir?
- Hangi e-posta veya dış bağlantı için ayrı kaynak adresi/PTR yönetimi gerekir?
- Hangi servisler yalnızca dışarıya bağlantı açar ve ortak NAT kullanabilir?
- Geliştirme, staging ve üretim arasında gerekli erişim ve arıza yalıtımı nasıl sağlanacak?
Örnek 1: E-ticaret uygulaması
Varsayımsal bir mağazada şu bileşenler bulunsun:
- Web arayüzü ve uygulama arka ucu.
- Veritabanı.
- Yönetim paneli.
- API alt alan adı.
- Sipariş bildirimleri için e-posta gönderimi.
Her bileşene ayrı genel IPv4 vermek yerine bağlantı akışlarını ayırın:
- Web ve API, doğru sertifika kapsamı ve SNI eşlemesiyle ortak ters proxy üzerinden sunulabilir; yönetim erişimi ayrıca kısıtlanır.
- Veritabanı özel ağda tutulabilir; gereken uygulamalara kontrollü erişim verilir.
- Gönderim hacmine göre yönetilen ortak e-posta hizmeti veya ayrı gönderim adresi seçilebilir; ayrı IP teslim garantisi değildir.
Yedeklilik ve diğer dış bağlantıları kapsam dışı bırakan bu basitleştirilmiş örnekte bir web giriş IPv4’ü, kendi e-postası işletiliyorsa ayrıca bir gönderim IPv4’ü düşünülebilir. Bu sayı bir üretim reçetesi değildir: yüksek erişilebilirlik, sabit çıkış izin listeleri ve bölge gereksinimi artırabilir. Saldırı yüzeyini azaltan şey yalnızca adres sayısı değil erişim politikasıdır.
Örnek 2: Çok kiracılı SaaS
Bir SaaS uygulamasında müşteriye özel alan adı, her müşteri için ayrı IP gerektirmez. Örnek akış:
- Bir veya birkaç giriş adresi web trafiğini uygun kapasitedeki proxy katmanına alır.
- Müşteri alt alan adları aynı girişe yönlendirilir; özel alan adlarının sahipliği doğrulanır ve sertifikaları hazırlanır.
- Alan adı veya URL yolu izin verilen tenant kaydıyla eşleştirilir; veri erişiminde kimlik doğrulama ve tenant yetkisi ayrıca denetlenir.
Host başlığı veya URL yolu tek başına kiracı yalıtımı değildir. Alan adı sahipliği, sertifika yenileme, tenant eşlemesi ve uygulama yetkilendirmesini birlikte test edin. SaaS’te özel alan adları ve otomatik SSL rehberi DNS-01 ile sertifika yönetimini ele alır. Paylaşımlı girişin kapasitesi ve arıza alanı müşteri sayısına göre ölçülmelidir.
Envanterden değişiklik planına
Uygulama öncesi kontrol listesini her servis için doldurun:
- Hizmet sahibini, adresi, DNS/PTR kayıtlarını, dış izin listelerini ve ücretini kaydedin.
- Gelen ve giden bağlantıların adres ailesini ve zorunlu genel erişimini belirleyin.
- Paylaşım için sertifika, protokol, kapasite, güvenlik ve yedeklilik koşullarını doğrulayın.
- Seçilen mimariyi pilotta test edin; kabul ölçütü, sorumlu ve geri dönüş planı belirleyin.
- DNS/bağımlılık geçişini gözleyip eski tahsisi ancak ihtiyaç bitince iade edin; ücretin durduğu tarihi teyit edin.
Sağlayıcı Teklifini Teknik İhtiyaçla Eşleştirin
DCHost veya başka bir sağlayıcıyla görüşürken ihtiyaç listenizi ürün, konum ve kullanım senaryosuyla birlikte paylaşın. Bu yazı, belirli bir pakette IPv4/IPv6 tahsisi, BYOIP veya yönetilen güvenlik hizmetinin bulunduğuna dair taahhüt değildir. Kararı seçilen hizmet için teyit edilmiş kapsam üzerinden verin.
1. Fatura ve adres yaşam döngüsü
Teklifte şu bilgilerin ayrı ayrı bulunmasını isteyin:
- Pakete dahil adres sayısı, ek adres bedeli ve tahsis için gereken gerekçe/uygunluk koşulları.
- Kurulum, yenileme, trafik ve yönetim ücretleri; adres iadesi ve ücretin durma zamanı.
- Adres değişikliği, hizmet taşıma ve fesih halinde bildirim süresi ve sorumluluklar.
Bunları aynı süre ve para biriminde karşılaştırın. Birleşik giriş katmanı veya NAT ekleniyorsa yeni hizmet giderlerini de toplam maliyete yazın; azalan adres satırı tek başına net tasarrufu göstermez.
2. IPv6 kapsamı ve test sorumluluğu
IPv6 desteğini genel bir evet/hayır yanıtıyla değerlendirmeyin. Seçtiğiniz hizmet için ayrıntıları netleştirin:
- Verilen önek/adres, yönlendirme, ağ geçidi ve ters DNS yönetimi.
- Yük dengeleyici/CDN, güvenlik duvarı, izleme ve teknik destek kapsamı.
- IPv4 ve IPv6 için dış bağlantı testleri, hata takibi ve değişiklik sonrası geri dönüş sorumlusu.
3. Olay yönetimi ve adres geçmişi
Adresin bugün bir listede görünmemesi gelecekte sorunsuz çalışacağını kanıtlamaz. İşletim süreci için:
- Kötüye kullanım bildirimlerinin hangi kanalla ve kimin tarafından ele alınacağını belirleyin.
- DDoS kapsamını ve saldırı sırasında hizmetin sınırlandırılabileceği koşulları inceleyin.
- PTR yetkisini, e-posta hata takibini ve gerektiğinde engel listesi düzeltmesinin sorumlusunu netleştirin.
Sorun çıktığında önce kaynağı düzeltin ve sonucu doğrulayın. Yeni IP’ye geçmek, ele geçirilmiş bir servisi güvenli hale getirmez. Paylaşımlı adresin diğer hizmetler üzerindeki etkisini de olay kaydına ekleyin.
4. Değişiklik ve büyüme planı
Teknik tasarımın yanında işletim takvimi de belirleyin:
- Büyüme için yeni adres gerektiren kullanım eşiğini ve tedarik süresini kaydedin.
- DNS değişikliği öncesinde TTL’yi düşürüp önceki TTL süresini bekleyin; yeni değer mevcut önbellekleri anında değiştirmez.
- Eski adresi bırakmadan önce gerçek trafik, uzun bağlantılar ve dış izin listelerinin yeni yola geçtiğini gözleyin.
İlk Adım: Ölçülebilir Bir Adres Değişikliği Seçin
IPv4 tükenişi, mevcut projeleri aceleyle taşımayı gerektirmez. Sağlıklı çalışan hizmetleri korurken yeni tahsis ihtiyacını ve kullanım nedeni kalmamış adresleri görünür hale getirin. Önceliği maliyet, risk ve uygulama emeğini birlikte değerlendirerek belirleyin.
İlk pilot tek bir eski staging tahsisinin kaldırılması, SNI ile giriş paylaşımı veya küçük bir dual-stack dağıtımı olabilir. Bunların farklı sonuçları vardır: biri doğrudan adresi serbest bırakabilir, diğeri gelecekteki geçişe hazırlık sağlar. Başarı ölçütünü baştan yazın.
DCHost’tan seçtiğiniz hizmet için teklif isterken adres envanterini, gerekli protokolleri, konumu ve hedef geçiş tarihini iletin. Ürün kapsamı teyit edildikten sonra test ve geri dönüş adımlarını planınıza ekleyin.
Pilot sonrası tahsis sayısını, faturayı, bağlantı hatalarını ve işletim yükünü karşılaştırın. Sonraki adımı fiyatın mutlaka yükseleceği beklentisine değil, bu ölçümlere ve gerçek büyüme ihtiyacına bağlayın.
