الخلاصة

  • فصل RFC 1504 بين هوية الشبكة عبر النفق، المؤلفة من DI والنطاق الأصلي، وبين الرقم الذي يخصصه كل موجّه خارجي لعرضها داخل شبكته المحلية.
  • إذا دار الرقم المحلي في مسار زائد وعاد بلا هوية النفق، تعذر على منشئه تمييز ترجمته من نطاق حقيقي؛ فيعيد تعيينه ويُنتج shadow network، أي سجلات متعددة لشبكة مادية واحدة.
  • لا يثبت RI-Ack أو صف في جدول أو رقم صالح اكتمال الهوية أو التسليم. يلزم ربط حقبة التعيين والمنفذ والاتصال والتسلسل واللقطة والحدث بنتيجة حزمة محددة.

مسار ثانٍ أعاد الشيء من دون تاريخه

نُشر RFC 1504 في أغسطس 1993 باسم Alan Oppenheimer من Apple Computer. كان مذكرة معلومات توثق بروتوكول Apple قد يعمل فوق Internet، لا معياراً للإنترنت ولا تقريراً عن انتشار منتج بعينه.

صُمم AURP ليربط شبكات AppleTalk Phase 2 عبر شبكة أجنبية مثل IP أو عبر وصلة نقطة إلى نقطة. وكان يوفر ثلاثة أسطح مترابطة: نقل حزم AppleTalk داخل النفق، نشر معلومات التوجيه بين الموجّهات الخارجية، ثم عرض معلومات الشبكات البعيدة للآلات المحلية.

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

لم تتضاعف الأسلاك أو الأجهزة. الذي تضاعف هو وصف فقد السلسلة التي تقول من أين جاء.

التضارب بدأ من استقلال مشروع

قد تدير مؤسستان شبكتي AppleTalk منفصلتين وتختاران الرقم نفسه. قبل الربط، كل رقم صالح في مجاله. بعد إنشاء النفق، لا يستطيع الرقم وحده تعيين الوجهة.

عالج AURP ذلك بهوية UI تستخدم داخل النفق. يشتق الموجّه الذي يجري remapping هذه الهوية من DI خاص بالمجال ومن رقم الشبكة أو نطاقها الأصلي. أما داخل المجال المستقبل، فيخصص الموجّه رقماً غير متعارض من مجموعة محجوزة للترجمة.

تستمر الأجهزة القديمة في العمل بأرقام AppleTalk مألوفة. ولا يُفرض عليها فهم هوية عابرة للمجالات. لكن الموجّه الحدودي يصبح مسؤولاً عن جدول يربط العرض المحلي بالأصل.

قد يحصل UI واحد على رقمين مختلفين في مجالين. وقد يُعاد استخدام رقم واحد لـ UI مختلف في وقت لاحق. لذلك لا يثبت اختلاف الرقم اختلاف الشبكة، ولا يثبت تطابقه بقاء الهوية.

التعيين الديناميكي أضاف الزمن إلى المفتاح

يحجز التعيين الثابت رقماً معلوماً لـ UI محدد. يسهل التحقيق، لكنه يستهلك مجالاً محدوداً. أما التعيين الديناميكي فيوزع الأرقام عند ظهور الشبكات ويزيد السعة، لكنه يجعل معنى الرقم مرتبطاً بحقبة.

أوصى RFC 1504 بعدم إعادة استخدام الرقم ما دامت أرقام أخرى متاحة، وألا يُعطى موضع شبكة انقطعت فوراً لشبكة ظهرت للتو. اختفاء الصف من الجدول الحالي لا يمحو حزمة متأخرة أو cache أو طريقاً آخر ما زال يحمل المعنى القديم.

السجل الكامل ليس «47 يساوي X». بل «على الموجّه R والمنفذ P، وفي الحقبة E، عرض 47 الهوية <DI, original range> من T1 إلى T2». ومن دون هذه الحدود، تتحول كفاءة إعادة الاستخدام إلى احتمال تنفيذ فعل قديم على كائن جديد.

الترجمة غيّرت الحقول التي تعرفها فقط

كان الموجّه يستطيع تغيير رقم الشبكة في ترويسة DDP، وفي عنوان كيان NBP، وفي بيانات التوجيه AURP. وإذا حملت الحزمة checksum لـ DDP، وجب التحقق منه قبل التغيير ثم ضبطه على الصفر، لأن القيمة القديمة لم تعد تصف البايتات الجديدة.

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

وأظهرت إدارة الشبكة الفرق نفسه. فقد ترجع الاستجابة عبر النفق بأرقام أصلية غير معيّنة محلياً. تحتاج محطة الإدارة إلى الاستعلام عن قاعدة remapping في الموجّه كي تصلها بالعرض المحلي. وعرّف RFC 1742 لاحقاً كائنات MIB لمنافذ AppleTalk وجداول RTMP والعدادات. جعلت تلك اللغة بعض التشغيل مرئياً، ولم تجعل رقماً منفرداً هوية عالمية.

كيف وُلدت الشبكة الشبح

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

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

يشير رقمان الآن إلى الشبكة المادية نفسها. وقد تضيف دورة أخرى رقماً ثالثاً. سماها RFC 1504 shadow networks. يستمر التكاثر حتى تتجاوز المسافة الظاهرة حد عدد القفزات.

يحد ذلك من الدوران، لكنه لا يصلح provenance. حذف route لأنها بعيدة لا يبيّن أي الصفوف أصل وأيها ظل.

