الخلاصة

  • عرض RFC 3019 جدولاً للواجهات وآخر لذاكرة MLD، لكنه جعل عدداً من الحقول أدوات تحكم: تمكين البروتوكول أو تعطيله، إنشاء سطر أو حذفه، إعلان العضوية المحلية، ضبط المؤقتات وربط واجهة proxy.
  • أثبت السطر حالة يمثلها الوكيل فحسب؛ ولم يثبت وحده مستمعاً بعيداً لا يزال حاضراً، أو نية مأذونة، أو forwarding، أو تسليم packet، أو استلام application.

يبدو سطر cache كأنه أثر تركه listener في الطريق. عنوان المجموعة موجود، الواجهة معروفة، وعنوان IPv6 يظهر بصفته آخر من أرسل Membership Report.

غير أن RFC 3019 لم يصمم دفتراً سلبياً. المدير نفسه استطاع أن يكتب في هذا الدفتر.

كان يستطيع إنشاء entry أو حذفها، وتحديد أن النظام المحلي عضو، وتمكين MLD على الواجهة أو تعطيله، وتعديل فترات Query، وربط العضوية بواجهة proxy أخرى.

من هنا جاءت الحدود: قد يكون السطر صحيحاً تماماً داخل الوكيل، من دون أن يكون دليلاً مستقلاً على أن host بعيداً أرسل تقريراً حديثاً أو أن التطبيق تلقى multicast traffic.

جمع جدول الواجهة بين السياسة والرصد

عرّف RFC 3019 جدولين. ضم MLD Interface Table سطراً لكل واجهة يعمل عليها MLD. وضم MLD Cache Table سطراً لكل زوج من multicast group وinterface يحتفظ له الوكيل بحالة عضوية. استهدف الجدولان hosts وrouters، مع حقول تخص router فقط.

احتوى سطر الواجهة على Query interval، وmaximum response delay، وإصدار MLD، وعنوان Querier، والعدد التراكمي للانضمامات، وعدد المجموعات الحالي، وRobustness Variable، وفترة سؤال آخر listener، وproxy interface، ومؤقتات Querier.

ليست هذه حقائق من النوع نفسه. فالعداد يسجل ماضياً تراكمياً، والـgauge يصف عدد السطور الحالي، وexpiry time يتنبأ بما سيحدث إن لم تصل إشارة جديدة، أما القيمة القابلة للكتابة فتمثل policy.

وفي cache اجتمعت mldCacheSelf وmldCacheLastReporter وعمر السطر ووقت انتهاء صلاحيته وmldCacheStatus. قربها في الجدول لا يمنحها مصدر إثبات واحداً.

آخر مُبلّغ ليس قائمة الحضور

كان معنى mldCacheLastReporter محدوداً: عنوان مصدر آخر Membership Report استلمه الوكيل للمجموعة على الواجهة. وإذا لم يصل أي تقرير، كانت القيمة 0::0.

لم يقل الحقل إن ذلك العنوان ما زال يستمع. ولم يقل إنه العضو الوحيد.

وفق RFC 2710، يحتاج MLD إلى معرفة وجود listener واحد على الأقل في الوصلة. وإذا سمع host تقريراً من host آخر للمجموعة نفسها، أمكنه كبت تقريره الزائد. لذلك قد يمثل آخر عنوان ظاهر عدة أعضاء لم يتكلموا. وقد يغادر صاحبه بينما يبقى عضو آخر، أو يبقى النظام المحلي نفسه عضواً.

أما mldCacheExpiryTime فكان أقل وقت باق قبل ageing. وقد تعني القيمة صفر أن mldCacheSelf وحده يبقي entry، وأنها تزول فور خروج router من المجموعة. ومع ذلك سمح النص للتنفيذ بمعاملة تقاريره المحلية مثل تقارير hosts الآخرين، فلا يلزم الصفر دائماً.

إثبات listener بعيد يحتاج report time وحالة العضوية المحلية وtimer epoch واستمرارية الوكيل. وإثبات الاستلام يحتاج أيضاً بيانات forwarding ورصداً من جهة receiver.

استطاعت الإدارة إنتاج الحقيقة التي ستقرأها

حمل mldCacheStatus صلاحية read-create. أمكن للمدير إنشاء entry جديدة وحذف entry قائمة. وقال وصف مجموعة الامتثال الأساسية صراحة إنها صممت للسماح بإنشاء entries في MLD cache وحذفها.

