الخلاصة

  • يمثّل LSI هوية مضيف داخل سياق الجهاز الذي خصّصه؛ ولا تمنح هيئة IPv4 للبتات معنىً صالحاً على جهاز آخر.
  • يجب فصل إيصال التخصيص المحلي وربط HIT وحلّ الموقع واختيار المسار وارتباط HIP والبيانات المحمية ونتيجة التطبيق وسياق التدقيق.

لم يفشل التنسيق، بل تغيّرت جهة التفسير

يستعلم تطبيق قديم عن اسم، ويتلقى قيمة من 32 بت، ثم يمررها إلى connect(). يعرف النظام المحلي أنها LSI، فيحوّلها إلى Host Identity ويتابع سلسلة HIP. يرى التطبيق نجاحاً عادياً ولا يحتاج إلى معرفة ما حدث أسفله.

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

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

LSI مفتاح ترجمة لا موقع شبكة

يعرّف RFC 5338 معرّف النطاق المحلي بأنه كمية من 32 أو 128 بت تمثل محلياً Host Identity عند واجهة IPv4 أو IPv6. ويشرح RFC 9063 أن LSI ذي 32 بت يُترجم إلى HIT في طبقة HIP أو معالج المقابس، ولا يُرسل على السلك كمحدّد موقع.

لهذا يحتاج تفسير الرقم إلى اسم الجهاز المخصّص، وجيل جدول الربط، والـ HIT المقابل، وزمن الإنشاء والانتهاء. من دون هذه العناصر يشبه LSI رقم صف بلا اسم قاعدة البيانات. لا توجد سلطة عالمية تجبر جهازاً ثانياً على إعطائه المعنى نفسه.

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

وكيل DNS يختار تمثيلاً ولا يصدر حكم اتصال

يقترح RFC 5338 وكيلاً محلياً واعياً بـ HIP داخل مسار حلّ DNS. عندما تتوفر معلومات هوية، يمكنه إرجاع LSI أو HIT بدلاً من عنوان معتاد، وحفظ العلاقة محلياً، ثم تحويل القيمة عند استدعاء النظام.

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

وقد تعيد الدالة قائمةً تضم معرفات HIP وعناوين عادية. ترتيب HIP أولاً يعبر عن تفضيل، لكن بعض التطبيقات تبدأ الاتصالات بالتوازي. قد يفوز المسار العادي. لذلك لا تثبت قائمة getaddrinfo() أي قناة استخدمت فعلاً.

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

الإحالة تنقل الرمز ولا تنقل صاحب السلطة

في سيناريو من ثلاثة أطراف، يعطي B إلى C «عنوان» A الذي يستعمله. إذا كان ذلك العنوان LSI في B، فإن C لا يتلقى اسم A العالمي. إنه يتلقى مفتاحاً في جدول B، بينما بقي الجدول وصاحب القرار على الجهاز السابق.

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

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

يشبه RFC 9063 المسألة بترجمة العناوين على المضيف. التطبيقات التي تضع عنواناً محلياً داخل بروتوكول تطبيقي كانت هشة أمام NAT أصلاً. لا يصنع HIP الخلل، بل يكشف أن خانة واحدة كانت تؤدي أدوار الموقع والهوية والمؤشر المحلي معاً.

الذاكرة القديمة قد تقابل هوية جديدة

قد تحتفظ التطبيقات القديمة بنتيجة DNS أطول من عمر الربط الذي تريده طبقة HIP. يشير RFC 5338 إلى صعوبة جمع قيود LSI. إن أُعيد استعمال الرقم بينما تحتفظ به عملية قديمة، صار نفس الرمز باباً إلى Host Identity أخرى.

ويظهر الخطر نفسه في السجلات. إذا كان LSI رقم 9 مربوطاً اليوم بالهوية Y، فلا يجوز إسناد حدث الأمس ذي الرقم 9 إلى Y تلقائياً. ربط سجل قديم بجدول حالي لا يستعيد التاريخ؛ بل يكتب موضوعاً جديداً داخل الحدث.

يوصي RFC 5338 بتسجيل HIT وLSI وعناوين IP المقابلة ومعلومات FQDN كي يستطيع المشغّلون الربط بين السجلات. ويحتاج التدقيق أيضاً إلى الجهاز، وجيل الإقلاع أو الخريطة، والوقت، والعملية، والمقبس، وقرار السياسة.

هذا السجل الغني يثبت ما فهمته طبقة التوافق. ولا يثبت وحده اكتمال ارتباط HIP أو وصول حزم محمية أو نجاح العمل. يجب وصل هذه الإيصالات زمنياً من دون دمج سلطاتها.

HIT الصريح يقوّي الاسم ولا يضمن الخدمة

قد تعني connect(ip) ببساطة: اتصل بالنظام المتاح حالياً عند هذا العنوان. يمكن للسياسة المحلية أن تحاول HIP، لكن الطلب الأصلي لم يسمِّ بالضرورة Host Identity محددة بقوة، ولا يرى التطبيق الربط بين العنوان والهوية.

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

وهذا يفصل موضوع المقال عن حدود HIP الأخرى المنشورة: ليس السؤال هل مرر RVS الرسالة، أو بقي سجل DNS حديثاً، أو تحقق locator، أو عبر ESP جداراً نارياً. السؤال هو من يملك حق تفسير الرمز الذي ظهر لتطبيق قديم.

الاستماع العام يخفي اختيار هوية الخادم

يربط خادم قديم عادةً عنواناً عاماً، بينما قد يمتلك المضيف هويات متعددة. إن لم يحدد التطبيق HIT بعينه، تختار السياسة المحلية. يعرض RFC 5338 حالة UDP يمكن فيها أن يصل الطلب تحت توقع ثم يختار sendto() هوية خروج مختلفة، فيرفض العميل الرد.

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

المصادر وحدود الدليل

تثبت المصادر مواصفات وبنية معلنة وتقريراً تاريخياً للتجارب. ولا تثبت منتجاً حالياً أو انتشاراً أو حادثة أو مؤسسة متأثرة أو معدل فشل مقاساً.