[ppml] Policy Proposal: End Policy for IANA IPv4 allocations to RIRs
Izumi Okutani
izumi at nic.ad.jp
Thu Sep 13 22:05:45 EDT 2007
One more note.
I wasn't clear about if this is a global policy or a regional ARIN
policy - it is intended to be a global policy as it defines distribution
of IANA blocks.
izumi
Izumi Okutani さんは書きました:
> Thanks for your input Marla, and apologies for taking some time to reply.
>
> Just to clarify our intention, we think this will help reduce confusion
> for distribution of the last few IANA blocks.
>
> For example, if ARIN was planning to request for 2*/8 next month, but
> APNIC (or any other RIR) comes just before and IANA pool runs out as a
> result, ARIN will be left with 0 additional block it was counting on.
> This will also affect distribution of the last ARIN block within the
> region as you don't know which would be the last block until the last
> minute.
>
> By pre-defining what each RIR will receive in advance (with the size
> which does not affect each RIR's exhaustion date), we think it helps
> solve this issue and minimize confusion at the time of exhaustion.
>
> I see your point about section 2, so I'll remove it from my slides at
> the meeting. thanks. I'd also be happy to remove section 3 if it's an
> obvious fact which doesn't need to be shared.
>
>
> izumi
>
> Azinger, Marla さんは書きました:
>> Here are my two cents:
>>
>> -I don't support this. Let it run out. Write a policy figuring out what IANA does once contiguous requests cant be met.
>>
>> -Section 2 needs to be removed. It isn't policy and more a suggestion/guidance of things that RIR's should think about doing.
>> -Section 3 needs to be removed. It isn't policy and more a staff requirement for RIR's.
>>
>> Cheers!
>> Marla Azinger
>> Frontier Communications
>>
>> -----Original Message-----
>> From: ppml-bounces at arin.net [mailto:ppml-bounces at arin.net]On Behalf Of
>> Member Services
>> Sent: Friday, August 17, 2007 8:20 AM
>> To: ppml at arin.net
>> Subject: [ppml] Policy Proposal: End Policy for IANA IPv4 allocations to
>> RIRs
>>
>>
>> ARIN received the following policy proposal. In accordance with the ARIN
>> Internet Resource Policy Evaluation Process, the proposal is being
>> posted to the ARIN Public Policy Mailing List (PPML) and being placed on
>> ARIN's website.
>>
>> The ARIN Advisory Council (AC) will review this proposal at their next
>> regularly scheduled meeting. The AC may decide to:
>>
>> 1. Accept the proposal as a formal policy proposal as written. If the
>> AC accepts the proposal, it will be posted as a formal policy proposal
>> to PPML and it will be presented at a Public Policy Meeting.
>>
>> 2. Postpone their decision regarding the proposal until the next
>> regularly scheduled AC meeting in order to work with the author. The AC
>> will work with the author to clarify, combine or divide the proposal. At
>> their following meeting the AC will accept or not accept the proposal.
>>
>> 3. Not accept the proposal. If the AC does not accept the proposal,
>> the AC will explain their decision. If a proposal is not accepted, then
>> the author may elect to use the petition process to advance their
>> proposal. If the author elects not to petition or the petition fails,
>> then the proposal will be closed.
>>
>> The AC will assign shepherds in the near future. ARIN will provide the
>> names of the shepherds to the community via the PPML.
>>
>> In the meantime, the AC invites everyone to comment on this proposal on
>> the PPML, particularly their support or non-support and the reasoning
>> behind their opinion. Such participation contributes to a thorough
>> vetting and provides important guidance to the AC in their deliberations.
>>
>> The ARIN Internet Resource Policy Evaluation Process can be found at:
>> http://www.arin.net/policy/irpep.html
>>
>> Mailing list subscription information can be found at:
>> http://www.arin.net/mailing_lists/
>>
>> Regards,
>>
>> Member Services
>> American Registry for Internet Numbers (ARIN)
>>
>>
>> ## * ##
>>
>>
>> Policy Proposal Name: End Policy for IANA IPv4 allocations to RIRs
>>
>> Author: JPNIC IPv4 countdown policy team;
>> Akinori MAEMURA
>> Akira NAKAGAWA
>> Izumi OKUTANI
>> Kosuke ITO
>> Kuniaki KONDO
>> Shuji NAKAMURA
>> Susumu SATO
>> Takashi ARANO
>> Tomohiro FUJISAKI
>> Tomoya YOSHIDA
>> Toshiyuki HOSAKA
>>
>> Proposal Version: 2
>>
>> Submission Date: 2007/08/17
>>
>> Proposal type: new
>>
>> Policy term:renewable
>>
>> Policy statement:
>>
>> 1) Distribute a single /8 to each RIR at the point when new IANA free
>> pool hits 5 */8. This date is defined as "IANA Exhaustion Date".
>>
>> 2) It should be completely left up to each RIR communities to define a
>> regional policy on how to distribute the remaining RIR free pool to
>> LIRs within their respective regions after "IANA Exhaustion Date".
>>
>> Note 1: It is fine for an RIR to continue operations with the
>> existing policy if that is the consensus decision of the
>> respective RIR community.
>>
>> Note 2: Address recovery and re-distribution of recovered address
>> space is another important measure for considerations, but
>> should be treated as a separate policy proposal from
>> distribution of new IANA pool.
>>
>> 3) RIRs should provide an official projection on IANA Exhaustion Date
>> to the community through their website, at their Policy Meetings
>> and through any other effective means.
>>
>>
>> Rationale:
>> [current problem]
>> There are two major issues in terms of address management if no measures
>> are taken for IPv4 address exhaustion.
>>
>> 1) Continue applying a global coordinated policy for distribution of the
>> last piece(s) of RIR's unallocated address block does not match the
>> reality of the situation in each RIR region.
>>
>> Issues each RIR region will face during the exhaustion period vary by
>> region as the level of development of IPv4 and IPv6 are widely
>> different. As a result, applying a global co-ordinated policy may not
>> adequately address issues in a certain region while it could be work
>> for the others.
>>
>> For example, in a region where late comers desperately need even
>> small blocks of IPv4 addresses to access to the IPv4 Internet, a
>> policy that defines the target of allocations/assignments of IPv4
>> address space to be late comers would be appropriate in such region.
>> This would allow availablilty of IPv4 address space for such
>> requirements for more years.
>>
>> Another example comes from difference in IPv6 deployment rate.
>> For a region where IPv6 deployment rate is low, measures may be
>> necessary to prolong IPv4 address life for the existing business as
>> well as for new businesses until networks are IPv6 ready. Some
>> regions may have strong needs to secure IPv4 address space for
>> translators.
>>
>> A globally coordinated policy which addresses all the issues listed
>> above to meet the needs for all RIR regions may result in not solving
>> issues in any of the regions.
>>
>> 2) LIRs and stakeholders remain unprepared for the situation if they are
>> not informed
>>
>> If LIRs and the community are uninformed of the exhaustion, their
>> services and networks remain unprepared to face the situation at the
>> time of exhaustion.
>>
>> [Objective of the proposal]
>> This proposal seeks to provide the following solutions to the problems
>> listed above.
>>
>> 1) RIR community should be able to define their own regional policies on
>> how to assign the last piece(s) of allocation block in order to
>> address their own regional issues during the exhaustion period.
>>
>> 2) RIRs should provide official projection of the date when LIRs will be
>> able to receive the allocations under the current criteria. The
>> criteria should remain consistent until this date in order to avoid
>> confusion.
>>
>> [Pros and Cons]
>> Pros:
>> + It allows each RIR community to define a policy on how to distribute
>> the last piece(s) of allocations which best matches their situation.
>>
>> + It helps LIR better informed of the date when they are able to receive
>> allocations from RIRs under the current criteria and prepare for the
>> event.
>>
>> Cons:
>> + Concerns could be raised about allocating a fixed size to all RIRs,
>> that it artificially fastens the consumption rate of some RIR regions.
>> However, its impact is kept to minimum by keeping the allocation size
>> to a single /8 which makes merely 3-4 months difference.
>>
>> + Concerns could be raised that explicitly allowing regional policies
>> will encourage RIR shopping. However, this should not happen if the
>> requirements within each region is adequately reflected in each RIR's
>> policy through PDP. RIR may also chose to add criteria to prevent LIRs
>> from other regions submitting such requests.
>>
>>
>> Timetable for implementation:
>> Immediate after all 5 RIRs (and possibly ICANN) ratifies the policy.
>>
>>
>>
>> _______________________________________________
>> PPML
>> You are receiving this message because you are subscribed to the ARIN Public Policy
>> Mailing List (PPML at arin.net).
>> Unsubscribe or manage your mailing list subscription at:
>> http://lists.arin.net/mailman/listinfo/ppml Please contact the ARIN Member Services
>> Help Desk at info at arin.net if you experience any issues.
>> _______________________________________________
>> PPML
>> You are receiving this message because you are subscribed to the ARIN Public Policy
>> Mailing List (PPML at arin.net).
>> Unsubscribe or manage your mailing list subscription at:
>> http://lists.arin.net/mailman/listinfo/ppml Please contact the ARIN Member Services
>> Help Desk at info at arin.net if you experience any issues.
>
> _______________________________________________
> PPML
> You are receiving this message because you are subscribed to the ARIN Public Policy
> Mailing List (PPML at arin.net).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/ppml Please contact the ARIN Member Services
> Help Desk at info at arin.net if you experience any issues.
More information about the ARIN-PPML
mailing list