الخلاصة

  • يفرض RFC 5121 التفاوض على طبقة تقارب واحدة كحد أقصى لنقل IPv6 على الرابط، لكن هذا الإيصال يثبت طريقة التغليف ولا يثبت البنية الكاملة.
  • عندما يكون موجّه النفاذ بعيداً عن المحطة القاعدية، يشكل النفق لكل محطة أو لكل تدفق، مع اتصالات النقل اللاسلكية، رابطاً واحداً من المحطة إلى الموجّه.
  • يجب أن تفصل الحوكمة بين القدرة والاختيار وتدفق الخدمة وCID والنفق والبادئة وإعلان الموجّه وحالة التعددية وMTU ومسار الحزمة المرصود.

يمكن لمخطط تشغيل أن يرسم خطاً واحداً سميكاً بين المحطة القاعدية وموجّه النفاذ ويسميه «نفقاً عاملاً». هذه العبارة صحيحة من زاوية ضيقة جداً. لا تقول أي محطات حملها الخط، ولا ما إذا بقي سياق كل محطة مستقلاً، ولا أي بادئة ظهرت عند الطرف الآخر. في نموذج RFC 5121، هذه الأسئلة تحدد حقيقة رابط الطبقة الثالثة.

المحطة المتنقلة تتصل بالمحطة القاعدية عبر اتصال أو عدة اتصالات نقل. لكل اتصال معرّف CID، ويمكن أن توجد CIDs متعددة بين الطرفين نفسيهما. إذا كان موجّه النفاذ مدمجاً مع المحطة القاعدية، فإن مجموعة الاتصالات إلى محطة متنقلة واحدة تُعد رابطاً واحداً. أما إذا كان الموجّه منفصلاً، فيوصي النص بنفق لا تتجاوز حبيباته محطة واحدة أو تدفق خدمة واحد. تتحد الأنفاق والاتصالات لتكوين الرابط نقطة إلى نقطة.

الحبيبات تحفظ حدود المسؤولية

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

السجل المفيد يجب أن يعمل في الاتجاهين. من هوية المحطة، يسرد تدفقات الخدمة وCIDs والأنفاق وموجّه النفاذ. ومن أي CID أو حزمة ملتقطة، يعود إلى محطة واحدة وسياق رابط واحد. إن كان النظام يستطيع عد الأنفاق ولا يستطيع إثبات هذه العلاقات، فهو يدير سعة نقل لا حقيقة IPv6.

هذا الفصل لا يعني أن كل CID رابط مستقل. RFC 5121 يصرح بإمكان وجود اتصالات متعددة للمحطة نفسها. الرابط مفهوم في الطبقة الثالثة تحده الموجّهات التي تنقص Hop Limit، وليس نسخة من تعريف رابط IEEE في الطبقة الثانية.

طبقة تقارب واحدة تحل خلاف التغليف فقط

يوفر IEEE 802.16 أكثر من مسار لحمل IPv6، ومنها الجزء الخاص بـIP من Packet CS والمسار المرتبط بـ802.3/Ethernet. يتبادل الطرفان القدرات أثناء التسجيل، ثم تحدد رسائل إضافة الخدمة طبقة التقارب للاتصال المنشأ. نطاق RFC 5121 هو IP CS.

عندما يدعم الطرفان IP CS تكون هي الوضع الافتراضي. وعندما يدعمان IP CS وEthernet CS معاً يجب استخدام IP CS. وعلى رابط واحد يتفاوضان على طبقة تقارب واحدة كحد أقصى. إذا لم يجدا اختياراً مشتركاً، يفشل إنشاء اتصال النقل ولا يستطيع المضيف إرسال IPv6 أو استقباله عبر ذلك المسار.

هذه قاعدة ضرورية لكنها لا تعبر النفق نيابة عن الحزمة. دعم التنفيذ لا يعني أن الوضع ممكّن في الموقع؛ والتمكين لا يعني أنه اختير لهذه الجلسة؛ والاختيار لا يعني أن تدفق الخدمة نجح؛ ونجاح التدفق لا يعني أن المصنف وضع الحزمة في CID الصحيح. حتى اشتراط دعم المحطة القاعدية لكل تغليف Standards Track يسمح بإيقاف بعض الأوضاع في الإعداد.

