هشاشة IRR في AFRINIC في بيانات التوجيه القديمة والمنعكسة والمتكررة

عندما تجيب عدة سجلات على نفس المسار

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

أحد مصادر IRR لديه كائن مسار للبادئة مع AS أصلي ينتمي إلى مزود سابق. آخر لديه كائن أحدث لشبكة عميل تقول إنها انتقلت إلى مركز بيانات إقليمي. مصدر ثالث يعكس إدخالًا أقدم يبدو مقبولًا لأن اسم المشرف يشبه اسم حامل المورد. مجموعة AS-SET التي قدمها العميل تتوسع بشكل مختلف حسب ترتيب المصدر. في توسع واحد، البادئة مغطاة من خلال مخروط عميل لموزع. في آخر، تختفي لأن route-set يشير إلى AS-SET موجود في مستودع مختلف. يساعد فحص RPKI العام في جزء من السؤال لكنه لا يشرح لماذا تختلف آراء IRR أو أي علاقة تشغيلية حالية. يمكن لمهندس البورصة رفض المسار، أو قبوله، أو عمل استثناء يدوي، أو طلب رسائل، أو تأخير التذكرة. لا شيء من هذه الخيارات مجاني.

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

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

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

الإطار الصحيح ليس الولاء المؤسسي. ليس أن AFRINIC، أو أي RIR آخر، يجب أن تثق به لأنها تدعي تفويضًا مجتمعيًا. ولا أن IRRs الخاصة يجب أن تثق بها لأن المشغلين استخدموها لسنوات. السؤال أصعب: عندما تعطي عدة قواعد بيانات إجابات معقولة ولكن متناقضة حول سياسة التوجيه لمورد رقم نادر، أي إجابة يجب أن يعتمد عليها المزود أو التبادل أو السحابة أو الوسيط أو المشتري أو المقرض أو العميل، ومن يدفع عندما تكون الإجابة خاطئة؟

RPSL جعلت سياسة التوجيه قابلة للقراءة، وليست ذاتية التحقق

نشأ نظام سجل توجيه الإنترنت من حاجة تشغيلية معقولة. يسمح BGP للشبكات بإعلان المسارات، لكنه لا يوفر، بحد ذاته، تفسيرًا عامًا كاملاً لما تنوي الشبكة بدءه أو تمريره أو قبوله. سياسة التوجيه مهمة جدًا لتترك فقط في تكوينات الموجه الخاصة ورسائل البريد الإلكتروني. RFC 2622 عرفت RPSL، وأعطت المشغلين لغة منظمة للتعبير عن تلك السياسة. تتضمن كائنات مثل route وroute6 وaut-num وas-set وroute-set وmntner. هذه ليست أدوات قانونية. إنها كائنات قاعدة بيانات مصممة بحيث يمكن وصف علاقات التوجيه بشكل يمكن للبرامج استعلامه.

هذا التمييز غالبًا ما يكون أول ضحية للأتمتة. كائن route يربط بادئة بنظام مستقل أصلي. كائن route6، الموصوف في امتداد متعدد البروتوكولات لـ RFC 4012، يؤدي دورًا مشابهًا لـ IPv6. كائن mntner يحدد المشرف الذي يمكنه مصادقة التغييرات على الكائنات الأخرى. AS-SETs وroute-sets تسمح للمشغلين بوصف مجموعات من الشبكات أو المسارات، غالبًا بشكل متكرر. من هذه القطع، يمكن للشبكة إنشاء عوامل تصفية لعميل أو نظير. البنية ضيقة، لكن العواقب واسعة لأن المخرجات تصبح سياسة الموجه.

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

RPSL لم تجعل البيانات ذاتية التحقق. جعلتها قابلة للقراءة. هذا الفرق مهم في كل نزاع IRR مجزأ. إذا كان كائن route موجودًا في مستودع، يمكن تحليل الكائن. يمكن عكسه. يمكن مطابقته مع إعلان. يمكن سحبه إلى قائمة بادئات. لكن وجود الكائن لا يثبت أن حامل المورد أذن به، أو أن AS الأصلي لا يزال حاليًا، أو أن المشرف لا يزال يمثل الطرف المعني، أو أن نسخة مكررة في مكان آخر خاطئة، أو أن توسعة route-set عبر المصادر تعكس العلاقات التجارية الحالية. التنسيق يجعل الادعاء مقروءًا آليًا. لا يجعله حقيقيًا.

