الخلاصة

  • فصلت RFC 2516 بين مرحلة اكتشاف بلا حالة جلسة وبين جلسة PPP من نقطة إلى نقطة؛ ولم يخصص المضيف ومُركِّز الوصول موارد الواجهة الافتراضية إلا بعد إنشاء الجلسة.
  • أتاح AC-Cookie اختياري للمُركِّز اختبار ما إذا كانت قيمة أرسلها إلى عنوان مصدر ستعود إليه. أما Host-Uniq وRelay-Session-Id فخدما نطاقين مختلفين للربط، يملكهما المضيف والمرحل على التوالي.
  • تحمل هذه الوسوم المعتمة سياقاً محدوداً للحزمة؛ ولا يثبت أيّ منها هوية شخص أو إعداد PPP لاحقاً أو مرور البيانات أو تقديم خدمة تجارية.

بثٌّ من دون جدول جلسات

في فبراير 1999، وصفت RFC 2516 كيفية نقل PPP عبر Ethernet مشتركة بين مضيفين ومُركِّزات وصول عدة. بثّ المضيف رسالة PADI؛ وكان بوسع المُركِّز القادر على خدمته أن يرد برسالة PADO. يختار المضيف عرضاً ويرسل PADR أحادية الوجهة إلى المُركِّز الذي اختاره، ثم تؤكد PADS الخدمة المقبولة وتمنح معرّفاً للجلسة. فصلت المواصفة بوضوح بين الاكتشاف وجلسة PPP: يظل الاكتشاف بلا حالة جلسة حتى تنشأ الجلسة. عندئذ يجب على المضيف والمُركِّز كليهما تخصيص موارد لواجهة PPP افتراضية.

منعت هذه الحدود كل طلب ظاهر على شبكة مشتركة من التحول تلقائياً إلى التزام طويل الأمد بموارد الجلسة. ولا تعني عبارة «بلا حالة» أن معالجة الحزم لا تستهلك أي حساب؛ بل تحدد متى تنشأ الحالة الأشد دواماً الخاصة بجلسة PPP مختارة.

كان على القيمة أن تعود

يمكن للمُركِّز أن يضيف وسم AC-Cookie اختيارياً إلى PADO. ويجب على المضيف أن يعيده من دون تغيير في PADR، من غير أن يفسر محتواه. أوصت RFC بأن يستطيع المُركِّز إعادة توليد القيمة اعتماداً على عنوان المصدر في PADR. وبذلك يمكنه اختبار ما إذا كان العنوان الذي تلقى العرض قادراً على إعادة القيمة، ثم الحد من عدد الجلسات المتزامنة لذلك العنوان.

تذكر المواصفة مثالاً هو HMAC لعنوان MAC الخاص بالمضيف بمفتاح لا يعرفه إلا المُركِّز. لكنها لا تفرض هذه الخوارزمية ولا تعد بحماية شاملة؛ بل تقول صراحة إن ملف الارتباط لا يمنع جميع هجمات حجب الخدمة. إنه يؤخر التزام الموارد إلى حين عودة القيمة، ولا يحدد الشخص وراء عنوان الشبكة.

لكل من الوسوم الأخرى صاحب مختلف. يختار المضيف Host-Uniq كي يربط الرد بطلبه؛ ويعيده المُركِّز من دون تفسير. وقد يضيف مرحّل وسيط Relay-Session-Id، وهو معتم للطرفين ويجب أن يعود كما هو. إن ربط الحزم لا يحولها إلى هوية.

تغيّر PADS حالة الموارد

تتضمن PADS المقبولة SESSION_ID غير صفري واسم الخدمة المقبولة؛ أما رفض اسم الخدمة فيستخدم معرّفاً صفرياً ووسم خطأ. وتُعرّف جلسة PPPoE باجتماع عنوان MAC للمصدر وعنوان MAC للوجهة وSESSION_ID؛ فلا يكفي الرقم ذو 16 بتاً وحده.

تنقل PADS الاتصال إلى مرحلة جلسة PPP، لكنها لا تنفذ تفاوض LCP أو المصادقة الاختيارية أو إعداد بروتوكولات التحكم الشبكي التي تشرحها RFC 1661. ولا تعيد هذه المقالة موضوع حجم الحمولة وحد 1492 بايت الذي تتناوله RFC 4638 المجاورة؛ موضوعها توقيت تخصيص الموارد ونطاق ثلاثة وسوم مختلفة، لا إثبات تسليم خدمة لاحقة.

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

المصادر: RFC 2516؛ RFC 1661؛ RFC 2104؛ RFC 4638 (موضوع حمولة مجاور ومستبعد هنا).