الخلاصة

  • منحت RFC 3307 التخصيص بالخادم والتخصيص بالمضيف المجال الديناميكي نفسه 0x80000000-0xFFFFFFFF، وكان جزؤه الأعلى مستخدماً أيضاً لعناوين Solicited-Node. كان بوسع آليتين ملتزمتين بالنص اختيار المعرّف نفسه.
  • أنشأت RFC 10028 ستة نطاقات لدى IANA: MADCAP، غير مخصّص، تخصيص SSM بالمضيف، استخدام خاص، استخدام تجريبي، وSolicited-Node. أزالت تداخل سلطة التخصيص، لا كل تصادم على طبقة الشبكة أو الوصلة أو العتاد.
  • شارك Mike McBride في التأليف مع Nate Karstens وDino Farinacci. ينسّق السجل فضاء الأرقام المشترك، بينما تحتاج نسخة التنفيذ وشروط SSM والتوجيه وصحة المصدر وتفويض المستمع إلى أدلة مستقلة من الشبكة العاملة.

قد يلتزم طرفان بالقاعدة نفسها ثم يصطدما، إذا كانت القاعدة قد رسمت لهما المسار نفسه.

هذا ما ورثته معرّفات مجموعات البث المتعدد في IPv6 من RFC 3307. كان الخادم يستطيع تخصيص عنوان ديناميكياً، وكان المضيف يستطيع اختياره بنفسه. خُصص للطريقتين المجال الكامل من 0x80000000 إلى 0xFFFFFFFF. وفوق ذلك، كان المجال 0xFF000000-0xFFFFFFFF يحمل وظيفة Solicited-Node في Neighbor Discovery.

لم يكن على الخادم أو المضيف مخالفة مواصفة. كان يكفي أن يعمل كل منهما بمعزل عن الآخر. الخلل في الطبقة المشتركة: كلمة «ديناميكي» جُمعت تحتها سلطتان مختلفتان من دون فصل رقمي بينهما.

صدرت RFC 10028 على مسار معايير IETF في أغسطس 2026 لتصحيح هذا الجزء. ألّفها Nate Karstens وDino Farinacci وMike McBride. يُستخدم McBride هنا مدخلاً شخصياً إلى القصة، لا مخترعاً منفرداً ولا مالكاً لسجل IANA أو لقرار أي شبكة.

يعرض ملف IETF المحفوظ في 31 أغسطس 2026 McBride رئيساً لمجموعة PIM ومندوباً في MBONED وANIMA ومراجعاً في Routing Area Directorate ومؤلفاً لتسع وثائق RFC. وتنسبه RFC 10028 إلى Futurewei. ويضيف مقال تاريخي من Open Networking Foundation سياقاً مهنياً بصوته في 2017. تثبت هذه المصادر الهوية والسياق المؤرخ، ولا تثبت تبنياً لدى مصنع أو مشغّل.

لماذا يصل التكرار إلى طبقة الوصلة

تعرّف RFC 3307 البتات الدنيا الاثنتين والثلاثين من عنوان البث المتعدد IPv6 باعتبارها Group ID. وعلى Ethernet تُسقط هذه البتات مباشرة في عنوان البث المتعدد على طبقة الوصلة. لذلك لا يبقى التكرار مجرد صفين متماثلين في قاعدة بيانات؛ فقد تضطر بطاقة الشبكة أو المبدّل إلى استقبال تدفقات مختلفة على وجهة وصلة واحدة.

MADCAP، المعرّف في RFC 2730، بروتوكول عميل وخادم: يطلب المضيف من خادم تخصيص عنوان بث متعدد. أما العمل zeroconf الذي تصفه RFC 10019 كمطلب، فيحتاج إلى اختيار لا يعتمد على خادم. يمكن للنموذجين التعايش، لكن ليس إذا اعتبر كل منهما المجال نفسه ملكاً مشروعاً له.

العشوائية لا تنشئ حدوداً. قد تقلل احتمال أن يختار الطرفان القيمة نفسها، لكنها لا تلغي حقهما المشترك فيها. كما أن الجزء الخاص بـSolicited-Node لم يكن أرضاً فارغة أصلاً؛ فقد ارتبط بوظيفة أساسية في معمارية IPv6.

توضح RFC 10019 بقية المشكلة. على الحل اللامركزي أن يتعايش مع تطبيقات وآليات أخرى، ويكشف التصادمات في طبقتي الشبكة والوصلة ويحلها، بما في ذلك التصادم الذي يظهر بعد اجتماع جزأين انفصلا مؤقتاً. وقد تضيف جداول المبدّل المحدودة أو دوال التجزئة نوعاً آخر من الضغط.

حذفت RFC 10028 السبب الأسهل: ألا تعطي المواصفة آليتين مختلفتين المجال نفسه ابتداءً.

ستة نطاقات لا وعد واحد

يقسم سجل Dynamic Multicast Group IDs لدى IANA المجال إلى:

  • 0x80000000-0x8FFFFFFF لـMADCAP؛
  • 0x90000000-0xEFFFFFFF غير مخصّص؛
  • 0xF0000000-0xFCFFFFFF لتخصيص المضيف عناوين مجموعات SSM؛
  • 0xFD000000-0xFDFFFFFF للاستخدام الخاص؛
  • 0xFE000000-0xFEFFFFFF للاستخدام التجريبي؛
  • 0xFF000000-0xFFFFFFFF لعناوين Solicited-Node.

يحتاج منح عادي من المجال غير المخصّص إلى Standards Action. لا يحتوي كل قيد إلا على النطاق والوصف والمرجع. لا يسجل السجل المنتجات التي حدّثت، ولا يقيس حركة المرور، ولا يحدد من يحق له الاستماع.

