الخلاصة

  • اعتبر Neighbor Unreachability Detection في IPv6 قابلية الوصول ادعاءً يحتاج إلى تأكيد إيجابي حديث. وعندما يَقدم التأكيد تنتقل الخانة إلى STALE، لكنها لا تُحذف ولا تُطلق فحصاً ما دامت غير مستخدمة.
  • يفتح أول إرسال حالة DELAY كي تمنح الطبقات العليا فرصة لإثبات تقدّم الاتصال، ثم يبدأ PROBE فقط عند غياب الدليل. وأضاف RFC 7048 حالة UNREACHABLE والتراجع الأُسّي لفصل تجربة جار بديل عن التوقّف النهائي عن إنقاذ الجار الوحيد.

STALE كانت تصف عمر الدليل لا حالة الجهاز

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

سمّى IPv6 هذه الحالة STALE. ومن السهل قراءة الاسم في شاشة التشغيل وكأنه يعني «تالف»، بينما حدّه البروتوكولي أضيق. وضع RFC 1970 عام 1996 Neighbor Unreachability Detection ضمن Neighbor Discovery الأساسي، وحافظ RFC 2461 ثم RFC 4861 على آلة الحالات نفسها.

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

وصول إعلان من الجار لم يثبت المسار إليه

يهتم NUD بالمسار الأمامي كما يراه المرسل. وصول Router Advertisement يثبت أن حزمة انتقلت من الموجّه إلى المضيف. وكذلك Neighbor Advertisement غير المطلوبة. لكن أياً منهما لا يثبت أن حزمة حديثة أرسلها المضيف وصلت إلى طبقة IP لدى الجار.

لذلك قبلت المواصفات مصدرين للتأكيد الإيجابي. الأول Neighbor Advertisement مطلوبة رداً على Neighbor Solicitation: يجب أن يصل الطلب إلى الجار ثم تعود الإجابة، فتظهر دلالة على الاتجاهين. والثاني إشارة من طبقة عليا لا يمكن أن يظهر معها تقدّم الاتصال لو لم تصل الحزم السابقة.

يوضّح TCP الفكرة جيداً. فـ ACK جديد يعني أن بيانات سابقة بلغت الطرف الآخر، ووصول بيانات جديدة غير مكررة قد يعني أن ACK أقدم وصل إليه. وإذا كانت الوجهة خارج الوصلة، يدل هذا التقدّم أيضاً على أن موجّه الخطوة الأولى نقل حركة حديثة. قد لا يملك UDP أو الموجّه الذي يمرّر حزم الآخرين إشارة مماثلة، فيلزم الفحص الصريح.

هذا الدليل لا يصادق على هوية، ولا يضمن استمرار الخدمة، ولا يمنح حقاً في العنوان. إنما يبرّر قراراً محلياً محدوداً: الاستمرار في استخدام الربط الموجود في الذاكرة من دون فحص آخر.

الحزمة الفعلية أخذت فرصتها قبل حزمة التحكّم

عند إرسال أول حزمة عبر خانة STALE، يستخدم المضيف عنوان طبقة الربط المخزّن وينقلها إلى DELAY. والقيمة الافتراضية للانتظار خمس ثوان.

لم تكن DELAY مهلة فارغة. بعد سكون طويل قد تبدأ جلسة TCP وتنتج المصافحة سريعاً دليلاً على التقدّم. إذا وصل هذا الدليل، تعود الخانة إلى REACHABLE من دون Neighbor Solicitation إضافية.

أما إذا انتهت المهلة بلا تأكيد، فترسل العقدة Neighbor Solicitation أحادية الوجهة وتدخل PROBE. فالعنوان الرابط معروف، والسؤال هو هل ما زال هذا المسار المعروف يعمل؟ إعادة اكتشاف صاحب عنوان IPv6 عبر البث المتعدد سؤال مختلف يأتي لاحقاً.

بهذا الترتيب لا يخلق الزمن وحده حركة تحكّم. الزمن يقلّل الثقة، والاستخدام يجعل الشك مهماً، وDELAY تنتظر دليلاً قد تنتجه الحركة العادية، وPROBE تدفع كلفة الاختبار عند الضرورة فقط.

المؤقّتات لم تضع كل العقد على إيقاع واحد

حدّد RFC 4861 قيمة أساسية افتراضية قدرها 30 ثانية، وثانية واحدة لإعادة الإرسال، وخمس ثوان قبل أول فحص، وثلاث محاولات أحادية الوجهة. غير أن ReachableTime الفعلي يُختار عشوائياً بين نصف القيمة الأساسية ومرة ونصف. كما يمكن لـ Router Advertisement أن تقترح قيماً غير صفرية للزمن الأساسي وإعادة الإرسال.

