IPv6 Geçiş Mekanizmaları Nasıl Seçilir?

Sesli Dinle — Makale

IPv6 geçiş mekanizması seçimi, yalnız ağ cihazlarının IPv6 destekleyip desteklemediğine bakılarak yapılamaz. Ağ ekibi uygun yöntemi belirlerken uygulamaların hangi protokolle çalıştığını, IPv4 adreslerine ne kadar süre daha ihtiyaç duyulduğunu, DNS davranışını, güvenlik politikalarını, izleme kapasitesini ve sorun çıktığında kullanılacak geri alma seçeneklerini birlikte değerlendirir.

Dual-stack, tünelleme ve protokol çevirisi farklı ihtiyaçları çözer. Dual-stack, IPv4 ve IPv6'yı aynı cihazlarda paralel çalıştırır. Tünelleme, bir protokolün paketini diğer protokolün paketi içine yerleştirerek taşır; bu işleme kapsülleme denir. Çeviri ise paketlerin adres ve başlıklarını dönüştürerek IPv6 ve IPv4 uçlarının iletişim kurmasını sağlar. Hiçbiri her ağ için tek başına doğru seçim değildir.

Seçimden önce hedef de net olmalıdır. Yalnız IPv6 erişimi mi eklenecek, omurga IPv6'ya taşınırken eski bir bölüm mü korunacak, yoksa istemci ağı yalnız IPv6 ile çalıştırılıp IPv4 hizmetlerine erişim mi sürdürülecek? Aynı kurum, farklı ağ bölümlerinde farklı mekanizmalar kullanabilir.

IPv6 Geçişi İçin Mevcut Ağ Envanteri

Geçiş yöntemini seçmeden önce ağın gerçekte nasıl kullanıldığını belgelemek gerekir. Envanter yalnız yönlendirici ve anahtar listesinden oluşmaz. Ağ ekibi uygulamaları, DNS bağımlılıklarını, IP adreslerinin metin içinde kullanıldığı yerleri, güvenlik araçlarını ve dış hizmetlerle kurulan bağlantıları da belgelemelidir.

Uygulama ve Bağımlılık Envanteri

Her uygulama için istemci, sunucu ve aradaki bileşenlerin IPv4, IPv6 veya her ikisini destekleyip desteklemediğini ayrı ayrı kontrol edin. Alan adı yerine doğrudan IPv4 adresi kullanan yazılımlar, IPv4'e özgü programlama arayüzleri, erişim listeleri ve lisans kontrolleri çeviri ortamında beklenmedik davranabilir.

Uygulama testinde yalnız ana ekranın açılması yeterli değildir. Kimlik doğrulama, dosya aktarımı, bildirim, yedekleme, izleme aracısı, başka hizmetlerle veri alışverişi sağlayan API’lere yapılan çağrılar ve yönetim bağlantıları da aynı test kapsamında sınanmalıdır. Bir uygulama IPv6 üzerinden çalışırken bağlı olduğu hizmetlerden biri yalnız IPv4'e bağımlı kalabilir.

Adres, DNS ve Ağ Yolu Envanteri

Mevcut IPv4 alt ağlarını, genel ve özel adres kullanımını, IP adreslerini çeviren NAT noktalarını, IPv6 adres bloklarını tanımlayan prefixlerin tahsisini ve yönlendirme sınırlarını birlikte haritalayın. Dual-stack seçilecekse iki adres planının aynı ağ bölümlerinde nasıl işletileceği; yalnız IPv6 kullanan bir ağ ile çeviri seçilecekse hangi IPv4 hedeflerine hangi çeviri noktasından erişileceği belirlenmelidir.

DNS envanterinde IPv4 adresi veren A ve IPv6 adresi veren AAAA kayıtlarını kimin yönettiğini, sorguları yanıtlamak için yetkili sunuculara başvurup sonuçları önbelleğe alan recursive resolver hizmetlerini belirleyin. İç ve dış ağlara farklı yanıt veren split DNS yapılarını, kısa adları ve sabit adres içeren yapılandırmaları da kaydedin. Geçiş mekanizması DNS davranışını değiştirebilir; bu nedenle kayıt üretimini, önbellek süresini ve hata durumlarını uygulama testlerine ekleyin.

Dual-Stack, Tünelleme ve Protokol Çevirisinin Karşılaştırılması

Tablo, üç yaklaşımın adres planı, uygulama uyumluluğu ve işletim gereksinimlerini karşılaştırır. Çeviri sütunu, IPv6 istemcilerinin IPv4 hedeflerine erişmesini sağlayan ve bağlantı eşleştirmelerini tutan durum bilgili NAT64 örneğini esas alır; bağlantı durumu tutmayan çeviri yöntemlerinin kapasite ve adres planı farklıdır. MTU, bir ağ bağlantısında parçalanmadan taşınabilen en büyük IP paketinin boyutunu belirtir.

