الخلاصة

  • يسجل تاريخ IETF إصدار draft-ietf-pim-gaap-23 في 3 سبتمبر 2026 وينقل الوثيقة إلى AD Followup؛ وهي ما زالت مسودة إنترنت تجريبية وليست RFC معتمدة.
  • تلزم النسخة 23 تطبيقات IPv4 باستخدام 239.0.0.0/10 وتطبيقات IPv6 باستخدام نطاق Experimental Use في RFC 10028، حتى تبدأ التطبيقات المكتوبة بصورة مستقلة من مساحة حساب واحدة.
  • تقر المسودة في الوقت نفسه بأن أحد جانبي الانقسام قد يختار المرشح +1 للاسم نفسه، بينما يختار الجانب الآخر +2. وبما أن العنوانين مختلفان، لا يقع تصادم وقد تظل المجموعة منقسمة بعد عودة الاتصال.
  • غياب التصادم ملاحظة سلبية، وليس إثباتاً إيجابياً على أن الاسم والعنوان والمشاركين عادوا إلى نقطة التقاء واحدة.
  • يمكن لوصل محلي يثبت تقارب اسم المجموعة أن يحفظ الدليل. هذا اقتراح تحليلي من Daniel Kade، لا شرط من IETF أو من المسودة.

نطاق مشترك يغلق خلافاً في الإعداد

يؤرخ سجل الوثيقة النسخة 23 من Group Address Allocation Protocol في 3 سبتمبر. وفي اليوم نفسه تغيرت الحالة الفرعية من Revised I-D Needed إلى AD Followup، وعادت مراجعة IANA إلى Version Changed - Review Needed. هذه مراحل في عمل لم يكتمل؛ فلا هي موافقة من IESG ولا نشر لوثيقة RFC.

يقول سجل التغييرات في النسخة 23 إنها عالجت موقف DISCUSS وتعليقات Éric Vyncke. أما الخبر الأهم فيظهر عند جمع تعديلين مختلفين: أزيل سبب يمكن تفاديه لاختلاف التطبيقات، وفي الوقت نفسه صار سبب آخر لاختلاف الحالة مكتوباً بوضوح من دون أن يُحل.

يقترح GAAP أن يحصل المشاركون في البث المتعدد على عنوان مجموعة من غير خدمة تخصيص مركزية. يقدم التطبيق اسم المجموعة، ثم يحسب البروتوكول أربعة مرشحين فقط بواسطة SHA-256: الاسم الأصلي، ثم الاسم متبوعاً بـ +1 أو +2 أو +3. يرسل العقدة رسالة Claim للمرشح الأول وينتظر دورة دورية واحدة تقريباً، أي نحو دقيقة. إذا لم تصله مطالبة تستخدم فيها تسمية أخرى عنوان طبقة الشبكة نفسه، جاز للتطبيق بدء الاستخدام. وإذا وقع التصادم انتقل إلى المرشح التالي.

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

تظهر المقارنة الرسمية بين النسختين 22 و23 التغيير. كان المشغل يضبط نطاق العناوين المخصص للتطبيق. أما النص الجديد فيرى أن النطاق القابل للضبط لا يضمن التوافق إلا مع ضبط مماثل؛ فالمشغل يستطيع اختيار التطبيقات التي تعمل في نطاقه، لكنه لا يتحكم في أي تطبيق مستقل لـ GAAP أدمجه مطور كل برنامج.

لذلك يجب على IPv4 استخدام 239.0.0.0/10. وتحيل المسودة إلى RFC 2365 بشأن الكتل المتاحة لتوسيع نطاق Organization-Local، وإلى RFC 5771 بشأن قواعد تخصيص عناوين البث المتعدد. أما IPv6 فيستخدم 0xFE000000–0xFEFFFFFF، وهو نطاق Experimental Use الذي خصصه RFC 10028 لتجارب بروتوكولات التخصيص الديناميكي الجديدة. ولا ينفرد GAAP بهذا النطاق؛ إذ يمكن لتجارب أخرى استعماله أيضاً.

