سياسة ما قبل الاجتماع التحضيري للمؤتمر

آخر تعديل في -
المرجع. اسم افبوب-2010-v4-003-draft-02
الحالة

انتهى العرض
التاريخ 24 نوفمبر 2011
المؤلف (ق) ستيف برتران
كريس جروندمان
مارتن هانيغان
آرون هيوز
لوي لي
مات بونست
جيسون شيلر
تتأثر السياسة  
 
TOC

 

حافز:

اسمح للكل IPv4 جرد بغض النظر عن حجم البادئة المراد إرجاعها إليه ، ثم إعادة تخصيصها بعد ذلك بطريقة منصفة ومنصفة من خلال مرحلة ما بعد انتهاء IANA.

 

1.) الأساس المنطقي

تحدد هذه السياسة عملية التخصيص IPv4 يعالج ما بعد "مرحلة الاستنفاد" [1]. مطلوب سياسة عالمية لكي تتمكن IANA من الاستمرار في تخصيصها بشفافية IPv4 عناوين تتجاوز الإرهاق. من أجل الوفاء بمتطلبات هذه السياسة ، يجب على IANA إنشاء تجمع استصلاح لعقد العناوين والتوزيع منها وفقًا لهذه السياسة. تحدد هذه السياسة العملية التي يتم من خلالها IPv4 يمكن إرجاع العناوين وإعادة إصدارها من مرحلة ما بعد الإنهاك في IANA.

لا تنص هذه الوثيقة على متطلبات الأداء في تقديم الخدمات من قبل IANA إلى RIR وفقا لهذه السياسة. يجب تحديد هذه المتطلبات من خلال اتفاقيات مناسبة بين RIRو ICANN.

 

القصد من هذه السياسة هو كما يلي:

    • لتشمل كل مرحلة ما بعد الإنهاك IPv4 تمت إعادة مساحة العنوان إلى IANA.
    • يسمح بمخصصات IANA من مجموعة الاستصلاح بمجرد الانتهاء من مرحلة الاستنفاد.
    • يعرف "الحاجة" كأساس للمزيد IPv4 مخصصات IANA.
    • لا يفرق أي فئة IPv4 مساحة العنوان ما لم يحدد خلاف ذلك من قبل RFC.
    • تشجيع عودة IPv4 مساحة العنوان من خلال إتاحة عملية التخصيص هذه.
    • عدم السماح بنقل العناوين من مصدر الاستصلاح في حالة عدم وجود IPv4 سياسة النقل العالمية لتحييد التفاوتات في عملية النقل عبر RIR المناطق.
    • ينطبق على الإرث IPv4 تم تخصيص مساحة العنوان في البداية من قبل IANA للمستخدمين بما في ذلك التخصيصات لـ RIRs.
    • يتضمن أي طول للشظايا الموجودة حاليًا بواسطة IANA الآن أو في المستقبل.



2.) استصلاح بركة

عند اعتماد هذا IPv4 سياسة العنوان من قبل مجلس إدارة ICANN ، يجب على IANA إنشاء مجموعة استصلاح ليتم استخدامها بعد ذلك RIR IPv4 الاستنفاد كما هو محدد في القسم 4. سيحتوي مجمع الاستصلاح في البداية على أي أجزاء قد يتم تركها في مخزون IANA. بمجرد أول RIR تستنفد مخزونها من مساحة عنوان IP ، سيتم إعلان مجموعة الاستصلاح هذه نشطة. عندما يُعلن عن تجمع الاستصلاح نشطًا ، فإن السياسة العالمية لتخصيص المتبقي IPv4 مساحة العنوان [3] وسياسة تخصيص IPv4 سيتم إيقاف الحجب من سجلات الإنترنت الإقليمية [4] رسميًا.

 

3.) إعادة مساحة العنوان إلى IANA

ستقبل IANA في مجموعة الاستصلاح جميع المؤهلين IPv4 مساحة العنوان المعروضة للإرجاع. تتضمن مساحة العنوان المؤهلة العناوين التي لم يتم تصنيفها على أنها "استخدام خاص" من قبل IETF RFC أو العناوين المخصصة لها RIRما لم يتم إرجاعها بواسطة RIR التي تم تخصيصها لهم في الأصل. قد يعيد حاملو العناوين القديمة مساحة العنوان مباشرة إلى IANA إذا اختاروا ذلك.

 

4.) معالجة تخصيصات من تجمع الاستصلاح بواسطة IANA