هذا القيد كان أقل أهمية في السابق لأن المخاطر كانت أقل والثقافة التشغيلية كانت أكثر توجهاً بالعلاقات. السوق الحديثة أقل تسامحًا. IPv4 نادر؛ الأتمتة أعمق؛ الاعتماد على السحابة، وخوادم المسار، وخدمات الأمان المدارة، والتبادل عن بُعد، ونقل العناوين تعتمد جميعها على أدلة خارجية قابلة للتكرار. سجل ساعد المهندسين في التنسيق أصبح الآن يؤثر على ما إذا كان رأس المال والاتصال وعلاقات العملاء يمكن أن تتحرك.

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

لهذا السبب التجزئة مكلفة جدًا. إذا ظهرت نفس مفردات RPSL في عدة مستودعات، لكل منها نموذج سلطة مختلف، فإن السوق يتلقى بيانات تبدو متشابهة لكنها تستند على أسس مختلفة. كائن route في مصدر واحد قد يكون مرتبطًا بشكل وثيق بسجل حامل RIR. كائن route في آخر ربما تم إنشاؤه بواسطة مشغل شبكة منذ سنوات تحت ممارسة مشرف أقل تقييدًا. كائن منعكس قد يتأخر عن المصدر أو يحتفظ بمنظر محذوف. route-set قد تشير إلى كائنات موجودة فقط إذا استعلمت الأداة عن المستودعات الصحيحة. القواعد المشتركة تخفي الفرق المؤسسي تحتها.

التجزئة تحول أداة التنسيق إلى رسوم سوق

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

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

التكلفة الثانية هي الشرح. عندما يقول العميل، "كائن المسار موجود"، يجب على المزود أن يسأل أين. إذا كان الكائن في RADB ولكن ليس في IRR الخاص بـ RIR المعني، هل هذا كافٍ؟ إذا كان في مصدر AFRINIC لكن نسخة مكررة في مصدر آخر تشير إلى أصل مختلف، أي كائن يفوز؟ إذا كان لدى العميل AS-SET يتوسع عبر عدة مستودعات، هل يقبل المزود جميع المصادر أم فقط تلك الموجودة في قائمة مفضلة؟ إذا كان مزود العميل السابق أنشأ كائنات في مشرفه الخاص، هل يجب على العميل حذفها قبل أن يقبل المزود الجديد المسار؟ كل سؤال معقول. معًا تجعل الاتصال يبدو كتقاضي باسم آخر.

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

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

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

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

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

اختيار المصدر هو قرار اقتصادي متنكر كهندسة

RFC 7454، وثيقة عمليات وأمن BGP، تعامل اختيار المصدر كاهتمام عملي للمشغلين. تناقش تصفية البادئات، وعوامل تصفية العملاء المستمدة من سجلات التوجيه، وعودية AS-SET، والحاجة لتحديث عوامل التصفية، وصعوبة اختيار مصادر IRR التي يجب استخدامها. النص عملي، لكن الآثار الاقتصادية كبيرة: قاعدة اختيار المصدر هي سياسة ثقة. تقرر أي ادعاءات قاعدة بيانات رخيصة بما يكفي للاعتماد عليها وأي ادعاءات تتطلب تصعيدًا يدويًا أو رفضًا.

فكر في ناقل يقبل كائنات AFRINIC و RIPE و APNIC و ARIN و RADB عند بناء عوامل التصفية. هذه السياسة تزيد من الشمولية. تقلل تذاكر الدعم من العملاء الذين تعيش بياناتهم في مصادر أقدم أو غير إقليمية. كما تزيد من التعرض للتكرارات القديمة، وتواريخ التوثيق الأضعف، ومفاجآت العودية عبر المصادر. الآن فكر في ناقل يفضل فقط مصدر RIR المعني لكل بادئة ويتجاهل IRRs الخاصة حيث يوجد IRR لـ RIR. هذه السياسة قد تحسن توافق السلطة، لكنها يمكن أن تكسر العملاء المشروعين الذين حافظوا على سجلاتهم تاريخيًا في مكان آخر أو الذين تعيش كائنات أنشأها المزود خارج المصدر الإقليمي. ناقل ثالث قد يستخدم ترتيب تفضيل المصادر، ويقبل أول كائن مطابق.

هذه القاعدة فعالة حتى يكون المصدر المفضل قديمًا ويكون مصدر أقل تفضيلًا حاليًا.

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

