Summary

  • طرح Scott Leibrand وJason Schiller مقترح ARIN-2016-3: إذا استُخدم 80% من رصيد IPv4 القائم، أمكن التأهل لنقل كمية تعادل ذلك الرصيد، بحد أقصى /16.
  • أدخل المجلس الاستشاري المسار في المادة 8.5.7 وأضاف سقفاً تراكمياً خلال ستة أشهر. اعتمد مجلس الإدارة السياسة في يونيو 2017 ونُفذت في أغسطس.

عميل ينتظر الشبكة، والمكتب يبحث عن ورقة من زمن آخر

تخيّل مشغلاً لديه نحو ألف عنوان IPv4، شغّل أغلبها، ويستعد لفتح مواقع جديدة. الأجهزة والعملاء ينتظرون، وطلب المزيد يمر عبر ملفات تتنبأ باحتياج سنتين. وعندما نفد مخزون ARIN الحر، صار الحصول على عناوين إضافية يمر كثيراً عبر نقلها من مؤسسة أخرى؛ بقيت اختبارات الاحتياج تحمل منطق التخصيص القديم. جاء ARIN-2016-3 باختبار يسهل ربطه بما يحدث فعلاً في الشبكة: إثبات استخدام 80% من الرصيد الحالي، ثم طلب نقل كمية تصل إلى حجم ذلك الرصيد، ضمن سقف /16. بقي مسار إثبات الاحتياج المستقبلي المعتاد متاحاً.

تسمي وثيقة مجلس الإدارة Jason Schiller وScott Leibrand صاحبي المقترح. وتذكر سجلات السياسة David Huberman وOwen DeLong مسؤولَي متابعته في المجلس الاستشاري. وفي الوقت نفسه كان مقترح ARIN-2016-5 يعيد ترتيب شروط التحويلات في مادة جديدة تحمل الرقم 8.5؛ وهكذا وجب وضع الفكرة داخل دليل تتغير خريطته أثناء النقاش.

استقرت في المادة 8.5.7. ثم ظهر سؤال حاسم: ماذا يمنع مقدم الطلب من العودة مرات متتالية والتحايل على سقف /16؟ شرح Huberman في رسالة رسمية في يناير 2017 إضافة قيد زمني لهذه الغاية. النص النهائي يضع حد /16 مكافئاً لمجموع التحويلات عبر هذا المسار خلال أي فترة من ستة أشهر. هكذا يستطيع مشغل يحتاج التوسع أن يعرف حدود الطريق مسبقاً، وتستطيع ARIN عدّ كل رحلة عليه.

اعتمد مجلس الإدارة السياسة في 22 يونيو 2017، وتذكر سجلات ARIN تنفيذها في 8 أغسطس. قدّم Leibrand مع Schiller معادلة قابلة للتحقق من استخدام قائم. ثم صقلها النقاش الجماعي لتلائم نظام التحويلات وتحدد وتيرتها. صار بإمكان مشغل يوسّع شبكته أن يضع أمام ARIN ما عمل على الأرض، وأن يعرف أين تقف حدود الزيادة التالية. في مورد نادر، يهم مقدار ما يُنقل وموعد إمكان تكرار النقل بالقدر نفسه.

السجلات الأصلية