[ppml] Policy Proposal: End Policy for IANA IPv4 allocations to RIRs
owen at delong.com
Fri Aug 17 11:47:58 EDT 2007
DOH!!! Maybe you guys should set the Reply-to on those. ;-)
On Aug 17, 2007, at 8:42 AM, Member Services wrote:
> Your response only came back to Member Services (info at arin.net).
> Please post to PPML.
> Erika Goedrich
> ARIN Member Services
> 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
>> 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.
>> Second, the assertion that current policy is a globally
>> coordinated policy
>> is absurd. Each RIR sets its own policy for allocation and
>> 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
>> /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
>> from what will likely happen naturally in the course of current
>> IANA- >RIR
>> 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
>> 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.
>> 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
>>> 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
>>> 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
>>> 3. Not accept the proposal. If the AC does not accept the
>>> 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
>>> 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
>>> behind their opinion. Such participation contributes to a thorough
>>> vetting and provides important guidance to the AC in their
>>> The ARIN Internet Resource Policy Evaluation Process can be found
>>> Mailing list subscription information can be found at:
>>> 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
>>> 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
>>> 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
>>> 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
>>> to the community through their website, at their Policy Meetings
>>> and through any other effective means.
>>> [current problem]
>>> There are two major issues in terms of address management if no
>>> 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
>>> address space to be late comers would be appropriate in such
>>> 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
>>> A globally coordinated policy which addresses all the issues
>>> 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,
>>> 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
>>> 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
>>> [Pros and Cons]
>>> + It allows each RIR community to define a policy on how to
>>> the last piece(s) of allocations which best matches their
>>> + It helps LIR better informed of the date when they are able to
>>> allocations from RIRs under the current criteria and prepare
>>> for the
>>> + Concerns could be raised about allocating a fixed size to all
>>> that it artificially fastens the consumption rate of some RIR
>>> 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
>>> 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.
>>> 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