[arin-ppml] Draft Policy 2009-3 (Global Proposal): Allocation ofIPv4 Blocks to Regional Internet Registries - Last Call
Martin Hannigan
marty at akamai.com
Wed Oct 28 18:43:08 EDT 2009
I'm encouraged that there is something resembling a policy. Since this
appears to be more than slight contextual edits of the originally
submitted policy I strongly encourage the authors to resubmit their
policy in this form to the other RIR forums for consensus and their
hopeful adoption.
Best Regards,
Martin Hannigan
NRO NC
On Oct 28, 2009, at 2:39 PM, Member Services wrote:
> The ARIN Advisory Council (AC) met on 23 October 2009 and decided to
> send a revised version of the following draft policy to last call:
>
> Draft Policy 2009-3 (Global Proposal): Allocation of IPv4 Blocks
> to
> Regional Internet Registries
>
> The AC met in accordance with the ARIN Policy Development Process
> which
> requires the AC to meet within 30 days of the conclusion of the Public
> Policy Meeting to make decisions about the draft policies that had
> been
> presented. The AC revised the draft. The AC removed sections B.1.d
> and B.4.
>
> B.1. “d. Legacy address space. IPv4 address space allocated or
> assigned
> prior to the creation of the RIR.”
>
> B. “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.”
>
> Feedback is encouraged during this last call period. All comments
> should
> be provided to the Public Policy Mailing List. This last call will
> expire on 13 November 2009. After last call the AC will conduct their
> last call review.
>
> The draft policy text is below and available at:
> https://www.arin.net/policy/proposals/
>
> The ARIN Policy Development Process is available at:
> https://www.arin.net/policy/pdp.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: 28 October 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.
>
> 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.
>
> 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.
>
> 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 obsolete. The RIRs may already, according to their
> individual policies and procedures, recover IPv4 address blocks of any
> size. However, current policy requires IANA to make allocations to the
> RIRs in blocks of /8. If any blocks smaller than /8 are returned to
> the
> IANA, current policy does not provide a way to allocate that space.
> This
> policy provides a mechanism for the RIRs to return 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.
>
> The original version of Global Policy Proposal for the Allocation of
> IPv4 Blocks to Regional Internet Registries (ARIN policy 2009-3) was
> proposed in the ARIN region, discussed on the Public Policy Mailing
> List
> (PPML), and by the Advisory Council (AC). A number of concerns were
> expressed, mostly related to the mandatory requirement to return
> reclaimed space to IANA. In an attempt to alleviate some of these
> concerns, the AC modified 2009-3 to make the return of non-legacy
> space
> to IANA optional. This version of the proposal was discussed at the
> April 2009 ARIN XXIII meeting in San Antonio. During that discussion,
> it became clear that there was not a consensus in the ARIN region for
> either the original proposal, or the modified legacy-only version.
>
> As a result of subsequent discussions of the global policy at the
> spring
> AfriNIC and LACNIC meetings, it became clear that one of the reasons
> 2009-3 is such a difficult policy to get consensus on is that the
> original policy, as proposed, is a global policy proposal that has
> some
> local policy aspects, namely that requires each RIR to return
> reclaimed
> space. Ideally, global policies are supposed to maintain a clean
> separation from local policies: global policy is supposed to only
> govern
> the relationship between the IANA and the RIRs, and local policy
> defines
> what the RIR can do internally. As a side effect of the blurring of
> global and local policy in the current revision of 2009-3, ARIN (and
> most of the other RIRs) have been having an interesting debate about
> exactly which space should be covered by the policy.
>
> To sidestep this issue, the changes made to the proposal are in the
> 2nd
> paragraph of section A:
>
> "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."
>
> The original version read:
>
> "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."
>
> The distinction is that under the revised version of 2009-3, recovered
> space is returned after it is designated for return under local
> policies
> and strategies. The original text dictated the terms of what must be
> returned (everything /24 or larger) as part of the global policy.
>
> Since global policy is supposed to only govern the relationship
> between
> the IANA and the RIRs, and local policy defines what the RIR can do
> internally. This change brings the proposal more in line with that
> definition of a global policy, and should address a number of other
> concerns as well.
>
> As this is a global policy, it will need to be reconciled with the
> version passed in the other RIRs. As this appears to be a substantive
> change, that most likely means the other RIRs will need to go back and
> pass the modified version as well.
>
> XXXXXXXXXXXXXXXXXXXXXXXXXXXXX
>
> Below are 3 exemplar scenarios of the execution of this policy after
> Phase II is in force. These are not part of the rationale but are
> provided for illustrative purposes.
>
> Example 1:
>
>
>
> On 1 March 2020, IANA has the equivalent of a /17 (32,768 addresses)
> worth of IPv4 addresses.
>
> 1. IANA calculates that 1/10 of this space is 3,276 addresses.
>
> 2. IANA rounds this down to the next bit boundary, which creates a
> minimum allocation size of /21 (2,048 addresses).
>
> 3. Each RIR can request and receive a single allocation unit
> equivalent
> to a /21 worth of addresses.
>
> 4. While IANA may not be able to allocate a contiguous /21 and can
> allocate noncontiguous smaller blocks equivalent to a /21 worth of
> addresses.
>
> Example 2:
>
> On 1 March 2020, IANA has the equivalent of a /20 (4,096 addresses)
> worth of IPv4 addresses.
>
> 1. IANA calculates that 1/10 of this space is 409 addresses.
>
> 2. IANA rounds this down to the next bit boundary, which creates a
> minimum allocation size of /24 (256 addresses).
>
> 3. Each RIR can request and receive a single allocation unit
> equivalent
> to a /24 worth of addresses.
>
> 4. As the minimum size of address space returned to IANA is /24, IANA
> can allocate a contiguous range of addresses that amount to a /24.
>
> Example 3:
>
> On 1 March 2020, IANA has the equivalent of a /21 (2,048 addresses)
> worth of IPv4 addresses.
>
> 1. IANA calculates that 1/10 of this space is 204 addresses.
>
> 2. IANA rounds this down to the next bit boundary, which creates a
> minimum allocation size of /25 (128 addresses).
>
> 3. A /25 is smaller than the minimum permissible allocation size under
> this policy. A /25 is smaller than the minimum permissible allocation
> size under this policy. Therefore, IANA is unable to make an
> allocation
> until more address space is received.
>
> XXXXXXXXXXXXXXXXXXXXXXXXXXXXX
>
> 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.
>
More information about the ARIN-PPML
mailing list