IPv4 Bağlantısı Olmadan İnternet Kullanmak

• IPv4 bağlantısının kesildiği bir durumda bile IPv6, WireGuard ve Hetzner VPS üzerinden tam internet erişimi sağlanabildi
• Carrier Grade NAT (büyük ölçekli NAT) nedeniyle yalnızca IPv4 tarafında arıza yaşandı, ancak IPv6 etkilenmedi
• WireGuard tüneli kurularak VPS üzerinden IPv4 trafiği tünellenip normal web sitesi kullanım ortamı geri getirildi
• Ağ namespace’leri ve Docker kullanımı ile MTU sorununu çözme yöntemleri de ele alınıyor
• Linux ortamı ve açık kaynak araçlar sayesinde karmaşık ağ sorunlarını kendi başına çözme deneyimi vurgulanıyor

---

Genel Bakış

Birkaç gün önce yazar, bir elektrik kesintisinin ardından evdeki yönlendiricisinde IPv4 erişiminin koptuğu bir sorun yaşadı. Neyse ki IPv6 erişimi normaldi, bu sayede Google, Meta gibi bazı web sitelerine erişilebiliyordu; ancak GitHub gibi sitelerin büyük kısmına ulaşılamıyordu. Bunun üzerine Linux, WireGuard ve Hetzner VPS kullanarak yalnızca IPv6 ile tam internet erişim ortamını geri kazanma süreci özetleniyor.

Arızanın Nedeni ve Arka Planı

Ağ Ortamındaki Anormalliğin Tespiti

• Elektrik kesintisi sonrası toparlanma sürecinde, IPv6 sunucularına erişim normalken IPv4 sunucularına erişilemediği görüldü
• Tanı komutları (ping -6, traceroute) çalıştırıldığında da farkın yalnızca IP sürümüne göre oluştuğu ortaya çıktı
• Yapılan sorgulama sonucunda, operatör tarafındaki CG-NAT (Carrier Grade NAT) katmanında IPv4 dönüşümünde sorun olduğu anlaşıldı
• ISS tarafındaki bakımın birkaç gün süreceği öngörüldüğünden, sorunu doğrudan çözmek gerekti

NAT ve CG-NAT Açıklaması

• NAT (Network Address Translation): Birden fazla cihazın tek bir genel IPv4 adresini paylaşmasını sağlayan yöntemdir
  • Yönlendirici, iç IP’leri genel IP ve benzersiz portlarla eşleyerek trafiği yönetir; geri dönüş trafiğinde ise eşleme bilgisiyle iç hedefi yeniden belirler
  • Bu yapı nedeniyle örtük bir güvenlik duvarı etkisi oluşur ve port yönlendirme ihtiyacı doğar
• CG-NAT (Carrier Grade NAT): ISS’nin her ev yönlendiricisine bir kez daha ek NAT uyguladığı katmanlı yapıdır
  • IPv4 adres kıtlığı nedeniyle ISS içinde NAT iç içe uygulanır
  • CG-NAT ortamında port yönlendirme gibi servis sunumları daha da kısıtlıdır
  • Bu olayda yalnızca IPv4 trafiğinin bozulmasının nedeni de tam olarak bu katmandaki IPv4 paket işleme sorunudur

IPv6’nın Avantajları

• IPv6 adres alanı son derece geniştir; bu yüzden NAT olmadan da her cihaza doğrudan adres atanabilir
  • Ev tipi yönlendiricilerin çoğuna /64 alt ağı tahsis edilir ve bu da trilyonlarca adres kullanılabilmesi anlamına gelir
• Ayrı bir NAT gerekmeden doğrudan iletişim mümkündür, ancak güvenlik duvarı yapılandırması daha da önemli hale gelir
• CG-NAT yalnızca IPv4’e uygulandığı için bu olayda sadece IPv6 normal çalıştı
• Ancak hâlâ birçok sunucuya (ör. GitHub) yalnızca IPv6 ile erişilemiyor

WireGuard Tüneli ile IPv4’ü Geri Getirmek

Uygulama Özeti

