الخلاصة

  • تضع خارطة منتجات APNIC بند «Route management alignment» في الربع الثالث من 2026 لأتمتة المواءمة بين إدارة المسارات وحيازة الموارد وWhois وRPKI بعد النقل وإلغاء التخصيص وتغييرات الأنظمة.
  • لا تمثل هذه الطبقات نسخا من حقيقة واحدة: الحيازة تمنح سلطة السجل، وroute object في IRR يعلن سياسة أو نية، وROA تفوض AS كمصدر، أما BGP فيعرض مسارا مرصودا تخضع معاملته لسياسة كل شبكة.
  • لا يحدد البند العام أولوية السجلات عند التعارض، ولا حدود المعاملة، ولا حالة النجاح الجزئي، ولا الإشعار أو دليل rollback. هذا نقص في الوصف العام، وليس دليلا على غياب تصميم داخلي لدى APNIC.
  • يمكن لمصفوفة أولوية خاصة بكل نوع سجل، مع إيصال مهمة ذي نسخة يحفظ الحالة السابقة والسلطة والسبب وخطوات الفشل، أن تقلل العمل اليدوي من دون محو الاختلافات المشروعة.

ليست المزامنة ساعة واحدة

تبدو كلمة alignment إدارية ومحايدة. قد تعني مقارنة عمودين، إزالة فرق، ثم وضع علامة خضراء. لكن بند APNIC يجمع أربعة أسطح تملك آثارا تشغيلية مختلفة. فإذا اختلفت، لا يستطيع البرنامج أن «ينظف» البيانات من دون أن يقرر أي حالة تبقى وأيها تحذف أو تؤجل أو تعرض للمراجعة.

ينتمي بند «Route management alignment» إلى فريق Registry، ويحمل هدف Q3 لعام 2026 وعلامات ARMS وRPKI وWhois. ويقول الملخص إن APNIC ستؤتمت المواءمة مع حيازة الموارد، لتقليل التسوية اليدوية المرهقة والمعرضة للخطأ بعد عمليات النقل وإلغاء التخصيص وتغييرات النظام.

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

إلا أن السجلات لا تتكرر فقط. لكل واحد منها سؤال مختلف. عندما تختلف الإجابات، تتحول قاعدة المزامنة إلى توزيع للسلطة: من يحق له تعديل مورد؟ ما السياسة التي يقرأها مزود لبناء filter؟ ما الأصل الذي تعتبره RPKI مفوضا؟ وما المسار الذي تراه الشبكات فعليا؟

يحتوي السجل المنظم لخارطة الطريق على السنة والربع والفريق والمنتجات والملخص والحل المقترح، بينما يبقى changelog فارغا. لا تظهر فيه قاعدة precedence، أو حد المعاملة العابرة للأنظمة، أو تعريف للفشل الجزئي، أو مسار rollback، أو إخطار العضو، أو نطاق NIR وIRR خارجي. قد تكون لدى APNIC وثائق داخلية تتناول بعض ذلك أو كله. لا تسمح الأدلة بالقول إنها غير موجودة. الملاحظة الأضيق هي أن الالتزام العام لم يتضمنها بعد.

الحيازة لا تعني أن المسار معلن

يسأل سجل الحيازة: أي حساب أو مؤسسة يعترف بها السجل بوصفها صاحبة سلطة على كتلة عناوين أو ASN؟ وقد يحدد ذلك من يستطيع إدارة الخدمات المرتبطة. لكنه لا يحدد تلقائيا أي AS ينبغي أن يعلن كل بادئة الآن.

يسأل Internet Routing Registry سؤال السياسة. تصف APNIC الـIRR بأنه مجموعة موزعة من قواعد البيانات ينشر فيها المشغلون سياساتهم وإعلاناتهم، ويمكن لشبكات أخرى استخدامها لبناء المرشحات والإعدادات. ويشترط RFC 2725 تفويضا للبادئة وAS المصدر معا عند إنشاء route object. كما يعترف بحالات تعدد المصادر لنفس البادئة، وتداخل البادئات الأكثر تحديدا، وتغيير المزود وفترات إعادة الترقيم.

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

تجيب RPKI عن سؤال تفويض تشفيري أضيق. يعرّف RFC 9582 الـROA بأنها كائن موقع يسمح فيه حامل مساحة العناوين لـAS واحد بأن يكون مصدر مسارات لبادئات محددة. وعند تفويض عدة ASes تصدر عدة ROAs. يثبت الكائن الإذن ضمن سلسلة الشهادات؛ لكنه لا يثبت أن الإعلان قائم الآن، أو أن الوجهة قابلة للوصول، أو أن router بعينه سيقبل المسار.

أما BGP فيقدم الملاحظة التشغيلية. يشرح RFC 6483 كيفية مقارنة البادئة وorigin AS في مسار مستلم مع ROAs الصالحة للوصول إلى Valid أو Invalid أو Unknown. ويترك الإجراء المتخذ تجاه هذه النتائج للسياسة المحلية. تستطيع جهة السجل نشر التفويض، لكنها لا تختار المسار في كل شبكة.

