Menggunakan internet tanpa koneksi IPv4

 (jamesmcm.github.io)
3 poin oleh GN⁺ 2025-06-30 | 1 komentar | Bagikan ke WhatsApp
  • Bahkan dalam situasi koneksi IPv4 terputus, seluruh internet tetap bisa digunakan melalui IPv6, WireGuard, dan VPS Hetzner
  • Karena Carrier Grade NAT (NAT skala besar), gangguan hanya terjadi pada IPv4, sementara IPv6 tidak terdampak
  • Dengan menyiapkan terowongan WireGuard dan menyalurkan trafik IPv4 melalui VPS, lingkungan penggunaan web yang normal berhasil dipulihkan
  • Juga dibahas cara memanfaatkan network namespace dan Docker, serta metode mengatasi masalah MTU
  • Menekankan pengalaman menyelesaikan sendiri masalah jaringan yang kompleks berkat lingkungan Linux dan alat open source

Ringkasan

Beberapa hari lalu, penulis mengalami masalah akses IPv4 terputus pada router rumah setelah pemadaman listrik. Untungnya akses IPv6 tetap normal, sehingga sebagian situs web (Google, Meta, dan lainnya) masih bisa diakses, tetapi sebagian besar situs lain (seperti GitHub) tidak dapat dibuka. Tulisan ini merangkum proses memulihkan lingkungan internet penuh hanya dengan IPv6 menggunakan Linux, WireGuard, dan VPS Hetzner.

Penyebab gangguan dan latar belakang

Ditemukannya anomali lingkungan jaringan

  • Saat proses pemulihan setelah listrik padam, terkonfirmasi bahwa server IPv6 dapat diakses dengan normal, tetapi server IPv4 tidak bisa diakses
  • Hasil menjalankan perintah diagnostik (ping -6, traceroute) juga hanya menunjukkan perbedaan berdasarkan versi IP
  • Setelah ditanyakan, diketahui bahwa masalah terjadi pada lapisan CG-NAT (Carrier Grade NAT) milik operator, yang bermasalah dalam konversi IPv4
  • Karena diperkirakan butuh beberapa hari hingga perbaikan di sisi ISP selesai, penulis harus mencari solusi sendiri

Penjelasan NAT dan CG-NAT

  • NAT (Network Address Translation): metode yang memungkinkan banyak perangkat berbagi satu alamat IPv4 publik
    • Di router, IP internal diterjemahkan menjadi IP publik dan port unik untuk mengelola trafik, lalu saat pengiriman balik, tujuan internal dipulihkan berdasarkan informasi pemetaan
    • Struktur ini membuat NAT berfungsi sebagai firewall implisit dan memunculkan kebutuhan akan port forwarding
  • CG-NAT (Carrier Grade NAT): struktur berlapis di mana ISP kembali menerapkan NAT satu kali lagi pada router rumah pelanggan
    • NAT diterapkan secara bertingkat di internal ISP untuk mengatasi kelangkaan alamat IPv4
    • Dalam lingkungan CG-NAT, penyediaan layanan seperti port forwarding menjadi jauh lebih terbatas
    • Inilah alasan gangguan hanya terjadi pada trafik IPv4, karena masalahnya berada pada pemrosesan paket IPv4 di lapisan tersebut

Keunggulan IPv6

  • Ruang alamat IPv6 jauh lebih besar sehingga setiap perangkat dapat memperoleh alamat langsung tanpa NAT
    • Sebagian besar router rumah mendapatkan subnet /64, yang memungkinkan penggunaan triliunan alamat
  • Karena NAT tidak diperlukan, komunikasi langsung dimungkinkan, tetapi konfigurasi firewall menjadi lebih penting
  • CG-NAT hanya berlaku untuk IPv4, sehingga dalam kasus ini hanya IPv6 yang tetap berfungsi normal
  • Namun, masih banyak server (misalnya GitHub) yang belum bisa diakses hanya dengan IPv6

