الخلاصة

  • يضيف الإصدار 03 من مسودة Mark Smith الفردية بديلاً للعملاء الذين يشترطون خيار DHCPv4 Router 3: عنوان DHCP الخاص بالمضيف أو 127.0.0.1.
  • تتوقع المسودة أن تُبقي القيمتان حزم IPv4 غير المحلية داخل المضيف وأن تنتجا رسالة ICMP Destination Unreachable. هذا اقتراح، وليس نتيجة توافق منشورة.
  • الاختبارات التي أشار إليها مدوّنة LACNIC في 2 أكتوبر تناولت الإصدار 02، قبل إضافة هذا المسار.

التحليل

من المفترض أن تنقل البوابة الافتراضية الحركة إلى شبكة أخرى. لكن مراجعة جديدة لمسودة DHCPv4 تقترح أن يشير هذا الحقل، لدى بعض العملاء الأقدم، إلى الجهاز نفسه.

نشر Mark Smith الإصدار 03 من “Nearly IPv6 Only Dual Stack Hosts” في 16 أكتوبر. وكان الإصدار 02 قد انتهت صلاحيته في 15 يونيو. ويحافظ الإصدار الجديد على مسار حذف خيار DHCP Router 3 للعملاء الذين يقبلون غيابه، لكنه يضيف بديلاً لمن يُقال إنهم يشترطونه: إعادة عنوان DHCP الممنوح للمضيف نفسه أو 127.0.0.1 بوصفه قيمة للموجّه.

هذه ليست بوابات عادية. تحدد RFC 2132 الخيار 3 بوصفه قائمة الموجّهات التي يرسلها خادم DHCP إلى المضيف. وتقول المسودة إن استخدام قناع /32 مع إحدى القيمتين ينبغي أن يبقي الحزم المتجهة إلى عناوين IPv4 غير المحلية داخل المضيف، وأن يولّد فوراً رسالة ICMPv4 Destination Unreachable. لكن النتيجة تعتمد على تفسير العميل للمسار. ولا تنشر الوثيقة مصفوفة تبين أي العملاء يقبلون كل قيمة، وما المسارات التي يثبتونها، أو ما إذا كانت التطبيقات تعيد المحاولة عبر IPv6.

لا تجيب الاختبارات السابقة عن ذلك. تشير مقالة Alejandro Acosta المنشورة في مدوّنة LACNIC في 2 أكتوبر إلى الإصدار 02، وتذكر اختبارات على Windows 11 وFedora 43 وRaspberry Pi OS المبني على Debian Trixie وChromecast وGoogle Nest. وتقول أيضاً إن الهواتف الذكية لم تُختبر وإن الحاجة قائمة إلى مزيد من الاختبارات. حدثت تلك التجارب قبل الإصدار 03؛ لذلك لا تثبت صلاحية فرع Router الجديد.

ينبغي ألا يقتصر التحقق على قدرة خادم DHCP على إرسال القيمة. على مشغلي الشبكة مقارنة عنوان المضيف نفسه و127.0.0.1 في اختبارين منفصلين، عبر عملاء وإصدارات أنظمة مختلفة، مع توثيق إعدادات الخادم أو المرحّل. ويجب حفظ DHCP ACK، وفحص جدول المسارات الفعلي، والتقاط الحزم المتجهة إلى وجهات IPv4 خارج الجهاز، ثم التحقق من وصول خطأ ICMP إلى التطبيق ومن إعادة المحاولة عبر IPv6. كما ينبغي اختبار الاتصال داخل الوصلة على حدة: تعطيل التوجيه لا يثبت اختفاء كل اتصال IPv4 المحلي.

ولا تحل هذه المسودة محل DHCPv4 Option 108. تتيح RFC 8925 للمضيف المتوافق أن يعلن تفضيله للعمل عبر IPv6 فقط لمدة محددة. أما المقترح الجديد فيتناول الأجهزة التي لا تدعم ذلك الخيار أو ما زالت تنتظر إجابة DHCPv4. ومن ثم فإن التغيير في الإصدار 03 يطرح سؤال توافق، ولا ينشئ معياراً جديداً.

يعرض Datatracker الإصدار 03 بوصفه مسودة فردية نشطة، بلا مسار RFC وبحالة IESG “I-D Exists”. وتوضح الوثيقة نفسها أنها غير معتمدة من IETF ولا تتمتع بوضع رسمي في عملية المعايير. كما تذكر حالة مقصودة هي Informational وانتهاء الصلاحية في 19 أبريل 2027. استمرار تحديث المسودة يثبت أن الاقتراح لا يزال قيد العمل، لا أن IETF أو موردي أنظمة التشغيل اعتمدوه.

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

المصادر