الخلاصة

  • في حزمة IPv6 عملاقة، يحيل الصفر في Payload Length بالرأس الأساسي إلى خيار Jumbo Payload داخل رأس Hop-by-Hop التالي مباشرة.
  • يسجل الخيار الطول الفعلي في 32 بتاً، ولا يصح إلا لقيمة تتجاوز 65,535 ثمانية؛ لذلك لا يثبت الصفر وحده فراغ الحزمة ولا سلامة بنيتها.
  • صحة ترتيب الرؤوس لا تضمن أن كل وصلة أو نفق في المسار قادر على النقل، كما أن غياب خطأ ICMPv6 لا يثبت التسليم.

الصفر علامة انتقال لا مقداراً

رأس IPv6 الأساسي ثابت الطول عند 40 ثمانية، ويخصص 16 بتاً فقط لخانة Payload Length. في الحالة المعتادة، تحسب الخانة كل ما يلي الرأس الأساسي، بما في ذلك رؤوس الامتداد. وينتهي مجالها عند 65,535. لم توسع RFC 2675 الرأس الذي تحمله جميع الحزم من أجل حالة نادرة؛ بل استخدمت الصفر كقيمة حارسة ونقلت المقدار إلى خيار أوسع.

لكن هذا المعنى مشروط بالسياق. عندما يكون الطول الأساسي صفراً، وتشير Next Header إلى Hop-by-Hop Options، وتوجد بايتات بعد رأس IPv6، فعلى العقدة معالجة رأس الخيارات. هناك يعطي Jumbo Payload Length قيمة غير موقعة من 32 بتاً تشمل رؤوس الامتداد وبيانات الطبقات الأعلى بعد الرأس الأساسي، ولا تشمل الأربعين ثمانية الخاصة به، ويجب أن تزيد على 65,535.

وعليه، فإن سجل الحادث الذي يحتفظ بعبارة «Payload Length = 0» فقط قد حفظ الإحالة وحذف جوابها. يلزم أيضاً توثيق Next Header، ووجود الخيار وموضعه وقيمته، وعدد البايتات التي التقطتها أداة الرصد بالفعل. وإذا كانت اللقطة مبتورة بحد أقصى قصير، فقد يكون النقص في ملف الرصد لا في الحزمة المارة على الشبكة.

الدليل في اتساق الزوج

تحدد RFC 2675 التركيبات المرفوضة بدقة. طول أساسي صفري مع رأس Hop-by-Hop لا يحتوي خيار Jumbo خطأ. ووجود الخيار مع طول أساسي غير صفري خطأ آخر. كما أن قيمة Jumbo الأقل من 65,536 غير صالحة، ولا يجوز الجمع بين خيار Jumbo ورأس Fragment في الحزمة نفسها.

هذه الحدود تجعل وحدة الإثبات علاقة بين الحقول. يسلم الصفر سلطة تفسير الطول إلى الخيار، ويرد الخيار بالعدد، ثم يثبت ترتيب الرؤوس أن التسليم جرى في الموضع الصحيح. محلل يساوي كل صفر بحمولة فارغة سيحجب حزماً عملاقة سليمة؛ ومحلل يقبل كل صفر على أنه حزمة عملاقة سيدخل تراكيب تأمر المواصفة بإسقاطها.

قد تولد الأخطاء رسالة ICMPv6 من نوع Parameter Problem. تصنف RFC 4443 الرسالة Type 4، ويعني Code 0 العثور على حقل خاطئ في الرأس؛ تُسقط الحزمة، وينبغي إرسال الرد ضمن القيود المحددة. إلا أن غياب الرد ليس إيصال قبول. فقد تمنعه مرشحات أو حدود معدل الإرسال أو مسار غير متماثل أو انقطاع طريق العودة.

صفر UDP له اختصاص مستقل

لـ UDP خانة طول من 16 بتاً أيضاً. إذا نُقلت رسالة UDP داخل حزمة عملاقة وتجاوز طولها الحقيقي 65,535، يمكن أن تكون UDP Length صفراً. تستخرج الجهة المستقبلة الطول من Jumbo Payload Length بعد طرح رؤوس الامتداد الواقعة قبل UDP. ويستخدم فحص السلامة ذلك الطول الفعلي، لا الصفر.

يتعاون الصفران لكنهما لا يؤديان الوظيفة نفسها. صفر IPv6 يقود إلى خيار Jumbo، وصفر UDP يفعل قاعدة خاصة ببروتوكول النقل. رؤية أحدهما لا تسمح بافتراض الآخر. أما TCP فلا يملك خانة مماثلة لطول الحزمة؛ وفي هذا السياق تُعامل MSS بقيمة 65,535 كأنها بلا حد ذاتي، بينما يقيد اكتشاف MTU للمسار الحجم الممكن فعلياً.

حزمة صحيحة قد لا تجد طريقاً واسعاً

لا تصبح الحزم العملاقة ذات صلة إلا على وصلة يزيد MTU فيها على 65,575 ثمانية: أربعون للرأس الأساسي وحمولة تتجاوز 65,535. ولا تُلزم التطبيقات التي لا تتصل بوصلات كهذه بدعمها. وتعرف RFC 8201 قيمة Path MTU بأنها أصغر MTU على امتداد الطريق؛ وقد تُسقط الحزمة الكبيرة مع رسالة Packet Too Big.

لذلك تثبت سلامة الصياغة اتساق الإعلان، ولا تحجز سعة في نفق أو جهاز وسيط. قد يدعم المرسل والمستقبل والوصلة الأولى التنسيق بينما يعجز عنصر لاحق عنه. وفي الاتجاه الآخر، فإن إسقاط كل حزمة لمجرد احتوائها خيار Jumbo يرفض تنسيقاً صحيحاً في المعيار؛ وتحذر RFC 9288 من هذا النوع من التصفية الواسعة لرؤوس الامتداد.

ينبغي فصل ثلاثة ادعاءات: ما أعلنته الحزمة، وهل كان ترتيبها متسقاً، وماذا فعل المسار بها. تجيب الحقول الكاملة عن الأول، والتحقق البنيوي عن الثاني، ولا يجيب عن الثالث إلا الاستلام أو العدادات أو Packet Too Big أو اختبارات محكومة. لا يستطيع الصفر وحده حمل هذه الاستنتاجات كلها.

ويجب أن تكون نسبة العمل إلى الأشخاص بالقدر نفسه من الدقة. تسمي RFC 2675 كلاً من David Borman وSteve Deering وRobert M. Hinden، بينما تسمي RFC 8200 كلاً من Steve Deering وBob Hinden. ويصف ملف IETF Hinden بأنه أحد المشاركين في اختراع IPv6. لا تثبت هذه المصادر اختراعاً فردياً للآلية أو سيطرة على قرارات نشرها لدى مشغلين آخرين.

المصادر