• Hetzner VPS (hem IPv4 hem IPv6 stack desteğiyle) ve WireGuard kullanılarak, internet bağlantısının yalnızca IPv6 üzerinden çalıştığı bir durumda tam internet erişimi sağlayan bir yapı kuruldu
  • VPS üzerinde WireGuard sunucusu çalıştırıldı ve istemci cihazlarla tünel kuruldu
  • Trafik IPv6 üzerinden VPS’ye yönlendirilerek VPS aracılığıyla tüm sitelere (IPv4 dahil) erişim sağlandı
  • İlke olarak Dual-Stack Lite’a benziyor

Sunucu ve İstemci Yapılandırma Örnekleri

• WireGuard sunucu yapılandırması içinde hem IPv4 hem IPv6 trafiği işleniyor
  • MASQUERADE (dinamik IP dönüşümü), SNAT (sabit IP dönüşümü) kurallarına örnekler de yer alıyor
  • Doğrudan atanmış genel IPv6 kullanılarak NAT olmadan da WireGuard peer bağlantısı kurulabiliyor
  • PostUp/PostDown alanları birden fazla kez yazılarak komutların sırayla çalıştırılması sağlanabiliyor
• İstemci yapılandırma örnekleri
  • Doğrudan atanmış IPv6 adresi veya NAT’lenmiş ULA kombinasyonlarına dair örnekler açıklanıyor
  • AllowedIPs alanına 0.0.0.0/0, ::/0 eklenerek tüm trafiğin tünellenmesi mümkün oluyor
  • Google DNS (IPv4, IPv6) ve MTU ayarlama yöntemleri de veriliyor

Tünelin Sorunsuz Çalışması

• Her iki tarafta da WireGuard yapılandırması tamamlandıktan sonra IPv4/IPv6 trafiği sorunsuz şekilde tünellenebildi
• Aynı yöntem yazarın eşinin bilgisayarına da uygulandı ve Linux WireGuard istemcisi kolayca kuruldu
• Ancak kurumsal VPN ile aynı anda bağlantı genellikle mümkün olmadığından ek ağ namespace kullanımı gerekiyor

Ağ Namespace’leri ve Docker

İşlev ve Kullanım Yöntemi

• vopono gibi araçlarla uygulama bazlı ağ namespace’leri oluşturulup, ilgili namespace içinde VPN veya WireGuard arayüzü doğrudan belirtilebiliyor
  • Ayrı MASQUERADE kuralları tanımlamak gerekiyor; böylece iç trafik zorla WireGuard tüneline yönlendiriliyor
  • Dış dünyadan yalıtılmış DNS, gai.conf (IPv4 öncelikli DNS ayarı) gibi yapılandırma ipuçları da yer alıyor
• Namespace içinde VPN bağlantısı kurup uygulama çalıştırma yaklaşımına dair örnekler sunuluyor
  • Aynı namespace içinde birden fazla servis çalıştırılarak ağ çakışmaları önlenebiliyor

Docker Konteynerleriyle Birlikte Kullanım

• Docker daemon’u varsayılan olarak host ağ soketini kullandığı için yalnızca normal namespace içinde çalıştırmakla erişim sağlanamıyor
  • mount namespace, /sys bind mount gibi Unix sanallaştırma teknikleriyle bir workaround öneriliyor
  • dockerd, namespace içinde çalıştırılıp ayrı bir soket ve veri kökü tanımlanarak konteyner içindeki internet erişimi geri getiriliyor
  • Karmaşık ağ köprüsü ortamlarında ek ayarlar gerekebileceği de belirtiliyor

WireGuard MTU (MTU: Maksimum İletim Birimi) Sorunu

• WireGuard bağlantısından sonra bazı web sitelerine erişilemezken (ör. SSL), ping yanıtı alınabilen bir durum yaşandı
• Farklı boyutlarda ping testleriyle MTU’nun fazla yüksek olması nedeniyle büyük paketlerin yolda düşürüldüğü tespit edildi
  • MTU 1280’e düşürülünce sorun anında çözüldü