بالنسبة للبادئات التي تديرها AFRINIC، اختيار المصدر حساس بشكل غير عادي لأن سجلات المنطقة قد تحمل عدة تواريخ في وقت واحد. قد يكون للبادئة كائن route قديم في IRR تجاري لأن مزودًا أنشأه منذ فترة طويلة قبل أن يستخدم الحامل أدوات IRR الخاصة بـ AFRINIC. قد يكون لها كائن مرتبط بـ AFRINIC تم إنشاؤه أثناء تنظيف لاحق. قد يكون لها مراجع route-set تفترض أدوات على نمط RIPE لأن مزودًا أوروبيًا حافظ على سياسة العميل. قد يكون لها إدخالات IRR خاصة تستخدمها سحابة أو مزود DDoS. كل مصدر يمكن أن يكون معقولًا من وجهة نظر الطرف الذي أنشأه. المعقولية ليست مثل السلطة الحالية.

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

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

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

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

تأخير المرآة والتكرارات القديمة تخلق استمرارية كاذبة

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

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

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

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

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

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

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

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

المصادقة بدون تفويض لا تحل الثقة

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

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

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

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

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

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

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

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

العودية في AS-SET تجعل الأخطاء الصغيرة تسافر بعيدًا

AS-SETs هي واحدة من أكثر أجزاء نظام IRR فائدة وخطورة. تسمح لشبكة بنشر مجموعة من ASNs يجب معاملتها كجزء من مخروط العملاء أو سياسة التوجيه. مزود نقل يمكنه أن يطلب من العميل AS-SET، وتوسيعه بشكل متكرر، والعثور على ASNs داخله، ثم بناء فلاتر للبادئات المرتبطة بتلك ASNs. بدون هذه الآلية، سيكون صيانة فلتر العميل أكثر يدوية بكثير. معها، خادم مسار واحد أو ناقل يمكنه معالجة العديد من علاقات التوجيه تلقائيًا.

الخطر هو العودية. AS-SET يمكن أن يشمل AS-SETs أخرى. تلك AS-SETs يمكن أن تعيش في مصادر مختلفة. يمكن أن تشمل ASNs عميل قديمة، وموزعين سفليين، وroute-sets، أو كائنات تم الحفاظ عليها بمعايير سلطة مختلفة. التوسع يمكن أن يعتمد على المصدر. أداة تبحث في جميع المصادر قد تنتج مجموعة أكبر من أداة تقتصر على المصادر المفضلة. أداة تتوقف عند أول تطابق قد تعامل قاعدة بيانات واحدة as حاسمة. أداة تفشل مغلقة قد ترفض العملاء المشروعين. أداة تفشل مفتوحة قد تقبل مسارات من خلال سلسلة لم يدققها أحد مؤخرًا. تحذير RFC 7454 بشأن عودية AS-SET والفلاتر المستمدة من IRR ليس حاشية أكاديمية. إنها النقطة التشغيلية التي يصبح فيها تجزئة قاعدة البيانات تكوين موجه.

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

التأثير الاقتصادي هو الحجم. كائن route قديم واحد يؤثر على ادعاء بادئة-أصل واحد. عضو AS-SET قديم يمكن أن يؤثر على العديد من البادئات. route-set واسعة يمكن أن تؤثر على جميع البادئات المرتبطة بعدة ASNs. كائن عودي في مصدر موثوق يمكن أن يستورد بيانات أقل ثقة من مصدر آخر. نصف قطر الخطأ ينمو مع كل طبقة من عدم المباشرة. هذا يجعل نظافة AS-SET قضية سوق. تكلفة مجموعة غير دقيقة يتحملها ليس فقط المشرف، بل كل مزود نقل، وخادم مسار، وعميل، ونظير يعتمد على توسعها.

العودية تخلق أيضًا غموضًا. قد لا يعرف العميل لماذا يتضمن فلتر المزود أو يستبعد مسارًا. الجواب قد يكون مدفونًا في قاعدة اختيار مصدر عدة مستويات عميقة. تذكرة الدعم قد تقول "عدم تطابق IRR" عندما تكون المشكلة الحقيقية أن AS العميل مفقود من مجموعة سفلى، أو أن AS-SET مكررة في مصدر آخر مفضلة، أو أن إدخال موزع قديم لا يزال يتوسع. الأطراف تتجادل حول البادئة المرئية بينما السبب يجلس في سلسلة مخفية من كائنات RPSL.

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

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

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

