الخلاصة

  • يمكن أن تتكرر قيمة عنوان IPv6 محدود النطاق في مناطق مختلفة. يضيف المضيف المتصل بأكثر من منطقة فهرسًا محليًا منفصلًا عن العنوان، ويستخدمه لاختيار الواجهة من دون إرساله في الحزمة.
  • حاول RFC 6874 سنة 2013 وضع ZoneID داخل URI، ثم ألغى RFC 9844 هذا المسار سنة 2025 لعدم قابليته العملية في المتصفحات. أصبح المطلوب أن تسمح الواجهة بإدخال المنطقة أو اختيارها والتحقق منها وتحويلها محليًا.

السلطة موزعة بين أربع طبقات

سبق تصميم المقابس النقاش حول URI. يعرّف RFC 3493، المنشور في فبراير 2003، حقلين منفصلين في sockaddr_in6: العنوان في sin6_addr، ومحدد النطاق ذي 32 بتًا في sin6_scope_id.

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

ويحدد RFC 3493 أيضًا التحويل بين اسم الواجهة ورقمها. تستعلم if_nametoindex() من النظام الذي ينفذ العملية. إن لم يعرف الاسم فترجع فشلًا؛ لا تبحث في سجل عالمي ولا تطلب من الجار ترجمة الاسم.

اقترح RFC 4007 الصيغة النصية <address>%<zone_id>. ينبغي دعم رقم عشري غير سالب، ويمكن دعم أسماء تعتمد على النظام مثل أسماء الواجهات. بما أن العنوان يبين النطاق، يكفي أن يميز اللاحقة بين مناطق ذلك النطاق داخل الجهاز.

لكن الصيغة ليست بلا حدود. لا معنى لها مع عنوان عالمي، ولا ينبغي استخدامها مع loopback. يجب أن تبقى داخل العقدة وألا ترسل على الشبكة ما لم يتفق كل من سيفسرها مسبقًا على معناها.

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

التحقق من نص بلا قواعد عالمية

لم يحدد RFC 4007 مجموعة أحرف موحدة أو طولًا لمعرف المنطقة، وترك معنى الأسماء غير الرقمية للتنفيذ. تسمح هذه المرونة بأنظمة تسمية مختلفة، لكنها تجعل واجهة الإدخال مسؤولة عن الحماية.

يوصي RFC 9844 بحد طول مناسب ورفض مدخلات خطرة مثل NUL. ويسجل erratum 8553 held في RFC 4007 غياب هذه القيود ويحيل إلى الإرشادات الأحدث.

قد تمر السلسلة عبر نموذج وshell وملف إعداد ومحلل URI وسجل ثم API للنظام. يمكن لاختلاف في فك الترميز أو القطع أن يجعل الواجهة المعروضة غير الواجهة التي استلمتها النواة. فصل الحقول يتيح لكل طبقة التحقق من نوع واحد بدل تفسير لغة مركبة.

حتى النجاح لا يوسع الدليل. نجاح عملية عبر %eth0 يعني أن هذا الاسم حُل محليًا وأن العملية عملت عبر المسار في تلك اللحظة. لا يصادق على الطرف الآخر، ولا يثبت ملكية العنوان، ولا يمنح وصولًا عالميًا، ولا يجعل الاسم صالحًا لجهاز ثان.

القيمة نفسها لا تعني المجال نفسه

يمكن لحاسوب صيانة أن يتصل بشبكتين في الوقت ذاته. قد يوجد جهاز يحمل fe80::1 على كل شبكة. لا يعني ذلك أن IPv6 أخفق في كشف تعارض عالمي، لأن العنوان link-local لم يدّع أصلًا أنه عالمي.

يحدد RFC 4291 أن العنوان link-local صالح لوصلة واحدة، ويمنع الموجّهات من تمرير حزمة ذات مصدر أو وجهة link-local إلى وصلة أخرى. الحد موجود في سلوك التوجيه، لا في وعد بأن القيمة العددية لن تتكرر.

