IPv6 Neden Yaygınlaşmadı? Geçiş Süreci

2003 yılında bir veri merkezinde IPv6 için ilk konfigürasyonu yaptığımda, “beş yıl içinde her şey IPv6’ya geçmiş olur” diye düşünüyordum. Yirmi yıl geçti. Hâlâ aynı cümleyi kuruyoruz. Bu yazıda neden böyle olduğunu, teknik borçlar ve operasyonel gerçekler üzerinden konuşacağız.

IPv4’ün Ölmediği Gerçeği

IANA’nın son IPv4 bloğunu dağıtması 2011’di. Bölgesel kayıt kuruluşları (RIR) da stoklarını bitirdi sırayla. Teorik olarak IPv4 bitmeli, IPv6’ya geçiş zorunlu hale gelmeliydi. Ama olmadı. Çünkü NAT devreye girdi ve aslında tam anlamıyla bir yara bandı olan bu teknoloji, sistemi on yıllar boyunca ayakta tuttu.

Bugün bir kurumsal ağda tipik topolojiyi düşünün: Binlerce iç cihaz, birkaç public IP, ortada bir NAT gateway. Bu yapı “çalışıyor”. Çalıştığı sürece de kimse dokunmak istemiyor.

Gerçek şu ki IPv6 geçişinin önündeki en büyük engel teknik değil. İnsan psikolojisi ve operasyonel risk toleransı.

NAT’ın Yarattığı Konfor Tuzağı

NAT, IPv6’nın en büyük rakibi oldu. İşte bu noktada çoğu ağ mühendisi “ama NAT güvenlik sağlamıyor ki” diye itiraz eder. Doğru. Güvenlik için değil, adres tasarrufu için kullanılıyor. Ama yan etkisi olarak bir tür “doğal güvenlik duvarı” algısı yarattı.

Şu anda çalıştığım ortamda, legacy uygulama sunucularından birinin sadece iç ağdan erişilebilir olduğu varsayımıyla kritik portlar açık bırakılmış. Bu “güvenlik” tamamen NAT sayesinde. IPv6’ya geçsek ve her cihaz public bir adres alsa, bu sunucu anında internete açılır.

# Mevcut NAT durumunu görmek için
iptables -t nat -L -n -v

# IPv6'da NAT yerine geçecek olan yapı için ip6tables kontrol
ip6tables -L -n -v

# Dual-stack durumunu hızlıca kontrol etmek
ip -6 addr show
ip -6 route show

IPv6 ile birlikte her cihaz kendi global adresini alıyor. Bu teoride harika, pratikte mevcut güvenlik modelinizi tamamen yeniden tasarlamanız gerekiyor demek. Çoğu organizasyon bu maliyeti göze alamıyor ya da almak istemiyor.

Geçiş Mekanizmaları: Teoride Güzel, Pratikte Kabus

IPv4’ten IPv6’ya geçiş için onlarca mekanizma tanımlandı. Dual-stack, 6to4, Teredo, ISATAP, DS-Lite, MAP-T, MAP-E… Bu listenin uzunluğu bile sorunun bir göstergesi.

Dual-Stack Yaklaşımı

En mantıklı geçiş yöntemi dual-stack. Her cihaz hem IPv4 hem IPv6 çalıştırıyor. Ama bu demek oluyor ki ağınızdaki her bileşeni iki protokol için yönetmeniz gerekiyor.

# Ubuntu/Debian üzerinde dual-stack interface konfigürasyonu
# /etc/netplan/00-installer-config.yaml örneği

cat /etc/netplan/00-installer-config.yaml

network:
  version: 2
  ethernets:
    eth0:
      addresses:
        - 192.168.1.100/24
        - 2001:db8:1::100/64
      gateway4: 192.168.1.1
      routes:
        - to: ::/0
          via: 2001:db8:1::1
      nameservers:
        addresses:
          - 8.8.8.8
          - 2001:4860:4860::8888

# Konfigürasyonu uygula
netplan apply

# Doğrulama
ping6 -c 4 2001:4860:4860::8888
tracepath6 2001:4860:4860::8888

Dual-stack’in sorunu şu: Her iki protokolü de tam olarak izlemeniz, güvenlik politikalarını her ikisi için de uygulamanız gerekiyor. Bir sysadmin olarak söylüyorum, iki kez iş yapmak demek bu. Monitoring sistemleriniz, IPAM araçlarınız, firewall kurallarınız, tüm bunların IPv6’yı anlaması gerekiyor.

Tünel Mekanizmaları

6to4 ve benzeri tünel çözümleri teoride IPv4 altyapısı üzerinden IPv6 trafiği taşıyor. Pratikte performans sorunları, NAT arkasında çalışmama problemi ve güvenlik açıkları nedeniyle önerilmiyor artık.