AFRINIC تحول غموض قاعدة البيانات إلى مخاطرة مؤسسية

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

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

هذا هو المكان الذي تصبح فيه بيانات IRR المجزأة مخاطرة مؤسسية. إذا كان للبادئة أصل واحد في مصدر مرتبط بـ AFRINIC، وآخر في IRR تجاري، ومرجع قديم في AS-SET يحافظ عليه مزود سابق، فإن التعارض التقني هو أيضًا إشارة حوكمة. يقول إن السوق لا يستطيع بسهولة رؤية أي مؤسسة وأي مصدر وأي سلسلة سلطة يجب أن تحل الادعاء التشغيلي. في منطقة حيث العناوين نادرة والسجل كان تحت ضغط، هذا عدم اليقين يجذب أقساط المخاطرة.

الخطر ليس فقط ممثلين سيئين. الشبكات المشروعة تعاني من نفس الخصم. جامعة عامة ذات سجلات قديمة قد تعامل كمشتبه بها عندما تغير المزودين. مزود خدمة إنترنت صغير قد يفقد فرصة نقل لأن AS-SET الخاصة به تتوسع بشكل غير متناسق. وكالة حكومية قد تواجه أسابيع من المراجعة لأن جهات الاتصال التاريخية لم تعد تجيب. مركز بيانات قد يكافح لجلب مساحة العميل إلى بورصة محلية لأن مصدر آخر لا يزال يشير إلى ناقل دولي. هذه ليست بالضرورة فشلًا لموظفي AFRINIC أو لأي مشغل IRR واحد. إنها فشل لنظام اعتماد مجزأ لجعل الشرعية العادية رخيصة.

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

هذا المسار يتطلب الاعتراف بالطبقات المنفصلة. سجل موارد الأرقام AFRINIC هو دفتر الأستاذ الدائم. بيانات IRR هي نشر سياسة توجيه مجاورة لذلك الدفتر. RPKI و ROAs توفر دليل أصل تشفيري عبر آلية مختلفة. إعلانات BGP تظهر التوجيه الملاحظ، وليس السلطة. العقود وأوامر المحكمة قد تقرر الحقوق بين الأطراف، لكنها تحتاج ترجمة إلى إشارات تشغيلية. الخلط بين هذه الطبقات ينتج تجاوزًا أو إهمالًا. إبقاؤها منفصلة يسمح لكل منها بالقيام بعملها.

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

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

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

ندرة IPv4 تحول الغموض إلى علاوة

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

كتلة عناوين ليست قيمة فقط لأنها تظهر في سجل. إنها قيمة لأن الأطراف المقابلة تؤمن بإمكانية استخدامها. قابلية الاستخدام تعتمد على كومة من الأدلة: سجلات حامل السجل، والسلطة التعاقدية، وتاريخ التوجيه، وكائنات IRR، وAS-SETs، وحالة RPKI، وسمعة الإساءة، وDNS العكسي، وموافقات الانضمام للسحابة، وفلاتر الناقل. بيانات IRR المجزأة تجلس في منتصف تلك الكومة. إنها قريبة بما يكفي من العمليات لتؤثر على قابلية الوصول وقريبة بما يكفي من السجل لتؤثر على تصورات الشرعية. عندما تتعارض، تصبح الكتلة أقل سيولة.

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

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

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

العميل يرى هذا كموثوقية الخدمة. المؤسسات والوكالات العامة ومستخدمو السحابة لا يريدون تعلم الفرق بين RADB و AFRINIC وعودية AS-SET و RPKI. يريدون أن تعمل شبكة مزودهم. عندما تفشل هجرة لأن خادم مسار يرفض بادئة، يواجه العميل تأخيرًا وانعدام ثقة. المزود قد يلقي اللوم على السجل، أو المزود القديم، أو المزود الجديد، أو مصدر قاعدة البيانات. العميل يسمع فقط أن أصل العنوان كان أصعب في الاستخدام مما وعد.

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

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

RPKI يساعد، لكنه لا يذيب الاعتماد على IRR

غالبًا ما تقدم RPKI وتفويضات أصل المسار (ROAs) كبديل أنظف لـ IRR. إنها أنظف لسؤال محدد. ROA تسمح لحامل المورد، ضمن نظام شهادة المورد، بتحديد أي AS قد ينشئ بادئة حتى طول أقصى محدد. الشبكات التي تؤدي التحقق من صحة أصل المسار يمكنها تصنيف الإعلانات كصحيحة أو غير صحيحة أو غير موجودة. هذا تحسن قوي على سجلات النص غير الموثقة أو ضعيفة التوثيق. يقلل فئة واحدة من عدم اليقين حول سلطة الأصل.

