الخلاصة

  • نُشرت المراجعة 01 من draft-dong-sidrops-rpki-rtr-moa-pdu في 9 سبتمبر 2026، وأضافت سحباً كلياً وجزئياً للمجموعات الموزعة على عدة وحدات PDU، إلى جانب Refresh وRetry وExpire وSerial Number. وهي ما زالت Internet-Draft فردية نشطة، لا وثيقة عمل اعتمدتها SIDROPS ولا معياراً أقره IETF.
  • ينص المشروع على أن ترتيب التحقق وسلوك fallback بين MOA وROA الخاص بـIPv6 سيعالجان في مواصفة تحقق متوقع أن ترافق ملف MOA. الحد الأدنى المطلوب هو مصفوفة نتائج علنية للمستويين، لا أمراً مركزياً جديداً يقرر سياسة التوجيه لكل شبكة.

قد يحمل MOA واحد موقّع تفويضاً لبادئة ربط IPv6 كي تنشئ ربطاً لأربع بادئات IPv4. إذا كانت القائمة كبيرة، يستطيع المخبأ تقسيمها بين رسالتين. وعندما يُسحب لاحقاً عنصر من كل رسالة قديمة، هل يتعين على الموجّه تذكر شكل التقسيم الأول كي يحذف الحقين الصحيحين؟

تجيب المراجعة 01 بالنفي. عند السحب الكامل، يجوز للمخبأ إرسال كل البادئات في PDU واحدة أو إعادة استعمال المجموعات الجزئية السابقة. وعند السحب الجزئي، يجب أن يحتوي اتحاد رسالة أو أكثر على البادئات المسحوبة بالضبط، من دون زيادة. يحذف الموجّه هذا الاتحاد من قاعدة MOV المحلية، ولا يشترط تساوي عدد رسائل السحب مع عدد رسائل الإعلان.

هذه ليست حيلة في الترميز. إنها تفصل التفويض الدائم نسبياً عن العبوة المؤقتة التي اختارها النقل. طريقة تقسيم القائمة لا تنشئ صلاحية ولا تجعل سحبها مرهوناً بتاريخ الحزم.

لم تتضمن المراجعة 00 تلك القواعد. ويبين الفارق الرسمي بين 00 و01 كذلك إضافة ترتيب معياري للبادئات، وقسم لدورة الحياة، وحد صريح لما تغطيه هذه الوثيقة من التحقق.

الاسم لا يمنح الوثيقة صفة مجموعة العمل

تصف صفحة Datatracker وواجهة الوثيقة البرمجية النص بأنه تقديم فردي نشط. لا يسجلان stream تابعاً لـIETF، ولا Area Director مسؤولاً، ولا shepherd، ولا مستوى معيارياً مستهدفاً. يوثق السجل التاريخي نسخة Guozhen Dong الجديدة في 9 سبتمبر، وتحفظ واجهة التقديم أسماء المؤلفين والتواريخ.

وجود sidrops في اسم المشروع يشير إلى المجال الذي يستهدف النقاش فيه، ولا يثبت اعتماد المجموعة. أما ملف MOA الذي يستشهد به فهو وثيقة SIDROPS Working Group بالفعل. لا تنتقل تلك الصفة آلياً عبر الإحالة. كما أن طلب قيمة PDU من IANA، وهي ما زالت TBD، ليس تخصيصاً منجزاً.

خمس طبقات لا يجوز اختصارها إلى كلمة «موثوق»

في البداية ينشئ صاحب العناوين MOA موقّعاً. يصف ملف MOA في المراجعة 04 تفويض بادئة ربط IPv6 بإنشاء ربط لبادئة IPv4 واحدة أو أكثر. وإذا أريد تفويض عدة بادئات IPv6 للمجموعة نفسها، يلزم إصدار عدة كائنات MOA. الكائن يحدد حقاً، وليس مسار BGP ولا نتيجة تمرير.

بعد ذلك يتحقق برنامج relying party من الكائن. يطبق اختبارات RFC 6488، ثم يتأكد من وقوع كل بادئة IPv4 داخل امتداد تفويض موارد IP في شهادة الكيان النهائي. ويصرح الملف بأن بنية RPKI تقدم authorization، لا إثبات هوية شخص ولا non-repudiation.

ثم يحول المخبأ MOA صالحاً إلى PDU مرتب. تلك صورة مشتقة مهيأة للموجّه. حماية جلسة المخبأ والموجّه لا تستبدل التوقيع ولا تحقق موارد الكائن الأصلي.

تأتي بعد ذلك قاعدة MOV المحلية في الموجّه. يعرّف RFC 8210 Serial Number بأنه نسخة منطقية لمخبأ واحد. لا تقارن الأرقام بين مخبأين أو نسختين من البروتوكول، وقد لا تستمر بعد reset. يحدد Protocol Version وSession ID وSerial Number معاً إن كان تاريخان قابلين للمقارنة؛ ولا يثبت أي منها وحده إرادة صاحب المورد.

وأخيراً يصل إعلان BGP من نوع 4map6. تفحص المراجعة 06 من 4map6 إمكان الوصول إلى بادئة الربط، وتحدّث Mapping rule Database، وتطبق قيود توزيع محلية. أما ما حدث فعلاً في RIB وFIB وحركة الرزم فيحتاج دليله الخاص.

كذلك لا يمثل ROA اسماً آخر لـMOA. يصف RFC 9582 تفويض نظام مستقل بإنشاء مسارات لبادئات عناوين. أما MOA المقترح فيفوض بادئة IPv6 بإنشاء ربط لبادئات IPv4. قد تشترك الأداتان في RPKI، لكن الفعل المفوض مختلف.

السحب ليس انتهاء صلاحية