# 6in4 tüneli manuel kurulum örneği (HE.net benzeri servisler için)
ip tunnel add he-ipv6 mode sit remote [UZAK_IPv4] local [YEREL_IPv4] ttl 255
ip link set he-ipv6 up
ip addr add 2001:db8::2/64 dev he-ipv6
ip route add ::/0 dev he-ipv6
ip -f inet6 addr

# Tüneli kaldırmak için
ip tunnel del he-ipv6

Bu komutları çalıştırdığınızda aslında bir şey fark edersiniz: Tünel ayakta duruyor, traceroute’da garip gecikmeler görüyorsunuz, MTU sorunları çıkıyor. Gerçek dünyada tünel çözümleri nadiren sorunsuz çalışır.

ISS Tarafı: Türkiye’de Durum

Türkiye’deki internet servis sağlayıcılarının IPv6 dağıtım oranlarına bakıldığında tablo pek iç açıcı değil. Büyük ISS’lerin bir kısmı IPv6 altyapısını kurmuş durumda ama son kullanıcılara dağıtmıyor ya da çok kısıtlı dağıtıyor.

Neden? Birkaç somut sebep:

CPE (müşteri tarafı ekipman) sorunu: Sahada on yıllık modem/router var, bunların büyük çoğunluğu IPv6’yı düzgün desteklemiyor
DHCPv6 altyapısı: Milyonlarca müşteriye prefix delegation yapmak ciddi altyapı yatırımı gerektiriyor
Destek maliyeti: IPv6 ile gelen sorunları çözecek teknik destek ekibini yetiştirmek zaman alıyor
“Çalışıyor, dokunma” kültürü: Mevcut IPv4 altyapısı ayakta olduğu sürece yatırım yapma isteği yok

# ISS'inizin IPv6 verip vermediğini test etmek
curl -6 https://ipv6.google.com
curl -s https://api6.my-ip.io/ip

# Daha detaylı bağlantı testi
ip6tables -L INPUT -n
ss -6 -tlnp

# IPv6 bağlantınızın kalitesini ölçmek
ping6 -c 10 -i 0.2 2001:4860:4860::8888 | tail -3

Kurumsal Ağlarda Gerçek Engeller

Bir müşterimizin ağ geçiş projesinde karşılaştığımız gerçek senaryoyu paylaşayım. 500 kişilik orta ölçekli bir şirket, IPv6’ya geçmeye karar verdi. Pilot çalışmayı başlattık.

İlk hafta sorunları:

Eski model Cisco Catalyst switch’lerin bir kısmında IPv6 için ayrı lisans gerekiyordu. Bu maliyeti kimse öngörmemişti. Bazı switch’ler IPv6 routing için yeterli TCAM kapasitesine sahip değildi.

İkinci hafta:

Kurumsal antivirus yazılımı IPv6 trafiğini düzgün inceleyemiyordu. Güvenlik ekibi panikle “IPv6 trafiğini bloklayalım” dedi, bu da dual-stack’in amacını tamamen ortadan kaldırıyordu.

Üçüncü hafta:

Şirketin kendi geliştirdiği iç uygulama, veritabanı bağlantı string’lerinde hardcoded IPv4 adresleri kullanıyordu. Bu uygulamaları güncellemek için geliştirme ekibi devreye girdi, ama “sprint’e sığmıyor” cevabı geldi.

# Ağınızdaki IPv6 sorunlarını tespit etmek için hızlı tarama
# Hangi hostların IPv6 desteklediğini bulmak
nmap -6 -sn 2001:db8:1::/64

# Açık IPv6 portlarını taramak
nmap -6 -p 22,80,443,8080 2001:db8:1::100

# IPv6 router advertisement'ları izlemek (rogue RA tespiti)
tcpdump -i eth0 -n "ip6[40] == 134"

# İç ağda IPv6 etkinleştirilmiş servisleri bulmak
ss -6 -tlnp | grep LISTEN

Uygulama Katmanı Sorunları

IPv6 geçişinin en az konuşulan ama en sancılı boyutu uygulama katmanı. Sistem yöneticisi olarak altyapıyı hazırlayabilirsiniz, ama uygulamalar hazır değilse sıfır ilerleme.

Yaygın Uygulama Sorunları

Socket binding problemleri: Bazı eski uygulamalar sadece 0.0.0.0 üzerine bind oluyor, :: (IPv6 wildcard) üzerine değil. Bu durumda IPv6 üzerinden erişim sağlanamıyor.

