الخلاصة

  • تعرّف RFC 10038 رابطة هوية في DHCPv6 لمحددات SRv6، تشمل IAID وبنية المحدد ومدتي التفضيل والصلاحية ونقطتي T1 وT2 وربط الخادم وحالة صريحة عند عدم توافر محدد.
  • تؤدي Reply صالحة إلى تهيئة المحدد لدى العميل، لكنها لا تثبت مساراً محلياً أو إعلاناً. أما إنشاء SID محلياً واستخدام عدة محددات وإعلان تلك المعرفات فتبقى خارج نطاق الوثيقة.
  • حرر Weiqiang Cheng وChangwang Lin الوثيقة، وشارك Ruibo Han وDaniel Voyer وGeng Zhang في تأليفها، وساهم Yuanxiang Qiu فيها. إنها صياغة جماعية لحالات منفصلة، لا دليلاً على اختراع فردي أو نشر تشغيلي.

تبدأ المخاطرة عند حدود الثقة. يفترض المثال في RFC 10038 أن الخادم والعميل والـCPE ومكونات النفاذ تقع في نطاق SR واحد موثوق. لكن الوثيقة لا تعتبر كلمة «موثوق» إعداداً أمنياً كافياً. فالعميل عند الحد مطالب بترشيح الحركة على واجهتيه الداخلية والخارجية، والجهاز ومنافذه يجب أن يبقيا تحت الإدارة المتوقعة للمشغل.

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

نُشرت RFC 10038 في أغسطس 2026 على مسار المعايير لدى IETF. وهي توسع DHCPv6 بخياري IA_SRV6_LOCATOR وIA Locator، وبالحالة NoSRv6LocatorAvail. وهكذا يصبح منح محدد SRv6 معاملة ذات هوية وبنية وزمن، بدلاً من أن يكون بادئة مجهولة في قائمة.

أما الإسناد البشري فله الحدود نفسها. Weiqiang Cheng وChangwang Lin محرران، وRuibo Han وDaniel Voyer وGeng Zhang مؤلفون مشاركون، وYuanxiang Qiu مساهم. وكان ملف Cheng الرسمي لدى IETF، المحفوظ في 31 أغسطس 2026، يصفه بأنه Chief Architect of IP Networks في China Mobile Research Institute ورئيس مجموعة SRv6 Operations ومؤلف تسع وثائق RFC. يثبت ذلك سجلاً عاماً في المعايير، ولا يثبت أن China Mobile أو أي مشغل آخر نشر الآلية.

هوية العقد تحمي معناه

يحمل كل IA_SRV6_LOCATOR معرف IAID يميزه عن روابط العميل الأخرى. ويحدد T1 موعد العودة إلى الخادم الأصلي لتمديد المدد، بينما يسمح T2 بالاتصال بأي خادم متاح. ويحمل خيار المحدد مدتي التفضيل والصلاحية وأطوال أجزاء locator block وlocator node وfunction وargument وقيمة Algorithm.

هذه ليست حقول عرض. إنها ما يسمح للمشغل بإعادة بناء الواقعة: من طلب، عبر أي relay، ومن أي خادم، وما البنية التي أعيدت، وما الوقت المتبقي. ويستطيع Renew أو Rebind تمديد الحالة نفسها، بينما ينهي Release أو انتهاء الصلاحية الربط ويتيح استرجاع المورد.

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

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

منح المحدد لا يثبت التوجيه

تصف الفقرة 5.5 خطوة لاحقة. يمكن للـrelay أو خادم DHCPv6 تثبيت مسار محلي للمحدد، وينبغي أن يشير next hop إلى العميل الطالب. ويمكنه بعد ذلك إعلان المسار ببروتوكول توجيه تقليدي كي تتعلمه الموجهات الأخرى.

هذا الفصل جوهري. قد يوجد ربط الخادم من دون إدخال في RIB. وقد يظهر الإدخال من دون برمجة FIB. وقد تمنع سياسة التصدير الإعلان. وقد يخرج الإعلان من جهاز ولا تتقارب كل الموجهات. وحتى بعد التقارب قد تغيب SID أو SR policy المطلوبة على CPE. أما وصول الحزمة فيحتاج إلى ملاحظة محددة النطاق.

تحدد قيمة Algorithm أيضاً شكل الإعلان. تسمح القيمة صفر بإعلان reachability عادي لبادئة IP، بينما تتطلب القيمة غير الصفرية Locators TLV المعرفة لـIS-IS أو OSPFv3. محو هذه القيمة وتحويل كل شيء إلى بادئة IPv6 عامة يفقد معنى يحتاجه الحساب.

لذلك يجب أن يحتفظ الإثبات بعناصر منفصلة: ربط الخادم، تهيئة العميل، RIB، FIB، شكل الإعلان، التقارب، SID، السياسة، المرشحات، واختبار الحزمة. يمكن ربطها بالمحدد وIAID نفسيهما، لكن لا يجوز منحها نتيجة نجاح واحدة.

الإنهاء يختبر قابلية الرجوع

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

يعرف الخادم IAID، ويعرف جهاز النفاذ next hop، ويملك نظام التوجيه الإعلان، وقد تحفظ وحدات التحكم SIDs وسياسات وذاكرات مؤقتة. يحتاج إثبات الإنهاء إلى مفتاح يربط الرابطة المنتهية بكل حالة مشتقة منها.

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

القراءة الصحيحة تجمع قائمة العقود الحالية ومدى التجميع ومعاملة البادئة المحددة عند الحد. قد يكون الإسقاط المنضبط لحزمة نحو محدد منتهٍ هو النتيجة الآمنة المقصودة.

الثقة تحتاج إلى أدلة تشغيلية

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

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

من السجل إلى النتيجة الجارية

تقدم Running-Code Primacy لدى Heng Lu اختباراً مباشراً: يسجل العقد حقيقة إدارية، لكنه لا ينشئ المسار. وتطلب Minimum Initial Specification أن تكون القواعد المشتركة صارمة بقدر ما تحتاجه قابلية التشغيل البيني والسلامة، مع إبقاء اختيارات المستقبل محلية.

تحدد RFC 10038 الرموز والصيغ والساعات وسلوك العميل والخادم والـrelay وحدود التحرير والتوجيه. ولا تختار خطة SID أو التجميع أو سياسة الخدمة لكل مشغل. لذلك يجب أن تقدم الأنظمة المحلية دليلها الخاص حيث تنتهي الوثيقة المشتركة.

يربط السجل القابل للتكرار هوية العميل وIAID والـrelay والخادم والمحدد وبنيته وAlgorithm وT1/T2 والمدد والربط وتهيئة العميل والمسار والإعلان والتقارب وSID والسياسة والمرشحات واختباراً مضبوطاً للحزم. وعند التحرير تُفحص السلسلة نفسها في الاتجاه العكسي.

«مُنح المحدد» نتيجة دقيقة. «ثُبت المسار وأُعلن» نتيجة أخرى. «وصلت الحزمة ضمن شروط معروفة» نتيجة ثالثة. جعل عمل Cheng وزملائه النتيجة الأولى قابلة للتدقيق؛ ولم يحولها إلى سلطة على النتائج اللاحقة.

المصادر