الخلاصة

  • خصصت RFC 894 القيمة الست عشرية 0800 بوصفها EtherType لـ IPv4، وطلبت ملء حقل بيانات Ethernet بالأصفار إذا قل عن الحد الأدنى البالغ 46 ثمانية. توجد تلك البايتات على الوصلة، لكنها ليست جزءًا من حزمة IP ولا من Total Length.
  • يحتاج المستقبل إلى حجم الوصلة الفعلي لتخصيص مخزن الاستقبال، وإلى Total Length لإيقاف تحليل IP. صاغت RFC 6274 لاحقًا علاقة الاحتواء، وأوجبت إسقاط الحزمة عندما تسلم الوصلة عددًا أقل مما تدعيه IP.
  • ما لا يحمل معنى داخل IP قد يحمل سرًا على السلك. وثقت CERT/CC مشغلات أعادت استخدام محتوى قديم في الحشو؛ كما تبقي أخطاء RFC 894 المصححة سجل النص الأصلي منفصلًا عن القراءة التي تحققت منها جهة النشر.

المسطرة الداخلية سبقت Ethernet

عرفت RFC 791 حقل Total Length بأنه طول مخطط بيانات IPv4 كاملًا بالثمانيات، شاملًا رأس IP والبيانات. أما IHL فيقيس طول الرأس بكلمات 32 بت ويحدد بداية البيانات. الأول يحدد نهاية الرأس، والثاني يحدد نهاية الرزمة.

جاءت RFC 894 في أبريل 1984 لتضيف وعاء Ethernet حول هذا الكائن. ينقل الإطار رأس IP ثم بياناته مباشرة، وتحمل خانة Type القيمة الست عشرية 0800.

لكن حقل بيانات Ethernet لا يجوز أن يقل عن 46 ثمانية. قد يكون رأس IPv4 الأدنى عشرين ثمانية ولا يحمل أي بيانات. عندئذ تحتاج الوصلة إلى 26 ثمانية أخرى، مع أن IP لم تنشئها.

الحل هو أصفار خارج الرزمة. لا تتغير Total Length، ولا يتلقى التطبيق بيانات مزيفة، وتبلغ Ethernet حدها الأدنى. تصبح العلاقة الطبيعية:

IHL × 4 <= IP Total Length <= حجم حمولة طبقة الوصلة

يجوز أن تكون المتباينة الثانية صارمة في إطار صحيح تمامًا. الفرق هو الحشو، لا جزء مجهول من IP.

0800 يختار القواعد ولا يعد الثمانيات

القيمة 0800 تساوي 2048 عشريًا، لكنها ليست وعدًا بأن الحمولة 2048 ثمانية. إنها تعرّف البروتوكول الذي يفسر ما يلي.

شرح RFC 1122 سبب أهمية التمييز. حين تتشارك إطارات Ethernet وIEEE 802.3 الكابل نفسه، تقع خانة Length في الموضع نفسه الذي تقع فيه EtherType. القيم التي لا تتجاوز 1500 تعد أطوالًا لـ802.3، بينما قيم EtherType الصحيحة أكبر من 1500.

لذلك يفتح 2048 قواعد IPv4. بعد ذلك تبحث الآلة في رأس IPv4 عن Total Length لتعرف النهاية. لا يجوز أن تستبدل آخر مخزن الوصلة بهذا الحقل لمجرد وصول بايتات إضافية.

أوجبت RFC 1122 على مضيف Ethernet بسرعة 10 Mb/s إرسال صيغة RFC 894 واستقبالها. وكان ينبغي أن يستقبل صيغة IEEE 802 في RFC 1042، مع جواز إرسالها. وإذا أرسل الصيغتين وجب أن يوفر إعدادًا يختار بينهما وأن تكون RFC 894 هي الافتراضية. الوسط المادي الواحد لا يثبت أن البنية واحدة.

ثمانية بايتات خارجية غيرت السعة لا هوية IP

وضعت RFC 1042 رزم IP وARP داخل IEEE 802.2 LLC وSNAP. يبلغ مجموع رأسي LLC وSNAP ثمانية بايتات، وتحمل آخر 16 بت في SNAP قيمة EtherType: الرقم 2048 لـIP و2054 لـARP.

إذا فرضت شبكة IEEE 802 حدًا أدنى، أضيفت أصفار أيضًا، وبقيت خارج Total Length. والحد الأدنى 28 ثمانية الذي يورده النص يتكون من عشرين لرأس IPv4 الأدنى وثمانية لـLLC/SNAP، من دون رأس MAC. إنه لا يلغي حد 46 ثمانية في حقل بيانات Ethernet؛ إنهما حسابان لسطحين مختلفين.

ذكرت RFC 1122 أن MTU في Ethernet هو 1500 وفي 802.3 هو 1492. تستهلك التغلفة الخارجية الثمانيات الثمانية. لكنها لا تحذفها من رأس IP ولا تحولها إلى حشو داخل Total Length.