تطبق المراجعة الجديدة مؤقتات RFC 8210. عندما ينتهي Refresh، يرسل الموجّه Reset Query، وينبغي أن يواصل مؤقتاً استخدام بيانات MOA المثبتة وهو ينتظر الرد. إذا فشل الطلب، يحاول بعد Retry. وإذا لم ينجح التحديث قبل Expire، فعليه حذف كل بيانات MOA ووقف قرارات MOV المبنية عليها إلى أن تعود صلة المخبأ.

ويجب أن يصاحب تغير بيانات MOA ارتفاع في Serial Number، بحيث يمكن كشف منظر قديم أو غير متزامن داخل سياق جلسة قابل للمقارنة.

السحب رسالة عن تغير تفويضات بعينها. أما الانتهاء فهو حد محلي لاستخدام مشهد كامل لم يعد الموجّه قادراً على تحديثه. قد يزيل السحب الجزئي بادئتين ويبقي غيرهما؛ أما تجاوز Expire فيخرج مدخل MOA كله من القرار مؤقتاً.

ولا يثبت أي منهما وحده أن إعلان 4map6 سُحب، أو أن FIB تغيرت، أو أن الرزم استعادت وجهتها. يجب إبقاء الكائن الموقّع، ورسالة المخبأ، ومدخلة MOV، ومسار BGP، ومشاهدة الرزم أدلة منفصلة.

عند التقاء الدليلين تتوقف المواصفة الحالية

ينبه ملف MOA إلى أن تفويض صاحب IPv4 قد يكون صحيحاً، بينما ينشئ طرف ثالث بادئة IPv6 الأساسية بصورة خبيثة. لهذا يوصي أيضاً بالتحقق من ROA الخاص بـIPv6.

يعيد مشروع PDU ذكر هذا الاعتماد، ثم يقول إن التفاعل التفصيلي بين MOA وIPv6 ROA، بما فيه ترتيب التحقق وfallback، خارج نطاقه. ويتوقع أن تعالجه مواصفة تحقق MOA مرافقة للملف.

عند إغلاق البحث، أظهرت عمليات البحث العامة في Datatracker عن MOA في أسماء الوثائق وMapping Origin في عناوينها ملف MOA ومشروع PDU ومواد اجتماعات، لكنها لم تظهر وثيقة جارية تحمل وظيفة التحقق المذكورة. هذه نتيجة محدودة بالسجل العام؛ لا تثبت غياب قواعد داخلية لدى المطورين ولا تمنع ظهور مشروع لاحق.

المسائل المؤجلة عملية جداً. ماذا يفعل الموجّه إذا كان MOA Valid ونتيجة ROA لـIPv6 هي Invalid؟ ماذا يعني NotFound؟ هل يمنع التثبيت، أم يخفض الأفضلية، أم يترك التقييم معلقاً، أم يحيله إلى سياسة المشغّل؟ وإذا بقيت بيانات MOA داخل مدة Expire لكن مسار IPv6 تغير، فأي وقت مشاهدة يحكم؟ وبعد عودة المخبأ، ما الاختبارات التي تسبق إعادة الربط؟

لا يجيب Serial Number عن هذه الأسئلة. فهو يرتب نسخ مخبأ واحد في سياق واحد، ولا يرتب سلطتين ولا يختار سياسة شبكة. السحب الدقيق يحدد ما سيحذف؛ ولا يحدد ما ينبغي تصديقه.

يقصر مشروع 4map6 الاستخدام الأول على بيئة مضبوطة يديرها مشغّل واحد أو قلة متعاونة. ويقول إن الاتساع سيحتاج إلى آلية authentication مخصصة في وثيقة أخرى. يمكن لاتفاق محلي أن يسد الفراغ في شبكة صغيرة، شرط ألا يقدم على أنه قاعدة عالمية للبروتوكول.

مصفوفة ثنائية المستوى تكفي كبداية

ليس من الضروري توسيع PDU. يمكن للمواصفة المرافقة أو ملف تشغيل علني أن ينشر مصفوفة نتائج ثنائية المستوى.

ينبغي لكل صف أن يربط نتيجة MOA وسببها بعنوان المخبأ وProtocol Version وSession ID وSerial Number ووقت المشاهدة، ثم يضيف نتيجة ROA لبادئة IPv6. بعد ذلك يحدد ترتيب الاختبارات؛ وهل تحجب نتيجة الأخرى أو تخفضها أو تتركها غير منفذة؛ والحالة المحلية المبقاة أو المحذوفة؛ ونسخة سياسة المشغّل؛ والفعل؛ وشرط الاستعادة.

تغطي المصفوفة في حدها الأدنى MOA صالحاً مع IPv6 Valid وInvalid وNotFound؛ وMOA غير صالح أو منتهي؛ وبيانات مخبأ قديمة قبل Expire وبعده؛ والسحب الجزئي والكامل؛ وreset؛ والمزامنة بعد إعادة الاتصال. يجب ألا يتحول NotFound إلى Valid، ولا يسجل اختبار لم ينفذ بوصفه ناجحاً.

يتبع هذا الاقتراح حد Minimum Initial Specification لدى Heng Lu: توحيد أقل سطح يلزم للتنسيق، مع بقاء القرار النهائي محلياً. ويضيف Running Code Primary ضرورة الاحتفاظ بدليل القاعدة التي نُفذت فعلاً. المصفوفة اقتراحي التحريري، لا نصاً أقره IETF أو SIDROPS أو المؤلفون.

أنجزت المراجعة 01 خطوة مفيدة: أصبح التفويض قادراً على الخروج من قاعدة الموجّه من دون الارتهان لتغليفه القديم. على النص التالي أن يوضح بالدقة نفسها كيف يعود عندما يختلف دليلان.

المصادر