وكان mldCacheSelf أيضاً read-create وقيمته الافتراضية true.

لذلك قد ينشأ السطر من Report على الوصلة، أو join محلي، أو أمر إداري، أو timer لم ينته بعد. ولم يكن السطر الحالي مضطراً إلى حفظ سلسلة السبب كاملة.

إذا أنشأت automation سطراً لاختبار ثم قرأته، أثبتت القراءة أن الوكيل احتفظ بالحالة المطلوبة. لم تكن شاهداً ثانياً على Report من host بعيد، لأن الكاتب والقارئ استخدما surface واحدة.

التحكم مشروع وضروري. الخطر هو محو origin ثم تقديم control record على أنه observation مستقل.

حذف سطر الواجهة عطّل MLD

لم يكن mldInterfaceStatus مجرد وصف. تفعيل السطر مكّن MLD، وتدميره عطّل MLD على الواجهة.

استطاع المدير أيضاً تغيير Query interval وresponse delay وrobustness وفترة سؤال آخر listener. تقصير الفترة خفّض leave latency، لكنه غيّر النافذة التي يستطيع فيها Report إبقاء الحالة.

وربط mldInterfaceProxyIfIndex واجهتين: membership تعلمها الجهاز على واحدة قد تدفعه إلى إرسال Report على الأخرى. الصفر يعني عدم وجود proxy، والقيمة غير الصفرية تجعل حالة محلية سبباً لفعل upstream.

قد يغير SET مقبول سلوك الاكتشاف والانتهاء والإشارة. لكنه لا يثبت أن Query التالية خرجت، أو أن الجار استلمها، أو أن multicast forwarding تغير، أو أن application استقبلت payload.

read-create لم يلزم كل تنفيذ بالكتابة

لم تكن أقصى صلاحية في schema تعداداً لقدرات الأجهزة المنشورة.

سمحت عبارات الامتثال للـhosts والـrouters بأن يكون الحد الأدنى للوصول إلى mldInterfaceStatus هو read-only. لم تكن الكتابة مطلوبة. يجب فصل تعريف object عن capability الوكيل وعن VACM view وعن authorization الطلب وعن النتيجة الفعلية.

عرّف RFC 2579 دورة RowStatus العامة، لكن active ظل حالة إدارة. لم يثبت persistence بعد restart ولا التزامن مع MLD engine ولا أثر data plane.

القراءة كشفت معلومات والكتابة هددت الخدمة

حذّر RFC 3019 من أن objects المقروءة قد تكشف معلومات عن multicast sessions. ويمكن لـmldCacheSelf وmldCacheLastReporter المساعدة في تحديد machines مرتبطة بعنوان group. وصف النص القراءة غير المأذونة بأنها قليلة الضرر نسبياً؛ وهذا حكم تاريخي لا قاعدة privacy عامة.

أما الكتابة غير المأذونة فقد تسبب denial of service. ودعم SET في بيئة غير آمنة قد يضر network operations.

عدّ النص SNMPv1 وحده بيئة غير آمنة. وحتى حماية الشبكة بـIPsec لم تحدد من يحق له تغيير كل object. لذلك أوصى بـUSM في RFC 2574 وVACM في RFC 2575.

حماية channel، وهوية principal، وصلاحية view، وقبول SET، وتغير protocol، وforwarding، وreceiver outcome إيصالات منفصلة.

وسّع RFC 5519 النموذج من دون إعادة كتابة الماضي

أبطل RFC 5519 في 2009 مفعول RFC 3019. جمع إدارة IGMP وMLD في MGMD MIB، وفصل جداول host وrouter، وأضاف source-filter state لـIGMPv3 وMLDv2.

أظهر الخلف حدود النموذج الأول، لكنه لم يضف بأثر رجعي تلك الحقول إلى سطر 2001. كما لم يثبت implementation أو deployment أو migration بعينه.

تثبت الوثائق design lineage، لا حالة شبكة حية.

تستخدم المقالة أفكار Lu Heng كعدسات معلنة. يفصل Running-Code Primacy بين module والوكيل العامل. ويفصل Reality Layers بين row وReport وpolicy وforwarding وreceipt. ويشرح Minimum Initial Specification فائدة surface أولية صغيرة من دون افتراض قدرات النسخة اللاحقة.

لم يكتب Lu Heng RFC 3019 ولم يزكّه.

كان الجدول أداة جيدة لإدارة سؤال محدود. لم يكن جواباً آلياً عن كل listener وكل packet.

Sources