الخلاصة

  • أتاح RFC 3736 لعقدة تملك عنوان IPv6 بالفعل أن تطلب إعدادات إضافية عبر تبادل DHCPv6 من رسالتي Information-request وReply، من دون طلب تخصيص عنوان.
  • تعني «بلا حالة» أن الخادم لا يحتاج إلى حفظ حالة ديناميكية لكل عميل كي يقدم هذه الخدمة؛ لكن معرّف العميل الاختياري والسياسة المحلية والمرحلات تظل ذات صلة.

العنوان ومحلّل الأسماء مهمتان منفصلتان

يمكن للتهيئة الذاتية عديمة الحالة في IPv6 أن تمكّن المضيف من تكوين عنوان اعتماداً على إعلانات الموجّه. لكن ذلك لا يجيب عن كل احتياجاته: فقد يحتاج أيضاً إلى عناوين خوادم DNS التكرارية أو معلومات خوادم SIP أو خيارات أخرى. ومن السهل تصور DHCP كحزمة واحدة: يطلب المضيف عنواناً من الخادم ويتلقى معه بقية إعدادات الشبكة.

فصل RFC 3736 بين الوظيفتين. يكون العميل قد حصل على عنوانه بوسيلة أخرى — غالباً التهيئة الذاتية عديمة الحالة أو الإعداد اليدوي — ويملك على الأقل عنواناً محلياً للرابط كي يتواصل. يرسل Information-request متضمناً خيار طلب يحدد أنواع الخيارات التي يريدها. ويرد الخادم برسالة Reply تحمل معلمات الإعداد التي اختارها. لا يطلب هذا النمط رابطة هوية للعنوان ولا يخصص فيه الخادم عنواناً.

اختُصر التبادل عمداً إلى رسالتين: Information-request ثم Reply. يستطيع المضيف طلب إعداد DNS من دون تحويل ذلك إلى إيجار عنوان. ويمكن لنظام الخادم نفسه خدمة العملاء الذين يطلبون عناوين وآخرين لا يريدون سوى معلمات إضافية؛ كما تعمل مرحلات DHCP بالطريقة نفسها المستخدمة مع الخدمة ذات الحالة.

لكن «بلا حالة» لا تعني أن الخادم بلا إعداد أو سياسة. ينص RFC 3736 على أن الخادم غير ملزم بالاحتفاظ بحالة ديناميكية عن كل عميل. كما يسمح للعميل بإرسال Client Identifier إذا أراد المسؤول تخصيص الرد لذلك المضيف. يظل الخادم يختار الخيارات وفق سياسة إعداده، ويظل المرحّل قادراً على تمرير الرسائل. ما لا تتطلبه الخدمة هو إنشاء رابطة عنوان لكل عميل ومتابعتها.

يساعد هذا التمييز على قراءة أعلام إعلانات الموجّه في IPv6. في RFC 4861 يشير علم Managed إلى إتاحة العناوين عبر DHCPv6، ويشير علم Other إلى إتاحة معلومات أخرى، مثل DNS، عبره. وعندما يكون Managed مضبوطاً يصبح Other زائداً. هذان مؤشران إلى الإتاحة؛ ولا يثبتان أن المضيف أكمل تبادل DHCP أو ثبّت محلّل أسماء أو يستطيع الوصول إليه.

بإزالة إيجار العنوان أزيلت ساعته أيضاً

للعناوين المخصصة أعمار مفضلة وصالحة تخبر العميل متى يواصل استخدامها ومتى تصبح غير صالحة. أما المعلومات الأخرى فقد لا يصاحبها عمر مماثل. ترك RFC 3736 صراحةً من دون حسم متى ينبغي للمضيف إرسال Information-request جديد لتحديث القيم، ولم يضع قاعدة للتحديث بعد الانتقال إلى رابط جديد.

أضاف RFC 4242 لاحقاً خيار Information Refresh Time، وهو حد أقصى للمدة قبل أن يطلب العميل تحديث معلومات DHCPv6. والسبب مهم: عندما لا يتضمن التبادل إيجار عنوان أو بادئة، قد لا توجد مدة صلاحية تخبر العميل بموعد العودة. ثم جمع RFC 8415 مواصفات DHCPv6، وأحلّ محل RFC 3736 وRFC 4242 مع الإبقاء على نمط طلب المعلومات ذي الرسالتين.

إذن فالتاريخ ليس «اختفى DHCP بمجرد أن كوّن SLAAC عنواناً». يمكن فصل تكوين العنوان عن بقية إعداد المضيف. يقلل ذلك الحالة المطلوبة لكل عميل في خادم المعلومات، لكنه يترك أولوية المصادر والتحديث ونطاق الواجهة وتثبيت محلّل الأسماء على المضيف ضمن دورة الإعداد. تثبت Reply أن البروتوكول أعاد خيارات؛ لكنها لا تثبت وحدها أن المضيف ثبّتها أو أن استعلام DNS نجح.

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

المصادر