الخلاصة

  • وافق IESG على النسخة 16 من مواصفة NAT64 ذات الحالة بصفتها Internet Standard، لكن النص المعتمد يفصل بوضوح بين سلوك التعيين وسياسة الترشيح الوارد.
  • ينبغي للمشغّل أن يثبت، كلًّا على حدة، كيف أُعيد استخدام الزوج الخارجي وأي مصادر سُمح لها باستعمال الحالة، مع تحديد البروتوكول والاتجاه والنسخة.

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

ثم يضيف تقرير التغيير استنتاجًا لم يُختبر: «لا يستطيع مصدر IPv4 غير معروف الوصول إلى الداخل». لم تُرسل حزمة من مصدر لم يتصل به المضيف سابقًا، ولم تُقرأ قاعدة الرفض الافتراضية، ولم يُحفظ ناتج القواعد المثبتة. انتقل الدليل من سؤال «أي زوج يمثل المضيف؟» إلى سؤال «من يملك حق العبور؟» من دون المرور بنقطة القرار الثانية.

في 4 سبتمبر 2026، وافق IESG على النسخة 16 من Stateful NAT64: Network Address and Protocol Translation from IPv6 Clients to IPv4 Servers بصفتها Internet Standard، وطلب من RFC Editor إدراجها ضمن STD 103. ويقول الإعلان إن NAT64 ذات الحالة مطبقة ومنشورة على نطاق واسع، وإن الوثيقة ستحل محل RFC 6146، وإن مسار العمل لم يشهد خلافًا كبيرًا.

لكن الموافقة ليست رقم RFC منشورًا. عند موعد إقفال هذا البحث، كانت صفحة Datatracker تعرض النسخة 16 في طابور RFC Editor، مع توقف النشر انتظارًا لمدخلات المؤلفين. ويسجل تاريخ الوثيقة خطوات الاعتماد، لا رقمًا نهائيًا لم يصدر بعد.

كما لا تعني الموافقة أن سلوك البروتوكول تغيّر فجأة. يصف إعلان IESG معالجة الخطأين 4756 و8416 بأنها تحريرية أو توضيحية ولا تؤثر في السلوك أو قابلية التشغيل البيني. ويؤكد الملحق A في النسخة 16 أن الخطأين لا يحملان أثرًا بروتوكوليًا. وتبقى RFC 6146 خط الأساس التاريخي حتى نشر الخلف. المسألة الحقيقية إذن ليست جدارًا ناريًا جديدًا، بل فصل قرارين كانا مختلفين أصلًا.

التعيين يختار التمثيل الخارجي

تحتفظ NAT64 ذات الحالة بربط بين عنوان نقل IPv6 وعنوان نقل IPv4. في TCP وUDP، يتكون عنوان النقل من عنوان IP ومنفذ. وعندما يتوقف التدفق وتنقضي المهلة، يمكن تحرير الربط الديناميكي وإعادة استخدام مورد IPv4 المحدود.

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

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

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

الترشيح يقرر من يستعمل الحالة

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

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

ولا يوجد ترتيب صالح لكل الحالات. توصي RFC 4787 بالترشيح المستقل عن نقطة النهاية حين تكون شفافية التطبيق هي الأولوية، وبالترشيح المعتمد على العنوان حين تكون الصرامة أهم. ويمكن أن يكون الخيار تحت سيطرة المسؤول. وتسمح RFC 5382 بأن يختلف ترشيح TCP عن ترشيح UDP. لهذا لا تكفي خانة عامة تقول إن الجهاز «متوافق».

أما ICMP فله بنية مختلفة. تستخدم RFC 5508 معرّف الاستعلام بدل منفذ TCP أو UDP. ويوضح تصحيح الخطأ 4756 أنه لا توجد، في مرحلة المعالجة المقصودة، قاعدة ترشيح معتمدة على العنوان تماثل حالة TCP/UDP. لا يعني ذلك غياب كل سياسة عن ICMP، بل يعني أن نسخ مصفوفة اختبار UDP إليه ينتج قياسًا زائفًا.

الربط الثابت يفضح ضعف الشهادة العامة

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

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

تقدم RFC 7269 خبرة تشغيلية تشمل التوافر العالي والأمان، وتضيف RFC 8683 إرشادات نشر NAT64/464XLAT. تضعان المترجم داخل نظام له توجيه وفشل وتشغيل. ولا تجعل أي منهما إعادة استخدام الزوج إثباتًا للترشيح.

إيصال قرار يحفظ المسارين

يقترح Daniel Kade إيصال قرار للتعيين والترشيح. يحدد رأسه المترجم وإصدار البرنامج والواجهة واتجاهها والبروتوكول. ثم يسجل في حقول منفصلة نمط التعيين، ونمط الترشيح، والإجراء الافتراضي، ومصدر الحالة الثابت أو الديناميكي أو PCP، ومهل الربط والجلسة، ونسخة السياسة، وصاحب الموافقة، وحدود الموارد، وانتهاء الاستثناء.

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

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

تطلب The Policy Mirror تحديد الموضع الذي تكتسب فيه القاعدة قوتها: التعيين عند تخصيص الزوج، والترشيح عند مسار القرار الوارد. وتتطلب Running-Code Primacy إثبات عمل الموضعين. أما Reality, Not Advocacy فتضع الحد: يشرح المعيار الخيارات، لكنه لا يثبت عيب شبكة بعينها لم تخضع للتدقيق.

المصادر