الخلاصة

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

تعرض لوحة رقابة عبارة «يفضّل عنواناً مؤقتاً»، ثم يحولها التقرير التنفيذي إلى «استُخدم عنوان خاص». تحولت رغبة التطبيق إلى شهادة هوية من دون أن يقرأ أحد العنوان المختار.

وضع RFC 5014 حلاً أضيق. كانت التطبيقات تستطيع تثبيت عنوان محدد عبر bind() أو IPV6_PKTINFO، لكنها عندئذ تتحمل تعقيد ملاءمته للوجهة والواجهة والنطاق. أما الخيار الجديد فيسمح بتعديل بعض تفضيلات الاختيار ويترك بقية القواعد للنظام.

هناك ثلاثة أزواج: عنوان home أو care-of، مؤقت أو public، وCGA أو non-CGA. يمكن جمع صفات من محاور مختلفة. الجمع بين طرفي المحور نفسه تناقض؛ فيعيد socket الخطأ EINVAL، وتعيد إضافة getaddrinfo() الخطأ EAI_BADEXTFLAGS. هذا يثبت سلامة الطلب من التناقض فقط.

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

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

وقد تتغلب التعليمات الصريحة على التفضيل. إذا ثبّت bind() أو IPV6_PKTINFO المصدر، فذلك العنوان مقدّم على IPV6_ADDR_PREFERENCES. وجود العلم في السجل لا يعني أنه صاحب القرار الفعلي.

للشرط الصارم مسار آخر. يصرح RFC بأن تفضيلات العناوين لا تضمن تحقق متطلبات التطبيق. على التطبيق وضع الأعلام نفسها في المحلل وsocket، وطلب الاختيار، وقراءة المصدر بواسطة getsockname()، واختبار صفاته بواسطة inet6_is_srcaddr()، ثم إيقاف الاتصال إذا لم يطابق الشرط.

حتى الاختيار قد يرسل مبكراً. في TCP قد يخرج SYN من connect() قبل أن يفحص التطبيق المصدر. لهذا يعرّف النص bind2addrsel() لربط العنوان الذي كان سيختاره النظام للوجهة من دون بدء الاتصال. أما connect() في UDP فيستطيع إجراء الاختيار المحلي من دون إرسال datagram. المختار ليس هو المرسل.

تُرجع دالة التحقق 1 أو 0 أو -1: عنوان محلي يحقق كل الأعلام، أو عنوان لا يطابقها، أو عنوان غير محلي/إدخال غير صالح. ولا يثبت الرقم 1 المسار البعيد. قد تكون صفة home صحيحة على جهاز لا يطبق Mobile IPv6 أو على عقدة موجودة في حالة home، من دون أن تكون دليلاً على موقع إنسان.

ولا ينبغي تضخيم الصفات الأخرى. يبين RFC 8981 أن تغيير العنوان المؤقت يحد من نافذة الربط السهل للنشاط بعنوان واحد، ولا يضمن إخفاء الهوية في الطبقات الأخرى. ويربط RFC 3972 CGA بمادة مفتاح عام، لكنه يوضح أن CGA ليست هوية مصدّقة. طلبها ليس تحققاً من توقيع أو إذناً.

كما تغيرت الافتراضات مع الزمن. اعتمد RFC 5014 على RFC 3484 الذي فضّل العنوان العام في ذلك السياق. استبدله RFC 6724 وجعل المؤقت مفضلاً في القاعدة المقابلة. لا بد من تسجيل مرشحي الجهاز وسياسة نسخته لحظة القرار.

يجب أن يحفظ إيصال اختيار المصدر: التطبيق وsocket، الأعلام والقيمة السابقة، أعلام المحلل وترتيب الوجهات، الأعلام المتجاهلة، مجموعة المرشحين، مراجعة السياسة، أي تثبيت صريح، طريقة الاختيار واحتمال الإرسال المبكر، نتيجة getsockname()، مدخلات التحقق ونتيجته الثلاثية، قرار المتابعة أو الإيقاف، ثم الحركة الخارجة والعودة ونتيجة التطبيق كلّاً على حدة.

هذا اقتراح تشغيلي لا مطلب خفي في RFC. إنه تطبيق لطبقات الواقع لدى Heng Lu: نية التطبيق، واختيار المضيف، وصفة العنوان، ومسار الشبكة، والنتيجة المؤسسية ليست حقيقة واحدة.

المصادر