لكن RPKI لا تذيب مشكلة IRR. المشغلون ما زالوا يستخدمون بيانات IRR لفلاتر العملاء، وتوسع AS-SET، وسياسة route-set، وتوقعات الحد الأقصى للبادئة، وتوثيق سياسة التوجيه. ROA يمكن أن تقول أن AS مخول لإنشاء بادئة. لا تصف مخروط العميل الكامل خلف AS نقل. لا تنظف AS-SETs القديمة. لا تزيل كائنات route المكررة من IRRs الخاصة. لا تشرح لماذا يقول أحد المستودعات أن مزودًا سابقًا لا يزال ينشئ الكتلة. لا تخبر الوسيط ما إذا كانت مراجع IRR القديمة ستؤخر انضمام المشتري للناقل. لا تقرر ما إذا كان يجب حذف كائن أنشأه المزود بعد إنهاء العقد.

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

في حالة AFRINIC، قيمة RPKI قد تكون عالية بشكل خاص لأن الضغط المؤسسي يجعل دليل الأصل القابل للتحقق آليًا جذابًا. ROA يمكن أن تطمئن المزود بأن الحامل نشر تفويض أصل حالي. يمكن أن تساعد مزود السحابة في تمييز أصل جديد مشروع من كائن IRR قديم. يمكن أن تعطي المشتري عنصر عناية واجبة أنظف. لكنها لا تجيب على كل سؤال تجزئة المصدر. بادئة يمكن أن يكون لها ROA صالح وما زالت تظهر في AS-SETs قديمة. خادم مسار يمكنه استخدام فلاتر مستمدة من IRR ترفض المسار قبل أن تعني RPKI شيئًا. مزود يمكن أن يتطلب تسجيل IRR للتزويد حتى لو كانت RPKI صالحة. الثقافات التشغيلية تتغير ببطء.

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

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

بالنسبة لأتمتة خادم المسار والنقل، التحسين العملي هو سياسة مدركة للتعارض. نظام يجب أن يكون قادرًا على القول: ROA تتحقق من هذا الأصل، مصدر IRR المرتبط بـ AFRINIC يدعمه، IRR غير إقليمي لديه نسخة مكررة قديمة، و AS-SET في مصدر آخر لا يزال يشير إلى المزود السابق. هذه إشارة سوق أفضل من قبول أو رفض ثنائي. تسمح للمشغل بقبول المسار مع فتح تذكرة تنظيف، أو رفض فقط إذا وصل التعارض إلى حد مخاطرة محدد. الهدف ليس بيانات أكثر لذاتها. الهدف هو حكم أرخص وأكثر اتساقًا.

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

سؤال الثقة مختلف لكل طرف مقابل

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

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

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

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

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

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

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

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

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

معيار ضيق للاعتماد في منطقة AFRINIC

معيار عملي لاعتماد IRR في منطقة AFRINIC يجب أن يبدأ بالتواضع حول ما يثبته أي أثر فردي. كائن route يثبت أن بيان بادئة-أصل موجود في مصدر تحت قواعد ذلك المصدر. كائن route6 يفعل نفس الشيء لـ IPv6. mntner يثبت من يمكنه مصادقة تغييرات قاعدة بيانات معينة، وليس من يحمل كل تفويض أساسي. AS-SET تصف علاقات التوجيه المقصودة لكنها قد تستورد بيانات قديمة أو عبر مصادر. ROA توفر دليل أصل تشفيري أقوى، لكن ليس خريطة كاملة لمخاريط العملاء أو السلطة التجارية أو تنظيف قاعدة البيانات. BGP المرصود يظهر ما يحدث، وليس بالضرورة ما هو مخول.

من ذلك التواضع يتبع تسلسل هرمي. لموارد AFRINIC المدارة، يجب أن يحمل السجل المرتبط بـ AFRINIC ومصدر سياسة التوجيه وزنًا إثباتيًا عاليًا عندما يكون حاليًا وإجرائيًا نظيفًا وشفافًا. إدخالات IRR غير AFRINIC يجب أن تبقى قابلة للاستخدام، لكن لا ينبغي للمشغلين التظاهر بأن كل كائن RPSL يستند على نفس أساس السلطة. RPKI يجب أن تعزز ضمان الأصل. توسع AS-SET يجب أن يعامل كسلسلة مصادرها وأعمارها ومراجعها عبر المصادر مهمة. الاستثناءات اليدوية يجب أن تكون مؤقتة ومسجلة. التكرارات القديمة يجب أن تكون مرئية وقابلة للتصحيح.

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

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

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

