الخلاصة

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

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

تضع RFC 7157، وعنوانها IPv6 Multihoming without Network Address Translation، اسماً لهذا الخلل في التركيب. صدرت في مارس 2014 بوصفها RFC معلوماتية تعكس إجماع IETF. يرد O. Troan محرراً، ثم David Miles وSatoru Matsushima وTakashi Okimoto وDan Wing. ويسجل ملف Ole Trøan الرسمي في IETF هذه المساهمة. إنها نسبة دقيقة إلى عمل جماعي، لا برهان على اختراع منفرد أو إدارة أي نشر أو تأليف الوثائق اللاحقة.

تنطلق الوثيقة من وظيفة خفية في NAPT المستخدم مع IPv4. جهاز الحافة لا يغيّر العنوان فقط؛ فهو غالباً يختار عنوان المصدر الخارجي، ويحدد القفزة التالية، وقد يتوسط في DNS. يرى المضيف الداخلي عنواناً خاصاً وبوابة واحدة، بينما تبقى صلة العنوان العام بالمسار والمزود وخريطة الأسماء داخل الصندوق.

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

تحدد RFC 7157 ثلاثة أسئلة قبل الحزمة الأولى: أي عنوان مصدر يلائم الوجهة والمزود؟ أي قفزة أولى تقبل ذلك المصدر؟ وأي محلل DNS يعرف مساحة الأسماء المقصودة؟ يطبق مزودون كثيرون ترشيح الدخول لمنع انتحال المصدر. لذلك قد تُسقط حزمة تحمل بادئة صحيحة من المزود «أ» إذا خرجت عبر المزود «ب». صحة كل عنصر لا تثبت صحة المجموعة.

القرار الأول هو المصدر. تحدد RFC 6724 خوارزميات افتراضية لاختيار عناوين المصدر والوجهة، وتسمح بجدول سياسة إداري. تلاحظ RFC 7157 أن القواعد الافتراضية قد لا تحسم المصدر الملائم عندما توجد بادئات من مزودين مختلفين. وتعرّف RFC 7078 خيار DHCPv6 لتوزيع جدول الاختيار. لكن وصول الخيار لا يثبت أن المضيف ثبّته أو أبقاه صالحاً أو استخدمه لهذه الحزمة.

القرار الثاني هو الباب. قد تترك إعلانات الموجّه أكثر من موجّه افتراضي في حالة صالحة. واختيار أي منها قد يرسل مصدراً مشروعاً إلى شبكة عليا ترفضه. جاءت RFC 8028 لاحقاً في مسار المعايير لتحدد الترتيب: يختار المضيف المصدر أولاً، ثم يسلّم الحزمة إلى موجّه أعلن بادئة ذلك المصدر. مؤلفاها Fred Baker وBrian Carpenter. وتشكر Ole Troan على نص مهم، لكن الشكر بالمساهمة ليس نقلاً لصفة المؤلف.

القرار الثالث هو سياق DNS. قد لا يعرف اسماً داخلياً إلا محلل VPN، وقد يعيد مزود أجوبة مختلفة بحسب مصدر الاستعلام. اختيار أسرع جواب يمكن أن ينتج عنواناً صحيحاً لا يعمل عبر المخرج المختار. تناقش RFC 7157 سياسة مرتبطة بمساحة النطاق، وتشير إلى RFC 6731 لتوزيع سياسة اختيار DNS عبر DHCPv6. لا يحتفظ جواب DNS بمعناه التشغيلي ما لم يبق مرتبطاً بواجهة الاستعلام ومصدره ومحلله ومجال تزويده.

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

وتحافظ الوثيقة على دقة مهمة بشأن البدائل. توصي بتجنب NAT وNPTv6 متى أمكن للحفاظ على الشفافية من طرف إلى طرف، لكنها تخلص أيضاً إلى ملاءمة حلول تعتمد على DHCPv6 للمشكلات المدروسة، وإلى احتمال الحاجة إلى NPTv6 حلاً انتقالياً. الهدف المعماري ومسار الهجرة الناقص ليسا الشيء نفسه. كما أن RFC 6296 التي تصف ترجمة بادئات IPv6 عديمة الحالة ليست أمراً عاماً بالقبول أو الرفض.

طورت أعمال لاحقة طريقة لحفظ الانتماء. تعرّف RFC 7556 مجال التزويد PvD بأنه مجموعة متسقة من معلومات الشبكة، مثل بادئات المصدر وخوادم DNS ولاحقاته والبوابة الافتراضية. ويهدف النموذج إلى منع خلط إعدادات من مجالات مختلفة بلا قصد. ثم تسمح RFC 8801 بإعلان معرّف PvD قائم على FQDN، وبمعلومات JSON اختيارية. يساعد المعرّف على الربط، لكنه لا يثبت الثقة أو إمكانية الوصول الحالية أو نجاح التطبيق.

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

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

هنا تبقى مساهمة Trøan التحريرية مهمة. لقد فصلت الوثيقة ما جمعه الصندوق القديم، وأظهرت أن الشفافية لا تعني غياب التحكم. معناها أن نعرف مدخلات القرار وصاحبه ومدته وكيفية التراجع عنه.

المصادر