Sanal ve fiziksel sunucu sağlayıcıları yıllardır IPv6-only altyapı kuruyor, ancak uygulamalar ve eski sistemler hâlâ IPv4 bekliyor. Bu yüzden ağ ekipleri, tertemiz bir IPv6-only omurga inşa etmelerine rağmen, IPv4 alt ağlarını, gateway adreslerini ve ARP'yi sonsuza dek yanlarında taşımak zorunda kalıyor. IETF'in yeni taslağı draft-vanmook-intarea-ipv6-resolved-gateway, bu sessiz yükü ortadan kaldırmayı hedefliyor: IPv4'ü, çeviri veya tünelleme olmadan, tamamen IPv6-only bir altyapı üzerinde bir hizmet olarak çalıştırmak.
ARP, 1982'den kalma bir protokol. Küçük LAN'lar için tasarlanmıştı, ama bugün binlerce sunucunun olduğu ortamlarda sürekli sorun çıkarıyor: ARP fırtınaları, önbellek zehirlenmeleri, büyük L2 segmentlerinde tablo taşmaları, geçişlerde gereksiz ARP yarışları. Bir CTO olarak 10.000 müşteri sunucusunun saniyede yarım milyon ARP isteği ürettiğini gördüm. İşte bu taslak o rakamdan doğdu. ARP olmadan, her IPv4 ana bilgisayarı yalnızca kendi /32 adresine ihtiyaç duyar; alt ağ, broadcast ve gateway israfı sona erer.
Dual-stack'in gizli maliyeti sadece iki adres ailesi değil; iki ACL seti, iki izleme konfigürasyonu, iki kat durum bilgisi demek. Ama asıl büyük yük, her IPv4 alt ağını tahsis etmek, belgelemek, yönlendirmek ve yeniden numaralandırmak. Yeni mekanizma ile IPv4 tamamen /32 hizmet olarak sunulduğunda, tahsis edilecek tek şey ana bilgisayar adresinin kendisi oluyor. Ayrıca güvenlik açısından da kazanç: bir /24 ağ, saldırgana ARP ile 254 hedef verirken, ARP'siz /32 ana bilgisayarlar taranamaz.
Büyük barındırma sağlayıcıları bu sorunu zaten kendi yöntemleriyle çözmüş durumda, ama standart olmadığı için çözümler birbiriyle uyumsuz. Hetzner, OVHcloud ve Scaleway gibi firmalar, müşterilerine /32 adres verip gateway'i alt ağ dışında bir adrese yönlendiriyor. Her biri farklı gateway adresi ve farklı işletim sistemi yapılandırması kullanıyor: Hetzner on-link, OVHCloud post-up host rotası, Scaleway pointopoint. Milyonlarca sunucu bu şekilde çalışıyor, ama hiçbiri bir RFC'de belgelenmiş değil. İşte IETF'in var olma nedeni tam da bu tür birlikte çalışabilirlik sorunlarını çözmek.
Akla gelen ilk soru: neden DHCPv4'e yeni bir seçenek eklenip IPv6 next-hop taşınmıyor? Çünkü DHCP seçeneği kolay kısım olsa da, onu çevreleyen her şey zor. IPAM'ler, provizyon sistemleri, faturalama platformları, müşteri portalları, izleme araçları, NOC runbook'ları ve ağ ders kitapları, IPv4 gateway'inin neye benzediğini bilir: dört oktetlik tanıdık bir alan. Bu bilgi tüm OSS/BSS ekosisteminde doğrulama mantığına gömülüdür. Gateway'in şeklini değiştirmek, on yıllar sürecek bir endüstri çapında koordinasyon sorunudur. O halde şekli değiştirme, anlamını değiştir.
Sistem Güvenliği
Taslak, tek bir özel amaçlı IPv4 adresi tanımlıyor: 192.0.0.11. Bu adres, bir sentinel (bekçi) değeri olarak çalışıyor. DHCPv4 sunucusu bunu sıradan Router Option (Option 3) olarak dağıtıyor; tüm DHCP sunucuları, röleleri, IPAM'ler ve provizyon sistemleri bu adresi hiçbir değişiklik yapmadan işleyebiliyor, çünkü tam olarak bekledikleri formatta. Değişiklik sadece ana bilgisayarda: sentinel adresini tanıyan bir istemci yığını, gateway'in aslında IPv6 üzerinden erişilebilen bir sonraki atlama olduğunu anlıyor ve ARP'ye gerek kalmadan doğrudan yönlendirme yapıyor.
Bu mekanizma, operatörlere pratik çıkarımlar sunuyor: ARP kaynaklı kesintiler sona eriyor, IPv4 adres tasarrufu sağlanıyor (her ana bilgisayar için yalnızca bir /32), alt ağ yönetimi ortadan kalkıyor ve güvenlik artıyor. Üstelik mevcut DHCP altyapısına dokunmadan, yalnızca istemci tarafında bir güncelleme ile hayata geçirilebiliyor. IETF 126'da sunulacak olan taslak, toplantı sonrası kabul çağrısı bekliyor. Eğer bir ağ işletiyorsanız, bu gelişmeyi takip etmekte fayda var: ARP'ye veda zamanı yaklaşıyor.
Kaynak: labs.ripe.net
