[arin-ppml] Draft Policy 2011-9 (Global Proposal): Global Policy for post exhaustion IPv4 allocation mechanisms by the IANA

[David Farmer]

The following is being added to the Rationale of this Draft Policy to 
clarify the intent, and to make clear that the ARIN community has an 
expectation that this global policy is not intended to interfere with 
the IETF making IPv4 assignments for specialised address blocks. 
Including, the Shared Transition Space for which there is a different 
policy within ARIN Region awaiting Board and IETF action.

"The NRO must clarify that this Global Policy is not intended to 
supersede the IETF’s right to make IPv4 assignments for “specialised 
address blocks (such as multicast or anycast blocks)” as documented in 
section 4.3 of RFC 2860. The NRO and IANA should coordinate with the 
IETF to make such assignments as necessary, and honor any reservations 
made for works currently in progress."

Thanks

On 9/9/11 11:25 CDT, David Farmer wrote:
> A quick update on the status of this Global Policy in the other regions;
> This Global Policy has just recently entered into Last Call within the
> RIPE region, and the Last Call period recently ended with the AfriNIC
> region; Both the APNIC and LACNIC regions have approved the policy.
>
> As one of the shepherds for the proposal it would good to see some
> discussion on the list prior to our discussion in Philly.
>
> However, I would ask that we try to keep the subject of whether ARIN
> should return address space to IANA, or not, as a separate discussion.
> As our region requested, this policy has return of addresses to IANA as
> optional, therefore it not a global policy matter, it is a regional
> matter. This Global Policy is about how the global community wants IANA
> to distribute such returned addresses, as well as some minimal holdings
> IANA currently has, irrespective of how or whether each region returns
> space to IANA. Therefore, I request we consider this Global Policy
> separate from the issue of ARIN returning address space to IANA.
>
> If possible I would request that the separate regional issue of should
> ARIN return space to IANA happen on a separate email thread, and I will
> advocate for separate time at the PPM in Philly for such a discussion if
> the community feels it is necessary.
>
> Additionally, the RIPE Staff requested an IANA Staff evaluation for this
> global policy, so I am including it here in addition to the ARIN Staff
> evaluation that was sent out previously.
>
> If you would like to see the original RIPE email, it is at:
> http://www.ripe.net/ripe/maillists/archives/address-policy-wg/2011/msg00803.html
>
>
>> --------oooooooooo--------------
>>
>> IANA staff impact analysis of RIPE policy proposal 2011-01 ( Draft
>> Policy ARIN-2011-9)
>>
>> This analysis considers the impact of ratification of RIPE policy
>> proposal 2011-01 (as a part of GPP-IPv4-2011) by the ICANN Board of
>> Directors.
>>
>> 1. The policy would require ICANN, as the IANA function operator, to
>> establish a Recovered IPv4 Pool. The pool would have to include “any
>> fragments that may be left over in the IANA”. In order to do this,
>> ICANN staff would have to work closely with the five RIRs’ staffs to
>> make sure the initial pool included all fragments assigned to IANA. It
>> is not clear whether this policy proposal is intended to supersede the
>> IETF’s right to make IPv4 assignments for “specialised address blocks
>> (such as multicast or anycast blocks)” as documented in section 4.3 of
>> RFC 2860. This should be clarified but that can probably be done by
>> way of assertions from the NRO rather than a revision to the policy
>> text. In the event that the policy is intended to supersede RFC 2860
>> there is a potential issue with the internal reservation of small
>> blocks address blocks that have been informally reserved for IETF
>> standards track work currently in progress.
>>
>> 2. It would replace the current procedure for Updating legacy Class A
>> IPv4 allocations, which was agreed with the NRO in February 2007. This
>> is because the text includes a statement that “The Recovered IPv4 Pool
>> will initially contain any fragments that may be left over in the
>> IANA. It will also hold any space returned to the IANA by any other
>> means” and this presumably include address space returned directly by
>> registrants.
>>
>> 3. Once it was activated by an RIR declaring that it has less than a
>> /9 in its inventory, IANA would have to make the first allocation.
>> IANA would then have to make additional allocations on 1 March and 1
>> September each year, if there is enough address space left in the
>> pool. The minimum allocation size would be a /24 and the “allocation
>> unit” used in each allocation would be determined by dividing the
>> total pool by five and rounding down to the nearest CIDR boundary. As
>> an example, if the pool contained 27 /24s, each RIR would be allocated
>> a /22 (or the equivalent made from multiple /24 prefixes) because 5.4
>> /24s is not on a CIDR boundary. There is no text stating that the
>> “allocation units” must be a single prefix and so it seems reasonable
>> to make them up from a bundle of prefixes when necessary.
>>
>> 4. All address space added to the Recovered IPv4 Pool would be
>> registered as such in the IANA IPv4 Address Space Registry. Similarly,
>> allocations from the pool would also be registered. This would require
>> the granularity of registration to move from /8 boundaries as is
>> currently the case and as such could inflate the size of the registry
>> from 256 lines to several thousand.
>>
>>
>> --------oooooooooo--------------
>
> Thanks
>
> On 8/24/11 14:58 CDT, ARIN wrote:
>> Draft Policy ARIN-2011-9 (Global Proposal)
>> Global Policy for post exhaustion IPv4 allocation mechanisms by the IANA
>>
>>
>> On 18 August 2011 the ARIN Advisory Council (AC) selected "Global Policy
>> for post exhaustion IPv4 allocation mechanisms by the IANA" as a draft
>> policy for adoption discussion on the PPML and at the Public Policy
>> Meeting in Philadelphia in October.
>>
>> The draft was developed by the AC from policy proposal "ARIN-prop-137
>> Global Policy for post exhaustion IPv4 allocation mechanisms by the
>> IANA." Per the Policy Development Process the AC submitted text to ARIN
>> for a staff and legal assessment prior to its selection as a draft
>> policy. Below the draft policy is the ARIN staff and legal assessment,
>> followed by the text that was submitted by the AC.
>>
>> Draft Policy ARIN-2011-9 is below and can be found at:
>> https://www.arin.net/policy/proposals/2011_9.html
>>
>> You are encouraged to discuss Draft Policy 2011-9 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.
>>
>> 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 ARIN-2011-9 (Global Proposal)
>> Global Policy for post exhaustion IPv4 allocation mechanisms by the IANA
>>
>> Date: 24 August 2011
>>
>> Policy statement:
>>
>> The IANA shall establish a Recovered IPv4 Pool to be utilized post
>> RIR IPv4 exhaustion. The Recovered IPv4 Pool will initially contain
>> any fragments that may be left over in the IANA. It will also hold
>> any space returned to the IANA by any other means.
>> The Recovered IPv4 Pool will be administered by the IANA. It will
>> contain:
>> a. Any fragments left over in the IANA inventory after the last
>> /8s of IPv4 space are delegated to the RIRs
>>
>> The IANA inventory excludes "Special use IPv4 addresses" as
>> defined in BCP 153 and any addresses allocated by the IANA
>> for experimental use.
>>
>> b. Any IPv4 space returned to the IANA by any means.
>> The Recovered IPv4 Pool will stay inactive until the first RIR has
>> less than a total of a /9 in its inventory of IPv4 address space.
>> When one of the RIRs declares it has less than a total of a /9 in
>> its inventory, the Recovered IPv4 pool will be declared active, and
>> IP addresses from the Recovered IPv4 Pool will be allocated as
>> follows:
>> a. Allocations from the IANA may begin once the pool is declared
>> active.
>> b. In each "IPv4 allocation period", each RIR will receive a
>> single "IPv4 allocation unit" from the IANA.
>> c. An "IPv4 allocation period" is defined as a 6-month period
>> following 1 March or 1 September in each year.
>> d. The IANA will calculate the size of the "IPv4 allocation unit"
>> at the following times:
>>
>> When the Recovered IPv4 Pool is first activated
>> At the beginning of each IPv4 allocation period
>>
>> To calculate the "IPv4 allocation unit" at these times, the
>> IANA will use the following formula:
>> IPv4 allocation unit = 1/5 of Recovered IPv4 pool,
>> rounded down to the next CIDR
>> (power-of-2) boundary.
>> No RIR may get more than this calculation used to determine
>> the IPv4 allocation unit even when they can justify a need for
>> it.
>> The minimum "IPv4 allocation unit" size will be a /24. If the
>> calculation used to determine the IPv4 allocation unit results
>> in a block smaller than a /24, the IANA will not distribute
>> any addresses in that IPv4 allocation period.
>> The IANA may make public announcements of IPv4 address
>> 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:
>>
>> The policy provides a mechanism for the ongoing distribution of
>> IPv4 address space, while removing the areas that have been
>> problematic in previous attemts at this proposal. The proposal:
>>
>> - Permits regional variation in runout policy amongst RIRs to
>> be accounted for in the distribution of the Recovered IPv4 Pool
>>
>> - Prevents the possibility of a single RIR being eligible to
>> be allocated the entire Recovered IPv4 Pool in the first
>> (and perhaps only) allocation period
>>
>> - Removes two areas of policy that have failed to reach
>> agreement in previous attempts at this proposal:
>>
>> - How addresses should be placed in the Recovered IPv4 Pool
>> - References to how transfers should or should not take
>> place
>>
>> Timetable for implementation:
>>
>> Once consensus has been reached in each of the 5 RIR regions, the
>> policy will be forwarded to ICANN for approval and then implemented
>> by the IANA.
>>
>>
>> #####
>>
>>
>> STAFF ASSESSMENT
>>
>> ARIN STAFF ASSESSMENT
>>
>> Proposal: ARIN-prop-137 Global Policy for post exhaustion IPv4
>> allocation mechanisms by the IANA
>>
>> Date of Assessment: 18 August 2011
>>
>> 1. Proposal Summary (Staff Understanding)
>>
>> IANA issued the last /8s in February 2011. There is no global policy for
>> IANA to allocate address space to the RIRs that is smaller than a /8.
>> The proposal tells IANA to set up a recovered address space pool, accept
>> returns by any means, and allocate address space to the RIRs in equal
>> amounts, twice a year, minimum /24.
>>
>> 2. Comments
>>
>> A. ARIN Staff Comments
>>
>> • This proposal would fill a policy gap. It would allow the RIRs to
>> return IPv4 address blocks smaller than a /8 to the IANA for equal
>> redistribution amongst the RIRs.
>>
>> B. ARIN General Counsel
>>
>> This policy poses no significant legal risks and is a useful advancement.
>>
>>
>> 3. Resource Impact
>>
>> This policy would have minimal resource impact from an implementation
>> aspect. Since this is a global policy proposal it would be implemented
>> after ratification by the ICANN Board. The following would be needed in
>> order to implement:
>>
>> • Updated guidelines
>> • Staff training
>>
>> 4. Proposal Text
>>
>> ARIN-prop-137
>> Global Policy for post exhaustion IPv4 allocation mechanisms by the IANA
>>
>> Policy statement:
>>
>> The IANA shall establish a Recovered IPv4 Pool to be utilized post
>> RIR IPv4 exhaustion. The Recovered IPv4 Pool will initially contain
>> any fragments that may be left over in the IANA. It will also hold
>> any space returned to the IANA by any other means.
>> The Recovered IPv4 Pool will be administered by the IANA. It will
>> contain:
>> a. Any fragments left over in the IANA inventory after the last
>> /8s of IPv4 space are delegated to the RIRs
>>
>> The IANA inventory excludes "Special use IPv4 addresses" as
>> defined in BCP 153 and any addresses allocated by the IANA
>> for experimental use.
>>
>> b. Any IPv4 space returned to the IANA by any means.
>> The Recovered IPv4 Pool will stay inactive until the first RIR has
>> less than a total of a /9 in its inventory of IPv4 address space.
>> When one of the RIRs declares it has less than a total of a /9 in
>> its inventory, the Recovered IPv4 pool will be declared active, and
>> IP addresses from the Recovered IPv4 Pool will be allocated as
>> follows:
>> a. Allocations from the IANA may begin once the pool is declared
>> active.
>> b. In each "IPv4 allocation period", each RIR will receive a
>> single "IPv4 allocation unit" from the IANA.
>> c. An "IPv4 allocation period" is defined as a 6-month period
>> following 1 March or 1 September in each year.
>> d. The IANA will calculate the size of the "IPv4 allocation unit"
>> at the following times:
>>
>> When the Recovered IPv4 Pool is first activated
>> At the beginning of each IPv4 allocation period
>>
>> To calculate the "IPv4 allocation unit" at these times, the
>> IANA will use the following formula:
>> IPv4 allocation unit = 1/5 of Recovered IPv4 pool,
>> rounded down to the next CIDR
>> (power-of-2) boundary.
>> No RIR may get more than this calculation used to determine
>> the IPv4 allocation unit even when they can justify a need for
>> it.
>> The minimum "IPv4 allocation unit" size will be a /24. If the
>> calculation used to determine the IPv4 allocation unit results
>> in a block smaller than a /24, the IANA will not distribute
>> any addresses in that IPv4 allocation period.
>> The IANA may make public announcements of IPv4 address
>> 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:
>>
>> The policy provides a mechanism for the ongoing distribution of
>> IPv4 address space, while removing the areas that have been
>> problematic in previous attemts at this proposal. The proposal:
>>
>> - Permits regional variation in runout policy amongst RIRs to
>> be accounted for in the distribution of the Recovered IPv4 Pool
>>
>> - Prevents the possibility of a single RIR being eligible to
>> be allocated the entire Recovered IPv4 Pool in the first
>> (and perhaps only) allocation period
>>
>> - Removes two areas of policy that have failed to reach
>> agreement in previous attempts at this proposal:
>>
>> - How addresses should be placed in the Recovered IPv4 Pool
>> - References to how transfers should or should not take
>> place
>>
>> Timetable for implementation:
>>
>> Once consensus has been reached in each of the 5 RIR regions, the
>> policy will be forwarded to ICANN for approval and then implemented
>> by the IANA.
>

-- 
===============================================
David Farmer               Email:farmer at umn.edu
Networking & Telecommunication Services
Office of Information Technology
University of Minnesota	
2218 University Ave SE	    Phone: 612-626-0815
Minneapolis, MN 55414-3029   Cell: 612-812-9952
===============================================