الخلاصة
- وافق IESG في 22 يونيو 2026 على وثيقة Best Current Practice تمنع تمرير حالات التحقق المشتقة من RPKI في سمات BGP عبر جلسات EBGP بين نطاقات إدارية مختلفة. والمراجعة 12 موجودة الآن في طابور RFC Editor.
- الحالة نتيجة محسوبة من بيانات وتوقيت وسياسة محلية. وضعها في سمة غير موقعة لا ينقل سلسلة الإثبات، لكنه يجعل تغيّر ROA أو تعطل cache أو انتهاء RTR سبباً لإعادة إعلان أعداد ضخمة من المسارات.
تأخر خمس دقائق يصنع حادثة ثانية
تضع الوثيقة AS65536 عميلاً لـ AS65537. يستخدم الاثنان خدمة RTR مركزية ودورة تحديث قدرها 300 ثانية، ويربطان Communities بحالة التحقق. هذا سيناريو تفسيري في النص، وليس تقريراً عن انقطاع وقع فعلاً.
يحدّث AS65536 بياناته قبل توقف الخدمة بثانية واحدة، بينما يحين تحديث AS65537 بعد التوقف بثانية. يفقد المزود الحمولة المتحقق منها أولاً، فتتحول مسارات كثيرة من Valid إلى NotFound. وبما أن Community تغيرت، يرسل UPDATE إلى عملائه، ويستقبل AS65536 تلك الموجة ويمررها.
بعد نحو 300 ثانية تنتهي رؤية AS65536 بدورها. تتغير Communities لديه، فتبدأ موجة ثانية من السبب الأصلي نفسه. يمكن لـ cache أطول عمراً أن يؤخر النتيجة، لكنه لا يلغي الانفصال إذا استمر التوقف بعد مدة TTL.
لم يلزم أن يتغير prefix أو Origin AS أو قابلية الوصول. العطل وقع في اعتماد التحقق. لكن تحويل مخرج محلي إلى جزء من هوية المسار الخارجي نقل كلفته إلى مستوى التحكم في BGP.
الكلمة تحمل الحكم وتترك الدليل
يعرّف RFC 6811 الحالات NotFound وValid وInvalid. يقارن موجه BGP المسار الذي استقبله بـ VRP مخزنة محلياً، ويطلب RFC التعامل مع النتيجة باعتبارها خاصية محلية للمسار.
وراء النتيجة عناصر لا تظهر في الكلمة: أي كائنات موقعة وصلت، وأيها اجتاز التحقق، ومتى تحدّث cache، وهل جلسة RPKI-to-Router سليمة، وكيف تستخدم السياسة المحلية النتيجة. قد تختلف رؤيتان لفترة قصيرة من غير أن تكون إحداهما مزورة.
لا تنقل Community مجموعة VRP ولا زمن التحديث ولا trust anchor ولا صحة cache ولا قاعدة القرار. يتلقى الجار الخلاصة، لكنه لا يتلقى ما يسمح له بإعادة إنتاجها.
كما أن سمات BGP المعتادة التي تعبر EBGP ليست موقعة. يستطيع طرف ثالث إضافة حالة مزعومة أو تعديلها. لذلك لا تثبت Valid الواردة من حسبها، ولا متى حسبها، ولا أنها توافق رؤية المستقبِل الحالية. إنها إشارة إلى عملية داخلية محتملة، وليست شهادة قابلة للنقل.
الحدود كانت واضحة في RFC 8097
أنشأ RFC 8097 Origin Validation State Extended Community غير متعدية كي تتشارك موجهات IBGP نتيجة داخل AS واحد. وكان الافتراض وجود ثقة وإدارة مشتركة.
افتراضياً، يجب على التنفيذ إسقاط هذه Community إذا استقبلها من peer عبر EBGP، وينبغي ألا يرسلها إلى peers عبر EBGP. والاستثناء الممكن هو AS متجاوران يخضعان للإدارة نفسها. فالحد المهم هو نطاق التحكم والمسؤولية، لا اختلاف أرقام AS وحده.
توسع الوثيقة الجديدة القاعدة لتشمل Communities العادية والممتدة والكبيرة والقيم الخاصة بالمشغل وأي سمة حالية أو لاحقة يسبب تغيرها UPDATE خارج الإدارة. وتشمل كذلك نتائج ASPA أو BGPsec المحلية إذا حاول المشغل تصديرها بالطريقة نفسها.
قد يحتاج جهاز ما إلى السمة داخلياً. عندئذ يمكن استخدامها، لكن يجب حذفها قبل إعلان NLRI إلى نطاق إداري آخر. الحاجة الداخلية لا تنشئ تفويضاً خارجياً.
نسبة صغيرة تصبح مئات الآلاف من المسارات
تستشهد الوثيقة بقياس من فبراير 2024 وجد أن 8% إلى 10% من رسائل BGP UPDATE التي رآها RIS احتوت Communities عامة تشير إلى NotFound أو Valid. كما ظهرت سلسلة تحديثات استمرت نحو ساعة بعد إنشاء كائن ROA أو حذفه. وهذه لقطة زمنية وليست نسبة ثابتة.
ولمنتصف 2026 تستخدم الوثيقة جدول IPv4 وIPv6 يضم نحو 1.3 مليون prefix، يغطي ROA قرابة 65% منها. إذا أدى تعطل RPKI cache إلى تغير الحالات وكانت الحالات تُصدَّر، فقد يلزم إعادة إرسال أكثر من 850 ألف مسار.
إعادة التحقق محلياً وظيفة سليمة. أما الهدر فينشأ حين يجعل تغير الدليل المحلي الجيران يعالجون المسار نفسه من جديد من دون أن يحصلوا على دليل قابل للتحقق. وتوزع أوقات الانتهاء هذا الحمل على موجات متلاحقة.
يمكن أيضاً استغلال الربط عمداً. من يستطيع إصدار كائنات موقعة وسحبها لعناوينه يستطيع قلب الحالات، ومن يعيد إعلان NLRI يستطيع تعديل سمات غير موقعة. وعندما تصبح الحالة جزءاً من هوية المسار الخارجي، تتحول تلك الأفعال إلى أداة churn.
على كل نطاق أن يقرر من أدلته
إذا تحققت شبكة من RPKI ورفضت Invalid فعلاً، فلا ينبغي أن تصدر تلك المسارات إلى عملائها. مجموعة المسارات المعلنة تحمل بالفعل أثر سياسة المرسل. ولا تضيف Community دليلاً موثقاً للجار.
على المستقبِل الذي يحتاج تأكيد الأصل أن يتحقق باستخدام رؤيته الحالية. هكذا تبقى الأدلة والتوقيت والقرار في نطاق مسؤولية واحد. أما اعتماد حكم الجار فيخلط التعاون بالتفويض: قد تصف شبكة ما فعلته، لكنها لا تقرر نيابة عن الشبكة التالية.
القاعدة التشغيلية ضيقة وقابلة للاختبار: جلب RPKI والتحقق منه محلياً، اتخاذ القرار محلياً، حصر سمات الحالة داخل الإدارة المشتركة، وإزالتها عند كل حد خارجي. ما يعبر هو المسار الذي اجتاز السياسة، لا رواية غير موقعة عن سبب اجتيازه.
المصادر
- IETF Datatracker — الوثيقة الحالية
- IETF Datatracker — سجل الوثيقة
- إعلان IETF — الموافقة بصفة Best Current Practice
- Internet-Draft الحالي — المراجعة 12
- RFC 6811 — التحقق من أصل prefix في BGP
- RFC 8097 — Extended Community لحالة التحقق
- RFC 8210 — بروتوكول RPKI-to-Router
- RIPE Labs — A BGP Side Effect of RPKI
- Lu Heng — Running-Code Primacy
- IETF Datatracker — تقرير مسؤول الوثيقة
- Lu Heng — Minimum Initial Specification
- Lu Heng — Reality Layers and Symbolic Power
إحاطة الأعضاء
سياق أعمق للملف الشخصي
سجّل الدخول بمستوى العضوية المناسب لفتح الإحاطة الكاملة وملاحظات المصادر.
للدائرة الاستراتيجية فقط
الدائرة الاستراتيجية
مفتوح لجميع القراء. افتح إحاطات الملف الشخصي بعد الانضمام وتسجيل الدخول.
انضم إلى الدائرة الاستراتيجيةلأعضاء تحالف القيادات فقط
تحالف القيادات
لأصحاب الأصول الفكرية المؤهلين وللإدارة؛ سجّل الدخول للوصول إلى إحاطات التحالف.
انضم إلى تحالف القيادات