المقاييس ستجعل المعيار ذا مصداقية. AFRINIC والمشغلون الرئيسيون يجب أن يكونوا قادرين على قياس عدد المرات التي يكون فيها للبادئات التي تديرها AFRINIC كائنات route أو route6 متضاربة عبر المصادر، وعدد المرات التي تختلف فيها توسعات AS-SET بترتيب المصدر، وكم عمر التكرارات القديمة، وكم هي حديثة المرايا، وكم من الوقت تستغرق التصحيحات، وكم عدد العملاء الذين يحتاجون إلى استثناءات يدوية. هذه الأرقام لا تحتاج لكشف ملفات العميل الخاصة. ستخبر السوق ما إذا كان التجزئة حكاية أو ضريبة مزمنة أو حالة تحسن.

نفس الانضباط يجب أن ينطبق على الأدوات. أنظمة التصفية يجب أن تكشف مسارات المصدر: أي مصدر، وكائن، وسلسلة AS-SET، وقاعدة عودية أنتجت القبول أو الرفض. يجب أن يكون الحاملون قادرين على اكتشاف أين تظهر بادئاتهم و ASNs عبر مصادر IRR الرئيسية و route-sets. يجب أن تبلغ خوادم المسار عن فئات الرفض المفهومة للأعضاء. يجب الحفاظ على السجلات التاريخية للتدقيق، لكن إرشادات الحالة الحالية يجب أن تكون واضحة بما يكفي للمشغلين لاستخدامها. الهدف ليس قاعدة بيانات مثالية. إنها بيئة قاعدة بيانات يتم فيها تصنيف عدم اليقين، وتحديده، ورخص تقليله.

هذا المعيار سيجعل الحياة أسهل لمهندس خادم المسار أمام وظيفة الفلتر عند الفجر. إذا أعطت عدة مصادر إجابات متناقضة، ستظهر الأداة النضارة ووضع السلطة ومسار المصدر وعمر التعارض. سيكون ROA صالح موزونًا لضمان الأصل لكن لا يستخدمه لتجاهل AS-SETs القديمة. سيكون المصدر المرتبط بـ AFRINIC موثوقًا لأن إجراءاته كانت مرئية، وليس لأن المؤسسة طلبت الانصياع. المصادر الخارجية ستؤخذ في الاعتبار مع حدودها. سيتلقى العميل مسار تنظيف واضح بدلاً من رفض غامض. سيظل الحكم مطلوبًا، لكنه سيكون أرخص.

تكلفة عدم إصلاح التجزئة

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

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

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

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

تكلفة السوق سترتفع مع استمرار ندرة IPv4. الندرة ترفع قيمة كل غموض يمكن أن يؤثر على الاستخدام: كائن route قديم، إدخال AS-SET مفقود، تأخير مرآة، تفضيل مصدر، أو نزاع حوكمة. بيانات IRR المجزأة تحول عيوبًا تقنية صغيرة إلى خيارات اقتصادية يملكها من يمكنه استغلالها أو حلها.

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

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

فرصة AFRINIC هي تقليل ذلك الثمن. ليس بأن تصبح حارس بوابة على كل استخدام تجاري لـ IPv4. ليس بطلب من المشغلين تجاهل المصادر غير الإقليمية. ليس بالتظاهر بأن RPKI يلغي قواعد بيانات سياسة التوجيه. الفرصة أضيق وأكثر قيمة: جعل دفتر الأستاذ المرتبط بـ AFRINIC ومصدر سياسة التوجيه معتمدين، وكشف التعارضات، والحفاظ على التاريخ، وتسريع التصحيح، وفصل المصادقة عن التفويض، ومساعدة المشغلين على رؤية أي ادعاء قاعدة بيانات يستند على أي أساس مؤسسي. إذا حدث ذلك، تعود بيانات IRR إلى دورها الاقتصادي الصحيح. تصبح وسيلة لجعل الثقة أرخص، وليس سببًا لشراء كل شبكة خريطة خاصة بها من الشك.