قد تبدأ عمليات التخصيص من تجمع الاستصلاح بمجرد الإعلان عن نشاط التجمع. يجب تخصيص العناوين في تجمع الاستصلاح على حدود CIDR. تخضع عمليات التخصيص من تجمع الاسترداد إلى الحد الأدنى لوحدة التخصيص مساوية لوحدة التخصيص الدنيا للجميع RIRs ووحدة تخصيص بحد أقصى 8/XNUMX. سيتم تقسيم تجمع الاستصلاح على حدود CIDR وسيتم توزيعه بالتساوي على جميع المؤهلين RIRمرة واحدة كل ربع سنة. أي الباقي لا يقسم بالتساوي على عدد المؤهلين RIRستظل s في "تجمع الاستصلاح" حتى تسمح هذه الفترة بإرجاع عناوين كافية لجولة أخرى من التخصيصات.

 

خفق RIR الأهلية للحصول على المخصصات من تجمع الاستصلاح

عند استنفاد RIRمساحة حرة وبعد استلام النهائي / 8 من IANA [3] ، RIR ستصبح مؤهلة لطلب مساحة العنوان من IANA Reclamation Pool عندما تعلن علنًا عبر قائمة البريد الإلكتروني الخاصة بالإعلانات العالمية الخاصة بها وعن طريق نشر إشعار على موقعها على الويب قد استنفدت فيه إمداداتها IPv4 مساحة العنوان. يتم تعريف الاستنفاد على أنه مخزون أقل من ما يعادل مفرد / 8 وعدم القدرة على تخصيص مساحة عنوان إضافية لعملائه في وحدات تساوي أو أقصر من أطول من أي RIRتحدد سياسة الحد الأدنى للتخصيص. حتى واحد / 10 أو ما يعادله IPv4 مساحة العنوان محفوظة خصيصا لأي غرض خاص من قبل RIR لن تحسب ضد ذلك RIR عند تحديد الأهلية ما لم يتم استلام هذه المساحة من مجموعة استصلاح IANA. أي RIR التي تم تشكيلها بعد أن صادق مجلس إدارة ICANN على أن هذه السياسة ليست مؤهلة لاستخدام هذه السياسة للحصول عليها IPv4 مساحة العنوان من IANA.

 

6.) متطلبات الإبلاغ

يجب على IANA أن تنشر أسبوعيًا على الأقل تقريرًا متاحًا للجمهور والذي يحتوي على الحد الأدنى من التفاصيل على كل مساحة العنوان التي تم تلقيها والتي تم تخصيصها. يجب أن تنشر IANA تقريرًا عن مساحة العنوان المرتجع يشير إلى الموارد التي تم إرجاعها ، ومن قبل من ومتى. تنشر IANA تقرير المخصصات أسبوعيًا على الأقل والذي يشير على الأقل إلى ماذا IPv4 تم تخصيص مساحة العنوان ، والتي RIR تلقى التخصيص ومتى. يجب على IANA نشر إشعار عام يؤكد ذلك RIR الأهلية لاحقًا للقسم 4.

 

7.) لا حقوق نقل

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

 

8.) التعاريف

IANA - هيئة الأرقام المخصصة للإنترنت أو من يخلفها

ICANN - شركة الإنترنت للأسماء والأرقام المخصصة ، أو من يخلفها

RIR - سجل الإنترنت الإقليمي كما اعترفت به ICANN

MoU - مذكرة تفاهم بين ICANN و RIRs

IPv4 - بروتوكول الإنترنت الإصدار الرابع (4) ، البروتوكول المستهدف لهذه السياسة العالمية

مساحة حرة - IPv4 العناوين الموجودة في المخزون في أي RIRو / أو IANA

 

9) المساهمون

تبرع الأفراد التاليون بوقتهم ومواردهم وجهدهم لتطوير هذا الاقتراح نيابة عن مجتمع الإنترنت:

ستيف برتران
كريس جروندمان
مارتن هانيغان
آرون هيوز
لوي لي
مات بونست
جيسون شيلر

 


10) المراجع

1. http://www.icann.org/en/general/allocation-remaining-ipv4-space.htm
السياسة العالمية لتخصيص الباقين IPv4 مساحة العنوان ، IANA ، تم استرجاعه في 27 أبريل 2010

2. http://aso.icann.org/documents/memorandum-of-understanding/index.html مذكرة تفاهم لمنظمة دعم عناوين ICANN (ASO) ، تم استرجاعها في 27 مايو 2010.

3. http://www.icann.org/en/general/allocation-remaining-ipv4-space.htm السياسة العالمية لتخصيص الباقين IPv4 مساحة العنوان

4. http://aso.icann.org/wp-content/uploads/2009/09/aso-001-2.pdf سياسة تخصيص IPv4 كتل لسجلات الإنترنت الإقليمية

