الخلاصة

  • عرّف RFC 3319 خيارين في DHCPv6 للعثور على وكلاء SIP محليين للاتصالات الصادرة: قائمة مرتبة من أسماء النطاقات وأخرى من عناوين IPv6.
  • إذا تلقى العميل القائمتين، فعليه تفضيل الأسماء واتباع إجراءات تحديد موقع خادم SIP. تقدم الخيارات وجهات مرشحة، لا دليلاً على موثوقية الوكيل أو اكتمال المكالمة.

كان عقد الإيجار يجيب عن سؤال أضيق من سؤال المكالمة

يسهل وصف المشكلة التي تناولها RFC 3319 على نحو مضلل. فقد يعرف عميل SIP العنوان الوارد في URI، لكنه يظل بحاجة إلى وكيل خروج محلي. قد يجعل جدار ناري أو خطة اتصال محلية أو خدمات طوارئ هذا الوسيط ضرورياً. كان الإعداد اليدوي ممكناً، وأضاف RFC مساراً آخر: أن يعرّف DHCPv6 العميل بوكلاء مرشحين.

الحد الفاصل يتعلق بدور الخادم. يميز RFC 3261 بين وكلاء المستخدم والخوادم الوكيلة وخوادم إعادة التوجيه والمسجلات. ويقصد RFC 3319 بعبارة «خادم SIP» المضيف الذي يشغّل وكيلاً للطلبات الصادرة تحديداً. وجود ذلك المضيف في رد DHCP لا يثبت أن المستخدم سجّل، أو أن الوجهة مخوّلة، أو أن حوار SIP اكتمل، أو أن الوسائط تفاوضت، أو أن المكالمة نجحت.

ترميزان وترتيب واحد للأفضلية

يحمل الخيار 21، OPTION_SIP_SERVER_D، قائمة أسماء نطاقات؛ ويحمل الخيار 22، OPTION_SIP_SERVER_A، قائمة عناوين IPv6. ترتب القائمتان حسب الأفضلية، ويجب على التنفيذ المطابق دعم الخيارين. يستطيع العميل طلب أحدهما أو كليهما في Option Request Option ضمن DHCPv6. ويتوقف ما يعيده الخادم على إعداده والطلب الوارد. وحتى إذا طلب العميل الاثنين، يجوز للخادم إعادة أحدهما فقط، وينبغي تفضيل خيار أسماء النطاقات.

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

الاسم مدخل إلى تحديد موقع SIP لا بديل عنه

تدخل أسماء النطاقات في آلية تحديد موقع خوادم SIP التي يصفها RFC 3263. ويوصي RFC 3319 بأن تشير الأسماء إلى سجلات NAPTR مختلفة، لا إلى سجلات A مختلفة فحسب. وبذلك يستطيع خادم DHCP واحد الإشارة إلى وكلاء يديرهم مزودون متعددون. لكن الخيار لا يحل محل NAPTR أو SRV؛ فهو يقدم نقطة بداية، ثم تظل آليات تحديد الموقع وقواعد النقل واجبة التطبيق.

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

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

قد تصبح نقطة الإعداد مساراً لتحويل الثقة

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

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

لا يزال الخيار القديم ظاهراً في سجلات DHCPv6 الأحدث

تطورت المواصفة العامة لـ DHCPv6؛ إذ حل RFC 9915 محل RFC 8415. ومع ذلك، ما زال سجل IANA لرموز خيارات DHCPv6 يربط الرمزين 21 و22 بـ RFC 3319، كما يقدم RFC 9243 اللاحق مجموعات YANG لإعداد صيغتي خيار خادم SIP. تثبت هذه السجلات استمرار الإشارة الإدارية ونموذج البيانات، لا مدى استخدام المشغلين أو دعم العملاء أو نجاح التحول الاحتياطي أو اكتمال المكالمات.

كان إسهام RFC 3319 أضيق — وأكثر أهمية من الناحية التحليلية — من عبارة «DHCP يعثر على خادم هاتف». فقد وحّد طريقة مرتبة لاكتشاف وكيل خروج محلي: الأسماء أولاً، والعناوين لاحقاً عند تحقق شروط معينة. أما المكالمة نفسها فتبقى خارج نطاق الخيار. قد يحدد الاكتشاف وجهة الإشارات، لكنه لا يشهد على ما يحدث بعدها.

المصادر