• MTU, tek seferde iletilebilecek en büyük paket boyutunu ifade eder
  • Tünel/kapsülleme ek yükü hesaba katılarak uygun MTU ayarı yapılmalıdır; aksi halde büyük paketlerde bağlantı sorunları oluşabilir
  • IPv6 için standarttaki en düşük MTU değeri 1280’dir

Sonuç ve Uygulama Tavsiyeleri

• WireGuard VPN sunucusu kurma, ağ namespace yönetimi, Docker için özel ortam ayarları ve MTU sorun giderme gibi başlıklarda Linux ve açık kaynak araçlarla ağ sorunlarını kendi başına teşhis edip çözme deneyimi öne çıkarılıyor
• Hetzner VPS gibi hizmetler fiyat/performans açısından istikrarlı ve WireGuard gibi yasal ağ servislerini işletmek için elverişli görülüyor
• Açık kaynak yönlendirici yazılımları (OpenWRT) ve Linux ağ tekniklerinin değeri yeniden vurgulanıyor
  • Ağı doğrudan yönetip değiştirebilme esnekliği, uzaktan çalışma ortamlarında büyük avantaj sağlıyor
  • Yeterli anlayış ve pratikle karmaşık ağ arızalarını da tek başına çözmek mümkün olabiliyor

Kaynaklar

• Tailscale – How NAT Traversal Works
• ArchWiki – WireGuard use case örnekleri
• Unix StackExchange – namespace içinde Docker hileleri
• AskUbuntu – DNS öncelik ayarı

(İlgili betikler, config’ler, ipuçları ve referans bağlantıları için özgün metne bakın)

[GN⁺]

Hacker News görüşleri

• Başlık biraz yanıltıcı gibi; aslında bu yazı daha çok “IPv6 tüneli üzerinden bir VPS’e bağlanıp IPv4 internete erişmek” ile ilgili, buna genelde 4in6 deniyor
  Yine de ilginç bir yöntem
  Bizim ISP’de IPv4 tarafında arıza olursa her şey tamamen gidiyor ve destek süreci nispeten daha basit oluyor; IPv6’da arıza olunca ise kısmi bozulmalar, yavaş bağlantılar ya da aralıklı erişim sorunları gibi daha garip belirtiler ortaya çıkıyor
  Özellikle de ağ geçidi IPv6 varmış gibi davranıyorsa, kullanıcı açısından sorun bazı özelliklerin çalışmaması gibi daha uğraştırıcı şekillerde görünebiliyor

  • Yakın zamanda IPv4 kısa süreliğine gidince Github’ın açılmamasından durumu fark etmiştim
    Günümüzde çoğu tüketiciye yönelik web sitesi IPv6 üzerinden düzgün çalışıyor
    Ama yönlendiricisi yalnızca IPv4 DNS sağlayan kişiler tamamen internetsiz kalmıştı
    Keşke Microsoft bu konuya biraz daha özen gösterse
    IPv4’ün geri gelip gelmediğini kontrol etmek için yönlendiriciye atadığım mDNS hostname’ini hatırlamam gerekmişti

  • Açıkçası evde IPv4 kesildiğinde eşim bunu fark bile etmedi
    Google, Facebook, Apple/iCloud ve CloudFlare tabanlı hizmetlerin neredeyse tamamı IPv6 üzerinden gayet iyi çalışıyor

  • Benim deneyimim de benzer
    IPv6 sorunlarında kök nedeni bulmak ve yeniden üretmek gerçekten zor; sürekli “ama bende çalışıyor?” durumu yaşanıyor

  • Çoğu ISP hâlâ IPv6’yı engelliyor, küçük şirketler de IPv6’yı denese bile AAAA kaydı gibi şeyleri unutabiliyor
    Bu yüzden kullanıcılar, arkadaşının evinde ya da kafedeki ucuz ISP bağlantısında bir şey çalışırken kendi evinde çalışmaması gibi durumlar yaşayabiliyor
    Kulağa tuhaf gelebilir ama çok iyi bir çözüm yok gibi; pratikte insan sadece IPv4’ün ortadan kalkmasını umuyor
    Happy Eyeballs gibi teknikler var (IPv4 ve IPv6 bağlantısını aynı anda deneyip daha hızlı olanı seçmek), ama pratikte sorunlar daha çok uygulama katmanında çıkıyor ve bunları çözmenin genel geçer bir yolu pek yok
    Ben kendi adıma ağda IPv6’yı açık bırakıp tarayıcıda IPv6 DNS’i kapatma gibi bir uzlaşma kullanıyorum ama tatmin edici değil

