[arin-ppml] ARIN-prop-137 Global Policy for post exhaustion IPv4 allocation mechanisms by the IANA

Jeffrey Lyon jeffrey.lyon at blacklotus.net
Tue Mar 8 17:02:31 EST 2011


I presume this was proposed by IANA? It looks like something that
would result in IPv4 being shuffled out of the ARIN region and into
developing regions and those who will be slow to adopt IPv6. For
reasons that I cannot qualify at this moment, I feel that developing
regions will also be much slower than the ARIN region to adopt IPv6.

Jeff

On Tue, Mar 8, 2011 at 2:46 PM, ARIN <info at arin.net> wrote:
> ARIN-prop-137 Global Policy for post exhaustion IPv4 allocation
> mechanisms by the IANA
>
> ARIN received the following policy proposal and is posting it to the
> Public Policy Mailing List (PPML) in accordance with the Policy
> Development Process.
>
> The ARIN Advisory Council (AC) will review the proposal at their next
> regularly scheduled meeting (if the period before the next regularly
> scheduled meeting is less than 10 days, then the period may be extended
> to the subsequent regularly scheduled meeting). The AC will decide how
> to utilize the proposal and announce the decision to the PPML.
>
> The AC invites everyone to comment on the proposal on the PPML,
> particularly their support or non-support and the reasoning
> behind their opinion. Such participation contributes to a thorough
> vetting and provides important guidance to the AC in their deliberations.
>
> Draft Policies and Proposals under discussion can be found at:
> https://www.arin.net/policy/proposals/index.html
>
> The ARIN Policy Development Process can be found at:
> https://www.arin.net/policy/pdp.html
>
> Mailing list subscription information can be found
> at: https://www.arin.net/mailing_lists/
>
> Regards,
>
> Communications and Member Services
> American Registry for Internet Numbers (ARIN)
>
>
> ## * ##
>
>
> ARIN-prop-137 Global Policy for post exhaustion IPv4 allocation
> mechanisms by the IANA
>
> Proposal Originator: Philip Smith
>   co-authors: Alejandro Acosta, Nicolas Antoniello, S. Moonesamy,
>        Douglas Onyango, Medel Ramirez, Masato Yamanishi
>
> Proposal Version: 1
>
> Date: 8 March 2011
>
> Proposal type: new
>
> Policy term: permanent
>
> 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.
>
>
>
> _______________________________________________
> 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.
>



-- 
Jeffrey Lyon, Leadership Team
jeffrey.lyon at blacklotus.net | http://www.blacklotus.net
Black Lotus Communications - AS32421
First and Leading in DDoS Protection Solutions



More information about the ARIN-PPML mailing list