الخلاصة

  • عالجت RFC 1868 فجوة في Proxy ARP: قد يعاود مضيف هاتفي الاتصال عبر خادم ثانٍ قبل أن تمحو أجهزة LAN عنوان الخادم الأول من ذاكرتها المؤقتة.
  • استخدمت UNARP رسالة ARP Reply غير مطلوبة بطول صفري لعنوان العتاد. كان على المستقبل الداعم حذف السجل المرتبط بعنوان IP المصدر، بينما كان متوقعاً من التنفيذ غير الداعم رفض الصيغة المختصرة.
  • الإرسال، ووصول الإطار إلى نظير بعينه، وقبول المحلل، وحذف السجل المحلي، وتعلم الاقتران الجديد، ونجاح تمرير البيانات أحداث مختلفة. لم توفر الرسالة إيصالاً بالمراحل التي تلت بثها.

عاد العنوان من باب آخر

لنتصور مستخدماً بعيداً يتصل بمجموعة مودمات مشتركة عبر خادم الاتصالات CS1. يبدو عنوان IP الخاص به للمضيف Host A وكأنه موجود على الشبكة المحلية نفسها، مع أن الحاسوب يقع خلف الخادم. حين يسأل Host A بواسطة ARP، يجيب CS1 نيابة عن الحاسوب البعيد ويقدم عنوان عتاده هو. يحتفظ Host A بهذا الاقتران ثم يرسل الإطارات اللاحقة إلى CS1.

كان هذا هو حل التوافق الذي وثقته RFC 1027. أخفى Proxy ARP الشبكة الفرعية والمسار عن مضيفين لم يكونوا مهيئين لفهمهما. حمل الوسيط التعقيد، لكن حقيقة المسار اختُصرت في سجل محلي واحد: لهذا العنوان IP استخدم عنوان عتاد الخادم.

إذا انقطع المستخدم ثم عاد سريعاً عبر CS2 قبل انتهاء صلاحية السجل، ظل عنوان IP ثابتاً وتغير من يملك الطريق. لم يصل هذا التغير إلى Host A، فواصل الإرسال إلى CS1. لم تكن البتات المخزنة تالفة؛ كانت الحقيقة التي وصفتها قد انتهت.

احتفظ كل مضيف بدفتره الخاص

عرّفت RFC 826 ARP وسيلة لتوزيع الاقتران بين عنوان بروتوكول وعنوان عتاد محلي. يطرح Request سؤالاً، ويقدم Reply اقتران المرسل، ويمكن للمستقبل دمجه في جدوله واستخدامه لاحقاً.

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

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

Reply بلا عنوان عتاد

نُشرت RFC 1868 بوصفها Experimental في نوفمبر 1995، واختارت تعديلاً ضيقاً بدلاً من بروتوكول تنقل كامل. استخدمت UNARP القيمة 2 الخاصة بـ ARP Reply، ونوع بروتوكول IPv4، وطول عنوان بروتوكول قدره أربعة، لكنها جعلت طول عنوان العتاد صفراً. حمل عنوان المصدر IP للمضيف المغادر، وكان عنوان الهدف 255.255.255.255. وبغياب حقلي عتاد المصدر والهدف، بلغ طول الرسالة ستة عشر بايت قبل ترويسة الوصلة.

كان على المستقبل الذي يفهم RFC 1868 أن يحذف مدخل الذاكرة المؤقتة المفهرس بعنوان IP المصدر. ولم يكن على الخادم أن يتذكر هل سبق أن أصدر Proxy ARP Reply لذلك المضيف؛ كان يستطيع إرسال UNARP عند كل انقطاع. كما أمكن لمضيف يغادر LAN بطريقة منظمة أن يرسلها عن نفسه.

اختار التصميم بين كلفتين غير متساويتين. الحذف الزائد يؤدي غالباً إلى عملية حل جديدة. الإبقاء على السجل الخاطئ يواصل إرسال الإطارات إلى وسيط لم يعد يملك الطريق. فضّل UNARP إعادة فتح السؤال على حماية استمرارية زائفة.

لكن حذف القديم لا ينشئ الجديد. بعد قبول الرسالة، بقي على Host A أن يرسل ARP Request جديداً، ويتلقى Reply، ويتعلم عنوان CS2، ثم يجرب تمرير البيانات. عدم الثقة في CS1 لم يكن دليلاً على الوصول عبر CS2.

التوافق أبقى حق الرفض

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

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

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

خفّض التكرار احتمال الفقد ولم يصنع إجماعاً

قدمت RFC 2176 سنة 1997 صيغة UNARP مرتبطة بـ IPv4 فوق MAPOS. استخدمت رمز عملية مخصصاً وحقول عتاد حقيقية. كان العقدة عند بدء العمل تبث ثلاث نسخ بفواصل ثلاثين ثانية. ولا يحذف المستقبل اقتران IP إلا إذا اختلف عنوان العتاد في الرسالة عن القيمة الموجودة في ذاكرته.

قللت النسخ الثلاث احتمال بقاء الحالة القديمة بسبب فقد إطار واحد. وحمى شرط المقارنة اقتراناً أصبح صحيحاً بالفعل. لكن ثلاث عمليات إرسال لم تكن ثلاث إقرارات. فرضت RFC نفسها تقادم الذاكرة والتنظيف الفوري عند فقد الوصلة كآليتين منفصلتين. لم تمنح إعلاناً واحداً سلطة الحقيقة كلها.

صنفت RFC 3790 RFC 1868 لاحقاً كامتداد يعتمد على IPv4 لحذف سجلات ARP. يثبت ذلك مكان الغرض في السجل المعياري، ولا يثبت الانتشار أو المطابقة أو النتيجة.

الإعلان الجديد بقي ادعاءً محلياً

شرحت RFC 5227 لاحقاً أن ARP Request يحمل صوتين: حقول المرسل تدعي اقتراناً، وحقول الهدف تسأل عن اقتران. يسأل Probe هل العنوان مستخدم بينما يشير إلى نية استخدامه. ويقول Announcement إن المرسل يستخدم العنوان الآن.

قالت UNARP العبارة المعاكسة: لا تثقوا بالاقتران السابق. يصل الادعاء الإيجابي أو السلبي إلى كل مستقبل كمدخل يفحصه وفق الصيغة والإعداد والحالة المحلية. لا يثبت أي منهما اتفاق الجميع، ولا غياب التعارض، ولا وصول الإطار التالي، ولا نجاح التطبيق.

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

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

توثق RFC 826 وRFC 1027 وRFC 1122 أساس ARP وProxy ARP وإبطال الذاكرة. تعرف RFC 1868 الرسالة التجريبية، وتقدم RFC 2176 صيغة لاحقة خاصة بوصلة، وتصنف RFC 3790 اعتماد IPv4، وتشرح RFC 5227 دلالة Probe وAnnouncement. تثبت هذه المصادر الصيغ والسلوك المطلوب والتوقعات المكتوبة. ولا تثبت استعمالاً حالياً، أو دعماً عاماً، أو مطابقة منتج بعينه، أو حادثة أو استغلالاً حقيقياً، أو نجاح التوصيل على شبكة فعلية.