الخلاصة

  • يضع العميل القادر الرمز 108 في قائمة المعلمات المطلوبة ضمن DHCPv4. ولا ينبغي للخادم إعادة خيار «IPv6-Only Preferred» إلا من مجموعة عناوين مضبوطة صراحة بوصفها IPv6-mostly؛ عندها يمتنع العميل عن طلب عنوان IPv4 المعروض.
  • الحد الأدنى للانتظار 300 ثانية، أما القيمة الافتراضية في RFC 8925 فهي 1800 ثانية. ينتهي التوقف بانقضاء المدة أو بحدث اتصال جديد. الدقائق الخمس أداة رجوع سريع، لا إعلاناً بأن IPv4 أزيل إلى الأبد.

عرض عنوان لا يُفترض قبوله

يعني DHCPOFFER عادة أن الخادم يعرض عنواناً كي يطلبه العميل. الخيار 108 يقلب النتيجة من داخل البروتوكول نفسه. يضيف العميل الرمز إلى Parameter Request List في DHCPDISCOVER أو DHCPREQUEST. ولا يرسل قيمة المؤقت ذات البايتات الأربعة؛ بل يقول فقط إن العنوان اختياري على هذه الواجهة إذا وفرت الشبكة وظائف التشغيل عبر IPv6 وحده.

لا يحق للخادم أن يفسر الصمت موافقة. يجب أن يكون العميل قد طلب الخيار، وأن تكون مجموعة العناوين المختارة مضبوطة كشبكة يغلب عليها IPv6. عند اجتماع الشرطين يعيد الخادم V6ONLY_WAIT. ويوصي RFC بأن تكون قيمة العنوان المعروض 0.0.0.0. فإذا تعذر ذلك بسبب البرنامج أو البنية، يجوز عرض عنوان حقيقي متاح، لكن من دون حجزه، لأن العميل غير متوقع أن يطلبه.

تفيد هذه المحادثة في جمع أجهزة مختلفة على الوصلة نفسها. الجهاز الذي لا يعرف الخيار يتابع DHCPv4 ويحصل على IPv4. والجهاز القادر يتخلى عنه. لذلك يمكن لأجهزة IPv4 فقط، والمكدس المزدوج، وIPv6 فقط أن تتشارك SSID أو VLAN من دون مضاعفة الشبكات أو بناء نظام قبول يدّعي معرفة كل تطبيق مسبقاً.

سلطة الآلية محدودة عمداً. لا تقرر أي جهاز «حديث»، ولا تضع موعداً سياسياً لنهاية الانتقال، ولا تجعل عدم التبني مخالفة. إنها تنسق اختياراً واحداً بين واجهة وحيز خادم محدد.

خمس دقائق كميزانية للتعافي

قيمة V6ONLY_WAIT عدد من 32 بت. إذا أرسل الخادم رقماً أقل من الحد الأدنى، يستخدم العميل 300 ثانية. أما القيمة الافتراضية في الوثيقة فهي 1800 ثانية، ولذلك لا يصح وصف الخمس دقائق بأنها الافتراضية.

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

توصي النسخة 07 من مسودة 6MOPS الصادرة في مارس 2026 بالبدء عند 300 ثانية كي يكون التراجع سريعاً، ثم زيادة المدة بعد إثبات الاستقرار. هذه Internet-Draft قيد العمل وليست RFC أو معياراً نهائياً. ومع ذلك، يمكن اختبار منطقها: إذا ظهرت تبعية خطرة، يتوقف المشغل عن إرسال الخيار، ويعود العملاء إلى DHCPv4 بعد انتهاء الوقت أو إعادة الاتصال.

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

ليس المؤقت علامة تردد. إنه ضمان ألا تتحول قراءة خاطئة لقدرة الجهاز إلى انقطاع طويل.

ستة سجلات لا مفتاح واحد

عبارة «الخيار 108 مفعّل» تختزل واقعاً يتكون من ست طبقات على الأقل.

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

الثانية الطلب المرصود. هل ظهر الرمز 108 فعلاً في قائمة المعلمات؟ إذا لم يطلبه العميل، فلا تشكل رسالة الخادم موافقة.

الثالثة نطاق الخادم. هل جاءت الاستجابة من المجموعة نفسها المضبوطة كـ IPv6-mostly؟ لا يكفي أن تعرض لوحة الجهاز أن الميزة متاحة.

الرابعة العرض. هل كان طول الخيار أربعة بايتات؟ ما قيمة الانتظار؟ هل عُرض 0.0.0.0 أم عنوان حقيقي غير محجوز؟ يكشف التقاط مضبوط للحزم ذلك.

الخامسة حالة العميل. هل امتنع فعلاً عن طلب العنوان، وكم استمر؟ ماذا فعل عند INIT-REBOOT أو التجديد أو إعادة الاتصال؟ إرسال الخادم لا يثبت تنفيذ نظام التشغيل.

السادسة نتيجة الخدمة. هل وصل PREF64 في الوقت المناسب؟ هل كان NAT64 متاحاً؟ هل شُغّل CLAT للتطبيقات التي تحتاج socket من IPv4؟ هل أنجز المستخدم عمله؟ غياب الإيجار لا يجيب عن أي من ذلك.

الفصل بين الطبقات يسمح بعبارة قابلة للمراجعة: رفض هذا العميل هذا العنوان، في هذه المجموعة، طوال هذه المدة، ونجحت هذه التطبيقات أو فشلت. أما «أُوقف IPv4» فلا يقدم موضعاً للتشخيص.

الترجمة عقد مستقل عن الخيار

