11 poin oleh GN⁺ 2026-04-21 | 1 komentar | Bagikan ke WhatsApp
  • Pada jaringan awal yang berpusat pada koneksi point-to-point, sistem alamat hampir tidak diperlukan, tetapi meluasnya jaringan bus untuk menghemat biaya menumpuk kompleksitas seperti alamat MAC, bridging, dan ARP
  • Saat Ethernet dan IP digabungkan, pengalamatan MAC dan broadcast ARP menjadi perlu untuk meneruskan ke next hop, dan beban ini membesar drastis pada jaringan interkoneksi besar dan wifi
  • Dalam perancangan IPv6 tercermin harapan akan dunia yang lebih sederhana dengan meninggalkan bus fisik dan layer 2 internetwork, serta menghapus broadcast, ARP, DHCP, hingga alamat MAC
  • Namun dalam lingkungan deployment nyata, IPv4 dan framing lama tetap bertahan, sehingga warisan seperti neighbor discovery, DHCP, NAT, dan layer 2 bridging ikut dipertahankan
  • Untuk mempertahankan koneksi saat berpindah, alih-alih routing Internet masih terus digunakan layer 2 bridging dan tunneling terpusat, sementara alternatif seperti QUIC disebut sebagai jalur memutar untuk roaming

Jaringan bus sebagai pemicu yang merusak segalanya

  • Pada lingkungan awal jaringan telepon dengan circuit switching dan leased line, hanya ada koneksi point-to-point, sehingga tidak diperlukan sistem alamat; 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 bentuknya tetap input di satu sisi tersambung ke output di sisi lain, sehingga pada tahap ini pun alamat belum diperlukan
  • Ketika komputer dengan banyak antarmuka mulai meneruskan bit antarjalur, muncullah 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 menempelkan banyak perangkat pada satu kabel, dan terpisah dari keluarga Internet, masing-masing membentuk sistem layer 2 sendiri
  • LAN awal arcnet mengharuskan alamat layer 2 8-bit disetel manual dengan jumper atau DIP switch, dan duplikasi menyebabkan gangguan serius, tetapi karena jaringannya kecil, kerepotan ini masih terbatas
  • Ethernet memperkenalkan alamat MAC 48-bit dan menyelesaikan masalah duplikasi dengan memberikan alamat yang hampir unik sejak tahap manufaktur
  • Teknologi LAN seperti IPX dan Netware bekerja baik di dalam satu jaringan bus tunggal tanpa konfigurasi alamat, dan digambarkan sebagai masa ketika semuanya indah dan andal
  • Jaringan perusahaan besar dan kampus harus menghubungkan beberapa bus karena bottleneck satu bus 10 Mbps, tetapi alih-alih IP yang saat itu belum matang, mereka memilih bridging dan switching berbasis alamat Ethernet sebagai jalur ekspansi
  • Karena alamat Ethernet dialokasikan berurutan dari pabrik dan tidak memiliki hierarki, tabel bridging tidak bisa digabungkan secara efisien seperti tabel routing IP modern yang menangani rute per subnet
    • Untuk bridging yang efisien, perlu diingat pada bus mana setiap alamat MAC berada
    • Agar ini tidak perlu dikonfigurasi manual, dibutuhkan pembelajaran otomatis dan interaksi yang rumit
  • Jaringan bridge yang kompleks kemudian terhubung dengan cara seperti spanning tree, yang membawa serta banjir broadcast, jalur yang tidak optimal, dan kemampuan debugging yang rendah
  • Bridge perantara tidak memiliki konsep alamat pada Ethernet biasa, sehingga alat seperti traceroute tidak dapat dibuat; pada praktiknya bridging nyaris mustahil di-debug
  • Meski begitu, bridging bekerja sangat cepat, mendekati line rate Ethernet berkat optimisasi perangkat keras, dan itu saat itu merupakan keunggulan besar

