1 poin oleh GN⁺ 2 jam lalu | 1 komentar | Bagikan ke WhatsApp
  • Pada jaringan awal yang berpusat pada koneksi point-to-point, sistem alamat nyaris tidak diperlukan, tetapi seiring meluasnya jaringan bus untuk menekan biaya, kompleksitas seperti alamat MAC, bridging, dan ARP pun menumpuk
  • Ketika Ethernet dan IP digabungkan, pengalamatan MAC dan broadcast ARP menjadi perlu untuk meneruskan ke hop berikutnya, dan beban ini membesar drastis pada jaringan antarterhubung skala besar dan wifi
  • Dalam gagasan IPv6 tercermin harapan akan dunia yang lebih sederhana dengan meninggalkan bus fisik dan layer 2 internetwork, serta menghapus broadcast, ARP, DHCP, dan alamat MAC
  • Namun dalam lingkungan deployment nyata, IPv4 dan framing lama tetap bertahan, sehingga warisan seperti neighbor discovery, DHCP, NAT, dan bridging layer 2 ikut dipertahankan
  • Untuk mempertahankan koneksi saat berpindah, bridging layer 2 dan tunneling terpusat masih terus dipakai alih-alih Internet routing, dan alternatif seperti QUIC dibicarakan sebagai jalur memutar untuk roaming

Momen ketika jaringan bus merusak segalanya

  • Pada lingkungan awal circuit switching di jaringan telepon dan leased line, hanya ada koneksi point-to-point sehingga sistem alamat tidak diperlukan; bit yang dimasukkan di satu sisi akan keluar di sisi lain setelah jeda waktu tertentu
  • Bahkan setelah TDM dan virtual circuit switching diperkenalkan, dari sudut pandang pengguna tetap terasa seperti input di satu sisi tersambung ke output di sisi lain, dan pada tahap ini pun belum ada kebutuhan alamat
  • Saat komputer dengan banyak antarmuka mulai meneruskan bit di antara jalur, muncul alamat IP, subnet, dan routing, tetapi pada link point-to-point alamat MAC tetap tidak diperlukan
  • Untuk menekan biaya koneksi situs lokal, muncullah jaringan bus yang menghubungkan banyak perangkat ke satu kabel, dan terpisah dari keluarga Internet, masing-masing membangun sistem layer 2 sendiri
  • LAN awal arcnet mengharuskan alamat layer 2 8-bit disetel manual lewat jumper atau DIP switch, dan duplikasi bisa menimbulkan gangguan serius, tetapi karena jaringannya kecil, kerepotan itu masih terbatas
  • Ethernet memperkenalkan alamat MAC 48-bit untuk mengatasi masalah duplikasi dengan memberi alamat yang hampir unik sejak tahap manufaktur
  • Teknologi LAN seperti IPX dan Netware dapat bekerja baik tanpa pengaturan alamat di dalam satu jaringan bus tunggal, dan digambarkan sebagai masa ketika semuanya bekerja indah dan andal
  • Jaringan perusahaan besar dan kampus harus menghubungkan banyak bus karena bottleneck satu bus 10 Mbps, tetapi alih-alih memilih IP yang saat itu belum matang, mereka memilih bridging dan switching berbasis alamat Ethernet sebagai jalur ekspansi
  • Karena alamat Ethernet dialokasikan berurutan dari pabrik, alamat ini tidak memiliki hierarki, sehingga tabel bridging tidak bisa dikelompokkan seefisien tabel routing IP modern yang menangani rute per subnet
    • Agar bridging efisien, perlu diingat alamat MAC mana berada di bus yang mana
    • Agar ini tidak perlu disetel manual, dibutuhkan pembelajaran otomatis dan interaksi yang rumit
  • Jaringan bridge yang kompleks kemudian dibangun dengan cara seperti spanning tree, yang diikuti broadcast flood, rute tidak optimal, dan kemampuan debugging yang rendah
  • Pada bridge perantara, tidak ada konsep alamat dalam Ethernet biasa sehingga alat seperti traceroute tidak bisa dibuat; akibatnya bridging pada praktiknya hampir mustahil di-debug
  • Meski begitu, bridging berjalan sangat cepat mendekati line rate Ethernet berkat optimasi hardware, dan pada masa itu hal tersebut merupakan keunggulan besar

