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

Chris Grundemann cgrundemann at gmail.com
Wed Sep 28 15:59:05 EDT 2011


Although this change is to the rationale only, I believe it is not
necessary and only serves to muddy the water wrt the global policy
process. I hope that we can remove this change and advance this policy
in a form identical to the other regions which have already (or are in
the process of) adopted it.

Cheers,
~Chris

PS - I-D draft-weil (the cause for this concern) is now set to become
a BCP which will update RFC 5735 / BCP 153 upon adoption
<https://tools.ietf.org/html/draft-weil-shared-transition-space-request>.


On Fri, Sep 23, 2011 at 12:19, ARIN <info at arin.net> wrote:
> Draft Policy ARIN-2011-9 (Global Proposal)
> Global Policy for post exhaustion IPv4 allocation mechanisms by the IANA
>
> ARIN-2011-9 has been revised. This draft policy is open for discussion
> on this mailing list and will be on the agenda at the upcoming ARIN
> Public Policy Meeting in Philadelphia.
>
> ARIN-2011-9 is below and can be found at:
> https://www.arin.net/policy/proposals/2011_9.html
>
> The following paragraph was added to the rationale:
>
> "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."
>
> Regards,
>
> Communications and 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: 22 September 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
>
> 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.
>
> 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.
> _______________________________________________
> 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.
>



-- 
@ChrisGrundemann
weblog.chrisgrundemann.com
www.burningwiththebush.com
www.theIPv6experts.net
www.coisoc.org



More information about the ARIN-PPML mailing list