ظلّ الخيار المجهول يقول ما ينبغي فعله: كيف حدّد IPv6 حدود الجهل

الخلاصة

• منذ RFC 1883 يحدد أعلى بتّين في Option Type لخيار TLV في IPv6 ما يفعله العقدة المعالِجة إذا لم تعرف النوع: تتجاوزه، أو تسقط الحزمة، أو تسقطها وتعيد خطأ ICMPv6 يشير إلى البايت غير المعروف.
• ويعلن البت الثالث ما إذا كانت بيانات الخيار قد تتغير في الطريق. هذه البتات تضبط عاقبة الجهل وحساب التحقق، لكنها لا تُلزم كل موجّه بالمعالجة، ولا كل جهاز وسيط بالتمرير، ولا تجعل المحتوى موثوقاً.

كان في وسع البرنامج القديم فهم الحد من دون فهم المعنى

تصل الحزمة إلى وجهتها، فتتعرف الوجهة إلى ترويسة Destination Options وتقرأ بنية Type-Length-Value. ثم تجد نوعاً لم يُبرمج محلله فيها. لا تعرف ماذا تعني Option Data، لكنها تعرف طولها وأين يبدأ الخيار التالي.

أضافت RFC 1883، وهي أول مواصفة منشورة لـ IPv6 في ديسمبر 1995، نتيجة عدم المعرفة إلى بايت النوع نفسه. يحدد البتّان الأعلى الإجراء، ويبيّن البت التالي هل يمكن أن تتغير البيانات قبل الوجهة النهائية، وتشارك البتات الخمسة الباقية في هوية النوع.

لم يمنح ذلك مصمم الخيار الجديد سلطة تفسير فوق برنامج قديم. منحه فقط وسيلة لإعلان نتيجة احتياطية محدودة يستطيع الغريب تطبيقها من دون تخمين معنى القيمة.

احتوى بتّان أربع نتائج مختلفة

تعني 00 تجاوز الخيار بحسب طوله ومواصلة معالجة الترويسة. وتعني 01 إسقاط الحزمة. أما 10 فتعني الإسقاط وإرسال ICMPv6 Parameter Problem، Code 2، إلى عنوان المصدر، مع مؤشر يقع على Option Type غير المعروف. وتفعل 11 الشيء نفسه، لكنها لا ترسل التقرير عندما يكون عنوان الوجهة multicast.

ليست هذه درجات للأمان. قد يحمل خيار 00 محتوى لا تقبله سياسة محلية، وقد يكون خيار 11 مشروعاً لكنه يحتاج إلى الفهم كي تُحفظ دلالته. البتات تصنف ما يبقى ممكناً عند غياب المعرفة، لا نية المرسل.

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

جعل multicast حد الإبلاغ ظاهراً

الفارق بين 10 و11 محصور في وجهة multicast. يطلب الأول التقرير حتى في هذه الحالة، بينما يكبته الثاني. وهكذا يمكن قراءة احتمال توليد حركة خطأ من النوع نفسه بدلاً من تركه لتخمين كل تنفيذ.

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

منع البت الثالث توثيق قيمة متحركة كأنها ثابتة

يجيب البت التالي عن سؤال آخر. الصفر يعني أن Option Data لا تتغير في الطريق، والواحد يعني أنها قد تتغير. عند وجود Authentication Header، تُعامل بيانات الخيار الموسومة بالتغيّر كأنها بايتات صفرية عند حساب قيمة التحقق أو فحصها.

لا يصح أن يسمح البروتوكول بتحديث مشروع في الطريق ثم يزعم أن الحقل نفسه ثابت. لذلك أخرج IPv6 المنطقة المتغيرة من ذلك الوعد. لكن الاستثناء لا يمنح أي موجّه حق الكتابة؛ مواصفة الخيار الخاصة ما زالت تحدد من يغير ماذا وكيف.

كانت البتات الثمانية هوية واحدة