حتى الزمن ليس واحدا. ينبه RFC 6483 إلى أن انتشار كائنات RPKI قد يختلف عن انتشار المسارات. ربما نشرت ROA جديدة ولم يصل إليها cache محلي بعد. وربما ظهر إعلان قبل اكتمال الالتقاط. ويمكن تفويض مصدر احتياطي قبل استخدامه. لذلك قد يكون الاختلاف المؤقت مرحلة سليمة، لا بيانات فاسدة.

الحيازة وroute object وROA وBGP أدلة على السلطة والنية والإذن والسلوك. هي مترابطة، لكنها غير قابلة للاستبدال.

دليل 2017 حافظ على التعارض بدلا من إخفائه

يوفر Route Management Guide الذي نشرته APNIC عام 2017 تاريخا مفيدا للمشكلة. قدم الوثيقة يمنع استعمالها كمواصفة حالية لمشروع 2026. لكنها تكشف أن واجهة سابقة فرقت بالفعل بين النية المدارة في MyAPNIC والكائن المنشور في Whois.

كانت «route» في MyAPNIC نموذجا لإنشاء route object فعلي في Whois. وكان من الممكن وجود كل منهما من دون الآخر: نموذج لا يملك كائنا عاما، أو كائن Whois لا تديره route في MyAPNIC. وعندما يتغير كائن Whois من قناة أخرى، لا ينسخ النموذج التغيير بصمت. تظهر حالة conflict، ويختار المستخدم قبول التغيير أو إعادة كائن Whois إلى حالة النموذج.

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

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

قد يستبدل مشروع 2026 هذه الآلية بالكامل. لكن السؤال الذي أبرزته الواجهة القديمة يبقى: هل يمثل التعديل الخارجي نية أحدث ينبغي قبولها، أم حالة ينبغي التراجع عنها؟ إذا اتخذت الأتمتة القرار، فعليها أن تترك دليلا أوضح، لا أن تجعل التعارض غير مرئي.

«transactionally where possible» ليست ذرية عالمية

يقدم إعلان Registry API في أكتوبر 2024 سياقا أحدث. تستطيع الواجهة استرجاع معلومات التفويض وإدارة Whois وreverse DNS وROAs وroute objects. وتذكر APNIC مثالا لإنشاء ROA وroute object آليا عند إضافة إعلان BGP بدلا من تكرار العمل في MyAPNIC.

يحتوي الإعلان على قيد حاسم. يمكن إرسال عمليات إدارة المسار المجردة وreverse DNS في batches تنفذ «transactionally where possible». وكل التحديثات task objects غير متزامنة: يتلقى العميل رابطا، ويتابع الحالة، ثم يحصل على تفاصيل النتيجة.

تعترف عبارة «حيثما أمكن» بأن المعاملة لها حدود. قد تشترك كتابات في قاعدة بيانات واحدة في commit. لكن نشر كائن RPKI، والتقاطه لدى validator مستقل، وتحديث RIR آخر، وقبول كائن في IRR خارجي، وإعادة بناء filters لدى مزود، كلها أفعال في سلطات وساعات مختلفة. لا تحولها واجهة واحدة إلى commit موزع.

لذلك يجب أن يوضح مشروع المواءمة ما يقع خارج الذرية. إذا نجح تحديث Whois وفشلت ROA المقصودة، فلا تكفي كلمة Failed لمعرفة ما إذا كان تكرار الطلب آمنا. ينبغي أن تظهر المهمة الخطوة المنفذة، والخطوة الفاشلة، وآخر حالة آمنة، وشروط retry، وأي إجراء تعويضي أو quarantine.

كذلك لا ينبغي أن تعني Completed أن كل caches والشبكات رأت النتيجة. قد تعني فقط أن APNIC أنهت أفعالها. يجب فصل committed عن published وعن observed.

لا تثبت هذه القراءة أن API الحالية أخفقت في مثل هذه الحالة. أهميتها أن لغة APNIC العامة تضم بالفعل batch ومعاملة محدودة ومهمة غير متزامنة ونتيجة. يمكن توسيع هذه اللغة لتصف المواءمة الجديدة بدقة.

النقل يغير الحق قبل أن يحدد السياسة

تنص Transfer Conditions الحالية لدى APNIC على أنه في النقل الصادر بين RIRs تحذف من قاعدة Whois التابعة لـAPNIC الكائنات المرتبطة بالمورد، ومنها sub-assignments وroute objects وdomain objects. وبعد اكتمال النقل تفقد الجهة الأصلية حقوقها في عناوين IP وموارد ASN، وتسجل الموارد للجهة المستلمة.

تسمي الفقرة كائنات Whois. ولا تقول ماذا يحدث للـROAs. لا يجوز تحويل هذا الصمت إلى ادعاء بأنها تحذف أيضا. بل يوضح الحد أن إزالة سلطة المصدر وكائناته العامة ليست القرار نفسه المتعلق بالتفويض الذي يريده حامل المورد الجديد.

