[ppml] Policy Proposal: End Policy for IANA IPv4 allocations to RIRs
Izumi Okutani
izumi at nic.ad.jp
Mon Aug 20 05:49:38 EDT 2007
Thanks for the comments to our proposal. I've replied inline;
>> Owen DeLong wrote:
>>> I am neutral on this policy. I don't support it, but, I have no
>>> strong opposition
>>> to it, either.
>>> However, I do wish to address some of the items contained in the
>>> narrative.
>>> First, I think it is absolutely essential that each RIR
>>> communicate the impending
>>> IPv4 free pool exhaustion to their constituency. I believe this
>>> is happening and
>>> I do not believe this policy would affect that in any way.
You're probably right. It's something that is likely to happen in the
actual practice anyway.
The idea behind it is to give a better idea to each community when their
respective RIR's free pool will be exhausted by defining how the IANA
pool will be distributed.
It may also help in RIRs coordination by providing ideas on what is
agreeable to the community.
>>> Second, the assertion that current policy is a globally
>>> coordinated policy
>>> is absurd. Each RIR sets its own policy for allocation and
>>> assignment
>>> today. All that is globally coordinated currently is the policy
>>> on how
>>> the IANA allocates to RIRs. While I don't mind dividing the last 5
If that's already the current policy pracitce, that's fine.
This may be stating the obvious, but we weren't sure if the idea is
shared by everyone and wanted to make it clear.
(We assumed a certain level of co-ordination in RIR policies is
considered desirable as an unwritten practice)
>>> /8s evenly amongst the 5 RIRs (perhaps this policy should state
>>> the last N /8s where N is the current number of RIRs at the time N
>>> is reached, but, I don't anticipate N changing from 5 between now
>>> and then), I don't see the effect of this as being significantly
Point taken. N is already used by LACNIC proposal with a different
definition, so we can define the number as "R" to avoid the confusion;
----
distribute a single /8 to each RIR when free IANA IPv4 address pool
hits R, where R= no. of RIRs at the time of exhaustion (It is currently
five)
----
>>> different
>>> from what will likely happen naturally in the course of current
>>> IANA- >RIR
>>> policy.
>>> What this policy achieves is that each RIR clearly knows when it has
>>> received its last /8 from the IANA and knows which /8 that is. If we
>>> continue to follow current IANA->RIR practices, I believe that the
>>> IANA
>>> and RIRs will have a pretty good idea when that point is reached as
>>> well, with the possible surprise that some RIRs may receive one more
>>> allocation round than they expected to.
>>> Personally, I am much more concerned about the RIR policies to deal
>>> with RIR Free Pool exhaustion process. I'm pretty sure that IANA and
>>> RIRs can handle the IANA free pool exhaustion appropriately under
>>> existing policy, but, I don't regard this policy as harmful to
>>> that process.
Thanks for the imput. I agree that distribution of RIR free pool would
have a more direct impact to the community than that of the IANA pool.
We are plannning to propose a policy for RIR-->LIR distribution in the
APNIC region as the next step, and this is just a first step to move to
the next.
As mentioned in our proposal, we believe RIR-->LIR distribution policy
should be defined by each region to best match each region's
requirements, so it will be left up to ARIN community to decide what to
do with the last few blocks of free ARIN pool.
Hope this clarifies some of the ideas behind the proposal.
Izumi
>>> Owen
>>> On Aug 17, 2007, at 8:19 AM, Member Services wrote:
>>>> 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.
More information about the ARIN-PPML
mailing list