# Uygulamanızın IPv6 dinleyip dinlemediğini kontrol etmek
ss -tlnp | grep -E ':::|0.0.0.0'

# Nginx için dual-stack konfigürasyon örneği
# /etc/nginx/sites-available/default içine:
# listen 80;
# listen [::]:80;
# Bu satırların ikisi de olmalı

# Apache için kontrol
grep -r "Listen" /etc/apache2/ | grep -v "#"

# Python ile basit IPv6 socket testi
python3 -c "
import socket
s = socket.socket(socket.AF_INET6, socket.SOCK_STREAM)
s.bind(('::', 9999))
s.listen(1)
print('IPv6 socket dinleniyor...')
s.close()
"

# Java uygulamalarında IPv6 zorlamak için JVM parametresi
# java -Djava.net.preferIPv6Addresses=true -jar uygulama.jar

DNS çözümleme sorunları: Uygulamalar AAAA kaydı döndüğünde IPv6’yı kullanmayı reddedebiliyor ya da hatalı davraniyor. Özellikle eski Java sürümleri bu konuda sorunlu.

# AAAA kaydı sorgulama
dig AAAA google.com
dig AAAA +short ipv6.google.com

# Hem A hem AAAA kayıtlarını görmek
dig ANY google.com | grep -E "^google.com"

# Yerel DNS'in IPv6 sorguları yanıtlayıp yanıtlamadığını test et
dig @::1 AAAA google.com
dig @127.0.0.1 AAAA google.com

Güvenlik Açısından IPv6 Farkı

IPv6’ya geçtiğinizde güvenlik modeliniz ciddi anlamda değişiyor. Sysadminlerin çoğu bunu hafife alıyor.

Otomatik adres yapılandırması (SLAAC): IPv6’da cihazlar Router Advertisement mesajlarını dinleyerek otomatik adres alabilir. Bu özellik hem kolaylık sağlıyor hem de ciddi riskler barındırıyor. Ağa sahte bir RA gönderilirse, tüm cihazlar trafiğini o cihaz üzerinden yönlendirebilir.

# Rogue RA saldırılarına karşı Linux'ta RA'ları devre dışı bırakmak
# Sadece statik konfigürasyon kullanıyorsanız:
sysctl -w net.ipv6.conf.all.accept_ra=0
sysctl -w net.ipv6.conf.default.accept_ra=0

# Kalıcı hale getirmek için /etc/sysctl.conf'a ekle
echo "net.ipv6.conf.all.accept_ra=0" >> /etc/sysctl.conf
echo "net.ipv6.conf.default.accept_ra=0" >> /etc/sysctl.conf

# IPv6 firewall kurallarını kontrol et
ip6tables -L -n -v --line-numbers

# Temel IPv6 güvenlik kuralları eklemek
ip6tables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
ip6tables -A INPUT -p ipv6-icmp -j ACCEPT
ip6tables -A INPUT -i lo -j ACCEPT
ip6tables -A INPUT -j DROP

ICMPv6 engellenemez: IPv4’te ICMP’yi tamamen engelleyebilirdiniz (iyi fikir değildi ama yapılıyordu). IPv6’da ICMPv6 protokolün temel işlevselliği için zorunlu. Komşu keşfi, router advertisement, MLD hepsi ICMPv6 kullanıyor. ICMPv6 olmadan IPv6 çalışmaz. Bu, güvenlik duvarı kurallarınızı yazarken dikkatli olmanız gerektiği anlamına geliyor.

Geçiş Planlaması: Gerçekçi Bir Yaklaşım

Pek çok organizasyon “bir günde geçiş” hayali kuruyor. Bu olmaz. Gerçekçi bir geçiş planı şöyle görünmeli:

Aşama 1: Envanter ve Değerlendirme

Önce ne var ne yok bilin. Hangi cihazlar IPv6 destekliyor, hangi uygulamalar hazır, hangi ekipmanlarda firmware güncellemesi gerekiyor. Bu aşama genellikle altı ayı buluyor büyük ortamlarda.

# Ağdaki tüm aktif IPv6 adreslerini keşfetmek
# Neighbor Discovery tablosunu görüntüle
ip -6 neigh show

# Ağ geçiş hazırlığı için temel kontroller
# IPv6 forwarding aktif mi?
sysctl net.ipv6.conf.all.forwarding

# Router'ların IPv6 prefix dağıtıp dağıtmadığını kontrol et
rdisc6 eth0

# Mevcut IPv6 bağlantı kalitesi skoru almak
curl -s https://ipv6test.google.com/api/index?callback=? | python3 -m json.tool

Aşama 2: Pilot Uygulama

Kritik olmayan bir VLAN veya segment seçin. Hem IPv4 hem IPv6 çalıştırın. Sorunları burada öğrenin.

