الخلاصة

  • يقترح مشروع فردي مؤرخ 21 يوليو جدول عناوين محلية مخصصة SLAT، ليرى كل عميل لخادم المسارات اسماً مختلفاً من IPv4 للقفزة التالية إلى العضو المادي نفسه.
  • يعيد الخادم كتابة NEXT_HOP وفق عمود العميل القديم المتلقي. ويتعين على وكيل ARP/ND في نقطة التبادل أن يحل ذلك الاسم إلى العضو الصحيح. صحة إعلان المسار وتسليم الحزمة تتوقفان على دفتر واحد محدث.
  • يفرض RFC 7947 عادة مرور NEXT_HOP بلا تغيير عبر خادم المسارات. يقترح المشروع استثناء صريحاً؛ أما التناظر الثنائي خارج الخادم فيحتاج الجدول المنشور أو طريقة ترجمة أخرى.

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

يسمح RFC 8950 بإعلان مسار IPv4 مع قفزة IPv6 عندما تتفاوض الأجهزة على القدرة اللازمة. التفاوض لا يضيف الميزة إلى الموجّه القديم. يميز مشروع الترجمة بين Legacy الذي يحتاج قفزة IPv4، وSupporting الذي يستعمل الشكلين، وUnnumbered الذي يستخدم IPv6 بلا قفزة IPv4. خادم المسارات يجمع هذه القراءات المختلفة لمسار واحد.

يبدأ دفتر نقطة التبادل بهوية مادية: عنوان MAC وعنوان IPv6 محلي للوصلة وآخر عالمي، ثلاثية فريدة لكل عضو. هذه هي Local Address Table. ثم تتفق النقطة مع كل عضو Legacy أو Supporting على بادئة IPv4 محلية تخصه، وتضيف للجدول عمود أسماء للآخرين ضمن تلك البادئة؛ فيصبح SLAT. في مثال المشروع يظهر الجار نفسه بعنوان 10.0.0.10 لعضو، و192.0.2.10 لعضو آخر. اختلاف الاسمين لا يخلق جاراً إضافياً.

على خادم المسارات أن يقرأ العمود المناسب في الاتجاهين. إذا تلقى مسار IPv4 مع NEXT_HOP من IPv4، يحوله إلى عنوان IPv6 للمرسل المسجل في SLAT. وعند تسليمه إلى مستقبل Legacy، يضع عنوان IPv4 المستعار للمرسل في عمود ذلك المستقبل. لا يعيد كتابة القفزة لمستقبل Unnumbered، وينصح المشروع بإبقائها أيضاً لمستقبل Supporting. عنوان لا يملكه أي عضو في الجدول يمنع نشر المسار. صار السجل بوابة لتوزيع ادعاءات الوصول، لا مجرد قائمة جرد.

نصف الآلية الآخر على شبكة التناظر. ترصد نقطة التبادل رسائل ARP وNeighbor Discovery، وتجيب عن طلبات كل عميل من عموده المناسب؛ ويهدف النموذج المقترح إلى منع تبادل رسائل اكتشاف الجيران مباشرة بين العملاء. إن أعلن الخادم اسماً محلياً وأجاب الوكيل بعنوان MAC لعضو آخر، بقي المسار مرئياً في BGP بينما تتجه الحزمة إلى الطرف الخطأ. الدليل الناقص لأي تشغيل محدد هو أثر واحد يربط الإعلان المستلم وسطر SLAT ورد ARP/ND وحل FIB ووصول الحزمة، ثم يعيد الفحص عند تغيير عنوان العضو.

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

يمكن الانتقال بالتدريج. يبدأ رصد ARP/ND، ثم يعمل خادم جديد قادر على قفزات IPv6 لمسارات IPv4 إلى جانب القديم. في البداية قد تنسخ أعمدة SLAT توزيع IPv4 العام القائم، ثم يعاد ترقيم الأعضاء إلى بادئات محلية عند تضاؤل المخزون العام، وربما إلى نطاقات خاصة. هذا يتيح الرجوع إلى الوضع السابق، لكنه يترك نسختين من حقيقة العناوين بحاجة إلى اختبار طوال الفترة المختلطة.

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

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

مشروع ترجمة القفزة التالية، النسخة 02 · RFC 7947 · RFC 8950 · RFC 9161