الخلاصة

  • كان على PPP بلوغ مرحلة بروتوكولات الشبكة، ثم على IPv6CP بلوغ Opened؛ حمل التحكم القيمة 0x8057، بينما حملت رزم IPv6 المسموح بها القيمة 0x0057.
  • أثبت اختلاف Interface-Token تمييز طرفي تلك الوصلة فقط. لم يوثق الطرف الآخر، ولم يثبت التفرد العالمي أو ملكية العنوان أو إمكان الوصول أو استلام الرزمة.

تكشف حالة الصفر في RFC 2023 أهمية اسم الرد. إذا طلب طرف رمزاً صفرياً وكان لدى الطرف الآخر رمز غير صفري مختلف، نصت الوثيقة على إرسال اقتراح غير صفري داخل Configure-Ack. غيّرت RFC 2472 هذا الرد إلى Configure-Nak. أعاد التعديل الفصل بين قبول الطلب كما هو واقتراح قيمة بديلة.

فتح وصلة البيانات لم يكن فتحاً لـ IPv6

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

سمت RFC 2023 بروتوكول التحكم الخاص بـ IPv6 باسم IPv6CP. استخدمت رسائله حقل PPP بقيمة 8057، وكان ينبغي إسقاطها قبل مرحلة الشبكة. استخدمت رزم IPv6 القيمة 0057، ولم يسمح بها قبل وصول IPv6CP إلى Opened.

لهذا لا يعني LCP Opened أن IPv6 جاهز. مرحلة الشبكة تسمح ببدء التفاوض ولا تثبت اكتماله. أما IPv6CP Opened فيرفع حاجزاً بروتوكولياً؛ لا ينشئ مساراً ولا يثبت إرسال رزمة.

المقارنة كانت بين اقتراحين محليين

كانت Interface-Token خياراً من النوع 1 بطول ستة ثمانيات وقيمة من 32 بت. يختار كل طرف قيمة مؤقتة قبل Configure-Request. أوصت الوثيقة بجمع مصادر متعددة للاختلاف لأن عنوان طبقة الوصلة وحده قد لا يكون فريداً. عند غياب مصدر جيد، يرسل الطرف صفراً ليطلب اقتراحاً من نظيره.

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

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

لكل رد حد مختلف

يثبت Configure-Ack لقيمة غير صفرية قبول طلب بعينه في اتجاه واحد. لا يكمل الاتجاه المقابل ولا يحدد هوية الطرف. لم تناقش RFC 2023 مسائل الأمن، ولم يكن Interface-Token وسيلة مصادقة.

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

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

القدرة على الاستقبال ليست دليلاً على الاستخدام

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

استبدلت RFC 2472 رمز 32 بت بمعرّف واجهة من 64 بت وصححت رد الصفر. ثم استبدلت RFC 5072 الوثيقة اللاحقة. يحتفظ سجل IANA الحالي بالقيمتين 0057 و8057 لكنه يحيل IPv6CP إلى RFC 5072، ويصف 004f بأنه تاريخي. لذلك تمثل RFC 2023 مرحلة تصميم تاريخية لا تعليمات تشغيل حالية.

حتى مشاهدة إطار 0057 لا تثبت سوى أن إطاراً في نقطة الرصد صُنّف حاملاً لرزمة IPv6. يتطلب إثبات التسليم سجلاً مترابطاً عند الوجهة وفحص سلامة وإقراراً من طبقة النقل أو التطبيق. وتتطلب الهوية والتفويض أدلة مستقلة.

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

المصادر