IPv6-only sunucular: hosting geleceği mi, ne zaman mantıklı?

IPv6-only (sadece IPv6 ile erişilen) sunucular bugün “gelecek” tartışmasının merkezinde. Ancak hosting tarafında asıl soru şu: IPv6-only kurulduğunda erişilebilirlik ve işletme maliyeti gerçekten iyileşiyor mu? Bu yazıda IPv6-only altyapının neyi değiştirdiğini; DNS, güvenlik duvarı, TLS/SSL, yük dengeleme ve uygulama katmanında hangi somut adımları gerektirdiğini net biçimde ele alacağım. Son bölümde ise hangi senaryolarda IPv6-only’a geçmenin mantıklı olduğunu maddeler halinde karar çerçevesi olarak vereceğim.

IPv6-only ne demek? IPv4 yok mu?

IPv6-only sunucuda istemciler ve sunucu arasında iletişim yalnızca IPv6 üzerinden kurulur. Bu, iki farklı modele ayrılır:

Gerçek IPv6-only: Sunucunun arayüzlerinde IPv4 adres bulunmaz. Sunucu tarafında IPv4 ile bağlantı kabul edilmez.
IPv4 kapalı ama köprü var: Sunucu IPv4 konuşmaz; fakat sağlayıcı tarafında (örn. NAT64/DNS64 veya dual-stack proxy) istemciyi IPv6’a yönlendiren bir mekanizma bulunabilir. Bu modelde “IPv4 yok” görünse bile kullanıcı deneyimi IPv4 erişimi taklit edebilir.

NetKıyas’ta kullanıcılar genelde “IPv6-only alırsam her şey sorunsuz çalışır mı?” sorusunu soruyor. Cevap; hedef kitle, uygulama bağımlılıkları ve kullandığınız CDN/WAF/Load Balancer davranışlarıyla doğrudan ilişkilidir.

IPv4 tüketimi neden azalıyor?

IPv6-only’a geçişin maliyet boyutu önemli. IPv4 adres havuzu sınırlı olduğu için bazı sağlayıcılar IPv4 adreslerini ayrı bir kalem olarak fiyatlayabilir veya sınırlı kapasite nedeniyle ek ücretlendirebilir. IPv6’da adres alanı geniş olduğu için aynı ölçekle daha az “adres kıtlığı” sorunu yaşanır.

IPv6-only performansı: beklenen kazanımlar ve gerçek kontrol noktaları

IPv6-only genellikle “daha hızlı” diye pazarlanır; fakat pratikte hız kazancı iki kanaldan gelir:

Yol (routing) ve veri merkezi trafiği: Bazı bölgelerde IPv6 peering ve hat kalitesi IPv4’e göre daha iyi olabilir.
Tercüme maliyeti (translation): Eğer IPv4 istemciler IPv6-only’a erişiyorsa ve sağlayıcı çeviri mekanizması (NAT64/DNS64) kullanıyorsa, çeviri katmanı bazen ek gecikme veya sorun çıkarabilir.

Bu yüzden “IPv6-only daha hızlıdır” yerine şu ölçümü hedefleyin:

TTFB (Time to First Byte): Sunucu uygulama yanıt hızı.
TLS handshake süresi: IPv6 bağlantısında sertifika doğrulama ve oturum kurulumu.
İlk sayfa yükü: LCP ve INP gibi Core Web Vitals (özellikle mobil ağlarda).

Ne test etmelisiniz?

IPv6-only’a geçmeden önce, geçiş hedefinizin doğrulanması gerekir. Aşağıdaki kontrol listesini uygulayın:

Sunucuya IPv6 ile bağlanabiliyor musunuz?
Uygulama katmanınız (ör. Nginx/Apache, uygulama sunucusu) IPv6 socket’lerini doğru dinliyor mu?
DNS kayıtlarınız AAAA doğru mu?
TLS/SSL sertifikanız IPv6 üzerinde sorunsuz çalışıyor mu?
CDN/WAF (kullanıyorsanız) IPv6 trafiğini doğru upstream’e taşıyor mu?

Erişilebilirlik riski: IPv4 istemciler için ne olur?

IPv6-only’un en kritik tarafı erişilebilirliktir. Kullanıcı kitlenizin ne kadarının IPv4 kullanabildiğini bilmeden “IPv6-only geçelim” demek risklidir.