Dual-Stack Hangi Ortamlarda Kullanılır?

Dual-stack, uçların ve ağın hem IPv4 hem IPv6 çalıştırabildiği, IPv4 bağımlılıklarının sürdüğü ve iki protokolün birlikte yönetilebildiği ortamlarda geçişi kademeli yürütmeye uygundur. Uygulamalar hedefe göre IPv4 veya IPv6 kullanabilir; hizmetler tek seferde dönüştürülmek yerine ayrı aşamalarda taşınabilir.

Kademeli geçiş olanağı işletim yükünü ortadan kaldırmaz. Güvenlik duvarı, yönlendirme, DNS, kapasite takibi ve olay müdahalesi iki protokol ailesini de kapsamalıdır. IPv4 için uygulanan bir kontrolün IPv6'da otomatik olarak geçerli olduğu varsayılırsa, aynı hizmet iki farklı güvenlik düzeyiyle erişilebilir hale gelebilir.

Dual-stack seçimi, IPv4'ün süresiz korunacağı anlamına gelmez. Hedef yalnız IPv6 kullanan bir ağsa her uygulama için IPv6 kullanım oranı, kalan IPv4 ihtiyacının nasıl karşılanacağı ve ağdaki IPv4 desteğinin kaldırılma koşulları belirlenmelidir. Aksi halde iki protokolün birlikte yönetilmesi süresiz devam edebilir.

Tünelleme Ne Zaman Geçici Bir Çözüm Olarak Kullanılır?

Tünelleme, IPv6 destekleyen iki bölge arasında kalan altyapı henüz IPv6 taşıyamıyorsa veya belirli bir ağ bölümünü ana geçişten önce bağlamak gerekiyorsa kullanılabilir. IPv6 paketleri IPv4 içinde taşınabildiği için aradaki IPv4 yönlendirme altyapısını hemen değiştirmeden bağlantı kurulabilir.

Bu yöntem, ek kapsülleme ve ayrı tünel uçları oluşturur. Etkin MTU düşebilir; ağ yolu üzerindeki güvenlik ve izleme araçları yalnız dış paketi görüyorsa iç IPv6 akışının kaynak, hedef ve uygulama bilgileri görünmeyebilir. Tünel arızası, doğrudan yönlendirme sorunlarından farklı bir hata katmanı ekler.

Tünelleme seçilecekse ağ ekibi tünelin amacını, kapasitesini ve sorumlusunu belirlemelidir. Tünel yalnız IPv6 desteği eksik bir bağlantıyı geçici olarak aşmak için kuruluyorsa tünelsiz IPv6 erişimine geçiş koşulları ve kaldırma takvimi de yazılmalıdır. Güvenlik veya ağlar arası bağlantı gibi kalıcı bir amaçla kullanılan tünellerin ise IPv6 geçişi bittiğinde mutlaka kaldırılması gerekmez.

Protokol Çevirisi Hangi Durumlarda Kullanılır?

Protokol çevirisi, farklı IP sürümlerini kullanan uçların iletişim kurması gerektiğinde kullanılır. Durum bilgili NAT64, IPv6 istemcilerinin IPv4 sunucularına başlattığı TCP ve UDP akışlarını, ICMP sorgularını ve desteklenen hata mesajlarını çevirir; yanıt trafiği de ters yönde çevrilir. ICMP, hata bildirimi ve erişilebilirlik sınaması gibi ağ denetim işlevlerini taşır. IPv4 tarafından yeni bir bağlantı başlatılması ise uygun sabit eşleştirme veya ek bir mekanizma gerektirir. DNS64, A kaydındaki IPv4 adresinden çeviri yolunu gösteren bir IPv6 adresi üretip bunu sentetik AAAA yanıtı olarak istemciye verebilir.

Bu yaklaşım, istemci ağında IPv4 adres dağıtma ihtiyacını azaltabilir; ancak bütün uygulamaları kendiliğinden uyumlu yapmaz. Alan adı çözümlemesini atlayıp doğrudan IPv4 adresi kullanan uygulamalar, IP adresini uygulama verisi içinde taşıyan protokoller veya NAT davranışıyla uyumsuz akışlar ek bir geçiş yöntemi ya da uygulama düzeltmesi gerektirebilir.

464XLAT, IPv4 kullanan uygulamalar için istemcide veya yerel ağ geçidinde bir CLAT (Customer-Side Translator) çalıştırır. CLAT, uygulamanın IPv4 paketini IPv6'ya çevirir; ağdaki durum bilgili NAT64 bileşeni de IPv4 hedefine erişimi sağlar. Böylece doğrudan IPv4 adresi veya yalnız IPv4 destekleyen bir programlama arayüzü kullanan uygulamalar IPv6 ağı üzerinden çalışabilir. Ancak uygulama verisinin içine gömülmüş adresler ve NAT ile uyumsuz davranışlar yine ayrıca test edilmelidir.

