Apa yang dirundingkan IPv6CP dan apa yang masih perlukan prefiks
Alamat link-local pada antara muka PPP ialah langkah persediaan, bukan akses IPv6. Asingkan pertukaran pengecam daripada prefiks, laluan dan integrasi klien.
IPv6 timbul pada antara muka PPP, alamat link-local muncul, dan perubahan diisytiharkan selesai. Kemudian tiada apa dilalukan, tiada alamat global, dan ujian ke destinasi awam gagal sementara antara muka masih kelihatan dikonfigurasikan. Pautan timbul; rangkaian tidak pernah. Lakukan empat semakan di bawah mengikut urutan dan berhenti pada yang menjelaskan jurang itu.
Apa yang sebenarnya dibuktikan oleh alamat link-local
IPv6CP menaikkan IPv6 pada pautan PPP dan merundingkan pengecam antara muka untuk setiap pihak. Pengecam itu menghasilkan alamat link-local, yang cukup untuk bercakap dengan rakan melalui pautan dan tidak cukup untuk mencapai apa-apa lagi. Alamat itu membuktikan pautan sedia untuk IPv6, dan ia tidak membuktikan apa-apa tentang rangkaian di sebalik rakan. Membacanya sebagai alamat akses ialah kesilapan yang memulakan kebanyakan siasatan ini.
Empat soalan di bawah memisahkan apa yang diputuskan lapisan pautan daripada apa yang perlu dibekalkan oleh perkhidmatan. Jawab mengikut urutan, kerana soalan kemudian tidak dapat dijawab selagi soalan terdahulu 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 mesti datang
Alamat global memerlukan prefiks dari suatu tempat: pengumuman penghala, prefiks yang diwakilkan, DHCPv6 atau konfigurasi statik. IPv6CP tidak membawa satu pun, dan tidak berapa lama menunggu pada pautan akan menghasilkannya. RFC 5072 meletakkan IPv6CP sebagai langkah persediaan yang berjalan sebelum protokol IPv6 lain beroperasi pada pautan, dan itulah keseluruhan skopnya: menyediakan pautan, bukan menombori rangkaian. Bekalkan prefiks itu dan antara muka mula membawa trafik dan bukannya sekadar wujud.
Pengumuman penghala ialah jawapan biasa pada LAN dan kurang boleh dipercayai pada terowong titik ke titik, kerana klien perlu menghantar permintaan dan menerima jawapan. Sesetengah klien terowong tidak melakukan kedua-duanya. Semak apa yang klien sanggup terima sebelum memutuskan pelayan harus menghantarnya.
Prefiks yang sama mesti boleh dicapai dari hujung yang lain. Klien yang memegang alamat global tetapi tiada laluan pulang sudah dikonfigurasikan, bukan bersambung.
Laluan ialah janji berasingan
Walaupun dengan alamat, klien perlu tahu destinasi mana yang tergolong dalam terowong, dan pelayan perlu laluan pulang untuk destinasi itu. Itu dua keputusan di dua tempat. Terowong yang membawa semua trafik IPv6 memerlukan laluan lalai pada klien dan laluan pulang pada pelayan; terowong berpecah memerlukan kedua-dua pihak bersetuju pada senarai prefiks yang sama. Apabila mereka tidak bersetuju, trafik keluar dan tidak pernah kembali.
Tulis senarai itu sebelum mengkonfigurasi apa-apa. Jika pelan mengatakan hanya prefiks korporat melalui terowong, klien tidak sepatutnya mempunyai laluan IPv6 lalai, dan pelayan tidak sepatutnya mengumumkannya.
Integrasi klien menentukan selebihnya
Sesetengah klien terowong mengkonfigurasi IPv6 secara eksplisit. Network Extension Apple, contohnya, mengambil alamat, prefiks dan satu set laluan untuk terowong, jadi aplikasi yang menggunakannya tidak menunggu pengumuman gaya Ethernet. Yang lain bergantung pada pengumuman penghala yang tiba melalui pautan. Kedua-dua model sah dan memerlukan tingkah laku pelayan yang berbeza, jadi pilihan yang salah menghasilkan klien yang menunggu selama-lamanya mesej yang tiada siapa hantar. Kenal pasti model sebelum menukar pelayan.
Nama antara muka lama seperti ppp0 tidak membuktikan apa-apa tentang timbunan yang berjalan hari ini. Klien moden boleh menggunakan API terowong paket dan bukannya antara muka PPP, dan menganggapnya berkelakuan seperti sambungan sejarah ialah cara reka bentuk yang berfungsi dipecahkan. Tanya versi klien dan kaedah peruntukan, bukan nama antara muka.
Tulis pelan yang diperlukan klien
Keterangan lengkap merangkumi tiga perkara: alamat apa yang dipegang klien, destinasi mana yang harus dibawa terowong dan bagaimana rangkaian menghantar balasan. Alamat link-local tidak menjawab satu pun, dan pengumuman yang diterima hanya menjawab sebahagian daripada satu. Semak setiap perkara secara berasingan dan bukannya menerima penunjuk hijau. Kemudian catat mekanisme mana yang membekalkan setiap jawapan, kerana catatan itu menjadikan laporan IPv6 seterusnya sebagai semakan dua minit.
Simpan catatan itu bersama dokumentasi perkhidmatan dan kemas kini apabila klien berubah. Pelan yang betul untuk klien PPP mungkin salah untuk klien terowong paket pada perkhidmatan yang sama. Empat soalan kekal sama; hanya jawapannya berubah.