الخلاصة

  • أتاح RFC 3963 لموجّه متنقل أن ينقل نقطة اتصال بادئة واحدة أو عدة بادئات لشبكة متنقلة، بينما ظلت العقد الداخلية غير معنية بآلية الحركة؛ وكان الإقرار الإيجابي ذو الراية R يثبت معالجة الارتباط وإعداد التحويل، لا إمكان الوصول إلى كل عقدة.
  • استند النمط الصريح والنمط الضمني والتوجيه الديناميكي إلى مصادر مختلفة لمعرفة البادئات. لذلك يجب أن تبقى صلاحية البادئة والطريق والنفق واختبار العقدة والجلسة ونتيجة الخدمة إيصالات منفصلة.

يمكن لشبكة داخل قطار أو مركبة أن تحتفظ بعناوينها وبوابتها بينما يتغير الاتصال الخارجي. لا تحتاج الكاميرات والحساسات والمحطات إلى تنفيذ بروتوكول حركة خاص بها؛ فالموجّه عند الحافة يفعل ذلك عنها. هذه هي البنية التي ثبّتها RFC 3963 في يناير 2005 باسم NEMO Basic Support.

حين يغادر الموجّه المتنقل وصلة المنزل، يحصل على Care-of Address ويرسل Binding Update إلى Home Agent. تعني الراية R أنه يطلب معاملة الموجّه المتنقل. يربط الوكيل Home Address الثابت بالعنوان المؤقت الجديد، ثم ينشئ التحويل للبادئات المصرح بها. ويحمل نفق ثنائي الاتجاه الحركة بين الوكيل والموقع الحالي للموجّه.

كان الإقرار محدد النطاق. الحالة صفر مع R في Binding Acknowledgement تسمح للموجّه بأن يفترض أن الوكيل عالج التحديث وثبّت تحويل البادئات. لا تقول الرسالة إن كل حساس يعمل، ولا إن جلسة بقيت متصلة، ولا إن المسار أمثل، ولا إن تطبيقاً منح الصلاحية. إنها إيصال من مستوى التحكم لعناوين وبادئات ونفق.

الراية تطلب وظيفة ولا تنشئ هوية

يرفع الموجّه R في الطلب، ويرد الوكيل بها عند القبول. تحدد الراية معنى المعالجة، لكنها لا توثق المرسل بمفردها. ألزم RFC 3963 باستخدام IPsec لمصادقة الإشارات بين الطرفين. علاقة الأمان هي أساس الثقة بالمصدر، أما R فتصف المطلوب داخل تلك العلاقة.

لهذا لا يكفي سجل يقول إن الارتباط نجح. ينبغي حفظ Home Address وCare-of Address ورقم التسلسل والمدة والرايتين H وR وخيارات البادئات الدقيقة وعلاقة IPsec وحالة الإقرار وطرفي النفق والطرق التي أضيفت أو حذفت. حتى هذا السجل الكامل لا يراقب الأجهزة الواقعة خلف الموجّه.

يوضح التاريخ التقني الحد. قدّم RFC 3775 أساس Mobile IPv6 للمضيف في ذلك الوقت، ثم راجعه RFC 6275. وضع RFC 3963 شبكة خلف نقطة النهاية المتنقلة. اتسع نطاق العناوين التي يمثلها الارتباط، ولم تتسع معه قدرة المراقبة.

ثلاثة مسارات لمعرفة البادئة

في النمط الصريح، يحمل Binding Update خياراً واحداً أو عدة خيارات Mobile Network Prefix. يستطيع Home Agent مقارنتها بجدول Prefix Table يبين ما يحق لذلك الموجّه استخدامه. وكانت المعالجة كلية: إذا تعذر إنشاء التحويل لكل البادئات المذكورة، فلا يجوز تحويل أي منها، ويُرفض التحديث بالحالة 141. أما البادئة غير المصرح بها فتؤدي إلى 142.

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

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

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

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

الشفافية جمعت الراحة والفشل في نقطة واحدة

في الدعم الأساسي تمر حركة Mobile Network Nodes إلى Correspondent Nodes عبر Home Agent. يغلّف الوكيل الحزم الهابطة إلى Care-of Address. ويتحقق الموجّه من أن المصدر الخارجي هو وكيله، ما لم يوفر IPsec في نمط النفق الحماية نفسها، ثم يتأكد من أن الوجهة الداخلية ضمن Mobile Network Prefix قبل تسليمها.

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

لم يعرّف الدعم الأساسي تحسين المسار لحركة البادئات المتنقلة. ويمكن لموجّهات متداخلة أن تكوّن شجرة وأن تضاعف الأنفاق. رتبت RFC 4885 وRFC 4886 وRFC 4887 المصطلحات والأهداف والمشكلات. وحللت RFC 4888 صعوبات تحسين المسار، بينما رسمت RFC 4889 فضاء الحلول. وجود التحويل لا يثبت أن الطريق أمثل.

أضافت وثائق لاحقة آليات مجاورة. تناولت RFC 5488 وRFC 6276 تفويض بادئات DHCPv6 للشبكات المتنقلة، ووصفت RFC 6089 flow bindings. تضيف هذه الآليات قرارات وأدلة، لكنها لا تحول إقرار الارتباط الأول إلى فحص لكل عقدة.

يمكن تثبيت السجل التاريخي من صفحة RFC Editor وبحث التصويبات وDatatracker وسجل IANA Mobility Parameters. تثبت هذه المصادر حالة الوثيقة والتصويبات المبلغ عنها والقيم المنسقة، ولا تثبت تبني شبكة بعينها أو صحة تطبيقها.

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

حرّك RFC 3963 شبكة كاملة لأنه قلل عدد الجهات التي يلزم أن تتحرك. أما درسه الأعمق فهو ألا نزيد عدد النتائج التي نسمح لإشارة واحدة بأن تشهد عليها.

المصادر