Çeviri noktası durum bilgisi tutuyorsa kapasite planı yalnız bant genişliğine göre yapılmamalıdır. Eşzamanlı oturum sayısı, IPv4 adres ve port tüketimi, zaman aşımı davranışı, yedeklilik ve günlük hacmi de izlenmelidir. Çeviri cihazının arızalanması, yalnız IPv6 kullanan çok sayıda istemcinin IPv4 hizmetlerine erişimini aynı anda etkileyebilir.

DNS, Doğrudan IPv4 Adresleri ve MTU'nun Geçiş Seçimine Etkisi

Paketlerin taşınabiliyor olması, DNS yanıtlarının uygulamaya uygun olduğunu veya büyük paketlerin hedefe ulaşabildiğini göstermez. Ağ ekibi DNS, doğrudan adres kullanımı ve paket boyutu için pilot öncesinde ayrı test senaryoları hazırlamalıdır.

DNS64 ve Doğrudan IPv4 Adresi Kullanımı

Dual-stack ortamında A ve AAAA kayıtlarının doğruluğu, istemcinin erişilebilir bir yolu seçebilmesi için gereklidir. Çeviri ortamında DNS64, normalde AAAA sorgusu ilgili adın AAAA kaydı bulunmadığını gösterdiğinde, varsa A kaydından IPv4 hedefi temsil eden bir IPv6 adresi üretir. DNS sorgusunun zaman aşımına uğraması veya sunucu hatasıyla sonuçlanması, kayıt yokluğu gibi değerlendirilmez. Hedefin gerçek AAAA yanıtı varsa genellikle aynen iletilir; ancak yapılandırılmış adres dışlama kuralları bazı AAAA yanıtlarının elenmesine ve sentez yapılmasına neden olabilir. DNS64, hedefin gerçek IPv6 yolundaki her erişim hatasını otomatik olarak NAT64 ile aşmaz.

Yapılandırma dosyalarındaki, veri tabanlarındaki ve uygulama kodundaki doğrudan IPv4 adresleri bu süreci atlar. Ağ envanteri URL'lere, erişim listelerine, izleme hedeflerine, sertifika yapılandırmalarına ve lisans kontrollerine gömülmüş adresleri de kapsamalıdır. Doğrudan yazılmış her adres otomatik olarak sorun çıkarmaz; CLAT desteği veya uygulamanın çeviri adresi oluşturabilmesi gibi koşullar sonucu değiştirir. Bu adresler çeviri seçeneğinin uygunluğunu belirleyen testlere dahil edilmelidir.

DNS yanıtlarının kaynağını ve bütünlüğünü imzalarla doğrulayan DNSSEC de pilotta sınanmalıdır. DNS64'ün ürettiği AAAA yanıtı, yetkili DNS sunucusunun imzaladığı özgün kayıt değildir. DNSSEC doğrulamasını kendisi yapan bir istemci bu yanıtı doğrudan doğrulayamaz; doğrulamanın ve adres sentezinin nerede yapılacağı birlikte planlanmalıdır. Sorunu çözmek için DNSSEC doğrulamasını genel olarak kapatmak uygun değildir.

MTU ve Paket Boyutu

Tünelleme ek başlık taşıdığı için kullanılabilir paket boyutunu azaltabilir. ICMPv6 hata mesajlarının engellenmesi, yanlış MTU değeri veya ağ yolundaki farklı MTU sınırları küçük paketler iletilirken büyük aktarımların takılmasına yol açabilir. Sorun yalnız hız testiyle değil, farklı boyutlarda gerçek uygulama akışlarıyla incelenmelidir.

Dual-stack ve çeviri ortamlarında da ağ yolunun IPv4 ve IPv6 tarafları farklı MTU davranışı gösterebilir. Bu nedenle başarı kriterleri yalnız bağlantının kurulmasını değil, büyük yanıtları, dosya aktarımını, şifreli oturumları ve uzun süreli akışları da kapsamalıdır. Path MTU, kaynak ile hedef arasındaki yolun en küçük MTU değeridir; ölçüm yalnız sınanan yolu ve zamanı temsil eder. Farklı kullanıcı, hedef veya trafik yönü için aynı sonuç varsayılmamalıdır.

IPv6 Geçişinde Güvenlik, İzleme ve Olay Görünürlüğü

IPv6 geçişi, mevcut güvenlik politikasının yalnız adres biçimini değiştirerek kopyalanması değildir. Trafiğin hangi protokolü, tüneli veya çeviri noktasını kullandığı erişim kararlarını ve olay incelemesini etkiler.

