الخلاصة

  • يستخدم عميل DHCPv6 رسالة Confirm بعد تغيّر معلومات الشبكة ليسأل عن ملاءمة عناوينه الحالية للوصلة الجديدة؛ ولا يوجّه السؤال إلى الخادم الذي منحها أصلاً.
  • تعني Success أن كل العناوين المقدمة اجتازت اختبار الوصلة. لا ينظر الخادم في T1 أو T2 أو العمر المفضل أو العمر الصالح، ولا تضيف الإجابة وقتاً إلى الإيجار.
  • يبيّن عمل Tomek Mrugalski مع مؤلفي RFC 9915 قيمة الفصل بين دليل الموقع، وسلطة الإيجار، ودليل التشغيل. لوحة تجمعها تحت عبارة «تم التأكيد» تنسب إلى البروتوكول وعداً لم يصدر عنه.

كلمة مطمئنة تجيب عن سؤال واحد

يستيقظ حاسوب محمول بعد انتقاله من شبكة إلى أخرى. ما تزال لديه عناوين IPv6، لكن معلومات الموجّه أو الوصلة تغيّرت. بدلاً من التخلص منها فوراً، يرسل العميل رسالة Confirm.

اسم الرسالة واسع؛ اختصاصها ضيق. لا يسأل العميل: «هل ما تزال تهيئتي كلها صحيحة؟» ولا يطلب وقتاً إضافياً. إنه يسأل: «هل مجموعة العناوين التي لدي ملائمة لهذه الوصلة؟»

يخصص RFC 9915 هذا الإجراء لعميل لديه عناوين من دون بادئات مفوضة. يضع في الطلب معرّف العميل وروابط الهوية التي تحتوي جميع العناوين المعنية. ولا يضع Server Identifier. فإذا سمّى خادماً بعينه، وجب على الخادم إسقاط الرسالة.

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

إذا كانت العناوين كلها ملائمة، يرسل Success. وإذا كان واحد منها على الأقل غير ملائم، يرسل NotOnLink. وإذا لم يملك معلومات البادئات اللازمة، أو لم يتلق عنواناً يفحصه، فلا يجيب. لذلك لا يجوز تحويل الصمت إلى موافقة ضمنية.

الأصفار ترسم حدود السلطة

توجد في الرسالة حقول زمنية، لكن المواصفة تطلب من العميل ضبط T1 وT2 في IA_NA، والعمرين المفضل والصالح في IA Address، على صفر لأن الخادم سيتجاهلها.

هذه العبارة القصيرة تمنع خلط وظيفتين. العناوين جزء من سؤال عن الطوبولوجيا. أما أزمنة الإيجار فليست معروضة على المجيب كي يمددها. معرفة أن بادئة ما تخص الوصلة لا تعني امتلاك سجل الربط بين ذلك العنوان وذلك العميل.

تظهر سلطة الوقت في Renew. عند T1، يعود العميل إلى الخادم الذي حصل منه على الإيجار. يستطيع ذلك الخادم العثور على الربط وإرجاع قيم جديدة لـT1 وT2 والعمرين المفضل والصالح. وإذا تعذر الرد حتى T2، تسمح Rebind للعميل بطلب التمديد من خادم متاح يستطيع تحمل المسؤولية.

سجل IANA يعطي العمليات رموزاً منفصلة: 4 لـConfirm، و5 لـRenew، و6 لـRebind. وهذه ليست ثلاث طرق لقول «الإيجار جيد»:

  • يوزع Confirm سؤال الوصلة على أي خادم يملك معرفة كافية بها.
  • يحفظ Renew قرار التمديد أولاً للخادم المانح.
  • يفتح Rebind باب التمديد لسلطة أخرى بعد تعذر المسار الأول.

رمز الرسالة يثبت اتفاق الطرفين على اسم العملية فقط. لا يثبت أن المجيب يملك الربط، أو أن الساعة تغيرت، أو أن حركة البيانات وصلت إلى غايتها.

الاستمرار لا يعيد ملء الساعة الرملية

بعد Success، يستطيع العميل مواصلة استخدام العناوين وفق آخر أعمار معروفة. لو بقي من العمر الصالح ثلاثون دقيقة قبل الرسالة، فلن تصبح ثلاثين دقيقة جديدة بعد الرد. إنها الدقائق نفسها وهي تتناقص.

وقد يتخذ العميل الإجراء الفوري نفسه من دون أي Reply. إذا انتهت محاولة Confirm بلا رد صالح، يوصي RFC 9915 بالاستمرار في استخدام الإيجارات والتهيئة الأخرى وفق أعمارها المعروفة. من ثم، بقاء العنوان على الواجهة لا يكشف هل وصل Success أم انتهت المهلة.

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

يوضح RFC 4862 أثر الساعة. يكون العنوان مفضلاً، ثم يصبح متقادماً، ثم غير صالح. قد يخدم العنوان المتقادم اتصالات قائمة مع عدم تفضيله لاتصالات جديدة. أما غير الصالح فلا يستخدم مصدراً ولا يقبل وجهة. لا تحول Confirm هذه المراحل إلى حالة واحدة اسمها «نشط».

إنها استمرارية بلا إيجار خيالي. يمنع البروتوكول انقطاعاً غير ضروري حين يتأخر المجيب، لكنه لا يمنح العميل وقتاً لم يمنحه أي خادم.

إجابة إيجابية واحدة لا تمحو الخلاف

لأن الطلب لا يحدد خادماً، قد تصل عدة Replies. تنص المواصفة على أن العميل يستطيع استخدام العناوين إذا حمل أي رد صالح Success، وأن يتجاهل ردود NotOnLink. ولا يبدأ اكتشاف الخوادم من جديد إلا إذا وصل رد واحد أو أكثر وكانت كلها NotOnLink.

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

