📵 🧚 🤞🏾 IPv6 - Anda salah melakukannya 🧝🏿 💙 👶🏿

Ada banyak kesalahpahaman dan mitos seputar IPv6. Seringkali, penyedia hosting salah paham bagaimana menggunakannya dan berpikir pendekatan usang dari dunia IPv4. Misalnya, memiliki octillions alamat IPv6, hoster menjual alamat ke klien secara individual, alih-alih mengalokasikan jaringan / 64 penuh, sebagai berikut dari rekomendasi.

Itu terjadi bahwa hosters menetapkan alamat IPv6 untuk klien yang berbeda dalam jaringan yang sama / 64 Pada saat yang sama, layanan besar, seperti Google, menganggap semua alamat dalam kisaran / 64 sebagai satu klien. Akibatnya, pelanggan mungkin menderita karena kegiatan bandmate.

Ketersediaan alamat IPv6 memungkinkan Anda untuk menetapkan alamat eksternal penuh ke sumber daya internal, seperti kontainer atau klien VPN. Untuk melakukan ini, tuan rumah harus menyediakan klien dengan jaringan diarahkan secara terpisah. Sayangnya, hampir tidak ada yang bisa melakukan ini.

Pada artikel ini, kami akan menganalisis kesalahan utama dalam penggunaan penyedia IPv6.

Alur cerita: RFC 3177

Pada tahun 2001, rekomendasi tentang alokasi alamat direkomendasikan (maaf untuk tautologi, ini penting) untuk digarisbawahi:

/ 48 secara umum
/ 64 jika di belakangnya satu dan hanya satu subnet
/ 128 jika satu dan hanya satu perangkat

Dokumen ofensif RFC 2119, yang mengatur penerapan berbagai tingkat kepatuhan wajib dengan instruksi, mendefinisikan "direkomendasikan" sebagai berikut:
Kata-kata "Harus" atau "Disarankan" berarti bahwa mungkin ada alasan yang masuk akal dalam keadaan tertentu untuk tidak bertindak dengan cara ini, namun demikian, pilihan jalur perilaku yang berbeda harus merupakan keputusan yang seimbang yang dibuat dengan pemahaman penuh tentang konsekuensinya.
Mungkin tidak ada yang memiliki pemahaman penuh tentang konsekuensi pada waktu itu, mungkin "keadaan tertentu" tidak didefinisikan, tetapi, dengan satu atau lain cara, semua orang mengikuti rekomendasi.

Secara umum, pada saat penulisan dokumen, lalu lintas IPv6 sangat jarang dan ditemukan, sebagian besar, di institut dan jaringan pribadi penggemar yang ingin tahu. Beberapa masalah nyata mulai terakumulasi dan dianalisis, tetapi butuh banyak waktu.
Memikirkan kembali dimulai pada tahun 2005. Akhirnya, rekomendasi ini tidak digunakan lagi pada tahun 2011.

Kesadaran akan masalah: RFC 6177

Kebijakan pengalamatan baru secara eksplisit menyatakan bahwa / 48 hanya sebuah keinginan, bukan persyaratan. Tidak ada indikasi angka tertentu yang diberikan, namun, diindikasikan bahwa / 64 atau lebih pendek bekerja dalam kondisi normal.

Logika utama dalam merekomendasikan ukuran penerbitan blok / 48 ke konsumen akhir mengejar tiga tujuan.

Pertama, ruang alamat yang ditugaskan harus memadai untuk tujuan konsumen dan mudah diperluas, tanpa squat barbell. Ya, persis seperti yang dikatakannya, hanya dalam versi bahasa Inggris - lompatlah melalui lingkaran. Salah satu alasan penting untuk beralih ke IPv6 adalah mengubah ukuran tujuan yang ada dari "alamat tunggal" menjadi "beberapa subnet."

Kedua, perubahan penyedia harus dilakukan dengan masalah minimal. Jika Anda dapat menyimpan skema alamat subnet lama saat pindah ke ruang alamat baru, maka ini akan menghemat banyak pekerjaan

. Ketiga, alokasi blok / 48 harus mencakup peningkatan kebutuhan ruang alamat dari konsumen yang sedang berkembang.

Meskipun semua kondisi ini terpenuhi, menjadi jelas bahwa rekomendasi / 48 adalah, secara sederhana, berlebihan.

Pin / 64 sebagai unit masalah

Selain urutan distribusi, ada poin lain. Ternyata banyak fitur IPv6 tidak berfungsi jika awalan jaringan tidak / 64. Yaitu, mereka tidak bekerja:

Neighbor Discovery (ND)
Secure Neighborship Discovery (SEND)
beberapa bagian Mobile IPv6
Situs Multihoming oleh Intermediasi IPv6
banyak hal kecil yang berbeda

Faktor tambahan adalah fakta bahwa banyak teknologi yang dirancang bergantung pada awalan jaringan.

