الخلاصة

  • أعطت RFC 3361 خيار DHCPv4 رقم 120 ترميزين متنافيين: قائمة مفضلة من أسماء DNS أو قائمة مرتبة من عناوين IPv4 لوكلاء SIP الصادرين المحليين.
  • يستطيع الاسم تفويض اختيار النقل والمنفذ والمثيل والبديل إلى DNS، بينما يجمد العنوان ترتيب المضيفين. لا يثبت أي منهما نجاح معاملة SIP أو مسار الاتصال اللاحق.

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

صدرت RFC 3361 في أغسطس 2002 ضمن Standards Track، وحددت خيار DHCPv4 رقم 120 لاكتشاف وكيل SIP محلي للطلبات الصادرة. أمكن للعميل في بعض البيئات الاتصال مباشرة بالهدف في URI، بينما احتاج في بيئات أخرى، ومنها الشبكات التي فيها جدران نارية، إلى خادم محلي. كان DHCP طريقة من عدة طرق، وظل الإعداد اليدوي ممكناً.

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

لم يكونا شكلين كتابيين للمعلومة نفسها. يفتح اسم النطاق إجراء تحديد خادم SIP في RFC 3263. تستطيع سجلات NAPTR عرض وسائل النقل، وتستطيع SRV تحديد المثيلات والمنافذ والأولويات والأوزان، ثم توفر A أو AAAA العناوين أو مساراً احتياطياً. يطابق العميل ما يقدمه النطاق مع قدراته وسياساته. وهكذا يفوض الاسم القرار إلى رسم خدمات قابل للتغيير.

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

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

حددت RFC 3361 معنى وجود أسماء عدة. ينبغي أن تشير إلى نطاقات NAPTR مختلفة، كموفرين مختلفين، لا أن تحل محل عدة سجلات A لنطاق واحد. يجرب العميل النطاقات بالترتيب، ولا ينتقل إلى التالي إلا إذا فشل الاتصال أو لم توجد وسيلة نقل مشتركة أو حظرت سياسته النطاق.

لذلك كانت هناك مراتب متداخلة. يرتب DHCP نطاقات المزودين، ويختار NAPTR خدمات النقل، ويوزع SRV المثيلات بالأولوية والوزن، ويعطي الحل عناوين، ثم تستبعد قدرة العميل وسياساته ما لا يناسب. يخفي تعبير «الوكيل المعد» سلسلة من جهات القرار.

رسمت RFC 3263 أيضاً الحد الذي يجب أن يتوقف عنده الاختيار. بعد نجاح الاتصال بخادم في معاملة SIP، كان على إعادة الإرسال وطلب CANCEL وACK الخاص بالرد النهائي غير 2xx العودة إلى الخادم نفسه. يمكن أن يكون الاكتشاف مرناً قبل الاتصال، لكن حالة المعاملة تحتاج إلى ثبات بعده.

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

وضعت RFC 3396 لاحقاً ترتيباً دقيقاً لهذا الجمع، وسمحت بتقسيم الخيارات الطويلة بين نسخ وحقول محملة. لكنها سجلت أيضاً أن كثيراً من وكلاء DHCP المنشورين لم ينفذوا التجميع. يستطيع المرسل الالتزام بالقاعدة، ويظل المستقبل عاجزاً عن إعادة بناء القيمة.

كانت RFC 3361 تطلب هذا الأسلوب إذا تجاوزت قائمة الأسماء سعة الخيار الواحد. قبل أول استعلام DNS، كانت القائمة الطويلة تعتمد على ترتيب الأجزاء ودعم المستقبل. إثبات أن الخادم أرسل كل البايتات لا يثبت أن العميل أعاد بناء القائمة نفسها.

قدمت RFC 3319 تصميماً مختلفاً لـ DHCPv6 في العام التالي. خصصت خيارين منفصلين، واحداً للأسماء وآخر لعناوين IPv6. أوضحت أن DHCPv6 لا يعاني نقص رموز الخيارات، ولذلك استطاع الاستغناء عن بايت الترميز. صارت الخيارات أقصر وأسهل تحليلاً وأفضل محاذاة، وأمكن للعميل طلب الشكل الذي يريد. تحولت ندرة سجل IPv4 إلى تعقيد داخل الرسالة.

اعتمدت الأسماء ترميز الملصقات في RFC 1035، وطلبت دعم ضغط DNS، جزئياً لاستيعاب آليات الأسماء الدولية مستقبلاً. تحتها جاءت خدمة SRV من RFC 2782 ونظام NAPTR الذي صاغته RFC 3403. بقي الخيار صغيراً لأنه كان يشير إلى آلة أكبر مستقلة عنه.

وسعت الإحالة المرونة والثقة معاً. حذرت RFC 3361 من أن مهاجماً يعدل أو يضيف جواب DHCP يستطيع توجيه وكيل المستخدم إلى خادم SIP خبيث، واعتراض الطلبات أو منع الخدمة. ويمكنه حذف أسماء كانت ستحل إلى خوادم SIP تستخدم TLS. لا يحمل عقد DHCP المحادثة، لكنه يستطيع اختيار بوابة الإشارة الأولى وإخفاء بدائل أكثر أمناً قبل أن يراها العميل.

لا يزال سجل IANA الحالي لمعاملات BOOTP وDHCP يربط الرمز 120 بخيار خوادم SIP. يثبت الصف تنسيق الرقم والاسم، ولا يثبت أن شبكة تستخدمه اليوم أو أن عميلاً يطلبه أو يفهم الشكلين أو أن الوكيل يعمل.

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

يلزم حفظ إيصال لكل طبقة. في DHCP: الخادم والمرحل والبايتات والشكل والترتيب والمدة. للأسماء: NAPTR وSRV وA/AAAA وTTL والاختيار بعد التصفية. للعناوين: ترتيب المحاولات والمنفذ والنقل. ثم تسجل بصورة مستقلة استجابة الوكيل والمعاملة والتوجيه اللاحق ووصف الجلسة والوسائط.

يستخدم المقال بحثين لـ Lu Heng كعدستين معلنتين. يوضح “Minimum Initial Specification” قيمة خيار مشترك ضيق يترك تشغيل المزود وسياسة DNS والنشر للقرار المحلي. ويفصل “Reality Layers” بين الرمز المسجل والإعداد المسلم والخدمة المحلولة والتنفيذ العامل ونتيجة الاتصال. هذه قراءة تحريرية لا ادعاء عن مؤلف RFC 3361 أو مقصده.

صنع الخيار 120 موعداً، لا وصولاً. اختار بايت الترميز تفويض القرارات التالية إلى نظام أسماء حي أو تثبيت جزء منها في صف عناوين. سمّى العقد بداية الإشارة؛ أما استمرارها فاحتاج إلى دليل تالٍ.

المصادر