الخلاصة

  • لم يكن Configure-Ack مكاناً لتحسين الطلب أو إعادة ترتيب خياراته؛ كان يجب أن يطابق آخر Configure-Request في المعرّف والترتيب والمحتوى، حتى تصبح الموافقة دليلاً قابلاً للفحص بايتاً بايتاً.
  • كان اتفاق LCP ثنائي الاتجاه. يقترح Nak قيماً مقبولة، ويوقف Reject التفاوض على خيار بعينه، ولا تبلغ الحالة Opened إلا بعد إرسال Ack واستلام Ack آخر.

نعمٌ غيّرت رقماً لم تعد نعمًا

لنفترض أن الطرف أ يحدد أكبر إطار يستطيع استقباله. يفهم الطرف ب خيار Maximum-Receive-Unit، لكنه يرى أن رقماً قريباً أنسب، فيضعه داخل Configure-Ack. تبدو الاستجابة حلاً وسطاً مهذباً، لكنها غير صالحة في PPP.

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

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

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

الاقتراح البديل والرفض احتاجا لغتين مختلفتين

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

لا يعدّل Nak الطلب القائم. على صاحب الطلب أن يقرر هل يرسل Configure-Request جديداً، وبمحتوى ومعرّف جديدين. ولا تصبح القيمة المقترحة نافذة إلا إذا عادت في طلب صريح ثم حصلت على Ack مطابق.

أما Configure-Reject فيرسم حداً أصلب. فالخيار غير معروف، أو غير منفذ، أو لا تسمح الإدارة المحلية بالتفاوض عليه. ينسخ Reject الخيار المرفوض، بدلاً من اختراع بديل، وعلى المحاولة التالية أن تحذفه. والخيار المنطقي الذي لا يحمل قيمة بديلة يُرفض ولا يُقابل بـNak.

وهكذا وزع البروتوكول السلطة بين ثلاثة أفعال: Ack يثبت قبول ما طُلب، وNak يصف مساحة ممكنة، وReject ينفي وجود تلك المساحة. ولا يمنح أي منها النظير حق تغيير شرط محلي بصمت.

حمل السلك الواحد تفاوضين

ما لم ينص خيار بعينه على غير ذلك، تعمل خيارات LCP في اتجاه واحد، وغالباً ما تصف استقبال مُرسل Configure-Request. يشرح أ إلى ب كيف يستطيع أ الاستقبال من ب؛ ثم يرسل ب طلباً مستقلاً عن استقباله من أ.

قد يتقاطع الطلبان. ربما حصل أ على Ack لطلبه، بينما لم يحسم بعد هل يجيب طلب ب بـAck أو Nak أو Reject. سمّى RFC 1171 هذه الحالة Ack-Received: وصلت موافقة، لكن الموافقة المقابلة لم تُرسل. لا تصنع موافقة اتجاه واحد موافقة في الاتجاه المعاكس.

ثم حدد RFC 1331 عتبة الفتح بوضوح: تنتهي مرحلة إنشاء الوصلة عندما يكون Configure-Ack قد أُرسل واستُلم. لا تكفي إشارة الحامل المادي ولا Ack واحد لكي يعلن طرف منفرداً أن وصلة PPP كلها مفتوحة.

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

غياب الخيار كان يعني القيمة الافتراضية

لا تسرد Configure-Request كل قدرات الجهاز؛ بل تسرد التغييرات المطلوبة على القيم الافتراضية. ويوصي RFC 1661 بعدم إدراج الخيار إذا كان يحمل قيمته الافتراضية. لذلك لا يعني الغياب جهلاً، بل استمرار قاعدة معلومة.

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

تُفحص خيارات الطلب معاً. يقبل Ack القائمة المرتبة كاملة، ويعرض Nak القيم المختلف عليها فقط، ويعيد Reject ما خرج من التفاوض. هكذا يبقى الرد ذا حدود ذرية، من دون إجبار الجهاز على كشف كل قدراته أو تمكينها.

بقيت لغة التحكم مقروءة أثناء الخلاف على الضغط

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

حافظ RFC 1548 وRFC 1661 على طريق ثابت: تُرسل حزم LCP الخاصة بالتكوين والإنهاء وCode-Reject كما لو لم يُفعّل أي خيار. ولا يُطبق عليها ضغط حقول Address أو Control أو Protocol.

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

للصمت والمساومة التي لا تنتهي حد

تستخدم Configure-Request مؤقت Restart وعداداً لأن الوصلة قد تفقد الحزم. يجب أن يكون Max-Configure قابلاً للضبط، ويوصي RFC 1661 بعشر محاولات افتراضياً. نفاد العداد سبب محلي لإيقاف المحاولة، لا برهاناً تلقائياً على هجوم أو انقطاع مادي.

وقد تصل الردود من دون تقارب. يعد Max-Failure رسائل Nak المتوالية، والقيمة الموصى بها خمس. بعد ذلك تتحول رسائل Nak اللاحقة إلى Reject، ويتوقف الطرف عن إضافة الخيارات التي يرغب محلياً في فرضها. إذا لم تُقرّب الاقتراحات المواقف، يضيق مجال التفاوض بدلاً من احتلال آلة الحالات إلى الأبد.

فتح LCP لم يكن فتحاً لـIP

ظهرت رموز التكوين الأربعة في RFC 1134 في نوفمبر 1989، واستمرت عبر RFC 1171 وRFC 1331 وRFC 1548 حتى معيار الأساس RFC 1661 في يوليو 1994. وخلال ذلك اتضحت المراحل المنفصلة.

تعلن الطبقة السفلى أولاً أن المسار المادي متاح. يفاوض LCP المعلمات المستقلة عن طبقة الشبكة. وإذا اختير بروتوكول مصادقة تأتي المصادقة بعد إنشاء الوصلة. ثم يفتح Network Control Protocol كل بروتوكول شبكة على حدة. لا يُسمح بحركة IP لمجرد رؤية Ack في LCP.

إذن لا يثبت Configure-Ack هوية، ولا نجاح المصادقة، ولا عنوان IP، ولا مساراً أو تطبيقاً متاحاً. يثبت فقط أن مرسل الرد قبل اقتراح LCP محدداً كما هو.

وما زال سجل PPP لدى IANA يخصص الأرقام 1 إلى 4 لـRequest وAck وNak وReject، ويحافظ على فضاء الخيارات. يثبت السجل مفردات مشتركة، لا انتشاراً حالياً ولا صحة كل تنفيذ.

جعل الاتفاق المحدود الاختلاف قابلاً للتشغيل

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

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

المصادر وحدود الاستنتاج

توثق RFC 1134 وRFC 1171 وRFC 1331 وRFC 1548 وRFC 1661 التطور والصيغ والحالات وحدود التقارب، ويوثق سجل IANA التخصيصات الحالية. لا تقيس هذه المصادر الانتشار المعاصر أو امتثال الشركات أو الأداء أو ممارسة المشغلين أو مهلة تشغيلية واحدة. وقراءة المطابقة بوصفها سلطة ثنائية محدودة استنتاج تحريري من الآلية.