Memulihkan IPv4 dengan terowongan WireGuard

Gambaran implementasi

  • Dengan memanfaatkan VPS Hetzner (mendukung stack IPv4/IPv6) dan WireGuard, penulis membangun lingkungan yang memungkinkan akses internet penuh saat koneksi internet hanya tersedia lewat IPv6
    • Menjalankan server WireGuard di VPS dan membangun terowongan dengan perangkat klien
    • Trafik dialihkan ke VPS melalui IPv6, lalu dari VPS seluruh situs (termasuk IPv4) dapat diakses
    • Prinsipnya mirip dengan Dual-Stack Lite

Contoh konfigurasi server dan klien

  • Pada konfigurasi server WireGuard, baik trafik IPv4 maupun IPv6 ditangani
    • Termasuk contoh aturan MASQUERADE (konversi IP dinamis) dan SNAT (konversi IP tetap)
    • Dengan memanfaatkan IPv6 global yang dialokasikan langsung, koneksi peer WireGuard dapat dibuat tanpa NAT
    • Entri PostUp/PostDown dapat ditulis beberapa kali agar setiap perintah dijalankan berurutan
  • Contoh konfigurasi klien
    • Dijelaskan contoh penggunaan alamat IPv6 yang dialokasikan langsung atau kombinasi ULA yang berada di balik NAT
    • Dengan menerapkan 0.0.0.0/0, ::/0 pada AllowedIPs, seluruh trafik dapat ditunnelkan
    • Juga disediakan cara mengatur Google DNS (IPv4, IPv6) dan MTU

Terowongan berjalan normal

  • Setelah konfigurasi WireGuard di kedua sisi selesai, tunneling IPv4/IPv6 berjalan normal
  • Metode yang sama juga diterapkan pada PC istrinya dengan pemasangan klien WireGuard Linux yang sederhana
  • Namun, umumnya tidak memungkinkan terhubung bersamaan dengan VPN kantor, sehingga dibutuhkan network namespace tambahan

Network namespace dan Docker

Fungsi dan cara pemanfaatan

  • Dengan alat seperti vopono, dapat dibuat network namespace per aplikasi, lalu antarmuka VPN atau WireGuard dapat ditentukan langsung di namespace tersebut
    • Perlu aturan MASQUERADE tambahan untuk memaksa trafik internal melewati terowongan WireGuard
    • Termasuk tips konfigurasi DNS yang terisolasi dari luar dan gai.conf (pengaturan DNS yang memprioritaskan IPv4)
  • Disajikan contoh implementasi menghubungkan VPN dan menjalankan aplikasi di dalam namespace
    • Menjalankan beberapa layanan di namespace yang sama membantu mencegah konflik jaringan sejak awal

Kombinasi dengan container Docker

  • Karena daemon Docker secara default menggunakan soket jaringan host, akses tidak bisa dilakukan hanya dengan menjalankannya di namespace biasa
    • Disajikan workaround menggunakan teknik virtualisasi Unix seperti mount namespace dan bind mount /sys
    • Dengan menjalankan dockerd di dalam namespace serta menentukan soket dan data root terpisah, koneksi internet di dalam container dapat dipulihkan
    • Disebutkan juga bahwa lingkungan bridge jaringan yang kompleks mungkin memerlukan pengaturan tambahan

Masalah MTU WireGuard (MTU: Maximum Transmission Unit)

  • Setelah koneksi WireGuard aktif, muncul gejala di mana hanya sebagian situs web yang tidak bisa diakses (misalnya SSL), sementara ping tetap merespons normal
  • Melalui pengujian ping dengan berbagai ukuran, ditemukan bahwa MTU terlalu tinggi sehingga paket besar terbuang di tengah jalan
    • Masalah langsung teratasi setelah MTU diturunkan menjadi 1280
  • MTU adalah ukuran paket maksimum yang dapat dikirim dalam satu kali transmisi
    • MTU yang sesuai perlu diatur dengan mempertimbangkan overhead terowongan/enkapsulasi; jika tidak, koneksi dapat bermasalah saat mengirim paket besar
    • Dalam spesifikasi IPv6, MTU minimum adalah 1280

