Apa yang dinegosiasikan IPv6CP, dan apa yang masih butuh prefiks
Alamat link-local pada antarmuka PPP adalah langkah penyiapan, bukan akses IPv6. Pisahkan pertukaran pengenal dari prefiks, rute, dan integrasi klien.
IPv6 muncul di antarmuka PPP, alamat link-local muncul, dan perubahan dinyatakan selesai. Lalu tidak ada yang dirutekan, tidak ada alamat global, dan uji ke tujuan publik gagal sementara antarmuka masih tampak terkonfigurasi. Tautan sudah naik; jaringan tidak pernah. Jalankan keempat pemeriksaan di bawah secara berurutan dan berhenti pada yang menjelaskan celahnya.
Apa yang sebenarnya dibuktikan alamat link-local
IPv6CP menaikkan IPv6 pada tautan PPP dan menegosiasikan pengenal antarmuka untuk tiap sisi. Pengenal itu menghasilkan alamat link-local, yang cukup untuk berbicara dengan rekan melalui tautan dan tidak cukup untuk menjangkau apa pun yang lain. Alamat itu membuktikan tautan siap untuk IPv6, dan tidak membuktikan apa pun tentang jaringan di balik rekan. Membacanya sebagai alamat akses adalah kesalahan yang memulai sebagian besar penyelidikan semacam ini.
Keempat pertanyaan di bawah memisahkan apa yang diputuskan lapisan tautan dari apa yang harus disediakan layanan. Jawablah secara berurutan, karena pertanyaan berikutnya tidak dapat dijawab selama pertanyaan sebelumnya masih terbuka.
| Question | Answered by | What it does not settle |
|---|---|---|
| Is IPv6 up on the link? | IPv6CP: interface identifiers, then link-local addresses | Any address reachable beyond the peer |
| Where does a global prefix come from? | Router advertisement, delegated prefix, DHCPv6 or static configuration | IPv6CP carries no prefix of its own |
| Who owns the routes? | The client's tunnel configuration and the server's return path | A link-local address implies no route at all |
| How does this client get configured? | Explicit tunnel settings or router advertisements, depending on the client | The standard does not choose for the implementation |
Dari mana prefiks harus datang
Alamat global membutuhkan prefiks dari suatu tempat: pengumuman router, prefiks yang didelegasikan, DHCPv6, atau konfigurasi statis. IPv6CP tidak membawa prefiks, dan berapa lama pun menunggu di tautan tidak akan menghasilkannya. RFC 5072 menempatkan IPv6CP sebagai langkah penyiapan yang berjalan sebelum protokol IPv6 lain beroperasi di tautan, dan itulah seluruh cakupannya: menyiapkan tautan, bukan menomori jaringan. Sediakan prefiksnya dan antarmuka mulai membawa lalu lintas alih-alih hanya ada.
Pengumuman router adalah jawaban umum di LAN dan kurang andal di terowongan titik-ke-titik, karena klien harus mengirim permintaan sekaligus menerima jawabannya. Sebagian klien terowongan tidak melakukan keduanya. Periksa apa yang bersedia diterima klien sebelum memutuskan server harus mengirimkannya.
Prefiks yang sama harus dapat dijangkau dari ujung lain. Klien yang memegang alamat global tetapi tidak punya jalur balik sudah terkonfigurasi, bukan terhubung.
Rute adalah janji terpisah
Bahkan dengan alamat, klien perlu tahu tujuan mana yang termasuk terowongan, dan server perlu jalur balik untuk tujuan itu. Itu dua keputusan di dua tempat. Terowongan yang membawa seluruh lalu lintas IPv6 memerlukan rute bawaan di klien dan rute balik di server; terowongan terpisah menuntut kedua sisi menyepakati daftar prefiks yang sama. Bila tidak sepakat, lalu lintas keluar dan tidak pernah kembali.
Tuliskan daftarnya sebelum mengonfigurasi apa pun. Jika rencana mengatakan hanya prefiks perusahaan yang lewat terowongan, klien tidak boleh punya rute IPv6 bawaan, dan server tidak boleh mengumumkannya.
Integrasi klien menentukan sisanya
Sebagian klien terowongan mengonfigurasi IPv6 secara eksplisit. Network Extension dari Apple, misalnya, mengambil alamat, prefiks, dan sekumpulan rute untuk terowongan, sehingga aplikasi yang memakainya tidak menunggu pengumuman bergaya Ethernet. Yang lain bergantung pada pengumuman router yang tiba melalui tautan. Kedua model sah dan menuntut perilaku server berbeda, sehingga pilihan yang salah menghasilkan klien yang menunggu selamanya pesan yang tidak dikirim siapa pun. Kenali modelnya sebelum mengubah server.
Nama antarmuka lama seperti ppp0 tidak membuktikan apa pun tentang tumpukan yang berjalan hari ini. Klien modern dapat memakai API terowongan paket alih-alih antarmuka PPP, dan menganggapnya berperilaku seperti koneksi historis adalah cara merusak rancangan yang berfungsi. Tanyakan versi klien dan metode penyediaan, bukan nama antarmuka.
Tuliskan rencana yang dibutuhkan klien
Deskripsi lengkap mencakup tiga hal: alamat apa yang dipegang klien, tujuan mana yang harus dibawa terowongan, dan bagaimana jaringan mengirim balasan. Alamat link-local tidak menjawab satu pun, dan pengumuman yang diterima hanya menjawab sebagian dari satu. Periksa tiap butir secara terpisah alih-alih menerima indikator hijau. Lalu catat mekanisme mana yang memasok tiap jawaban, karena catatan itu mengubah laporan IPv6 berikutnya menjadi pemeriksaan dua menit.
Simpan catatan itu bersama dokumentasi layanan dan perbarui saat klien berubah. Rencana yang benar untuk klien PPP bisa salah untuk klien terowongan paket pada layanan yang sama. Keempat pertanyaan tetap sama; hanya jawabannya yang bergeser.