الخلاصة

  • ألزمت RFC 2011 كيان IP العامل عبر SNMPv2 بمجموعتي ipGroup وicmpGroup للامتثال، لكنها أقرت في ملاحظة IESG بأن IpAddress ذي الأربعة ثمانيات لا يدعم إلا IPv4.
  • يثبت صف ظاهر أو عداد متزايد ما وقع داخل مجموعة الكائنات المعلنة؛ ولا يثبت ظهور عناوين IPv6 أو سوابقه أو مساراته أو جيرانه، ولا أثر تغيير في الإعداد.
  • أنشأت RFC 2465 سطح إدارة منفصلاً لـIPv6، وربطت RFC 4001 نوع العنوان بقيمته، ثم وحدت RFC 4293 المسارين ضمن IP-MIB مستقلة عن نسخة البروتوكول.

نجح المقياس في اختبار حدوده الخاصة

لم يكن القيد استنتاجاً لاحقاً. قالت ملاحظة IESG في RFC 2011 إن وحدات MIB الخاصة بـIP وUDP وTCP آنذاك لم تدعم سوى IPv4، لأن IpAddress يمثل عنواناً من 32 بت في OCTET STRING بطول أربعة. أما عنوان IPv6 ذو 128 بت فلم تكن له قيمة صالحة في ذلك النوع.

دخل هذا القرار في بنية الجداول. في ipAddrTable كان ipAdEntAddr يحمل العنوان ويعمل في الوقت نفسه فهرساً للصف، وكان قناع الشبكة من نوع IpAddress أيضاً. واستخدم ipNetToMediaTable النوع نفسه في هوية الربط بين عنوان الشبكة وعنوان الوسيط. وهكذا لم يحدد النوع شكل الخانة فقط؛ بل حدد الصفوف التي يمكن أن توجد والطريقة التي يستطيع المدير مخاطبتها بها. غياب صف IPv6 لم يكن بالضرورة خطأً أبلغ عنه النظام، بل كان شيئاً لا يستطيع النموذج تمثيله.

كان في وسع الوكيل أن يطبق كل الكائنات الإلزامية، ويجيب كل قراءة مصرح بها، وينجح في فحص الامتثال بصدق. يبدأ الخطأ فقط عند تحويل العبارة المحلية «يمتثل لهذه الـMIB» إلى عبارة أوسع: «سلوك IP في العقدة مغطى».

لكل عداد مجتمع محدد

كان لـRFC 2011 عمل تاريخي دقيق. عرّفت MIB-II كائنات IP وICMP في إطار SNMPv1، بينما كانت إدارة مسارات IP قد حُدّثت في وثيقة منفصلة. نقلت RFC 2011 الكائنات المتبقية إلى SNMPv2 واستبعد وصف وحدتها إدارة المسارات صراحة.

فرض بيان ipMIBCompliance مجموعتي ipGroup وicmpGroup. شملت الأولى حالة التمرير، وTTL الافتراضي، وإحصاءات الإدخال والإخراج، وإعادة التجميع والتجزئة، وصفوف العناوين والربط بين الشبكة والوسيط؛ وشملت الثانية رسائل ICMP وأخطاءه. إنها أدوات قياس واسعة، لكنها ليست مرادفاً للشبكة كلها.

حتى العدادات المتجاورة لها مقامات مختلفة. يشمل ipInReceives الحزم الواردة التي وصلت بخطأ. ويعد ipInDiscards الحزم المهملة رغم عدم وجود خطأ في المعالجة، لكنه لا يشمل الإهمال أثناء انتظار إعادة التجميع. ويخص ipOutNoRoutes الحزم التي لم يوجد لها مسار. أما ipReasmFails فلا يساوي بالضرورة عدد الشظايا المفقودة. ارتفاع الرقم يثبت تغير مجموعة معرفة؛ ولا يسمي وحده عائلة العنوان أو الحزمة أو المسار أو الخدمة أو السبب.

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

ظهر IPv6 أولاً إلى جوار النموذج القديم

لم تمدد RFC 2465 في عام 1998 الخانة القديمة. بل عرّفت مجموعة عامة مستقلة لـIPv6، وفيها ستة جداول للواجهات وإحصاءاتها والسوابق والعناوين والمسارات والربط مع الوسيط. صار عنوان IPv6 سلسلة من 16 ثمانية، من دون اشتراط تغيير SMIv2 أو تطبيقات SNMP الممتثلة.

حُلّت مشكلة التمثيل، لكن التشغيل مزدوج المكدس اكتسب عملية وصل جديدة. على المشغل أن يعرف عائلات MIB التي طبقها الوكيل، والجداول التي سأل عنها الجامع فعلاً، وكيف تطابقت هويات الواجهات، وهل جمعت لوحة العرض العائلتين أم فضلت إحداهما بصمت. لم يصبح امتثال RFC 2011 خاطئاً بسبب وجود RFC 2465؛ بل ظل دليلاً على جانب IPv4 فقط.

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

كان التوحيد مشروع ترحيل لا تبديل اسم

في عام 2006 أبطلت RFC 4293 كلاً من RFC 2011 وRFC 2465 ووحدة ICMPv6 المنفصلة. أنشأت وحدة مستقلة عن نسخة IP؛ فأضافت بُعد نوع البروتوكول إلى إحصاءات النظام والواجهة، ونوع العنوان إلى كائنات العناوين، وبنى مشتركة للسوابق والموجهات الافتراضية والجيران الفيزيائيين.

سجل التعديل صريح في كلفة ذلك. كان تحويل ipAddrTable إلى ipAddressTable تقريبياً فقط؛ والفروق كبيرة إلى حد أن كتابة شيفرة جديدة قد تكون أسهل من تعديل القديمة. احتاجت إجراءات SNMP إلى فهرسة جديدة، واحتاجت العدادات الجديدة إلى أدوات قياس جديدة. استطاعت المواصفة تعريف المخطط المقصود، لكنها لم ترحل الوكيل أو الجامع أو الأرشيف أو الإنذار أو قرار المشغل يوم نشرها.

لذلك ينبغي أن يربط إثبات التغطية أثناء الانتقال بين مراجعة الوحدة، وأنواع العناوين المدعومة، وسياق SNMP، ومثيلات الكائنات، والاستعلام الفعلي، ووقت الجمع، والقاعدة التي استهلكت النتيجة. من دون هذه الروابط، قد يخفي المؤشر الأخضر عائلة كاملة لا يراها النظام.

المصادر

حدود الأدلة

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