الخلاصة

  • عالجت RFC 903 مشكلة محددة عند بدء التشغيل من حالة باردة: يعرف المضيف بلا قرص عنوانه العتادي، لكنه يحتاج إلى عنوان بروتوكول قبل استخدام IP.
  • وضع RARP عملية البحث في طبقة ربط البيانات. وكان الخادم يجيب استناداً إلى جدول يحتفظ به للربط بين العناوين العتادية وعناوين البروتوكول؛ ولم تثبت الإجابة هوية الجهاز أو اكتمال إقلاعه.
  • لم يحدد البروتوكول جواباً صريحاً بمعنى «غير موجود». فإذا لم يسمع العميل شيئاً، كان عليه انتظار انتهاء المهلة من دون أن يعرف هل غاب الربط، أم فُقدت حزمة، أم لم يجب أي خادم.
  • توضح RFC 950 وBOOTP لماذا لا يكفي عنوان واحد لإعداد مضيف: فقد يحتاج أيضاً إلى بوابة، وخادم أسماء، وقناع شبكة فرعية، وملف إقلاع.

السؤال الأول سبق IP

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

في RFC 903، المنشورة في يونيو 1984، اقترح Ross Finlayson وTimothy Mann وJeffrey Mogul وMarvin Theimer بروتوكول RARP. تصف المذكرة مضيفاً يسأل مصدراً خارجياً عن عنوان بروتوكوله عبر وسط بثّ مثل Ethernet. أما ARP فيحل المسألة في الاتجاه المقابل: يجد العنوان العتادي عندما يكون عنوان البروتوكول معروفاً. يبدأ RARP من العنوان العتادي ويسأل عن عنوان البروتوكول المقابل له.

لم تكن هذه خدمة عامة لإثبات الهوية. لم يسأل RARP من يملك المحطة أو ما إذا كان يحق لشخص استخدام عنوان ما. بل أتاح لمضيف غير مُعدّ أن يطلب ربطاً محدداً قبل بدء اتصالات IP المعتادة.

خادم محلي حفظ الإجابة

عرّفت RFC 903 بروتوكول RARP عمداً كآلية منفصلة في طبقة ربط البيانات. أعادت استخدام تنسيق حزم ARP، لكنها خصصت رموز عمليات مختلفة للطلب العكسي والرد العكسي. وعندما يطلب المضيف عنوانه هو، يضع العنوان العتادي نفسه في حقلي المرسل والهدف. ويمكن لخادم يتعرف إلى هذا العنوان أن يرد بعنوان البروتوكول المقابل للهدف.

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

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

الصمت لا يعني «غير موجود»

تحدد RFC 903 الطلبات والردود العكسية، لكنها لا تعرف حزمة «غير موجود» أو حزمة خطأ. يوضح المؤلفون أن عدداً من الخوادم قد يكون مخولاً بالرد. ولذلك لم يعرّفوا رسالة رفض مستقلة، بل طلبوا من صاحب الطلب انتظار المهلة إذا لم يصل رد خلال فترة معقولة.

أبقى هذا الاختيار التبادل صغيراً، لكنه ترك العميل أمام ملاحظة ملتبسة. فقد يعني انتهاء المهلة أن لا خادم يملك الربط؛ وربما فُقد الطلب أو الرد، أو تعطلت الوصلة، أو لم يتوفر أي خادم. لا يميز الصمت بين هذه الحالات. وسجل إقلاع يكتب فقط «انتهت مهلة RARP» لا يحسم السبب.

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

عنوان واحد لا يهيئ المضيف كله

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

احتفظ BOOTP، الذي وُضع في العام التالي، بوظيفة البحث عن IP انطلاقاً من العنوان العتادي، وأضاف معلومات إقلاع أكثر، منها اسم ملف اختياري. كما أتاح تصميمه الإقلاع عبر البوابات. وتقارن RFC 951 صراحة بين نهج IP/UDP وبين حزم RARP في طبقة الربط والتعديلات الخاصة على النواة أو المشغل اللازمة للوصول إليها. ثم أوضحت RFC 1542 سلوك مرحلات BOOTP؛ وتشرح RFC 2131 DHCP بوصفه مبنياً على BOOTP مع إضافة التخصيص التلقائي لعناوين قابلة لإعادة الاستخدام وخيارات الإعداد.

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

السجل ليس الجهاز

تقدم ملاحظة Heng Lu رقم 72 إطاراً تحليلياً لاحقاً، لا دليلاً على عام 1984: يسجل الدفتر واقعاً لكنه لا ينشئه. لم يكن RARP سجلاً عالمياً، لكن التمييز يظل مفيداً. فقد نسق جدول الخادم ربطاً محلياً؛ ولم يحول العنوان المعاد إلى دليل على ملكية العتاد أو هوية المستخدم أو نجاح التشغيل.

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

المصادر

RFC 903 — A Reverse Address Resolution Protocol؛ RFC 826 — An Ethernet Address Resolution Protocol؛ RFC 950 — Internet Standard Subnetting Procedure؛ RFC 951 — Bootstrap Protocol؛ RFC 1542 — Clarifications and Extensions for the Bootstrap Protocol؛ RFC 2131 — Dynamic Host Configuration Protocol. الملاحظة 72 إطار تحريري لاحق، وليست مصدراً تاريخياً.