Kesimpulan dan saran pemanfaatan

  • Tulisan ini menekankan pengalaman mendiagnosis dan menyelesaikan sendiri masalah jaringan menggunakan Linux dan alat open source, mulai dari membangun server VPN WireGuard, mengelola network namespace, menyiapkan lingkungan khusus Docker, hingga troubleshooting MTU
  • Layanan seperti VPS Hetzner dinilai stabil dibanding harganya dan memudahkan pengoperasian layanan jaringan yang sah seperti WireGuard
  • Nilai firmware router open source (OpenWRT) dan teknik networking Linux kembali ditegaskan
    • Fleksibilitas untuk mengelola dan memodifikasi jaringan secara langsung memberikan keuntungan besar dalam lingkungan kerja jarak jauh
    • Dengan pemahaman dan latihan yang cukup, gangguan jaringan yang kompleks pun dapat diselesaikan sendiri

Referensi

  • Tailscale – How NAT Traversal Works
  • ArchWiki – contoh use case WireGuard
  • Unix StackExchange – trik Docker di dalam namespace
  • AskUbuntu – pengaturan prioritas DNS

(skrip terkait, config, tips, dan tautan referensi dapat dilihat di sumber asli)

Bacaan terkait

1 komentar

 
GN⁺ 2025-06-30
Opini Hacker News

  • Judulnya terasa sedikit menyesatkan, karena sebenarnya isi tulisan ini lebih dekat ke “mengakses internet IPv4 dengan terhubung ke VPS melalui terowongan IPv6”, yang biasanya disebut 4in6
    Bagaimanapun, ini pendekatan yang menarik
    Dalam pengalaman saya, saat IPv4 bermasalah di ISP kami, semuanya langsung down sehingga isu dukungannya relatif sederhana; tetapi jika yang bermasalah adalah IPv6, gejalanya jadi aneh dan parsial, seperti koneksi lambat atau putus sesekali
    Terutama jika gateway keliru mengira ia punya IPv6, dari sudut pandang pengguna masalahnya jadi lebih merepotkan karena hanya beberapa fungsi yang tidak bekerja

    • Baru-baru ini saat IPv4 sempat tidak berfungsi, saya baru sadar setelah Github tidak bisa diakses
      Sekarang kebanyakan situs web konsumen berjalan normal lewat IPv6
      Namun, orang yang router-nya hanya menyediakan DNS IPv4 mengalami internet yang benar-benar terputus
      Rasanya Microsoft seharusnya memberi perhatian lebih soal ini
      Untuk mengecek apakah IPv4 sudah kembali, saya bahkan harus mengingat hostname mDNS yang saya tetapkan di router

    • Terus terang, IPv4 pernah putus di rumah saya dan istri saya bahkan tidak menyadarinya
      Google, Facebook, Apple/iCloud, dan hampir semua layanan berbasis CloudFlare berjalan baik lewat IPv6

    • Pengalaman saya juga mirip
      Masalah IPv6 memang sangat sulit diidentifikasi penyebabnya dan direproduksi, dan akhirnya yang terdengar cuma “di komputer saya sih jalan?”

    • Kebanyakan ISP masih memblokir IPv6, dan banyak usaha kecil juga hanya “mencoba” IPv6 lalu lupa hal seperti record AAAA
      Akibatnya pengguna mendapati sesuatu bisa jalan di rumah teman atau kafe dengan ISP murah, tapi tidak jalan di rumah sendiri
      Ini mungkin terdengar aneh, tetapi tampaknya memang tidak ada solusi bagus selain berharap IPv4 menghilang saja
      Ada teknik seperti Happy Eyeballs (mencoba koneksi IPv4/IPv6 bersamaan lalu memilih yang lebih cepat), tetapi dalam praktiknya masalah lebih sering muncul di tingkat aplikasi, dan tidak banyak cara umum untuk menyelesaikannya
      Dalam kasus saya, komprominya adalah mengaktifkan IPv6 di jaringan tetapi mematikan DNS IPv6 di browser, walau hasilnya tetap tidak memuaskan

  • Jika ingin memakai IPv6 tetapi ISP tidak menyediakannya, Hurricane Electric (HE) sudah sangat lama menawarkan layanan tunnel gratis
    Tautan yang relevan antara lain tunnelbroker.net, ipv6.he.net, panduan Fedora, blog Brandon Rozek, panduan DD-WRT, skrip auto-update forum Mikrotik, dan panduan RockyLinux untuk berbagai metode setup

    • Ada satu hal yang perlu diperhatikan: layanan streaming sering memblokir tunnel semacam ini karena dianggap seperti upaya bypass VPN, sehingga konten yang dibatasi wilayah ikut diblokir
      Meski begitu, berkat fitur RA (router advertisement), perangkat jaringan apa pun dapat menyiarkan jaringan IPv6 dalam unit /64, sehingga beberapa perangkat di dalam jaringan tetap bisa memakai alamat IPv6 meskipun router tidak mendukung tunnel HE secara langsung (selama router tidak memfilter RA demi alasan keamanan)
      Ini sangat nyaman saat ingin menjalankan layanan sendiri di rumah karena bisa dilakukan hanya dengan IPv6 tanpa port forwarding

    • Layanan Hurricane Electric memang bagus, tetapi sekarang makin banyak ISP yang menyediakan IPv6 secara default sehingga pengguna umum mulai meninggalkan layanan tunnel
      Selain itu, makin banyak layanan jaringan yang menganggap tunnel he.net sebagai sumber penyalahgunaan atau abuse lalu memblokirnya, sampai akhirnya saya harus menonaktifkan penggunaan IPv6 di sebagian besar jaringan saya

    • Sebagai catatan, tunnel Hurricane Electric mensyaratkan Anda harus menerima alamat IPv4 publik dari ISP
      Jika Anda berada di balik NAT seperti carrier-grade NAT, Anda perlu mencari solusi lain untuk menghadirkan IPv6 ke rumah

    • Saya sudah 5 tahun menjadi “pelanggan” tunnel 6in4 gratis HE di OpenBSD
      Dengan konfigurasi jaringan sederhana seperti file /etc/hostname.gif0, semuanya terus berjalan stabil
      Saya juga memakainya untuk berkomunikasi dengan klaster VPS di AWS yang sengaja dikonfigurasi tanpa IPv4
      Karena AWS kini mengenakan biaya alamat IPv4 secara agresif, menurut saya cara ini sangat membantu menghemat biaya

  • Jika benar-benar butuh akses v4 dari lingkungan v6 only, memakai gateway DNS64+NAT64 publik adalah solusi yang mudah
    Lihat daftar provider publik nat64.net
    Biasanya cukup dengan mengganti server DNS
    DNS64 akan mensintesis record AAAA untuk situs yang tidak punya record AAAA agar bisa terhubung ke box NAT64
    Lalu NAT64 menerima trafik tersebut dan melakukan konversi protokol + NAT
    Sebagai contoh praktik, Anda bisa langsung mengakses tempat seperti github dengan perintah dig atau curl

    • Di Eropa, memakai nat64.net secara langsung pun terasa cukup nyaman
      Pengalaman saya sejauh ini hanya bagus

    • Jika memakai Cloudflare WARP, kecepatannya bisa terasa jauh lebih baik
      Anda juga bisa langsung mengakses alamat IPv4 melalui WARP

  • Kadang saya heran memang ada pengguna yang hidup di lingkungan IPv6-only
    Dulu untuk situasi sebaliknya (lingkungan IPv4-only tetapi perlu akses IPv6), jika punya kontrol penuh atas server, solusi tercepat dan paling praktis adalah memakai proxy SOCKS5 (ssh -D)
    Cukup atur browser agar memakai proxy socks dan langsung bisa digunakan
    Jika diterapkan ke seluruh sistem, malah ada risiko koneksi ssh ikut putus, jadi itu yang agak saya khawatirkan

  • Situasinya mirip dengan saya
    Sudah sekitar 2 minggu tiket gangguan IPv4 saya terbuka, tetapi jawabannya hanya “teknisi akan segera menanganinya”
    Karena IPv6 normal, sepertinya mereka tidak menganggapnya sebagai gangguan total
    Di Jerman ada aturan soal kompensasi konsumen dalam kasus seperti ini, jadi saya akan cek apakah kasus ini termasuk
    Masalah dari pendekatan yang disarankan di blog adalah rentang IP data center sering diblokir oleh banyak layanan, atau diminta melewati captcha, atau diperlakukan seperti IP milik penyedia VPN, dan hampir tidak ada cara untuk menghindarinya
    Dalam kasus saya, solusinya harus berlaku untuk seluruh rumah, jadi saya menyiapkan aturan routing dan NAT lewat Wireguard di router, dan untungnya saya memakai perangkat terbuka seperti Ubiquiti EdgeRouter
    Kalau yang saya pakai FritzBox, pekerjaan ini pasti jauh lebih sulit
    Namun, ada kekurangan berupa performa router yang tidak cukup kuat sehingga melambat saat jumlah koneksi banyak; saya sedang mempertimbangkan beralih ke IPSec yang mendukung hardware offloading

    • FritzBox juga menyediakan alur konfigurasi GUI yang sangat bagus untuk koneksi VPN
      Asumsi dasarnya memang FritzBox ke FritzBox, tetapi VPN yang kompatibel juga bisa
      Ada juga pengaturan rute IPv4/IPv6 statis
      Masalah terbesar adalah mengetahui parameter enkripsi IPSec apa yang diminta pihak seberang; Wireguard memang lebih mudah, tetapi di sisi lain ada persoalan akselerasi hardware
      Jika perlu, ada juga teknik membackup seluruh konfigurasi FritzBox, mengeditnya langsung, lalu menghitung ulang checksum sebelum memasukkannya kembali
      AVM menyembunyikan sangat banyak detail konfigurasi yang tidak diekspos ke pengguna, dan itu memang disengaja
      Sebagian dibuat agak sulit agar pengguna tidak merusak router secara tidak sengaja

    • Saya tidak terlalu tahu kondisi di Jerman, tetapi di Belanda, jika internet tetap dan seluler Anda memakai ISP yang sama, Anda bisa meminta data seluler gratis saat jaringan kabel mengalami gangguan
      Kalau memungkinkan, saya sarankan menanyakan opsi itu ke ISP Anda

  • Bahkan setelah sekian lama, saya masih belum menemukan alasan yang jelas untuk memindahkan semua perangkat dan homelab saya ke IPv6
    Port forwarding dan aturan firewall masih terasa lebih intuitif, sedangkan berpindah ke IPv6 terlihat seperti akan membawa berminggu-minggu pekerjaan troubleshooting, firewall, pengalamatan ulang, dan kerumitan lain
    Saya penasaran apakah ada sesuatu yang saya lewatkan

    • Secara realistis, pada tahap sekarang hampir tidak ada yang Anda lewatkan
      Ke depan, jika perusahaan besar seperti Google atau Cloudflare tidak lagi sanggup menanggung biaya alamat IPv4 yang terus naik, mereka mungkin akan mulai memberi insentif untuk IPv6, misalnya membatasi kecepatan koneksi IPv4
      AWS dulu hanya mengenakan biaya untuk IPv4 Elastic IP yang tidak dipakai, tetapi sekarang alamat yang sedang dipakai pun tetap dikenai biaya
      Saat nanti Anda meningkatkan gateway atau router, ada baiknya langsung membiarkan IPv6 aktif; untuk saat ini dual-stack membuat perangkat dan layanan lama tetap berjalan tanpa masalah
      Untuk autokonfigurasi alamat IPv6, secara historis pendekatannya memang semrawut, tetapi tampaknya mulai mengerucut ke SLAAC, sementara di sisi ISP DHCPv6 kemungkinan masih akan dipakai cukup lama

    • Sebenarnya tidak sesulit itu
      Jika jaringan rumah Anda tidak terlalu rumit, cukup luangkan sedikit waktu di suatu malam dan IPv6 bisa selesai disetel
      Dalam kasus Comcast, cukup aktifkan opsi IPv6 di router, ISP akan memberikan prefix, lalu itu akan otomatis diiklankan ke jaringan, dan Anda hanya perlu membuka port yang diperlukan di firewall

    • Anda tidak melewatkan apa pun
      Di lingkungan enterprise, manfaat penerapan IPv6 sering kalah dibanding kekurangan atau kompleksitas tambahannya
      Saya mengelola sekitar 3500 perangkat, 7 gedung, 2 koneksi WAN 10Gbps, 1 koneksi WAN 4Gbps, dan 26 alamat IPv4 publik
      Sampai sekarang tidak ada satu pun alasan yang benar-benar mengharuskan saya memakai IPv6
      Menjalankan dual-stack justru menambah beban dan kompleksitas jaringan yang tidak perlu
      Bahkan baru-baru ini saya dua kali mengajukan blok alamat IPv6 statis dan terus ditolak
      Secara praktis tidak ada manfaatnya, bahkan mendapatkannya pun sulit
      Jika melihat panduan pengajuan IPv6 pertama dari ARIN,
      → memiliki alokasi IPv4
      → akan segera melakukan multihoming IPv6
      → punya 13 end-site (kantor, dsb.) dalam 1 tahun
      → punya 2000 alamat IPv6 dalam 1 tahun
      → punya 200 subnet /64 dalam 1 tahun
      Anda harus memenuhi salah satunya agar memenuhi syarat pengajuan

  • Saya sangat menghargai kebijakan Apple App Store yang mewajibkan semua aplikasi berjalan di jaringan IPv6-only
    Bagi pengembang, pengalaman pertamanya mungkin mengejutkan, tetapi dari sisi konsumen tuntutan seperti ini sangat disambut baik

    • Namun kebijakan itu tidak mewajibkan sisi server memiliki alamat IPv6

    • Kalau begitu, saya jadi penasaran apakah github bisa diakses lewat v6 dari dalam aplikasi

  • Dalam pekerjaan, saya mengoperasikan beberapa VPN IPv6 only untuk mengakses infrastruktur internal
    Masalah terbesarnya adalah klien Windows dan macOS wajib punya server DNS v6
    Karena klien bisa berada di jaringan yang mendukung v6 atau tidak, kami menjalankan server DNS langsung di dalam VPN lalu mengirimkannya otomatis ke klien
    Tetapi setelah koneksi VPN terputus, aplikasi Wireguard tidak bisa memulihkan DNS semula, dan itu menimbulkan berbagai masalah

    • Saya pernah berhasil memakai IPv6-only dengan baik di jaringan ISP IPv4 only dan lingkungan macOS tanpa DNS terpisah
      Saya tidak ingat persis caranya, tetapi macOS berjalan baik hanya dengan diberi alamat v6
      Cukup tetapkan alamat ULA di host, dan itu mudah jika penggunanya tahu caranya
      Aplikasi VPN dapat memanfaatkan skrip yang menambahkan ULA ke jaringan IPv6-only secara langsung
      Hanya saja, jika alamat ULA yang dibuat dibiarkan begitu saja, itu bisa menimbulkan masalah saat pengguna berpindah ke jaringan v6 lain

  • Jika menghadapi situasi yang sama, Anda bisa dengan mudah membuat lingkungan proxy socks memakai proxy ssh (ssh -D 8080 user@hostname)
    Setelah terhubung, cukup setel alamat proxy browser ke localhost:8080

    • Saya juga tadinya ingin memberi saran yang sama
      Untuk solusi sementara, ini sangat sederhana dan bahkan cukup bagus dipakai terus-menerus jika perlu
      Hanya saja, AllowTcpForwarding harus diaktifkan di sshd_config

    • Saya selalu memakai cara ini saat menggunakan Wi-Fi publik
      Jadi saya tidak perlu membayar layanan VPN, dan tidak perlu mempercayainya; cukup kirim melalui proxy socks di server infomaniak saya sendiri

  • Secara pribadi saya sangat frustrasi dengan IPv4, terlebih ISP saya memaksa hanya menyediakan IPv4
    Lambatnya adopsi IPv6 menurut saya adalah kegagalan besar industri teknologi
    Saya jadi bertanya siapa yang harus bertanggung jawab
    Apakah produsennya yang membuat firmware router seadanya, apakah karena kepemimpinan ISP yang terus mendorong IPv4, apakah karena spekulan alamat IPv4, atau karena kurangnya pelatihan bagi engineer jaringan dan staf dukungan; saya rasa perlu pembahasan yang lebih mendasar tentang akar masalahnya
    Kalau internet bisa bertransisi cukup baik dari TLS 1.0, bukankah seharusnya IPv4 juga bisa dilewati?
    Mungkin di masa depan semacam proxy AI untuk kode legacy bisa menjadi solusi

    • Peralihan dari TLS 1.0 lebih mudah karena prinsip end-to-end
      Selama server dan klien mendukung protokol baru, perangkat perantara (router, switch, dll.) cukup melihat lapisan jaringan (IP) dan tidak peduli versi baru TLS
      Namun jika yang diubah adalah protokol lapisan jaringan (IP) itu sendiri, semua perangkat jaringan di tengah ikut terdampak
      Sebagai catatan, saat adopsi TLS 1.3 pun middlebox sudah merusak prinsip end-to-end dengan memantau atau memodifikasi trafik, sampai demi kompatibilitas TLS 1.3 harus menyamar seperti reconnect TLS 1.2; situasinya memang absurd

    • Perbedaannya adalah TLS hanya perlu didukung server/klien, sedangkan perangkat jaringan perantara cukup memahami paket TCP
      IPv6 harus didukung oleh seluruh perangkat di antara server dan klien, sehingga menjadi teknologi yang bergantung pada “penyebut umum terendah”
      Upgrade TLS tidak mengubah terlalu banyak hal secara mendasar, sementara IPv6 mengubah terlalu banyak hal sekaligus
      Kalau melihat ke belakang, mungkin akan lebih mudah diadopsi bila IPv6 hanya memperluas alamat menjadi 64-bit saja

    • Secara praktis, banyak orang enggan mengadopsi karena manfaat penggantiannya terlalu kecil atau nyaris tidak ada
      Bukan karena ada teori konspirasi besar IPv4, hanya saja hasilnya tidak sepadan dengan pekerjaan dan risikonya

    • Ada lelucon di industri jaringan bahwa “IPv6 adalah solusi akademis yang dipaksakan ke masalah rekayasa”
      Jika mempertimbangkan kompatibilitas skala besar dengan IPv4 sekaligus implementasi, operasi, dan pemeliharaan di lapangan, IPv6 terasa terlalu kompleks
      IPv4 juga nyaris tidak punya masalah nyata selain kekurangan alamat, jadi kecil kemungkinan ia benar-benar hilang
      Karena itu, di lapangan IPv6 sering gagal menjadi solusi yang betul-betul praktis