• IPv6 kullanmak isteyip de ISP’si sağlamayanlar için Hurricane Electric(HE) çok uzun zamandır ücretsiz tünel hizmeti veriyor
  İlgili bağlantılar arasında tunnelbroker.net, ipv6.he.net, Fedora kurulum rehberi, Brandon Rozek blogu, DD-WRT kurulum rehberi, Mikrotik forumu otomatik güncelleme betiği, RockyLinux rehberi gibi çeşitli kurulum yöntemleri var

  • Bir noktaya dikkat etmek lazım: yayın servisleri bunu sık sık engelliyor; VPN ile dolanma gibi algılanıyor ve bölge kısıtlı içerik yüzünden erişim kesiliyor
    Yine de RA (router advertisement) sayesinde herhangi bir ağ cihazı /64 düzeyinde IPv6 ağını yayınlayabiliyor; böylece yönlendirici HE tünelini doğrudan desteklemese bile ağdaki birçok cihaz IPv6 adresi kullanabiliyor (tabii yönlendirici güvenlik nedeniyle RA’yı filtrelemiyorsa)
    Evde bir şeyi dışarıya açmak istediğinizde bunu port forwarding olmadan yalnızca IPv6 ile yapabilmek çok kullanışlı

  • Hurricane Electric hizmeti iyi ama artık ISP’ler giderek daha fazla varsayılan olarak IPv6 sağladığı için sıradan kullanıcılar tünel hizmetlerinden uzaklaşıyor
    Ayrıca bazı ağ hizmetleri he.net tünellerini kötüye kullanım ya da istismar kaynağı olarak görüp engelliyor; sonunda ben de kendi ağımda IPv6 kullanımını büyük ölçüde kapatmak zorunda kaldım

  • Not olarak, Hurricane Electric tünelinin çalışması için ISP’den mutlaka genel bir IPv4 adresi almanız gerekiyor
    Eğer carrier-grade NAT gibi bir NAT ortamındaysanız, eve IPv6 getirmek için bu yöntem yerine başka bir çözüm bulmanız gerekir

  • HE’nin ücretsiz 6in4 tünelini OpenBSD ile 5 yıldır kullanan bir “müşteri” olarak konuşuyorum
    /etc/hostname.gif0 gibi dosyalarla yapılan ağ yapılandırması sayesinde uzun süredir sorunsuz çalışıyor
    Bunu AWS üzerinde bilerek IPv4’süz kurduğum bazı VPS kümeleriyle iletişimde de kullanıyorum
    AWS’nin IPv4 adresleri için ciddi ücret almaya başlaması nedeniyle bunun maliyetleri düşürmede çok yardımcı olduğunu düşünüyorum

• Gerçekten yalnızca v6 olan bir ortamda v4 erişimi gerekiyorsa, açık DNS64+NAT64 Gateway kullanmak oldukça kolay bir çözüm
  nat64.net üzerindeki açık sağlayıcı listesine bakılabilir
  Normalde yalnızca DNS sunucusunu değiştirmeniz yeterli
  DNS64, AAAA kaydı olmayan siteler için NAT64 kutusuna bağlanılabilsin diye sentetik AAAA kaydı üretir
  Sonrasında NAT64 trafiği alır ve protokol dönüşümü + NAT yapar
  Uygulamalı örnek olarak dig ya da curl komutlarıyla github gibi yerlere hemen erişmek mümkün

  • Avrupa’da nat64.net doğrudan kullanılsa bile oldukça akıcı çalışıyor
    Şahsen yalnızca iyi deneyimler yaşadım

  • Cloudflare WARP kullanılırsa hızın çok daha iyi olduğu hissediliyor
    WARP üzerinden IPv4 adreslerine doğrudan erişmek de mümkün