Internet yang berjalan di atas bus

  • Dari struktur yang menghubungkan komputer individual melalui link point-to-point jarak jauh, lambat laun muncul kebutuhan untuk menghubungkan seluruh LAN, sehingga koneksi jarak jauh antarlan menjadi perlu
  • Bridging jarak jauh yang sederhana tidak layak karena masalah kontrol kemacetan; Ethernet bridging hanya bekerja jika semua link memiliki kecepatan mirip atau kemacetan nyaris tidak ada
  • Menghubungkan langsung Ethernet 10 Mbps dengan link point-to-point 0.128 Mbps melalui bridging adalah usaha tanpa harapan, dan pencarian rute berbasis flooding juga terlalu boros pada link lambat
  • Routing yang tidak optimal yang masih bisa ditoleransi di lingkungan lokal menjadi fatal pada link jarak jauh yang lambat dan mahal, sehingga tidak skalabel
  • Kumpulan masalah ini sudah lama ditangani oleh Internet, dan menghubungkan bus LAN dengan teknologi Internet sebenarnya bisa memberi struktur yang jauh lebih baik
  • Maka dirancanglah format frame untuk membawa paket Internet di atas LAN seperti Ethernet dan arcnet; dari titik inilah masalah mulai timbul
  • Jika ada beberapa IP router dalam satu segmen Ethernet, perlu cara membedakan router mana yang harus menerima dan meneruskan paket, dan alamat IP tujuan akhir saja tidak cukup untuk menyatakan pilihan itu
  • Karena itu, tujuan akhir dibiarkan di header IP, sementara router next hop yang sesungguhnya ditentukan melalui alamat MAC pada frame Ethernet
  • Informasi yang sebenarnya ingin diungkap manusia adalah kirim ke IP tujuan 10.1.1.1 melalui router MAC 11:22:33:44:55:66, tetapi sistem operasi justru menanganinya dalam bentuk seperti via router IP 192.168.1.1
  • Untuk abstraksi ini, sistem operasi lebih dulu harus mencari alamat Ethernet milik IP router, dan sebagai langkah perantara ditambahkanlah ARP
  • ARP bekerja dengan menyiarkan broadcast ke seluruh Ethernet lokal untuk mencari pemilik IP tertentu, dan jika ada bridge maka karena ini broadcast Ethernet, paket itu harus diteruskan ke semua antarmuka
  • Pada Ethernet besar yang saling terhubung, broadcast berlebihan menjadi salah satu mimpi buruk terbesar, terutama pada wifi
  • Setelah itu bridge dan switch mulai menambahkan berbagai hack khusus untuk mengurangi jangkauan ARP, dan beberapa perangkat terutama access point wifi bahkan membuat respons ARP palsu, tetapi semuanya pada dasarnya mendekati hack teknis