أوضحت RFC 2460 عام 1998 أن البتات الثلاث العليا ليست سياسة منفصلة تُلصق بمعرّف من خمسة بتات. Option Type هو البايت الكامل. وإذا تشابهت البتات الخمس الدنيا واختلفت العليا فنحن أمام نوعين مختلفين.

تستخدم Hop-by-Hop Options وDestination Options فضاء الأنواع نفسه، مع إمكان تقييد موضع نوع بعينه في مواصفته. ويجب أيضاً معالجة الخيارات بترتيب ظهورها. لا يجوز للمستقبل أن يقفز إلى خيار مألوف لاحق وينفذه قبل أن يحسم أمر الخيار المجهول السابق.

يحفظ الترتيب السببية: إذا أمر خيار مبكر بالإسقاط فلا يمنح خيار معروف لاحق قبولاً بأثر رجعي.

لم يكن الخيار المجهول ترويسة تمديد مجهولة

تعيش بتات الإجراء داخل TLV في ترويسة Hop-by-Hop Options أو Destination Options معروفة. ولا تمنح قيمة Next Header التي تسمي Extension Header مجهولة الطول أو القواعد نفسها تلقائياً.

فضّلت RFC 6564 إضافة Destination Option جديدة حين تكفي، وطلبت تبريراً تقنياً قبل إنشاء Extension Header جديدة. كما فرضت صيغة مشتركة تحمل الطول على الترويسات المستقبلية، من دون أن تعيد تشكيل كل الصيغ القديمة.

وفصلت RFC 7045 بين الأدوار. تسقط الوجهة الحزمة إذا احتوت Extension Header لا تعرفها. أما عقدة التمرير فلا ينبغي عادة أن تسقطها لمجرد أنها لا تعرف ترويسة حديثة؛ وإذا اختارت تفتيش السلسلة فعليها تحديث معرفتها بالأنواع المسجلة. يختلف هذا عن قراءة بتات خيار مجهول داخل حاوية معروفة.

كشفت الأجهزة الوسيطة ما لا تحله الوصفية الذاتية

تبحث الجدران النارية وموازنات الحمل والموجّهات السريعة عن حقول طبقة النقل. قد تؤدي سلسلة طويلة أو نوع جديد إلى recirculation أو slow path أو عجز عن العثور على المنافذ التي تحتاجها السياسة.

احتفظت RFC 8200 بالإجراءات الأربعة وبت التغيّر، لكنها ربطت معالجة Hop-by-Hop في عقد العبور بالتهيئة الصريحة. ووثقت RFC 9098 الخيارات الصعبة حين لا يجد الجهاز المعلومة المطلوبة: يمرر بلا التفتيش المقصود، أو يسقط، أو يستهلك مسار معالجة أعلى كلفة.

لا يخلق بايت النوع سعة محلل أو عتاد. إنه يجعل الجهل متوقعاً فقط بعد أن تصل المعالجة إلى ذلك TLV.

ما لم تمنحه البتات قط

لا تعني 00 أن الخيار آمن أو أن له حق المرور، ولا تثبت 11 عداءً. وبت التغيّر ليس رخصة تعديل عامة. تسجيل النوع لا يثبت دعمه عبر المسار، ورسالة ICMP لا توثق هوية المرسل أو قصده.

تنسق الآلية بين غرباء لأن سلطتها ضيقة: قاعدة عامة، وتنفيذ محلي، ثم دليل من الحزم التي تعمل فعلاً.

المصادر وحدود الدليل

نشأت القاعدة في RFC 1883، وتوضحت هوية البايت الكامل في RFC 2460، وبقيت في RFC 8200. أما حدود صيغ الترويسات والتمرير ففي RFC 6564 و7045، والقيود التشغيلية في RFC 9098. لا تقيس هذه النصوص الدعم أو الإسقاط الحالي في كل منتج وشبكة.