IPv6'nın harika bir tasarım olduğu dünya (2017)
(apenwarr.ca)- İlk ağlarda odak noktadan noktaya bağlantılardı; bu yüzden neredeyse hiç adresleme şemasına ihtiyaç yoktu, ancak maliyeti düşürmek için veriyolu ağlarının yayılmasıyla MAC adresleri, köprüleme ve ARP gibi karmaşıklıklar birikmeye başladı
- Ethernet ile IP birleşince bir sonraki sıçramaya iletim için MAC adresleme ve ARP yayınları gerekli hale geldi; bu yük büyük birbirine bağlı ağlarda ve wifi'da çok daha fazla büyüdü
- IPv6 tasarımında fiziksel veriyolunu ve layer 2 internetwork'ü terk edip yayın, ARP, DHCP ve hatta MAC adreslerini ortadan kaldıran daha basit bir dünya beklentisi vardı
- Ancak gerçek dağıtım ortamlarında IPv4 ve mevcut çerçeveleme varlığını sürdürdü; neighbor discovery, DHCP, NAT ve layer 2 köprüleme gibi miraslar da birlikte kaldı
- Hareket halindeyken bağlantıyı korumak için Internet yönlendirmesi yerine layer 2 köprüleme ve merkezi tünelleme hâlâ kullanılıyor; QUIC gibi alternatifler ise roaming için dolaylı bir çıkış yolu olarak anılıyor
Veriyolu ağlarının her şeyi mahvetmesinin başlangıcı
- Telefon şebekesinin ilk devre anahtarlamalı ve kiralık hat ortamlarında yalnızca noktadan noktaya bağlantılar vardı; bu yüzden adresleme şemasına ihtiyaç yoktu ve bir taraftan giren bitler belli bir süre sonra diğer taraftan çıkıyordu
- TDM ve sanal devre anahtarlama geldikten sonra da kullanıcı açısından yapı hâlâ bir uçtaki girdinin diğer uçtaki çıktıya bağlanması şeklindeydi; bu aşamada da adres gerekmiyordu
- Birden çok arayüze sahip bilgisayarlar hatlar arasında bit aktarmaya başlayınca IP adresleri, alt ağlar ve yönlendirme ortaya çıktı, ama noktadan noktaya bağlantılarda yine de MAC adreslerine ihtiyaç yoktu
- Yerel sahaları bağlama maliyetini düşürmek için birçok cihazın aynı hatta bağlandığı veriyolu ağları ortaya çıktı ve Internet ailesinden ayrı, kendine özgü layer 2 yapıları gelişti
- İlk LAN'lardan arcnet'te 8 bitlik layer 2 adresleri jumper veya DIP switch ile elle ayarlamak gerekiyordu; çakışma olursa ciddi arızalar çıkıyordu, ama ağlar küçük olduğu için bu rahatsızlık sınırlıydı
- Ethernet, 48 bitlik MAC adreslerini getirerek üretim aşamasında neredeyse benzersiz adres verme yöntemiyle çakışma sorununu çözdü
- IPX ve Netware gibi LAN teknolojileri tek bir veriyolu ağı içinde adres ayarı olmadan iyi çalışıyordu; bu dönem zarif ve güvenilir işleyen bir çağ olarak anlatılıyor
- Büyük şirket ve üniversite ağları tek bir 10 Mbps veriyolunun darboğazı nedeniyle birden çok veriyolunu birbirine bağlamak zorunda kaldı, ancak o dönemde yeterince olgunlaşmamış IP yerine Ethernet adreslerine dayalı köprüleme ve anahtarlamayı büyüme yolu olarak seçti
- Ethernet adresleri fabrikada sıralı verildiği için hiyerarşik değildi; bu yüzden köprü tabloları, alt ağ bazlı yolları tutan modern IP yönlendirme tabloları gibi verimli biçimde gruplanamıyordu
- Verimli köprüleme için her MAC adresinin hangi veriyolunda olduğunu hatırlamak gerekiyordu
- Bunu elle ayarlamamak için otomatik öğrenme ve karmaşık etkileşimler gerekti
- Karmaşık köprü ağları spanning tree gibi yöntemlerle birbirine bağlandı; bunun sonucu yayın taşması, optimal olmayan yollar ve düşük hata ayıklanabilirlik oldu
- Aradaki köprülerde normal Ethernet'te adres kavramı olmadığı için traceroute benzeri araçlar yapılamıyordu; köprüleme pratikte neredeyse hata ayıklanamaz bir yapıydı
- Buna rağmen köprüleme, donanım optimizasyonu sayesinde Ethernet hat hızına yakın şekilde çok hızlı çalışıyordu ve o dönemde bu büyük bir avantajdı
Veriyolu üzerinde çalışan Internet
- Uzak mesafeli noktadan noktaya bağlantılarla tek tek bilgisayarları bağlayan yapıdan, zamanla tüm LAN'ı bağlama ihtiyacı doğdu ve LAN'lar arasında uzun mesafeli bağlantılar gerekli hale geldi
- Basit uzun mesafeli köprüleme, tıkanıklık denetimi sorunları yüzünden işe yaramıyordu; Ethernet köprüleme tüm bağlantıların benzer hızda olduğu ya da tıkanıklığın çok az olduğu varsayımıyla çalışıyordu
- 10 Mbps Ethernet ile 0.128 Mbps noktadan noktaya hattı doğrudan köprülemek umutsuzdu; flooding tabanlı yol keşfi de yavaş hatlarda aşırı savurgandı
- Yerelde katlanılabilir olan optimal olmayan yönlendirme, yavaş ve pahalı uzun mesafeli hatlarda ölümcüldü; dolayısıyla ölçeklenebilir değildi
- Bu sorun kümesi, Internet tarafının zaten ilgilendiği bir alandı; LAN veriyollarını Internet teknolojileriyle bağlamak çok daha iyi bir yapı sağlayabilirdi
- Böylece Ethernet ve arcnet gibi LAN'lar üzerinde Internet paketlerini taşıyan çerçeve biçimleri tasarlandı ve sorunlar da bu noktada başladı
- Aynı Ethernet segmentinde birden çok IP yönlendiricisi varsa, paketi hangi yönlendiricinin alıp ileteceğini ayırt etmek gerekiyordu; yalnızca nihai hedef IP bu seçimi ifade etmeye yetmiyordu
- Bu nedenle nihai hedef IP başlıkta kalırken, gerçek bir sonraki sıçrama yönlendiricisi Ethernet çerçevesinin MAC adresi ile belirtilmek zorunda kaldı
- İnsanın ifade etmek istediği gerçek bilgi
hedef IP 10.1.1.1'i yönlendirici MAC 11:22:33:44:55:66'ya gönderolsa da, işletim sistemi bunu192.168.1.1 yönlendiricisi üzerindengibi bir biçimde ele aldı - Bu soyutlama için işletim sistemi önce yönlendirici IP'sinin Ethernet adresini bulmak zorundaydı ve aradaki adım olarak ARP eklendi
- ARP, yerel Ethernet'in tamamına belirli bir IP'nin sahibini bulmak için yayın gönderen bir yöntemdir; arada köprü varsa Ethernet yayını olduğu için tüm arayüzlere iletilmesi gerekiyordu
- Büyük birbirine bağlı Ethernet ağlarında aşırı yayın en büyük kabuslardan birine dönüştü; özellikle wifi'da daha da kötüydü
- Sonrasında köprüler ve anahtarlar ARP'nin yayılım alanını daraltmak için özel hileler eklemeye başladı; bazı cihazlar, özellikle wifi erişim noktaları, sahte ARP yanıtları bile üretti ama bunların hepsi teknik hack'lere yakındı
Miras yüzünden ölüm
- Zamanla Ethernet üzerindeki IP dışı protokollerin neredeyse tamamı kayboldu ve ağlar, fiziksel katman kabloları üzerinde veriyolu biçimli layer 2, bunları birbirine bağlayan köprüler ve onun üzerinde layer 3 yönlendiricilerden oluşan bir yapıya oturdu
- Elle IP yapılandırmanın yorgunluğu artınca otomatik yapılandırma ihtiyacı doğdu, ancak cihazlar zaten Ethernet adresleriyle fabrikadan çıkıyordu ve IPv4'ün 32 bit adresleri üretim aşamasında kalıcı biçimde benzersiz atama yapmak için yetersizdi
- IP adreslerini basitçe sıralı vermek, yeniden Ethernet gibi hiyerarşik olmayan bir yapıya dönmek anlamına geldiği için iyi bir çözüm değildi
- Bu yüzden bootp ve DHCP ortaya çıktı; bunlar da ARP gibi özel işlem gerektiren protokoller haline geldi
- DHCP, henüz IP adresi olmayan bir düğümün önce gönderim yapmasını gerektirdiği için, RFC'de tanımlı biçimde fiilen anlamsız bir IP başlığı doldurmak zorundaydı; DHCP sunucusu da bunu çekirdek IP katmanı yerine raw socket ile doğrudan doldurmak zorundaydı
- bootp ve DHCP sonuçta bir IP adresi atayabilmek için Ethernet adresini bilmek zorundaydı; dolayısıyla ARP'nin tersine yakın bir rol oynadılar
- RARP aynı işi daha basit biçimde yapıyordu, ancak burada neredeyse hiç ele alınmadığı belirtiliyor
- Sonuç olarak Ethernet ile IP giderek daha sıkı biçimde birbirine dolandı ve bugün neredeyse ayrılmaz hale geldi
- IP yönlendirme tabloları yönlendiricileri IP adresiyle gösteriyormuş gibi yapsa da aslında dolaylı biçimde MAC adreslerini gösteriyor; ARP köprülerin üzerinden geçiyor ve DHCP IP paketi gibi görünse de aslında Ethernet protokolüne daha yakın bir yapı oluyor
- Aynı anda hem köprüleme hem yönlendirme daha karmaşık hale geldi; köprüleme çoğunlukla IEEE ve donanım dünyasında, yönlendirme ise çoğunlukla IETF ve yazılım dünyasında kaldı ve iki taraf birbirini yok sayar gibi davrandı
- Ağ yöneticileri hız gereksinimine ve DHCP sunucusu yapılandırmaktan kaçınma derecesine göre köprüleme ile yönlendirme arasında seçim yaptı; olabildiğince köprüleme kullanıp yalnızca gerektiğinde yönlendirmeye geçtiler
- Köprüleme karmaşıklığı sonunda layer 2 kararlarını üst katmanlara taşıyıp IP üzerindeki protokollerle merkezi biçimde yöneten SDN'e uzandı
- SDN, anahtarların ve köprülerin kendi başına rastgele davranmasından daha iyiydi, ancak başlangıçta zaten fazla büyümüş ağı yazılımla ele alan IP'nin kendisinin de zaten yazılım tanımlı bir ağ olduğu düşünülürse bunun temelde ironik olduğu söyleniyor
- IPv4 başlangıçta donanım hızlandırmaya uygun değildi ve pratikte de donanım hızlandırması yeterince iyi olmadı; DHCP yapılandırması da çok zahmetliydi, bu yüzden yöneticiler giderek daha büyük alanları köprülemeyi öğrendi
- Günümüzün büyük veri merkezleri fiilen SDN tabanlı dev bir sanal veriyolu ağı gibi çalışıyor ve çoğu durumda paketleri gerçek anlamda yönlendirmiyor deniyor
Şimdi yukarıdaki hikâyeyi bir anlığına unutalım
- 1990'ların başında IETF IPv6'yı tasarlarken zaten büyük bir karmaşa başlamıştı, ama yaklaşan felaketin önlenebileceği varsayımıyla tasarım sürdürüldü
- Bu süreçteki temel değişimlerden biri, fiziksel veriyolu ağlarının kullanımının fiilen sona ermiş olmasıydı
- Ethernet artık gerçek bir veriyolu değildi, yalnızca öyleymiş gibi davranıyordu; hız arttıkça CSMA/CD'yi sürdürmek imkânsız hale geldi ve yeniden yıldız topolojisine dönüldü
- Her istasyondan merkezi anahtara ayrı kablo çekilen yapı yaygınlaştı ve duvarlar, tavanlar, zeminler büyük ve pahalı Ethernet kablo demetleriyle doldu
- Hatta wifi bile paylaşımlı kablosuz ortam olarak nihai veriyolu gibi görünse de, pratikte neredeyse tamamen infrastructure mode ile dev bir yıldız topolojisini taklit ediyor
- Aynı erişim noktasına bağlı iki wifi istasyonu bile doğrudan haberleşmiyor; karşı tarafın MAC adresi yazılı paketi erişim noktasına gönderiyor ve erişim noktası bunu yeniden iletiyor
- X düğümünün Internet'teki Z düğümüne, IP yönlendiricisi Y üzerinden, wifi erişim noktası A aracılığıyla gönderim yaptığı durumda Z IP hedefi, Y Ethernet hedefi, A ise gerçek kablosuz iletim karşı tarafı oluyor; adres katmanları karmaşık biçimde üst üste biniyor
- Bunun için 802.11, gerçek Ethernet hedefi ile ara Ethernet hedefini birlikte taşıyan 3-address mode sunuyor
- Ayrıca
to-APvefrom-APbitleri var; bunlar istasyon→AP ve AP→istasyon yönünü gösteriyor, her iki bit de aynı anda doğruysa AP'ler arası aktarıcı davranışı da ifade edilebiliyor - A bir repeater olup paketi tekrar baz istasyonu B'ye göndermeliyse, havadaki gerçek gönderici/alıcı ile Ethernet kaynak/hedefinin hepsi farklılaştığından 4-address mode gerekiyor
- 802.11s mesh'te 6-address mode'a kadar çıkılıyor; yazar da bu noktada anlamayı bıraktığını söylüyor
IPv6'nın iyi bir tasarım olduğu dünya
- IPv6'yı düşünen IETF, yaşanmış karmaşayı ve ileride gelecek daha büyük karmaşayı görerek mevcut mirası geride bırakan yeni bir dünya hayal etti
- Bu dünyanın varsayımları; fiziksel veriyolu ağlarının kaldırılması, layer 2 internetwork'ün kaldırılması, yayınların kaldırılması, MAC adreslerinin kaldırılması, ARP ve DHCP'nin kaldırılması, donanım hızlandırmaya uygun basit bir IP başlığı, adres kıtlığının çözülmesi ve çekirdek dışında elle IP yapılandırmasının kaldırılmasıydı
- Eğer layer 2 her zaman noktadan noktaya olsaydı yayın gönderilecek bir hedef olmazdı; dolayısıyla multicast ile değiştirilebilirdi ve gönderici ile alıcı zaten açık olduğu için MAC adresleri de gereksiz olurdu
- MAC adresleri ortadan kalkarsa IP ile MAC arasındaki eşleme de gerekmeyeceği için ARP ve DHCP de ortadan kalkabilir; ayrıca büyük alt ağ yönlendirmesini yeniden kullanmaya yetecek kadar geniş adres alanı sağlanabilirdi
- Bu dünyada wifi repeater'lar, wifi erişim noktaları, Ethernet anahtarları ve hatta SDN'in tamamı IPv6 yönlendiricileri olarak çalışmış olacaktı deniyor
- Böylece ARP storm, IGMP snooping bridge ve bridging loop ortadan kalkacak, tüm yönlendirme sorunları traceroute ile izlenebilir olacaktı beklentisi vardı
- Her Ethernet paketindeki 12 baytlık kaynak/hedef MAC adresleri ve her wifi paketindeki 18 baytlık adres bilgisi kaldırılabildiği için, IPv6 IPv4'ten 24 bayt daha büyük adresler kullansa bile Ethernet başlığının kalkması hesaba katıldığında gerçek ek yükün yalnızca 12 bayt olduğu hesaplanıyor
- Bu şekilde bir gün Ethernet adreslerinin kendisini kaldırma beklentisinin, IPv6 adres uzunluğunun aşırı büyüklüğünü gerekçelendirmeye yardım ettiği anlatılıyor
- Ancak bu güzel tasarım gerçek dünyada hayata geçmedi
Rüya için ağıt
- Bir iş arkadaşının söylediği "katmanlar yalnızca eklenir, kaldırılmaz" sözü genel sonuç olarak veriliyor
- IPv6'nın avantajları, ancak mevcut mirası bırakıp yeniden başlayabilmek mümkün olsaydı geçerli olacaktı; gerçekte ise bu neredeyse imkânsızdı
- IPv6 yaygınlığı %99'a ulaşsa bile IPv4 tamamen ortadan kalkmadığı sürece Ethernet adresleri ve wifi adresleri de kaybolmaz; IEEE 802.3 ve 802.11 çerçeveleme standartları sürdükçe ilgili bayt tasarrufu da gerçekleşmez
- Bu yüzden IPv6 sonunda ARP'den daha karmaşık bir neighbor discovery mekanizmasına ihtiyaç duydu ve veriyolu ağları ortadan kalksa bile ARP benzeri davranış için yayın benzeri simülasyonlar gerekmeye devam etti
- Evlerde eski IPv4 ampulü çalıştırmak için yerel DHCP sunucusu hâlâ çalıştırılmak zorunda ve o ampulün internete çıkabilmesi için NAT de sürmek zorunda deniyor
- Daha kötüsü, IPv6 ekibi mobile IP sorununu çözmeden bırakmış; bunun sonucu olarak korkunç layer 2 köprüleme hâlâ gerekli olmuş
- O dönemde planın, önce IPv6'yı birkaç yıl içinde yaygınlaştırmak, IPv4 ve MAC adresleri ortadan kalktıktan sonra mobile IP'yi daha kolay çözmek olduğu anlaşıldığı söyleniyor
- O zamanlar hareket halinde bilgisayar kullanımı neredeyse yok sayıldığı için, yalnızca Ethernet portları arasında dolaşırken ftp oturumunu sürdürmek gibi tuhaf senaryolar hayal edilebildiği anlatılıyor
Katil uygulama olarak mobile IP
- Sonraki tarihte yanımızda taşıdığımız bilgisayarlar, yani telefonlar, farklı kablosuz erişim noktaları arasında hareket ettirilen günlük araçlar haline geldi
- LTE'de bu geçiş çoğunlukla çalışıyor, wifi'da ise bazen çalışıyor; ama bunun sırrının Internet yönlendirmesi değil layer 2 köprüleme olduğu söyleniyor
- Internet yönlendirmesi hareketliliği hiç ele almıyor; IP ağında yer değiştirip IP adresiniz değişince açık tüm bağlantılar kopuyor
- Kurumsal wifi, LAN'ın tamamını layer 2'de köprüleyerek merkezi DHCP sunucusunun hangi erişim noktasına bağlanırsanız bağlanın aynı IP adresini vermesini sağlıyor; köprü yeniden yapılandırılırken yaşanan birkaç saniyelik karışıklık dışında bağlantı korunuyor
- Çok sayıda extender veya repeater bulunan ev wifi'ları da aynı yöntemi kullanıyor
- Buna karşılık yürürken mağazaların sunduğu açık wifi'lar gibi farklı wifi ağları arasında geçince her seferinde yeni bir IP adresi alınıyor ve tüm bağlantılar kopuyor
- LTE ise daha da ileri gidip kilometrelerce farklı baz istasyonları arasında hareket ederken bile aynı IP adresini koruyor; mobil ağlarda da çoğunlukla IPv6 adresleri kullanıldığı belirtiliyor
- Bunun yöntemi, trafiği merkezi bir noktaya tünelleyip ardından çok sayıda güvenlik duvarıyla birlikte tek bir aşırı büyük sanal layer 2 LAN olarak köprülemek; bunun bedeli de korkunç bir karmaşıklık ve utandıracak düzeyde ek gecikme
- Operatörlerin bunu düzeltmek istediği, ama neredeyse imkânsız olduğu söyleniyor
Mobile IP'yi gerçekten çalıştırmanın yolu 1
- mobile IP'nin neden düzgün çalışmadığına verilen yanıt, oturum tanımlamak için kullanılan meşhur 4-tuple tanımının yanlış olması sonucuna bağlanıyor
- TCP ve UDP oturumları
(source ip, source port, destination ip, destination port)ile tanımlanıyor; bu yapı layer 3 ile layer 4 arasında uzanıyor ve IP adresi değişimlerine karşı kırılgan - Oturum tanımlama yalnızca layer 4 verisine dayanıyor olsaydı mobile IP kusursuz çalışırdı iddiası ortaya atılıyor
- Örnek olarak X:1111, Y:80 ile konuşurken X adresini Q'ya değiştirirse paket
(Q,1111,Y,80)olur; Y bunu mevcut oturum olarak tanımaz ve atar, Y'nin(Y,80,X,1111)olarak geri gönderdiği paket de artık X'e ulaşamaz - Alternatif olarak port numaralarının bugünkü 16 bit yerine 128 ya da 256 bitlik benzersiz hash değerleri kadar büyütülmesi ve soketlerin IP adresinden bağımsız etiketlerle tanımlanması öneriliyor
- Bu durumda paketler layer 3'te yönlendirme için yine
(X,Y)adres bilgisini taşır, ama çekirdek alım sırasında soket tanımlaması için layer 3 bilgisini kullanmaz; yalnızca uuid kullanır - Hedef port 80 ise yalnızca yeni oturum başlarken istenen hizmeti seçmek için gerekir; sonrasında görmezden gelinebilir ya da atılabilir deniyor
- Y'nin çekirdeği
(uuid)oturum paketinin yakın zamanda X'ten geldiğini önbelleğe alır; X daha sonra Q'ya taşınıp aynı(uuid,80)etiketiyle gelirse bunu o oturumla eşleyip yanıt hedefini X yerine Q olarak güncelleyebilir - Bu sayede bağlantı korunur, ancak sahteci tarafından bağlantının ele geçirilmesini önlemek için ek önlem gerektiği notu düşülüyor
- Ancak UDP ve TCP böyle çalışmıyor ve bunu bugün değiştirmek, IPv4'ü IPv6 ile değiştirmek kadar kolay görünse de on yıllar sonra bile yarısından azı tamamlanmış türden bir proje olarak değerlendiriliyor
QUIC ve dolaylı olarak mümkün bir çıkış
- Olumlu tarafta, bir başka katman ihlali sayesinde dolaylı bir çözüm ihtimali sunuluyor
- Eski TCP'yi bırakıp UDP üzerinde QUIC kullanılırsa, UDP'nin 4-tuple'ını bağlantı tanımlayıcısı olarak kullanmayan bir yaklaşım mümkün olabilir
- UDP portu özel bir mobility layer portuysa, içeriği yeniden açılıp uygun uuid etiketli iç paketler olarak yorumlanabilir ve bunlar doğru oturumla ve soketle eşleştirilebilir
- Deneysel QUIC protokolünün en azından teoride böyle bir yapıya uygun paket biçimine zaten sahip olduğu söyleniyor
- QUIC'in kullandığı durumsuz paket şifreleme ve kimlik doğrulama zaten benzersiz oturum kimlikleri veya anahtarlar gerektirdiği için, görece az ek çalışmayla şeffaf roaming desteğinin mümkün olabileceği umudu dile getiriliyor
- Böyle olursa geriye sadece UDP ve TCP'yi Internet'ten tamamen kaldırmak kalır; o zaman bu kez gerçekten layer 2 köprülemeye gerek kalmayacak ve yayınlar, MAC adresleri, SDN ve DHCP de ortadan kaldırılabilecek deniyor
- Son cümle Internet'in zarafetinin geri kazanılması ifadesiyle bitiyor
Ek düzeltmeler
-
2017-08-16 düzeltmesi
- Yukarıdaki mobile IP fikrinin IPv6 ile sınırlı olmadığı belirtiliyor
- IPv4 ve NAT ortamlarında, hatta birden çok NAT üzerinden roaming durumlarında bile çalışabileceği yönünde düzeltme yapılıyor
-
2017-08-15 düzeltmesi
- Bağlantı ele geçirmeyi önleme yolu olarak TCP başlangıcındaki SYN-ACK-SYNACK benzeri alışveriş en basit örnek diye veriliyor
- Y, yeni ana makine Q'dan gelen ilk pakete hemen güvenirse, Internet'in herhangi bir yerindeki saldırganın X→Y bağlantısını ele geçirmesi kolaylaşır
- Y bir çerez gönderip Q da bunu alıp işleyerek yeniden Y'ye gönderirse, en azından basit bir dış saldırgan değil, aradaki adam düzeyinde bir saldırgan gerekmiş olur
- QUIC gibi şifreli protokoller kullanıldığında, bu handshake de oturum anahtarıyla korunabilir
-
2017-10-24 düzeltmesi
- QUIC dışında da bu tür roaming destekli TCP yerine geçebilecek protokol adayları olduğu ve MinimaLT'nin örnek verildiği belirtiliyor
- MinimaLT'nin roaming sorununu zarif biçimde çözen ilk protokol olduğu duyulduğu ve gelecekte benimsenen çözümlerin de bu yapıyı taklit edebileceği söyleniyor
-
2020-07-09 düzeltmesi
- IPv4/IPv6 geçişi ve birlikte çalışabilirlik üzerine ek düşüncelerin başka bir yazıda yayımlandığına değiniliyor; metin içinde ek açıklama yok
1 yorum
Hacker News yorumları
Benim bakış açıma göre IPv6, kusursuz protokol tasarımının zirvesi olmayabilir ama insanların ortaya koyduğu daha iyi alternatifler sonunda yine IPv6’ya benzer bir biçime yakınsıyor. Herkes sürekli bundan daha iyisini çıkaramıyorsa, bu sonuçta IPv6’nın epey iyi bir tasarım olduğunu gösterir
Eski Hacker News tartışmalarına bakınca bu konunun 2017 başlığı, 2019 başlığı, 2020 başlığı, 2023 başlığı gibi birkaç yılda bir sürekli geri döndüğü görülüyor
Bu yazının ARP’ye fazla olumsuz yaklaştığını düşünüyorum. ARP sayesinde yönlendirici olmadan da LAN içinde IP ağ iletişimi mümkün oluyor ve varsayılan ağ geçidi de aynı genel LAN IP iletişiminin özel bir durumu olarak ele alınabiliyor. Yine de ağ tarihine dair anlatım gerçekten harika; IPv6 kısmını da hâlâ okuyorum
Bu yazının tam olarak ne demek istediğini biraz karıştırdım. Ağ cihazlarımın MAC adreslerine dayanarak kendi IPv6 adreslerini aldığını mı söylüyor, bunun da stateless IPv6’ın özü mü olduğunu merak ediyorum. Bildiğim kadarıyla IPv6, IPv4 tükenmesi ve NAT sorununu çözmek için de ortaya çıktı. Ama Xbox’ım IPv6 yoksa ağın kötü olduğunu söylüyor; bu da bana epey Kuzey Amerika merkezli bir bakış gibi geliyor
IPv6’da hem SLAAC hem DHCPv6 bulunmasının büyük bir hata olduğunu giderek daha çok düşünüyorum. SLAAC kendi başına harika ama iki yapılandırma mekanizması olması fazla kafa karıştırıcı. Android’in DHCPv6 desteklememesi de bu karmaşayı artırıyor. Tahminimce SLAAC, bilgisayarların pahalı ve DHCP sunucularının ayrı cihazlar olduğu dönemin ürünü. Ama artık bilgisayarlar ucuz ve çoğu yönlendirici DHCP çalıştırabiliyor; yani koşullar değişti. DHCPv6 varsayılan olarak MAC tabanlı adres dağıtacak şekilde ilerleseydi yapılandırma daha basit olabilirdi, bağlantı yerelinde ise otomatik yapılandırma yine korunurdu
Bu yazıyı çok ilginç buldum ama bir noktayı iyi anlayamadım. Yazar artık WiFi’da da CSMA/CD kullanılmadığını söylüyor; peki o zaman gerçekte nasıl çalışıyor? Yazar, aynı erişim noktasına bağlı iki WiFi istasyonunun da birbirleriyle doğrudan iletişim kurmadığını açıklıyor. Öyleyse her istasyon, duyduğu sinyalin kendisine mi ait olduğunu, başka bir istasyonun AP’ye gönderdiği bir sinyal mi olduğunu, yoksa AP’nin başka bir istasyona gönderdiği bir sinyal mi olduğunu bir noktada ayırt etmek zorunda. O halde sadece adı değişmiş benzer bir mekanizma hâlâ gerekmiyor mu diye merak ediyorum
Eskiden IPv6 kaçınılmaz bir sonraki adım gibi görünüyordu ama bugün bu kadar ivme kaybetmiş olması, belki de başta çözmeye çalıştığı problemin o kadar önemli olmadığını düşündürüyor. Son kullanıcı açısından bakınca, nasıl olduysa yeterince IPv4 adresi bulunmuş ve internet dönmeye devam etmiş gibi görünüyor; bu yüzden IPv6’ya gerçekten ihtiyaç var mıydı diye ben de sorguluyorum. Bu sonucun yanlış olup olmadığını merak ediyorum