الخلاصة

  • يعرّف RFC 9647 نموذج YANG 1.1 باسم ietf-babel لإدارة Babel، وهو معيار على مسار المعايير نُشر في أكتوبر 2024، ومتوافق مع بنية NMDA، ومبني على RFC 9046، مع تركيز على إدارة Babel عبر IPv6. النموذج يوسّع قدرة المشغّلين على قراءة الحالة وضبط الإعدادات، لكنه لا يلغي الحاجة إلى التحقق من التنفيذ الفعلي.
  • لا تعني قيمة selected في حالة المسار أن حزمة بيانات وصلت فعلاً إلى وجهتها أو أن واجهة الإرسال استخدمت المسار كما هو متوقع. إنها إسقاط إداري لحالة داخلية في التنفيذ، ولذلك تحتاج المؤسسات إلى ربطها بأدلة إضافية تشمل تثبيت RIB/FIB، ونتائج المصافحة، وسلوك التمرير الحقيقي.
  • يحدد RFC 9647 عناصر قابلة للمراقبة والتهيئة تشمل التمكين، والثوابت، والواجهات، ومجموعات مفاتيح MAC، وكائنات DTLS، والمسارات. كما يعرض حالات مسارات تتضمن البادئة، ومعرّف الموجّه، والجوار، والمقياس المستلم أو المحسوب، ورقم التسلسل، والقفزة التالية، وحالتي القابلية والاختيار feasible وselected.
  • لا يفرض YANG وحده وجود كل المعلومات المقروءة الإلزامية في نموذج المعلومات؛ فالتنفيذ مسؤول عن ملء هذه القيم. لذلك لا تكفي سلامة مخطط YANG لإثبات أن جميع البيانات التشغيلية المطلوبة موجودة أو صحيحة أو حديثة.

من نموذج الإدارة إلى برهان التشغيل

يمثل RFC 9647 خطوة في انتقال Babel من بروتوكول يمكن تشغيله ومراقبته بأدوات خاصة إلى بروتوكول يمكن وصف حالته من خلال نموذج إدارة معياري. المرجع الأساسي هو RFC 9647: A YANG Data Model for Babel، مع بيانات النشر والتعريف المتاحة في صفحة RFC 9647 وسجل IETF Datatracker.

القيمة التشغيلية للنموذج ليست في إضافة «حقيقة جديدة» إلى الشبكة، بل في تنظيم الأسئلة التي يمكن طرحها على التنفيذ: هل Babel مفعّل إدارياً؟ ما الواجهات المشاركة؟ ما القواعد الفعلية لاختيار المسارات؟ ما الجيران المعروفون؟ ما الحالة المحسوبة؟ وما المسار الذي يراه نظام الإدارة مختاراً؟

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

ما الذي يجعله RFC 9647 قابلاً للفحص والتهيئة؟

يعتمد النموذج على فلسفة NMDA الواردة في RFC 8342، حيث يمكن التمييز بين الحالة المقصودة intended، والحالة الجارية running، والحالة التشغيلية operational. هذه النقطة مهمة خصوصاً مع ورقة enable.

في RFC 9647، تمثل قيمة enable في مخازن الإعداد النية الإدارية: هل يريد المشغّل تشغيل الوظيفة؟ أما في الحالة التشغيلية فهي تمثل ما إذا كان التشغيل الفعلي مفعّلاً. الفارق بين الاثنين ليس تفصيلاً شكلياً؛ فهو موضع محتمل لفشل الإثبات. قد تكون السياسة المقصودة صحيحة، بينما تكون الخدمة الفعلية غير مفعّلة بسبب قيود تنفيذية أو اختلافات في الحالة.

يشمل النموذج مجموعة واسعة من الكائنات:

  • معلمات التمكين والثوابت.
  • تكوين الواجهات المشاركة في Babel.
  • مجموعات مفاتيح MAC.
  • كائنات DTLS.
  • حالات المسارات والجيران.

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

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

حدود ما يستطيع YANG إثباته

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

هذا الحد يغيّر طريقة تدقيق الشبكات. فوجود مسار في نموذج YANG لا يساوي بالضرورة وجود سجل تشغيلي كامل حول كيفية وصوله إلى هذه الحالة. يجب على المشغّل التحقق من:

  1. نسخة الوحدة وميزات النموذج المتاحة.
  2. مصدر البيانات ووقت أخذ اللقطة.
  3. وجود جميع حقول الحالة المطلوبة.
  4. توافق الحالة المعروضة مع التنفيذ الفعلي.

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

