IPv4 vs IPv6: Isu Praktis yang Sering Terlewat

Kebanyakan dari kita masih menganggap IPv6 sebagai "urusan masa depan", padahal di banyak jaringan modern IPv6 sudah aktif secara default — di laptop, di VPS, bahkan di router rumah sekalipun kita tidak pernah sengaja mengaktifkannya. Masalahnya bukan IPv6 itu sendiri, tapi kondisi setengah jalan: IPv6 menyala tapi tidak benar-benar berfungsi penuh, sementara sistem tetap mencoba memakainya lebih dulu. Hasilnya adalah gejala klasik yang membingungkan — koneksi kadang lambat beberapa detik sebelum akhirnya jalan, atau gagal total padahal ping ke domain lain lancar-lancar saja. Saya cukup sering menemui pola ini saat menangani server atau deployment, jadi saya rasa penting untuk dibahas sebagai isu praktis, bukan sekadar teori jaringan.

Kenapa "setengah jalan" itu yang paling menyebalkan

Secara default, sistem operasi modern mengikuti kebijakan Happy Eyeballs (RFC 8305): ketika sebuah domain punya alamat IPv4 dan IPv6 sekaligus, sistem akan mencoba keduanya secara paralel dan memakai mana yang lebih cepat merespons. Ini bagus di teori. Masalahnya muncul ketika IPv6 tercatat sebagai tersedia (misalnya karena router mengumumkan Router Advertisement atau ada alamat link-local) tapi jalur keluarnya sebenarnya tidak benar-benar tersambung ke internet — entah karena ISP belum benar-benar mendukung IPv6, firewall memblokir sebagian trafik IPv6, atau konfigurasi DNS AAAA mengarah ke alamat yang salah. Alih-alih langsung gagal dan jatuh ke IPv4, koneksi harus menunggu timeout dulu. Dari sisi pengguna, ini terasa seperti "kadang lambat, kadang cepat", yang jauh lebih sulit didiagnosis dibanding kegagalan total.

Cara cepat memastikan status IPv6 di sistem Anda

Sebelum menyalahkan aplikasi atau load balancer, saya biasanya cek dulu di level jaringan. Beberapa langkah sederhana yang bisa dijalankan dari terminal:

  • Cek apakah interface punya alamat IPv6 global (bukan cuma link-local fe80::) dengan ip -6 addr di Linux atau ifconfig di macOS.
  • Tes konektivitas keluar langsung ke alamat IPv6 publik, misalnya lewat salah satu layanan uji IPv6 publik yang banyak tersedia, atau dengan curl -6 -v https://domain-anda.com, untuk memastikan jalurnya benar-benar nyambung, bukan cuma tersambung ke router lokal.
  • Cek record DNS domain yang bermasalah dengan dig AAAA nama-domain.com. Kalau ada record AAAA tapi server tujuan sebenarnya tidak melayani IPv6 dengan benar, ini penyebab paling umum dari gejala "lambat lalu jalan".

Sebagai ilustrasi, bayangkan sebuah server yang menerima keluhan koneksi lambat secara acak: curl -6 menggantung lama sebelum akhirnya timeout, sementara curl -4 langsung sukses dalam hitungan milidetik. Pola seperti ini biasanya berarti AAAA record mengarah ke jalur yang belum benar-benar berfungsi — begitu record itu dihapus atau firewall IPv6 diperbaiki, gejalanya hilang. Ini bukan bug aplikasi, murni isu jaringan yang kebetulan nyambung ke lapisan aplikasi.

Praktik yang saya pegang di production

Beberapa prinsip umum yang saya pakai supaya tidak terjebak masalah ini:

  • Jangan tambahkan record AAAA untuk sebuah host kecuali jalur IPv6-nya sudah benar-benar diuji ujung ke ujung, termasuk firewall dan security group-nya.
  • Kalau memang belum siap mendukung IPv6 penuh, lebih baik konsisten IPv4-only dulu daripada setengah-setengah — setengah jalan itu yang paling sering bikin masalah tersembunyi.
  • Saat debugging koneksi yang "kadang lambat kadang cepat" tanpa pola jelas, jadikan pengecekan IPv4 vs IPv6 sebagai langkah standar, sebelum masuk ke debugging aplikasi yang lebih rumit.
  • Untuk container atau orkestrasi seperti Docker, perlu diingat bahwa dukungan IPv6 di dalam container sering berbeda dari host-nya, jadi jangan berasumsi keduanya otomatis konsisten.

Ringkasnya

IPv6 sendiri bukan masalah — justru arah jangka panjang jaringan internet memang ke sana. Yang jadi masalah adalah dukungan yang setengah-setengah: DNS bilang ada IPv6, tapi jalurnya tidak benar-benar berfungsi. Kalau menemui gejala koneksi yang tidak konsisten padahal secara logika aplikasi tidak ada yang berubah, cek dulu status IPv6 sebelum menghabiskan waktu di lapisan yang lebih tinggi. Satu perintah curl -6 vs curl -4 sering kali cukup untuk membedakan mana masalah jaringan, mana masalah aplikasi.