Mati karena warisan

  • Seiring waktu, protokol non-IP di atas Ethernet hampir lenyap, dan jaringan mengeras menjadi struktur dengan bus layer 2 di atas kabel fisik, bridge yang menghubungkan bus-bus itu, lalu router layer 3 di atasnya
  • Ketika kelelahan terhadap konfigurasi IP manual meningkat, muncul kebutuhan konfigurasi otomatis, tetapi perangkat sudah telanjur dikirim dengan alamat Ethernet, dan alamat IPv4 32-bit tidak cukup untuk diberi identitas unik permanen sejak tahap manufaktur
  • Jika alamat IP dialokasikan berurutan secara sederhana, kita justru kembali ke struktur nonhierarkis seperti Ethernet, jadi itu bukan solusi yang tepat
  • Karena itu lahirlah bootp dan DHCP, yang seperti ARP juga menjadi protokol yang memerlukan perlakuan khusus
  • Karena DHCP harus lebih dulu dikirim oleh node yang belum punya alamat IP, protokol ini harus mengisi header IP yang pada praktiknya nyaris tidak bermakna tetapi diwajibkan RFC, dan server DHCP harus mengisinya sendiri lewat raw socket alih-alih lapisan IP kernel
  • Pada akhirnya bootp dan DHCP perlu mengetahui alamat Ethernet untuk menetapkan alamat IP, sehingga perannya hampir seperti ARP versi terbalik
  • Disebutkan pula bahwa RARP melakukan hal yang sama dengan cara lebih sederhana, tetapi nyaris tidak dibahas di sini
  • Akibatnya Ethernet dan IP menjadi semakin terikat erat hingga kini hampir tak terpisahkan
  • Tabel routing IP tampak seolah menunjuk router dengan alamat IP, padahal sebenarnya menunjuk alamat MAC secara tidak langsung; ARP melintasi bridge, dan DHCP tampak seperti paket IP tetapi strukturnya pada dasarnya lebih dekat ke protokol Ethernet
  • Pada saat yang sama bridging dan routing sama-sama makin rumit; bridging umumnya berada di ranah IEEE dan hardware, routing umumnya di ranah IETF dan software, dan keduanya cenderung berpura-pura yang lain tidak ada
  • Operator jaringan memilih antara bridging dan routing berdasarkan tuntutan kecepatan dan sejauh mana mereka ingin menghindari konfigurasi server DHCP; sebisa mungkin mereka memakai bridging sebanyak mungkin dan routing hanya saat diperlukan
  • Kompleksitas bridging pada akhirnya mendorong pengambilan keputusan layer 2 ke lapisan lebih tinggi, lalu dikelola secara terpusat dengan protokol di atas IP melalui SDN
  • SDN memang lebih baik daripada switch dan bridge yang masing-masing bertindak sesuka hati, tetapi tetap terasa ironis karena IP sendiri pada dasarnya sudah merupakan software-defined network untuk menangani jaringan yang terlalu besar lewat software
  • Pada awalnya IPv4 sulit dipercepat dengan hardware dan dalam praktiknya memang tidak cukup dipercepat, sementara konfigurasi DHCP sangat merepotkan, sehingga operator makin terbiasa melakukan bridging untuk cakupan yang semakin besar
  • Saat ini data center besar digambarkan pada dasarnya beroperasi sebagai jaringan bus virtual raksasa berbasis SDN, dan dalam banyak kasus tidak benar-benar merutekan paket

Sekarang lupakan dulu cerita sebelumnya

  • Ketika IETF merancang IPv6 pada awal 1990-an, banyak kekacauan sebenarnya sudah berlangsung, tetapi desain tetap berjalan dengan asumsi bahwa bencana yang akan datang masih bisa dihindari
  • Dalam proses itu, satu perubahan penting adalah bahwa penggunaan jaringan bus fisik pada dasarnya sudah berhenti
  • Ethernet bukan lagi bus sungguhan, melainkan hanya berpura-pura sebagai bus; ketika kecepatan meningkat dan CSMA/CD tak bisa dipertahankan, topologi pun kembali ke bentuk bintang
  • Struktur dengan menarik kabel individual dari tiap stasiun ke switch pusat menjadi umum, dan dinding, plafon, serta lantai pun dipenuhi bundel kabel Ethernet yang besar dan mahal
  • Bahkan wifi, yang tampak seperti medium radio bersama alias bus pamungkas, dalam praktiknya hampir selalu meniru topologi bintang besar melalui infrastructure mode
  • Dua stasiun wifi yang terhubung ke access point yang sama pun tidak berkomunikasi langsung; keduanya mengirim paket ke access point dengan mencantumkan alamat MAC lawan, lalu access point memancarkannya kembali
  • Jika node X mengirim ke node Internet Z melalui IP router Y lewat wifi access point A, maka Z menjadi tujuan IP, Y menjadi tujuan Ethernet, dan A menjadi pasangan transmisi radio yang sesungguhnya, sehingga lapisan alamat bertumpuk dengan rumit
  • Untuk itu 802.11 menyediakan 3-address mode yang memuat tujuan Ethernet sebenarnya sekaligus tujuan Ethernet perantara
  • Ada pula bit to-AP dan from-AP untuk menandai arah stasiun→AP dan AP→stasiun, dan jika keduanya bernilai benar sekaligus, operasi repeater antarap juga bisa dinyatakan
  • Jika A adalah repeater yang harus mengirim lagi ke base station B, maka pelaku pengirim/penerima pada transmisi udara dan source/tujuan Ethernet semuanya berbeda, sehingga diperlukan 4-address mode
  • 802.11s mesh bahkan memiliki 6-address mode, dan penulis menyebut bahwa pada titik itu ia menyerah untuk memahaminya

