الخلاصة

  • وصول PPP إلى طور بروتوكول الشبكة ووصول IPV6CP إلى Opened شرطان محليان لازمان، لا إيصالاً بوجود عنوان عالمي صالح للاستخدام.
  • إيقاف اكتشاف تكرار العنوان العالمي يعتمد على شرطين طوبولوجيين مستقلين لا يظهران في Configure-Ack ويجب إثباتهما باستمرار.

في مراجعة ضمان، يقدم فريق الوصول سجلاً قصيراً: تفاوض المعرف، وصل IPV6CP إلى Opened، ولم يظهر خطأ. ويُطلب من المراجع أن يستنتج أن IPv6 العالمي كان آمناً ومتاحاً.

السجل صحيح، لكن الاستنتاج يطلب منه أكثر مما يحتويه.

يعرّف RFC 5072 نقل IPv6 فوق PPP وبروتوكول التحكم IPV6CP. قبل تبادل أي حزمة IPv6 يجب أن يدخل PPP طور بروتوكول الشبكة وأن يبلغ IPV6CP حالة الفتح. هذه بوابة ترتيب ضرورية. لا تنشئ وحدها عنوان unicast عالمياً ولا تثبت مساراً أو جواباً من الطرف البعيد.

الخيار الذي يعرفه المستند هو Interface-Identifier بطول 64 بت. يحمل كل Configure-Request نسخة واحدة. إذا كانت القيمتان غير صفريتين ومختلفتين يمكن إرسال Ack. وإذا تطابقتا يأتي Nak باقتراح آخر. وإذا كانتا صفراً ينتهي التفاوض بـ Reject. ما ثبت هو اختلاف الطرفين داخل وصلة نقطة إلى نقطة بعينها.

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

يستخدم الطرف المحلي المعرف المتفاوض عليه لصنع عنوان link-local. ثم ينبه RFC 5072 صراحة إلى عدم افتراض استخدام المعرف ذاته في العناوين العالمية. يستطيع النظير توليد معرف أو أكثر لها. لهذا لا يكفي سجل IPV6CP للإجابة عن العنوان العالمي الذي رُكّب لاحقاً.

يظهر الفرق في Duplicate Address Detection. بالنسبة إلى عنوان link-local المبني من معرف فاوض عليه الطرفان، يصبح DAD زائداً داخل الوصلة. أما العنوان العالمي فلا يجوز اعتبار الفحص زائداً إلا إذا تحقق شرطان معاً.

يجب أن تكون البادئة التي يعلنها موجه الوصول حصرية لوصلة PPP نفسها. ويجب ألا يكوّن الموجه المنهي عنواناً عالمياً لنفسه من تلك البادئة. عندئذ فقط يوصي RFC 5072 بأن تضبط الإدارة DupAddrDetectTransmits على صفر.

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

يضع RFC 4862 الأصل العام: يجب تنفيذ DAD على عناوين unicast قبل إسنادها، سواء جاءت من SLAAC أو DHCPv6 أو ضبط يدوي، مع استثناءات معلنة. كما يعرف القيمة صفر بأنها عدم تنفيذ DAD. لذا يحتاج الاستثناء إلى رقابة بديلة قابلة للتدقيق.

وللعنوان العالمي مساران مختلفان. في المسار عديم الحالة يجمع المضيف بادئة Router Advertisement مع معرف. وفي المسار ذي الحالة يحصل على العنوان من خادم مثل DHCPv6. إعلان البادئة ليس منحاً، والمنح ليس تركيباً على الواجهة، والتركيب ليس مساراً أو وصولاً.

تغيرت توصية توليد المعرف لاحقاً. يحدث RFC 8064 RFC 5072 رسمياً، ويوصي بطريقة RFC 7217 المعتمة دلالياً للعناوين المستقرة المولدة بـ SLAAC، ويحذر من تضمين عنوان ثابت لطبقة الوصلة. لكن تحديث المعيار لا يثبت تطبيقه في جهاز محدد.

ولا يساوي فتح IPV6CP توثيق النظير. يعرض RFC 5072 قوائم القبول والمصادقة والتشفير كحمايات منفصلة، وينبه إلى إمكان إعادة تشغيل طريقة مبنية على MD5. يمكن أن ينجح التحكم في IPv6 وتبقى الهوية أو الصلاحية غير محسومة.

ينبغي لإيصال التفعيل أن يحفظ على حدة: حالة LCP؛ نتيجة المصادقة والتخويل؛ رسائل IPV6CP وAck/Nak/Reject؛ معرفي الطرفين وطريقة توليدهما؛ عنوان link-local؛ طريقة الحصول على العنوان العالمي والبادئة والعمر؛ نتيجة DAD أو دليل الشرطين؛ العنوان والمسار المركبان؛ مصدر الحزمة المرصودة؛ رد الطرف؛ ونتيجة التطبيق.

هذه توصية تشغيلية وليست شرطاً خفياً في RFC. وهي تطبق فصل طبقات الواقع لدى Heng Lu: نية الضبط، وحالة التحكم، وحالة العنوان، والحزمة المرصودة، والنتيجة المهنية حقائق مترابطة لا حقيقة واحدة.

Sources