ملخص

  • اقترح M. Andri Setiawan وDavid Aditya Yoga Pratama منح مورد IPv6 تلقائياً مع كل تفويض IPv4 جديد أو أولي لدى APNIC والسجلات الوطنية، على أن يبدأ نشره خلال عامين.
  • كان طالب IPv4 الإضافي سيُطالب بإثبات تقدمه في نشر IPv6. وسألت APNIC عن عقوبة فوات الموعد من دون أن تجد جواباً محدداً في النص. لم يحظ المقترح بتوافق في APNIC 57 وأُسقط في سبتمبر 2024.

تطلب مورداً من IPv4 فتجد في الكيس مورداً من IPv6 وساعة مضبوطة على عامين. تلك كانت فكرة المقترح الذي قُدم في يناير 2024 باسم M. Andri Setiawan وDavid Aditya Yoga Pratama. أراد الاثنان أن تمنح APNIC والسجلات الوطنية تخصيصاً أو إسناداً من IPv6 تلقائياً مع كل تفويض IPv4 جديد أو أولي، وأن يدخل المورد الإضافي مرحلة النشر خلال عامين.

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

الساعة واضحة، أما الجرس فمفقود. سألت APNIC ماذا سيحدث إن انقضى العامان من دون نشر: هل يُسحب IPv6 وحده، أم يُسحب معه IPv4 الذي جاء برفقته، أم تُتخذ خطوة أخرى؟ لم يحسم النص ذلك. والفارق ليس لغوياً لدى مشغل شبكة يضع ميزانيته وخطة خدمته؛ فخسارة مورد غير مستخدم تختلف عن تعريض عنوان IPv4 الذي يعتمد عليه العمل للخطر.

ثم تأتي الفاتورة. أشار التقييم إلى أن اقتران كتلة IPv4 بحجم /23 بكتلة IPv6 بحجم /32 قد يرفع فئة الرسوم. هدف أصحاب المقترح، تسريع استخدام IPv6، مفهوم. لكن وسيلته جمعت المنح التلقائي واحتمال تكلفة أعلى والتزاماً بإثبات الاستخدام لاحقاً. وكان المطلوب أيضاً تعديل نظام توزيع الموارد بحيث لا يختار المتقدم IPv4 أو IPv6 أو الاثنين بصورة منفصلة. كل شيء في الكيس، بما فيه الشروط غير المكتملة.

في اجتماع APNIC 57 يوم 29 فبراير 2024 لم يتحقق توافق. وأسقط رؤساء المسار المقترح prop-158 في 6 سبتمبر من دون عرضه للنقاش في APNIC 58. بقيت الساعة فكرة على الورق. لكنها تركت سؤالاً عملياً: كيف يقيس السجل نشر IPv6 فعلاً، وما الثمن المحدد إذا ربطه بطلب IPv4 القادم؟