الخلاصة

  • شفّرت RFC 3956 طول بادئة وبادئة أحادية ومعرّفاً صغيراً في عنوان مجموعة IPv6 كي تشتق موجهات PIM-SM نقطة RP واحدة.
  • يستطيع أي مستخدم تقديم عنوان المجموعة، لذلك لا يثبت الاشتقاق الصحيح أن RP موجودة أو قابلة للوصول أو مخولة أو أنها تملك حالة مصدر أو سلّمت بيانات.

حملت الوجهة جزءاً من الإعداد

يتلقى التطبيق عنوان مجموعة من إعداد أو دليل أو صفحة. منحت RFC 3956 بعض هذه العناوين وظيفة ثانية: مادة حساب نقطة الالتقاء التي يستخدمها PIM Sparse Mode.

كان IPv6 يفتقر إلى ترتيب MSDP نفسه المستخدم مع ASM في IPv4، ولم يكن SSM بديلاً فورياً لكل الحالات. اشتقاق RP من الوجهة ألغى الحاجة إلى توزيع خريطة مستقلة لهذا الاختيار.

لكن الإعداد لم يختف؛ انتقل إلى بتات تأتي من خارج إدارة الراوتر.

لم يتسع العنوان لعنوان آخر كامل

لا يمكن وضع RP من 128 بتاً داخل مجموعة من 128 بتاً مع إبقاء هوية المجموعة. بُني الحل فوق تنسيق RFC 3306: علم يحدد embedded-RP، وحقل plen وبادئة شبكة ومعرّف RIID من أربع بتات تعيد بناء RP ضمن قيود معينة.

حُجز RIID الصفر. أمكن اختيار نقاط متعددة بقيم غير صفرية تحت بادئة واحدة، لكن عنوان المجموعة الكامل أنتج مرشحاً واحداً. بقي تفرد Group ID خارج النطاق؛ اتفاق الحساب لم يكن اتفاقاً على سلطة تخصيص المجموعة.

حصلت الخريطة المضمّنة على أولوية أطول مطابقة مقارنة بوسائل أخرى. منعت الإجابات المتضاربة، ولم تمنح الإجابة المختارة حياة أو صحة.

أدخل المستخدم حركة إلى مستوى التحكم

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

تصف RFC المعلومات بأنها من مصدر غير موثوق، لأن أي مستخدم على الإنترنت يمكنه توفير المجموعة. يجب تطبيق فحوص صلاحية لا تقل عن فحوص RP المتعلمة بطرق أخرى، مع استبعاد نتائج مثل fe80::/10 و::/16 وff00::/8.

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

لم تضمن الوثيقة الوجود نفسه

يفترض PIM-SM أن RP المتعلمة أو المضبوطة قابلة للوصول ضمن المجال. تقر RFC 3956 بأن هذا لا يمكن إثباته عموماً، وأن RP أجنبية مضمنة قد لا تكون موجودة أصلاً.

وجود مسار يثبت اختيار قفزة تالية فقط. لا يثبت عملية PIM أو قبول Register أو حالة مصدر أو قدرة. يثبت Join حالة وسيطة، لا وصول البيانات. ويثبت cache أن حساباً حُفظ، لا أن المرشح يعمل الآن.

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

احتفظ كل بروتوكول بحكمه

فصّلت RFC 4601 لاحقاً Join وRegister والأشجار المشتركة، وعرّفت RFC 3810 MLDv2. عضوية محلية وحالة PIM ووصول حزمة ليست إيصالاً واحداً.

عرّفت RFC 4607 SSM الذي يسمي المصدر والمجموعة ويتجنب RP. رأته RFC 3956 بديلاً مهماً لا استبدالاً فورياً شاملاً. الاسم الأدق لا يثبت التنفيذ أيضاً.

حدّثت RFC 7371 معمارية عناوين البث المتعدد لاحقاً. تحفظ بيانات RFC Editor وصفحة التصحيحات سجل الوثيقة، لا انتشارها في شبكة بعينها.

كانت فائدة embedded-RP أن المرشح صار قابلاً لإعادة الإنتاج، فقلّ اختلاف الإعداد. لكنه ظل مرشحاً. سمّى العنوان المكان الذي ينبغي أن يحاول عنده التحكم؛ أما المسار ورسائل PIM وحالة المصدر والعدادات ورؤية المستقبل فكانت أدلة المراحل التالية.

المصادر