يفترض RFC 8925 وجود NAT64 للوصول إلى وجهات IPv4 فقط. لكنه لا يتفاوض على تقنية الترجمة، ولا يرسل بادئة NAT64، ولا يثبت أن الطريق إلى المترجم يعمل.

يعالج RFC 8781، الذي شاركت Jen Linkova في تأليفه أيضاً، جزءاً آخر من السلسلة. فهو يحدد خياراً في Router Advertisement لإبلاغ المضيف بـ PREF64. ويوصي RFC 9872 بهذه الطريقة في النشر الجديد، مع إبقاء الاكتشاف عبر DNS احتياطاً عندما لا يتوفر خيار RA أو لا يدعمه العميل. وقبل الحصول على PREF64 قد تتعطل التطبيقات والوجهات التي تعتمد IPv4 وحده.

يسد 464XLAT فجوة البرامج القديمة. يقدم CLAT على جهة العميل واجهة IPv4 للتطبيق، ثم يحمل المرور عبر IPv6 نحو مترجم الشبكة. لكن RFC 6877 واضح: هذه موصولية IPv4 محدودة، وليست بديلاً واحداً مقابل واحد لكل وظائف IPv4؛ فلا تعيد الاتصالات الواردة ولا جميع أنماط الند للند.

لذلك قد يكون الخيار 108 صحيحاً وتفشل الخدمة. رفض العميل العنوان لكن RA لم يحمل PREF64. وصلت البادئة لكن مسار NAT64 مقطوع. نجحت الترجمة لكن VPN حجب ترويسات امتداد IPv6. نجح المتصفح عبر IPv6 الأصلي بينما فشل تطبيق يستخدم عنوان IPv4 حرفياً لأن CLAT لم يعمل.

يجب أن يسمي تقرير الحادث الطبقة المكسورة. وصف كل ذلك بأنه «مشكلة IPv6» يلغي القدرة على معرفة ما إذا أوفى DHCP بوعده وما الذي يحتاج إلى إصلاح.

ما كان المكدس المزدوج يخفيه

يستطيع Happy Eyeballs ترك مسار IPv6 متعطل والانتقال إلى IPv4 من دون أن يشعر المستخدم. هذا مفيد للتجربة، لكنه قد يخفي خللاً سنوات. عند إزالة العنوان لا يبقى المسار البديل، فيظهر العطل القديم لأول مرة.

تقترح مسودة 6MOPS ترتيباً تدريجياً: تفعيل إعلان PREF64 أولاً، ثم معالجة الخيار 108 على خادم DHCPv4، ثم التفعيل المضبوط لكل جهاز إذا كان المشغل يدير الأجهزة. وتحذر من أن بعض الأنظمة يعالج الخيار افتراضياً ولا يوفر مفتاح إيقاف؛ يصبح هذا النظام IPv6 فقط فور بدء الخادم بإرسال الخيار، فيتحول تعديل خادم صغير إلى حدث على مستوى الشبكة الفرعية.

عرضت شرائح Jen Linkova في IETF 118 تجربة في مكاتب Google بدأت بمواقع تجريبية ثم توسعت بنسب متدرجة. وأشارت إلى انخفاض استخدام DHCP وعناوين متوقع استعادتها. هذه أرقام منسوبة إلى ذلك العرض وتلك البيئة، وليست قياساً عالمياً مستقلاً.

ما يمكن نقله هو المنهج: مجموعة صغيرة، رصد، توسع، ومسار رجوع. تضع الوثيقة فرضية تشغيلية؛ وتقرر الإيجارات والحزم والحوادث إن كانت قد نجحت.

ماذا يثبت إيجار لم يؤخذ؟

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

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

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

يجب قياس عدد طالبي الرمز، والاستجابات الصحيحة، والإيجارات المتجنبة، والمحاولات اللاحقة، وحالات الرجوع، وصحة NAT64 وCLAT، والفشل حسب التطبيق، والعناوين التي أمكن فعلياً تقليص مجموعتها أو إعادة استخدامها. خانة فارغة في سجل الإيجار ليست بعدُ مورداً مستعاداً.

تمنع ساعة الدقائق الخمس تحويل جواب مؤقت إلى عقيدة. تسجل الشبكة «ليس الآن»، تراقب النتيجة، وتسمح بجواب مختلف لاحقاً.

دور Jen Linkova كما تثبته الوثائق

يسمي RFC 8925 كلاً من Lorenzo Colitti وJen Linkova وMichael C. Richardson وTomek Mrugalski مؤلفين. كما تظهر Linkova مع مؤلفين آخرين في RFC 8781 وRFC 9872 ومسودة 6MOPS الحالية. يثبت ذلك مساهمة مستمرة في آليات تشغيل IPv6 مترابطة، لا اختراعاً منفرداً ولا سيطرة على التطبيقات أو الشركات أو عمليات النشر.

هذا الحد ينسجم مع التصميم. الوثيقة تحدد معنى مشتركاً، والعميل يختار الطلب، والمشغل يضبط المجموعة، والكود الجاري ينتج النتيجة. الجهاز غير المشارك يستمر في DHCPv4 العادي ولا يصبح «غير صالح» بقرار مؤسسة.

المساهمة الأهم ليست وضع تاريخ لنهاية IPv4. إنها تحويل سؤال ضخم إلى اختبار محدود: هل يمكن لهذا العنوان، في هذه الظروف، أن يبقى في وضع الاستعداد لخمس دقائق؟ وبعدها يبقى للنظام حق السؤال مرة أخرى.

المصادر