IPv6 geçişi çoğu kurumda “adresi açalım, bitti” diye düşünülür. Sahada ise IPv6; DNS, firewall politikası, yük dengeleme, gözlemlenebilirlik ve incident refleksi ile birlikte gelir. Doğru tasarlanmazsa “iki protokol = iki kat sorun yüzeyi” olur.
Bu yazıda benim pratikte en çok işe yarayan yaklaşımı anlatıyorum: dual‑stack ile kontrollü başla, IPv6‑only hedefle, geçişi ölçülebilir yap.
Neden IPv6‑only hedeflemelisin?
Dual‑stack uzun süre kalıcı olursa operasyonel borç üretir:
- Her servis için iki adres ailesi test edilir (IPv4/IPv6)
- Firewall/ACL’ler iki kez yönetilir
- DNS tarafında “A/AAAA davranışı” iki ayrı hata sınıfı doğurur
- Troubleshooting runbook’ları iki katına çıkar
IPv6‑only’e giden yol, uzun vadede daha sade bir ağ ve daha stabil operasyon demektir. Dual‑stack burada sadece köprü.
Başlamadan önce: gerçek envanter
Önce şunu netleştir:
- IPv4 bağımlılığı olan yerler: eski uygulamalar, lisans server’lar, cihaz yönetim arayüzleri
- L7 edge: CDN/WAF/Ingress/LB katmanı IPv6’yı nasıl ele alıyor?
- DNS davranışı: resolver zinciri, split‑horizon, cache politikası
- Gözlemlenebilirlik: loglarda IP alanları IPv6’ya hazır mı? (index, parsers, dashboards)
- Security: firewall platformu IPv6 policy’yi eşdeğer yönetiyor mu?
Adresleme ve yönlendirme: “küçük ama kurallı” başla
Benim sevdiğim model:
- Her site / DC / region için /48 (veya ihtiyaçla /56)
- Her VLAN/segment için /64
- Router advert (RA) ile “otomatik” açmadan önce statik ve kontrollü başla (özellikle server segmentlerinde)
Yönlendirme tarafında:
- Core/backbone IPv6’yı önce taşıyıcı olarak aç (IGP + BGP politikaları)
- Daha sonra servis segmentlerini dual‑stack yap
- En son client/endpoint tarafını genişlet
DNS: A/AAAA dengesi ve “mutlaka ölç”
Dual‑stack’te kritik risk: client ve resolver davranışı.
- Happy Eyeballs (client’ların IPv6/IPv4 yarışması) çoğu modern sistemde var ama “her yerde var” diye varsayma.
- AAAA yayınladığında, bazı eski stack’ler IPv6’yı dener ve takılır.
Benim kuralım:
- IPv6’yı ağda taşı
- Servisi IPv6’da ayağa kaldır (back‑end ready)
- DNS’te AAAA’yı kademeli aç (canary)
- Her adımda latency ve hata oranını izle
Ölçmek için basit bir başlangıç:
- Resolver query log’larında A/AAAA oranı
- Uygulama log’larında “client IP family”
- LB/Ingress metriklerinde IPv6 bağlantı sayısı
Firewall ve segmentasyon: IPv6 policy “kopya” değildir
IPv4 dünyasında NAT bazen “kötü ama pratik” bir izolasyon hissi verir. IPv6’da NAT yok (olmalı da değil). Bu yüzden:
- “NAT vardı, zaten dışarıdan gelmiyordu” yaklaşımı çöker
- Security modelin gerçek hâli ortaya çıkar: stateful firewall + doğru segmentasyon
Checklist:
- IPv6 inbound/outbound kuralları IPv4 ile eşdeğer mi?
- “deny by default” gerçekten var mı?
- ICMPv6’ı “tam kapatma” (PMTUD ve neighbor discovery için gerekli)
- Loglama: drop’lar IPv6’da da aynı pipeline’a düşüyor mu?
MTU ve PMTUD: en sinsi incident sınıfı
IPv6’da fragment işlemi farklı çalışır; Path MTU Discovery (PMTUD) doğru akmalı.
Semptomlar:
- TCP bağlantısı kuruluyor ama büyük payload’larda “garip” timeout’lar
- Sadece bazı rotalarda problem
- Uygulama katmanında rastgele 504/timeout
Operasyonel yaklaşım:
- ICMPv6 “Packet Too Big” mesajlarının düşmediğini doğrula
- Tüneller (VPN, GRE, overlay) üzerinde MTU planı çıkar
- Gözlem: PMTU ile ilgili hata loglarını / kernel counter’larını takip et
Geçiş fazları (benim sahadaki sıralamam)
Faz 0 — Hazırlık (1–2 sprint)
- Envanter + “IPv6 ready” checklist
- Monitoring/logging alanları IPv6’yı parse edecek hale gelir
- Firewall policy modelleme (IPv4 ile parity)
Faz 1 — Taşıyıcı ağ (backbone) IPv6 (1 sprint)
- Core routing + edge uplink’lerde IPv6 taşı
- BGP policy, route‑map ve prefix‑list’ler tanımlı
- OOB yönetim ağı (mümkünse) önce dual‑stack
Faz 2 — Sunucu segmentleri dual‑stack (2–4 sprint)
- Önce stateless değil, kontrollü adresleme
- Servis discovery/DNS kademeli
- Load balancer health check ve logging parity
Faz 3 — Servis front‑door IPv6 (kademeli)
- Ingress/LB üzerinde IPv6 listener’lar
- AAAA canary (ör. %1 trafik)
- Hata oranı, latency ve “retry storm” sinyalleri
Faz 4 — IPv6‑only adaları (en değerli aşama)
Burada amaç: IPv6‑only’i gerçek hayatta test etmek.
- Yeni bir internal servis segmentini IPv6‑only aç
- IPv4 bağımlılıkları varsa NAT64/DNS64 gibi geçici köprüleri planla
- Runbook: “IPv6‑only segmentte incident nasıl çözülür?”
Faz 5 — Default IPv6‑only (uzun vadeli hedef)
Dual‑stack’i kapatmak için en iyi zaman: “her şey mükemmel olduğunda” değil; ölçümlerin sana yeterli güven verdiğinde.
Incident runbook: operasyonda neleri hazır tutarım?
Benim standart setim:
- “DNS mi, routing mi, firewall mı?” ayrımı için 5 dakikalık triage akışı
dig/drillile A/AAAA karşılaştırma örnekleritraceroute -6/mtr -6yolları- Firewall log sorguları: IPv6 drop analizi
- PMTU şüphesi için hızlı kontrol adımları
Sonuç
IPv6 geçişi bir “network projesi” değil; uçtan uca operasyon tasarımıdır. Dual‑stack ile kontrollü başla, gözlemlenebilirliği ve güvenliği parity’de tut, ardından IPv6‑only adalarıyla gerçek üretim kasını geliştir. Bu yaklaşım, hem riskini düşürür hem de “sonsuz dual‑stack” tuzağına düşmeni engeller.