• Bazen gerçekten IPv6-only kullanıcılar olması bana ilginç geliyor
  Eskiden bunun tersi durumda (IPv4-only ortamdan IPv6 erişimi gerektiğinde), sunucu üzerinde tam denetiminiz varsa çok hızlı devreye alınabilen en iyi çözüm SOCKS5 proxy (ssh -D seçeneği) kullanmaktı
  Tarayıcıyı sadece socks proxy kullanacak şekilde ayarlamak hemen işe yarıyordu
  Bunu tüm sistem genelinde yapmak ise ssh bağlantısını bile koparabilir; endişe verici kısmı da bu

• Ben de benzer bir durumdayım
  Yaklaşık 2 haftadır IPv4 arızasıyla ilgili destek kaydı açık ama sadece “yakında bir teknisyen ilgilenecek” cevabı geliyor
  IPv6 çalıştığı için bunu tam kesinti olarak görmüyor gibiler
  Almanya’da bu tür durumlarda tüketici tazminatıyla ilgili yasalar var ama bu vakaya uyup uymadığını kontrol edeceğim
  Blog yazısında önerilen yöntemin sorunu şu: veri merkezi IP blokları birçok hizmet tarafından engelleniyor, captcha isteniyor ya da VPN sağlayıcısı IP’si gibi muamele görüyor; bundan kaçınmanın pek yolu yok
  Benim durumumda çözümü evin tamamı için uygulamak gerekti, bu yüzden yönlendiricide Wireguard ile yönlendirme ve NAT kuralları tanımladım; Ubiquiti EdgeRouter gibi açık bir cihaz olduğu için şanslıydım
  Eğer FritzBox olsaydı bunu yapmak muhtemelen çok daha zor olurdu
  Yalnız yönlendirici yeterince güçlü değilse bağlantı sayısı arttığında yavaşlıyor; bu yüzden donanım offload destekli IPSec’e geçmeyi düşünüyorum

  • FritzBox da VPN bağlantıları için gerçekten çok iyi bir GUI kurulum süreci sunuyor
    Temel varsayım FritzBox to FritzBox olsa da, uyumlu bir VPN ise sorun yok
    Sabit IPv4/IPv6 rota tanımları da destekleniyor
    En büyük sorun karşı tarafta hangi IPSec şifreleme ayarlarının istendiğini anlamak; Wireguard daha kolay ama öte yandan donanım hızlandırma konusu var
    Gerekirse FritzBox yapılandırmasının tamamını yedekleyip elle düzenledikten sonra sadece checksum’u yeniden hesaplayarak tekrar içe aktarma gibi teknikler de var
    AVM kullanıcıya göstermediği çok büyük miktarda ayrıntılı ayarı içeride saklıyor; bu bilinçli bir tercih
    İnsanların yanlışlıkla yönlendiriciyi bozmasını önlemek için bazı şeyleri bilerek biraz zorlaştırmışlar

  • Almanya’daki durumu bilmiyorum ama Hollanda’da sabit ve mobil internet için aynı ISP’yi kullanıyorsanız, sabit hat arızalandığında ücretsiz mobil veri talep edebiliyorsunuz
    Mümkünse ISP’ye bu seçeneği sormanızı tavsiye ederim

