كان رد التطبيق دليلاً على إمكان الوصول إلى الموجّه: RFC 3316

الخلاصة

• أوصى RFC 3316 بأن يستفيد المضيف الخلوي من إقرار TCP جديد أو تقرير استقبال RTCP أو استجابة SIP بوصفها دليلاً إيجابياً على أن حركة صادرة حديثة عبرت موجّه القفزة الأولى.
• كان الاستنتاج محدوداً: يمكنه تحديث حالة الجار وتجنب مسبار NUD، لكنه لا يثبت اكتمال التطبيق ولا استمرار الاتصال ولا يجعل كل حركة واردة برهاناً على سلامة المسار الصادر.

لم تكن الحزمة المكلفة في جلسة IPv6 خلوية مبكرة تحمل دائماً بيانات المستخدم. أحياناً كانت مجرد سؤال تحكم يملك المضيف إجابته بالفعل من طبقة أخرى.

تتابع آلية Neighbor Unreachability Detection، أو NUD، ما إذا كانت القفزة التالية قد كانت قابلة للوصول في وقت قريب. عندما تنتهي صلاحية تلك الثقة مع استمرار الإرسال، يستطيع المضيف بعث Neighbor Solicitation أحادية الوجهة وانتظار Neighbor Advertisement مستثارة بها. في Ethernet يجاور هذا التبادل حل العناوين بصورة طبيعية. أما وصلات GPRS وUMTS التي تناولها RFC 3316 فكانت أقرب إلى نقطة مقابل نقطة: للمضيف جار واحد هو الموجّه الافتراضي المعروف، ولا توجد عناوين طبقة ربط معتادة. لم تعد عملية حل العنوان ضرورية، لكن كشف فشل القفزة الأولى ظل ضرورياً.

لذلك طرح الملف سؤالاً أدق: هل أثبت بروتوكول آخر بالفعل أن حزمة صادرة حديثة تقدمت في الاتجاه المطلوب؟

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

نقل RFC 3316 الفكرة نفسها إلى تطبيقات خلوية تعتمد UDP بكثرة. لا يقدم UDP تأكيد تسليم بذاته، ولهذا كان على التطبيق أن يكشف إشارة ذات علاقة سببية صحيحة. في RTP، قد يصلح جزء من تقرير استقبال RTCP يبين أن بعض الحزم وصلت إلى النظير. وفي SIP، تدل الاستجابة لطلب على أن الطلب خرج ووصل. أما عندما يعمل المضيف الخلوي في جهة خادم SIP، فإرسال الاستجابة لا يوفر عادة هذا الدليل؛ وصول ACK لاحق قد يبين أن الاستجابة السابقة لطلب INVITE بلغت الطرف الآخر.

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

والحالة الناتجة لم تكن شهادة دائمة. قد ينقل تأكيد من طبقة أعلى قيد الجار إلى REACHABLE لمدة محدودة. إذا توقفت الأدلة الجديدة يهرم إلى STALE؛ ومع إرسال جديد يمكن أن ينتقل إلى DELAY ثم PROBE، فتعود رسائل Neighbor Solicitation المخصصة. لم يلغ RFC 3316 آلية NUD، بل تجنب تكرار السؤال حين كانت الحركة النشطة تقدم جواباً صالحاً.

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

استمرت الآلية بعد انتهاء الملف. حل RFC 7066 محل RFC 3316 في 2013، وأضاف EPS إلى النموذج، وأبقى أمثلة TCP وRTCP وSIP، وأضاف استجابة DNS. استمرار النص يبين بقاء الاستنتاج في ملف التعريف، ولا يثبت أي الأجهزة نفذته أو عدد المسابير التي وفرها.

الدرس التاريخي ليس أن يقرر التطبيق التوجيه. إنه أن آلة حالة تستطيع إعادة استخدام دليل من طبقة أخرى عندما تكون علاقة الاستلزام واضحة. يفيد تقرير النظير البعيد عن القفزة الأولى لأن الحزمة الصادرة كان لا بد أن تعبرها. وتنتهي النتيجة عند هذا الحد: تقرير RTCP لا يثبت جودة الوسائط، واستجابة SIP لا تثبت اكتمال المكالمة، وموجّه قابل للوصول لا يثبت توافر الخدمة، ودليل حزمة واحدة لا يضمن الحزمة التالية.

المصادر: RFC 3316، RFC 2461، RFC 4861، RFC 7066، RFC 7849، RFC 8504، RFC 3550، وRFC 3261.