التاريخ
25.08.2010 تم نشر الاقتراح لأول مرة في قائمة مراسلات rpd بواسطة Steve Bertrand.
27.08.2010 تم النشر على الموقع والمرجع المخصص AFPUB-2010-v4-003
25.11.2010 تمت مناقشة التحديث الجديد خلال اجتماع السياسة العامة AfriNIC-13 وتمت إعادة تسميته إلى AFPUB-2010-GEN-006
24.11.2011

 2011-11-24 - ينتهي العرض بعد عام من عدم النشاط.
إصدار سابق
  افبوب-2010-v4-003-draft-01

آخر تعديل في -

 

التفاصيل

  • المرجع. الاسم: AFPUB-2014-GEN-004-DRAFT-03

  • الحالة: آخر مكالمة

  • التاريخ: 03 يونيو 2015

  • الحالة:
    نفذت

  • المؤلف (ون):
    فرانك هابشت، تنزانيا تبادل الإنترنت ،
    ميتشوكي موانجي ، جمعية الإنترنت / KIXP ،
    نيشال جوبوردان، بيت المقاصة للحزم / JINX

 

1. ملخص للمشكلة التي يعالجها هذا الاقتراح

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

 

2. ملخص عن كيفية معالجة هذا الاقتراح للمشكلة 

تطلب هذه السياسة من AFRINIC الحجز والنشر IPv4 الموارد ، و ASNليتم استخدامها من قبل IXPs فقط. 

 

3. الاقتراح

3.1 مقدمة

 

يعتبر على نطاق واسع أن نقاط تبادل الإنترنت (IXPs) هي واحدة من العناصر الحاسمة اللازمة لتطوير اقتصادات الإنترنت. أفريقيا لا تزال في طور تطوير هذه ، وهي ، في الوقت نفسه ، تواجه استنفاد وشيك لها IPv4 موارد. 

 

عدم وجود IPv4 تؤدي العناوين التي يجب أن تنمو أو تبدأ في IXPs الجديدة إلى خلق تعقيدات توجيه غير ضرورية وغير ضرورية للشبكات المتصلة بالإنترنت ، وتتطلع إلى نظير في IXPs لتعزيز نطاق شبكتها.

 

لدى AFRINIC بالفعل سياسة قائمة لتخصيص مساحات لنقاط تبادل الإنترنت [1]، لكن هذه السياسة لا تحجز مساحة IPV4 على وجه التحديد لضمان وجود مساحة لنقاط تبادل الإنترنت المستقبلية لتنمو وتتطور. بالإضافة إلى ذلك، تحجز هذه السياسة مجموعة من ASNs بين 0 - 65535 للاستخدام من قبل IXPs ، لخوادم طريق IGP. 

 

3.2 التمييز بين نظير IXP وشبكات الإدارة

 

نميز بين نوعين من موارد رقم IP اللازمة والمستخدمة في نقاط تبادل الإنترنت. 

 

LAN IXP النظرة هي كتلة عناوين الشبكة المتجاورة التي ستستخدم IXP لتعيين عناوين IP الفريدة لكل عضو نظير ، لكل مشارك نظير لتبادل حركة مرور الشبكة عبر البنية التحتية النظيرة المشتركة. أفضل الممارسات هي عدم ظهور شبكة LAN النظيرة لـ IXP في عرض جدول التوجيه العالمي ، من بين أشياء أخرى للحد من متجهات الهجوم لأجهزة توجيه حدود ISP عبر IXP. 

 

من وجهة نظر تحديد الشبكة والرصد والتحليل ، من المستحسن أن يتم توفير مساحة "الشبكة المحلية النظيرة" من كتلة متجاورة. LAN IXP management هي شبكة الإدارة التي يستخدمها IXP لتوفير الخدمات في IXP ، مثل المراقبة والإحصاءات والبريد وأنظمة التذاكر وتوفير النقل إلى جذور DNS ، وما إلى ذلك. شبكات الإدارة ، يُمكن الوصول إليها على الصعيد العالمي ، على سبيل المثال لنشر البيانات والسماح بالوصول عن بُعد للبنية الأساسية الجيدة للشبكة (مثل خوادم الجذر و TLD DNS) ومشاريع البحث. 

 

3.3 استخدام خوادم مسار BGP 

 

عادةً ما تستخدم IXPs خوادم مسار BGP للمساعدة في إدارة جلسات التطابق بين المشاركين المختلفين. تنفذ خوادم المسار سياسة توجيه IXP في شكل مجتمعات BGP ، عادة في شكل A: B ، حيث A ، B تمثل A = IXP BGP و B = مشارك ASN. 

 

