الخلاصة

  • Reconfigure مشغّل موثّق يطلب من العميل بدء Renew أو Rebind أو Information-request؛ إرسالها لا يثبت إعداداً جديداً.
  • استلام الخادم للطلب الذي حدده يفي بطلب Reconfigure الخاص به، لكن Reply والتثبيت المحلي والأثر التشغيلي تبقى سجلات مستقلة.

المشكلة ليست في الرسالة، بل في اختصارها إلى كلمة «اكتمل». وفق RFC 9915 يرسل الخادم Reconfigure لكي يبدأ العميل واحداً من تبادلات لاحقة محددة. لا ترسل الرسالة بنفسها عنواناً مطبقاً أو بادئة مستخدمة أو خادماً محللاً فعلياً، ولا تمنح مراقباً دليلاً على أن أيّاً من ذلك صار واقعاً.

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

إن وصل Reconfigure صالح إلى العميل، فالحقيقة التالية ما زالت ضيقة. يحدد الخيار Renew أو Rebind أو Information-request، ويبدأ العميل التبادل المختار ويتجاهل Reconfigure إضافية أثناءه. تسمي RFC الرسالة الأولى trigger؛ فهي تشغّل معاملة أخرى، ولا تجعل إعداداً معيناً نافذاً بمفردها.

بعد ذلك يستطيع الخادم أن يسجل إيصالاً محدداً. عندما يتلقى Renew أو Rebind أو Information-request الذي طلبه، يفسر ذلك بوصفه إيفاءً بطلب Reconfigure. النتيجة الصادقة هي أن الخادم تلقى نوع رسالة العميل الذي طلبه. ليست النتيجة أن Reply وصل، أو أن خياراته قُبلت، أو أن نظام العميل ثبّتها.

ولا تؤدي التبادلات الثلاثة إلى ادعاء واحد. لـ Renew وRebind قواعدهما الخاصة بالربط واختيار الخادم؛ أما Information-request فيطلب معلومات من دون عناوين أو بادئات. Reply هو الكائن الذي قد يحمل معلومات الإعداد في كل تبادل. لذا يلزم Reply وخياراته أو IA ذات الصلة للقول إن قيمة بعينها تغيّرت. وللقول إن النظام ثبتها، أو اختار مساراً، أو استخدم DNS، أو مرّر حركة، أو أكمل تطبيقاً، يلزم دليل مستقل من موضع تلك النتيجة.

المصادقة تحمي حافة محددة ولا تدمج ما بعدها. تفرض RFC 9915 مصادقة DHCP في Reconfigure بسبب خطر حجب الخدمة. وتقدم RFC 9096، التي شارك Volz أيضاً في تأليفها، سياقاً لتحسينات أمن وخصوصية DHCPv6. لا يمنح أي منهما شهادة عامة بالتوافر أو النجاح التشغيلي.

ينبغي للسجل القابل للمراجعة أن يحتفظ بـ DUID العميل، ومعرف الخادم، وإرسال Reconfigure ونتيجة التحقق، وmsg-type المطلوب، والطلب المطابق الذي استلمه الخادم، وReply وحقوله المناسبة. وإذا كان الادعاء عن نتيجة تشغيلية، تضاف ملاحظة مستقلة عن التثبيت أو التنفيذ. يساعد سجل IANA في تسمية شفرات DHCPv6، لكنه لا يثبت أن المراحل اللاحقة وقعت.

تنسجم هذه الطريقة مع مبدأ Heng Lu: احتفظ بأصغر حقيقة شوهدت. «أرسل الخادم Reconfigure» و«تلقى الخادم الطلب المطلوب» عبارتان نافعتان. تسميتهما «العميل مهيأ» تستبدل الدليل بتوقع. Volz مؤلف مشارك في معيار جماعي، لا مالك لعميل أو خادم أو شبكة حقيقية في هذه القصة.

المصادر