Erişilebilirlikte iki durum vardır:

Hedef kitleniz ağırlıkla IPv6 kullanıyorsa: sorunsuz geçiş olasılığı yüksektir.
Hedef kitleniz IPv4 ağırlıklıysa: çeviri mekanizmaları devreye girer ve hata ihtimali artar.

DNS64/NAT64 tam olarak neyi etkiler?

Birçok geçiş stratejisinde DNS64/DNS46? (doğru kavram DNS64) ve NAT64 üzerinden IPv4 istemciler IPv6-only hizmete ulaştırılır. Süreç kabaca şöyledir:

IPv4-only bir istemci DNS sorgusu yapar.
DNS64, A kayıtlarını taklit ederek AAAA üretir.
NAT64, IPv4 paketlerini IPv6’ya çevirir.

Bu mekanizma doğru yapılandırılmadığında şu sorunlar görülür:

Bazı uygulama uç noktalarında bağlantı kurulamaması
Belirli tarayıcılarda veya mobil operatörlerde kısa süreli erişim kesintileri
Bazı firewall kurallarının çeviri trafiğini yanlış değerlendirmesi

TLS/SSL ve sertifika tarafı: IPv6-only’da sık yapılan hatalar

IPv6-only geçişte TLS tarafı genelde sorun çıkarmaz; fakat üç somut noktaya dikkat etmezseniz hızlı hatalar görebilirsiniz:

Sertifika doğrulama yöntemi: HTTP-01 yerine DNS-01 tercih etmek bazı senaryolarda daha stabildir.
SNI ve vhost eşleşmesi: Nginx/Apache vhost’lar IPv6 dinleme portu ile doğru eşleşmeli.
Orta katmanlar: CDN/WAF varsa, “client-ip” ve upstream yönlendirmesi IPv6 formatında doğru taşınmalı.

Net kontrol: Hangi portların IPv6’da dinlediğini doğrulayın

Sunucunuzda IPv6 dinleme kontrolü için tipik yaklaşım şudur:

Web sunucusu (örn. Nginx) listen [::]:443 gibi IPv6 dinlemeyi yapmalı.
Uygulama servisleri (örn. Node.js, Java) reverse proxy ile doğru bağlantı kurmalı.

DNS mimarisi: AAAA kayıtları tek başına yeterli mi?

IPv6-only’a geçişte DNS tarafı “AAAA ekledim oldu” seviyesinde kalmamalı. Aşağıdaki hedefler net olmalı:

IPv6 kullanıcıları için AAAA kayıtları doğru TTL ile yayınlanmalı.
Dual-stack veya geçiş sürecinde A kayıtlarının kaderi planlanmalı.
Reverse DNS (PTR) gerekiyorsa (bazı mail/repütasyon sistemlerinde), sağlayıcı ile uyum kontrol edilmeli.

AAAA TTL’i nasıl seçilmeli?

Taşıma/yeniden yönlendirme sık yapılıyorsa TTL kısa tutulur (örn. 300-600 sn). Daha stabil bir ortamdaysa TTL uzatılır. Buradaki amaç, arıza anında DNS geri dönüşünü hızlandırmaktır.

Güvenlik duvarı ve erişim kontrolü: IPv6 kuralları farklı mı?

Evet, pratikte farklı. IPv4 için yazdığınız kural mantığı IPv6’ya otomatik uygulanmaz. Şu konular sık görülür:

Firewall’da IPv6 chain’leri ayrı olabileceği için kuralların hiç çalışmaması
Geo/IP bazlı kural setlerinin IPv6 adres uzaylarını eksik kapsaması
Rate limit (ör. fail2ban, WAF kuralları) log formatlarının IPv6 için beklenenden farklı gelmesi

Kontrol listesi (geçiş öncesi)

Uygulama portlarınız (80/443 vb.) IPv6 üzerinde erişilebilir mi?
SSH/Panel gibi yönetim arayüzleri IPv6’da açık mı? Açık ise kısıtlı mı?
WAF/Anti-DDoS varsa IPv6 trafik imzası ve threshold ayarları güncel mi?

Uygulama uyumluluğu: hangi yazılımlar daha fazla etkilenir?

