الخلاصة
- يُنشأ نفق L2F على
MID=0، ثم تُقبل كل وصلة عميل بصورة مستقلة على MID غير صفري؛ نجاح المرحلة الأولى لا يوقع عن الثانية. - يحدد CLID وMID وChallenge وKey سياقاً بروتوكولياً بين NAS وHome Gateway، ولا يثبت هوية بشرية مخولة أو هوية تطبيق.
- لا يقدم L2F تسليماً موثوقاً لحركة البيانات، لذلك لا يثبت نجاح التحكم وصول كل إطار أو تحقق نتيجة خدمة قابلة للاستخدام.
الهوية الظاهرة هي بداية المسار لا نهايته
يصف RFC 2341 بنية طلب هاتفي افتراضي. يتصل المستخدم عبر PSTN أو ISDN بخادم نفاذ شبكي لدى مزود الإنترنت، بينما تنتهي وصلة PPP أو SLIP فعلياً عند Home Gateway بعيدة. ينقل L2F إطارات طبقة الربط بين الموضعين، فيفصل مكان النفاذ المادي عن مكان إنهاء البروتوكول.
ينشأ عن هذا الفصل تسلسل مسؤوليات. تصل المكالمة إلى NAS. يبدأ PPP تفاوض LCP. يجمع NAS قدراً محدوداً من المعلومات لتحديد هوية ظاهرة واختيار Home Gateway. ينشأ نفق L2F. تقرر البوابة قبول وصلة عميل معينة أو رفضها. قد يقع تحقق إضافي، ثم إعداد طبقة الشبكة، ثم نقل الإطارات، ثم جلسة التطبيق والنتيجة التي يراها المستخدم. كل بند واقعة مستقلة.
تفاوض النفق نفسه يستخدم MID=0. يتبادل الطرفان L2F_CONF وL2F_OPEN مع Name وChallenge وAssigned_CLID. بعد نجاح ذلك يصبح النفق متاحاً لإنشاء العملاء. هذه العبارة تحدد قدرة جديدة، لكنها لا تقول إن عميلاً قد قُبل.
لكل وصلة عميل MID غير صفري. يرسل NAS رسالة L2F_OPEN أخرى قد تتضمن نوع التحقق ومعلومات من CHAP أو PAP أو LCP. لا تسجل الوصلة كوصلة مقبولة إلا عندما ترد Home Gateway بـL2F_OPEN. يبدأ نقل إطارات PPP أو SLIP بعد ذلك. لذلك يمكن أن يكون النفق مفتوحاً بلا عملاء، ويمكن أن تختلف نتائج عدة عملاء داخل النفق نفسه.
المعرّف يختار جدول حالة ولا يمنح سلطة
يستخدم CLID لفصل الأنفاق المتداخلة عندما لا تكفي الوسيلة السفلى لتمييزها. ويختار MID وصلة عميل داخل النفق. الصفر مخصص لحالة النفق، والقيم غير الصفرية لحالات العملاء. وإذا أعيد استخدام MID بعد الإغلاق، فيجب تهيئته كوصلة جديدة تماماً.
هذه أدوات لفك التعدد. إنها تجيب: أي سياق يعالج الحزمة؟ ولا تجيب: من يمسك الطرفية؟ ما الصلاحيات التي يملكها الآن؟ وأي ذات قبلها التطبيق؟ تحويل MID إلى هوية يضيف ادعاء لا ينتجه البروتوكول.
الفصل ظاهر في النص نفسه. هدف ISP هو اكتشاف «apparent identity» والبوابة المقصودة. ثم تقرر Home Gateway القبول أو الرفض. ويمكن إجراء مرحلة تحقق ثالثة بعد القبول، خارج نطاق L2F. ولـCHAP في RFC 1994 حد challenge-response خاص به. جمع اسم، وتمرير بيانات، والتحقق من سر، ومنح إذن شبكي، وقبول جلسة تطبيق ليست مترادفات.
ما يصل إلى التحكم قد لا يصل إلى البيانات
يجب إعادة إرسال رسائل التحكم في L2F. أما حركة البيانات فلا تحصل من L2F على ضبط تدفق أو تسليم موثوق؛ البروتوكول المحمول هو المسؤول عن التعافي. ولا تستخدم حركة البيانات العادية حقل Seq غالباً.
لهذا لا تصبح رسالة OPEN مؤكدة، أو استجابة ECHO، أو Key صحيحة، إيصالاً لكل إطار. قد تثبت استجابة النظير أو وجود السياق أو ملاحظة حركة عند حد معين. لكنها لا تعطي سلسلة عهدة من الطرف إلى الطرف.
في PPP، يحمل L2F إطار طبقة الربط بعد إزالة framing المادي وtransparency وFCS. وتبقى رسائل PPP Echo وتفاوض NCP وTERMREQ مجرد إطارات HDLC-like محمولة. لا يكتشف L2F طلب TERMREQ بنفسه؛ يجب أن تتسبب نتيجة نقطة PPP في انتقال L2F إلى الإغلاق. الطبقة الناقلة لا تفهم تلقائياً معنى النتيجة داخل حمولتها.
كما يمر PPP بإنشاء LCP، ثم تحقق اختياري، ثم إعداد بروتوكولات الشبكة عبر NCP. بعد ذلك فقط يبدأ التطبيق جلسته وطلبه. نجاح OPEN لعميل لا يختصر هذه المراحل ولا يثبت نهايتها.
حماية Key لا تشمل كل معنى لكلمة أمان
عند إنشاء النفق يستخدم الطرفان سراً مشتركاً وحساب challenge-response. ويمكن أن تحمل الحزم التالية Key بطول 32 بت مشتقة من استجابة التحقق؛ كما تُسقط الحزم ذات CLID المجهول أو Key الخاطئة أو البنية غير الصحيحة. يقلل ذلك بعض مخاطر الانتحال داخل علاقة NAS–Home Gateway المعدة مسبقاً.
لكنه لا يثبت سرية الحمولة، ولا تخويل المستخدم النهائي، ولا تحقق التطبيق، ولا نتيجة المعاملة. فصل RFC 3193 لاحقاً، في سياق L2TP/IPsec، بين تحقق النفق وسلامة كل حزمة ومنع الإعادة والسرية والأمن من الطرف إلى الطرف. لا يمكن إرجاع هذه القدرات إلى L2F بأثر رجعي، لكن الفصل يكشف خطأ مساواة جواب طرف النفق بأمان الخدمة كلها.
وثيقة تاريخية وليست شهادة انتشار
الحالة الحالية لـRFC 2341 هي Historic. تنص مذكرة الحالة على أنها لا تحدد معيار إنترنت من أي نوع. ويضعها IETF Datatracker في Legacy stream من دون IETF endorsement أو مكانة رسمية في مسار المعايير. تبقى الوثيقة سجلاً تقنياً، لكن وجودها لا يثبت مقدار النشر أو التشغيل البيني أو الاستخدام الحالي أو مطابقة أي منتج.
الدروس القابلة للبقاء هي طريقة المحاسبة. يلزم سجل مستقل للمكالمة المادية، وLCP، واختيار البوابة، والنفق حسب CLID، والعميل حسب MID، والتحقق اللاحق، والإطارات عند الطرفين، وNCP، وجلسة التطبيق، والنتيجة المرئية. كما ينبغي إبقاء عدادات NAS وHome Gateway منفصلة. لا يجوز لإيصال أن يشهد على حد لم يراقبه.
المصادر
- https://www.rfc-editor.org/info/rfc2341/
- https://www.rfc-editor.org/rfc/rfc2341.html
- https://datatracker.ietf.org/doc/rfc2341/
- https://datatracker.ietf.org/doc/rfc2341/history/
- https://errata.rfc-editor.org/search/?rfc_number=2341
- https://www.rfc-editor.org/rfc/rfc1661.html
- https://www.rfc-editor.org/rfc/rfc1662.html
- https://www.rfc-editor.org/rfc/rfc1994.html
- https://www.rfc-editor.org/rfc/rfc2661.html
- https://www.rfc-editor.org/rfc/rfc2868.html
- https://www.rfc-editor.org/rfc/rfc3193.html
- https://www.rfc-editor.org/rfc/rfc3931.html
- https://heng.lu/running-code-primary-the-patch-needed-to-preserve-the-internet-original-design/
- https://heng.lu/minimum-initial-specification-localized-future-decision-voluntary-adoption-internet-coordination-system/
- https://heng.lu/on-reality-layers-symbolic-power-and-why-clarity-feels-so-hostile/
- https://heng.lu/on-data-sovereignty-technical-vs-practical-realities/
- https://heng.lu/on-why-btw-media-exists-and-why-reality-not-advocacy-is-the-product/
إحاطة الأعضاء
سياق أعمق للملف الشخصي
سجّل الدخول بمستوى العضوية المناسب لفتح الإحاطة الكاملة وملاحظات المصادر.
للدائرة الاستراتيجية فقط
الدائرة الاستراتيجية
مفتوح لجميع القراء. افتح إحاطات الملف الشخصي بعد الانضمام وتسجيل الدخول.
انضم إلى الدائرة الاستراتيجيةلأعضاء تحالف القيادات فقط
تحالف القيادات
لأصحاب الأصول الفكرية المؤهلين وللإدارة؛ سجّل الدخول للوصول إلى إحاطات التحالف.
انضم إلى تحالف القيادات

