الخلاصة

  • يمكن لقناع DHCPv4 بطول /32 وحذف خيار الموجّه تلبية طلب العميل القديم مع إزالة مساره المعتاد إلى عناوين IPv4 خارج الوصلة.
  • قد تتوقف الطلبات المتكررة، لكن العميل يحتفظ بإيجار فريد ويمكن لمضيف آخر على الوصلة أن يرسل إليه حزم IPv4.

هدوء الطلب لا يعني عودة العنوان إلى المجموعة

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

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

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

يظل لكل مضيف إيجار فريد

تلفت المسودة إلى تكلفة قد يخفيها وصف «شبه مقتصر على IPv6»: يحتاج خادم DHCPv4 إلى منح كل مضيف على الوصلة عنواناً فريداً. ولا يمكن عادةً منح العنوان نفسه لجميع العملاء الهادئين على مقطع مشترك. وقد يجري فحص لاكتشاف التعارض قبل استخدام العنوان. وإذا حصل جهازان على العنوان نفسه يظهر التعارض؛ وتحذر المسودة من أن إعادة العنوان المتعارض باستمرار قد تؤدي إلى حلقة من رسائل DHCPDECLINE.

قد يقل ضجيج الطلبات بينما يستمر التخصيص. يظل الإيجار يشغل خانة في مجموعة العناوين إلى أن يحرر العميل العنوان أو تنتهي مدة الإيجار الديناميكي. وتعرّف RFC 2131 التخصيص الديناميكي بأنه مؤقت وقابل لإعادة الاستخدام حين لا تعود الحاجة إليه. وجود سجل إيجار نشط لا يقيس حركة البث ولا يثبت أن العنوان صار متاحاً.

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

تسمح المسودة بإعادة استخدام منضبطة للمجموعة نفسها بين وصلات مادية مختلفة عندما يكون خادم DHCP متصلاً مباشرة بكل وصلة. لكن هذا ليس إذناً عاماً. عند استخدام DHCP relay، يستند الخادم إلى عنوان المرحّل لاختيار المجموعة، ولذلك تشترط المسودة تفرد المجموعة على امتداد الشبكة المرحّلة. تجاهل هذا الحد قد يحول الوفر النظري إلى خطأ في اختيار العنوان.

الإيجار الأطول يقلل التجديد ويطيل الحجز

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

يوفر الخيار 108 مساراً مختلفاً لفئة أخرى. توحّد RFC 8925 خيار IPv6-Only Preferred للعملاء المتوافقين في شبكة IPv6-mostly مضبوطة صراحةً لهذا الغرض. وإذا دعم العميل والخادم الآلية، يستطيع العميل الاستغناء عن عنوان IPv4 حين توفر الشبكة الوظائف اللازمة. وقد يحافظ ذلك على سعة المجموعة. أما طريقة /32 فتستهدف العملاء الذين لا يفهمون الخيار 108؛ وتقول المسودة إن الأسلوبين يمكن أن يتعايشا. ولا يثبت أي منهما وحده عمل التطبيقات أو DNS64/NAT64 أو الخدمات المطلوبة.

غياب البوابة لا يعادل جداراً نارياً

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

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

ما الذي تظهره المصادر العامة

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

الوثيقة المشار إليها هي النسخة 02 من مسودة إنترنت فردية. يسجل IETF Datatracker انتهاءها في 15 يونيو 2026، ويذكر أنها لا تملك وضعاً رسمياً في عملية معايير IETF. لا يثبت الانتهاء رفضاً تقنياً، كما أن وجود المسودة لا يجعلها معياراً معتمداً. ولا تقدم المواد التي راجعناها انخفاضاً مقاساً في بث DHCP أو سلسلة لإشغال المجموعة أو نتائج انتقال التطبيقات أو تدقيقاً للأمن الوارد.

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

المصادر: