الخلاصة

  • يميّز مقال في مدونة LACNIC بين عناوين martian، وbogons المرتبطة بحالة الموارد، وإعلانات RPKI Invalid. ويؤكد الكاتب أن رأيه لا يمثل بالضرورة LACNIC.
  • قد تدخل الفئات الثلاث في سياسة ترشيح واحدة، إلا أن أدلتها تأتي من سجل عناوين ذات استخدام خاص، ولقطة لحالة الموارد، ومنظور ROA متحقق منه داخل ذاكرة مؤقتة؛ ولا تتغير هذه المصادر في الوقت نفسه.
  • تعرّف RFC 6811 حالة Invalid بالرجوع إلى بيانات تفويض منشأ متحققة، وتقر بإمكان اختلاف الذواكر المحلية. أما التصرف بعد النتيجة فهو سياسة محلية، والتحقق من المنشأ ليس تحققاً من المسار.
  • يمكن لسجل موجز يحفظ الفئة والمصدر والنسخة والزمن والنطاق والتصرف المحلي أن يشرح العدد المجمع من دون كشف بادئات أو عملاء أو أقران أو إعدادات.

الرقم الواحد يخفي ثلاثة شروط مختلفة

من المعقول أن تجمع شبكة ما نتائج عدة قواعد تصفية في مؤشر واحد. فالمشغّل يحتاج إلى متابعة الحمل أو معرفة أن شيئاً تغير. لكن الفائدة التشغيلية للعدد لا تمنحه معنى واحداً. يشرح مقال LACNIC عن martians وbogons وRPKI Invalids أن هذه التسميات تشير إلى علاقات مختلفة بالبيانات، حتى عندما تؤدي في النهاية إلى قرار مماثل على واجهة تشغيلية.

في العرض الوارد في المقال، يرتبط martian بمساحة عناوين محجوزة لاستخدامات خاصة. وترتبط فئة من bogon بحالة مساحة لم تكن متاحة أو مفوضة أو مخصصة على النحو المتوقع. أما RPKI Invalid فيتعلق بعلاقة بين إعلان ومساره من حيث البادئة وAS المصدر والتفويض المرئي في ROA. لا ينبغي تحويل هذا الشرح إلى سياسة صادرة عن LACNIC أو إلى وصف لسلوك شبكة في المنطقة. المقال موقّع باسم Sergio Kleiman، ويورد في نهايته أن الآراء قد لا تمثل LACNIC. ولا يقدم دليلاً على حادثة أو إحصاء إقليمي أو إجراء موحد من المشغّلين.

الأهم هو السؤال الذي يتركه المقال مفتوحاً: ما البيانات التي أعطت التصنيف معناه عند لحظة القرار؟ الساعة الأولى هي ساعة السجل. فـ سجل IANA لعناوين IPv4 ذات الاستخدام الخاص هو سطح المرجع لخصائص هذه العناوين في IPv4. إذا اعتمدت سياسة على خاصية فيه، فإن المراجعة اللاحقة تحتاج إلى معرفة النسخة أو وقت الجلب المستخدمين. من دون ذلك، قد تُعرض خاصية تمت قراءتها في وقت محدد كأنها حقيقة لا تاريخ لها.

الساعة الثانية هي ساعة حالة الموارد. يذكر مقال LACNIC أن مجموعات بيانات bogon تتبدل حين تصبح الموارد متاحة أو تُفوّض أو تُخصّص. لذا ينبغي وصل أي نتيجة بلقطة محددة وبوقت محدد. قد تجعل عملية تخصيص لاحقة قائمة قديمة بحاجة إلى فحص، لكنها لا تعيد كتابة ما كانت القائمة تعبر عنه في وقت سابق. وينبغي هنا فصل تغير المصدر عن تأخر تحديث القائمة وعن القرار الذي اتخذته القاعدة المحلية.

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

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

الإيصال أفضل من كشف الشبكة

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

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

المصادر