الخلاصة

  • يرفع RFC 8654 الحد الأقصى لرسائل BGP، عدا OPEN وKEEPALIVE، من 4,096 إلى 65,535 ثُمانيّة، ولا يسمح بإرسال رسالة موسعة إلا لنظير أعلن القدرة رقم 6.
  • القدرة التزام استقبال على جلسة واحدة وليست تفويضًا للشبكة كلها؛ وقد يفرض الدعم المختلط إسقاط سمات أو حجب UPDATE أو سحب مسار.

يبدأ الغلاف الأكبر بوعد ثنائي

يضع RFC 4271 أساسًا واضحًا: لا تُعالج رسالة BGP إلا بعد استلامها كاملة، وحجمها الأقصى 4,096 ثُمانيّة. يرفع RFC 8654 السقف لاستيعاب عائلات عناوين وميزات جديدة، مع استثناء رسائل OPEN وKEEPALIVE.

التحكم ليس في الرقم بل في التفاوض. ينبغي للمتحدث القادر على استقبال الرسائل الموسعة أن يعلن القدرة بواسطة RFC 5492، وهي صيغة SHOULD في المعيار. تسجلها IANA بالرقم 6. ويجوز للمرسل، بصيغة MAY، أن يبعث رسالة موسعة فقط إذا تلقى هذه القدرة من النظير في تلك الجلسة.

الإعلان يرتب التزامًا فعليًا: يجب على التطبيق، بصيغة MUST، أن يستقبل حتى 65,535 ثُمانيّة. وبالعكس، إذا كان قادرًا تقنيًا لكنه لم يعلن القدرة بسبب الإعداد، فيُحظر عليه قبول رسالة موسعة؛ وهذه صيغة MUST NOT. القدرة البرمجية لا تتجاوز حد الجلسة المضبوط.

ويضع RFC 8654 حدًا مستقلًا للإرسال: يُحظر أن تتجاوز رسالة NOTIFICATION المرسلة إلى نظير لم يعلن القدرة 4,096 ثُمانيّة (MUST NOT).

قدرة حافة واحدة لا تنتقل إلى الحافة التالية

قد تدخل UPDATE أكبر من 4,096 ثُمانيّة من نظير داعم ثم تحتاج إلى الانتشار نحو جار لم يعلن القدرة. الجلسة الأولى أجازت الاستقبال ولم تمنح إذنًا للجلسة الثانية.

ينص RFC 8654 بصيغة SHOULD على أن يحاول الوسيط تقليص الرسالة بإزالة السمات المؤهلة فقط لنهج «attribute discard» في RFC 7606. ويجب ألا تؤثر تلك السمات في اختيار المسار أو تثبيته. إذا بقيت الرسالة أكبر من الحد فيُحظر إرسالها إلى الجار غير الداعم (MUST NOT). وإذا كان NLRI قد أُعلن سابقًا لذلك الجار فيجب سحبه من الخدمة.

قد يستفيد تطبيق يحتاج إلى سمات أو NLRI أكثر. لكن الكلفة قد تقع على الجار التالي وعلى مستخدمي مسار لا يعبر حد 4,096 ثُمانيّة. هكذا تتحول سعة التمثيل إلى قرار انتشار ووصول.

الاتساق الداخلي مسؤولية نشر

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

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

لا يحل RFC 8654 مشكلات أمن BGP الأصلية. قد تزيد المخازن الأكبر التعرض لاستنزاف الموارد عمدًا أو عرضًا. تلقي القدرة لا يثبت شرعية المسار أو سلامة الحمولة؛ بل يثبت سعة استقبال معلنة فقط.

الأدلة والحدود

يحدد RFC 8654 الحجم والاستثناءات والتفاوض وحدود الدعم المختلط. ويقدم RFC 4271 الحد الأصلي، ويعرّف RFC 5492 إعلان القدرات، ويقيد RFC 7606 إسقاط السمات، ويؤكد سجل IANA الرمز 6.

لا تحدد المصادر الشبكات التي تفعّل الميزة اليوم، ولا كلفة ذاكرة عامة، ولا تضمن أن حذف السمات سيكفي دائمًا. أما السلطة والتفويض والمستفيدون والكلفة والبديل المضاد فهي استنتاجات تحليلية من المعايير.

المصادر