الخلاصة

  • تسمح RFC 9928 لوكيل 4o6RA بتغليف رسائل DHCPv4 داخل DHCPv6 وفكها نيابة عن عميل IPv4 قديم لا يدرك وجود الآلية.
  • نقل وظيفة 4o6 إلى عقدة وسيطة قد يحجب مقطع الطبقة الثانية عن اكتشاف طوبولوجيا DHCPv6. توصي الوثيقة ببنية متجاورة تجمع 4o6RA وLDRA، لكنها تترك تبادل معلومات الواجهة بينهما خارج النطاق.
  • يثبت العقد الناجح أن الخادم خصص إعداداً وأن الرد عاد إلى العميل. ولا يثبت بمفرده منفذ الدخول، أو الخريطة المحلية لقيمة Interface-ID المعتمة، أو قاعدة الخادم التي طُبقت، أو غياب مسار DHCPv4 مباشر.
  • ينبغي لإيصال العهدة أن يربط الملاحظة عند الدخول، والتغليف، وترتيب المرحلات المتداخلة، وقرار الخادم، والتسليم إلى المنفذ الأصلي، وكشف التجاوز، والانتهاء أو التصحيح.

نجاح ظاهر مع حلقة مفقودة

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

حددت RFC 7341 نقل DHCPv4 عبر DHCPv6 عندما يستطيع العميل نفسه تنفيذ التغليف. لا يملك الجهاز غير القابل للترقية هذه القدرة. لذلك تنقل RFC 9928 الوظيفة إلى DHCPv4-over-DHCPv6 Relay Agent.

يتلقى 4o6RA رسالة DHCPv4، وينشئ DHCPV4-QUERY، ويرسلها عبر المسار الداعم لـDHCPv6. وعند وصول DHCPV4-RESPONSE سليم، يستخرج رد DHCPv4 ويسلمه إلى العميل الطالب. تنص الوثيقة صراحة على أن العميل القديم لا يعلم أنه يستخدم خدمة DHCP 4o6.

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

الموقع جزء من مدخلات التخصيص

توضح RFC 7969 أن خادم DHCP قد يخصص العناوين والمعلمات بحسب معلومات الطوبولوجيا التي توفرها بنية الترحيل. يعرف المرحل مكان استقبال الطلب الأصلي، ويمكن أن تساعد هذه المعرفة في اختيار المجموعة المناسبة.

لا يمثل DHCPv4 وDHCPv6 المسار بالطريقة نفسها. في DHCPv4 يضبط المرحل الأول عادة حقل giaddr، ولذلك لا ينتقل سوى جزء من مسار متعدد المراحل. أما DHCPv6 فيستطيع تداخل رسائل Relay-forward، وإرفاق link-address وInterface-ID في طبقات متعاقبة.

عندما تُنقل وظيفة 4o6 من العميل إلى عقدة وسيطة، تنشأ رسالة DHCPv6 بعد مقطع الطبقة الثانية. تقول RFC 9928 إن الحل الذي يستخدم 4o6RA وحده لا يضيف معلومات الواجهة إلى الرسالة المغلفة، وبذلك تنقطع طوبولوجيا ذلك المقطع عن الخادم.

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

قيمة Interface-ID تحتاج إلى خريطة محلية

توصي RFC 9928 بجمع 4o6RA مع Lightweight DHCPv6 Relay Agent بصورة متجاورة. يحصل LDRA على معلومات الواجهة المواجهة للعميل ويضع Interface-ID في DHCPV4-QUERY الصاعد.

تلزم RFC 6221 LDRA بإدراج Interface-ID في كل Relay-forward. وينبغي أن تبقى القيمة مستقرة للواجهة نفسها عبر إعادة التشغيل، لأن الخادم قد يستخدم المطابقة الدقيقة في سياسة تعيين المعلمات.

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

تلزم RFC 9915 الخادم بنسخ Interface-ID إلى Relay-reply. يستخدم المرحل القيمة لاختيار واجهة التسليم إلى العميل. وهكذا تشارك القيمة في قرار الذهاب وفي مسار العودة، من دون أن تصادق بذاتها على صحة الربط الفيزيائي المحلي.

الحد الداخلي متروك للتنفيذ

لا تحدد RFC 9928 كيف ينقل 4o6RA معلومات الواجهة إلى LDRA، ولا شكلها الداخلي، ولا ما إذا كانت تشير إلى مشاركة 4o6RA. قد تنفذ منصة الوظيفتين داخل عملية واحدة، بينما تستخدم أخرى عتاد تبديل ووكيل برمجيات وخدمة تحكم.

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

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

مسار التجاوز قد ينتج حالة ثانية معقولة

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

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

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

عشر وصلات في إيصال العهدة

الإيصال المقترح ضبط تشغيلي تحريري، وليس خيار DHCP جديداً ولا شهادة امتثال من IETF.

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

بعد ذلك تُحفظ Interface-ID المعتمة، وطبقة Relay-forward التي ظهرت فيها، وترتيب link-address والمرحلات الذي استخدمته السياسة. يسجل الخادم القاعدة المطابقة، ومجموعة العناوين، والمعلمات المعادة. ويربط جانب العودة تداخل Relay-reply وفك التغليف والتسليم إلى الواجهة الأصلية.

يسجل البند التاسع اختبار التجاوز ونتيجته. ويغلق البند العاشر السجل عند Renew أو Rebind أو انتقال المنفذ أو التصحيح أو الانتهاء أو الرجوع. لا يستطيع سجل خادم منفرد إثبات الدخول الفيزيائي، ولا يستطيع سجل المبدّل إثبات قاعدة التخصيص. قيمة الإيصال في إبقاء الادعاءات منفصلة وقابلة للربط.

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

المصادر