[arin-ppml] Policy Proposal (Global): Allocation of IPv4 Blocks to Regional Internet Registries

heather skanks heather.skanks at gmail.com
Fri Jan 30 11:57:28 EST 2009


I don't really have an opinion as to whether the concept is
good/worthwhile yet - but I have a lot of concerns about how this
would work, what the repercussions could be and whether it is worth
it.  As written, I'm currently opposed to this policy.

Here's a run down of my questions/concerns.

It is not clear whether it is mandatory that RIR's proactively recover
space, but it sounds as though it is mandatory that recovered space be
turned over to IANA.  Is this a conflict?  Does this create a
dis-incentive to recover space?

If address space is returned to an RIR, and they have an immediate
need for that space, can they assign it?  or *must* they wait for the
quarterly interval and return it to IANA?  IMO, they shouldn't be
forced to return it if they have requests within their region that
could be met by reassigning the recovered space.

Does this have the potential to break/change rDNS delegations?
Geo-location stuff?  RPKI?

What effect would this have on the RIR's db's?  How much work would it
be on staff and the db's to break up their aggregates in order to
return something?

What does this do to aggregation?  How will preferences to aggregation
be made? It sounds like first come, first serve.. gets the most
aggregated prefixes.

It sounds as though you can't return space after phase1, is this
correct? Intentional?

Whatever space starts in the queue by definition could be depleted in
1 year, if each RIR makes a request each 6 months.  Is it worth it to
extend the "free pool" for one year?  Especially if there is no
incentive/proactive process to recover space?  If RIR's can reassign
returned space until the quarterly interval, there may be little if
anything to return to IANA.

I think this policy doesn't really do anything to extend the free pool
or soften the blow of depletion.  I imagine there would be the least
amount of address space in the queue the first year when it is most
needed.  If a mechanism to return space after phase 1 existed - the
amount of space to delegate could go up - but probably wouldn't for
several years, until IPv6 adoption took hold.

--Heather

