الخلاصة

  • يسمح RFC 9798 لعنوان Receiver RLOC أن يكون مجموعة متعددة البث فقط عندما تدعم الشبكة التحتية لنواة LISP نقل IP multicast؛ أما اختيار مجموعة يمكن للـETR الانضمام إليها فهو قرار محلي.
  • ينشئ ITR الجذري إدخالاً في قائمة واجهات الخروج لكل تعيين فريد في الشبكة التحتية. وإذا احتاج إلى تتبع ETR التي أرسلت طلبات الانضمام، فعليه استخدام عنوان المصدر في Join/Prune، ويجب أن يكون عنوان ETR RLOC.
  • يمكن للمصادقة أن تدعم إثبات مصدر الطلب وسلامته، لكنها لا تثبت حق استخدام المجموعة أو قدرة المسار أو وجود أعضاء أو وصول البيانات.

المجموعة تجيب عن سؤال المكان لا سؤال الهوية

عندما تكون قيمة Transport صفراً ويحمل Receiver RLOC عنواناً متعدد البث، يعلن ETR عن المجموعة التي يريد أن يتلقى عليها التدفق المغلف. لا يحتوي العنوان على عدد ETR، ولا على أسماء المضيفين خلفها.

يحدد RFC 9798 مصدراً آخر لتتبع الجهات الطالبة. إذا احتاج ITR إلى قائمة ETR التي تلقى منها PIM joins، فيجب أن يستخدم عنوان IP المصدر لرسالة Join/Prune الواردة، ويجب أن يكون ذلك المصدر عنوان RLOC للـETR. ولهذا لا يجوز دمج المجموعة المطلوبة وهوية المرسل في خانة واحدة اسمها «المستقبل».

نُشر RFC 9798 في يونيو 2025 بصفة Experimental ويحدّث RFC 8059. لا يغير تركيب Transport Attribute ولا دلالته، بل يقصر التحديث على Transport=0. يظل العنوان الأحادي مستخدماً للتغليف الأحادي، ويصبح العنوان متعدد البث صالحاً للتغليف متعدد البث، بشرط أن تدعم الشبكة التحتية لنواة LISP ذلك النقل.

هذا الشرط ليس آلية تصديق عن بعد. عندما يقرر ETR استخدام multicast في الشبكة التحتية، يختار مجموعة يستطيع الانضمام إليها، ويحدد موقع LISP الصاعد الذي يجب أن تتجذر عنده الشجرة، ثم ينشئ Join/Prune وفق RFC 8059. ينص RFC 9798 على أن اختيار المجموعة قرار محلي خارج نطاقه. لذلك يحتاج التدقيق إلى سياسة النطاق واختبار القدرة وإصدار الإعداد وتوقيت القرار، لا إلى قيمة المجموعة وحدها.

عدد التعيينات يحدد موضع الكلفة

يفصل RFC 6831 حالة (S-EID,G) داخل المواقع عن حالة (S-RLOC,G) في النواة. يغلف ITR الحزم، ويمكن لشجرة multicast في النواة أن تنسخها، ثم يفك ETR المستقبل التغليف ويتحقق من الحالة الداخلية.

يصف RFC 9798 ثلاثة أشكال. يمكن لعدة تدفقات overlay أن تشترك في تدفق underlay واحد، أو يمكن لتدفق overlay واحد أن ينقسم إلى تدفقات underlay متعددة بحسب قيود xTR اللاحقة، أو يكون لكل تدفق تعيين فريد. يخفّض many-to-one عدد الأشجار، لكنه قد يرسل إلى موقع حركة لم يطلبها لذلك المصدر؛ يوضح RFC 6831 أن ETR لا يرفضها إلا بعد فك التغليف وفحص (S-EID,G). يعالج one-to-many اختلاف النطاقات مقابل نسخ أكثر عند الجذر. ويزيد one-to-one العزل مع زيادة الحالة.

وحدة مسؤولية ITR واضحة: لكل تعيين multicast فريد في الشبكة التحتية، يخصص إدخالاً جديداً في outgoing-interface list. ويجوز له تطبيق سياسة محلية للحد من عدد النسخ. لا يحدد RFC حصة عالمية. لذا يجب أن يتضمن سجل السعة مفتاح التعيين وإدخال OIF وعدد النسخ المطلوبة والمقبولة وسبب الحد.

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

فهم الترميز لا يعني اكتشاف القدرة

يعرّف RFC 5384 الغلاف العام لسمات PIM Join. وينبه إلى أن السمات المؤثرة في بناء الشجرة تفيد داخل نطاقات متعاونة يُعرف مسبقاً أن موجّهاتها تفهم الترميز والسمات. يستخدم PIM المعتاد خيار Hello لتجنب إرسال الترميز إلى جار غير قادر.

لكن RFC 8059 يذكر أن xTR في LISP لا تتبادل PIM Hello، ولا يوجد خيار Hello للتفاوض على هذه السمات. يُفترض أن الأنظمة التي تدعم النسخ الأحادي عند الرأس تدعمها، وتكون سمتا Transport وReceiver RLOC غير عابرتين. يوسع RFC 9798 الاستخدام إلى multicast من دون إنشاء اكتشاف قدرة شامل أو جهة عالمية لتخصيص المجموعات.

لذلك تُفصل طبقات الدليل. نجاح التحليل يثبت قبول التمثيل. سياسة النطاق تثبت النية المحلية. إدخال OIF يثبت حالة تحكم. جداول multicast والعدادات تثبت نشاطاً جارياً. أما سجل الاستقبال فيثبت النتيجة. لا تمنح أي طبقة سلطة تلقائية للطبقات الأخرى.

المصادقة تضيق شبهة واحدة فقط

يقرر RFC 8059 أن أمن السمات لا يتجاوز أمن حزمة PIM. ويعرض RFC 9798 خطراً من طلبات انضمام كثيرة بمجموعات مختلفة أو متداخلة، لما قد تسببه من تداخل واستنزاف موارد النسخ. ويقول إن آليات RFC 5796 يمكن أن تُستخدم للتحقق من الطلبات، مع إمكان التتبع أو وضع حد للمجموعات لكل ETR RLOC مصدر.

لا يحول ذلك المقترح إلى نظام تفويض إلزامي. يعالج RFC 5796 حماية رسائل PIM-SM المحلية للوصلة بواسطة IPsec، وعلاقات الأمان والمفاتيح ومصادقة الأقران. عند تشغيلها وتسجيلها بطريقة سليمة، تدعم دليلاً على المصدر وسلامة الرسالة. لكنها لا تخصص المجموعة، ولا تقيس قدرة كل وصلة، ولا تثبت العضوية أو التسليم.

السجل الدفاعي يربط باختصار واحد: بايتات Join/Prune، السمات المحللة، نتيجة المصادقة وعلاقة الأمان، RLOC المصدر، قرار ETR المحلي، الجذر، عدد التعيينات، OIF، قرار الحد، حالة النواة، العدادات، فك التغليف، التحويل الداخلي ونتيجة المستقبل. عندئذ فقط يمكن تحديد الحد الذي توقف عنده الدليل.

المصادر