Summary

  • تقترح النسخة العاشرة من مسودة IETF استخدام بادئة NAT64 المعروفة لتمثيل عناوين IPv4 الخاصة والمشتركة. المسودة في مرحلة النداء الأخير لدى IESG حتى 23 نوفمبر 2026.
  • سيترجم CLAT غير الخاضع للإدارة هذه الحزم افتراضيًا، بينما يجب أن يتيح PLAT المدار تعطيل الترجمة. وتوصي المسودة بالإبقاء على الرفض القديم عند ترقية الأجهزة القائمة.
  • استخدام بادئة واحدة يختصر التعقيد، لكنه يضع قرار الوصول إلى الخدمة الداخلية على عاتق المسار الصحيح وقواعد الجدار الناري وقائمة السماح.

قد يكون الحارس الذي يمنع الوصول إلى خادم داخلي مجرد سطر في معيار عناوين. تلزم RFC 6052 مترجم NAT64 بإسقاط الحزم التي تجمع البادئة المعروفة 64:ff9b::/96 مع عنوان IPv4 غير عالمي. استفادت شبكات من هذا الحظر حتى عندما لم تكتب سياسة وصول خاصة بتلك الوجهة. الآن يناقش IETF رفع المنع العام. عندها لا يعود الصمت التشغيلي قاعدة أمنية.

الحظر القديم يعالج مشكلة حقيقية. تسمح RFC 1918 لمؤسسات مختلفة بإعادة استخدام الرقم الخاص نفسه. قد يكون 10.0.0.1 خادم رواتب في مؤسسة وجهاز تحكم في أخرى. إضافة بادئة IPv6 معروفة لا تكشف أيهما المقصود. في المقابل، يمنع الإسقاط الشامل جهازًا يعمل بـIPv6 وحده من بلوغ خدمة داخلية شرعية ما زالت تعمل بـIPv4. وتشمل المسودة أيضًا عناوين الفضاء المشترك في RFC 6598.

لماذا لا تكفي بادئتان؟

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

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

لهذا تقترح النسخة العاشرة تعديل صياغة RFC 6052 نفسها. يتحول «يجب عدم استخدام» البادئة مع العنوان غير العالمي إلى «يجوز استخدامها». يترجم CLAT غير المدار افتراضيًا، ويترجم PLAT المدار ما لم يضبط المسؤول خلاف ذلك، مع وسيلة إلزامية للإيقاف. هذه ليست مجرد راحة في ترقيم الشبكة؛ إنها نقل لسلطة الرفض من قاعدة عامة إلى مسؤول محلي يمكن مساءلته.

ترقية البرنامج ليست تصريح دخول

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

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

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

ما زالت النسخة العاشرة مسودة في النداء الأخير، بينما تظل RFC 6052 القاعدة المنشورة. لكنها تكشف الثمن الحقيقي للتبسيط: عندما لا يعود المعيار يرفض الجميع، يجب أن تعلن المؤسسة من تسمح له بالمرور ولماذا.

مسودة IETF · RFC 6052 · RFC 1918 · RFC 6598