On Fri, Jan 23, 2009 at 11:15 AM, Member Services <info at arin.net> wrote:
>
> The shepherds from the ARIN Advisory Council for this proposal are Scott
> Leibrand and Marla Azinger.
>
> Regards,
>
> Member Services
> American Registry for Internet Numbers (ARIN)
>
>
> Member Services wrote:
> > ARIN received the following global policy proposal. In accordance with
> > the ARIN Policy Development Process, the proposal is being posted to the
> > ARIN Public Policy Mailing List (PPML).
> >
> > This proposal is in the first stage of the ARIN Policy Development
> > Process. ARIN staff will perform the Clarity and Understanding step.
> > Staff does not evaluate the proposal itself at this time, their only aim
> > is to make sure that they understand the proposal and believe that the
> > community will as well. Staff will report the results of this step to
> > the ARIN Advisory Council (AC) within 10 days.
> >
> > The AC will review this proposal at their next regularly scheduled
> > meeting (if the period before the next regularly scheduled meeting is
> > less than 10 days, then the period may be extended to the subsequent
> > regularly scheduled meeting). The AC will decide how to utilize the
> > proposal. The decision will be announced to 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 Policy Development Process can be found at:
> > http://www.arin.net/policy/pdp.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: Allocation of IPv4 Blocks to Regional Internet
> > Registries
> >
> > Proposal Originator:
> >
> > This proposal was developed by a team consisting of persons from each of
> > the 5 RIRs.
> >
> > Adiel A. Akplogan" AfriNIC
> >
> > Raul Echeberria LACNIC
> >
> > MAEMURA Akinori APNIC
> >
> > Axel Pawlik RIPE NCC
> >
> > Ray Plzak ARIN
> >
> > Oscar A. Robles-Garay" LACNIC
> >
> > Nigel Titley RIPE NCC
> >
> > Paul Wilson APNIC
> >
> > Proposal Version: 1.0
> >
> > Date: 13 January 2009
> >
> > Proposal type: New
> >
> > Policy term: Permanent
> >
> > Policy statement:
> >
> > This document describes the policy governing the allocation of IPv4
> > address space from the IANA to the Regional Internet Registries (RIRs).
> > This document does not stipulate performance requirements in the
> > provision of services by IANA to an RIR in accordance with this policy.
> > Such requirements should be specified by appropriate agreements among
> > the RIRs and ICANN.
> >
> > This policy is to be implemented in two phases.
> >
> > A. Phase I: Recovery of IPv4 Address Space
> >
> > Upon ratification of this policy by the ICANN Board of Directors the
> > IANA shall establish a mechanism to receive IPv4 address space which is
> > returned to it by the RIRs, and hold that address space in a 'recovered
> > IPv4 pool'.
> >
> > Each RIR through their respective chosen policies and strategies may
> > recover IPv4 address space which is under their administration. Each RIR
> > shall at quarterly intervals return any such recovered address space to
> > the IANA in aggregated blocks of /24 or larger, for inclusion in the
> > recovered IPv4 pool.
> >
> > During Phase I, no allocations will be made from the recovered IPv4 pool.
> >
> > B. Phase II: Allocation of Recovered IPv4 address space by the IANA
> >
> > Upon ratification of this policy by the ICANN Board of Directors and a
> > declaration by the IANA that its existing free pool of unallocated IPv4
> > addresses space is depleted; Global Addressing Policy ASO-001-2 (adopted
> > by ICANN Board 8 April 2005) is rescinded. IANA will then commence to
> > allocate the IPv4 address space from the recovered IPv4 pool.
> >
> > 1. Allocation of IPv4 Address Space
> >
> > a. For the purposes of this policy, an 'IPv4 allocation period' is
> > defined as a 6-month period following 1 March or 1 September in each year.
> >
> > b. At the beginning of each IPv4 allocation period, the IANA will
> > determine the 'IPv4 allocation unit' for that period, as 1/10 of its
> > IPv4 address pool, rounded down to the next CIDR (power-of-2) boundary.
> >
> > c. In each allocation period, each RIR may issue one IPv4 request to the
> > IANA.  Providing that the RIR satisfies the allocation criteria
> > described in paragraph B.2, the IANA will allocate a single allocation
> > unit, composed of the smallest possible number of blocks available in
> > its IPv4 address pool.
> >
> > 2. IPv4 Address Space Allocation Criteria
> >
> > A RIR is eligible to receive additional IPv4 address space from the IANA
> > when the total of its IPv4 address holdings is less than 50% of the
> > current IPv4 allocation unit, and providing that it has not already
> > received an IPv4 allocation from the IANA during the current IPv4
> > allocation period.
> >
> > 3. Initial Allocation of IPv4 Address Space
> >
> > Each new RIR shall, at the moment of recognition, be allocated one (1)
> > allocation unit by the IANA. If an allocation unit is not available,
> > then the IANA will issue this block as soon as one is available. This
> > allocation will be made regardless of the newly formed RIR's projected
> > utilization figures and shall be independent of the IPv4 address space
> > that may have been transferred to the new RIR by the already existing
> > RIRs as part of the formal transition process.
> >
> > 4. Reporting
> >
> > a. All returned space is to be recorded in an IANA-published log of IPv4
> > address space transactions, with each log entry detailing the returned
> > address block, the date of the return, and the returning RIR.
> >
> > b. All allocated space is also to be recorded in this IANA-published log
> > of IPv4 address space transactions, with each log entry detailing the
> > address blocks, the date of the allocation and the recipient RIR.
> >
> > c. The IANA will maintain a public registry of the current disposition
> > of all IPv4 address space, detailing all reservations and current
> > allocations and current IANA-held address space that is unallocated.
> >
> > d) The IANA may make public announcements of IPv4 address block transactions
> > that occur under this policy. The IANA will make appropriate
> > modifications to the "Internet Protocol V4 Address Space" page of the
> > IANA website and may make announcements to its own appropriate
> > announcement lists. The IANA announcements will be limited to which
> > address ranges, the time of allocation and to which Registry they have
> > been allocated.
> >
> > Rationale:
> >
> > With the depletion of the IANA free pool of IPv4 address space, the
> > current policy regarding the allocation of IPv4 address space to the
> > RIRs will become moot. The RIRs may, according to their individual
> > policies and procedures, recover IPv4 address space. This policy
> > provides a mechanism for the RIRs to retro allocate the recovered IPv4
> > address space to the IANA and provides the IANA the policy by which it
> > can allocate it back to the RIRs on a needs basis. This policy creates a
> > new global pool of IPv4 address space that can be allocated where it is
> > needed on a global basis without a transfer of address space between the
> > RIRs.
> >
> >
> > Timetable for implementation:
> >
> > This policy is to be implemented immediately upon ratification by the
> > ICANN Board of Directors according to the global policy process
> > described in the ASO MoU.
> >
> >
> > _______________________________________________
> > PPML
> > You are receiving this message because you are subscribed to
> > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> > Unsubscribe or manage your mailing list subscription at:
> > http://lists.arin.net/mailman/listinfo/arin-ppml
> > Please contact 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 (ARIN-PPML at arin.net).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact info at arin.net if you experience any issues.



More information about the ARIN-PPML mailing list