Internet yang berjalan di atas bus

  • Dari struktur yang menghubungkan komputer individual dengan link point-to-point jarak jauh, kebutuhan perlahan bergeser ke konektivitas seluruh LAN, sehingga koneksi jarak jauh antarlAN menjadi perlu
  • Bridge jarak jauh yang sederhana tidak layak karena masalah kontrol kemacetan, dan bridging Ethernet hanya bekerja dengan asumsi semua link berkecepatan mirip atau hampir tidak ada kemacetan
  • Menghubungkan langsung Ethernet 10 Mbps dengan link point-to-point 0.128 Mbps lewat bridging tidak punya 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 sebenarnya sudah ditangani oleh Internet, dan menghubungkan bus LAN dengan teknologi Internet bisa menghasilkan struktur yang jauh lebih baik
  • Karena itu dirancanglah format frame untuk membawa paket Internet di atas LAN seperti Ethernet dan arcnet, dan dari titik inilah masalah mulai muncul
  • Jika ada beberapa router IP di dalam satu segmen Ethernet, perlu dibedakan router mana yang harus menerima dan meneruskan paket, dan alamat IP tujuan akhir saja tidak cukup untuk mengekspresikan pilihan itu
  • Karena itu, tujuan akhir tetap diletakkan di header IP, sementara router next hop yang sebenarnya harus ditentukan lewat alamat MAC pada frame Ethernet
  • Informasi yang sebenarnya ingin diungkapkan manusia adalah kirim tujuan IP 10.1.1.1 ke MAC router 11:22:33:44:55:66, tetapi sistem operasi akhirnya menangani ini dalam bentuk seperti lewat IP router 192.168.1.1
  • Untuk abstraksi ini, sistem operasi harus lebih dulu mencari alamat Ethernet dari IP router, dan sebagai langkah perantara ditambahkan ARP
  • ARP bekerja dengan mengirim broadcast ke seluruh Ethernet lokal untuk mencari pemilik IP tertentu, dan jika ada bridge, karena ini broadcast Ethernet maka harus diteruskan ke semua antarmuka
  • Pada Ethernet besar yang saling terhubung, broadcast berlebihan menjadi salah satu mimpi buruk terbesar, dan khususnya jauh lebih parah di wifi
  • Setelah itu bridge dan switch mulai menambahkan hack khusus untuk mengurangi jangkauan penyebaran ARP, dan beberapa perangkat, terutama access point wifi, bahkan membuat balasan ARP palsu, tetapi semuanya mendekati hack teknis belaka

Mati karena warisan

  • Seiring waktu, protokol non-IP di atas Ethernet hampir menghilang, 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
  • Saat kelelahan akibat konfigurasi IP manual meningkat, muncul kebutuhan akan konfigurasi otomatis, tetapi perangkat sudah keluar dari pabrik dengan alamat Ethernet, dan alamat IPv4 32-bit tidak cukup untuk ditetapkan unik secara permanen sejak manufaktur
  • Jika alamat IP dialokasikan secara berurutan begitu saja, hasilnya kembali ke struktur nonhierarkis seperti Ethernet, sehingga itu bukan solusi yang tepat
  • Maka lahirlah bootp dan DHCP, dan keduanya menjadi protokol yang memerlukan perlakuan khusus seperti ARP
  • Karena DHCP harus dikirim lebih dulu oleh node yang belum punya alamat IP, header IP yang pada dasarnya tidak bermakna namun berbentuk sesuai RFC tetap harus diisi; server DHCP juga harus mengisinya sendiri lewat raw socket, bukan lewat lapisan IP kernel
  • Pada akhirnya bootp dan DHCP tetap perlu mengetahui alamat Ethernet agar bisa menetapkan alamat IP, sehingga berperan hampir seperti ARP terbalik
  • Disebutkan bahwa RARP melakukan hal yang sama dengan lebih sederhana, tetapi hampir tidak dibahas di sini
  • Akibatnya, Ethernet dan IP makin lama makin terikat erat dan kini hampir tak bisa dipisahkan
  • Tabel routing IP tampak seolah menunjuk router dengan alamat IP, tetapi sebenarnya secara tidak langsung menunjuk alamat MAC; ARP melintasi bridge, dan DHCP tampak seperti paket IP padahal strukturnya lebih mirip protokol Ethernet
  • Pada saat yang sama bridging dan routing sama-sama makin kompleks, sementara bridging umumnya berada di ranah IEEE dan perangkat keras, dan routing di ranah IETF dan perangkat lunak, keduanya memperlakukan yang lain seolah tidak ada
  • Operator jaringan memilih antara bridging dan routing berdasarkan kebutuhan kecepatan dan seberapa enggan mereka menyusun server DHCP, dan sebisa mungkin memakai bridging sebanyak-banyaknya lalu menggunakan routing hanya saat perlu
  • Kompleksitas bridging pada akhirnya mendorong keputusan layer 2 naik ke lapisan lebih atas dan dikelola terpusat dengan protokol di atas IP, yaitu SDN
  • SDN memang lebih baik daripada switch dan bridge yang berjalan semaunya masing-masing, tetapi dikritik tetap terasa ironis karena IP sendiri sebenarnya sudah merupakan jaringan yang didefinisikan perangkat lunak untuk menangani jaringan yang kebesaran
  • IPv4 pada awalnya sulit dipercepat dengan perangkat keras dan pada praktiknya memang tidak cukup dipercepat, sedangkan konfigurasi DHCP sangat merepotkan, sehingga operator makin terampil melakukan bridging untuk cakupan yang makin besar
  • Data center besar masa kini digambarkan pada dasarnya bekerja seperti jaringan bus virtual raksasa berbasis SDN, dan sering kali tidak benar-benar merutekan paket