Dunia tempat IPv6 merupakan desain yang bagus

  • IETF yang memikirkan IPv6 melihat kekacauan yang sudah terjadi dan yang akan datang, lalu membayangkan dunia baru yang membuang legacy lama
  • Premis dunia itu adalah menghapus jaringan bus fisik, layer 2 internetwork, broadcast, alamat MAC, ARP dan DHCP, sambil menyediakan header IP sederhana yang bisa dipercepat dengan hardware, mengatasi kekurangan alamat, dan meniadakan konfigurasi IP manual di luar core
  • Jika layer 2 selalu point-to-point, maka tidak ada target untuk broadcast sehingga ia bisa diganti dengan multicast; dan karena pasangan kirim/terima sudah jelas, alamat MAC juga menjadi tidak perlu
  • Jika alamat MAC hilang, maka pemetaan antara IP dan MAC juga tidak lagi dibutuhkan, sehingga ARP dan DHCP bisa ikut lenyap, dan ruang alamat yang cukup besar juga dapat memungkinkan penggunaan kembali routing subnet besar
  • Dalam dunia itu, wifi repeater, wifi access point, Ethernet switch, hingga SDN semuanya dibayangkan akan berfungsi sebagai router IPv6
  • Dengan begitu, ARP storm, IGMP snooping bridge, dan bridging loop akan hilang, dan semua masalah routing akan bisa dilacak dengan traceroute
  • Karena setiap paket Ethernet bisa menghapus 12 byte alamat MAC sumber dan tujuan, dan setiap paket wifi bisa menghapus 18 byte informasi alamat, penulis menghitung bahwa meski IPv6 memakai alamat 24 byte lebih besar daripada IPv4, jika header Ethernet juga dihapus maka tambahan overhead efektifnya hanya 12 byte
  • Harapan bahwa suatu hari alamat Ethernet itu sendiri bisa dihapus digambarkan ikut membantu membenarkan pilihan panjang alamat IPv6 yang tampak berlebihan
  • Namun desain yang indah ini tidak pernah terwujud di dunia nyata

Requiem untuk sebuah mimpi

  • Ungkapan rekan kerja, "layer hanya bertambah, tidak pernah dihapus," diajukan sebagai kesimpulan utama
  • Keunggulan IPv6 hanya berlaku jika legacy lama bisa dibuang dan semuanya dimulai ulang, tetapi dalam kenyataannya hal itu hampir mustahil
  • Walaupun adopsi IPv6 mencapai 99%, selama IPv4 belum benar-benar hilang, alamat Ethernet dan alamat wifi juga tidak akan hilang, dan selama standar framing IEEE 802.3 dan 802.11 tetap dipakai, penghematan byte itu pun tak akan terwujud
  • Karena itu IPv6 akhirnya membutuhkan neighbor discovery yang bahkan lebih kompleks daripada ARP, dan walaupun jaringan bus telah hilang, simulasi mirip broadcast tetap harus dipertahankan agar mekanisme ala ARP bisa berjalan
  • Di rumah, server DHCP lokal tetap harus dijalankan demi menyalakan lampu IPv4 lama, dan NAT juga tetap diperlukan agar lampu itu bisa mencapai internet
  • Yang lebih buruk, tim IPv6 dinilai membiarkan masalah mobile IP tetap tak terpecahkan, sehingga bridging layer 2 yang buruk itu tetap dibutuhkan
  • Menurut penulis, rencananya saat itu adalah menerapkan IPv6 lebih dulu dalam beberapa tahun, lalu setelah IPv4 dan alamat MAC lenyap, mobile IP akan lebih mudah diselesaikan
  • Pada masa itu, kasus penggunaan komputer yang berpindah tempat hampir tidak terpikirkan; bayangan yang ada hanya skenario canggung seperti berpindah di antara port Ethernet sambil tetap menjalankan ftp

