الخلاصة

  • يحدد RFC 9915 DHCPv6 بوصفه نظاماً للتكوين عديم الحالة ولإسناد العناوين والبادئات بحالة، ويمكنه العمل بدلاً من SLAAC أو إلى جانبه.
  • نُشر RFC 9915 في يناير 2026 بوصفه معيار IETF للإنترنت STD 102، وهو يلغي RFC 8415 ويضم التصحيحات المعتمدة.
  • التغيير التشغيلي ليس رسالة عنوان جديدة، بل جعل هوية العميل والخادم، وروابط الهوية، والأعمار، والتجديد، وإعادة الربط، وتفويض البادئات قابلة للتتبع خلال دورة الحياة.

في التبادل المعتاد يرسل العميل رسائل الاكتشاف والطلب، ويعرض الخادم معلمات العنوان أو البادئة والخيارات، ثم يحتفظ الطرفان بسياق يحدد من يملك الحالة. يعرّف DUID العميل، ويُستخدم Server Identifier لتمييز الخادم صاحب العرض أو الحالة. لا يكفي نجاح Reply الأول: لكل Identity Association، مثل IA_NA للعناوين، أعمار صالحة ومرغوبة، ونوافذ T1 وT2 تحدد متى يجدد العميل ومتى يعيد الربط إذا تعذر الوصول إلى خادمه.

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

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

يحذف RFC 9915 تعيين العناوين المؤقتة IA_TA، كما يحذف قدرة Server Unicast، بما فيها خيار Server Unicast ورمز الحالة UseMulticast. هذا تضييق للسلوك القديم، لا إعلان بأن عناوين الخصوصية اختفت. فـ SLAAC في RFC 4862، وامتدادات العناوين المؤقتة في RFC 8981، يقدمان حدوداً مستقلة لعناوين الخصوصية؛ ولا ينبغي تحويل إزالة IA_TA إلى استنتاج بأن DHCPv6 حل محل SLAAC في كل شبكة.

وتزداد المخاطر مع تعدد روابط الهوية أو خيارات DHCPv6 ذات الحالة. قد ينجح IA للعناوين ويفشل IA آخر، أو قد تُدار البادئة المفوضة في مسار مختلف. يحذر RFC 7550 من افتراض أن كل الحالات المتعددة تتصرف كمعاملة واحدة. لذا يجب أن تعرض المراقبة حالة كل IA، وDUID، وServer Identifier، وT1/T2، والمدة المتبقية، ونتيجة التجديد وإعادة الربط، ومعرّف المرحّل، واستخدام البادئة الهابطة.

سجل الادعاء–الدليل

الادعاء الدليل
الحالة الحالية لـ DHCPv6، الإزالة، الأعمار والتبادلات RFC 9915
خط الأساس الملغى وحدود المقارنة RFC 8415
التكوين الذاتي SLAAC والتعايش RFC 4862
متطلبات راوتر العميل وتفويض البادئة RFC 7084
سلوك خيارات DHCPv6 المتعددة ذات الحالة RFC 7550
العناوين المؤقتة للخصوصية مع SLAAC RFC 8981

هذه ليست دعوى عن دعم مورّد أو انتشار شامل. كما أن سلوك شبكة مختلطة تجمع تطبيقات مبنية على RFC 8415 وRFC 9915، أو حدود المهلات الآمنة، يحتاج إلى دليل اختبار محلي؛ لا يكفي النص المعياري لإثباته.