الخلاصة

  • ينجح LISP عندما تجتمع حقائق منفصلة: يسجل ETR مخوّلاً علاقة EID بـRLOC، ويحلها Mapping System، ويحتفظ ITR بنسخة لم تنته صلاحيتها، ويختار RLOC وفق Priority وWeight، ثم توصله الشبكة الأساسية ويكمل ETR التسليم الداخلي.
  • كان David Meyer واحداً من عدة مؤلفين للمواصفة الأصلية ولـRFC 9300 الحالي. أهميته هنا ليست ادعاء اختراع منفرد، بل تتبع انتقال فكرة فصل أنيقة إلى نظام تشغيلي تحكمه الصلاحيات والوقت وحدود الثقة.

عندما يظل الاسم صحيحاً ويضيع المكان

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

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

ظهر الدافع ضمن سؤال أوسع عن قابلية توسع التوجيه. يوثق RFC 4984 ورشة IAB لعام 2006، حيث رأى المشاركون أن تحميل عنوان IP وظيفتي المعرّف والمحدد الطوبولوجي يساهم في ضغط جداول التوجيه. اعتبروا أن نوعاً من الفصل ضروري، لكنهم لم يصمموا تنفيذه هناك، كما أن التقرير يعرض آراء المشاركين لا موقفاً رسمياً نهائياً لـIAB.

يقدم RFC 9299 بنية LISP. يبدو EID وRLOC من حيث الصياغة مثل عناوين IPv4 أو IPv6، لكن دلالتهما مختلفة. يعرّف EID العقدة من دون حمل موضعها بين النطاقات، بينما يعرّف RLOC نقطة اتصال في underlay. يحفظ Mapping System العلاقة، وتغلف موجهات LISP الحزمة الداخلية نحو الموضع المناسب.

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

ما الذي لا يثبته EID

يشترط RFC 9300 أن يكون EID المستخدم على الإنترنت العام فريداً مثل أي عنوان عام، وأن يخصص من EID-Prefix مرتبط بالموقع. لا يعني ذلك ملكية قانونية أو هوية بشرية أو قابلية حمل عالمية بين المزودين. ولا يثبت أن التسجيل موجود أو أن المسار يعمل الآن.

تبدأ سلسلة التسليم عندما يربط ETR بين EID-Prefix وRLOC واحد أو أكثر. يرسل Map-Register إلى Map-Server، وعلى الخادم معرفة السوابق التي يحق لذلك ETR تسجيلها. يحتاج الطرفان أيضاً إلى سر مشترك معد مسبقاً لاشتقاق مفاتيح التوثيق. يحذر RFC 9301 من أن قبول السابقة من دون هذا الفحص يتيح اختطافاً بسيطاً.

عند الإرسال، يبحث ITR عن EID الوجهة بأطول تطابق للسابقة داخل Map-Cache المحلي. يعيد النجاح Locator-Set؛ أما الفشل فيطلق Map-Request عبر Map-Resolver. خلال الانتظار يستطيع التطبيق إسقاط الحزم أو تخزينها مؤقتاً. لذلك لا توصف تجربة الفشل بكلمة «يدعم LISP»، بل بسياسة محلية محددة.

للجواب TTL. تفرض القيمة صفر الحذف الفوري، فيما تسمح قيمة خاصة للمستلم باختيار المدة. كما يحتفظ cache بحالة الوصول. قد يكون Map-Server قد قبل RLOC جديداً بينما تستخدم أجهزة ITR البعيدة النسخة السابقة حتى الآن.

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

بعد ذلك يجب أن توصل underlay الحزمة الخارجية إلى RLOC، وعلى ETR فك التغليف وإيصال الحزمة الداخلية داخل موقع الوجهة. خريطة صحيحة لا تثبت وصول underlay، ووصول الغلاف لا يثبت آخر جزء داخلي.

نسخ لا تنتهي في اللحظة نفسها

يجدد ETR التسجيل دورياً، ويمكن لـMap-Server حذفه عند غياب Map-Register صالح. أما Negative Map-Reply بلا محددات موقع فيمكن أن يعني عدم التسجيل أو رفضاً بالسياسة أو فشل التوثيق. وقد يأمر بالتوجيه الأصلي أو بإعادة الطلب أو بعدم التصرف أو بالإسقاط. الحفاظ على سبب الغياب جزء من السلامة، لا تفصيل في التسجيل.