إذا استمر المستلم في استخدام origin AS نفسه، تتغير الحيازة ولا تتغير النية التشغيلية بالضرورة. وإذا انتقل إلى AS جديد، فقد يحتاج إلى تجهيز التفويض الجديد قبل سحب المسار القديم. وإذا عبر النقل إلى RIR آخر، فقد يحدث حذف المصدر وظهور سجل الوجهة على ساعتين مختلفتين. هذه سيناريوهات لاختبار التصميم، وليست حوادث منسوبة إلى APNIC.

الحذف أولا قد ينشئ فترة Invalid أو NotFound يمكن تجنبها. والاحتفاظ المفتوح قد يبقي سلطة قديمة. ونسخ BGP المرصود إلى ROA يحول السلوك إلى إذن من دون قرار الحامل. لا توجد حركة واحدة آمنة لكل نقل.

ينبغي أن يفكك النظام كلمة aligned إلى حالات: prepared لتغيير مفوض لم يصبح نافذا؛ committed لكتابة قبلها السجل؛ published لكائن صار متاحا؛ observed لفحص مستقل رآه؛ retired لحالة قديمة توقفت عن منح السلطة. لكل مرحلة دليل ومالك.

اختلافات يجب على الخوارزمية احترامها

أولها تعدد المصدر المشروع. يدعم IRR وRPKI أكثر من origin. ينبغي التحقق من السلطة ونطاق البادئة بدلا من اعتبار العدد الأكبر من واحد خطأ. قد تكون إزالة مصدر احتياطي خفضا للأمان باسم النظافة.

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

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

وتضيف desalocation حدودا رابعة. تسميها خارطة الطريق ولا تحدد تسلسلها. انتهاء سلطة المورد قد يبرر السحب، لكن مهلة الإخطار والمراجعة ووضع موارد يديرها NIR لا تستنتج من كلمة واحدة. أما الكائنات في IRR خارجي فلا تقع تحت commit محلي لـAPNIC.

سلطة لكل سؤال بدلا من مصدر حقيقة واحد

يبدو شعار single source of truth مريحا لأنه يخفي النزاع. لكنه هنا يجيب عن أربعة أسئلة بسجل واحد. الحيازة مرجع لمعرفة من يحق له التصرف. والطلب المصادق عليه دليل على النية. والـIRR إعلان سياسة. والـROA تفويض للمصدر. وBGP ملاحظة. لا ينبغي لأي واحد أن يصنع معاني الآخرين.

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

ويضاف عمود للذرية: ما الكتابات التي تشترك فعلا في معاملة؟ ما الذي ينشر لاحقا؟ أين يبدأ اعتماد على مؤسسة خارجية؟ ماذا يعزل إذا نجحت خطوة واحدة؟ ومتى يستطيع المشغل تبديل الإعلان أو إعادة بناء المرشح بأمان؟

الأهم فصل إلغاء السلطة القديمة عن إنشاء نية جديدة. يمكن للنقل أن يوقف حساب المصدر عن التعديل، لكنه لا يسمح لـAPNIC بتخمين AS الذي اختاره المستلم. وقد تطلق ملاحظة BGP تحذيرا، لكنها لا ينبغي أن توقع ROA.

إيصال يبقى بعد rollback

تحتاج كل مهمة مؤثرة إلى إيصال ذي نسخة. يبدأ بمعرف الحدث والمهمة ونوع trigger ووقته، ثم snapshot الحيازة الذي استخدم للتحقق من سلطة الطالب. ويعرض، كل على حدة، الحالة السابقة واللاحقة لنموذج المسار وroute objects في Whois وROAs.

يحمل كل تغيير قاعدة precedence خاصة بنوعه وreason code. ويرسم الإيصال حدود المعاملة: الكتابات التي committed معا، والمنشورات التي ما زالت pending، والأنظمة الخارجة عن سلطة APNIC. في النتيجة الجزئية يسجل الخطوة الناجحة والفاشلة وآخر حالة آمنة وشروط retry وquarantine والإجراء التعويضي.

وللرؤية مواقيت منفصلة: متى أمكن الاستعلام عن Whois، ومتى نشر كائن RPKI، ومتى لاحظه تحقق مستقل. ويمكن إرفاق BGP كإشارة، لا كأمر أو ضمان للوصول.

تظهر inter-RIR وNIR وإلغاء التخصيص وIRR الخارجي كعلامات نطاق. ويسجل الإشعار والتأكيد ومسار المراجعة وoverride ومالك الخدمة من دون كشف مفاتيح أو بيانات شخصية غير ضرورية. ويضيف rollback نتيجة جديدة مرتبطة بالمهمة الأصلية ولا يمحوها.

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

تستحق أتمتة العمل اليدوي الدعم. لكن اتساق البيانات لا يثبت صحة الحكم الذي صنعه. قبل أن تختار الآلة الفائز في التعارض، ينبغي أن تجعل APNIC قاعدة الاختيار ونتيجتها قابلتين للقراءة.

المصادر