الخلاصة

  • اقترحت بنية HIP لعام 2006، التي كتبها Robert Moskowitz وPekka Nikander، هوية قائمة على مفتاح عام لتسمية نقطة الاتصال، مع إبقاء عنوان IP محدداً للموقع الذي تُوجَّه إليه الحزم.
  • يمكن لهذا الفصل أن يحافظ على ارتباط الاتصال بعد تغيير العنوان إذا استخدم المضيفان HIP. لكنه لا ينقل تسجيل عنوان ولا يحدّث تلقائياً قواعد كل تطبيق.

يغادر حاسوب محمول شبكة ويتصل بأخرى فيحصل على عنوان جديد. تغير المسار الذي تسلكه الحزم، لكن المضيف المقصود لم يتغير. كثيراً ما حمّلت البروتوكولات عنوان IP وظيفتين معاً: وصف الموقع الطوبولوجي وتسمية نقطة الاتصال. جعل Robert Moskowitz وPekka Nikander هذا التداخل مسألة معمارية صريحة في RFC 4423.

يضيف Host Identity Protocol فضاءً مستقلاً للهوية بين طبقة الإنترنت وطبقة النقل. في هذا التصميم، يكون Host Identifier مفتاحاً عاماً؛ أما Host Identity فهي الهوية المجردة التي يمثلها ذلك المفتاح. ويقدم Host Identity Tag، أو HIT، تمثيلاً مختصراً من 128 بت. لا يختفي عنوان IP: تظل الموجّهات بحاجة إليه لتحديد وجهة الحزمة. الذي يتغير هو أن العنوان لا يعود مضطراً وحده إلى تحديد المضيف المرتبط بعلاقة النقل.

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

تساعد سلسلة RFC على تحديد إسهام Moskowitz بدقة. نُشرت RFC 4423 في مايو 2006 بوصفها وثيقة معلوماتية. وتصف ملخصها نفسها بأنها لقطة لتفكير المؤلفين في خريف 2003، مع التنبيه إلى أن البنية ربما تطورت؛ وهي لا تحدد معياراً للإنترنت. ثم جاءت RFC 7401، التي حررها Moskowitz مع مؤلفين آخرين، لتحدد HIP الإصدار الثاني ضمن مسار Standards Track. وتشرح كيف تنشئ مضيفات موافقة حالة مشتركة في طبقة IP عبر تبادل تشفيري من أربع حزم. وفي 2021 حدّثت RFC 9063، التي شارك Moskowitz وMiika Komu في تأليفها، البنية وأحلت محل RFC 4423، مستفيدة من دروس تنفيذ RFC 7401 ومتناولة مرونة الخوارزميات التشفيرية والثقة عند الاستخدام الأول.

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

تقدم الملاحظة 68 لـHeng Lu زاوية اقتصادية مختلفة: قد يتحول العنوان إلى ذاكرة تجارية حين يبني العملاء والشركاء وفرق الأمن توقعاتهم حوله. هذا ليس وصفاً لـHIP ولا دليلاً على تبنيه في بيئة محددة. لكنه يساعد على تمييز شكلين من الاستمرارية. يفصل HIP هوية المضيف المستخدمة في تبادل البروتوكول عن محدد الموقع المستخدم للتوجيه؛ لكنه لا يعيد كتابة العلاقات الخارجية التي تراكمت حول العنوان.

لذلك يُفهم عمل Moskowitz على نحو أدق بوصفه رسماً لحد معماري: «قد يتغير مساري، لكن هوية نقطة الاتصال الموثقة حالة أخرى». وتكمن فائدة الحد في ضيق نطاقه. يمكن لـHIP أن يقلل الاعتماد على عنوان ثابت في التنقل وتعدد الاتصالات، لكنه لا يحل محل DNS أو التوجيه أو إدارة الموارد أو سياسات التطبيقات أو ترتيبات استمرارية الخدمة للعملاء.

المصادر