الترجمة وحدها ليست العلة، والازدواج وحده ليس العلة. يجتمع الخطر حين يعبر الاسم المحلي طريقاً خارج الحد المفترض ثم يعود في رسالة لا تحمل ما يكفي للتعرف عليه.

النفق المتعدد النقاط كان وعداً بالاتصال

عامل AURP النفق المتعدد النقاط كأنه وصلة افتراضية واحدة. ويرسل كل exterior router معلومات شبكته المحلية فقط، ولا يعيد عبر النفق ذاته ما تعلمه من exterior router آخر. هذا هو split horizon.

تفترض القاعدة أن جميع أعضاء النفق يستطيعون التواصل مباشرة. لكن النفق قد يكون جزئياً عن قصد أو بسبب خطأ. قد يتصل B بـ A وC من دون اتصال مباشر بين A وC. ولا يستطيع B عادة استنتاج نية المسؤول من حالة البروتوكول.

قد يكون تمثيل الواقع بنفقين مستقلين أوضح من وصفه بوصلة واحدة. الاسم «multipoint tunnel» ليس قياساً للوصل الفعلي.

التطبيق الجزئي جعل الكشف جزئياً

يقرر كل مسؤول محلي ما إذا كان سيشغّل remapping. حذر RFC 1504 من تشغيله في بعض الموجّهات دون غيرها. فالتضارب يصبح أرجح، كما تصبح خاصية كشف الحلقة غير متناظرة.

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

وكان على موجّهين زائدين يجريان التعيين أن يستخدما DI نفسه للمجال المحلي، وأن يربطا كل UI بعيد بالرقم المحلي نفسه. اقترح النص إعداداً يدوياً كاملاً أو مشاركة مستقبلية، لكنه قال إن AURP لا يدعم تلك الوظيفة حينها.

وُجدت redundancy للطريق قبل أن توجد معاملة تضمن redundancy لذاكرة الهوية.

التشابه كان قرينة لا حكماً

عدّ RFC 1504 معلومات route محتملة الدلالة على حلقة عندما يطابق حجم نطاقها وقائمة zones شبكة محلية. لكنه لم يجعل التطابق إثباتاً. يقترح التحقيق إرسال حزمة AppleTalk عبر النفق ثم مراقبة عودتها من منفذ محلي.

تولّد الصفات المتشابهة فرضية؛ وتضيف عودة الحزمة نفسها دليلاً على المسار في لحظة معينة. ولا يثبت الاختبار قصد المسؤول أو دوام topology أو نتيجة كل خدمة.

ووضع قسم الأمن حداً مماثلاً. وصف network hiding وdevice hiding كشكل ضعيف من الأمن، ولم يعالج الأمن العام. عدم ظهور خدمة في Chooser لا يثبت غيابها، وإخفاء route لا يصادق المصدر.

الإقرار يؤكد حزمة ولا يوحد العالم

ينقل AURP صورة أولية ثم updates. لكل اتصال أحادي الاتجاه connection ID، ولكل حزمة sequence number. ينتظر المرسل RI-Ack قبل التالية ويكرر الاستجابة إذا ضاع الإقرار.

قد يتصل peer جديد بينما تنتظر أحداث لم تُرسل بعد. فتصل إليه صورة أولية، ثم حدث يبدو غير منسجم معها. عالج RFC 1504 بعض الحالات بتحويل المعنى: distance change لشبكة مجهولة يعامل كإضافة، والإضافة لشبكة معروفة كـ distance change، وبعض أحداث الانقطاع المجهولة تُتجاهل.

هذه قواعد لإنتاج حالة قابلة للعمل، لا snapshot ذرية لكل peers. ويثبت RI-Ack استلام sequence واحدة، لا انتشار RTMP محلياً ولا تطابق جداول التعيين ولا وصول payload.

إذا فاض جدول المستقبل وضاعت معلومات، لا تكفي آخر update. يطلب المستقبل الجدول الكامل من جديد بواسطة RI-Req. بعد ثقب في التاريخ، يجب إنشاء baseline جديدة.

الملف الذي يربط الظل بأصله

يلزم التحقيق ربط ستة أشياء: UI الأصلي؛ قرار التعيين وحقبته؛ الاتصال والتسلسل ونوع الصورة أو الحدث؛ منفذ وطريق الدخول؛ نسخة الجدول والـ next hop؛ probe أو payload في الخدمة المقصودة.

قد ينهار رقمان مختلفان إلى UI واحد. وقد ينتمي رقم واحد إلى حقبتين مختلفتين. وقد تكون route صحيحة ويظل عنوان مضمّن بلا ترجمة. لا يجيب الرقم وحده أي سؤال من هذه الأسئلة.

ما لا تثبته المصادر

لا تثبت المصادر عدد عمليات نشر AURP، أو امتثال منتج معين، أو حادثة shadow network واقعية، أو استخداماً حالياً. يحفظ RFC 1504 التصميم والتحذير ولا يحفظ نتيجة شبكة مسماة.

يشرح RFC 1378 تفاوض AppleTalk على PPP وحمل معلومات AURP في وصلة نقطة إلى نقطة؛ ولا يثبت convergence. يعرّف RFC 1742 مفردات الإدارة؛ ولا يثبت أن agent معين يعرض قاعدة تعيين كاملة. وتقدم نصوص Lu Heng عدسة معلنة: specification وlocal presentation والقرار الإداري وrunning result سجلات منفصلة.

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

المصادر