• Bu kadar zamana rağmen tüm cihazlarımı ve ev laboratuvarımı IPv6’ya geçirmek için net bir neden hâlâ göremiyorum
  Port forwarding ve firewall ayarları en azından daha sezgisel; IPv6’ya geçince haftalarca sorun giderme, firewall ve adres yeniden yapılandırması gibi karmaşıklıklar çıkacakmış gibi geliyor
  Acaba benim gözden kaçırdığım bir şey mi var

  • Gerçekçi olmak gerekirse şu aşamada kaçırdığınız pek bir şey yok
    İleride Google, Cloudflare gibi büyük şirketler giderek artan IPv4 adres maliyetlerini taşımakta zorlanırsa IPv6 lehine teşvikler verebilirler (örneğin IPv4 bağlantılarına hız sınırlaması gibi)
    AWS de eskiden yalnızca kullanılmayan IPv4 Elastic IP’lere ücret keserken artık kullanılıyor olsa bile ücret alıyor
    Gelecekte ağ geçidi ya da yönlendirici yükseltirken IPv6’yı da açık bırakmak mantıklı olabilir; şu anda IPv4/IPv6 dual-stack ile mevcut cihazlar ve hizmetler sorunsuz çalışır
    IPv6 otomatik adresleme konusunda tarihsel olarak ortalık biraz dağınıktı ama gidişat SLAAC yönünde; ISP tarafında ise DHCPv6’nın daha uzun süre kullanılacağı anlaşılıyor

  • Aslında o kadar zor değil
    Özel olarak karmaşık bir ev ağı yoksa akşamdan kısa bir vakit ayırarak IPv6 kurulumu yapılabilir
    Comcast örneğinde yönlendiricide IPv6 seçeneğini açınca ISP’den prefix geliyor ve bu tek başına ağa otomatik olarak duyuruluyor; sonra sadece istediğiniz portları firewall’da açmanız yetiyor

  • Kaçırdığınız bir şey yok
    Kurumsal ortamlarda IPv6’ya geçmenin artılarından çok eksileri ve karmaşıklığı var
    Ben yaklaşık 3500 cihaz, 7 bina, 2 adet 10Gbps ve 1 adet 4Gbps WAN ile 26 genel IPv4 adresi yönetiyorum
    Şu ana kadar IPv6 kullanmak zorunda olduğum hiçbir durum olmadı
    Dual-stack çalıştırmak ağa gereksiz yük ve karmaşıklık getiriyor
    Hatta yakın zamanda sabit bir IPv6 adres bloğu almak için iki kez başvurdum ve ikisi de reddedildi
    Pratikte bir kazancı yok, üstüne üstlük tahsis almak bile zor
    ARIN IPv6 ilk başvuru rehberi incelendiğinde,
    → IPv4 tahsisine sahip olmak
    → IPv6 multihoming’i hemen planlıyor olmak
    → 1 yıl içinde 13 uç siteye (ofis vb.) ulaşmak
    → 1 yıl içinde 2000 IPv6 adresi kullanacak olmak
    → 1 yıl içinde 200 adet /64 alt ağ kullanacak olmak
    koşullarından en az birini sağlamanız gerekiyor

• Apple App Store politikasında tüm uygulamaların IPv6-only ağlarda çalışması gerektiği şartını gerçekten takdir ediyorum
  Geliştirici açısından ilk başta şaşırtıcı olabilir ama tüketici tarafında böyle bir zorunluluk görmek çok sevindirici

  • Ancak bu politika sunucu tarafında IPv6 adresine sahip olmayı zorunlu kılmıyor

  • O zaman uygulama üzerinden github’ın v6 ile erişilebilir olup olmadığını merak ediyorum

• İş ortamında dahili altyapıya erişim için birkaç tane IPv6 only VPN işletiyoruz
  En büyük sorun, Windows ve macOS istemcilerinin mutlaka v6 DNS sunucusuna ihtiyaç duyması
  İstemci v6 destekleyen bir ağda da olabilir, olmayan bir ağda da; bu yüzden VPN içinde doğrudan DNS sunucusu çalıştırıp bunu istemcilere otomatik iletiyoruz
  Ama VPN bağlantısı koptuğunda Wireguard uygulaması DNS’i eski haline döndüremiyor ve çeşitli sorunlar çıkıyor

  • Ben ISP’nin IPv4 only ağı ve macOS ortamında da ayrı bir DNS olmadan IPv6-only kullanabildim
    Tam olarak nasıl yaptığımı hatırlamıyorum ama macOS yalnızca v6 adresi verilince de sorunsuz çalışıyordu
    Host’a bir ULA adresi tanımlamak yeterli, bunu bilen kullanıcı için oldukça kolay
    VPN uygulaması IPv6-only ağ için ULA ekleyen bir betik kullanabilir
    Yalnız oluşturulan ULA adresi öylece bırakılırsa kullanıcı başka bir v6 ağına geçtiğinde sorun yaratabilir

