IPv4 memfragmentasi saat transit; IPv6 mengirim pesan paket terlalu besar sebagai gantinya
Hanya router IPv4 yang boleh memfragmentasi paket kebesaran. IPv6 mengharapkan pengirim bereaksi terhadap pesan paket terlalu besar, yang bisa dirusak oleh terowongan atau aturan ICMP yang difilter.
Kegagalan IPv6 jauh lebih sering disalahkan pada protokolnya daripada pada ukuran paket yang menyebabkannya. Kedua keluarga benar-benar menangani paket kebesaran secara berbeda, dan terowonganlah yang membuat perbedaan itu penting. Router IPv4 boleh memfragmentasi paket bila aturan mengizinkan, sedangkan router IPv6 tidak boleh memfragmentasi saat transit sama sekali. IPv6 memberitahunya kepada pengirim, dan pengirim diharapkan bereaksi. Semua yang salah setelahnya bergantung pada apakah pesan itu sampai.
Apa yang dilakukan tiap keluarga
Tabelnya adalah mekanismenya dalam empat baris, dan satu baris menjelaskan sebagian besar kebingungan.
| Behaviour | IPv4 | IPv6 |
|---|---|---|
| Router fragments an oversized packet | Allowed while DF is clear | Never |
| Signal returned to the sender | ICMP Fragmentation Needed | ICMPv6 Packet Too Big |
| Size that must always work | 68 bytes | 1280 bytes |
| Fragmentation possible | Routers or source | Source only |
IPv6 tidak punya fragmentasi saat transit dan tidak punya flag DF untuk dibersihkan, jadi tidak ada yang bisa dijadikan cadangan saat paket terlalu besar. Pengirim harus diberi tahu, dan pengirim harus memercayainya.
Terowongan menyempitkan jalur tanpa suara
VPN menambahkan header luar, dan pada kasus terenkripsi juga data integritas, sebelum paket meninggalkan host. Paket dalam bisa muat di MTU antarmuka yang dilihatnya sementara paket luar melebihi batas tautan berikutnya, dan itulah sebabnya hal ini muncul pertama kali di terowongan. Turunkan MTU antarmuka terowongan dengan sengaja, atau kencangkan TCP MSS di jalur, dan tuliskan angka yang Anda pilih serta alasannya.
Overhead ESP bergantung pada mode dan algoritme, jadi MTU terowongan yang tepat adalah perhitungan, bukan kebiasaan. Apa pun yang Anda pilih, nilainya harus menyisakan ruang untuk paket IPv6 dalam berukuran penuh 1280 byte, karena setiap tautan IPv6 wajib membawa sebanyak itu. Terowongan yang tidak bisa membawa 1280 byte IPv6 bukan masalah penyetelan; itu jalur rusak bagi keluarga itu. Kendala itulah yang hilang ketika nilai MTU disalin dari penerapan yang hanya IPv4.
Mengapa gejalanya berupa macet
Kegagalannya bukan kesalahan bersih, dan itulah sebabnya salah didiagnosis. Handshake TCP selesai, respons kecil tiba, dan koneksi macet begitu respons besar atau unggahan besar dimulai, karena itulah paket pertama yang cukup besar untuk dibuang. SSH tersambung lalu macet pada keluaran besar pertama, dan header halaman termuat sementara isinya tidak pernah selesai.
Jika pesan paket terlalu besar dari ICMPv6 difilter, pengirim tidak pernah tahu dan terus mengulangi ukuran yang sama. Itu lubang hitam, bukan jalur lambat, dan tandanya adalah batas ukuran yang berulang, bukan kehilangan acak. Membiarkan lalu lintas kendali yang relevan tetap diizinkan adalah bagian dari penerapan IPv6 yang berfungsi, bukan kebaikan.
Jangan menonaktifkan pesan yang menjadi tempat bergantung jalur Anda sendiri lalu menggambarkan hasilnya sebagai kesalahan IPv6. Argumen yang sama berlaku untuk pesan Fragmentation Needed milik IPv4, yang sama-sama tidak populer di kalangan penulis firewall dan sama-sama diperlukan.
Ukur batasnya, lalu perbaiki lapisannya
Periksa alih-alih menebak: gunakan flag don't-fragment pada IPv4 dan ukuran muatan tetap pada IPv6, dan catat di mana balasan berhenti. ping -M do -s 1472 dan ping -6 -s 1400 cukup untuk menetapkan bentuk masalahnya, dan tracepath melaporkan MTU jalur yang ditemukan di sepanjang jalan.
Lalu perbaiki lapisan yang memiliki angka itu: MTU antarmuka terowongan, penjepitan MSS untuk TCP, atau jalurnya sendiri. RFC 8200 adalah rujukan untuk aturan IPv6, dan bacanya lebih singkat daripada insiden yang dicegahnya.
Uji keluarga yang benar-benar dipakai aplikasi, karena nama tumpuk ganda bisa menjawab pada satu keluarga dan tidak pada yang lain, dan aplikasi bisa berpindah setelah perubahan jaringan. Catat alamat yang Anda uji, karena hasil terhadap record A tidak mengatakan apa pun tentang record AAAA.
Perlakukan batas ukuran sebagai bukti
Batas ukuran yang berulang adalah salah satu dari sedikit gangguan jaringan yang mereproduksi persis, pada jumlah byte yang sama, dari sumber yang sama, setiap kali. Itu menjadikannya hadiah, bukan misteri, dan juga berarti perbaikan bisa diverifikasi alih-alih diharapkan.
Tuliskan MTU yang ditemukan, MTU terowongan yang Anda konfigurasi, dan uji yang membuktikan perbedaannya ke dalam tiket. Orang berikutnya akan bertemu aritmetika yang sama di tautan lain.