IPv6-only hedefi çoğu kurumda doğru bir strateji: adres yönetimi sadeleşir, ağ tasarımında bazı “legacy” yükler azalır ve modern cloud/edge dünyasıyla daha iyi hizalanırsınız. Ama pratikte gerçek hayat şudur: IPv4 bağımlılıkları bir anda bitmez.
NAT64/DNS64 burada “sonsuz geçici çözüm” değil, kontrollü bir köprü olarak değer üretir: IPv6-only istemciler, IPv4-only hedeflere erişebilir; siz de dönüşümü parça parça yönetirsiniz.
1) NAT64 ve DNS64: kim ne yapar?
- DNS64: İstemci bir domain için AAAA ister. Eğer hedefin IPv6’sı yoksa, DNS64 sentez AAAA üretir (NAT64 prefix’i ile).
- NAT64: İstemciden gelen IPv6 trafiğini alır, hedef IPv4’e çevirir ve geri dönüşü yönetir.
Bu ikisi birlikte çalışmazsa, sadece NAT64 kurmak “DNS nereden bulacak?” sorusunu açık bırakır.
2) Ne zaman mantıklı? (ve ne zaman değil?)
Mantıklı senaryolar:
- İç ağda bazı servisler IPv4-only, ama istemci ağını IPv6-only yapmak istiyorsunuz.
- Veri merkezi / kampüs / overlay ağında IPv6’yı standart yapmak istiyorsunuz.
- Uygulama ekibi IPv6 desteğini getirmeden önce geçici erişim köprüsü gerekiyor.
Riskli/yanlış senaryolar:
- Ağ trafiği yoğun stateful ve “source IP sabit” beklentili (bazı lisans/allowlist dünyaları).
- Protokoller “IP literal” kullanıyor (DNS’e hiç bakmayan istemci).
- DNSSEC doğrulama davranışları ve split-horizon karmaşık (tasarım ister).
3) Tasarım: minimum viable mimari
Sahada en stabil gördüğüm model:
- En az iki NAT64 node (HA) + healthcheck
- NAT64 prefix standardı (kurum içinde net)
- DNS64’ün sadece belirli istemci segmentlerinde aktif edilmesi (kademeli geçiş)
- Log/metric: NAT64 state, translation errors, top domains
3.1 NAT64’ü nerede konumlandırmalı?
Prensip: NAT64 “egress”e yakın olmalı, ama “tek nokta” olmamalı.
- Kampüs/şube: edge’de (merkezî NAT64) latency’yi artırabilir
- Veri merkezi: core’da konumlandırmak daha dengeli
İşletim hedefi: NAT64’ün incident’te “gizli” bir bileşen olmaması.
4) Operasyon runbook’u: sorun yaşarsan ne kontrol edersin?
4.1 Belirti: IPv6-only istemci bazı sitelere gidemiyor
- Domain AAAA mı dönüyor? DNS64 sentezi var mı?
- DNS64 sadece o segmentte mi aktif?
- NAT64 node sağlıklı mı? (CPU/state/packet drop)
- Hedefin IPv4’ü reachable mı? (routing/ACL)
- MTU/PMTUD problemi var mı? (tünel/overlay varsa sık)
4.2 Belirti: Bazı uygulamalar çalışıyor, bazıları patlıyor
Bu genelde “DNS kullanmayan” veya “IP literal” kullanan uygulamalardır.
- Uygulama konfig’de IP literal var mı?
- Proxy/agent kendi DNS çözümlemesini yapıp farklı davranıyor mu?
4.3 Belirti: Güvenlik/allowlist şikâyeti (kaynak IP)
NAT64, hedef tarafta kaynak IP’yi NAT havuzundan gösterir.
- Allowlist tarafında NAT64 havuzu tanımlı mı?
- NAT64 havuzu sabit mi, dinamik mi?
- Bu bağımlılık planlı mı, geçici mi?
5) İzleme: NAT64/DNS64’ü “gözle” değil “metrikle” yönet
Önerdiğim minimum metrik seti:
- NAT64:
translations_active,translations_failed,icmp_errors,conntrack_usage - DNS64:
synth_aaaa_total,synth_aaaa_ratio,dns_errors_total - Operasyon: “top domains via NAT64” (hangi bağımlılıklar IPv4-only?)
Bu metrikler, IPv6-only geçişinin gerçek durumunu ortaya çıkarır: hangi servisler hâlâ IPv4’e bağımlı?
6) Geçiş stratejisi: köprüyü bir gün kaldıracağın şekilde kur
NAT64/DNS64’ün değeri, geçişi mümkün kılmasıdır. Bu yüzden en baştan şu soruları cevaplayın:
- Hangi servisler IPv4-only? Sahibi kim?
- IPv6 desteği için hedef tarih var mı?
- NAT64 üzerinden geçen kritik domain’ler hangileri?
- NAT64 kapandığında “ne kırılır?” listesi hazır mı?
7) Kapanış
IPv6-only geçiş, “bir ayarda IPv6 açmak” değildir. NAT64/DNS64 bu yolculukta doğru kullanılırsa güçlü bir köprüdür: kesintisiz geçiş sağlar, bağımlılıkları görünür kılar ve kademeli dönüşümü mümkün hale getirir. Ama köprüyü işletilebilir yapan şey; segment bazlı aktivasyon, ölçüm ve net bir kaldırma planıdır.