Mobile IP sebagai killer app

  • Setelah itu sejarah berubah: komputer yang dibawa-bawa, yakni telepon, menjadi hal biasa dan bergerak di antara banyak access point nirkabel
  • Di LTE, perpindahan ini sebagian besar berhasil; di wifi kadang berhasil, tetapi rahasianya bukan Internet routing melainkan bridging layer 2
  • Internet routing sama sekali tidak menangani mobilitas; jika berpindah di jaringan IP dan alamat IP berubah, semua koneksi yang sedang terbuka akan langsung putus
  • Wifi perusahaan mempertahankan seluruh LAN sebagai bridge layer 2 agar server DHCP pusat memberikan alamat IP yang sama dari access point mana pun, dan koneksi tetap bertahan asalkan bisa menerima beberapa detik kekacauan saat bridge direkonfigurasi
  • Wifi rumahan dengan beberapa extender atau repeater memakai cara yang sama
  • Sebaliknya, jika seseorang berjalan melewati jaringan wifi yang berbeda-beda seperti wifi publik di tiap toko, ia akan mendapat alamat IP baru setiap kali dan semua koneksi akan terputus
  • LTE melangkah lebih jauh dengan mempertahankan alamat IP yang sama meski berpindah bermil-mil di antara banyak base station, dan disebutkan bahwa jaringan seluler umumnya menggunakan alamat IPv6
  • Caranya adalah dengan menunnel trafik ke titik pusat, lalu menjembataninya menjadi satu virtual LAN layer 2 yang sangat besar bersama banyak firewall; harga yang dibayar adalah kompleksitas luar biasa dan latensi tambahan yang memalukan
  • Operator ingin memperbaikinya, tetapi disebutkan bahwa hal itu hampir mustahil

Cara benar-benar membuat mobile IP bekerja 1

  • Jawaban atas mengapa mobile IP tidak berjalan baik diarahkan pada kesimpulan bahwa definisi terkenal 4-tuple untuk identifikasi sesi itu keliru
  • Sesi TCP dan UDP diidentifikasi sebagai (source ip, source port, destination ip, destination port), struktur yang melintasi layer 3 dan layer 4 serta rapuh terhadap perubahan alamat IP
  • Dikemukakan bahwa jika identifikasi sesi hanya didasarkan pada data layer 4, mobile IP akan bekerja dengan sempurna
  • Sebagai contoh, ketika X:1111 berkomunikasi dengan Y:80 lalu X pindah ke Q, paket menjadi (Q,1111,Y,80), sehingga Y tidak mengenalinya sebagai sesi lama dan membuangnya; paket balasan (Y,80,X,1111) dari Y juga tak lagi bisa mencapai X
  • Sebagai alternatif, nomor port dibayangkan diperbesar dari 16-bit saat ini menjadi nilai hash unik sekitar 128 atau 256-bit, dan socket diidentifikasi dengan tag yang tidak bergantung pada alamat IP
  • Dalam model ini, paket tetap memuat informasi alamat (X,Y) pada layer 3 untuk routing, tetapi saat menerima, kernel tidak memakai informasi layer 3 untuk identifikasi socket dan hanya memakai uuid
  • Port tujuan 80 hanya diperlukan untuk membedakan layanan yang diinginkan saat memulai sesi baru, dan setelah itu bisa diabaikan atau dihilangkan
  • Kernel Y menyimpan cache bahwa paket sesi (uuid) baru-baru ini datang dari X; jika setelah X pindah ke Q paket dengan tag (uuid,80) yang sama datang lagi, kernel dapat mencocokkannya ke sesi tersebut sambil memperbarui tujuan balasan dari X menjadi Q
  • Dengan cara ini koneksi tetap hidup, tetapi ada catatan bahwa perhatian tambahan dibutuhkan untuk mencegah pembajakan koneksi oleh peniru
  • Namun UDP dan TCP tidak bekerja seperti ini, dan mengubahnya sekarang dinilai seperti proyek mengganti IPv4 dengan IPv6: tampak mudah, tetapi puluhan tahun kemudian pun belum selesai sampai setengahnya

QUIC dan kemungkinan jalan memutar

  • Di sisi positif, diajukan kemungkinan solusi tak langsung melalui satu pelanggaran lapisan lagi
  • Dengan meninggalkan TCP lama dan memakai QUIC di atas UDP, dimungkinkan pendekatan yang tidak menggunakan 4-tuple UDP itu sendiri sebagai pengenal koneksi
  • Jika port UDP adalah port mobility layer khusus, maka isi di dalamnya bisa dibuka lagi, ditafsirkan sebagai paket internal dengan tag uuid yang sesuai, lalu dicocokkan ke sesi dan socket yang benar
  • Disebutkan bahwa protokol QUIC eksperimental setidaknya secara teori sudah memiliki format paket yang cocok untuk struktur seperti ini
  • Karena enkripsi dan autentikasi paket stateless yang dipakai QUIC pada dasarnya juga memerlukan pengenal sesi atau kunci yang unik, ada harapan bahwa dukungan roaming transparan bisa diwujudkan dengan usaha yang relatif kecil
  • Jika itu terjadi, maka yang tersisa hanyalah menghapus seluruh UDP dan TCP dari Internet, dan kali ini bridging layer 2 benar-benar tidak lagi diperlukan; broadcast, alamat MAC, SDN, dan DHCP pun bisa dihapus
  • Tulisan ditutup dengan kalimat tentang pemulihan keanggunan Internet

