الخلاصة

  • تخصص IEEE Registration Authority قيم EtherType وLSAP، وقد منحت IANA ‏OUI بالقيمة 00-00-5E؛ لذلك تقتصر سلطة IANA على المساحات الفرعية الواقعة تحت هذا التفويض.
  • رقم البروتوكول من بايتين بعد OUI الخاص بـ IANA ليس EtherType؛ فلا تكتمل الهوية من دون الحامل وOUI والقيمة الداخلية.
  • تفصل RFC 9542 بين موضع الحقل، ومالك فضاء الأسماء، والسجل المرجعي، ومسار الموافقة، والمواصفة، والتنفيذ، والنتيجة.

لم يكن الخطأ في قراءة الأرقام السداسية. كان في اختصارها حتى اختفى مصدرها.

تتضمن السلسلة 88-B7-00-00-5E-00-42 ثلاثة أفعال مؤسسية. خصصت IEEE RA القيمة 0x88B7 بوصفها OUI Extended EtherType. ومنحت IEEE ‏IANA البادئة 00-00-5E. ثم حجزت IANA الرقم 0x0042 داخل هذا الفضاء للاستخدام في الوثائق. لا يحق للبايتين الأخيرين وحدهما أن يتحدثا باسم السلسلة كلها.

نشرت IETF RFC 9542 في أبريل 2024 بوصفها BCP 141، وهي تحل محل RFC 7042. لم تنشئ سجلاً جديداً لدى IANA ولم تغير تخصيصاً قائماً. أهم ما تفعله هو رسم حدود التفويض: إدارة مساحة فرعية لا تمنح سلطة على الحقل الكامل الذي يحملها.

شكل الحقل يسبق اسمه

EtherType معرف من 16 بت بقيمة لا تقل عن 0x0600. يظهر في أبسط إطار Ethernet II بعد عنواني MAC، وقد تسبقه حقول علامات إضافية. سلطة تخصيصه هي IEEE RA.

يستخدم LLC بنية أخرى. يأتي حقل طول ثم زوج من معرفات LSAP ذات الثمانية بتات. وفي SNAP تظهر AA-AA-03 ثم OUI من ثلاثة بايتات ورقم بروتوكول من بايتين. مالك OUI هو الذي يخصص الرقم الأخير.

يوفر EtherType ‏0x88B7 حاملاً آخر للمعرفات القائمة على OUI. في 88-B7-00-00-5E-qq-qq خصصت IEEE الحامل وOUI، بينما تدير IANA ‏qq-qq داخل المساحة المفوضة إليها. تشابه العرض لا يجعل الحقلين تابعين لسجل واحد.

كما يسمح SNAP بوضع EtherType بعد OUI صفري بالكامل. في تلك الحالة تكون البايتات الأخيرة EtherType فعلاً. أما بعد 00-00-5E فهي رقم بروتوكول لدى IANA. قاعدة بيانات تحتفظ باللاحقة فقط تفقد الدليل اللازم للاختيار بين القراءتين.

من يعرض الجدول ليس دائماً من يخصص الرقم

تنشر IANA مجموعة “IANA OUI Ethernet Numbers” لتخصيصاتها تحت OUI الخاص بها. يسجل جدول SNAP فيها 0x0042 للاستخدام الوثائقي. هنا تتحدث IANA ضمن صلاحيتها.

وتنشر أيضاً “IEEE 802 Numbers”. يوضح قسم EtherTypes أن IANA لا تخصص تلك القيم، وأن القائمة معلومات مساهم بها وغير متحقق منها، ويوجه إلى IEEE RA. الاستضافة والتنسيق مع الخبراء لا يحولان العرض المعلوماتي إلى سجل إصدار.

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

عندما يغذي الجدول قواعد أمنية تصبح المشكلة تنفيذية. قد يُسمح بقيمة وثائقية كأنها بروتوكول معياري، أو يُعامل اختبار محلي كتخصيص عالمي. لذلك يجب حفظ تصريح السجل عن نطاق مسؤوليته، لا رابط الصفحة فقط.

شروط التخصيص تحد من سلطة IANA