السياسة الافتراضية للواجهات ليست دائماً السياسة الفعلية

يصف RFC 9647 سلوكيات افتراضية مهمة مرتبطة بنوع الوسط. في البيئات السلكية تكون الإعدادات الافتراضية مبنية على قاعدة «اثنان من ثلاثة» مع split horizon، بينما تعتمد البيئات اللاسلكية افتراضياً على ETX من دون split horizon.

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

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

الهوية والتوثيق: المفاتيح موجودة لكن الارتباط يحتاج إثباتاً

يدعم النموذج إدارة مفاتيح MAC وكائنات DTLS، بما في ذلك إعدادات التطبيق الافتراضي. هذه الإعدادات يمكن أن تشير إلى الواجهات التي تُنشأ لاحقاً، ما يوفر آلية لتطبيق السياسة على كائنات مستقبلية.

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

  • أن الواجهة الفعلية مفعّلة للمصادقة المطلوبة.
  • أن مرجع مجموعة المفاتيح أو كائن DTLS مرتبط بها.
  • أن المصافحة تمت بالهوية المتوقعة.
  • أن نتائج التوثيق ظهرت في التسلسل الزمني الصحيح.

تحظى مفاتيح MAC الحساسة ومفاتيح DTLS الخاصة بحماية NACM وفق نموذج التحكم في الوصول الوارد في RFC 8341. هذه الحماية تقلل خطر كشف الأسرار عبر واجهات الإدارة، لكنها لا تثبت وحدها نجاح المصادقة أو صحة المسار التشغيلي.

سلسلة الإثبات ذات العشر إيصالات

لتحويل حالة Babel من معلومة إدارية إلى حالة تشغيلية قابلة للدفاع، يحتاج المشغّل إلى سلسلة أدلة عملية من عشر نقاط:

  1. إيصال الوحدة: نسخة وحدة ietf-babel والميزات المتاحة والمراجعة المستخدمة.
  2. إيصال المخزن والزمن: مصدر البيانات، وأصلها، ووقت التقاطها.
  3. إيصال الحالة: وجود حقول القراءة فقط المطلوبة وعدم افتراضها من غياب الأخطاء.
  4. إيصال تصنيف الواجهة: إثبات نوع الواجهة والبيئة التي تعمل فيها.
  5. إيصال السياسة الفعلية: القيم الافتراضية والتجاوزات والمؤقتات المطبقة.
  6. إيصال الهوية: علاقة مفاتيح MAC وكائنات DTLS بالواجهات المعنية.
  7. إيصال المصافحة: نتائج التوثيق وتبادل الجيران.
  8. إيصال التسلسل: تاريخ ظهور الجوار، وتغيرات المسار، وأرقام التسلسل.
  9. إيصال التثبيت: انتقال القرار إلى RIB ثم FIB إن كان التنفيذ يتطلب ذلك.
  10. إيصال السلوك: تمرير حزم فعلي، وتعافٍ من الفشل، وقياس مستقل لقابلية الوصول.

هذه السلسلة تمنع الخلط بين «ما يقوله نموذج الإدارة» و«ما يحدث في الشبكة».

الأمن خارج حدود النموذج

يوضح RFC 9647 أن قسم الأمن فيه محدود بنموذج YANG نفسه، بينما توجد اعتبارات أمن البروتوكول والمصادقة والتشفير في وثائق Babel الأخرى، ومنها RFC 8966، وRFC 8967، وRFC 8968.

هذا الفصل بين الطبقات مهم. فالنموذج الإداري يمكن أن يصف وجود كائن DTLS أو إعداد MAC، لكنه لا يحل محل تحليل البروتوكول أو التحقق من مقاومة الهجمات أو صحة آليات المصادقة.

كما أن أي تقييم للقدرات المتاحة يجب الرجوع إلى المراجع المعيارية ذات الصلة، بما فيها RFC 9046 الذي يستند إليه RFC 9647، ومعلمات YANG المسجلة في IANA YANG Parameters Registry.

حدود الدليل والتفسير

لا يقدم RFC 9647 دليلاً على جودة نشر معينة، ولا يحدد معدلات تبني، ولا يقدم مقارنات أداء بين تطبيقات. كما لا يمكن استنتاج موثوقية شبكة كاملة من قراءة جدول مسارات فقط.

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

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

Sources