• Aynı durumdaysanız ssh -D 8080 user@hostname ile kolayca ssh proxy üzerinden socks proxy ortamı kurabilirsiniz
  Sonra tarayıcı proxy adresini localhost:8080 olarak ayarlamanız yeterli

  • Ben de tam olarak bunu önerecektim
    Geçici çözüm olarak çok basit, gerektiğinde kalıcı araç olarak da gayet iyi
    Yalnız sshd_config içinde AllowTcpForwarding etkin olmalı

  • Ben kamusal Wi‑Fi kullanırken bunu hep yapıyorum
    VPN hizmetine para vermeye gerek kalmıyor; güvenmek zorunda da değilsiniz, trafiği kendi infomaniak sunucum üzerindeki socks proxy’ye gönderiyorum

• Kişisel olarak IPv4’ten çok şikâyetçiyim; özellikle de ISP’min beni zorla yalnızca IPv4’te tutması daha da sinir bozucu
  IPv6’nın bu kadar yavaş benimsenmesini teknoloji sektörünün büyük bir başarısızlığı olarak görüyorum
  Bundan kimin sorumlu tutulması gerektiğini düşünüyorum
  Sorun kötü router firmware’leri mi, ISP’lerin IPv4 odaklı liderliği mi, IPv4 adres spekülatörleri mi, yoksa ağ mühendisleri ve destek personelinin yetersiz eğitimi mi; bence nedenlere dair daha temel bir tartışma gerekli
  İnternet TLS 1.0’dan görece iyi geçebildiyse, IPv4’ten de çıkabilmeli diye düşünüyorum
  İleride legacy kod için bir tür yapay zeka proxy’si bile çözüm olabilir

  • TLS 1.0’dan geçişin daha kolay olmasının nedeni end-to-end principle idi
    Sunucu ve istemcinin yeni protokolü desteklemesi yetiyordu; aradaki cihazlar (router, switch vb.) yalnızca ağ katmanındaki IP’ye bakıyordu ve TLS’nin yeni sürümünden etkilenmiyordu
    Ama ağ katmanı protokolünü (IP) değiştirirseniz aradaki tüm ağ cihazları etkilenir
    Hatta TLS 1.3 geçişinde bile middlebox’lar end-to-end ilkesini bozup trafiği izlediği/değiştirdiği için uyumluluk adına TLS 1.3’ün TLS 1.2 yeniden bağlantısı gibi görünmesini sağlayan garip hileler gerekmişti

  • Fark şu ki TLS’de sadece sunucu ve istemcinin desteklemesi yeterlidir; aradaki ağ cihazları yalnızca TCP paketlerini görür
    IPv6 ise sunucu ile istemci arasındaki tüm ara cihazların desteklemesini gerektirir; yani “en düşük ortak payda”ya bağımlı bir teknolojidir
    TLS yükseltmesi çok büyük değişiklikler getirmemişti ama IPv6 aynı anda fazla sayıda şeyi değiştirdi
    Geriye dönüp bakınca insan, IPv6 yalnızca adresleri 64 bite çıkarsaydı belki yaygınlaşması daha kolay olurdu diye düşünüyor

  • Gerçekte birçok insan geçişin somut faydasını çok az gördüğü ya da hiç görmediği için isteksiz davranıyor
    Büyük bir IPv4 komplosu yok; mesele sadece yapılan iş ve alınan risk karşısında getirinin az olması

  • Ağ dünyasında “IPv6, mühendislik sorununa uydurulmuş akademik bir çözüm” diye bir şaka vardır
    IPv4 ile uyumluluğu koruyarak bunu büyük ölçekte gerçekten devreye almak, işletmek ve bakımını yapmak düşünülünce IPv6 fazla karmaşık kalıyor
    Aslında adres kıtlığı dışında IPv4’ün çözemediği ciddi bir sorun da yok; bu yüzden IPv4’ün tamamen ortadan kalkması pek olası görünmüyor
    Bu nedenle sahada IPv6 çoğu zaman gerçek bir çözüm gibi hissedilmiyor