التصريح قبل التأويل: كيف استعار DHCP حقول الإقلاع القديمة

الخلاصة

• يعلن الخيار 52 استخدام file أو sname أو كليهما لحمل خيارات DHCP. إعادة الاستعمال محددة بالرسالة والحقول المختارة، وليست إذناً بتأويل أي مساحة مجهولة.
• استعارة مساحة إضافية لا تحل وحدها حد طول الخيار الواحد. يحدد RFC 3396 كيف تُجمع أجزاء الرمز نفسه وفق الترتيب المنطقي options ثم file ثم sname.
• تبقى حدود الحقول قائمة، ويمكن نقل معلومات الإقلاع القديمة إلى خيارات مخصصة. صحة التجميع لا تثبت ثقة الإعداد ولا تعني أن البرامج القديمة تبنت القاعدة الجديدة.

أين يوضع الإذن بتغيير القراءة؟

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

حل DHCP المشكلة بوضع تصريح Option Overload في منطقة options العادية. يقرأ المستقبل تلك المنطقة أولاً، ثم يفسر file إن كان مختاراً، وبعده sname إن كان مختاراً. هذه هي القاعدة التي يثبتها RFC 2131، المنشور في مارس 1997.

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

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

حقول الأسماء لم تكن فراغاً بلا وظيفة

في سبتمبر 1985 وصف RFC 951 بروتوكول BOOTP لمساعدة جهاز لم تكتمل بيئته التشغيلية على معرفة عنوان وخادم وملف إقلاع. احتوى التنسيق الثابت على مواضع واضحة لهذه المعلومات.

كان sname بطول 64 ثمانية بتات للاسم الاختياري للخادم، وfile بطول 128 لاسم ملف الإقلاع، وكلاهما سلسلة تنتهي بصفر. وكانت vend مساحة من 64 ثمانية بتات لمعلومات خاصة بالمورّد.

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

احتفظ DHCP بالهيكل وأضاف خدمة إعداد أوسع. جعل RFC 2131 منطقة options متغيرة الطول، وألزم العملاء بالاستعداد لاستقبال منطقة خيارات لا تقل عن 312 ثمانية بتات، مع آلية أخرى للتفاوض على رسائل أكبر. هذا يختلف عن الحد الأقصى لبيانات ظهور واحد لخيار، وهو 255 بايتاً بسبب حقل الطول ذي البايت الواحد.

الإعلان كان موجوداً قبل مواصفة الخيارات الطويلة

عرّف RFC 1533، الصادر في أكتوبر 1993، Option Overload بالفعل. رمزه 52 وطول بياناته بايت واحد. تعني القيمة 1 استخدام file، والقيمة 2 استخدام sname، والقيمة 3 استخدام الاثنين.

إذن، لم تبدأ الفكرة في 2002 مع قواعد التجزئة والضم، ولا في مراجعات 1997 وحدها. التسلسل التاريخي يفرق بين السماح باستعمال مواقع إضافية وبين توضيح كيفية استعادة قيمة موزعة بين عدة ظهورات.

التصريح خاص بالحقول المحددة في الرسالة الحالية. لا يغير معاني جميع الرسائل المقبلة ولا يضم حقلاً غير مختار لأن المساحة الأخرى ضاقت. ويجب أن يبقى في options العادية حتى يسبق التأويل الذي يغيره.

بهذا تكون الحرية محدودة لكنها مفيدة: يمكن للتنفيذ أن يختار أين يضع المعلمات ضمن الأماكن المسموح بها، بينما يظل اكتشاف هذا الاختيار قابلاً للتحقق عند الطرف المقابل.

الاستعارة لا تهدم الجدران

تبدأ منطقة الخيارات العادية بأربعة بايتات من magic cookie ثم بالعناصر الموسومة. الخيار المتغير المعتاد يتكون من رمز وطول والعدد المحدد من بايتات البيانات؛ الطول لا يشمل الرمز ولا بايت الطول نفسه. أما Pad وEnd فاستثناءان يتكون كل منهما من بايت واحد.

عندما يُستخدم file أو sname للخيارات، تبدأ الخيارات عند أول بايت من الحقل، من دون نسخة إضافية من cookie. ويجب إنهاء الخيارات في كل حقل مستخدم بعلامة End، ثم ملء الباقي بـPad. كل ظهور مشفّر لخيار يجب أن يبقى كاملاً داخل حقل واحد.

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

يبلغ مجموع file وsname مقدار 192 بايتاً من المواضع الخام، لكنه ليس 192 بايتاً مفيداً مضموناً. الرموز والأطوال والنهايات والحشو والتصريح والمعلومات المنقولة من مواضعها القديمة تستهلك جزءاً منه. هذه إعادة استعمال محدودة، لا توسيع بلا نهاية ولا تجزئة IP باسم آخر.

الاسم يستطيع مغادرة مكانه القديم

يعرّف RFC 2132، من مارس 1997، الخيار 66 لاسم خادم TFTP عندما يكون sname مستخدماً للخيارات، والخيار 67 لاسم ملف الإقلاع عندما يُعاد استخدام file.

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

يسجل سجل BOOTP/DHCP لدى IANA هذه الرموز، ومعها Domain Search ذي الرمز 119. هي أرقام خيارات، لا منافذ نقل. تشابه الرقم 67 مع منفذ UDP المستخدم لخادم DHCP لا يجعل الخيار والمنفذ شيئاً واحداً.

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

قد يكون الاسم قصيراً ولا يتسع له موضعه

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

عالج Ted Lemon وStuart Cheshire الحالتين في RFC 3396، الصادر في نوفمبر 2002. وحذف النص صراحة الجملة في RFC 2131 التي كانت تقيد تكرار الخيار افتراضياً، ووضع قواعد التجزئة والضم بصورة محددة.

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

مثال الوثيقة هو المسار /diskless/foo، بطول 13 بايتاً، مقسوماً إلى سبعة وستة. يقع القطع داخل diskless، لا عند فاصل ذي معنى في المسار. ليس للموضع الذي اختاره المرسل دلالة مستقلة؛ المعنى يأتي بعد استعادة القيمة الكاملة.

لذلك ليست إعادة استعمال الحقول مرادفاً لتقسيم الخيارات. يمكن للحقول المستعارة حمل خيارات كاملة، ويمكن لقيمة مقسومة أن تبقى كل أجزائها في options العادية. إحدى الآليتين تحدد المواضع، والأخرى تحدد كيفية استعادة الكل من ظهورات متعددة.

ترتيب التجميع ليس ترتيب الوصول إلى البايتات

في التخطيط الموروث، يسبق sname حقل file، ويسبق الاثنان options. لكن المخزن المنطقي المجمع في RFC 3396 يتبع options ثم file ثم sname، مع استبعاد الحقول التي لم تُحدد للاستعارة.

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

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

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

معرفة قدرة الطرف الآخر بقيت مسؤولية تشغيلية

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

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

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

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

إحداثيات لا توجد إلا بعد إعادة الكل

في الشهر نفسه عرّف RFC 3397 خيار البحث في النطاقات، ذي الرمز 119. يمكن لقائمة البحث DNS أن تمتد عبر عدة ظهورات، وتستخدم ضغط الأسماء لتقليل تكرار اللواحق.

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

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

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

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