حين تتغير العلاقة، يستطيع Solicit-Map-Request دفع أجهزة ITR التي خزنتها فعلاً إلى طلب نسخة جديدة. تخضع الرسائل لحدود معدل، ولا ينبغي لمن لا يملك cache ذا صلة أن يطلب تحديثاً بلا حاجة. التعديل المركزي لا يمحو كل نسخة عالمية فوراً؛ بل يبدأ تقارباً لدى القراء النشطين.

يوضح RFC 9302 صعوبة التقارب في البيئات المغلقة الموثوقة من خلال Map-Version اختياري من اثنتي عشرة بتة. يزداد عند إضافة RLOC أو حذفه، أو تغيير Priority أو Weight، أو تغير الوصول المحلي. وبما أن حيز الأرقام دائري، قد يبدو رقم قديم جداً جديداً بعد الالتفاف؛ لذا ينبغي انتظار TTL السابق على الأقل أو إثبات انتقال المرور النشط.

لكن RFC 9300 يمنع على الإنترنت العام استخدام Map-Versioning أو gleaning أو Locator-Status-Bits أو Echo-Nonce اختصاراً لتحديث الخريطة أو إثبات وصول RLOC. يجب الاعتماد على وسائل control plane. صلاحية الإشارة مرتبطة بنطاق الثقة الذي صممت له.

الحماية تتعلق بالعلاقة

يفترض تحليل RFC 9301 أن Mapping System آمن وموثوق، وأن بينه وبين ETR علاقة ثقة معدة مسبقاً، وأن النظام يعرف أي EID يحق لكل ETR إعلانه. يترك إنشاء المفاتيح والحقوق خارج نطاقه. لا يستطيع بروتوكول أن يمنح الشرعية التي يجب على مؤسسة ما تحديدها أولاً.

يفرض السياق العام تطبيق LISP-SEC في RFC 9303. يوفر توثيق المصدر وسلامة بيانات البحث ومنع الإعادة والتحقق من التفويض في ادعاء EID-Prefix. فالخريطة المزورة قد تحول المرور أو تسمح بالمطالبة بسابقة أوسع. ومع ذلك، يفترض LISP-SEC أن Mapping System يوصل الطلب إلى ETR المقصود وأن Map-Server يستطيع فحص حق التسجيل.

لذلك ليس EID اعتماداً تشفيرياً. وثباته قد يخلق خطراً آخر: ربط EID طويل العمر بتتابع RLOCs يمكن أن يكشف حركة طوبولوجية. تقليل إعادة الترقيم لا يساوي تقليل التتبع.

موضع Meyer في سجل جماعي

يحمل RFC 9300 أسماء Dino Farinacci وVince Fuller وDave Meyer وDarrel Lewis والمحرر Albert Cabellos. وشارك Meyer أيضاً في RFC 6830 السابق. لا تمنحه هذه الاستمرارية سيادة على LISP؛ فهي تجعله شاهداً مناسباً على نضوج المواصفة من فصل مفاهيمي إلى قواعد للمهلة والتحديث والأمن.

تذكر صفحة ONUG التاريخية عمله في Cisco وBrocade، ومشاركته في IAB ولجنة برنامج NANOG، وصلته بمشروع RouteViews في جامعة أوريغون. هذه معلومات مؤرخة وليست إثباتاً لوظيفته الحالية. لكنها تضعه قرب سؤال متكرر: كيف يصبح وضع control plane قابلاً للرؤية والفحص بدل أن يبقى وعداً تصميمياً؟

توجد مادة سابقة عن Meyer تركز على RouteViews وRPSL وOpenDaylight والانفتاح العام لحالة التوجيه. أما هذه المادة فتبحث في آلية مختلفة: من يحق له كتابة علاقة EID-RLOC، وكم تبقى النسخة صالحة، وما الذي ينبغي إثباته بعد نجاح الحل.

يقدم RFC 7215، وهو دليل نشر Experimental، قائمة تحقق تكسر الاختصار. فهي تشمل المنصة والإعداد وMTU وتخصيص السابقة ووصول RLOC والتسجيل ومفتاحه وcache للوسطاء وسياسات BGP والرؤية الخارجية والمرور الفعلي. تعكس بعض الأدوات مرحلة انتقال 2014، لكن منطق الإثبات ثابت: وجود المواصفة لا يثبت الإعداد، والإعداد لا يثبت التسجيل، والتسجيل لا يثبت التسليم.

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

المصادر