الخلاصة

  • يحدد إعلان APNIC يوم 29 سبتمبر 2026، من العاشرة إلى الثانية عشرة بتوقيت UTC+10، لتحديث بيئة شبكة GCP المستخدمة في DASH وnotification.apnic.net وREx وخدمة AS0 ROA. وينص على أن التوقف غير متوقع. هذه توقعات لنافذة لم تبدأ بعد، وليست قياساً لحداثة كل سجل أو خبراً عن انقطاع.
  • تنص سياسة موارد الأرقام الحالية، الفقرة 5.1.4، على إصدار بيانات ROA بأصل AS0 للمساحات التي تديرها APNIC ولم تُفوَّض، والمصنفة Available أو Reserved، وعلى إزالة البادئة من AS0 عند تفويضها. لا تنص تلك الفقرة على مهلة تحديث محددة لعام 2026.
  • وصفت APNIC في تقرير نشر الخدمة سنة 2020 هدفاً لإزالة البادئة وإعادة النشر خلال أقل من خمس دقائق في الظروف العادية. هذا وصف تاريخي للتصميم والتنفيذ آنذاك، لا اتفاق مستوى خدمة حالي ولا نتيجة لصيانة لم تقع.
  • تستخدم الخدمة ملف تحديد مرساة ثقة منفصلاً، TAL، لا يضاف إلى أدوات التحقق إلا بقرار من المشغل. توصي APNIC باستعمال AS0 للتنبيه أو المشورة، لا بالتصفية الآلية لمسارات BGP. أي أثر على مسار بعينه يعتمد على التحقق وسياسة الشبكة التي تتلقى البيان.

أربعة أسماء لا تعني حالة تشغيل واحدة

تُظهر صفحة تحديثات الخدمة أن الإعلان نُشر في 24 سبتمبر؛ موعد العمل بعده بخمسة أيام. لم تذكر APNIC أن الخدمات الأربع تشترك في قاعدة بيانات واحدة أو منظومة توقيع واحدة أو نقطة تعطل واحدة. ذكرها معاً يعني أنها ضمن نطاق تحديث البيئة الشبكية المعلن. أما اعتذارها المعتاد في نهاية النص عن إزعاج قد يسببه «انقطاع»، فلا يمثل شهادة على وقوع انقطاع، ولا يلغي العبارة المحددة التي تتوقع عدم التوقف.

هناك إعلان آخر بتاريخ 31 يوليو 2025 يورد الأسماء الأربعة نفسها عند ترقية Kubernetes، مع توقع مماثل بعدم توقف الخدمة. تكرار القائمة يوضح أن APNIC تعامل AS0 بوصفه جزءاً من سطح الصيانة الذي تخبر عنه المستخدمين. لكنه لا يثبت أن بنية 2026 هي بنية 2025. سجل الإعلانات ليس مخططاً لمراكز البيانات.

ولكل خدمة سؤال مناسب. هل يمكن الدخول إلى واجهة DASH؟ هل يستجيب طرف الإشعارات كما هو متوقع؟ هل تبقى بيانات REx قابلة للاستعمال؟ وبالنسبة إلى AS0: هل البيان الموقّع الذي يُسترجع الآن يطابق آخر تغير في حالة الموارد؟ هذه أسئلة تحريرية للتحقق، وليست أهداف أداء أعلنتها APNIC لكل منتج. عنوان URL قد يستجيب بنجاح ويعيد نسخة أقدم من البيان. لا دليل هنا على حدوث ذلك فعلاً؛ لكنه فرق منطقي لا يجوز إخفاؤه خلف ضوء أخضر واحد.

لحظة خروج البادئة من «غير مفوّض»

تعطي الفقرة الرابعة من RFC 6483 لبيان ROA ذي الأصل AS 0 معنى نفي صلاحية إنشاء مسار من البادئة المبينة والبادئات الأكثر تخصيصاً. تستعمل APNIC هذا الوصف للمساحات IPv4 وIPv6 التي تديرها ولم تُفوِّضها بعد. وتربط سياستها ذلك بالحالتين Available وReserved في ملف الإحصاءات الموسّع للتفويض. عندما تنتقل بادئة إلى صاحب حساب، لا يعود من الصحيح إبقاؤها في إقرار المساحة غير المفوّضة. لهذا تشترط السياسة إزالتها.

وثّق عرض التنفيذ في APNIC 50 كيف كانت APNIC تتعامل مع تلك اللحظة في 2020. قال إن تحديثات التفويض الحية كانت تُطبّق في غضون خمس دقائق على حالتي RPKI الرئيسية وAS0؛ وذكر مكوّناً داخلياً مرتبطاً بأحداث السجل ومستودع نشر سحابياً ومراقبة مستمرة. وذكر نص الإطلاق هدفاً أقل من خمس دقائق في الأحوال العادية. لهذه التفاصيل قيمة لأنها تجعل السؤال قابلاً للقياس. لكنها لا تخبرنا هل بقيت المهلة نفسها بعد ست سنوات، أو كيف صارت البنية، أو ما الذي سيحدث أثناء صيانة سبتمبر. السياسة الحالية تُبقي واجب الإزالة واضحاً، من دون توقيت محدد في المادة التي راجعناها.

إذا حدث تفويض مناسب خلال النافذة، ينبغي وصل أربع ساعات مستقلة: وقت اعتماد التفويض في السجل المرجعي؛ وقت توليد تغطية AS0 جديدة لا تشمل البادئة؛ وقت إتاحة الجسم الموقّع الجديد؛ ووقت حصول جهة خارجية عليه. وقد تأتي ساعة خامسة تخص أداة تحقق أضافت TAL الإضافي، لأن دورية جلب المستودع لدى المشغل لا تقع تحت تحكم APNIC. تأخر الجلب الخارجي وحده لا يثبت تأخر النشر من المصدر، كما أن تأريخ النشر داخلياً وحده لا يثبت ما كان متاحاً من خارج المؤسسة. يلزم تعريف النسخ وأزمنة ملاحظتها معاً.

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

مرساة مستقلة لا تعني عزلاً مادياً

تجعل APNIC اعتماد AS0 اختيارياً بواسطة TAL منفصل. هذه وسيلة مهمة لمنع استخدام البيان من غير قصد ضمن الثقة العادية في RPKI. لكنها حدّ ثقة لدى الجهة المتلقية، لا دليل على أن أجهزة النشر منفصلة مادياً عن بيئة GCP التي سيجري تحديثها. يتحدث تقرير 2020 عن مستودع سحابي، ويتحدث إعلان 2026 عن عمل في شبكة GCP؛ لا يكفي الربط بينهما لرسم الشبكة الحالية أو افتراض عطل مشترك.

في فرضية بقاء بيان AS0 قديم يغطي بادئة فُوِّضت حديثاً، قد تستمر أداة تحقق اختارت ذلك TAL في رؤية نفي موقّع. لكن حالة المسار النهائية تتوقف على جميع بيانات ROA ذات الصلة وسلوك التحقق، ثم على قواعد التوجيه المحلية. ليس معنى وجود نفي أن حزم البيانات سقطت أو أن العالم كله رفض المسار. تحذر APNIC نفسها من أن الخطأ قد يسبب تعطلاً وفق الإعدادات، وتحث على استعمال استشاري أو تنبيهي بدلاً من المرشح الآلي. لا يثبت الإعلان أي تأخر أو تصنيف Invalid أو ضرر للمستخدمين.

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

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

المصادر