Bukan hanya ancaman untuk melanggar standar yang baru ditemukan itu alasan untuk menulis rekomendasi baru. Dua pendapat tentang validitas yang meragukan juga sangat populer.
Pertama, banyak perangkat menerapkan routing IPv6 secara terprogram, dengan kruk dan sepeda, dan karenanya tidak siap untuk transisi penuh ke sana. Kemungkinan peningkatan penundaan karena ini dapat meningkat berkali-kali, jika bukan urutan besarnya. Definisi default dari subnet / 64 akan sangat mengurangi penundaan ini.

Kedua, beralih ke standar baru selalu menyulitkan dukungan teknis dan administrator sistem. Awalan tunggal / 64 seharusnya mengurangi rasa sakit ini ke nilai yang dapat diterima.

Situasi di garis depan

Seperti yang sudah terjadi sebelumnya pada tahun 2001, rekomendasi / 64 dianggap oleh banyak pemain Internet besar sebagai standar. Di satu sisi itu bagus, di sisi lain, tidak begitu baik.

Untuk banyak sistem peringkat, misalnya, untuk pengenalan spam, semua alamat dari satu blok akan dianggap milik satu spammer. Secara teori, ini seharusnya membuat hidup lebih mudah bagi pengguna, pada kenyataannya, justru sebaliknya.

Seringkali, penyedia tidak repot-repot dengan hal-hal seperti belajar tentang praktik umum. Alamat dapat dikeluarkan sesuai dengan prinsip apa pun, setidaknya bahkan menurut horoskop.

Ada beberapa masalah yang khas, dan semuanya berasal dari pelanggaran rekomendasi oleh penyedia di satu sisi, dan kepatuhan ketat kepada mereka oleh beberapa organisasi lain di sisi lain.
Mengeluarkan alamat dari satu blok ke beberapa pengguna dapat mengarah pada fakta bahwa mereka semua akan dianggap sebagai satu pengguna aktual, misalnya, mesin di jaringan organisasi.

Jika beberapa orang dari blok ini mulai mencari kucing secara bersamaan, Google dapat memutuskan bahwa botnet ini akan mengirimkan permintaan untuk penipuan pencarian atau beberapa hal lain yang tidak terlalu bagus. Dari sudut pandangnya, ini semua adalah satu pengguna. Hasil logisnya adalah captcha yang semakin rumit.

Ini, seperti yang Anda tahu, adalah jawaban paling tidak berbahaya untuk penipuan hipotetis.
Situasi sebaliknya adalah penerbitan ke satu pengguna alamat dari blok yang berbeda. Jika pengguna blok ini masuk ke daftar hitam seseorang, maka alamat pengguna yang jujur akan jatuh ke dalamnya. Kisah yang sangat menarik: beberapa alamat Anda diblokir oleh satu jaringan iklan, beberapa diblokir oleh yang lain.

Selain itu, kejutan tidak menyenangkan lainnya mungkin terjadi. Misalnya, Anda menerima blok / 64 untuk penggunaan Anda, tetapi ini adalah blok dinamis, sebagai alamat dinamis - hari ini 2001: DA8: 1D01: FA13 :: / 64, besok 2001: DA8: 1D01: FC15 :: / 64. Petualangan baru setiap hari!
Ada kemungkinan besar untuk bertemu berbagai kombinasi masalah ini dan garu lengkung fantastis lainnya di lampiran.

Terbitkan IPv6 dari server kami

Jika kita memiliki trilyun alamat IP, maka mengapa tidak memberikan alamat IP asli, misalnya, untuk klien VPN sehingga mereka pergi ke Internet tanpa NAT dan dapat menerima koneksi masuk dari dunia. Kedengarannya hebat, tetapi dalam praktiknya tidak mudah. Ini akan membutuhkan jaringan IPv6 terpisah yang dialihkan melalui alamat IP yang ditetapkan untuk antarmuka server.

Misalkan server diberi alamat 2a01:baba::c0fee:dead/64, maka klien VPN akan membutuhkan jaringan terpisah, seperti 2a01:baba:fafa:0f0f::/64dialihkan melalui alamat tersebut 2a01:baba::c0fee:dead/64.

Sayangnya, sangat sedikit penyedia hosting memiliki alat untuk mengeluarkan jaringan seperti itu kepada klien, itulah sebabnya Anda harus menggunakan kruk seperti ND Proxy .

Kesimpulan

Membaca rekomendasi IETF bukanlah kegiatan yang paling menarik, tetapi sangat bermanfaat. Mengisi mereka dengan malam musim dingin yang panjang jelas tidak sepadan, tetapi juga mengabaikan membaca bagian yang penting bagi Anda juga tidak diinginkan.

Saat memilih penyedia, pastikan ia berbagi sudut pandang ini.

Anda harus memahami bahwa pendekatan yang salah dalam alokasi alamat tidak membahayakan penyedia, dan untuk sebagian besar kontrak bahkan tidak dapat menjadi dasar untuk kompensasi.
Namun, ini mungkin menjadi faktor kunci bagi Anda, meskipun Anda sendiri belum curiga.