الخلاصة

  • أتاح RFC 3493 لمقبس AF_INET6 التواصل مع نظير IPv4 ممثلاً بعنوان IPv4 مضمّن في IPv6. قيّد IPV6_V6ONLY المقبس إلى IPv6، لكن الوثيقة جعلته معطلاً افتراضياً.
  • لذلك لم يثبت اسم عائلة المقبس أو نجاح الربط الشامل عائلة النظير ولا ملكية منفذ IPv4 منفصل. كانت قيمة الخيار الفعلية ونتيجة كل bind والاتصالات المقبولة إيصالات مستقلة.

تبدأ المسألة من مراجعة أمنية تبدو واضحة. هناك عملية مصنفة IPv6 ومنفذ واحد، فتُبنى قاعدة على أن IPv4 يسلك مساراً آخر. لكن RFC 3493 صمم واجهة تسمح لمقبس IPv6 بأن يمثل نظيراً من IPv4، وبذلك يمكن لعملية واحدة أن تملك المدخلين معاً.

استخدمت الواجهة عنوان IPv4 المضمّن في IPv6. وُضعت 32 بت من عنوان IPv4 في أسفل بنية بطول 128 بت تحت السابقة الثابتة ::ffff:. استطاع التطبيق الاتصال بعقدة IPv4 عبر AF_INET6، وعند الاستقبال أمكن للنواة إعادة النظير في sockaddr_in6. وفر IN6_IS_ADDR_V4MAPPED() اختباراً لمن يحتاج التمييز.

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

عرّفت الفقرة 5.3 الخيار IPV6_V6ONLY. إذا فُعّل، اقتصر مقبس AF_INET6 على اتصالات IPv6. ونص RFC على تعطيله افتراضياً. وفق ذلك العقد التاريخي، استطاع مستمع شامل واحد استقبال IPv6 الأصلي وIPv4 الممثل بصورة مضمّنة.

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

لا تكفي قائمة العمليات. قد تعمل العمليتان بينما فشل bind لإحداهما. ولا تكفي قائمة المقابس إذا فسرت AF_INET6 على أنه IPv6 فقط. يلزم حفظ العائلة، والقيمة المقروءة لـIPV6_V6ONLY، والعنوان الشامل أو المحدد، وnamespace، والمنفذ، ونتيجة bind، وأنواع النظراء المقبولين فعلياً.

تضيف الوثيقة قيداً مهماً: لا يؤثر الخيار في العناوين المضمّنة التي تدخل العقدة كاتصال IPv6 صحيح عبر SIIT. يصف RFC 6052 وRFC 6145 عناوين مدمجة وترجمة رزم، وهي ليست مجرد تقديم محلي لنظير IPv4 إلى مقبس ثنائي. لذلك لا تكشف هيئة العنوان وحدها مكان التحويل.

حل الاسم مرحلة أسبق. يعيد getaddrinfo() مرشحين بحسب العائلة والرايات. ينظم RFC 6724 الاختيار، ويعامل RFC 8305 مساري IPv6 وIPv4 كبدائل تتنافس. وجود المرشح لا يثبت وجود listener أو نجاح الاتصال أو الترخيص أو الخدمة.

أما التعطيل الافتراضي فهو حقيقة مؤرخة بعام 2003. RFC 3493 وثيقة Informational أبطلت RFC 2553 وأشارت إلى معيار رسمي آخر للواجهة. قد تختلف أنظمة التشغيل وبيئات التشغيل والمنصات الحالية. لا بد من قياس القيمة الحديثة بدلاً من إسقاط التاريخ عليها.

الدرس الباقي هو ترتيب الأدلة: العائلة المعلنة، قيمة الخيار الفعلية، نطاق bind، ملكية المنفذ، تمثيل النظير، قرار التطبيق والنتيجة. من دون ذلك قد تخفي عبارة «مستمع IPv6» باب IPv4، أو تخفي أن مستمع IPv4 المقصود لم يبدأ قط.

المصادر