IPv6-only geçişte en çok etkilenen bileşenler genelde şunlardır:

IP adresi formatını program içinde statik kullanan uygulamalar
Bağlantı kurulumunda IPv4’ü sabitleyen kütüphaneler
Allowlist/whitelist mantığı sadece IPv4 CIDR’lerine göre yapılandırılmış servisler

Net test yöntemi

Geçiş öncesinde staging ortamınızda şu senaryoları deneyin:

Uygulama dışarıdan bir endpoint’e bağlanıyor mu? (örn. API çağrısı) IPv6 çözümleme (AAAA) çalışıyor mu?
Veri tabanı bağlantısı IPv6 adres üzerinden kurulabiliyor mu?
Log/monitoring araçları IPv6 formatını doğru parse ediyor mu?

Net karar: IPv6-only’a ne zaman geçmek mantıklı?

Aşağıdaki tablo karar vermeyi hızlandırır.

Senaryo	IPv6-only yaklaşımı	Gerekçe
Kitle belirgin şekilde IPv6 ağırlıklı	Önerilir	Erişilebilirlik riski düşüktür, çeviri ihtiyacı azalır.
CDN/WAF/Load balancer uçlarında IPv6 güçlü	Önerilir	Upstream yönlendirme ve TLS akışı daha kontrollüdür.
IPv4 kullanım kitlesi yüksek, erişim kesintisi maliyeti yüksek	Aşamalı geçiş şart	DNS64/NAT64 davranışı test edilmeden “tek hamle” risklidir.
Uygulamada IP bağımlılıkları var (allowlist, sabit IP)	Geçiş öncesi refactor	Kod ve kural setleri IPv6 uyumlu yapılmadan geçiş yapılamaz.
İçerik statik + edge cache yoğun	Orta/uygun	Az sayıda dinamik bağlantı varsa risk düşer.
Mail/VoIP gibi protokoller	Planlı doğrulama	Reverse DNS, MX/AAAA ve erişim kuralları birlikte ele alınmalıdır.

Aşamalı geçiş için 3 adım

Hazırlık (staging + ölçüm): IPv6-only altyapıda TTFB ve hata oranlarını karşılaştır.
DNS kademesi: İlk aşamada AAAA’yı aktif et; erişim gözlemi yap.
Kademeli IPv4 azaltma: A kayıtlarını tamamen kaldırmadan önce belirli bir süre trafik ve hata trendini doğrula.

Maliyet açısından gerçekçi çerçeve: sadece fiyat etiketi değil

IPv6-only çoğu zaman IPv4 adres maliyetini düşürür. Ancak toplam maliyet şu bileşenlerden oluşur:

Sunucu/plan fiyatı (VDS/VPS veya managed ortam)
Load balancer/CDN/WAF ücretleri (varsa)
İşletme maliyeti (izleme, olası düzeltmeler, geçiş süresi)
Sertifika yenileme/otomasyon maliyeti (operasyon)

Bu yüzden en iyi yaklaşım “IPv6-only daha ucuzdur” demek yerine şudur:

IPv4 adres maliyet kalemi sağlayıcınızda ayrı ise: toplam maliyet farkı genellikle belirgin olur.
Ancak çeviri gerekecekse ve destek/arıza maliyeti artacaksa: tasarruf netleşmeyebilir.

Sonuç: IPv6-only hosting geleceği mi?

IPv6-only hosting “her yerde hemen” doğru cevap değildir; doğru kullanım senaryosunda ise net bir avantaj sunar. Gerçekçi karar için iki şeyi birlikte düşünün: kullanıcı erişim profili (IPv6 oranı) ve altyapı uyumu (DNS/TLS/firewall ve uygulama bağımlılıkları). Eğer hedef kitleniz IPv6 ağırlıklıysa veya CDN/WAF uçlarınız IPv6 trafiğini sorunsuz taşıyorsa IPv6-only’a geçiş, hem operasyonel netliği hem de olası maliyet düşüşünü güçlendirir.

Aksiyon önerisi: Önce staging ortamında AAAA tabanlı test yapın, TTFB ve hata oranlarını ölçün, ardından DNS’te kademeli olarak geçin. Bu sıralama, “gelecek için doğru teknoloji” seçiminizi ölçülebilir sonuçlarla doğrular.