فصل RFC 4007 بين مفهومين في مارس 2005. النطاق scope هو حجم منطقة طوبولوجية، أما المنطقة zone فهي نسخة معينة من منطقة بهذا النطاق. كل وصلة تمثل منطقة مستقلة من نطاق link-local.

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

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

الاسم المقروء ليس إحداثية قابلة للنقل

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

أوصى RFC 4007 بمناطق افتراضية، ويستخدم الصفر عادة للدلالة على الاختيار الافتراضي. غير أن RFC 9844 يسجل أن أنظمة تشغيل لا تقدم افتراضيًا صالحًا، ويذكر Linux. نجاح برنامج بلا لاحقة في بيئة لا يثبت أن السياق غير مطلوب؛ ربما اختارته البيئة ضمنيًا.

كما أن توحيد كتابة العنوان لا يوحد اللاحقة. وضع RFC 5952 قواعد لصياغة عنوان IPv6، مثل ضغط الأصفار وحالة الحروف والأقواس عند إضافة المنفذ. يوضح RFC 9844 أن هذه القواعد لا تشمل امتداد المنطقة في RFC 4007.

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

التراجع الذي أعاد المسؤولية إلى مكانها

في أغسطس 2025 جعل RFC 9844 وثيقة RFC 6874 متقادمة بالكامل، لأن منفذي المتصفحات وجدوا النهج غير عملي. كما ألغى تحديث RFC 3986، وسجل erratum 8552 المتحقق هذا التغيير.

لا يقترح المعيار الحالي URI بديلًا. بل يطلب من أي واجهة تقبل عنوانًا غير global unicast أن تتيح إدخال معرّف المنطقة أو اختياره. يفضل الشكل الكامل مع %، لكن يمكن استخدام حقل منفصل أو قائمة أو فاصل آخر أو معلمة مستقلة.

تحتفظ الواجهة بالعنوان والمعرّف منفصلين، وتحول المعرف إلى رقم واجهة محلي، وينبغي أن تعرض خطأ عند الاسم غير الصالح. لا تستطيع inet_pton() في POSIX تحويل fe80::1%eth0 وحدها. يحتاج البرنامج إلى getaddrinfo()، أو إلى فصل السلسلة والجمع بين inet_pton() وif_nametoindex().

يستبعد RFC 9844 دلالات جلب URI في المتصفح. لا يحل مسألة HTTP origin ولا يعد برابط محمول. إنه يضمن أن أداة تحتاج إلى منطقة تستطيع جمعها بوضوح، من دون أن ترسلها أو تجعلها جزءًا من عنوان IPv6.

محاولة جعل القرينة جزءًا من URI

يصف RFC 3986، الصادر في يناير 2005، URI بوصفه بناءً ذا نطاق عالمي، مع إمكان اعتماد بعض الأفعال على سياق المستخدم. ويحجز % لبدء percent-encoding، لذلك يمثل %25 علامة النسبة المئوية الحرفية.

حاول RFC 6874 في 2013 تركيب ZoneID داخل هذا البناء. صار الجزء المحاط بأقواس في URI من نوع HTTP مثل [fe80::a%25en1]: تمثل %25 الفاصل %، ويأتي بعدها الاسم المحلي.

كان الهدف تمكين المتصفح أو أداة تعتمد URI من الوصول إلى جهاز link-local. لكن الوثيقة نفسها قالت إن ZoneID ذو معنى في عقدة المنشأ فقط، وإنه ينبغي نزعه قبل وضعه في طلب HTTP صادر.

بدت القرينة جزءًا من URI في شريط العنوان، ثم وجب أن تختفي عند الإرسال. ظهرت أسئلة عن origin والسجل والإشارات المرجعية والوسيط وموعد فك %25. قد تفك طبقتان الترميز مرتين فتغيران المسار بدل أن تنظفاه.

لم تكن المشكلة في اختيار الرمز. كانت في إدخال قرار واجهة محلية في هوية صممت لتُحفظ وتُقارن وتُنقل بين سياقات متعددة.

سياق يكتمل حين يتوقف

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

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

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

المصادر