الخلاصة
- يقترح
draft-ietf-intarea-dhcp-rate-signaling-00نقل معدلات الرفع والتنزيل ونوع الاحتساب عبر DHCP، ويجعل الصفر يعني عدم التقييد أو إزالة حد سابق، لا أن السعة المقاسة تساوي صفراً. - لا بد من حفظ الإشارة الأصلية، وحالتها في التبادل، ومصدرها وهدفها ونوعها وعمرها والحد المحلي والإعداد الفعلي؛ وإلا تحولت أوامر التحكم إلى ادعاءات مضللة عن الخدمة.
يبدأ الخطأ حين تجمع المنصة كل الأرقام في عمود اسمه «السرعة». رقم من ملف المشترك، وآخر في رسالة DHCP، وثالث في إعداد الصف، ورابع من اختبار مرور. الوحدات واحدة، لكن السلطة والمعنى مختلفان.
خيار DHCP Rate الذي تدرسه مجموعة INTAREA يحمل قيمة للرفع وأخرى للتنزيل ونوعاً يميز احتساب الطبقة الثانية عن الثالثة. الغاية هي مساعدة جهاز العميل على وضع shaping وAQM قرب عنق الزجاجة حين تكون وصلة Ethernet أسرع من الخدمة المشتراة. ويمكن للـrelay ومبدّل DHCP snooping استخدام الإشارة أيضاً.
لكن revision 00، المؤرخ في 27 أغسطس 2026 والمنتهي في 28 فبراير 2027، Internet-Draft معلوماتي وليس RFC أو دليلاً على تنفيذ مشغّل بعينه. رموز الخيار والسجلات المطلوبة لم تصبح حقائق نشر نهائية.
الصفر فعل، لا مشاهدة
في معنى هذه sub-options، الصفر يطلب rate غير مقيد أو إزالة limiter سبق تطبيقه والعودة إلى الوضع الافتراضي. لا يقول إن الوصلة اختُبرت وكانت سرعتها صفراً. إذا حوّل نظام التحليلات هذا الحقل مباشرة إلى مقياس أداء، فسيسجل انقطاعاً كاذباً لحظة تنفيذ إزالة صحيحة.
هذه ليست حالة خاصة هامشية. إنها تذكير بأن كل قيمة تحتاج نوع ادعاء. «أرسل الخادم أمراً بالإزالة» غير «أزال الجهاز الحد» وغير «تحسن throughput». ينبغي أن يحمل كل سجل فعله ومصدره وزمنه بدلاً من الاكتفاء بالعدد.
وفي PPPoE، تتقدم إشارة DHCP على rate يصل في رد مصادقة PPP، لكن انتهاء الجلسة يسحب هذه السلطة. الصلاحية جزء من المعنى؛ الأمر القديم ليس تفويضاً دائماً.
العرض قد يؤثر في الاختيار ولا يغير الواجهة
قد يرى العميل الخيار في DHCPOFFER أو ADVERTISE ويستخدمه لاختيار الخادم. لا يجوز له تطبيقه حتى DHCPACK أو REPLY. الرقم المبكر معلومة اختيار، وليس بعدُ إذناً بتغيير الصف.
لذلك عبارة «رأى الجهاز 500 Mbit/s» ناقصة. في أي رسالة؟ هل أعاد الخادم المختار القيمة في الرد النهائي؟ هل غيرها relay؟ وهل lease ما زال صالحاً؟ حفظ آخر رقم فقط يمحو انتقال السلطة.
ويستطيع العميل اقتراح معدل أو نوع طبقة. للخادم أن يقبل أو يرفض أو يحول. اقتراح العميل دليل على طلبه، لا على الباقة التجارية ولا على ما فرضته الشبكة لاحقاً.
relay يستطيع أن يغيّر الحقيقة المنقولة
في DHCPv4 يستطيع relay قراءة الخيار من DHCPACK وإنشاء shaper أو policer محلي. ويمكنه إضافة الخيار أو تعديله أو حذفه بعد الرجوع إلى RADIUS أو مصدر AAA آخر.
حتى لو كان التعديل مشروعاً، تبقى قيمة خرج الخادم وقيمة دخل العميل قطعتين مختلفتين من الدليل. يلزم إيصال للتحويل: هوية relay، وربط الجلسة، وإصدار سجل AAA، والقيمة قبل وبعد، والاتجاه، والنوع، والهدف، والسبب، والعمر.
يقدم RFC 3046 سياق معلومات relay، ويقدم RFC 2865 إطار RADIUS، لكنهما لا يثبتان تلقائياً صلاحية تعديل بعينه. حذف القيمة القديمة لأن الجديدة «هي الفعالة» يمنع تفسير ما وقع.
موضع الخيار داخل DHCPv6 يحدد المخاطَب
يمكن للخادم وضع rate للعميل في REPLY وخيارات أخرى في طبقات RELAY-REPL المتداخلة. قد يتلقى CPE قيمة 480 Mbit/s بينما يتلقى relay قيمة 520 للسماح بهامش burst. الاختلاف ليس تعارضاً حين يختلف الهدف.
على relay استهلاك الخيار الموضوع في غلافه، لا استخراج قيمة من payload الداخلي الموجه إلى العميل. حيازة الحزمة لا تمنح سلطة على كل تعليماتها.
ولهذا لا يكفي تسجيل المشترك والرقم. يجب حفظ مستوى التغليف، والفاعل المقصود، وحالة الرسالة. قيمة صحيحة مطبقة على الهدف الخطأ تظل قراراً بلا تفويض.
النوع المجهول يبطل الأرقام الجذابة
معدل الطبقة الثانية لا يساوي بالضرورة معدل الطبقة الثالثة حتى إن تشابه الرقمان. استخدام نوع خاطئ قد ينقل عنق الزجاجة. يسمح المشروع بتجاهل sub-option code مجهول لدعم التطور، لكنه يطلب رفض الخيار كله إذا حمل حقل معروف وحاسم، مثل rate type، قيمة مجهولة أو reserved.
وتحافظ الحقول المكررة على ترتيبها؛ يعالج الجهاز المثيل الأخير. إذا حولت pipeline السجل إلى مجموعة بلا ترتيب فلن تعيد بناء القرار. وقد ينجح lease بينما يفشل Rate Option وحده. نجاح DHCP ليس دليلاً على نجاح سياسة السرعة.
الرقم نفسه قد يبدّل مصدره
عند تعارض DHCPv4 وDHCPv6 يفضّل المشروع v6 ويشترط حفظ بروتوكول المصدر مع القيمة المطبقة. إذا أعطى كلاهما 500 Mbit/s ثم انتهى lease v6، قد يبقى الرقم على الشاشة بينما تنتقل السلطة إلى v4.
تغيرت عندها هوية الخادم ومسار relay والعمر حتى لو لم تتغير الخانات. وإن لم يبق lease v4 صالح، يعود الجهاز إلى default. مساواة الأرقام لا تعني استمرارية المصدر.
هذا تطبيق مباشر لفكرة Heng Lu عن أولوية running code: لا تُستنتج السلطة من اسم المؤسسة أو من وجود حقل؛ يجب فحص الحالة التي تعمل فعلاً وسلسلة الأوامر التي أنشأتها.
المراقب يصبح منفذاً حين يبرمج العتاد
يمكن لمبدّل DHCP snooping تحويل الخيار المرصود إلى queue أو shaper أو policer. عندئذ لم يعد مجرد watcher. صار actuator يؤثر في مرور المشترك.
التقاط packet يثبت عبور الحقل، لا أنه كان موجهاً للمبدّل أو أن commit نجح. ينبغي ربط نطاق ثقة المنفذ، والجلسة، ومستوى التغليف، والهدف، وسعة الواجهة، والسقف المحلي، ومعاملة الإعداد، وقراءة العتاد بعد التنفيذ.
كذلك قد يرسل الخادم 2 Gbit/s إلى منفذ لا يتجاوز 1 Gbit/s. الإشارة صحيحة كسجل سياسة، والحد المحلي صحيح كتنفيذ. لا يصح استبدال أحدهما بالآخر.
الأمر الصحيح نحوياً قد يكون هجوماً
يعمل DHCP غالباً من دون تشفير أو مصادقة. يستطيع خادم rogue أو مهاجم on-path حقن قيمة منخفضة تخنق الخدمة مع بقاء الاتصال والعنوان سليمين. threshold دنيا تمنع بعض القيم المتطرفة، والسعة الفيزيائية تحد القيم العليا، لكن أياً منهما لا يوثق المصدر.
يصف RFC 3118 مصادقة DHCP، إلا أن وجود المواصفة لا يثبت نشرها. ينبغي التحقق من trusted ports وserver allow-list وسلسلة relay وحماية snooping وربط الجلسة وسلطة بيانات AAA.
يشير المشروع إلى أن gateway مزيفاً أو DNS متلاعباً أو استنزاف العناوين قد تكون أخطر. لا يجعل ذلك التقييد الخبيث مقبولاً؛ بل يوضح أن الحقل يدخل control plane يحتاج أصلاً إلى حدود ثقة قوية.
إيصال التحكم ليس حكماً على latency
معرفة عنق الزجاجة تساعد shaping وAQM. يشرح RFC 7567 ضرر الطوابير المفرطة، ويصف RFC 9330 طوابير L4S الضحلة. لكن تثبيت queue لا يثبت تحسن latency.
يلزم قياس الإعداد الفعلي، وشغل الصف، والعلامات، والإسقاطات، وتوزيع التأخير، وthroughput، والأخطاء، وrollback. الإشارة نية، وcommit فعل، والنتيجة ادعاء لاحق يحتاج دليلاً لاحقاً.
يمكن للمعيار المشترك أن يبقى رفيعاً: الاتجاه، والنوع، والهدف، وحالة الرسالة، والأولوية، والانتهاء، وfallback. لا يستطيع بمجرد ترميز الرقم أن يجعل ملف المشترك صحيحاً أو relay شفافاً أو النتيجة جيدة.
عدم اليقين
قد يتغير المشروع أو يستبدل أو ينتهي. لم تتحقق هذه المادة من تنفيذ لدى مشغّل أو CPE أو relay أو switch أو firmware محدد. منافع الأداء والدعم دوافع مقترحة تتطلب اختباراً مستقلاً في كل بيئة.
المصادر
- https://datatracker.ietf.org/api/v1/doc/document/draft-ietf-intarea-dhcp-rate-signaling/?format=json
- https://datatracker.ietf.org/doc/draft-ietf-intarea-dhcp-rate-signaling/
- https://datatracker.ietf.org/doc/draft-ietf-intarea-dhcp-rate-signaling/history/
- https://heng.lu/minimum-initial-specification-localized-future-decision-voluntary-adoption-internet-coordination-system/
- https://heng.lu/running-code-primary-the-patch-needed-to-preserve-the-internet-original-design/
- https://heng.lu/the-policy-mirror/
- https://www.ietf.org/archive/id/draft-giese-dhcp-rate-signaling-01.txt
- https://www.ietf.org/archive/id/draft-ietf-intarea-dhcp-rate-signaling-00.txt
- https://www.ietf.org/archive/id/draft-ietf-intarea-dhcp-rate-signaling-00.xml
- https://www.rfc-editor.org/rfc/rfc2131.html
- https://www.rfc-editor.org/rfc/rfc2516.html
- https://www.rfc-editor.org/rfc/rfc2865.html
- https://www.rfc-editor.org/rfc/rfc3046.html
- https://www.rfc-editor.org/rfc/rfc3118.html
- https://www.rfc-editor.org/rfc/rfc6221.html
- https://www.rfc-editor.org/rfc/rfc7567.html
- https://www.rfc-editor.org/rfc/rfc8415.html
- https://www.rfc-editor.org/rfc/rfc9330.html
إحاطة الأعضاء
سياق أعمق للملف الشخصي
سجّل الدخول بمستوى العضوية المناسب لفتح الإحاطة الكاملة وملاحظات المصادر.
للدائرة الاستراتيجية فقط
الدائرة الاستراتيجية
مفتوح لجميع القراء. افتح إحاطات الملف الشخصي بعد الانضمام وتسجيل الدخول.
انضم إلى الدائرة الاستراتيجيةلأعضاء تحالف القيادات فقط
تحالف القيادات
لأصحاب الأصول الفكرية المؤهلين وللإدارة؛ سجّل الدخول للوصول إلى إحاطات التحالف.
انضم إلى تحالف القيادات
