الخلاصة

  • تنص مسودة مجموعة v6ops، النسخة 02 المؤرخة في 28 أكتوبر، على استخدام عنوان IPv4 عام متاح لمصدر رد ICMPv4 عندما يكون مصدر خطأ ICMPv6 الخارجي غير قابل للترجمة. إذا لم يتوفر عنوان عام، يجب استخدام 192.0.0.8. لم تضع النسخة 01 أولوية العنوان العام بهذه الصراحة.
  • يوصى بإضافة كائن Node Identification يحمل مصدر IPv6 الأصلي. في رسالة Packet Too Big لا يمكن إضافة هذا الامتداد إلا بعد الترجمة إلى ICMPv4؛ ويمكن حذفه مع إبقاء توصية إرسال الخطأ. يسجل سجل IANA 192.0.0.8/32 عنوانًا وهميًا لا وجهة عالمية الوصول.

المصدر في ترويسة الرد ليس شاهدًا كافيًا

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

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

يحدد سجل IANA الرسمي معنى الرقم بدقة. 192.0.0.8/32 عنوان IPv4 وهمي خصصه RFC 7600. تصلح قيمته بوصفه مصدرًا وفق خانة السجل، بينما لا يصفه السجل وجهة صالحة أو قابلة للتوجيه أو متاحة عالميًا كوجهة. إذا ظهر الرقم في أداة تتبع المسار، فهو علامة على مسار احتياطي في الترجمة. ليس عقدة فعلية يمكن تحديد موقعها من هذا الرقم. من يرسمه جهازًا في الشبكة سيبحث عن آلة لا يشهد السجل بوجودها.

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

تظل أداة التشخيص طرفًا في القصة. تقول المسودة إن الاستفادة الكاملة من الإضافة تحتاج برنامجًا مثل traceroute قادرًا على تفسير Node Identification وعرضه. يمكن أن يكون العنوان الأصلي داخل الرزمة بينما تكتفي الشاشة بإظهار 192.0.0.8. القرار الذي اتخذه المترجم بشأن البيانات، والقرار الذي اتخذه البرنامج بشأن إظهارها، حدان مختلفان للمساءلة.

خطأ حجم الرزمة يفضح المقايضة

في Packet Too Big يحتاج المرسل إلى معرفة أن حجم رزمته لا يصلح للمسار. لا يمكن إدراج امتداد ICMP المطلوب داخل رسالة ICMPv6 من هذا النوع قبل الترجمة. لذلك يجب تكوين رسالة ICMPv4 أولًا ثم إضافة كائن الهوية. تسمح المسودة للمنفذ بترك الكائن في هذه الحالة، لكنها توصي بترجمة خطأ الحجم باستخدام المصدر الوهمي وألا تُسقط الرسالة. حفظ إشارة الحجم أولى من إسكاتها لمجرد أن بطاقة هوية المصدر لا يمكن تجهيزها في التوقيت المثالي.

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

هناك شرط يسبق اختيار المصدر: على المترجم فصل أخطاء حركة IPv4 التي ترجمها عن أخطاء IPv6 الأصلية. عنوان IPv6 مخصص أو بادئة /64 مخصصة تجعل الفصل سهلًا. إذا استُخدم العنوان نفسه للنوعين، قد يلزم الاحتفاظ بحالة أو فحص ترويسة الرزمة التي أثارت الخطأ. تخصيص IANA لرقم احتياطي لا يتخذ هذا القرار بدلًا عن الجهاز.

يعرض Datatracker المشروع بوصفه مسودة مجموعة عمل رُفعت إلى IESG وما زالت في تقييم المدير المختص. إن أُقرت، ستحدّث RFC 6791 وRFC 7915؛ لا تطلب تخصيص IANA جديدًا ولا تعرض قياسًا لشبكة منشورة. تناولت مقالات Daniel Kade السابقة سياسة كشف هوية العقدة ومعالجة AFI مجهول في الامتداد العام. هنا يجري الاختبار عند مترجم لا يملك عنوان IPv4 عامًا للخطأ نفسه.

المصادر