يشترط RFC 9542 أن يخدم الرقم الجديد تحت 00-00-5E معياراً لـ IETF أو معياراً متصلاً بعملها، وأن يوثق في Internet-Draft أو RFC. ويجب أن يتضمن البروتوكول حقل إصدار في موضع ثابت أو علامة مكافئة تمكن الإصدارات القديمة من التعرف على الإصدارات اللاحقة.

تخضع التخصيصات العادية لـ Expert Review. أما 0x0000 و0xFFFF فمحجوزان ويتطلبان IESG Ratification. ولا يجوز منح رقم تحت OUI الخاص بـ IANA لبروتوكول لديه EtherType بالفعل؛ إذ يمكنه استخدام EtherType مباشرة أو وضعه بعد OUI الصفري في SNAP.

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

تخضع عناوين MAC تحت OUI الخاص بـ IANA للحد نفسه. يجب أن تخدم المعايير، وأن تخصص في كتل مصطفة بقوى العدد اثنين، وألا تساعد مصنعي الواجهات على تجنب الحصول على كتلهم من IEEE. التفويض يعالج حاجة محددة ولا ينشئ سلطة بديلة.

قيمة الوثائق ليست قيمة تجربة

الرقم 0x0042 تحت OUI الخاص بـ IANA مخصص للأمثلة في الوثائق. وفي معاملات تنظيمية أخرى تستخدم 0x42 للغرض نفسه. يسمح ذلك للمواصفات بعرض بايتات واقعية من دون التصادم مع تخصيص تشغيلي.

أما IEEE فقد عينت 0x88B5 و0x88B6 بوصفهما EtherType للتجربة المحلية. إنهما في سجل مختلف ولهما غرض مختلف. وصف 00-00-5E-00-42 بأنه «EtherType تجريبي» يخلط الحامل بمالك الفضاء وبسياسة الاستخدام.

وقد تتحول الأمثلة إلى اعتماد دائم عندما تنسخ قوالب المختبر إلى الإنتاج، أو تعبر التجربة المحلية حدود المجال الإداري. حفظ النطاق والمسؤول وتاريخ الانتهاء مع القيمة يكشف هذا الانجراف قبل أن يصبح مكلفاً.

سجل التخصيص لا يثبت ما فعله الجهاز

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

تبدأ سلسلة الإثبات بالبايتات والمواضع والعلامات والطول. يحدد الحامل وOUI فضاء الأسماء. يثبت سجل IEEE أو IANA التخصيص، وتثبت المراجعة والمواصفة شروطه. بعد ذلك يأتي إصدار المحلل وإعداده، ثم التقاط الحزمة، ثم إيصال الطرف النهائي.

دمج هذه الإيصالات يرفع سلطة تنسيق التفرد إلى شهادة تشغيل لم تُمنح. الفصل بينها يحفظ مسؤولية كل طرف: السجل عن فضائه، والمصنع عن التنفيذ، والمشغل عن النتيجة المرصودة.

جرد صالح أثناء الحادث

ينبغي حفظ البايتات الأصلية، والموضع، والعلامات، والحامل، وOUI الكامل، والقيمة الداخلية، ومالك السجل، والمصدر وتاريخه، وفئة الموافقة، والمواصفة، وإصدار المحلل، والنتيجة. الاسم السهل أداة بحث، لا الدليل الوحيد.

عندئذ يمكن تفسير التباين. قد تتأخر قائمة IANA المعلوماتية عن IEEE RA. وقد يعرض محلل قيمة IANA صحيحة كأنها EtherType. وقد تظهر قيمة وثائقية في شبكة حية. لكل حالة علاج مختلف، ولا يكفي اختيار الصفحة الأسهل وصولاً.

لا يبني RFC 9542 سلطة مركزية جديدة. إنه يحفظ خريطة التفويض. تحتفظ IEEE بالمساحة المباشرة، وتحتفظ IANA بالجزء الذي مُنح لها، ويبقى على التنفيذ أن يثبت سلوكه. الهوية الكاملة وحدها تمنع بايتين من اكتساب تفويض لم يكن موجوداً على السلك.

المصادر