الخلاصة

  • تخفض prop-164-v005 أصغر allocation من IPv6 من /32 إلى /40، وتضيف أحجاماً أصغر على حدود nibble ومساراً للإرجاع والتقليص وحجز مساحة للنمو.
  • تبقي prop-170-v001 الحد الأدنى /32، ولا تحاذي allocation إلا بطلب صريح وبعد أن يثبت فحص الحاجة القائم حجم الطلب.
  • تقول دراستا الأثر المنشورتان في 18 أغسطس إن النصين يحتاجان إلى مراجعة إذا حصلا معاً على التوافق. لذلك يجب تحديد نتائج 164 وحدها و170 وحدها وكلاهما ولا واحد منهما قبل APNIC 62.

الكلمة المشتركة تخفي بوابتين مختلفتين

تعرض خريطة NOG Alliance المقترحين في سجلين مستقلين للنقاش في APNIC 62. وهذا الفصل أدق من قراءة العنوانين كخيار تقني واحد.

يعمل النص الحالي لـprop-164-v005 عند بوابة الدخول. فهو يسمح بتخصيصات أصغر من /32 حتى /40، على درجات مثل /32 و/36 و/40. كما يمنح بعض حاملي الموارد طريقاً لإعادة المساحة الزائدة وتقليص الكتلة، ويدخل وضعاً متناثراً أو حجزاً قريباً كي يمكن التوسع لاحقاً.

أما prop-170-v001 فتعمل بعد اجتياز البوابة. تبدأ بحاجة قُيّمت وفق القواعد القائمة، ثم تسمح بنتيجة محاذاة إذا طلبها صاحب الطلب. لا تخفض /32، ولا تشمل assignments، ولا تفرض عموماً على الحامل القائم إعادة موارده أو تغيير الحجم أو إعادة الترقيم.

يمكن إذاً لعضو أن يؤيد المحاذاة المشروطة ويرفض فتح حد أدنى جديد عند /40. ويمكن لآخر أن يريد تخصيصات صغيرة قابلة للتسجيل، لكنه لا يقبل معالجة prop-170 للتوسع. سهولة قراءة النظام الست عشري لا تحسم توزيع السلطة.

ويشرح تاريخ prop-164 هذا الفرق. يحفظ Mail Archive نسخة أقدم بدأت بمشكلة الاختيار بين allocation أكبر من الحاجة وassignment أصغر لا يتيح تمثيل sub-allocations كما ينبغي. وشرحت JPNIC هذا الفرق للمجتمع الياباني. منذ ذلك الحين انتقل المقترح من /36 إلى /40، وأضيفت إليه قواعد الإرجاع والحجز؛ أي إن سطح القرار اتسع.

تحذير 18 أغسطس ليس مجرد تحرير

تصف دراستا الأثر مسارين مختلفين للتنفيذ. وتقدر دراسة prop-164 المدة بنحو تسعة أشهر، مع تعديل أنظمة السجل كي تقبل الكتل الأصغر وطلبات التقليص والحجوزات. وتطلب الدراسة توضيح ما إذا كان حامل /32 يستطيع التقليص إلى /36 أم إلى /40 فقط، وما العمل عند غياب مساحة مجاورة مناسبة، وهل يكفي الوضع المتناثر القائم من دون حجز صريح.

أما دراسة prop-170 فتُقدّر المدة بنحو ستة أشهر. يتطلب الأمر تحديث إرشادات وفحص الطلبات لإضافة خطوة المحاذاة مع بقاء اختبار الحاجة والحد الأدنى ونطاق assignments كما هي.

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

ولا يصح جمع الآراء القديمة في تفويض واحد. فقد تساءلت ملاحظات المجتمع الياباني المحفوظة هنا عما إذا كان الانتقال إلى /36 سيؤجل فقط مطالبة جديدة بـ/40، وشككت في حجة التوفير. وسجل عرض SANOG حجة دقة Whois/RDAP. كان ذلك نقاشاً عن الحد الأدنى في prop-164، لا تفويضاً تلقائياً للمحاذاة بعد فحص الحاجة في prop-170.

أربع خانات قبل الاجتماع

في خانة prop-164 وحدها يجب ذكر الحد الأدنى الجديد، والدرجات المسموح بها، وشروط الإرجاع والتقليص، وقاعدة الحجز، والبديل عند غياب التجاور، ووضع الحاملين القائمين. لا تدخل آلية prop-170 لمجرد تشابه الاسم.

في خانة prop-170 وحدها يبقى /32. يجب فصل طلب المحاذاة عن الحاجة المثبتة وعن prefix النهائي، وتأكيد خروج assignments، وشرح التوسع حين لا توجد مساحة متصلة. لا ينشأ مدخل /40 ولا حق الإرجاع.

خانة كلاهما تحتاج نصاً مركباً حقيقياً. أي تعريف يتقدم عند التداخل؟ هل يجوز التقليص إلى /36 أو /40 أو كليهما؟ هل المساحة المجاورة محجوزة بحكم السياسة، أم هي جهد تشغيلي، أم ليست وعداً؟ ما القاعدة إذا شُغلت المساحة المتوقعة؟ عبارة «ننسق لاحقاً» لا تجيب.

خانة لا واحد منهما تبقي الوضع القائم. غياب التوافق لا يسمح بتحقيق النتيجة نفسها عبر إرشادات داخلية.

إذا لم يوجد نص موحد قبل الاجتماع، يمكن للرئاسة إجراء حكمين مستقلين. وحتى إذا ظهر دعم لكليهما، يعود أي دمج جوهري إلى مراجعة ظاهرة قبل اعتباره قراراً. هكذا يطبق التحرير القرار بدلاً من أن يصنعه.

الفائدة التقنية لا توسع التفويض

حد nibble يعني أربع بتات، أي خانة واحدة في النظام الست عشري. وهو مفيد للقراءة والتقسيم والتوثيق والأتمتة. كما يرفض RFC 6177 افتراض حجم واحد يناسب جميع شبكات IPv6 النهائية.

لكن الأدوار لا تندمج. يقدم المجتمع الخبرة ويحكم على المقترحات. تقرر الرئاسة وجود التوافق على نسخة محددة. تحلل الأمانة الأثر وتنفذ القاعدة المعتمدة. يصمم حاملو الموارد شبكاتهم ويشغلونها. يسجل Whois وRDAP حالة التفويض، ولا يثبتان إعلان BGP أو استخدام كل عنوان محجوز.

يوفر مبدأ Heng Lu في الحد الأدنى للمواصفة الأولية معياراً مناسباً: لا يوضع في الطبقة المشتركة إلا ما تتطلبه قابلية التنسيق، وتبقى القرارات اللاحقة عند من يتبناها ويشغلها. والمطلوب هنا تحديد حالة السجل المشتركة التي تتغير، وما يبقى قراراً للشبكة العاملة.

لا يتنبأ هذا المقال بنتيجة APNIC 62. قد تظهر نسخة أو صياغة مشتركة جديدة؛ ومدتا الستة والتسعة أشهر تقديريتان؛ ولا دليل بعد على ما سيحصل عليه طالب حقيقي أو كيف سيعلن المسار.

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

المصادر