هذه النحافة مناسبة للوظيفة. تكفي طبقة مشتركة تقول إن MADCAP لا يستخدم شريحة مضيف SSM. لا تحتاج تلك الطبقة إلى إدارة التطبيق أو سياسة المشغّل لكي تمنع تعيين المجال نفسه مرتين.

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

أزالت RFC 10028 فئة «آليتان مُجازتان رسمياً في النطاق نفسه». لم تلغ الحاجة إلى الكشف عن الفئات الأخرى وحلها. تحويل النتيجة إلى عبارة «انتهت تصادمات البث المتعدد» سيهدم الدقة التي حققها السجل.

نطاق SSM لا يخلق SSM

نطاق تخصيص المضيف مقيّد بـSource-Specific Multicast. في SSM تتحدد القناة بالزوج (S,G)، أي المصدر والمجموعة. تشرح RFC 4607 أن مصدرين مختلفين يستطيعان إعادة استخدام القيمة نفسها لـG لأن القناتين الكاملتين مختلفتان. يقل بذلك عبء جعل كل مجموعة فريدة عالمياً.

إلا أن الإحداثي S لا يخرج من الرقم تلقائياً. يجب أن يعرف التطبيق المصدر، وأن يدعم المضيف الاشتراك المحدد بالمصدر عبر IGMPv3 أو MLDv2، وأن يحافظ الموجّه المعيّن ومجال PIM على هذه الدلالة. توصي RFC 8815 بـSSM للبث المتعدد بين المجالات، لكنها تعد دعم التطبيقات والأنظمة جزءاً فعلياً من الانتقال.

تنص RFC 10028 على أن دعم SSM ليس شاملاً. اختيار قيمة من 0xF0000000-0xFCFFFFFF في شبكة قديمة لا يفعّل MLDv2 ولا ينشئ حالة PIM ولا يعرّف المصدر للتطبيق ولا يثبت شرعيته. صحة المجال وصلاحية القناة حقيقتان منفصلتان.

تفيد هنا قاعدة Heng Lu حول «المواصفة الأولية الدنيا» و«أولوية الكود العامل». يحدد المشترك الحد الأدنى اللازم للتشغيل البيني؛ تبقى الخيارات التالية محلية؛ ويثبت التبنّي والسلوك الفعلي أن التغيير صار واقعاً. لا يعني ذلك مساواة سجل بروتوكولي لدى IANA بسجل إنترنت إقليمي، بل يعني منع السجل من ادعاء ما لا تراه إلا الشبكة.

خريطة MADCAP القديمة قد تبقى في البرمجية

قلّصت RFC 10028 مجال MADCAP إلى جزء صغير من المجال السابق. تذكر أن المؤلفين كانوا يعرفون تنفيذاً واحداً ولا يعرفون نشرات واسعة النطاق وقت الكتابة. عبارة «لا نعرف» ليست مسحاً كاملاً. هي حد للدليل المتاح، ولا يجوز تحويلها إلى يقين بعدم الوجود.

يجب تحديث أي تنفيذ قائم ليستخدم 0x80000000-0x8FFFFFFF، أو عزله في بيئة لا توجد فيها بروتوكولات تخصيص IPv6 multicast أخرى. لا تعيد صفحة IANA كتابة ملف تنفيذي قديماً، ولا تصلح جهازاً انتهى دعمه، ولا تغير إعداداً منسوخاً منذ سنوات.

ينبغي أن يربط إيصال الهجرة الرقم بمن أنشأه: اسم allocator ونسخته، الآلية، الإعداد، لقطة القاعدة، الوقت والنتيجة المرصودة. إذا حفظ السجل عنوان IPv6 فقط، فقد يعجز التحقيق عن التمييز بين MADCAP قديم ومضيف SSM ملتزم وتطابق في الإسقاط أو انقسام شبكي أو إساءة متعمدة.

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

وصل الإعلان بالمشاهدة

تثبت وثيقة RFC قرار IETF. تثبت صفحة IANA الحالة العامة المنشورة للسجل. يثبت اختبار تنفيذ أن allocator بعينه بقي داخل شريحته. يثبت اختبار (S,G) ومشاهدة الحزم سلوكاً في مسار وزمن محددين. ويثبت سجل الهوية أو الوصول شرعية المصدر أو تفويض المستمع.

لا يرث أحد هذه الأدلة بقية الادعاءات.

لا يقيس قيد IANA نسبة التبنّي. لا يثبت عنوان SSM أن المسار يدعمه. لا يثبت وصول الحزمة أن مرسلها مخوّل. ولا يضمن اختبار بلا تصادم كل النطاقات والطوبولوجيات وحدود العتاد.

يكفي دفتر تشغيل رشيق: allocator ونسخته، الآلية، Group ID والعنوان الكامل، نسخة RFC ولقطة IANA، متطلبات SSM، طريقة كشف التصادم وتصنيفه، مشاهدة التوجيه، تحقق المصدر، تفويض المستمع، ومسؤول التراجع. يجب أن يلتزم كل حقل بحد شهادة صاحبه.

لم يعد McBride وKarstens وFarinacci بأن جدولاً سيشغّل البث المتعدد. أوقفوا المواصفة عن صناعة تداخل يمكن تجنبه. فتحوا مكاناً لآليات لاحقة من دون أن تورث خطأ الخريطة القديمة.

جعل السجل التعايش ممكناً. وعلى الشبكة أن تثبت أنه حدث.

المصادر