الخلاصة

  • عرّفت RFC 1393 خيار IPv4 ذي النوع 82 ورسالة ICMP مخصصة، كي يبلغ كل موجّه عن رقم القفزة وسرعة وصلة الخروج وMTU.
  • تقليل محاولات المصدر تطلّب عملاً جديداً في كل قفزة؛ لم ينتشر الخيار على نطاق واسع، ثم صُنّف Historic وأصبح إسقاطه هو التوصية.

حين يصف الطريق نفسه

تنجح traceroute التقليدية لأنها تستعمل سلوكاً موجوداً أصلاً. عندما تنفد TTL يعيد الموجّه رسالة ICMP Time Exceeded. يكرر المصدر المحاولة بقيم 1 ثم 2 ثم 3، ويجمع المسار. رأت RFC 1393 أن ذلك يولد نحو 2n حزمة، ويعيد اجتياز القفزات القريبة، وقد يقيس مسارات مختلفة أثناء التشغيل، كما لا يكشف طريق العودة مباشرة.

حمل النوع 82 معرّفاً يختاره المصدر، وعدّاداً للذهاب وآخر للعودة، وعنوان IPv4 الذي تستقبل عليه التقارير. هذا المعرّف منفصل عن حقل Identification في ترويسة IPv4. يبدأ عدّاد الذهاب من الصفر، وتشير القيمة 0xFFFF في عدّاد العودة إلى أن الحزمة ما زالت في طريقها إلى الوجهة.

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

تستطيع الوجهة نسخ الخيار إلى الرد، والاحتفاظ بمعرّف المصدر وبيانات الذهاب، ثم بدء عدّاد العودة من الصفر. هكذا وعد التصميم برؤية الاتجاهين باستخدام n+1 حزمة. لكن العدّادات ليست TTL؛ فهي لا تزيد إلا عند إرسال تقرير فعلي. لذلك لا يثبت غياب رسالة أن الطريق أقصر، ولا يكفي عدّ الرسائل لتحديد طوله.

عبء انتقل إلى البنية التحتية

اعترفت RFC 1393 بأن الوظيفة الجديدة يجب أن تُضاف إلى الموجّهات، بينما لم تناقش الاعتبارات الأمنية. أوضحت RFC 7126 لاحقاً أن إجبار كل موجّه على معالجة خاصة وتوليد ICMP قد يُستغل لاستنزاف المعالج.

سجلت RFC 6814 النتيجة التاريخية: بقي الخيار تجريبياً ولم ينتشر على الإنترنت العام، ثم أبطلت RFC 1393 رسمياً ونقلتها إلى حالة Historic. ثم قررت RFC 7126 أن حجب النوع 82 لا يسبب أثراً تشغيلياً أو أثراً في قابلية التشغيل البيني، وأوصت الموجّهات والبوابات الأمنية والجدران النارية بإسقاطه.

لم تختف الحاجة إلى معرفة المسار. الذي لم ينجح هو نقل التوفير من جهاز القياس إلى خدمة جديدة لا تكتمل فائدتها إلا إذا نفذتها كل عقدة في الطريق.

المصادر