IPv6CP ต่อรองอะไร และอะไรยังต้องใช้คำนำหน้า
ที่อยู่ link-local บนอินเทอร์เฟซ PPP เป็นขั้นตอนการตั้งค่า ไม่ใช่การเข้าถึง IPv6 แยกการแลกเปลี่ยนตัวระบุออกจากคำนำหน้า เส้นทาง และการเชื่อมต่อไคลเอนต์
IPv6 ขึ้นบนอินเทอร์เฟซ PPP ที่อยู่ link-local ปรากฏขึ้น และการเปลี่ยนแปลงถูกประกาศว่าเสร็จสิ้น จากนั้นไม่มีอะไรถูกกำหนดเส้นทาง ไม่มีที่อยู่ทั่วโลก และการทดสอบไปยังปลายทางสาธารณะล้มเหลวในขณะที่อินเทอร์เฟซยังดูเหมือนถูกกำหนดค่าแล้ว ลิงก์ขึ้นแล้ว แต่เครือข่ายไม่เคยขึ้น ทำการตรวจสอบสี่ข้อด้านล่างตามลำดับและหยุดที่ข้อซึ่งอธิบายช่องว่าง
ที่อยู่ link-local พิสูจน์อะไรได้จริง
IPv6CP ทำให้ IPv6 ขึ้นบนลิงก์ PPP และต่อรองตัวระบุอินเทอร์เฟซสำหรับแต่ละฝั่ง ตัวระบุดังกล่าวสร้างที่อยู่ link-local ซึ่งเพียงพอต่อการพูดคุยกับคู่ผ่านลิงก์ และไม่เพียงพอต่อการเข้าถึงสิ่งอื่นใด ที่อยู่พิสูจน์ว่าลิงก์พร้อมสำหรับ IPv6 และไม่ได้พิสูจน์สิ่งใดเกี่ยวกับเครือข่ายหลังคู่ การอ่านมันเป็นที่อยู่สำหรับเข้าถึงคือข้อผิดพลาดที่การสอบสวนเหล่านี้ส่วนใหญ่เริ่มต้น
คำถามสี่ข้อด้านล่างแยกสิ่งที่ชั้นลิงก์ตัดสินออกจากสิ่งที่บริการต้องจัดหา ตอบตามลำดับ เพราะยังตอบคำถามหลังจากไม่ได้ตราบใดที่คำถามก่อนหน้ายังเปิดอยู่
| 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 |
คำนำหน้าต้องมาจากไหน
ที่อยู่ทั่วโลกต้องมีคำนำหน้าจากที่ใดที่หนึ่ง การประกาศจากเราเตอร์ คำนำหน้าที่มอบหมาย DHCPv6 หรือการกำหนดค่าแบบคงที่ IPv6CP ไม่ได้พาคำนำหน้าใดมา และการรอคอยบนลิงก์ไม่ว่าจะนานเท่าใดก็ไม่ทำให้เกิด RFC 5072 วาง IPv6CP เป็นขั้นตอนการตั้งค่าที่ทำงานก่อนโปรโตคอล IPv6 อื่นจะทำงานบนลิงก์ และนั่นคือขอบเขตทั้งหมดของมัน คือการเตรียมลิงก์ ไม่ใช่การกำหนดเลขให้เครือข่าย จัดหาคำนำหน้าแล้วอินเทอร์เฟซจะเริ่มพาการรับส่งข้อมูลแทนที่จะเพียงมีอยู่
การประกาศจากเราเตอร์เป็นคำตอบทั่วไปใน LAN และเชื่อถือได้น้อยกว่าในอุโมงค์แบบจุดต่อจุด เพราะไคลเอนต์ต้องส่งคำขอและยอมรับคำตอบไปพร้อมกัน ไคลเอนต์อุโมงค์บางตัวไม่ทำทั้งสองอย่าง ตรวจสอบว่าไคลเอนต์ยอมรับอะไรได้ก่อนตัดสินใจว่าเซิร์ฟเวอร์ควรส่งมัน
คำนำหน้าเดียวกันต้องเข้าถึงได้จากอีกปลายหนึ่ง ไคลเอนต์ที่มีที่อยู่ทั่วโลกแต่ไม่มีเส้นทางกลับถูกกำหนดค่าแล้ว ไม่ได้เชื่อมต่อ
เส้นทางเป็นสัญญาแยกต่างหาก
แม้มีที่อยู่ ไคลเอนต์ต้องรู้ว่าปลายทางใดอยู่ในอุโมงค์ และเซิร์ฟเวอร์ต้องมีเส้นทางกลับสำหรับปลายทางเหล่านั้น นี่คือการตัดสินใจสองอย่างในสองที่ อุโมงค์ที่พาการรับส่ง IPv6 ทั้งหมดต้องมีเส้นทางเริ่มต้นบนไคลเอนต์และเส้นทางกลับบนเซิร์ฟเวอร์ อุโมงค์แบบแบ่งต้องให้ทั้งสองฝั่งตกลงในรายการคำนำหน้าเดียวกัน เมื่อไม่ตรงกัน การรับส่งจะออกไปและไม่กลับมาอีก
เขียนรายการก่อนกำหนดค่าใด ๆ ถ้าแผนบอกว่ามีเพียงคำนำหน้าองค์กรผ่านอุโมงค์ ไคลเอนต์ไม่ควรมีเส้นทาง IPv6 เริ่มต้น และเซิร์ฟเวอร์ไม่ควรประกาศมัน
การเชื่อมต่อไคลเอนต์ตัดสินส่วนที่เหลือ
ไคลเอนต์อุโมงค์บางตัวกำหนดค่า IPv6 อย่างชัดเจน ตัวอย่างเช่น Network Extension ของ Apple รับที่อยู่ คำนำหน้า และชุดเส้นทางสำหรับอุโมงค์ ดังนั้นแอปพลิเคชันที่ใช้มันจึงไม่รอการประกาศแบบ Ethernet ไคลเอนต์อื่นพึ่งพาการประกาศจากเราเตอร์ที่มาทางลิงก์ ทั้งสองแบบถูกต้องและต้องการพฤติกรรมเซิร์ฟเวอร์ที่ต่างกัน ดังนั้นการเลือกผิดจะทำให้เกิดไคลเอนต์ที่รอข้อความซึ่งไม่มีใครส่งตลอดไป ระบุแบบก่อนเปลี่ยนเซิร์ฟเวอร์
ชื่ออินเทอร์เฟซเก่าเช่น ppp0 ไม่ได้พิสูจน์สิ่งใดเกี่ยวกับสแตกที่ทำงานวันนี้ ไคลเอนต์สมัยใหม่อาจใช้ API อุโมงค์แพ็กเก็ตแทนอินเทอร์เฟซ PPP และการสมมติว่ามันทำงานเหมือนการเชื่อมต่อในอดีตคือวิธีทำให้การออกแบบที่ใช้งานได้พัง ถามเวอร์ชันไคลเอนต์และวิธีการจัดหา ไม่ใช่ชื่ออินเทอร์เฟซ
เขียนแผนที่ไคลเอนต์ต้องการ
คำอธิบายที่สมบูรณ์ครอบคลุมสามสิ่ง ไคลเอนต์มีที่อยู่ใด อุโมงค์ควรพาปลายทางใด และเครือข่ายส่งคำตอบกลับอย่างไร ที่อยู่ link-local ไม่ตอบข้อใดเลย และการประกาศที่ยอมรับแล้วตอบเพียงส่วนหนึ่งของข้อเดียว ตรวจสอบแต่ละรายการแยกกันแทนที่จะยอมรับสัญญาณสีเขียว จากนั้นบันทึกว่ากลไกใดให้คำตอบแต่ละข้อ เพราะบันทึกนั้นทำให้รายงาน IPv6 ครั้งถัดไปเป็นการตรวจสอบสองนาที
เก็บบันทึกไว้กับเอกสารบริการและอัปเดตเมื่อไคลเอนต์เปลี่ยน แผนที่ถูกต้องสำหรับไคลเอนต์ PPP อาจผิดสำหรับไคลเอนต์อุโมงค์แพ็กเก็ตบนบริการเดียวกัน คำถามทั้งสี่เหมือนเดิม มีแต่คำตอบที่เคลื่อนที่