الخلاصة

  • أوصى RFC 1888 أولاً بإعادة تصميم خطط OSI تصميماً أصلياً لـIPv6، ثم عرّف أربع آليات توافق اختيارية.
  • لم تجعل قابلية التحويل العكسي منطقة OSI الممتدة عبر روابط عدة شبكة IPv6 فرعية واحدة، ولم توحّد السوابق أو تحول هوية المضيف إلى هوية واجهة.
  • فصل RFC 4048 بين آليات قيل إنها لم تستخدم بجدية وبين خطأين في الاتجاه المعاكس؛ وصحح RFC 4548 الجزء الضيق الخاص بفضاء ICP فقط.

ثلاث سلطات وثلاثة أنواع من الدليل

نُشر RFC 1888 في أغسطس 1996 بصفة Experimental، ولم يكن معيار إنترنت. قبل عرض صيغ التوافق، نصح أصحاب خطط NSAP المخططة أو المنشورة ببناء خطة IPv6 أصلية، وإعادة تمثيل الطوبولوجيا المحلية حيث أمكن. كانت هذه أولوية معمارية، لا ملاحظة تحريرية.

ظهر السبب في ثلاثة اختلافات. أولاً، يمكن لمنطقة Area في OSI/IS-IS أن تشمل روابط مادية متعددة، في حين تفترض شبكة IPv6 الفرعية رابطاً واحداً. نسخ رقم Area إلى خانة subnet يحافظ على الرقم ولا ينشئ علاقة الجوار التي يحتاجها الاكتشاف في الوصلة الأخيرة.

ثانياً، يتطلب التجميع واسع النطاق سابقة مشتركة. عناوين IPv6 العادية والعناوين المشتقة من NSAPA المقيدة لا تتجمع تلقائياً. قد تستعيد الخوارزمية كل عنوان بدقة، فيما يضطر نظام التوجيه إلى إعلان مسارات أكثر.

ثالثاً، قد تعرّف عدة عناوين NSAP نظام OSI نهائياً بوصفه مضيفاً عبر واجهاته، أما IPv6 فيسند عناوينه إلى الواجهات. نقل هوية المضيف لا يحدد الواجهة القابلة للوصول. كما أن RFC 1888 استبعد ترحيل ES-IS وIS-IS وبنيتهما؛ أي إن الصيغة لم تنقل معها مستوى التحكم.

أربع آليات لا تمنح النتيجة نفسها

وضعت الآلية الأولى NSAPA مقيدة من نوع ICD أو DCC داخل عنوان IPv6 من ستة عشر ثُمانية يبدأ بـ0x02. كان التحويل خوارزمياً وقابلاً للعكس ضمن المجموعة المحددة، لكن النص حذّر من توجيه غير كفء ومن الحاجة إلى آلية إضافية عندما تضم Area شبكات مادية فرعية متعددة.

استخدمت الثانية 0x03 وحملت NSAPA مبتورة. يكفي الجزء الهرمي للوصول نحو Area، لكنه لا يكفي للوجهة النهائية. كان لا بد من خيار وجهة يحمل NSAPA كاملة أو حزمة CLNP مغلفة. وعند الوصول يقرر المستقبل محلياً: يمرر أو يفك التغليف أو يسقط. لم تحدد الوثيقة اكتشافاً تلقائياً للمرحلة الأخيرة، بل أشارت فقط إلى ربط ثابت أو آلية مستقبلية شبيهة بـES-IS.

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

أبقت الآلية الثالثة عنوان IPv6 عادياً وأرفقت خيار مصدر أو وجهة يحوي NSAPA كاملة ليفسره المستقبل. العقد التي لا تستخدم الخاصية غير ملزمة بتنفيذها؛ لذلك يثبت وجود الخيار أن المرسل عرضه، لا أن المستقبل فهمه أو فعّله.

أما الرابعة فوضعت IPv6 داخل NSAPA من عشرين ثُمانية تحت IANA AFI 35 وICP صفر. مُنع التضمين المتكرر لتجنب الشذوذ والحلقات المرتبطة بـRFC 1326. يوفر RFC 1629 سياق NSAP فوق ATM، وRFC 3513 سياق بنية IPv6 اللاحقة؛ ولا يثبت أي منهما تشغيل RFC 1888.

التصنيف التاريخي لم يمح الحاجة الضيقة

قال RFC 4048 سنة 2005 إنه، بقدر ما كان IETF يعلم، لم تُستخدم تحويلات NSAP داخل IPv6 استخداماً جدياً ولم تدعمها تطبيقات IPv6. هذا تقييم مؤسسي منسوب ومحدود بالمعرفة، وليس إحصاءً لكل تجربة خاصة. لكنه أسند نقل الوثيقة إلى Historic وإعادة سابقة IPv6 السابقة إلى Reserved.

كان الاتجاه المعاكس قد جذب اهتماماً، بما فيه استخدام محتمل مع ATM، واحتوى القسم 6 خطأين. حقل ICP طوله ستة عشر بتاً، أي ثُمانيتان، لا الثُمانية الثالثة وحدها. والـIDI المؤلف من أربعة أرقام عشرية يُشفّر في ثُمانيتين BCD، لا كعدد ثنائي حر.

استبدل RFC 4548 هذا القسم وحده سنة 2006. تحت AFI 35، يرمز ICP العشري 0 إلى IPv6 و1 إلى IPv4؛ وتحتاج القيم 2–9999 إلى صيغة معرفة ومنشورة وإجماع IETF. يحفظ سجل IANA لأرقام OSI NSAPA هذه المعاني. السجل دليل سلطة دلالية، لا دليل محلل أو مسار أو حركة.

توضح صفحات RFC Editor الخاصة بـRFC 1888 وRFC 4048 وRFC 4548 الحالة وعلاقة الاستبدال. لم يُعد RFC 4548 آليات NSAP المقيدة أو المبتورة داخل IPv6؛ بل أنقذ وظيفة ترقيم ضيقة بعد تقاعد المحيط الأقدم.

لذلك يجب ترتيب الإثبات: وثيقة، تحويل عكسي، تركيب صحيح، رقم مسجل، محلل، سياسة تمكين، مسار، حلّ الوصلة الأخيرة، قرار المستقبل، نتيجة التطبيق، ثم رصد مستقل للاستخدام. لا تمنح أي درجة سلطة الدرجة التالية.