الخلاصة

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

الإيجار أخضر والشبكة الداخلية مظلمة

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

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

يرسم RFC 8415 هذا الحد بوضوح. صُمم تفويض البادئة لحالات لا يعرف فيها الموجّه المفوِّض طوبولوجيا الشبكة خلف الموجّه الطالب. يختار الخادم البادئة ويرسلها، ثم يصبح العميل مسؤولاً عنها. يمكنه تقسيمها إلى شبكات فرعية وإسنادها إلى واجهات والإعلان عنها. تلك أفعال لاحقة وليست خصائص يحملها نجاح IA_PD.

نقل مسؤولية محدود بالزمن

الوحدة التشغيلية ليست عبارة «البادئة موجودة»، بل هوية العميل وIAID والبادئة وطولها والخادم وT1 وT2 ومدة التفضيل ومدة الصلاحية ووقت الرصد. قد يمدد Renew هذه القيم، لكن RFC 8415 يسمح أيضاً للخادم بتغيير مجموعة البادئات أو إعادة بادئة غير مناسبة بأعمار صفرية. لذلك يجب حفظ محتوى الرد الفعلي لا لون المؤشر.

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

يضيف RFC 9818 متطلبات على موجّهات CE التي تفوّض عبر واجهات LAN. عليها دعم IA_PD داخلياً، والتخصيص من التجمع المتاح، وتسجيل خطأ إداري عند عدم كفاية البادئات. ولا يجوز تغيير بادئة وصلة من دون تغير في السياسة أو الطوبولوجيا. والأهم أن جدول التوجيه المحلي يجب أن يتحدث ديناميكياً مع الإيجارات والقفزات التالية، وأن يزيل المسار عند Release أو انتهاء الصلاحية.

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

بناء الإيصال من جانبي الحد

يسجل جانب التفويض الخادم وDUID وIAID والبادئة الدقيقة ووقت المعاملة وT1/T2 والعمرين ونوع الحدث: تخصيص أو Renew أو Rebind أو Release أو انتهاء. ويسجل جانب الطلب البادئات الفرعية المستخدمة فعلاً والروابط أو الموجّهات المستفيدة والأعمار الموروثة وإصدار الإعداد الذي اتخذ القرار.

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

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

إبقاء النطاق منضبطاً

لا يحوّل الإيصال DHCPv6 إلى بروتوكول طوبولوجيا؛ بل يجمع أدلة موزعة مع احترام فصل المسؤوليات. ولا يحل اختيار المصدر أو سياسة الشبكات متعددة المزوّدين. يستبعد RFC 9818 هذا السيناريو بسبب تعقيد التوجيه والتجهيز والسياسة، ولذلك يحتاج المشغل إلى أدلة منفصلة للخروج والعودة ونطاق الفشل.

المصادر