Perbaikan tambahan

  • Revisi 2017-08-16

    • Gagasan sebelumnya terkait mobile IP tidak terbatas pada IPv6
    • Disebutkan bahwa hal itu juga bisa bekerja pada IPv4 dan lingkungan NAT, bahkan untuk roaming yang melintasi beberapa NAT
  • Revisi 2017-08-15

    • Sebagai cara mencegah pembajakan koneksi, pertukaran mirip SYN-ACK-SYNACK pada awal TCP diajukan sebagai contoh paling sederhana
    • Jika Y langsung mempercayai paket pertama dari host baru Q, penyerang dari mana pun di internet akan mudah membajak koneksi X→Y
    • Jika Y mengirim cookie lalu Q menerimanya, memprosesnya, dan mengirimkannya kembali ke Y, maka setidaknya penyerang harus berada pada level man-in-the-middle, bukan sekadar penyerang eksternal sederhana
    • Jika memakai protokol terenkripsi seperti QUIC, handshake tersebut juga bisa dilindungi dengan kunci sesi
  • Revisi 2017-10-24

    • Selain QUIC, ada kandidat protokol pengganti TCP lain yang mendukung roaming semacam ini, dan MinimaLT disebut sebagai contoh
    • Dituliskan bahwa MinimaLT adalah protokol pertama yang pernah didengar penulis yang menyelesaikan masalah roaming dengan elegan, dan solusi yang diadopsi ke depan mungkin akan meniru struktur ini
  • Revisi 2020-07-09

    • Hanya disebutkan bahwa penulis memposting pemikiran tambahan tentang migrasi dan interoperabilitas IPv4/IPv6 di tulisan lain, tanpa penjelasan tambahan di tubuh artikel

