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

Wed Oct 7 14:17:58 EDT 2009

A revised rationale has been added to the 2009-3 draft policy page:
https://www.arin.net/policy/proposals/2009_3.html

Regards,

Member Services
American Registry for Internet Numbers (ARIN)


Member Services wrote:
> Draft Policy 2009-3 (Global Proposal)
> Allocation of IPv4 Blocks to Regional Internet Registries
>
> On 14 September 2009 a revised version of Draft Policy 2009-3 was posted
> to the Public Policy Mailing List (PPML). ARIN staff reviewed the text
> of the draft policy and produced the following revised staff and legal
> assessment.
>
> 2009-3 is under discussion on PPML and will be presented at the upcoming
> Public Policy Meeting in Dearborn.
>
> Draft Policy 2009-3 is below and can be found at:
> https://www.arin.net/policy/proposals/2009_3.html
>
> Regards,
>
> Member Services
> American Registry for Internet Numbers (ARIN)
>
>
> ## * ##
>
>
> Staff Assessment
>
> Draft Policy 2009-3 (Global Proposal)
> Allocation of IPv4 Blocks to Regional Internet Registries
>
> Text assessed: 14 September 2009
>
> I. Summary (Staff Understanding) (revised):
>
> Staff understands that this proposal would be implemented in 2 phases.
> Phase 1 says that the RIRs may elect to return any IPv4 addresses they
> recover (via policy or procedure) to the IANA but it does not require
> them to return recovered IPv4 address space to IANA.
>
> Phase 2 would start after the depletion of the IANA free pool and would
> nullify the existing IANA to RIR policy (Global Addressing Policy
> ASO-001-2). The new IANA to RIR policy would allow each RIR to receive
> approximately 1/10th of the recovered IPv4 pool from IANA once every 6
> months as long as it meets the qualification criteria written in
> paragraph B2. IANA will be required to keep a log of all returned IPv4
> address space and all issued IPv4 address space from the recovered pool,
> as well as maintain a public registry of the current disposition of all
> IPv4 address space.
>
> II. Comments
>
> A. ARIN Staff Comments (revised)
> • If an RIR is fully authoritative for a /8, and as a result of this
> policy, returns a portion of that /8 to IANA, it is likely that the DNS
> authority for the /8 could change. If the returned space is then
> re-issued by IANA to a different RIR, is the /8 now considered an
> ERX-like "fractured" /8, which the RIRs must then exchange zone
> fragments for to put together a complete set of zone files for the /8?
> Close coordination by the 5 RIRs will be required in order to
> successfully manage the potential reverse DNS implications.
>
> B. ARIN General Counsel Comments (revised):
>
> The current basis of allocating number resources was established in
> RFC's 2008 and 2050 and is defined to be according to operational need.
> If one region has greater needs than another, current allocation policy
> does not call for equal distribution of numbering resources to all RIR's.
>
> The revised portion of this policy removes objectionable requirements in
> the prior version that required ARIN to return all recovered IPV4 space
> to the IANA, when such space might be needed in this region, or other
> regions were not maintaining need's based distribution policies. That
> first problem was exacerbated by a second: the policy included a
> redistribution mechanism that did not follow RFC 2008 and 2050 but would
> provide ARIN, at best, only one fifth of such space, when it was also
> likely ARIN would return more than one fifth of the recovered space. The
> revision to voluntarily permit, but not require ARIN to return such
> recovered space is a substantial advance and removes strong legal and
> fiduciary objections to the prior draft.
>
> Accordingly, the revised policy also removes the prior version's
> disincentive for any RIR, including ARIN, to undertake financial
> expenditure of its financial resources for programs intended to obtain
> returned space, since it does not force 100% return to IANA. Since ARIN
> has expended significant resources seeking the return of unused number
> resources, this is again a positive change. It also appears, and it must
> be made so if it is not, that the revised language would not interfere
> with transfers made under ARIN's new policy, which is intended to
> encourage better use of otherwise underutilized resources.
>
> However, the revised proposal appears to retain the predecessor' drafts
> policy that each RIR with needs will be an equal recipient of such
> returned space, even if those needs are disparate. This policy could
> tend to reallocate returned space away from where it is recovered, in
> the ARIN region, to other regions. This would be objectionable from a
> fiduciary duty perspective if one or more of the other RIRs abandon
> needs-based policies, but are then permitted by this policy to obtain
> equal additional resources.
> However, since ARIN can choose not to return recovered resources if
> others RIRs are not maintaining needs based policies, this is no longer
> a fatal legal flaw, since ARIN can chose not to provide returned
> resources for redistribution under such circumstances.
>
> There is a concern over one particular piece of the policy. In 4 it
> states: "Each new RIR shall, at the moment of recognition, be allocated
> one (1) allocation unit by the IANA." The 'new' reference appears
> unwise, with "recognized" RIRs being a better choice.
>
> III. Resource Impact
>
> The resource impact of implementing this policy is viewed as moderate as
> it represents a fundamental change to the business rules of ARIN’s
> inventory management of number resources. It is estimated that this
> policy would require a minimum of 6 person months of effort to implement
> following ratification by the ARIN Board of Trustees. Because this
> implementation is not planned, it may preempt ARIN's current project
> deployment schedule.
>
> It may require the following:
>
> • Modifications to existing registration procedures to include the
> handling of returned/reclaimed address space and the process of
> requesting additional address space from the IANA.
>
> • Modifications to the existing registration software and systems as
> well as the zone gen and any other processes tied to managing reverse 
> DNS.
>
> • Staff training
>
> • Inter-RIR coordination
>
> End of assessment.
>
> Member Services wrote:
>> Draft Policy 2009-3 (Global Proposal)
>> Allocation of IPv4 Blocks to Regional Internet Registries
>>
>> On 20 August 2009 the ARIN Advisory Council (AC) selected 2009-3 for
>> adoption discussion on the PPML and at the Public Policy Meeting in
>> Dearborn.
>>
>> 2009-3 comes from a global policy proposal. Global policies require the
>> agreement of all five RIRs according to their policy development
>> processes and ratification by ICANN. And, global policies require
>> specific actions by the IANA.
>>
>> After the ARIN Public Policy Meeting in April 2009 the AC returned
>> 2009-3 to their docket for further development and evaluation.
>>
>> The AC revised the text. The difference between the text presented at
>> the ARIN meeting in April and the current version is in "A. Phase I" as
>> follows:
>>
>> Old ARIN "A. Phase I"
>>
>> Each RIR through their respective chosen policies and strategies may
>> recover IPv4 address space which is under their administration. At
>> quarterly intervals, each RIR shall return to the IANA any legacy
>> address space recovered, and may return to the IANA any non-legacy
>> address space recovered, in aggregated blocks of /24 or larger, for
>> inclusion in the recovered IPv4 pool.
>>
>> New ARIN "A. Phase I"
>>
>> Each RIR through their respective chosen policies and strategies may
>> recover IPv4 address space which is under their administration and
>> designate any such space for return to the IANA. Each RIR shall at
>> quarterly intervals return any such designated address space to the
>> IANA in aggregated blocks of /24 or larger, for inclusion in the
>> recovered IPv4 pool.
>>
>> Draft Policy 2009-3 is below and can be found at:
>> https://www.arin.net/policy/proposals/2009_3.html
>>
>> You are encouraged to discuss Draft Policy 2009-3 on the PPML prior to
>> the October Public Policy Meeting. Both the discussion on the list and
>> at the meeting will be used by the ARIN Advisory Council to determine
>> the community consensus for adopting this as policy.
>>
>> Note, the ARIN version of the global proposal is different from the text
>> at the other RIRs. The AC's version has a revised "A. Phase I" (APNIC's
>> equivalent is prop-069, see the second paragraph of 5.1). The ARIN
>> version also includes a definition of legacy space.
>>
>> The APNIC proposal can be found at:
>> http://www.apnic.net/policy/proposals/prop-069
>>
>> The ARIN Policy Development Process can be found at:
>> https://www.arin.net/policy/pdp.html
>>
>> Draft Policies and Proposals under discussion can be found at:
>> https://www.arin.net/policy/proposals/index.html
>>
>> Regards,
>>
>> Member Services
>> American Registry for Internet Numbers (ARIN)
>>
>>
>> ## * ##
>>
>>
>> Draft Policy 2009-3 (Global Proposal)
>> Allocation of IPv4 Blocks to Regional Internet Registries
>>
>> Version/Date: 14 September 2009
>>
>> 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 and
>> designate any such space for return to the IANA. Each RIR shall at
>> quarterly intervals return any such designated 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. Return of recovered address space (as described above) will
>> continue throughout Phase II.
>>
>> 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
>> address 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. The following definitions apply to this policy:
>>
>> a. Recovered Address Space. Recovered address space is that address
>> space that is returned to an RIR as a result of any activity that seeks
>> to reclaim unused address space or is voluntarily returned to the RIR or
>> is reclaimed by the RIR as a result of legal action or abuse
>> determination. Recovered address space does not include that address
>> space that is reclaimed because of non-payment of contractual fees whose
>> reclamation date is less than 1 year at the time of the report.
>>
>> b. IPv4 Address Holdings. IPv4 address holdings are all unallocated IPv4
>> address space held by an RIR to include recovered address space not yet
>> returned less that address space that is committed in accordance with
>> the RIR's reservation policy and practices.
>>
>> c. Aggregated address blocks. Aggregated address blocks are contiguous
>> prefixes that can be aggregated on natural bit boundaries. 10.0.0.0/24
>> and 10.0.1.0/24 are two contiguous prefixes that can be combined to form
>> an aggregated address block. 10.0.0.0/24 and 10.0.1.0/25 are two
>> contiguous prefixes that cannot be combined on a natural bit boundary to
>> form an aggregated block.
>>
>> d. Legacy address space. IPv4 address space allocated or assigned prior
>> to the creation of the RIR.
>>
>> 2. 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.
>> The minimum 'IPv4 allocation unit' size will be a /24.
>>
>> 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.
>>
>> 3. 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.
>>
>> 4. 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.
>>
>> 5. 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.
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>
>
>
>
> _______________________________________________
> 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.
>