الخلاصة

  • في الوصول عبر PPP يأتي IPv6CP بعد LCP، بينما قد تنتهي مصادقة RADIUS وتفويضه قبل تخصيص العنوان. لذلك قد لا يعرف NAS بعد ما إذا كان المضيف سيستخدم IPv4 أو IPv6 أو كليهما.
  • أجازت RFC 3162 وجود سمات العائلتين في رسالة RADIUS واحدة، وتركت لـNAS تطبيق ما يستطيع العميل استخدامه فقط. فقيمة التفويض لا تثبت بحد ذاتها وجود عنوان أو بادئة أو مسار أو خدمة عاملة.

وصل الرد قبل السؤال

يحتاج خادم الوصول إلى قرار سياسة قبل فتح جلسة المشترك. لكن عندما يسأل خادم RADIUS هل يسمح للمستخدم، قد تظل تهيئة طبقة الشبكة النهائية للمضيف غير محسومة. وهذا الترتيب هو الجانب الأوضح في RFC 3162، «RADIUS and IPv6»، المنشورة في أغسطس 2001.

تعالج الوثيقة مهمتين مترابطتين لكنهما مختلفتان. يمكن تشغيل RADIUS فوق IPv6؛ وبشكل منفصل، يمكن لرسائل RADIUS حمل سمات تدعم وصول المستخدم إلى شبكة IPv6. استخدام عنوان IPv6 لنقل RADIUS لا يعني تخصيص بادئة IPv6 للمشترك. تناقش الوثيقة الأمرين، لكن مشكلة التوقيت تتعلق بالثانية.

تشرح RFC 3162 التسلسل من خلال الوصول عبر Point-to-Point Protocol. يسبق Link Control Protocol ‏(LCP) بروتوكول IPv6 Control Protocol ‏(IPv6CP). وقد تنتهي المصادقة والتفويض عبر RADIUS قبل تخصيص العنوان. لذلك عندما يرسل Network Access Server ‏(NAS) رسالة Access-Request، قد لا يعرف سلفاً ما إذا كان المضيف سيستخدم IPv4 أو IPv6 أو كليهما.

يمنع ذلك تصميماً بسيطاً: اسأل أولاً عن عائلة العناوين التي سيستخدمها العميل، ثم أعد السمات الخاصة بها وحدها. يحتاج NAS إلى القرار قبل أن يقدم التفاوض اللاحق الإجابة. لا تقترح RFC 3162 التخمين؛ بل تسمح بوجود سمات IPv4 وIPv6 في رسالة RADIUS نفسها، وتترك إلى NAS اختيار ما ينطبق. وينبغي لـNAS تخصيص العناوين والبادئات التي يستطيع العميل استخدامها فعلاً فقط.

التفويض ليس تهيئة

تحافظ السمات ذاتها على هذا التمييز. تحدد NAS-IPv6-Address الجهاز الذي يطلب المصادقة. وتتعلق Framed-Interface-Id بمعرّف واجهة IPv6. أما Framed-IPv6-Prefix فتحمل بادئة ومساراً مقابلاً لتهيئتهما للمستخدم. وتوفر Framed-IPv6-Route معلومات توجيه، بينما تسمي Framed-IPv6-Pool مجموعة بادئات مهيأة يمكن تخصيص إحداها. هذه نقاط تحكم مختلفة وليست براهين متبادلة على الاتصال.

بعض القيم تلميحات صريحة. إذا تفاوض IPv6CP بنجاح على خيار Interface-Identifier، يضع NAS المعرّف الذي يفضله في Access-Request. ويوصى خادم RADIUS باحترام التلميح، لكنه غير ملزم بذلك. ويمكن لـNAS أيضاً اقتراح بادئة IPv6 في الطلب، ويجوز للخادم تجاهلها. إن Access-Accept ردّ سياسة، لا سجلّ يثبت قبول واجهة العميل للتفضيل ولا أن الحزم باتت تصل إلى الإنترنت.

وتقيد RFC 3162 استخدام البيانات المعادة أيضاً. فلا حاجة إلى حجز عنوان IPv4 لمضيف لا يدعم إلا IPv6، كما لا يحتاج المضيف الذي يستخدم IPv4 وحده أو 6to4 إلى بادئة IPv6. هذه نصيحة محدودة، لكنها تحدد المسؤوليات: يقدم خادم RADIUS سمات السياسة؛ ويرى NAS حالة الجلسة المتفاوض عليها، وينبغي له تجنب تهيئة عائلة لا يستطيع العميل استخدامها.

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

تبقى الطبقات منفصلة

ما زالت هناك خطوات لاحقة. قد يتضمن الطلب تفضيلاً من NAS؛ وقد يجيز الرد بادئة أو يعيدها؛ وقد يتفاوض IPv6CP على معرّف الواجهة؛ وربما يهيئ NAS عنواناً أو مساراً. ولا يبيّن قابلية الخدمة للوصول إلا اختبار من طرف إلى طرف بعد ذلك. تحدد RFC 3162 السمات وموضعها في التبادل، لكنها لا تسجل جلسة مشترك حقيقية ولا تصادق على نتائج الخطوات التالية.

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

خصصت RFC 3162 ستة أرقام لسمات RADIUS المتعلقة بـIPv6، من 95 إلى 100. وأضافت المعايير اللاحقة مفردات أخرى: عرّفت RFC 4818 سمة بادئة مفوضة، وأضافت RFC 6911 سمات أخرى لشبكات الوصول عبر IPv6، وحدّثت RFC 8044 إرشادات أنواع بيانات RADIUS. لذلك ليست وثيقة 2001 جرداً كاملاً لتجهيز الوصول الحديث. مساهمتها التاريخية أضيق وأوضح: إتاحة التفويض للعائلتين قبل معرفة أيهما ستستخدمه الجلسة.

تقدم ملاحظة Lu Heng رقم 20 عدسة تحريرية هنا: الوصف الرسمي والحالة القابلة للرصد في النظام طبقتان مختلفتان. ووفق هذا الإطار، تسجل السمة ما طلبه الخادم أو فضّله أو فوّضه؛ لكنها لا تثبت وحدها ما ثبّته NAS أو ما استطاع المستخدم الوصول إليه. هذا تفسير تحريري لا ادعاء من مؤلفي RFC 3162.

المصادر

  1. RFC 3162 — RADIUS and IPv6
  2. سجل RFC 3162 لدى RFC Editor
  3. RFC 2865 — Remote Authentication Dial In User Service (RADIUS)
  4. RFC 2866 — RADIUS Accounting
  5. RFC 2868 — RADIUS Attributes for Tunnel Protocol Support
  6. RFC 2472 — IP Version 6 over PPP
  7. RFC 2460 — Internet Protocol, Version 6 Specification
  8. RFC 3056 — Connection of IPv6 Domains via IPv4 Clouds
  9. RFC 4818 — RADIUS Delegated-IPv6-Prefix Attribute
  10. RFC 6911 — RADIUS Attributes for IPv6 Access Networks
  11. RFC 8044 — Data Types in RADIUS
  12. RFC 2044 — UTF-8, a Transformation Format of Unicode and ISO 10646
  13. Lu Heng، الملاحظة 20