ما الذي يتفاوض عليه IPv6CP، وما الذي لا يزال يحتاج إلى بادئة
العنوان المحلي للرابط على واجهة PPP خطوة إعداد، وليس وصولاً إلى IPv6. افصل تبادل المعرّفات عن البادئات والمسارات وتكامل العميل.
يُشغَّل IPv6 على واجهة PPP، ويظهر عنوان محلي للرابط، فيُعلن أن التغيير قد اكتمل. ثم لا يوجد أي توجيه، ولا يوجد عنوان عام، ويفشل اختبار نحو وجهة عامة بينما تبدو الواجهة مهيأة. الرابط قام، أما الشبكة فلم تقم. نفّذ الفحوص الأربعة أدناه بالترتيب وتوقف عند الفحص الذي يفسر الفجوة.
ما الذي يثبته العنوان المحلي للرابط فعلاً
يرفع IPv6CP بروتوكول IPv6 على رابط PPP ويتفاوض على معرّف واجهة لكل طرف. ينتج عن ذلك المعرّف عنوان محلي للرابط، وهو كافٍ للتواصل مع النظير عبر الرابط وغير كافٍ للوصول إلى أي شيء آخر. يثبت العنوان أن الرابط جاهز لـIPv6، ولا يثبت شيئاً عن الشبكة خلف النظير. قراءته كعنوان وصول هي الخطأ الذي يبدأ معظم هذه التحقيقات.
تفصل الأسئلة الأربعة أدناه ما تحسمه طبقة الرابط عما يجب أن توفره الخدمة. أجب عنها بالترتيب، لأن السؤال اللاحق لا يمكن الإجابة عنه بينما يبقى سؤال سابق مفتوحاً.
| Question | Answered by | What it does not settle |
|---|---|---|
| Is IPv6 up on the link? | IPv6CP: interface identifiers, then link-local addresses | Any address reachable beyond the peer |
| Where does a global prefix come from? | Router advertisement, delegated prefix, DHCPv6 or static configuration | IPv6CP carries no prefix of its own |
| Who owns the routes? | The client's tunnel configuration and the server's return path | A link-local address implies no route at all |
| How does this client get configured? | Explicit tunnel settings or router advertisements, depending on the client | The standard does not choose for the implementation |
من أين يجب أن تأتي البادئة
يحتاج العنوان العام إلى بادئة من مكان ما: إعلان موجّه، أو بادئة مفوّضة، أو DHCPv6، أو إعداد ثابت. لا يحمل IPv6CP بادئة، ولن ينتج عنها انتظار على الرابط. يضع RFC 5072 بروتوكول IPv6CP كخطوة الإعداد التي تعمل قبل أن تعمل بروتوكولات IPv6 الأخرى على الرابط، وهذا هو نطاقه كله: تهيئة الرابط، لا ترقيم الشبكة. وفّر البادئة وتبدأ الواجهة بحمل الحركة بدلاً من مجرد الوجود.
إعلانات الموجّه هي الجواب الشائع على شبكة محلية، وهي أقل موثوقية على نفق نقطة إلى نقطة، لأن العميل عليه أن يرسل الطلبات ويقبل الجواب معاً. بعض عملاء الأنفاق لا يفعلون أياً منهما. تحقق مما يقبله العميل قبل أن تقرر أن يرسله الخادم.
يجب أن تكون البادئة نفسها قابلة للوصول من الطرف الآخر. العميل الذي يحمل عنواناً عاماً بلا مسار عودة مهيأ، لا متصل.
المسارات وعد منفصل
حتى مع وجود عنوان، يحتاج العميل إلى معرفة الوجهات التي تنتمي إلى النفق، ويحتاج الخادم إلى مسار عودة لتلك الوجهات. وهذا قراران يُتخذان في مكانين. النفق الذي يحمل كل حركة IPv6 يحتاج مساراً افتراضياً على العميل ومسار عودة على الخادم؛ والنفق المنفصل يحتاج أن يتفق الطرفان على قائمة البادئات نفسها. عندما يختلفان، تخرج الحركة ولا تعود أبداً.
اكتب القائمة قبل إعداد أي شيء. إذا قال الخطة إن بادئة الشركة وحدها تمر في النفق، فلا يجب أن يكون للعميل مسار IPv6 افتراضي، ولا يجب أن يعلن الخادم واحداً.
تكامل العميل يحدد الباقي
بعض عملاء الأنفاق يهيئون IPv6 صراحةً. يأخذ Network Extension من Apple، مثلاً، عنواناً وبادئة ومجموعة مسارات للنفق، فلا ينتظر تطبيق يستخدمه إعلاناً على نمط Ethernet. ويعتمد آخرون على إعلانات الموجّه الواصلة عبر الرابط. النموذجان مشروعان ويحتاجان سلوك خادم مختلفاً، واختيار النموذج الخطأ ينتج عميلاً ينتظر إلى الأبد رسالة لا يرسلها أحد. حدد النموذج قبل تغيير الخادم.
اسم واجهة قديم مثل ppp0 لا يثبت شيئاً عن الحزمة العاملة اليوم. قد يستخدم عميل حديث واجهة برمجة نفق الحزم بدلاً من واجهة PPP، والافتراض بأنه يتصرف كاتصال تاريخي هو كيفية كسر تصميم عامل. اسأل عن إصدار العميل وطريقة التزويد، لا عن اسم الواجهة.
اكتب الخطة التي يحتاجها العميل
يغطي الوصف الكامل ثلاثة أشياء: العنوان الذي يحمله العميل، والوجهات التي يجب أن يحملها النفق، وكيف ترسل الشبكة الردود. العنوان المحلي للرابط لا يجيب عن أي منها، والإعلان المقبول يجيب عن جزء واحد فقط. افحص كل بند على حدة بدلاً من قبول مؤشر أخضر. ثم سجّل أي آلية وفرت كل جواب، لأن ذلك السجل يحول تقرير IPv6 التالي إلى فحص من دقيقتين.
احتفظ بالسجل مع توثيق الخدمة وحدّثه عندما يتغير العميل. الخطة التي كانت صحيحة لعميل PPP قد تكون خاطئة لعميل نفق حزم على الخدمة نفسها. تبقى الأسئلة الأربعة كما هي؛ والجواب فقط يتحرك.