الخلاصة

  • وضعت RFC 3338 مترجماً بين واجهة المقابس ومكدسي IPv4 وIPv6 في المضيف. فإذا لم يكن للطرف سوى سجل AAAA، أمكنها اصطناع إجابة A من مخزون IPv4 محلي وربطها بعنوان IPv6 الفعلي، من دون ترجمة رؤوس حزم IP.
  • كانت القيمة التي يراها التطبيق حالة داخل المترجم، لها نطاق وجيل. وقد يهدم هذا المظهر نفاد المخزون، أو طرد الخرائط وإعادة استخدامها، أو الفروق الدلالية بين الواجهات، أو اختلاف دعم المضيف لـIPv6 عن دعم الخدمة على منفذ بعينه.

أعاد محلل الأسماء شكلاً يفهمه التطبيق القديم

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

يعترض محلل الأسماء في BIA استدعاء التطبيق ويبحث عن سجلات A وAAAA معاً. فإذا وجد AAAA فقط، يختار معين العناوين قيمة من مخزون IPv4 الداخلي، ويحفظ زوج IPv4–IPv6، ويبني إجابة A للتطبيق. يتلقى البرنامج الشكل المألوف المكوّن من أربعة بايتات فيواصل العمل من دون تعديل.

وعندما يمرر البرنامج تلك القيمة لاحقاً إلى دالة مقبس IPv4، يعترض معين الدوال الاستدعاء، ويستخرج عنوان IPv6 من الخريطة، ويستدعي واجهة IPv6 المقابلة. تسير الحزم عبر مكدس IPv6 الأصلي. وهذه نقطة الفصل عن Bump-in-the-Stack في RFC 2767: لا يحتاج BIA إلى إعادة كتابة رؤوس IPv4 وIPv6 في طبقة الشبكة.

ما بدا عنواناً كان يشير إلى صف في جدول

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

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

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

قد يصبح مقبض الأمس طرفاً آخر اليوم

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

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

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

ترجمة الدالة لم تجعل الواجهتين متطابقتين في المعنى

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

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

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

وجود AAAA للمضيف لا يثبت أن المنفذ يتحدث IPv6

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

بحثت RFC 3338 تجربة كل عنوان معاد. ففي TCP قد يراقب BIA فشل connect وينتقل إلى الخيار التالي. أما في UDP فلا ينتج الإرسال الناجح بالضرورة جواباً فورياً يمكن مراقبته، ولذلك يصعب أو يستحيل على المترجم أن يعرف وحده أي عنوان نجح، وقد يضطر التطبيق إلى إجراء التكرار بنفسه.

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

قد تصبح طبقة التوافق ذريعة لعدم النقل

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

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

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

عالج سباق الاتصال اللاحق مشكلة مجاورة بطريقة مختلفة

وضع BIS في RFC 2767 التحويل في طبقة أدنى واعتمد على SIIT في RFC 2765؛ أما RFC 3338 فنقلت التكيف عمداً إلى حد الواجهة. قدمت RFC 2893 سياق الانتقال بمكدسين في ذلك الزمن، ثم وثقت RFC 3493 امتدادات المقابس الأساسية لـIPv6، واستعرضت RFC 4038 خيارات انتقال التطبيقات.

حددت RFC 6555 وتحديثها RFC 8305 لاحقاً أساليب Happy Eyeballs لترتيب محاولات الاتصال أو تسابقها بين عائلتي العناوين. تعالج هذه الأساليب التأخير والتراجع من دون تحويل قيمة IPv4 مصطنعة إلى اسم مستعار خاص لطرف IPv6. وإسقاط تلك الخوارزمية اللاحقة على BIA يمحو الفرق التاريخي بين اختيار مرشحين حقيقيين وإنشاء مقبض محلي متغير.

تعرف RFC 4291 بنية عنونة IPv6، لكنها لا تمنح مخزون BIA الداخلي معنى عالمياً. كما لا تثبت أي من هذه المعايير أن مورداً أو مشغلاً نشر RFC 3338 فعلاً؛ وصف الآلية ليس دليلاً على اعتمادها.

يحتاج كل مقبض توافق إلى رقم جيل

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

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

من دون هذه الروابط يرى المحقق رقماً على هيئة IPv4 وينسب إليه معنى عالمياً لم يملكه قط. كانت RFC 3338 وسيلة انتقال، لكنها كانت أيضاً درساً في المقابض: البتات ليست الهوية؛ الخريطة الحية القابلة للتحقق هي التي تمنحها المعنى.

المصادر