1 komentar

 
GN⁺ 2 jam lalu
Komentar Hacker News
  • Dari sudut pandang saya, meskipun IPv6 bukan puncak desain protokol yang sempurna, alternatif yang katanya lebih baik pada akhirnya selalu mengerucut ke bentuk yang mirip IPv6. Kalau terus-menerus tak ada yang bisa membuat sesuatu yang lebih baik dari ini, menurut saya itu berarti IPv6 pada akhirnya adalah desain yang cukup bagus

    • Menurut saya itu pernyataan yang bahkan lebih kuat. Hampir semua alternatif yang lebih baik yang diajukan orang sebenarnya sudah pernah dipertimbangkan dalam proses desain IPv6, lalu ditolak dengan alasan yang umumnya cukup masuk akal
    • Kalau dipikir-pikir lagi, rasanya menambahkan 16 bit atau 32 bit saja ke IPv4 mungkin sudah cukup, tapi saya tetap setuju bahwa IPv6 itu lumayan baik dan bekerja dengan baik. Sebagian besar keluhan yang saya dengar datang dari ketidaktahuan, tetapi ada satu pengecualian, yaitu alamat yang panjang. Ini memang benar-benar merepotkan, dan encoding yang dibaca manusia juga kurang bagus, jadi kalau setidaknya cara representasinya dibuat lebih mudah dibaca, itu akan sangat membantu
    • Saya tidak setuju dengan tafsiran itu. Dunia terus berubah, dan menurut saya IPv6 dirancang pada 1998 terutama berdasarkan kebutuhan perusahaan perangkat jaringan. Perspektif pengguna akhir, administrator jaringan, dan pengembang aplikasi menurut saya tidak cukup tercermin. Alasan ia masih bertahan sampai sekarang pun menurut saya sebagian besar karena biaya hangus dan utang teknis lama. Jika dirancang baru hari ini, dengan kondisi seperti SD-WAN, kebutuhan mobile, dan perubahan harga chip, kemungkinan besar akan muncul protokol yang berbeda. Saya juga merasa konsep alamat sumber dan tujuan itu sendiri perlu dipikirkan ulang. Pada 2026, lapisan jaringan yang secara bawaan tidak memiliki enkripsi 0RTT terasa ketinggalan zaman. Elemen-elemen seperti ND, ARP, RA, dan DHCP yang pada dasarnya berasumsi adanya kepercayaan juga terasa tidak aman karena tidak ada autentikasi. Jika perangkat tetangga mengklaim memiliki alamat tertentu, kenapa perangkat saya harus langsung percaya? Baik pada jaringan kabel maupun nirkabel, saya juga frustrasi karena saat terhubung ke jaringan, kita tidak memverifikasi keamanan dan sistem identitas jaringan lawan. Masalah keamanan, kepercayaan, dan identitas seharusnya menjadi pusat perhatian, tetapi ternyata tidak, dan fitur-fitur baru pun pada akhirnya terasa disesuaikan dengan struktur pendapatan vendor. Selain keamanan, saya juga menganggap arah menuju identity-based addressing lebih penting daripada alamat berbasis angka. Karena ketergantungan pada teknologi ini begitu besar, saya juga merasa campur tangan pemerintah diperlukan, dan rasanya pahit jika masalah alamat dan keamanan gaya 2005 ini diwariskan ke generasi mendatang dan koloni di Mars
    • Saya juga tidak setuju dengan tafsiran bahwa mereka memang tidak bisa berbuat lebih baik. Rasanya lebih seperti dirilis lalu selesai. Daripada melakukan perubahan sebesar IPv6, menurut saya mereka seharusnya membuat ipv4+ yang lebih dekat ke perpanjangan IPv4, dengan penyempurnaan yang dilakukan beberapa kali
  • Jika mengumpulkan diskusi Hacker News lama, topik ini ternyata terus berulang setiap beberapa tahun, seperti thread 2017, thread 2019, thread 2020, dan thread 2023

  • Saya kurang suka bahwa tulisan ini memandang ARP terlalu negatif. Berkat ARP, jaringan IP di dalam LAN bisa berjalan tanpa router, dan default gateway pun bisa diperlakukan sebagai kasus khusus dari komunikasi IP LAN biasa yang sama. Meski begitu, penjelasan sejarah jaringannya sendiri benar-benar luar biasa, dan saya masih sedang membaca bagian IPv6-nya

    • Tentu saja saya tidak menganggap ARP satu-satunya cara untuk menyelesaikan alamat layer 2. Menurut saya ARP menimbulkan pelanggaran lapisan dan lalu lintas broadcast berlebihan, yang menambah masalah di lingkungan seperti WiFi. Misalnya, NDP pada IPv6 berjalan di atas paket IPv6 yang sebenarnya berbasis ICMPv6, jadi pelanggaran seperti itu tidak ada, dan berkat multicast, kebutuhan untuk menyebarkan broadcast ke seluruh layer 2 juga berkurang
  • Saya agak bingung tulisan ini sebenarnya ingin mengatakan apa. Apakah maksudnya perangkat jaringan saya menetapkan sendiri alamat IPv6 berdasarkan alamat MAC, dan itu adalah inti dari stateless IPv6? Setahu saya, IPv6 juga muncul untuk mengatasi kehabisan IPv4 dan masalah NAT. Tapi Xbox saya mengatakan jaringan saya kurang bagus karena tidak ada IPv6, dan ini juga terasa seperti sudut pandang yang cukup berpusat pada Amerika Utara

    • Tepatnya, saat ini sebagian besar perangkat non-server cenderung menggunakan semantically opaque interface identifiers seperti yang dijelaskan di RFC8064 dan RFC7217, bukan alamat berbasis MAC atau EUI64. Alamat yang stabil biasanya dipakai untuk trafik masuk, sedangkan untuk trafik keluar bisa digunakan privacy address sementara yang berubah seiring waktu. Dan stateless di sini berarti perangkat dapat mengonfigurasi alamatnya sendiri lewat SLAAC tanpa konfigurasi terpusat seperti DHCPv6
    • Menurut saya, keluhan Xbox itu kemungkinan lebih terkait ketiadaan UPnP daripada IPv6 itu sendiri. Memang, jika ada IPv6 sebagian masalah seperti itu bisa berkurang. Namun ironisnya, dukungan IPv6 di konsol justru dulu termasuk lambat, jadi saya juga penasaran seberapa baik sebenarnya dukungan Xbox terhadapnya
    • Sebaliknya, saya justru penasaran apakah Xbox bisa berfungsi dengan baik tanpa IPv4. Perangkat Windows di perusahaan saya tidak bisa, dan saya tahu konsol game lain juga masih punya ketergantungan pada IPv4
  • Saya makin merasa bahwa mempertahankan SLAAC dan DHCPv6 sekaligus di IPv6 adalah kesalahan besar. SLAAC sendiri bagus, tetapi memiliki dua mekanisme konfigurasi sangat membingungkan. Fakta bahwa Android tidak mendukung DHCPv6 juga makin menambah kebingungan. Dugaan saya, SLAAC adalah produk dari zaman ketika komputer mahal dan server DHCP berupa perangkat terpisah. Tapi sekarang komputer murah dan sebagian besar router bisa menjalankan DHCP, jadi kondisinya berbeda. Kalau DHCPv6 dari awal bergerak ke arah pembagian alamat berbasis MAC, rasanya konfigurasi akan lebih sederhana, dan autokonfigurasi pada link-local juga tetap bisa dipertahankan

    • Sebagai catatan, sejak Android 11 memang ada dukungan DHCPv6 dalam bentuk Prefix Delegation. Namun jika melihat tulisan terkait, saya tetap merasa ada pendekatan khas platform berupa kami lebih tahu di sana
  • Tulisan ini menurut saya sangat menarik, tetapi ada satu bagian yang kurang saya pahami. Penulis mengatakan bahwa bahkan di WiFi sekarang CSMA/CD tidak lagi digunakan, jadi saya penasaran sebenarnya bagaimana cara kerjanya. Penulis menjelaskan bahwa dua stasiun WiFi yang terhubung ke access point yang sama pun tidak saling berkomunikasi langsung. Kalau begitu, pada titik tertentu masing-masing stasiun tetap harus bisa membedakan apakah sinyal yang didengarnya adalah miliknya sendiri, milik stasiun lain yang mengirim ke AP, atau milik AP yang mengirim ke stasiun lain. Kalau begitu, bukankah mekanisme yang mirip tetap diperlukan, hanya namanya saja yang berbeda?

  • Dulu IPv6 terlihat seperti langkah berikutnya yang tak terelakkan, tetapi melihat betapa lesunya sekarang, saya jadi bertanya-tanya apakah masalah yang semula ingin diselesaikannya memang tidak sepenting itu. Dari sudut pandang pengguna nyata, bagaimanapun juga orang tampaknya masih bisa mengamankan cukup banyak alamat IPv4 sehingga internet tetap berjalan, jadi saya sendiri mulai mempertanyakan apakah IPv6 benar-benar dibutuhkan. Saya penasaran apakah kesimpulan ini keliru

    • Saya merasa bahkan kata kita di sini pun tidak jelas merujuk ke siapa. Dulu orang bisa mendapatkan /24 hanya dengan mengajukan permohonan, tetapi sekarang sering kali kita harus membeli blok bekas yang pernah dipakai jaringan spam yang sudah tutup, sehingga reputasi IP-nya berantakan. Bahkan kalau ingin meng-host sesuatu sendiri, kalau bukan dalam skala jaringan besar maka sering kali pada praktiknya kita harus menyewa satu IPv4 dari perusahaan Amerika. Bagi saya ini mirip seperti uranium yang secara teori ada di pasar, tetapi dalam praktiknya sangat sulit didapat
    • Menurut saya masalah itu tetap penting. Fakta bahwa ada solusi sementara seperti NAT justru menjadi buktinya. Orang-orang makin terbiasa dengan kondisi yang makin buruk, dan menganggap wajar kualitas panggilan dengan latensi tinggi atau situasi ketika seluruh komunikasi terhenti saat infrastruktur seperti Cloudflare down. Padahal internet pada awalnya dirancang untuk menghindari ketergantungan terpusat seperti itu. Bagi saya, mengatakan tidak ada masalah di sini terdengar seperti mengatakan kemacetan lalu lintas bukan masalah hanya karena hari ini saya berhasil sampai ke kantor. Menurut saya ini perlu dilihat lebih panjang dan dalam gambaran yang lebih besar