تجزئة 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، وهو قراءة أقصر من الحادث الذي يمنعه.
اختبر العائلة التي يستخدمها التطبيق فعلاً، لأن اسماً ثنائي المكدس قد يستجيب على عائلة ولا يستجيب على الأخرى، وقد يبدّل التطبيق بعد تغيّر الشبكة. وسجّل العنوان الذي اختبرته، لأن نتيجة مقابل سجل A لا تقول شيئاً عن سجل AAAA.
تعامل مع حدّ الحجم كدليل
حدّ الحجم القابل للتكرار هو واحد من الأعطال الشبكية القليلة التي تتكرّر بدقة، بالعدد نفسه من البايتات، من المصدر نفسه، في كل مرة. وهذا يجعله هدية وليس لغزاً، ويعني أيضاً أن الإصلاح يمكن التحقق منه بدلاً من الأمل فيه.
اكتب في التذكرة MTU المكتشف وMTU النفق الذي ضبطته والاختبار الذي أثبت الفرق. وسيلتقي الشخص التالي بالحساب نفسه على وصلة مختلفة.