ما الذي تغيّر
التغيير الوحيد المثبت هو إدخال مقترح RIPE NCC 2024-02 في 14 أكتوبر 2024. ولا يثبت التسلسل المقدم أي مراجعة أو تعديل أو اعتماد أو رفض أو سحب لاحق.
RIPE NCC · مراقبة سجلات الإنترنت الإقليمية
ابدأ من هنا للاطلاع على سجل كل مقترح على حدة: ما الذي تغيّر، ولماذا كان مهمًا، ومن دافع عن أي موقف، وكيف تطورت المواقف، وما الذي تقرر، وأين لا تزال هناك ثغرات في الأدلة.
حقائق موثقة
من الذي شكّل النقاش فعلياً؟
تحليل BTW
التغيير الوحيد المثبت هو إدخال مقترح RIPE NCC 2024-02 في 14 أكتوبر 2024. ولا يثبت التسلسل المقدم أي مراجعة أو تعديل أو اعتماد أو رفض أو سحب لاحق.
لا يمكن تحديد موضوع جدل فعلي من السجل المقدم، إذ لا توجد رسائل نقاش أو مشاركون في النقاش أو بيانات مواقف أو حجج مؤيدة أو معارضة. وأي توصيف لمضمون الخلاف سيتجاوز الأدلة المتاحة.
المثبت هو إدخال المقترح في 14 أكتوبر 2024، وليس صدور قرار نهائي بشأنه. وتسجل المقاييس صفراً للرسائل والمشاركين في النقاش والأيام النشطة، لذلك لا توجد مداولات موثقة يمكن ربطها بنتيجة قرار، ولا يمكن وصف المقترح بأنه اعتُمد أو رُفض أو سُحب.
تسجل البيانات فاعلين رسميين اثنين ومشاركين إجمالاً اثنين، مقابل صفر مشاركين في النقاش وصفر رسائل. لذلك لا تمثل القيم الصفرية لحصص أعلى المشاركين ومؤشر HHI والعدد الفعال للمشاركين دليلاً على مشاركة واسعة أو متوازنة؛ بل تعكس غياب نشاط رسائلي قابل للتوزيع. كما أن أعداد نواة 50% و80% والمشاركين لمرة واحدة والمتكررين تساوي صفراً للسبب نفسه.
لا يمكن إثبات نقطة اختناق مؤسسية أو تحديد فاعل تحكم في تقدم المقترح. الحد الوحيد الظاهر في البيانات هو توقف التسلسل المقدم عند مرحلة الإدخال؛ ومن دون مراحل لاحقة أو سجلات نقاش أو تصويت أو تقييم إجماع، لا يمكن معرفة أين أو لدى من تعطل المسار أو تقدم.
Initial allocation range · Version 2 changes the undocumented initial-allocation choice from /32 or /28 to the full range /32 up to /28. Intermediate sizes therefore become explicit options. Requests larger than /28 still require justification.
LIRs that meet the initial allocation criteria are eligible to receive an initial allocation of /32 or /28 without needing to supply any additional information.حقائق موثقة ↗
LIRs that meet the initial allocation criteria are eligible to receive an initial allocation of /32 up to /28 without needing to supply any additional information.حقائق موثقة ↗
One extension per organization · Version 2 replaces the entitlement of an LIR to extend each qualifying allocation with a one-time extension of one allocation per organization. The rationale identifies limiting stockpiling as the purpose. The /28 ceiling and the restriction to allocations originally issued directly by RIPE NCC as a single prefix remain.
LIRs that hold one or more IPv6 allocations that were originally issued directly by the RIPE NCC as a single prefix may request an extension of each such allocation up to a /28 without the need for additional documentation.حقائق موثقة ↗
Organizations, not LIRs, that hold one or more IPv6 allocations that were originally issued directly by the RIPE NCC as a single prefix may request once an extension of one of such allocation up to a /28 without the need for additional documentation.حقائق موثقة ↗
Conservation objection and reserved-space response · Version 2 replaces the absence of opposing arguments with a conservation objection: the new maximum initial block contains twice as much space as /29. Its response says RIPE NCC already reserves a /26 for each new /29 and argues the depletion rate would not increase significantly. That is a stated counter-argument, not a measured outcome; smaller requests remain possible.
This policy proposal is perceived as counterproductive to conservation efforts. Under the proposal, LIRs can initially receive up to twice the amount of IPv6 space compared to the current system. Counterarguments: For each new /29 allocation, the RIPE NCC already reserves a /26 block. This means that the proposed change will not significantly increase the depletion rate of the RIPE NCC address pool.حقائق موثقة ↗
Partial-transfer objection and scope of the extension estimate · Version 2 adds the objection that a /28 can be split into sixteen /32 transfers, with the response that partially transferred allocations cannot be extended again. It also qualifies the unchanged 91% extension-availability estimate as including presumed stockpilers. Neither the numerical estimate nor the original-single-prefix restriction is newly introduced here.
Allowing extensions only for allocations originally issued as a single prefix avoids the risk of abuse by infinitely extending chunks resulting from partial IPv6 transfers.حقائق موثقة ↗
By extending the initial allocation size to /28, LIRs gain the ability to split and transfer up to 16 /32 blocks (the current minimum allocation size) to other LIRs. Counterargument: This practice would be discouraged by the fact that allocations resulting from partial transfers could not be extended anymore.حقائق موثقة ↗
Member-based extension entitlement and direct issuance · Version 3 replaces organization with Member and expressly requires the allocation to have been issued directly to that Member. It states separately that only one extension is available per Member regardless of how many LIR accounts it holds. The /28 limit, single-prefix origin and initial /32-to-/28 range are unchanged.
Organizations, not LIRs, that hold one or more IPv6 allocations that were originally issued directly by the RIPE NCC as a single prefix may request once an extension of one of such allocation up to a /28 without the need for additional documentation.حقائق موثقة ↗
A Member, that holds one or more IPv6 allocations originally issued directly to them by the RIPE NCC as a single prefix, may request an extension of one of these allocations up to a /28 without the need for additional documentation. Only one such extension may be granted per Member, regardless of the number of LIR accounts they hold.حقائق موثقة ↗
Extension allowance moves from Member to LIR · Version 4 returns the extension clause to LIRs and removes the explicit one-per-Member limit across multiple LIR accounts. Its rationale now describes one extension per LIR without further justification and cites Executive Board concerns about using Members. This changes the unit of eligibility; the initial allocation range and /28 extension ceiling remain unchanged.
Only one such extension may be granted per Member, regardless of the number of LIR accounts they hold.حقائق موثقة ↗
The proposal allows only one extension per LIR without further justification, which limits some of the potential adverse effects of stock-pilers. It also addresses the RIPE NCC Executive Board’s concerns in the previous impact analysis about using “Members” instead of “LIRs”.حقائق موثقة ↗
Original allocation provenance wording · Version 4 retains the requirement that the allocation originated as a single prefix directly from RIPE NCC but removes the words requiring issuance directly to the current applicant. The retained text no longer states that original-recipient condition explicitly. This wording change alone does not establish that every transferred block qualifies; the single-prefix restriction and the proposal’s warning about partial transfers remain.
A Member, that holds one or more IPv6 allocations originally issued directly to them by the RIPE NCC as a single prefix, may request an extension of one of these allocations up to a /28 without the need for additional documentation.حقائق موثقة ↗
LIRs that hold one or more IPv6 allocations originally issued directly by the RIPE NCC as a single prefix can request an extension of one of these allocations up to a /28 without providing further documentation.حقائق موثقة ↗
جارٍ التحميل
جزئية
أقدم مادة محفوظة: 30/06/1992
أحدث مادة محفوظة: 12/11/2026