IPv4 ve IPv6 İçin Eşdeğer Güvenlik Kuralları

Ağ ekibi dual-stack ağlarda IPv4 ve IPv6 için eşdeğer erişim politikaları uygulamalı, yalnız bir protokolü denetleyen cihaz veya kural bırakmamalıdır. Tünel trafiğini kabul eden uçları ve izin verilen karşı uçları sınırlandırmalı, beklenmeyen tünel trafiğini engellemelidir. Tünelin kendisi şifreleme veya karşı uç kimlik doğrulaması sağlamıyorsa bu korumalar ayrıca tasarlanmalıdır. Durum bilgili NAT64, bağlantı eşleştirmelerini tutar; ancak bu özellik tek başına eksiksiz bir güvenlik duvarı politikası yerine geçmez.

IPv6'nın etkinleştirilmesi güvenliği otomatik olarak artırmaz veya azaltmaz. Güvenlik düzeyi filtreleme, adres atama, aynı bağlantıdaki yönlendiricileri ve cihazları bulmayı sağlayan komşu keşfi mekanizmasının korunması, güncelleme yönetimi ve izleme kapsamına bağlıdır. Geçiş mekanizması seçilirken güvenlik ekibi, kullandığı ürünlerin ilgili paketleri ve günlük alanlarını doğru işleyebildiğini doğrulamalıdır.

Günlükleri ve Ağ Akışlarını Eşleştirme

Dual-stack günlüklerinde aynı hizmete ait IPv4 ve IPv6 olayları ortak kullanıcı, cihaz veya oturum bilgisiyle ilişkilendirilebilmelidir. Tünellerde iç ve dış adresler; çeviride ise özgün ve çevrilmiş adresler, TCP veya UDP gibi taşıma protokolü, ilgili portlar ve zaman bilgisi birlikte kaydedilmelidir. ICMP sorgularında port yerine sorgu tanımlayıcısı kullanılır.

Yalnız cihaz günlüklerine güvenmek yeterli olmayabilir; DNS sorguları, uygulama günlükleri, ağ akış kayıtları ve güvenlik alarmları birlikte karşılaştırılmalıdır. Bu kayıtları üreten sistemlerin saatleri güvenilir bir zaman kaynağına göre eşitlenmeli; saat dilimi, zaman hassasiyeti ve geçiş mekanizmasını belirten alanlar korunmalıdır. Aksi halde bir olayın gerçek istemciye veya ağ yoluna bağlanması güçleşir.

Aşamalı Geçiş ve Geri Alma Planı

Ağ ekibi geçişi, tek bakım penceresinde bütün ağı değiştirmek yerine ölçülebilir aşamalara ayırmalıdır. Her aşama, teknik başarının yanı sıra kullanıcılar üzerindeki etkisini ve işletim ekibinin müdahale yeteneğini de sınamalıdır.

1. Envanteri tamamlayın: Uygulama, adres, DNS, güvenlik, izleme ve dış bağımlılık kayıtlarını sahipleriyle doğrulayın.
2. Hedef modeli seçin: Hangi bölümlerin dual-stack, yalnız IPv6, tünel veya çeviri kullanacağını ve bunun nedenini yazın.
3. Sınırlı pilot kurun: Temsil edici kullanıcı, cihaz ve uygulama gruplarını seçin; yalnız kolay çalışan hizmetlerle yetinmeyin. Pilot başlamadan başarı eşiklerini ve başarısızlık durumunda geri alma koşullarını belirleyin.
4. Başarı kriterlerini izleyin: Bağlantı oranı, hata oranı, gecikme, oturum kurulumu, DNS sonucu, çevirici kapasitesi, MTU kaynaklı hata belirtileri ve destek kaydı sayısı gibi göstergeleri karşılaştırın.
5. Geri alma işlemini uygulamalı test edin: DNS, yönlendirme, güvenlik ve adres dağıtımı değişikliklerinin hangi sırayla geri alınacağını deneyin.
6. Kapsamı kademeli büyütün: Her dalgada önceki aşamadaki sorunlar çözülmeden yeni ağ bölümüne geçmeyin.

Geri alma planı yalnız yeni yapılandırmayı silmekten ibaret değildir. Yalnız IPv6 kullanan istemcilerin yeniden IPv4 adresi alması, DNS kayıtlarının ve önbelleklerin eski davranışa dönmesi, tünelin yerine kullanılacak alternatif yolun hazırlanması veya çeviri dışı erişimin sağlanması gerekebilir. Ağ ekibi geri alma kararı için hata eşiğini, sorumlu kişiyi ve azami müdahale süresini önceden tanımlamalıdır.