تستخدم تطبيقات BGP الحالية 6 بايتات لسمة المجتمع الموسعة. لذلك ، IXP مع 4 بايت ASN قيد الاستخدام على خادم التوجيه الخاص به لن يكون قادرًا على تنفيذ تعيين مجتمع A: B BGP بنجاح ، إذا كان لدى مشارك IXP بايت 4 بايت ASN. من المحتمل أن يتعرض هذا الموقف لمزيد من نقاط تبادل الإنترنت (IXPs) ، على شكل 4 بايت إضافية ASNيتم تخصيص s من خلال عملية AFRINIC الحالية. 

 

إذا كانت مجتمعات خادم مسار IXP تشمل IXP ASN والأقران ASN (من المتوقع أن يكون 4 بايت) ، ويتوفر ما مجموعه 6 بايت فقط ، يتبع ذلك خوادم توجيه IXP ASN لا يمكن أن يكون أطول من شغل أكثر من 2 بايت. 

 

3.4 الاقتراح 

 

لضمان وجود موارد كافية لتطوير نقاط تبادل الإنترنت ، تقترح هذه السياسة احتياطي AFRINIC IPv4 عناوين الشبكات المحلية النظيرة لـ IXP خارج كتلة العنوان التي تم تحديدها بشكل خاص وحصري لاستخدام الشبكة المحلية النظيرة لـ IXP. 

 

يجب أن تكون التعيينات للشبكات المحلية النظيرة لـ IXP من مجموعة واحدة مخصصة ، يتم نشرها على هذا النحو بواسطة AFRINIC. ينبغي أن تضمن تخصيصات شبكة Peering LAN لكل IXP حجز كتلة IP المجاورة / 24 (استنادًا إلى الحد الأدنى لحجم سياسة تعيين المستخدم النهائي / 24) لدعم النمو المستقبلي لـ IXP. سيمكّن ذلك IXP من زيادة موارد شبكة الاتصال المحلية النظيرة الخاصة به إلى / 23 دون الحاجة إلى إعادة ترقيم إلى تخصيص كتلة IP متجاورة جديدة. 

 

لا ينبغي توفير الواجبات لعناوين إدارة IXP من نفس الكتلة مثل شبكات IXP النظيرة المحلية. 

 

يُقترح حجز كتلة / 16 للمتطلبات المستقبلية لشبكات LAN المحلية النظيرة في منطقة خدمة AFRINIC ، وأن تقوم AFRINIC بنشر هذه الكتلة على هذا النحو. بالإضافة إلى ذلك ، يجب أن تحتفظ التخصيصات لشبكة LAN المحلية النظيرة لـ IXP بلوك IP / 24 المجاور المجاور لـ IXP الطالبة للنمو في المستقبل.

 

يجب دعم هذه الحجوزات حتى يحين الوقت الذي لم يعد بإمكان المجموعة المتاحة لـ / 16 تخصيص / 23 تخصيصًا. بعد ذلك ، قد يتم تعيين طلبات جديدة من المساحة المحجوزة لنمو IXP في المستقبل. يُقترح أيضًا الاحتفاظ بما يعادل كتلة إضافية / 16 لبادئات إدارة IXP ، منفصلة عن شبكات LAN المتماثلة. 

 

يقترح أن تحتفظ AFRINIC كتلة من ASNs بين 0 - 65535 للاستخدام في خوادم مسار BGP في IXPs في منطقة خدمة AFRINIC. عدد ال ASNيجب أن يكون حجم s المراد حفظه أكبر من 114 أو نصف الباقي ASNبين 0 - 65535 ضمن كتلة AFRINIC في تاريخ التصديق على هذه السياسة. سوف تقوم AFRINIC بتخصيص هذه الموارد على أساس من يأتي أولاً يخدم أولاً. 

 

3.5 معايير التقييم 

 

لا تقترح هذه السياسة معايير تقييم جديدة لما يحدد IXP صالحًا. 

 

4. تاريخ المراجعة

  1. 23 أكتوبر 2014 - افبوب-2014-GEN-004-DRAFT-01 نشر on RPD قائمة.
  2. 05 نوفمبر 2014 - افبوب-2014-GEN-004-DRAFT-02 نشر على RPD قائمة.
  3. 11 حزيران 2015 - AFPUB-2014-GEN-004-DRAFT-03 نشر on RPD قائمة.

 

مراجع حسابات

 

[1] سياسة AFRINIC لتعيينات المستخدم النهائي - AFPUB-2006-GEN-001، http://afrinic.net/en/library/policies/127-afpub-2006-gen-001 القسمان (5) و (6)

 

 

الصفحة 1 من 12