الخلاصة

  • خصص RFC 1918 ثلاث كتل IPv4 قابلة لإعادة الاستخدام من دون تنسيق مع IANA أو سجل إنترنت؛ ويكون العنوان متفرداً داخل مؤسسة واحدة أو مجموعة تنسق استعمالها فقط.
  • قد تستخدم مؤسستان الرقم نفسه استخداماً صحيحاً وهما منفصلتان. الاندماج أو الربط يغيّر المجال الذي يجب أن يتحقق فيه التفرّد، فيحوّل استعمالين محليين مشروعين إلى التباس واحد.
  • المسار، وإجابة DNS، وخريطة الترجمة، وهوية الطرف الموثقة، ونتيجة التطبيق أدلة مختلفة. وصول حزمة لا يثبت وحده أنها وصلت إلى المضيف المقصود.

الخط الفاصل كان يحمل سياقاً

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

قبل الربط، كان الاسم الكامل عملياً هو «10.9.8.7 داخل المؤسسة الأولى». لم يكن الجزء الأول يُكتب في كل حزمة لأن الفصل المادي والإداري حفظه. حين يمتد الاتصال عبر المؤسستين، لا يستطيع الموجّه استنتاج السيرة التي أرادها المرسل. الرقم باقٍ، أما النطاق الذي جعله واضحاً فقد تغير.

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

الاعتراض سبق أفضل الممارسات

في آذار 1994 نشر RFC 1597 نموذج العناوين للإنترنتات الخاصة. صنّف المضيفين بحسب حاجتهم إلى اتصال خارجي. كثير من محطات العمل، وأجهزة الصرف، والشاشات، وواجهات الموجّهات الداخلية تحتاج TCP/IP داخل المؤسسة من دون أن تحتاج عنواناً يميزها في العالم كله. إعادة استعمال مساحة محجوزة وفرت مورداً عالمياً ومنحت المخطط المحلي مرونة.

بعد أربعة أشهر جاء RFC 1627 معترضاً على كسر قاعدة التفرد العالمي. حاجات الغد لا تُعرف من حاجات اليوم: المؤسسات تتعاون وتندمج، والخدمة الداخلية قد تصبح خارجية، والترخيص أو التهيئة قد يرتبطان بالرقم. تورد الوثيقة مثالاً عن إعادة ترقيم آلاف الأجهزة في Apple، لكن حزمة المصادر هنا لا تتحقق بصورة مستقلة من العدد أو الكلفة أو النتيجة؛ لذا يثبت المثال طبيعة الحجة المعاصرة ولا يصلح إحصاءً عاماً.

في شباط 1996 أصدر المجتمع RFC 1918 بصفة BCP 5، فأبطل RFC 1597 وRFC 1627 معاً. وكان Eliot Lear من مؤلفي وثيقة الاعتراض ثم من مؤلفي النص الجديد. لم يخفِ الحل النهائي الخطر. أبقى على المساحة القابلة للتكرار، وذكر صراحة أن دمج إنترنتات خاصة غير منسقة قد يجعل بعض العناوين غير متفردة ويستدعي إعادة ترقيم المضيفين.

إذن لم يكن تصادم الاندماج مفاجأة لاحقة. كان عنصراً معروفاً في المقايضة التي اختيرت.

ثلاث كتل ووعد محدود

الكتل هي 10.0.0.0/8 و172.16.0.0/12 و192.168.0.0/16. تستطيع المؤسسة أن تستخدمها من دون التنسيق مع IANA أو سجل إنترنت، وتستطيع مؤسسات كثيرة أن تفعل الشيء نفسه. يحدد RFC 1918 الوعد بدقة: العناوين متفردة داخل المؤسسة، أو داخل مجموعة مؤسسات اختارت أن تنسق هذه المساحة كي تتواصل.

ما زال سجل IANA الحالي للعناوين ذات الغرض الخاص يصنف الكتل الثلاث Private-Use وغير قابلة للوصول العالمي. لا يمنح ذلك المؤسسة التي سبقت إلى استعمال /24 خاص حقاً حصرياً على غيرها. قابلية التكرار هي المقصود، وليست خللاً في التسجيل.

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

ولا تعني الخصوصية توثيق الهوية. يقول قسم الأمن في RFC 1918 إن قضايا الأمن ليست معالجة فيه. قد تستخدم مؤسسة مرشحات أو بوابات، لكن غياب المسار العالمي لا يثبت مَن هو الطرف الآخر.

الاندماج لا يخلق مالكاً للرقم