يمنع العشوائي آلاف الأجهزة على الوصلة نفسها من تقادم أدلتها وإطلاق فحوصها معاً. ولهذا لم يكن «ثلاثون ثانية حتى الموت» قاعدة في الأصل.

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

ثلاث محاولات سريعة قد تزيد العطب

في النموذج الأصلي لـ RFC 4861، تعيد PROBE إرسال Solicitation أحادية الوجهة، ثم تحذف الخانة بعد بلوغ الحد بلا إجابة. ومع القيم الافتراضية يعني ذلك ثلاث عمليات تفصل بينها ثانية. بعدها قد يختار المضيف موجّهاً آخر أو يعود إلى حلّ العنوان بالبث المتعدد.

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

وثّق RFC 6583 حلقة ضغط مشابهة. ففي شبكة IPv6 /64 يمكن لطلبات عناوين غير موجودة أن تزاحم أعمال NDP. وإذا أزاحت صيانة الخانات المستخدمة أو الإجابة عن فحوص NUD، تُحذف خانات صحيحة، ويزداد البث المتعدد، وتتوقف حركة قائمة. لذلك أوصى بإعطاء NUD المتعلق بوجهات مستخدمة أولوية على إنشاء خانات لوجهات قد لا تكون موجودة.

في 2014 سمّى RFC 7048 المشكلة بوضوح: NUD «متسرع أكثر من اللازم». أضاف التحديث حالة مفهومية UNREACHABLE. بعد الحد المعتاد لا تعود الخانة «معروفة الوصول» عند اختيار الخطوة التالية، فيمكن تجربة بديل. لكن يمكن الاحتفاظ بعنوان طبقة الربط، والاستمرار في إرسال الحزم عند الحاجة، ومواصلة الفحص بتراجع أُسّي.

يجب الانتقال لاحقاً إلى البث المتعدد لاكتشاف تغيّر عنوان طبقة الربط، ويمكن وقف الفحوص إذا لم تعد الخانة مستخدمة. يعرض RFC مثالاً للمحاولات عند 1 و4 و13 و40 ثانية، ويذكر 60 ثانية سقفاً ممكناً للفاصل. إنه مثال خوارزمي، لا قياس لكل منتج منشور.

UNREACHABLE فصل تغيير الأفضلية عن إغلاق باب التعافي

السؤالان مختلفان: هل ينبغي تفضيل جار آخر؟ وهل ينبغي التوقف كلياً عن محاولة هذا الجار؟ عند وجود موجّه بديل يجب أن تكون الإجابة الأولى سريعة. وعند غياب البديل، قد تحتاج الثانية إلى وقت أطول كي تتعافى وصلة لاسلكية أو تقارب spanning tree أو واجهة أُعيد تشغيلها.

يحدّ التراجع الأُسّي من كلفة التحكّم مع إبقاء احتمال التعافي. ولم تتغيّر معايير الإثبات: تقدّم موثوق من الطبقة العليا أو إجابة مطلوبة يعيدان REACHABLE، أما الإعلان غير المطلوب فلا يكفي. غيّر RFC 7048 عاقبة الفشل ولم يخفّف تعريف النجاح.

DAD استخدم الرسائل نفسها لقرار آخر

يستخدم RFC 4862 Neighbor Solicitation وAdvertisement في Duplicate Address Detection. يعمل DAD قبل إسناد عنوان أحادي الوجهة ويسأل هل يطالب عقدة أخرى بالعنوان المؤقت. يعمل NUD بعد اختيار جار واستخدامه ويسأل هل ما زال المسار المرتبط بالخانة يتقدّم.

قد يسمح الصمت المحدود في DAD باستخدام العنوان. أما في NUD، فيجعل الصمت الدليل قديماً، ثم يطلق الاستخدام DELAY وPROBE. تشابه الرسالة لا يساوي تشابه حجية الاستنتاج.

المصادر وحدود الدليل

يأتي التاريخ والحالات من RFC 1970 و2461 و4861. يحدّد RFC 4862 الفرق مع DAD، ويوثّق RFC 6583 ضغط التشغيل، ويعدّل RFC 7048 التعافي. لا تثبت هذه النصوص إعدادات المورّدين الحالية، أو نسبة الانتشار، أو أحجام الذاكرة، أو معدلات الأعطال، أو التزام شبكة بعينها.