الخلاصة

  • أبقى RFC 2452 معظم كائنات إدارة TCP، ومنها tcpActiveOpens، مستقلة عن استخدام الاتصال لـ IPv4 أو IPv6.
  • احتاج جدول IPv6 إلى ipv6TcpConnIfIndex لأن عناوين المنافذ الأربع لم تضمن دائماً تحديد سجل واحد على عقدة متعددة الواجهات.

أربعة حقول، وسياقان مختلفان

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

عندما نُشر RFC 2452 في ديسمبر 1998، أضاف ipv6TcpConnIfIndex بعد حقول العنوان والمنفذ. أصبح الفهرس الخامس جزءاً من مفتاح صف الإدارة. لم يضف RFC حقلاً خامساً إلى ترويسة TCP ولم يغير زوج الاتصال الذي تنتقله الحزم. الإضافة تخص السجل الذي تقرؤه منصة الإدارة: أي واجهة أو سياق يفسر هذه القيم؟

لماذا لم يُقسّم العدّادات أيضاً؟

قال RFC 2452 إن IPv6 لا يغيّر معنى معظم كائنات TCP المُدارة. فالتنفيذ يحتاج إلى دعم عناوين IPv6، لا إلى إنشاء «TCPng». المثال هو tcpActiveOpens، الذي يحصي الانتقالات المباشرة من CLOSED إلى SYN-SENT بغض النظر عن إصدار IP المستخدم بين الطرفين.

هذا القرار يحافظ على مقياس واحد لحدث TCP ذي معنى واحد. لكنه لا يجعل العدّاد المشترك وسيلة لإسناد الزيادة إلى IPv4 أو IPv6 أو اتصال بعينه أو واجهة أو مستخدم. ولا يثبت أن كل منتج خزّن القياسات في بنية داخلية واحدة؛ فالوثيقة تحدد عقد الإدارة، لا تصف التنفيذ الفعلي لكل جهاز.

كان الجدول استثناءً ملموساً. استخدم RFC 2012 نوع SMIv2 المسمى IpAddress، وهو أربعة بايتات فقط ولا يستطيع تمثيل عنوان IPv6. لذلك أنشأ RFC 2452 جدول ipv6TcpConnTable للاتصالات بين طرفين IPv6، وأبقى اتصالات IPv4 في الجدول السابق. أما إنشاء جدول جديد موحد فكان يتطلب تعديل RFC 2012 وقد يحمّل التطبيقات القديمة ذات IPv4 فقط كلفة التغيير. أبقى الجدول الموازي المسار القديم سليماً، ووضع RFC وحدته في شجرة MIB التجريبية لأنه توقع إدماجها في تحديث لاحق.

ما الذي يعنيه فهرس الواجهة؟

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

إذا تعذر تحديد الواجهة، سمح RFC بالقيمة صفر؛ والعنوان المحلي العام ::0 مثال محتمل. الصفر لا يحدد واجهة مجهولة برقمها، بل يحفظ حقيقة أن المعلومة غير متاحة. ملء هذه الفجوة لاحقاً بأقرب واجهة محتملة يحوّل عدم اليقين إلى إسناد لم يقدمه المصدر.

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

ورث جدول IPv6 أيضاً الحالة القابلة للكتابة deleteTCB(12)، التي يمكنها إنهاء الاتصال على العقدة المُدارة. يتناول مقال RFC 2012 المنشور قصة هذا التدخل؛ وهنا لا نذكره إلا بوصفه حدّاً للحساسية: دقة الملاحظة لا تمنح صلاحية التصرف ولا تثبت ما رآه الطرف الآخر.

في 2005، حل RFC 4022 محل RFC 2012 وRFC 2452 عبر TCP-MIB مستقل عن إصدار IP يستخدم صيغاً عامة للعناوين بدلاً من الإبقاء على جدول IPv6 وفهرسه كما هما. قدّم RFC 4001 الزوج InetAddressType وInetAddress وأشكالاً تتضمن المنطقة؛ وشرح RFC 4007 نطاقات IPv6 ومناطقها. وفي 2017، أعاد RFC 8096 تصنيف RFC 2452 على أنه Historic ووصف وحداته الخاصة بـ IPv6 بأنها obsolete لأغراض صيانة مستودعات MIB. كان توحيد النموذج أولاً، ثم إعادة التصنيف التاريخي لاحقاً؛ وهما حدثان منفصلان.

المصادر