المصنف هو جزء من سلسلة الإثبات

رأس MAC العام لا يحمل بمفرده دلالة صريحة على نوع الحمولة. تعتمد المعالجة على مصنفات قد تنظر إلى عناوين IPv6 وNext Header وفئة المرور ومجالات المنافذ، ثم تختار تدفق الخدمة واتصال النقل. بعد ذلك فقط تُغلف الحزمة برأس MAC ذي ستة بايتات.

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

لكل محطة بادئتها حتى لو شاركت الراديو

ينص النموذج على أن كل محطة تنتمي إلى رابط مختلف. يجب تعيين بادئة IPv6 فريدة أو أكثر لكل رابط محطة/مضيف، ويوصى بواحد أو أكثر من /64 مع علم on-link. وجود عدة محطات على القاعدة نفسها لا يصنع شبكة فرعية مشتركة. وقد تكون نهاية الرابط جهاز CPE يخدم مضيفين خلفه، لكن ذلك لا يضم المشترك المجاور.

يجب أن يسجل إيصال البادئة الموجّه الذي أعلنها، وسياق المحطة الذي استلمها، والأعلام والأعمار وآلية التفويض. DHCP أو AAA طريقة تسليم وليست ترخيصاً لفصل البادئة عن الرابط الذي تنتمي إليه.

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

هوية العنوان ليست هوية الرابط

طلب النص الأصلي اشتقاق modified EUI-64 من عنوان MAC ذي 48 بتاً، مع السماح بمعرفات عشوائية للخصوصية. حدّث RFC 8064 هذه التوصية ونصح بعدم تضمين عنوان طبقة ربط ثابت في IID ثابت.

هذا تحديث لسياسة تكوين جزء من العنوان، لا إلغاء لنموذج الرابط لكل محطة. ربط الجهاز وMAC وIID والعنوان وCID والرابط بمفتاح واحد يجعل أي تحسن في الخصوصية إعادة كتابة للتاريخ. فصل المفاتيح يسمح بتغيير IID مع بقاء نسب البادئة والنفق قابلاً للتدقيق.

الصمت والحجم يحتاجان سياقاً أيضاً

يمكن للمحطة أن تدخل وضع idle فيُفك الرابط اللاسلكي ويصبح paging ضرورياً. لتجنب الإيقاظ واستهلاك المورد، يسمح RFC 5121 بفواصل طويلة لإعلانات الموجّه وينصح بعدم إرسال استعلامات MLD دورية إلى مضيف نائم. الصمت الصحيح وفقدان الحالة قد يبدوان متطابقين. لذلك يلزم حدث الانتقال وحالة paging وآخر RA وعضويات multicast ومحفز إعادة التحقق.

أما MTU الافتراضي الموصى به فهو 1500 octets. عند استخدام قيمة مختلفة يجب إعلانها في خيار MTU ضمن Neighbor Discovery، وقد يكشف Path MTU حداً آخر. الإعداد والإعلان والعبور المرصود ثلاث حقائق.

ويذكر RFC أن حقل Len من 11 بتاً ينتج PDU بحجم 2048 bytes. يقترح Errata 1768 قيمة 2047، لكنه مصنف “Held for Document Update” لا Verified. الأمانة تقتضي حفظ النص والحساب والحالة الإجرائية معاً، ثم اختبار الأحجام بحزم ورسائل Packet Too Big بدلاً من تحويل الصفحة إلى نتيجة تشغيل.

عقد مشترك رقيق وسجل يمكن الاعتراض عليه

لا تتطلب هذه البنية حاكماً مركزياً لكل طبقة. يمكن للعقد المشترك أن يقتصر على صيغة الحمل المختارة، وطرفي رابط L3، ومعرفات ثابتة تربط التدفق وCID والنفق والبادئة، وإمكانية تصدير الدليل. تبقى سياسات التصنيف والعنونة والطاقة محلية وقابلة للاستبدال.

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

المصادر