الخلاصة

  • عرّفت RFC 9792 حقلاً فرعياً متغير الطول من نوع Prefix Extended Flags لكل من OSPFv2 وOSPFv3، لكنها لم تعرّف معنى أي بت بنفسها.
  • تسجل IANA الآن العلمين U وUP وفق RFC 9929؛ لكن التسجيل اللاحق لا يثبت التنفيذ أو الإرسال أو القبول أو أثر التوجيه.

عند صدور RFC 9792 في يونيو 2025، قالت بوضوح إن الوثيقة لا تعرّف أي بت. ما أصبح معيارياً هو مكان لخصائص لاحقة وقواعد للتعامل معه عندما يغيب أو يقصر أو يتكرر أو يصل مشوهاً. لم تكن هناك بعد خاصية إيجابية جديدة للبادئة.

في OSPFv2 يحمل الحقل الفرعي النوع 11 داخل Extended Prefix TLV في RFC 7684. وفي OSPFv3 يحمل النوع 37 ويمكن وضعه في حقول البادئات الثلاثة في RFC 8362، أو في SRv6 Locator TLV في RFC 9513.

تتكون القيمة من كتل طول كل منها 32 بت. يجب أن يكون الطول مضاعفاً لأربعة أوكتتات؛ وإلا تُعد LSA الحاوية مشوهة ويجب تجاهلها. ينهي المرسل القيمة عند آخر كتلة لازمة لحمل بت مضبوط على واحد. وكل علم معرّف يقع بعد الطول المستلم يُعامل كصفر. أما البتات غير المخصصة فترسل صفراً وتُتجاهل.

لذلك لا يمنح الغياب معنى إيجابياً. تتجاهل العقد القديمة الحقل الفرعي غير المعروف وفق RFC 3630 أو RFC 8362. وإذا تكرر داخل الحقل الأب، تُستخدم النسخة الأولى فقط وتُهمل البقية مع تسجيل الخطأ بمعدل محدود. لا توجد قاعدة لدمج النسخ.

المعنى وصل لاحقاً

تخصص سجلات IANA الحالية لـOSPFv2 وOSPFv3 البت 0 للعلم U والبت 1 للعلم UP استناداً إلى RFC 9929، بينما تظل البتات 2–31 غير مخصصة. أنشأت RFC 9792 الحاوية؛ ثم عرّفت RFC 9929 أول خاصيتين.

ولا يكفي أن يكون البت واحداً. يعني U أن البادئة غير قابلة للوصول، ويعني UP أن عدم الوصول مخطط له. يُتجاهل UP إذا غاب U. في OSPFv2 لا يصح العلمان إلا مع المقياس LSInfinity. وفي OSPFv3 يلزم أيضاً LSInfinity وبت NU في Prefix Options الأب. يظل الحقل الثابت في RFC 5340 جزءاً من المعنى.

يجب أن تفصل العبارة التشغيلية بين المواصفة، وتخصيص IANA، ودعم البرنامج، والإعداد المحلي، والبايتات المرسلة، وقرار المستقبل، وحساب المسار، وFIB، وحركة المرور. سياسة IETF Review في RFC 8126 تضبط شرعية تخصيص الرقم؛ وهي ليست قياساً للنشر.

تكشف RFC 9792 أن التمدد الآمن يبدأ بالامتناع عن الاستنتاج. وجود مكان للمعنى لا يخلق المعنى، ووجود معنى في سجل لا يجعله نتيجة تشغيلية.

المصادر