الخلاصة

  • وضع RFC 1048 القيمة 99.130.83.99 في أول حقل معلومات المورّد في BOOTP لتختار قواعد تفسير مشتركة. وبعدها تحمل الخانة العادية وسمها وطولها وقيمتها، فيستطيع العميل تجاوز ما لا يعرفه من دون أن يفقد بداية الخانة التالية.
  • لا توثّق cookie الخادم ولا تصدّق العناوين التي يحملها. فحدّ 64 ثمانية ووسما Pad وEnd وتوزيع الأرقام تنظم الشكل والتوافق؛ أما صحة المصدر وحداثة البيانات والإذن بالعمل فتبقى اختبارات أخرى.

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

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

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

العلامة العامة تختار المفسّر ولا تعرّف المتكلم

قيمة magic cookie هي 99.130.83.99 بالعشري، أو 63.82.53.63 بالسداسي عشري، وتُنقل بترتيب بايتات الشبكة. ويقول RFC 1048 إن وظيفتها تعريف النمط الذي ينبغي تفسير البيانات التالية وفقه.

عند رؤيتها يختار العميل مفسّر RFC 1048 بدلاً من تخطيط خاص بمورّد. هذه شهادة عن التمثيل فقط. القيمة ثابتة ومعلنة، يستطيع أي مرسل نسخها. لا تثبت هوية خادم BOOTP، ولا سلامة عبور المكرر، ولا حق المرسل في الإعلان عن موجّه أو خادم أسماء.

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

عبّر RFC 1542 لاحقاً عن الخطر بوضوح: لا يملك BOOTP آلية معقولة للتوثيق، ويمكن لخادم غير مصرح له أن يقدّم عنوان IP أو موجّهاً أو DNS زائفاً. لا يحتاج الرد الضار إلى كسر القواعد؛ يمكن أن يكون مثالياً من جهة الوسوم والأطوال.

الطول يحصر أثر ما لا يعرفه العميل

بعد cookie، تتكون الخانة العادية من ثمانية للوسم، وثمانية للطول، ثم عدد من ثمانيات القيمة يساوي ذلك الطول. لا يدخل الوسم والطول في الحساب. وتُرسل الأعداد متعددة الثمانيات بترتيب الشبكة.

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

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

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

Pad وEnd يحددان أين لا توجد قيمة

الوسم 0، Pad، يحتل ثمانية واحدة ولا يحمل طولاً. يستخدم للمحاذاة أو الفراغ. والوسم 255، End، يحتل ثمانية واحدة أيضاً وينهي سلسلة الخيارات؛ ثم تملأ الأصفار ما بقي.

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

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

إذن فالقواعد الصغيرة أوسع من اختصار TLV: cookie، وخانات عادية، واستثناءان بلا طول، وترتيب ضروري، ونهاية صريحة. تكمن قابلية التشغيل البيني في هذه التفاصيل التي تمنع القراءة الخاطئة.

المساحة الثابتة تفرض سياسة للاختيار

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

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

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

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

إدارة الجدول ليست توثيقاً للخدمة

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

من يدير قاعدة BOOTP يقرر ما ينشره خادم الإقلاع المحلي. لا يثبت هذا التحكم هوية خادم الملفات المذكور ولا سلامة الصورة التي يقدمها. يقول RFC 1048 إن قاعدة BOOTP وحدها لا تكفي للتوثيق القوي لخادم الملفات؛ على الخدمة أن تحل ذلك في مستواها.

تتكون عملية الإقلاع من سجلات منفصلة: الرسالة قابلة للقراءة بقواعد معروفة؛ الرد مرتبط بمحاولة؛ مسار خادم قدّم القيم؛ خدمة لاحقة قبلت العملية أو رفضتها بشروطها. جمعها تحت عبارة «cookie صحيحة» يخفي موضع الخطأ والجهة المسؤولة.

يوصي RFC 1542 بأن يرسل العميل cookie حتى إن لم يرسل خيارات، ثم End وأصفار الملء، كي يعرف الخادم تنسيق الرد المتوقع. هذا تفاوض عن القواعد بمحتوى شبه فارغ، وليس سراً يمنح الثقة.

ورث DHCP الوعاء ولم يرث ضماناً

استخدم RFC 1533 تنسيق امتدادات BOOTP لخيارات DHCP: وسم وطول وقيمة، مع Pad وEnd كاستثناءين. أبقى cookie وترتيب الشبكة والمدى المحلي. ثم وثّق RFC 2132 مجموعة أوسع من خيارات DHCP في السلالة نفسها.

هذه سلالة موثقة للتنسيق، وليست دليلاً على أن ممارسات DHCP اللاحقة كانت موجودة في شبكة BOOTP سنة 1988، ولا على بقاء كل الدلالات كما هي. ويقول RFC 1533 صراحة إنه لا يناقش مسائل الأمن. استمر الوعاء، ولم تصبح سلطة المصدر خاصية فيه.

كان إنجاز RFC 1048 محدوداً وقابلاً للتحقق: تحدد أربع ثمانيات طريقة القراءة، وتحفظ الأطوال حدود المجهول، ويضبط Pad وEnd الحركة، ويمنع الحد الصغير الطموح غير المقيد. أما الهوية والحداثة والإذن ونجاح الخدمة فظلت خارج سلطة cookie.

المصادر وحدود الإثبات

يصف RFC 951 BOOTP الأصلي وحقل 64 ثمانية واقتراح الرقم السحري. ويحدد RFC 1048 cookie والقواعد والترتيب والتخصيص والحجم. ويسجل RFC 1084 وRFC 1497 مراجعات الامتداد. ويبين RFC 1533 وRFC 1542 وRFC 2132 انتقال الشكل إلى DHCP وحدّ أمن BOOTP.

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