Sekarang lupakan sebentar cerita sebelumnya

  • Saat IETF merancang IPv6 pada awal 1990-an, kekacauan sebenarnya sudah berlangsung, tetapi desain tetap berjalan dengan asumsi bahwa bencana yang akan datang masih bisa dihindari
  • Salah satu perubahan kunci dalam proses itu adalah bahwa penggunaan jaringan bus fisik pada praktiknya sudah hampir berhenti
  • Ethernet tidak lagi benar-benar berupa bus dan hanya berpura-pura demikian; ketika peningkatan kecepatan membuat CSMA/CD tak bisa dipertahankan, topologi pun kembali ke bentuk bintang
  • Struktur dengan kabel terpisah dari setiap stasiun ke switch pusat menjadi umum, dan dinding, langit-langit, serta lantai dipenuhi bundel kabel Ethernet besar dan mahal
  • Bahkan wifi, yang tampak seperti bus utama berupa media radio bersama, pada praktiknya hampir selalu meniru topologi bintang besar melalui infrastructure mode
  • Bahkan dua stasiun wifi yang terhubung ke access point yang sama pun tidak berkomunikasi langsung; mereka mengirim paket ke access point dengan memasukkan alamat MAC node lawan, lalu access point menyiarkannya kembali
  • Jika node X mengirim ke node Internet Z melalui router IP Y dan access point wifi A, maka Z menjadi tujuan IP, Y menjadi tujuan Ethernet, dan A menjadi lawan pengiriman radio yang sebenarnya, sehingga lapisan alamat menjadi bertumpuk 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 kedua bit benar bersamaan, itu bahkan bisa mengekspresikan perilaku repeater antar-AP
  • Jika A adalah repeater dan harus mengirim lagi ke base station B, maka pengirim/penerima aktual di udara dan sumber/tujuan Ethernet semuanya berbeda, sehingga diperlukan 4-address mode
  • Pada mesh 802.11s bahkan ada 6-address mode, dan pada titik itu penulis mengaku menyerah untuk memahaminya

Dunia tempat IPv6 adalah desain yang baik

  • IETF yang memikirkan IPv6 melihat kekacauan yang sudah terjadi dan yang akan datang, lalu membayangkan dunia baru yang membuang warisan lama
  • Premis dunia itu adalah menghapus jaringan bus fisik, menghapus internetwork layer 2, menghapus broadcast, menghapus alamat MAC, menghapus ARP dan DHCP, memakai header IP sederhana yang bisa dipercepat dengan perangkat keras, mengatasi kelangkaan alamat, dan menghapus konfigurasi IP manual di luar core
  • Jika layer 2 selalu point-to-point, maka tidak ada target untuk broadcast sehingga bisa diganti dengan multicast, dan karena pihak pengirim dan penerima sudah jelas, alamat MAC juga tidak diperlukan
  • Jika alamat MAC hilang, pemetaan antara IP dan MAC juga tidak lagi dibutuhkan, sehingga ARP dan DHCP pun bisa hilang, dan ruang alamat yang cukup besar juga memungkinkan penggunaan kembali routing subnet besar
  • Dalam dunia itu dibayangkan wifi repeater, wifi access point, switch Ethernet, hingga SDN semuanya akan bekerja sebagai router IPv6
  • Dengan begitu, ARP storm, bridge dengan IGMP snooping, dan bridging loop akan hilang, dan semua masalah routing akan bisa dilacak dengan traceroute
  • Dengan menghapus 12 byte alamat MAC sumber/tujuan pada setiap paket Ethernet dan 18 byte informasi alamat pada setiap paket wifi, dihitung bahwa meski IPv6 memakai alamat 24 byte lebih besar daripada IPv4, tambahan overhead riilnya hanya 12 byte jika header Ethernet dihapus
  • Harapan bahwa suatu hari alamat Ethernet itu sendiri bisa dihapus disebut ikut membantu membenarkan pilihan panjang alamat IPv6 yang terasa terlalu besar
  • Namun desain indah ini tidak pernah terwujud di dunia nyata

