الخلاصة

  • طلب RFC 3091 من مزوّد البثّ المتعدد إرسال أرقام π إلى المجموعة 314.159.265.359، وهي ليست عنوان بثّ متعدد صالحاً في IPv4.
  • كما تجاوز المنفذان 314159 و220007، المخصصان في النص لـTCP وUDP، حدّ حقل المنفذ ذي 16 بتاً؛ لذلك لا يمكن وضعهما في الحزم كما كُتبا.

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

تكشف صيغة البثّ المتعدد الخلل بوضوح. سمّى RFC 3091 المجموعة 314.159.265.359. يتألف عنوان IPv4 العشري المنقّط من أربعة مقاطع ثمانية البتات، لا يتجاوز أي منها 255؛ ويحدد RFC 1112 نطاق مجموعات المضيفين في IPv4 من 224.0.0.0 إلى 239.255.255.255. تتضمن السلسلة خمسة مقاطع، كما أن المقطع الأول وحده أكبر من الحدّ. ليست هذه مجموعة بثّ متعددة صالحة لم تُسند بعد كي يسجلها مدير شبكة؛ فلا يمكن تفسير النص على أنه عنوان IPv4 أصلاً. ولا يستطيع مضيف الانضمام إلى المجموعة الحرفية التي يحددها المستند.

ويتكرر العيب نفسه في أرقام المنافذ. يعرّف RFC 793 منفذي المصدر والوجهة في TCP بحقلين، كلّ منهما 16 بتاً، وكذلك يحدد RFC 768 حقلي UDP بهذا العرض. أكبر قيمة غير موقعة هي 65,535. مع ذلك، يطلب RFC 3091 من خدمة TCP الإلزامية الاستماع على المنفذ 314159، وتعيد خدمة UDP الاختيارية استخدام الرقم نفسه؛ أما خدمتا التقريب للعدد 22/7 فتستعملان المنفذ 220007. لا يمكن ترميز أي من هذه الأرقام كمنفذ TCP أو UDP. وتنظم إجراءات IANA في RFC 6335 التخصيص داخل المجال الذي تستوعبه الحقول؛ ولا يؤدي تسجيل الرقم إلى توسيع عرضها.

ليس الأمر مجرد طرفة رقمية. ترسل خدمة TCP الأرقام تباعاً حتى يغلق العميل الاتصال. وتتيح خدمة UDP طلب الرقم ذي الترتيب n مع ردّ يتضمن موضعه. أما خدمة البثّ المتعدد فتستغني عن الطلب: ينتظر المزوّد ثلاثين ثانية دون أن يكتشف مزوّداً آخر، ثم يبث توزيعاً عشوائياً يفترض أن يجمعه العملاء مع الزمن. تختلف آلية البث عن الاستعلام، وعن جمع البيانات الموزع، لكن الخطوة الأولى في كل مسار هي الوصول إلى وجهة لا تستطيع طبقة النقل أو طبقة الشبكة تمثيلها.

يحمل المستند تاريخ 1 أبريل 2001 وتصنيف Informational. ويصنفه IETF Datatracker ضمن Independent Submission، وينص صراحة على أن IETF لا تؤيده وأنه لا يتمتع بوضع رسمي في عملية معايير IETF. تجعل هذه الملابسات، إلى جانب الأرقام غير القابلة للترميز والتحذير من انهيار وشيك للإنترنت ما لم يثق العملاء بخادم PIgen، قراءة النص بوصفه مزحة أمراً معقولاً. لكنها قراءة للسياق وليست دليلاً مستقلاً على نية المؤلف الخاصة. أما الحقيقة الأرشيفية الأضيق فهي أن وثيقة منشورة بصيغة RFC وصفت خدمة لا يمكن تمثيل وجهاتها بالبروتوكولات التي تستدعيها.

لا يشكل رقم RFC بحد ذاته دليلاً على وجود تنفيذ. يسجل ملف النشر ما كُتب ومسار النشر، لكنه لا يثبت أن مضيفاً استمع إلى المنفذ المحدد، أو أن مجموعة البث المتعدد وُجدت، أو أن عملية نشر استبدلت القيم، أو أن العملاء أعادوا تركيب π على شبكة حقيقية. تضيف طرق الحساب وDNS SRV تفاصيل تقنية، لكنها لا تصلح عرض الحقول. يستطيع سجل SRV الإعلان عن منفذ، لكن على بروتوكول النقل أن يكون قادراً على حمله.

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

المصادر