الخلاصة

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

الغياب يحتاج سلسلة كاملة

لا يحول RFC 9915 كل حقل مفقود إلى أمر. يلزم حفظ الـReply الأولى، والطلب اللاحق الذي طلب الخيار، والـReply المرتبطة التي أغفلته بعد التحقق منها. من دون الطلب لا نعرف هل كان على الخادم إرسال الخيار، ومن دون سياق المعاملة لا نعرف هل يحق للعميل تطبيق الرسالة.

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

استثناء ضيق ومثال إلزامي

يجوز بقاء القيمة فقط إذا تعذر إيقافها عملياً، ولم يوجد مصدر آخر، ولم يكن لها أثر خارجي. المثال هو hostname من Client FQDN وفق RFC 4704. أما عنوان خادم NTP المحذوف من Reply المؤهلة فيجب على العميل أن يتوقف عن استخدامه؛ RFC 5908 يحدد خيار موقع خادم الوقت.

ومع ذلك يسمح RFC 9915 بمصدر آخر للمعلومة نفسها. يرسل RFC 3646 عناوين DNS عبر DHCPv6، بينما يرسل RFC 8106 عناوين RDNSS عبر Router Advertisement. بقاء العنوان نفسه قد يعني سلطة جديدة لا تجاهل السحب القديم.

لا تخلط IA وReconfigure بالنتيجة

تُستثنى IA_NA وIA_PD وتُعالج وفق 18.2.10.1. وReconfigure مجرد محفز لتبادل Renew أو Rebind أو Information-Request. استلام المحفز، وإتمام التبادل، وتطبيق الحالة، وعودة الخدمة وقائع منفصلة.

أكمل الدليل داخل العميل

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

المصادر