Requiem untuk sebuah mimpi

  • Ungkapan rekan kerja, “lapisan hanya bertambah, tidak pernah dihapus,” diajukan sebagai kesimpulan keseluruhan
  • Keunggulan IPv6 hanya berlaku jika warisan lama bisa dibuang dan dimulai lagi dari awal, tetapi pada kenyataannya itu hampir mustahil
  • Bahkan jika tingkat adopsi IPv6 mencapai 99%, selama IPv4 belum sepenuhnya hilang, alamat Ethernet dan wifi juga tidak akan hilang; selama standar framing IEEE 802.3 dan 802.11 dipertahankan, penghematan byte itu pun takkan tercapai
  • Karena itu, IPv6 pada akhirnya membutuhkan neighbor discovery yang lebih kompleks daripada ARP, dan meskipun jaringan bus telah hilang, simulasi mirip broadcast tetap diperlukan agar perilaku ala ARP bisa terus berjalan
  • Di rumah, server DHCP lokal tetap harus dijalankan agar bohlam IPv4 kuno bisa berfungsi, dan agar bohlam itu bisa menjangkau internet, NAT juga tetap dibutuhkan
  • Yang lebih buruk, tim IPv6 dinilai meninggalkan masalah mobile IP tanpa solusi, dan akibatnya layer 2 bridging yang buruk tetap dibutuhkan
  • Disebutkan bahwa saat itu tampaknya ada rencana untuk lebih dulu menyebarkan IPv6 dalam beberapa tahun, lalu setelah IPv4 dan alamat MAC hilang, menyelesaikan mobile IP dengan lebih mudah
  • Pada masa itu penggunaan komputer bergerak nyaris belum dibayangkan, sehingga yang terpikir hanya skenario canggung seperti berpindah antarport Ethernet sambil tetap mempertahankan ftp

Mobile IP sebagai killer app

  • Setelah itu sejarah bergerak ke arah penggunaan komputer yang dibawa-bawa, yaitu telepon, yang berpindah di antara banyak access point nirkabel sebagai hal biasa
  • Di LTE perpindahan semacam ini umumnya bekerja, dan di wifi kadang bekerja, tetapi rahasianya bukan routing Internet melainkan layer 2 bridging
  • Routing Internet sama sekali tidak menangani mobilitas; jika Anda bergerak di jaringan IP dan alamat IP berubah, semua koneksi yang sedang terbuka akan putus
  • Wifi perusahaan menjembatani seluruh LAN di layer 2 agar server DHCP pusat memberi alamat IP yang sama tak peduli access point mana yang dipakai, lalu mempertahankan koneksi dengan hanya menanggung beberapa detik kekacauan saat bridge dikonfigurasi ulang
  • Wifi rumahan dengan banyak extender atau repeater juga memakai cara yang sama
  • Sebaliknya, jika Anda berjalan melewati jaringan wifi yang berbeda-beda seperti wifi publik dari toko ke toko, Anda akan mendapat alamat IP baru setiap kali, dan semua koneksi pun putus setiap saat itu terjadi
  • LTE melangkah lebih jauh dengan mempertahankan alamat IP yang sama bahkan saat berpindah beberapa mil di antara banyak base station, dan disebutkan bahwa jaringan seluler umumnya memakai alamat IPv6
  • Caranya adalah dengan men-tunnel trafik ke titik pusat, lalu menjembataninya bersama banyak firewall seolah menjadi satu LAN virtual layer 2 yang sangat besar; biayanya adalah kompleksitas luar biasa dan latensi tambahan yang memalukan
  • Operator seluler ingin memperbaiki ini, tetapi digambarkan sebagai hal yang nyaris mustahil