وتوضح RFC 895 أن القاعدة ليست رهينة الرقم 1500. تناولت Experimental Ethernet بسرعة 3 Mb/s وعناوين من ثمانية بتات، وسمحت برزمة IP تبلغ 1536 ثمانية. ومع ذلك ظل حشو الحد الأدنى خارج IP. تتغير مواصفات الحامل، ولا تتغير ملكية الرزمة.

خطأ “minimum 1500” بقي دليلًا على ما نشر

بعد أن تذكر RFC 894 الحد الأدنى الصحيح 46، تقول النسخة المنشورة إن “minimum” حقل البيانات هو 1500، ثم تستنتج في الجملة نفسها أن الحد الأقصى لرزمة IP هو 1500. لا يستقيم المنطق إلا إذا كانت الكلمة الأولى “maximum”.

تسجل Erratum 570، وهي تقنية ومتحقق منها، هذا التصحيح منذ بلاغ 2001. وتسجل Erratum 5141 التصحيح نفسه، بعد بلاغ 2017 وتحقق 2024. لا يعني التاريخ المتأخر أن حد Ethernet تغير في 2024.

تشرح سياسة أخطاء RFC Editor سبب بقاء الكلمة الخاطئة. لا تتغير RFC بعد نشرها. تعد errata المتحقق منها دقيقة، لكنها لا تدمج في ملفات TXT أو PDF أو XML.

النص الأصلي يثبت ما نُشر، وسجل errata يثبت كيف ينبغي قراءته. تعديل نسخة محلية في صمت يجعلها أسهل ويطمس أصل التعديل. تجاهل التصحيح يحفظ الأثر ويضيع المعنى الهندسي. لا بد من إبقاء الدليلين والرابط بينهما.

الحشو ليس trailer

ناقشت RFC 893 في الشهر نفسه Trailer Encapsulation. كانت تنقل رؤوس الطبقات الأعلى المتغيرة إلى ما بعد البيانات لتحسين محاذاة الذاكرة وتقليل النسخ لدى بعض المستقبلين. وكانت تحتاج إلى جار يفهم الترتيب المختلف.

لا ينقل حشو RFC 894 أي رأس. يبقى رأس IP أولًا وتتبعه البيانات، وتأتي الأصفار بعد النهاية التي تعلنها Total Length. لا يعيد المستقبل بناء رزمة معكوسة؛ بل يتوقف عن تفسير IP في موضعه الصحيح.

الحشو وtrailer وخيار IP وFCS عناصر مختلفة، ولو ظهرت كلها قرب نهاية إطار ما. الموضع لا يمنحها سلطة مشتركة.

استقبال الوعاء وتحليل الكائن قراران

نبهت RFC 6274 في 2011 إلى أن وحدة IP قد تتسلم حمولة وصلة أكبر من Total Length. غالبًا يفسرها حشو مشروع، وقد يصنعها مهاجم أيضًا.

لذلك ينبغي تخصيص مخزن الذاكرة وفق حجم الحمولة الذي تبلغ عنه طبقة الوصلة. هذه الخطوة تحمي استقبال الوعاء الخارجي. ولا تجعل كل ما في الوعاء جزءًا من IP؛ يظل التحليل محصورًا في Total Length.

أما إذا كانت حمولة الوصلة أصغر من Total Length فيجب الإسقاط والتسجيل. لا يجوز ملء الناقص من ذاكرة مجاورة. كذلك ينبغي أن يكون IHL مضروبًا في أربعة أقل من Total Length أو مساويًا له.

لا توجد “حقيقة طول” واحدة تحل المهمتين. طول الوصلة يضبط التخزين، وطول IP يضبط المعنى.

أصفار لم تكتب فتحولت إلى تسريب

في يناير 2003 وثقت CERT/CC VU#412115 مشغلات شبكة لم تملأ الإطارات القصيرة بأصفار. أعادت استخدام بيانات قديمة من مخزن الإطار. وقد تأتي المادة، بحسب التنفيذ، من ذاكرة النواة أو ذاكرة ثابتة للمشغل أو مخزن في بطاقة الشبكة.

لم تصبح تلك البايتات payload صالحًا داخل IP. يتوقف المحلل الصحيح قبلها. لكن جار Ethernet يستطيع رؤيتها في الإطار المادي. الاستبعاد من المعنى لا يساوي الإزالة من قناة الاتصال.

تحتوي إفادات الموردين لدى CERT على أنظمة متأثرة وغير متأثرة وأخرى مجهولة. لا تثبت أن كل المشغلات سربت. تثبت أن عدم تصفير الحشو صنع آلية إفشاء بعيدة في تنفيذات أبلغ عنها.

الطبقة التي تضيف البايتات مسؤولة عما تضيف. لا يعفيها Total Length من محتوى خرج فعليًا إلى السلك.

المصادر