تثبيت النطاقين خطوة حقيقية نحو قابلية التشغيل البيني. فلن يبدأ تطبيقان متوافقان بالحساب في عالمين منفصلين من العناوين. لكن وجودهما في مساحة مرشحين واحدة لا يجبرهما على اختيار المرشح نفسه لاسم بعينه.

قد يحتفظ الاتصال المستعاد بإجابتين صحيحتين محلياً

تعالج آلية إصلاح الانقسام الحالة الظاهرة أولاً. فإذا استخدم الجانبان العنوان نفسه لاسم مجموعة، التقت رسائل Claim بعد رجوع الاتصال وأصبح بوسع الإجراء مقارنة الحالة وحسمها.

أما الحالة التي أضيفت إلى النسخة 23 فأهدأ. افترض أن تصادماً محلياً لا علاقة له بالانقسام دفع الاسم المشترك في الجانب الأول من المرشح الأساسي إلى +1. وفي الجانب الآخر دفع تصادم مختلف الاسم نفسه إلى +2. كلا القرارين من القائمة المغلقة للمرشحين، وقد يكون سليماً داخل جزئه من الشبكة.

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

كان Vyncke قد طرح السؤال نفسه في تصويته لدى IESG: إذا استخدمت الشبكتان المنقسمتان +1 و+2، فهل سيُكتشف الأمر وهل سيتقارب الجميع؟ جعلت المراجعة الجديدة الحد جزءاً معلناً من النص، لكنها لم تحدد بعد آلية التقارب.

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

يطالب RFC 10019، وهو بيان المشكلة الذي يستشهد به GAAP، بأن يكتشف التخصيص اللامركزي تصادمات العناوين التي تنشأ أثناء انقسام مؤقت وأن يحلها. تظل هذه المهمة مهمة. إلا أن الحد الجديد مجاور لها ومختلف عنها: إنه اختلاف ربط الاسم، لا تصادم العنوان. ومن ثم يجب تسجيل «حُل التصادم» و«تقارب الاسم» نتيجتين منفصلتين في التجربة.

التجربة تحتاج إلى دليل إيجابي على الالتقاء

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

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

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

هذا الوصل اقتراح تحريري مني، وليس نصاً في GAAP أو سياسة لـ IETF أو IANA أو مجموعة PIM. غايته منع تحويل غياب علامة سيئة إلى إثبات لخاصية جيدة لم تُقَس.

يساعد تمييز Lu Heng في Minimum Initial Specification, Localized Future Decision على إبقاء الحل لامركزياً. فالنطاق الثابت هو القاعدة المشتركة الدنيا التي تحتاجها التطبيقات المستقلة كي تلتقي. ويمكن لوسائل اكتشاف الحالة النادرة وتسجيلها وإصلاحها أن تتطور محلياً أثناء التجربة، ما دامت النتائج قابلة للمقارنة ولا تضيع.

أما Running Code Primary فيحدد معيار الإثبات. فتغير حالة الوثيقة أو تخصيص من IANA أو رفع موقف DISCUSS يغير السجل المؤسسي. لكنه لا يبرهن أن تطبيقين واجها تصادمين محليين مختلفين سيعودان إلى ربط واحد. يتطلب ذلك اختباراً ينشئ الانقسام، ويفرض +1 و+2، ويعيد الرابط، ويحفظ ما استعملته كل عقدة فعلاً.

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

المصادر

  1. سجل GAAP في Datatracker
  2. تاريخ وثيقة GAAP
  3. GAAP، النسخة 23
  4. GAAP، النسخة 22
  5. المقارنة الرسمية بين النسختين 22 و23
  6. تصويت IESG على GAAP
  7. RFC 10019: مشكلة تخصيص عناوين البث المتعدد من دون إعداد
  8. RFC 10028: معرفات مجموعات البث المتعدد الديناميكية في IPv6
  9. RFC 2365: البث المتعدد بنطاق إداري
  10. RFC 5771: إرشادات IANA لعناوين البث المتعدد IPv4
  11. Lu Heng — Minimum Initial Specification, Localized Future Decision
  12. Lu Heng — Running Code Primary