الخلاصة

  • لم يكن RFC 917 معياراً؛ بل سجل تشغيل ستانفورد للشبكات الفرعية منذ مطلع 1982، مع نحو 330 مضيفاً و18 شبكة فرعية في 1984.
  • طابقت ستانفورد أرقام الشبكات الفرعية مع أرقام شبكات Pup الموجودة؛ ثم اقترح RFC 917 عرضاً يختاره كل نطاق، قبل أن يوصي RFC 950 بإجراءات للمضيفين في 1985.

العدد الذي يورده RFC 917 لا يصف الإنترنت كله: نحو 330 مضيفاً و18 شبكة فرعية وعدد قريب من ذلك من البوابات في ستانفورد. إنه سجل لموقع واحد في 1984. نشر جيفري موغل الوثيقة في أكتوبر بوصفها مقترحاً للنقاش والتحسين، لا معياراً نهائياً. ويقول النص إن شبكات IP الفرعية في ستانفورد كانت مستخدمة منذ أوائل 1982.

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

امتد هذا التوافق إلى التوجيه. حافظت العملية نفسها على جداول Pup وIP، مع تحويل أرقام الشبكات إلى أرقام فرعية. وكانت البوابات التي لا تفهم سوى Pup تمرر رزم IP اعتماداً على جداول Pup، من دون تعديل قيمة Time-to-Live في ترويسة IP. أما المضيفون متعددو الواجهات الذين عملوا كبوابات فكانوا يعدلونها. ذكر موغل أن هذا الترتيب لم يشهد أخطاء حلقات توجيه حتى وقت كتابة الوثيقة. لا يحول ذلك الملاحظة إلى إذن عام بتجاهل TTL.

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

أما MIT فواجهت قيداً مختلفاً. قبل تقسيم أرقام الشبكات إلى فئات، كان تخصيص رقم IP مستقل لكل وصلة محلية سيستهلك جزءاً كبيراً من المجال المتاح. احتفظت MIT برقم شبكة واحد وقسمت حقل «الباقي» ذي 24 بتاً إلى ثلاثة حقول من ثمانية: رقم الشبكة الفرعية، وحقل محجوز يجب أن يساوي صفراً، ثم رقم المضيف. وتطابق رقم الشبكة الفرعية مع رقم CHAOS. لم يُنفذ تبادل التوجيه الديناميكي الذي كان مخططاً بين البوابات، فاستمرت الجداول الثابتة؛ وساعدت رسائل ICMP Host Redirect على تقليل التعديلات المطلوبة في برمجيات المضيفين.

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

ولكي تعرف محطة بلا قرص هذا العرض عند الإقلاع، اقترح RFC 917 رسالتي ICMP هما Address Format Request وAddress Format Reply، مع بقاء الإعداد المخزن محلياً خياراً صالحاً. إن لم ترد بوابة، يمكن للمضيف البدء بافتراض عرض صفري ثم تعديل تفسيره بعد أن تعلن بوابة القيمة الفعلية. لا ينبغي الخلط بين هاتين الرسالتين المقترحتين ورسائل Address Mask الواردة لاحقاً في RFC 950.

في أبريل 1985، شرح RFC 940 مشكلة التوافق بين مضيفين من موردين مختلفين. وفي أغسطس، قال RFC 950 إنه مبني على RFC 917 وأوصى بإجراءات مشتركة للمضيفين عند استخدام الشبكات الفرعية، من دون استكمال وصف الإجراءات بين البوابات. يوضح التسلسل أن التشغيل المحلي سبق المقترح، وأن المعيار جاء لاحقاً لتقليل اختلاف سلوك المضيفين.

تُستخدم Note 64 لهينغ لو هنا كعدسة تحريرية لفكرة الحد الأدنى من القواعد المشتركة مع ترك القرار الداخلي محلياً. وهي ليست دليلاً على نيات موغل أو ستانفورد أو MIT أو بوستل.