لهذا ينبغي ألا تختزل السجلات ثلاثة ردود مختلفة في مؤشر أخضر واحد. عند وصول Success من خادم وNotOnLink من خادمين، يجب حفظ DUID لكل مجيب، ومسار relay، والواجهة، ومجموعة العناوين، ومراجعة البادئات التي استند إليها، والقرار الذي اتخذه العميل. قد يكون الخلاف أول أثر لعطل تهيئة لم يظهر بعد في الخدمة.

كما أن الحكم يخص المجموعة كلها. يكفي عنوان غير ملائم لكي تكون النتيجة NotOnLink، ولا تخبر الحالة وحدها أي عنوان تسبب بها. السجل الذي لا يحفظ المدخلات لا يستطيع تفسير المخرجات لاحقاً.

ما لا تستطيع Success إثباته

قد يكون العنوان ضمن البادئة الصحيحة ويفشل في اكتشاف العنوان المكرر. ملاءمة الوصلة ليست دليلاً على التفرد.

وقد يكون ضمن الوصلة بينما يتعذر الوصول إلى الموجّه المجاور. يعرّف RFC 4861 لاختبار وصول الجار آلة حالات ورسائل مختلفة.

وقد يكون صالحاً مصدراً فيما المسار الأعلى مفقود أو محجوب. معرفة الخادم بالبادئة ليست إيصالاً لتسليم الحزمة.

وقد يبقى الإيجار صالحاً فيما جلسة التطبيق منقطعة. تهيئة DHCP لا تضمن استمرارية النقل.

وقد يكون الخادم المجيب يعرف موقع البادئة من دون أن يعرف الربط الأصلي الذي أنشأه خادم آخر. Success لا تثبت سلسلة حفظ موحدة بين قاعدتي البيانات.

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

Tomek Mrugalski بين المواصفة والتنفيذ

يحمل RFC 9915 صفة Internet Standard STD 102، وشارك في تأليفه Tomek Mrugalski وBernie Volz وMichael C. Richardson وSheng Jiang وTimothy Winters، إضافة إلى مساهمات مجتمع أوسع. أسماء المؤلفين تشرح منشأ النص، لكنها لا تمنحهم سلطة على منتج بعينه أو شبكة مشغل بعينه.

تجعل السيرة العامة لـMrugalski منه مدخلاً مناسباً لفهم هذا الحد. يسجل IETF Datatracker عملاً واسعاً له في RFCs الخاصة بـDHCP. ويروي ملف ISC المكتوب أن مشروع Dibbler بدأ في عمله الجامعي ونما إلى تنفيذ DHCPv6، ثم شارك في تطوير Kea. ذلك سياق مهني موثق بتاريخ، وليس ضماناً بأن كل إصدار يطبق كل مسار بالطريقة نفسها.

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

وتضيف أولوية الكود العامل سؤالاً عملياً: أي فرع نفذه العميل فعلاً؟ اسم Confirm في السجل لا يجيب. قد يبدو Success والصمت متشابهين للحظات لأن العنوان بقي، ثم يفترقان عند انتهاء العمر. لا بد من ربط النص بالمسار التنفيذي.

تظهر مشكلة الوكالة عندما تتوزع التكلفة. يستطيع المورد إظهار «نجاح Confirm» بسهولة. يحتفظ مشغل النفاذ بسياق الوصلة والـrelay. تدير خدمة الإيجار سجل الربط. ويتحمل المستخدم الانقطاع إذا انتهت الصلاحية. حين تتحول أرخص إشارة إلى وعد عن الجميع، يحدد صاحب الإشارة معنى النجاح بينما يتحمل غيره الخسارة.

ستة إيصالات لعنوان بقي في مكانه

الإيصال الأول يثبت سبب السؤال: الواجهة، ومعلومات الموجّه أو الوصلة قبل التغير وبعده، وحالة العميل، والوقت. بدونه لا يمكن ربط الرسالة بحركة محددة.

والثاني يجمد الإيجار السابق قبل السؤال: DUID للخادم المانح، وIAID، والعنوان، ووقت الحصول عليه، وT1 وT2، والعمرين المفضل والصالح، وما تبقى منهما. هذه هي الساعة الحاكمة.

والثالث يحفظ الطلب: DUID للعميل، ومعرّف المعاملة، ومجموعة العناوين كاملة، والواجهة، وغياب Server Identifier. يبين الغياب أن السؤال كان عن الوصلة لا عن خادم بعينه.

والرابع يحتفظ بكل Reply: DUID للمجيب، ومسار relay، وسياق الوصلة، والحالة، ومجموعة البادئات أو مراجعة التهيئة التي استخدمها. أما الصمت فيسجل كانتـهاء للمحاولة، لا كـSuccess مصطنعة.

والخامس يشرح قرار التجميع: Success واحد على الأقل، أو ردود كلها NotOnLink، أو لا رد صالح. ويسجل هل واصل العميل أم أعاد الاكتشاف.

والسادس يفصل الأدلة اللاحقة: Renew أو Rebind، والأعمار الجديدة، والتقادم والإبطال، واكتشاف التكرار، والوصول إلى الجار، والمسار، ونتيجة التطبيق. قد تتفق هذه الحقائق كلها، لكن لا يجوز اشتقاق أي منها من كلمة Success وحدها.

الصياغة الصادقة ليست طويلة: «اعتبر الخادم S العناوين ملائمة للوصلة في الوقت T؛ أعمار الإيجار الأصلية لم تتغير». إنها أقل لمعاناً من علامة خضراء، وأقدر على تفسير ما سيحدث حين تنفد الساعة.

المصادر