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

[Member Services]

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.
>
>
>
>
>
>
>
>
>
>
>
>
>