IPv4 แบ่งแพ็กเก็ตระหว่างทาง ส่วน IPv6 ส่งข้อความว่าแพ็กเก็ตใหญ่เกินไปแทน
มีเพียงเราเตอร์ IPv4 เท่านั้นที่แบ่งแพ็กเก็ตที่ใหญ่เกินไปได้ IPv6 คาดว่าผู้ส่งจะตอบสนองต่อข้อความว่าแพ็กเก็ตใหญ่เกินไป ซึ่งอุโมงค์หรือกฎ ICMP ที่ถูกกรองอาจทำให้เสียได้
ความล้มเหลวของ IPv6 มักถูกโทษที่โปรโตคอลมากกว่าที่ขนาดแพ็กเก็ตที่เป็นสาเหตุ ทั้งสองตระกูลจัดการแพ็กเก็ตที่ใหญ่เกินไปต่างกันจริง และอุโมงค์คือสิ่งที่ทำให้ความต่างนั้นสำคัญ เราเตอร์ IPv4 แบ่งแพ็กเก็ตได้เมื่อกฎอนุญาต ขณะที่เราเตอร์ IPv6 ต้องไม่แบ่งระหว่างทางเลย IPv6 จะบอกผู้ส่งแทน และคาดว่าผู้ส่งจะตอบสนอง ทุกสิ่งที่จะผิดพลาดหลังจากนั้นขึ้นอยู่กับว่าข้อความนั้นไปถึงหรือไม่
แต่ละตระกูลทำอะไร
ตารางคือกลไกในสี่บรรทัด และหนึ่งแถวอธิบายความสับสนส่วนใหญ่
| 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 ไม่มีการแบ่งระหว่างทางและไม่มีแฟล็ก DF ที่ต้องล้าง จึงไม่มีอะไรให้พึ่งเมื่อแพ็กเก็ตใหญ่เกินไป ต้องบอกผู้ส่ง และผู้ส่งต้องเชื่อ
อุโมงค์ทำให้เส้นทางแคบลงอย่างเงียบ ๆ
VPN เพิ่มหัวข้อภายนอก และในกรณีที่เข้ารหัสก็เพิ่มข้อมูลความสมบูรณ์ด้วย ก่อนที่แพ็กเก็ตจะออกจากโฮสต์ แพ็กเก็ตภายในอาจพอดีกับ MTU ของอินเทอร์เฟซที่มองเห็น ขณะที่แพ็กเก็ตภายนอกเกินขีดจำกัดของลิงก์ถัดไป จึงเป็นเหตุให้เรื่องนี้ปรากฏก่อนในอุโมงค์ ลด MTU ของอินเทอร์เฟซอุโมงค์อย่างตั้งใจ หรือรัด TCP MSS ตามเส้นทาง แล้วบันทึกว่าคุณเลือกตัวเลขใดและเพราะอะไร
ภาระส่วนหัวของ ESP ขึ้นอยู่กับโหมดและอัลกอริทึม ดังนั้น MTU อุโมงค์ที่ถูกต้องคือการคำนวณ ไม่ใช่ธรรมเนียม สิ่งที่คุณเลือกต้องเหลือที่ว่างสำหรับแพ็กเก็ต IPv6 ภายในขนาดเต็ม 1280 ไบต์ เพราะทุกลิงก์ IPv6 ต้องรองรับขนาดนั้น อุโมงค์ที่ไม่สามารถรองรับ 1280 ไบต์ของ IPv6 ไม่ใช่ปัญหาเรื่องการปรับแต่ง แต่เป็นเส้นทางที่แตกหักสำหรับตระกูลนั้น ข้อจำกัดนี้เองที่หายไปเมื่อคัดลอกค่า MTU จากระบบที่ใช้เฉพาะ IPv4
ทำไมอาการจึงดูเหมือนค้าง
ความล้มเหลวไม่ใช่ข้อผิดพลาดที่สะอาด จึงถูกวินิจฉัยผิด การจับมือ TCP สำเร็จ คำตอบเล็ก ๆ มาถึง และการเชื่อมต่อหยุดทันทีเมื่อคำตอบใหญ่หรือการอัปโหลดใหญ่เริ่ม เพราะนั่นคือแพ็กเก็ตแรกที่ใหญ่พอจะถูกทิ้ง SSH เชื่อมต่อได้แล้วค้างที่ผลลัพธ์ใหญ่ครั้งแรก และส่วนหัวของหน้าจะโหลดได้แต่เนื้อหาไม่เคยเสร็จ
ถ้าข้อความแพ็กเก็ตใหญ่เกินไปของ ICMPv6 ถูกกรอง ผู้ส่งจะไม่มีทางรู้และพยายามขนาดเดิมซ้ำ ๆ นั่นคือหลุมดำไม่ใช่เส้นทางช้า และลายเซ็นของมันคือขอบเขตขนาดที่เกิดซ้ำได้ ไม่ใช่การสูญเสียแบบสุ่ม การอนุญาตทราฟฟิกควบคุมที่เกี่ยวข้องเป็นส่วนหนึ่งของการติดตั้ง IPv6 ที่ทำงานได้ ไม่ใช่ความเอื้อเฟื้อ
อย่าปิดข้อความที่เส้นทางของคุณเองพึ่งพาแล้วอธิบายผลลัพธ์ว่าเป็นข้อบกพร่องของ IPv6 ข้อโต้แย้งเดียวกันใช้กับข้อความ Fragmentation Needed ของ IPv4 ซึ่งไม่เป็นที่นิยมในหมู่นักเขียนไฟร์วอลล์เช่นกันและจำเป็นเช่นกัน
วัดขอบเขตแล้วจึงแก้ไขชั้นที่เกี่ยวข้อง
ตรวจสอบแทนการเดา ใช้แฟล็ก don't-fragment บน IPv4 และขนาดเพย์โหลดคงที่บน IPv6 และบันทึกว่าคำตอบหยุดที่ใด ping -M do -s 1472 และ ping -6 -s 1400 ก็เพียงพอที่จะกำหนดรูปร่างของปัญหา และ tracepath รายงาน MTU เส้นทางที่ค้นพบระหว่างทาง
จากนั้นแก้ไขชั้นที่เป็นเจ้าของตัวเลขนั้น คือ MTU ของอินเทอร์เฟซอุโมงค์ การรัด MSS สำหรับ TCP หรือเส้นทางเอง RFC 8200 เป็นเอกสารอ้างอิงสำหรับกฎของ IPv6 และอ่านสั้นกว่าเหตุการณ์ที่มันป้องกัน
ทดสอบตระกูลที่แอปพลิเคชันใช้จริง เพราะชื่อแบบ dual-stack อาจตอบได้ในตระกูลหนึ่งและไม่ได้ในอีกตระกูลหนึ่ง และแอปพลิเคชันอาจสลับหลังการเปลี่ยนแปลงเครือข่าย บันทึกที่อยู่ที่คุณทดสอบ เพราะผลลัพธ์กับระเบียน A ไม่ได้บอกอะไรเกี่ยวกับระเบียน AAAA
ถือว่าขอบเขตขนาดเป็นหลักฐาน
ขอบเขตขนาดที่เกิดซ้ำได้เป็นหนึ่งในความผิดพลาดของเครือข่ายไม่กี่อย่างที่จำลองได้อย่างแม่นยำ ด้วยจำนวนไบต์เดิม จากแหล่งเดิม ทุกครั้ง นั่นทำให้มันเป็นของขวัญไม่ใช่ปริศนา และยังหมายความว่าการแก้ไขสามารถตรวจสอบได้แทนที่จะหวัง
เขียน MTU ที่ค้นพบ MTU อุโมงค์ที่คุณกำหนดค่า และการทดสอบที่พิสูจน์ความต่างลงในตั๋ว คนถัดไปจะพบเลขคณิตเดียวกันบนลิงก์อื่น