الخلاصة

  • يوصي RFC 9872 بالحصول على بادئة تركيب NAT64 من خيار PREF64 في إعلانات الموجّه الذي يعرّفه RFC 8781.
  • تحفظ الإشارة الصلة بين قيمة البادئة وعمرها وشبكة الوصول والمسار الصاعد المؤدي إلى المترجم.

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

يضع RFC 9872 هذه المعلومة عند الالتحاق بالشبكة. ينبغي للطرف الحصول أولاً على PREF64 من إعلان الموجّه، كما ينبغي للمشغّل الذي ينشر NAT64 أن يعلنها هناك. وتبقى طريقة DNS في RFC 7050 عندما يغيب الخيار أو يتعذر على الطرف معالجته.

الإعلان يحمل النطاق والزمن

يخصص RFC 8781 نوع خيار اكتشاف الجيران 38 لـ PREF64. يحمل الخيار بتات البادئة ورمز طولها وعمراً بوحدات من ثماني ثوان. العمر صفر يسحب البادئة. ولا يُنصح بأن يكون عمرها أقصر من عمر الموجّه الافتراضي، كي لا تنتهي البادئة بينما يبدو المسار صالحاً.

يعامل الجهاز PREF64 كمعلومة خاصة بالشبكة التي استقبلها منها، ويربطها بمجال التهيئة PvD عند دعمه. يمكنه اختيار أي بادئة ذات عمر غير صفري، لكن لا ينبغي خلط مصادر اكتشاف مختلفة. وفي تعدد الاتصال يجب إرسال العنوان المركب إلى المسار الصاعد الذي يخدم مترجمه تلك البادئة.

قد يرى DNS شبكة أخرى

يستخرج RFC 7050 البادئة من إجابات AAAA يركبها محلل DNS64 لاسم IPv4 خاص. لكن DNS المشفر أو VPN أو الضبط اليدوي قد ينقل المحلل خارج شبكة الوصول، فلا يعرف مترجمها المحلي. كما تبقى نتائج DNS وفق TTL، بينما يستطيع إعلان الموجّه تغيير البادئة أو سحبها بعمر صفر مباشرة على الوصلة.

التوصية الأساسية في RFC 9872، وصيغة الخيار في RFC 8781، وطريقة DNS في RFC 7050. يعرّف RFC 6052 صيغة العنوان وRFC 7915 الترجمة. لا تثبت هذه الوثائق الانتشار الحالي أو سلامة المترجم.

ولا يعني اكتشاف PREF64 مصادقة إعلان الموجّه، أو إثبات إمكان الوصول إلى المترجم، أو إثبات النشر أو الأداء، كما لا يجعل Well-Known Prefix في RFC 6052 صالحاً لكل شبكة NAT64. تحتاج كل واحدة من هذه الادعاءات الخمسة إلى دليل مستقل.