Aşama 3: Kademeli Geçiş

Kritik sistemler en sona bırakılır. Önce edge sistemler, sonra iç servisler, en son legacy uygulamalar.

Bu planın pratikte ne kadar uzadığını tahmin edin. Üç ila beş yıl. Evet, bir organizasyonun tam IPv6 uyumluluğuna geçmesi için ciddi zaman gerekiyor.

Türkiye’deki Durum ve CGNAT Gerçeği

Türkiye’deki ISS’lerin büyük bölümü artık CGNAT kullanıyor. Yani siz bir public IPv4 adresi bile almıyorsunuz, yüzlerce kullanıcı aynı adresi paylaşıyor. Bu durum:

VPN kurulumlarını zorlaştırıyor
Port yönlendirmeyi imkansız hale getiriyor
Ev kullanıcısı olarak bir sunucu açmayı engelliyor
Bazı online servislerin abuse tespitini karmaşıklaştırıyor

CGNAT tam anlamıyla bir çıkmaz sokak. IPv6 bu sorunu çözüyor, her cihaza gerçek bir global adres veriyor. Ama ISS’ler CGNAT’ı benimsemiş durumda ve IPv6 dağıtımına olan aciliyeti kaybetmiş görünüyorlar.

# CGNAT arkasında mı olduğunuzu anlamak
# Dışarıdan görünen IP ile yerel IP'nizi karşılaştırın
curl -s https://api.my-ip.io/ip
ip addr show | grep "inet " | grep -v "127.0.0.1"

# 100.64.0.0/10 aralığında ise CGNAT altındasınız
# Bu aralık IANA tarafından CGNAT için ayrılmış
ip route | grep "100.64"

# IPv6 prefix delegation ile ev ağınıza prefix alınıyor mu?
dhclient -6 -P eth0
ip -6 addr show scope global

Operasyonel Olgunluk Meselesi

IPv6’nın yaygınlaşmamasının bir diğer nedeni: Ekiplerin IPv6 konusundaki bilgi açığı.

Bir Cisco CCNA sertifikası uzun yıllar boyunca IPv6’ya yüzeysel olarak değindi. BGP konuşan ağ mühendisleri bile IPv6 prefix aggregation, anycast adresleme veya OSPFv3 konfigürasyonu konusunda pratik deneyimden yoksun olabiliyor.

Bu bilgi boşluğu gerçek. Bir prodüksiyon ortamında IPv6 sorununu debug ederken, deneyimli bir ağ mühendisinin “IPv6 adresine ping atamıyorum neden” sorusunu sorduğuna bizzat şahit oldum. Cevap basitti: Scope ID eksikti, link-local adres kullanıyordu. Ama bu temel farkı bilmemek ciddi bir sorun.

# Link-local adreslerle çalışırken scope ID kullanımı
# Bu çalışmaz:
ping6 fe80::1

# Bu çalışır (scope ID olarak interface adı):
ping6 fe80::1%eth0

# Komşu keşfi için link-local adresleri görüntüle
ip -6 addr show scope link

# Tüm IPv6 adreslerini scope bilgisiyle göster
ip -6 addr show

Sonuç

IPv6’nın yaygınlaşmaması tek bir nedenin değil, birbirine kenetlenmiş onlarca faktörün sonucu. NAT’ın yarattığı yanlış güvenlik algısı, ISS’lerin CGNAT’a kaçışı, uygulama katmanındaki borç, ekip bilgi açıkları, ekipman yenileme maliyetleri ve “çalışıyor dokunma” kültürü hepsi birlikte bu tabloyu oluşturuyor.

Ama şunu net söyleyeyim: Kaçış yok. IPv4 adresleri gerçekten tükendi, ikinci el adres piyasasının fiyatları bunu kanıtlıyor. CGNAT iş modellerini bozuyor. Cloud sağlayıcıları IPv4 adreslerini artık ücretlendiriyor (AWS, GCP, Azure hepsinin artık public IPv4 için saatlik ücreti var).

Eğer hâlâ IPv6 geçişini planlamıyorsanız, bu kararı başkaları sizin için verecek. Bulut sağlayıcıları, büyük içerik platformları ve giderek artan operasyonel maliyetler sizi bir noktada masaya oturmaya zorlayacak.

Pratik önerim şu: Bugün test ortamınızda dual-stack açın. Sorunları öğrenin. Ekibinizi alıştırın. IPv6 zor değil, yabancı. Ve yabancılık, zaman ve pratikle çözülür.

IPv6 Neden Hâlâ Yaygınlaşmadı: Geçiş Süreci ve Zorluklar