الخلاصة

  • يعرّف RFC 5149 خيار تنقل لاختيار الخدمة داخل Binding Update في Mobile IPv6.
  • يحدد الخيار الخدمة المطلوبة، لكنه لا يمنح حق استخدامها.
  • لا يجوز أن يظهر أكثر من خيار واحد؛ ويأتي بعد MN-NAI إن وُجد وقبل خيارات التفويض أو المصادقة.
  • يحمل النوع 20 معرّفاً غير فارغ بطول 1 إلى 255 ثُمانية، بترميز UTF-8 وتطبيع NFKC.
  • لا يلزم أن يكون المعرّف فريداً عالمياً، بل بين الوكلاء المنزليين المسموح للعقدة بالتسجيل لديهم.
  • يصادق الوكيل المنزلي على العقدة ثم يتحقق بصورة مستقلة من تفويض الخدمة المحددة.
  • يُرفض الطلب غير المفوض بالحالة 151، SERVICE_AUTHORIZATION_FAILED.
  • يتطلب تغيير الخدمة إعادة التفويض، وقد يؤدي الفشل إلى حذف الربط السابق.
  • قد يؤثر الاختيار في العنوان والبادئة والتوجيه والجدار الناري والأمن والسياسة وQoS من دون إثبات تنفيذها.
  • ينبغي للعقدة المراسلة التي لا تشترك في معرفة كتالوج الخدمة أن تتجاهل الخيار بصمت.
  • يمكن لـ ESP حماية سرية المعرّف، لكنه لا يثبت الاستحقاق أو التسليم.
  • تحتاج نتيجة التسجيل، وتثبيت السياسة، ومسار البيانات، والفوترة، وتجربة المستخدم إلى أدلة منفصلة.

حماية الرسالة لا تصحح مصدر القرار

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

عندما تكون المعلومة حساسة، يوصي RFC باستخدام ESP في نمط النقل مع تشفير غير صفري على Binding Updates وBinding Acknowledgements. يجيب ذلك عن سؤال محدد: هل يستطيع مراقب الطريق قراءة الاختيار؟ لا يجيب عن أسئلة التفويض، أو صحة تحويل الاسم إلى سياسة، أو نجاح المسار.

والعكس صحيح أيضاً. قد يقرر الوكيل المنزلي أن العقدة مخولة، من دون أن يثبت هذا القرار أن الاختيار ظل سرياً أثناء النقل. يجب أن تظهر السرية، والسلامة، وهوية العقدة، واستحقاق الخدمة، ونتيجة التسليم كحقول أدلة مستقلة، لا كحالة أمنية خضراء واحدة.

معرّف محدود النطاق لا جواز مرور

يحتاج الاشتراك الواحد أحياناً إلى التمييز بين إنترنت عادي، ووصول مؤسسي، ونطاقات خاصة منفصلة، أو معالجة خاصة بالسياسة وجودة الخدمة. يضيف الخيار اسماً متغير الطول إلى تسجيل الربط كي يعرف الوكيل المنزلي أي سياق يفحص.

العقد السلكي دقيق: النوع 20، وقيمة من 1 إلى 255 ثُمانية، بترميز UTF-8 وبعد تطبيع NFKC. يسمح بخيار واحد فقط في كل Binding Update. إذا حضر MN-NAI جاء المعرّف بعده، ثم جاءت خيارات التفويض أو المصادقة. هذه الصيغة تمنع الغموض البنيوي، لكنها لا تحول النص إلى اعتماد.

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

الرفض قد يزيل المسار القائم

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

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

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

قبول الربط يسبق التسليم بعدة طبقات

يمكن للاختيار المقبول أن يؤثر في تخصيص العنوان أو البادئة، والتوجيه الصادر، وإعدادات الجدار الناري، وسياسة الأمن، والسياسات العامة، وQoS. لكن Binding Acknowledgement لا يقرأ حالة كل نظام لاحق؛ إنه يقرر نتيجة التسجيل لدى الوكيل المنزلي.

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

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

حدود المعرفة تمنع تعميم الاسم

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

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

وفي غياب المعرّف، يعامل الوكيل الطلب كسياق إنترنت عادي. يوصي RFC بقوة بالسماح بهذا الافتراض لتقليل الإعداد الخاص بالمشغل، لكنه لا يضمن تفويضه لكل مشترك. الافتراض يحدد سياق الطلب ولا يضمن الاتصال.

تثبت أرقام IANA — النوع 20 والحالة 151 — تنسيقاً وثائقياً مستقراً، لا وجود التنفيذ في جهاز معين. وقد حل RFC 6275 لاحقاً محل إطار RFC 3775 الأصلي. سلسلة المراجع توضح النسب التقني، ولا تقدم جرداً حياً للتشغيل أو التوافق.

المصادر

  1. RFC 5149، HTML
  2. RFC 5149، نص
  3. سجل RFC Editor
  4. سجل IETF Datatracker
  5. تاريخ RFC 5149
  6. مراجع RFC 5149
  7. تصحيحات RFC 5149
  8. RFC 3775
  9. RFC 6275
  10. RFC 4877
  11. RFC 4283
  12. RFC 6089
  13. RFC 5778
  14. RFC 5779
  15. RFC 6097
  16. RFC 7222
  17. Minimum Initial Specification
  18. On Reality Layers
  19. Running-Code Primacy