Cara benar-benar membuat mobile IP bekerja 1

  • Jawaban mengapa mobile IP tidak pernah bekerja dengan baik bermuara pada kesimpulan bahwa definisi terkenal 4-tuple yang dipakai untuk mengidentifikasi sesi itu keliru
  • Sesi TCP dan UDP diidentifikasi dengan (source ip, source port, destination ip, destination port), dan struktur ini melintasi layer 3 dan layer 4 serta rapuh terhadap perubahan alamat IP
  • Diajukan argumen bahwa jika identifikasi sesi hanya didasarkan pada data layer 4, mobile IP akan bekerja sempurna
  • Sebagai contoh, saat X:1111 berkomunikasi dengan Y:80 lalu X mengubah alamatnya menjadi Q, paket berubah 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, diajukan gagasan memperbesar nomor port dari 16-bit saat ini menjadi semacam nilai hash unik 128 atau 256 bit, dan mengidentifikasi socket dengan tag yang tidak bergantung pada alamat IP
  • Dalam hal ini paket tetap memuat informasi alamat (X,Y) pada layer 3 untuk routing, tetapi kernel saat menerima tidak memakai informasi layer 3 untuk mengidentifikasi 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 akan menyimpan cache bahwa paket sesi (uuid) baru-baru ini datang dari X, dan ketika X berpindah ke Q lalu datang lagi dengan tag (uuid,80) yang sama, Y bisa mencocokkannya ke sesi itu sambil memperbarui tujuan balasan dari X menjadi Q
  • Dengan begitu koneksi tetap hidup, tetapi tetap perlu perhatian tambahan untuk mencegah pembajakan koneksi oleh peniru
  • Namun UDP dan TCP tidak bekerja seperti ini, dan mengubahnya sekarang dinilai sebagai proyek yang dulunya tampak semudah mengganti IPv4 ke IPv6, tetapi puluhan tahun kemudian pun belum selesai separuh

QUIC dan kemungkinan jalan memutar

  • Sisi baiknya, ada kemungkinan solusi tidak langsung melalui satu pelanggaran lapisan lagi
  • Dengan membuang 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 diurai lagi sebagai paket internal dengan tag uuid yang sesuai lalu dipetakan ke sesi dan socket yang benar
  • Disebutkan bahwa protokol QUIC eksperimental setidaknya secara teori sudah memiliki format paket yang cocok untuk struktur semacam ini
  • Karena enkripsi dan autentikasi paket stateless yang dipakai QUIC memang sudah membutuhkan pengenal atau kunci sesi yang unik, diharapkan dukungan roaming transparan mungkin bisa ditambahkan dengan pekerjaan yang relatif kecil
  • Jika itu terjadi, lalu semua UDP dan TCP yang tersisa juga dihapus dari Internet, kali ini layer 2 bridging benar-benar tidak lagi diperlukan, dan broadcast, alamat MAC, SDN, serta DHCP juga bisa dihapus
  • Bagian terakhir ditutup dengan kalimat pemulihan keanggunan Internet

Catatan revisi tambahan

  • Revisi 2017-08-16

    • Gagasan mobile IP sebelumnya tidak terbatas pada IPv6
    • Direvisi bahwa ini juga dapat bekerja di lingkungan IPv4 dan 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 memercayai paket pertama dari host baru Q, penyerang di mana saja di internet akan mudah membajak koneksi X→Y
    • Jika Y mengirim cookie, lalu Q menerimanya, memprosesnya, dan mengirimkannya kembali ke Y, maka setidaknya serangan tidak bisa dilakukan oleh penyerang eksternal sederhana dan memerlukan kemampuan setingkat man-in-the-middle
    • Jika memakai protokol terenkripsi seperti QUIC, handshake itu juga dapat dilindungi oleh kunci sesi
  • Revisi 2017-10-24

    • Selain QUIC, ada kandidat protokol pengganti TCP lain yang mendukung roaming seperti ini, dan MinimaLT disebut sebagai contohnya
    • Ditulis bahwa MinimaLT adalah protokol pertama yang pernah didengar yang menyelesaikan masalah roaming dengan elegan, dan solusi yang diadopsi di masa depan mungkin akan meniru struktur ini
  • Revisi 2020-07-09

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

1 komentar

 
GN⁺ 2026-04-21
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