إلى جانب حالة دمج الشبكات، يحذر RFC 1918 من منظمتين تقرران لاحقاً إنشاء اتصال IP. ويوصي بالاختيار العشوائي للكتل الفرعية لتقليل احتمال التصادم. العشوائية تقلل الاحتمال ولا تنشئ آلية تنسيق أو شهادة بعدم التداخل.

لذلك لا يجوز أن يتحول الخلاف إلى سؤال: أي المؤسستين تملك 10/8؟ كلتاهما استخدمتا مورداً مصمماً للتكرار. الأسئلة التشغيلية هي: أي نطاق أقل اعتماداً على أرقامه، أي خدمة تحمل هوية مهمة للأعمال، مَن يستطيع تغيير التهيئة، مَن يختبر النتيجة، مَن يتحمل الانقطاع، وهل الترجمة جسر مؤقت أم طبقة دائمة؟

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

مجال العناوين هو الإحداثي الغائب

قدم RFC 2663 لاحقاً مصطلح address realm: مجال شبكي تُمنح فيه العناوين بصورة متفردة ويمكن للتوجيه أن يصل بها إلى الكيانات. هكذا يصبح الجزء المحذوف ظاهراً. العنوان الخاص المفيد هو «رقم داخل realm»، لا رقم معزول.

تربط NAT التقليدية مجالاً خاصاً بمجال خارجي عن طريق تغيير التمثيل، لكنها تفترض عدم تداخل المساحتين. عندما يكون للرقم نفسه معنى على الجانبين، يصف RFC 2663 twice NAT التي تغير المصدر والوجهة معاً. هي تصنع اسماً قابلاً للتوجيه لكل جانب، ولا تجعل الرقم الأصلي متفرداً عالمياً.

يفصل RFC 3022 الآلية أكثر. Basic NAT تربط مجموعة عناوين بأخرى، وNAPT تضيف منافذ النقل. ينبغي أن تمر الطلبات والردود بحالة ترجمة متسقة، وقد يفشل تدفق نُقل إلى جهاز لا يملك تلك الحالة. تستطيع الترجمة إبقاء أرقام المضيفين المحلية، لكنها تنتزع من عنوان IP دلالته طرفاً إلى طرف وتضع ذاكرة إضافية في الشبكة.

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

قد ينجح الاتصال مع الجهاز الخطأ

RFC 5684 منشور بصفة Independent Submission عام 2010، وليس مواصفة على مسار معايير IETF. درس تداخل العناوين الخاصة في NAT متعددة المستويات وفي شبكات VPN للوصول البعيد. يعرض مثالاً يكون فيه عنوان محلل DNS في الشبكة العليا هو نفسه عنوان مضيف محلي، فتُسلّم الاستعلامات محلياً بدلاً من الوصول إلى المحلل. وفي اتصال VPN منقسم قد تختلط خدمة في الموقع البعيد بخدمة المؤسسة المقصودة.

يسمي النص ذلك mistaken end host identity. الخطر أنه لا يظهر دائماً على هيئة انقطاع؛ قد يجيب شيء ما. وللحالات التي يصفها، يوصي بعناوين غير متداخلة أو عالمية لبعض الخوادم الحرجة، وبالتوثيق طرفاً إلى طرف بدلاً من الاعتماد على عنوان المصدر وحده.

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

100.64/10 عقد نطاق آخر

في 2012 أنشأ RFC 6598 الكتلة 100.64.0.0/10 بوصفها Shared Address Space بين CGN لدى مقدمي الخدمة ومعدات العملاء. وميزها صراحة عن المساحة الخاصة بالمؤسسات في RFC 1918. يسجل IANA كلتيهما كمساحة خاصة الغرض وغير قابلة للوصول العالمي، لكن المالك التشغيلي والحدود المقصودة مختلفان.

ليست المنازل والمؤسسات وشبكات مقدمي الخدمة «داخلاً» واحداً. لكل منها مجال، وتوجيه، وأسماء، ومسؤولون، وسطح تصادم. تشابه الأرقام لا ينقل قواعد نطاق إلى آخر.

لم يتخل RFC 1918 عن التفرد. اختار أن يُحفظ بالقرب من الحاجة إليه. كانت الشبكتان صحيحتين في ماضيهما المنفصل. وبعد اللقاء يجب على التصميم المشترك أن يعيد السياق: إما realm واضح، أو خريطة قابلة للتدقيق، أو رقم جديد، مع إثبات مستقل لهوية الخدمة التي أجابت.

المصادر