Re: [sig-policy] prop-086-v003: Global Policy for IPv4 Allocations by th
get some real feedback on this proposal here on the list, pre-meeting.
Cheers,
~Chris
On Fri, Feb 18, 2011 at 02:15, Gaurab Raj Upadhaya <gaurab at lahai dot com> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Dear SIG members,
>
> Version 3 of the proposal, 'Global Policy for IPv4 Allocations by the
> IANA Post Exhaustion', has been sent to the Policy SIG for review. It
> will be presented at the Policy SIG at APNIC 31 in Hong Kong SAR,
> China, 21-25 February 2011.
>
> Changes in version 3:
>
> - An author has been removed.
>
> We invite you to review and comment on the proposal on the mailing list
> before the meeting.
>
> The comment period on the mailing list before an APNIC meeting is an
> important part of the policy development process. We encourage you to
> express your views on the proposal:
>
> - Do you support or oppose this proposal?
> - Does this proposal solve a problem you are experiencing? If
> so, tell the community about your situation.
> - Do you see any disadvantages in this proposal?
> - Is there anything in the proposal that is not clear?
> - What changes could be made to this proposal to make it more
> effective?
>
>
> Information about this and other policy proposals is available from:
>
> http://www.apnic.net/policy/proposals
>
> Gaurab, Ching-Heng, and Terence
>
> ________________________________________________________________________
>
> prop-086-v003: Global Policy for IPv4 Allocations by the IANA Post
> Exhaustion
> ________________________________________________________________________
>
> Authors: Steve Bertrand <steve at ipv6canada dot com>
> Chris Grundemann <cgrundemann at gmail dot com>
> Aaron Hughes <ahughes at bind dot com>
> Louie Lee <louie at equinix dot com>
> Matt Pounsett <matt at conundrum dot com>
> Jason Schiller <schiller at uu dot net>
>
> Note: The above individuals donated their time, resources and
> effort to develop this proposal on behalf of the
> Internet Community.
>
> Version: 3
>
> Date: 18 February 2011
>
>
> 1. Introduction
> - ----------------
>
> This policy defines the process for the allocation of IPv4 addresses
> post "Exhaustion Phase" [1].
>
> A global policy is required in order for the IANA to be able to
> transparently continue to be able to allocate IPv4 addresses beyond
> exhaustion. In order to fulfill the requirements of this policy, the
> IANA must set up a reclamation pool to hold addresses in and distribute
> from in compliance with this policy. This policy establishes the
> process by which IPv4 addresses can be returned to and re-issued from
> the IANA post Exhaustion Phase.
>
> This document does not stipulate performance requirements in the
> provision of services by the IANA to an RIR in accordance with this
> policy. Such requirements should be specified by appropriate agreements
> among the RIRs and ICANN.
>
> The intent of this policy is as follows:
>
> - To include all post Exhaustion Phase IPv4 address space returned
> to the IANA.
> - Allows allocations by the IANA from the Reclamation Pool once the
> Exhaustion Phase has been completed.
> - Defines "need" as the basis for further IPv4 allocations by the
> IANA.
> - Does not differentiate any class of IPv4 address space unless
> otherwise defined by an RFC.
> - Encourage the return of IPv4 address space by making this
> allocation process available.
> - Disallow transfers of addresses sourced from the Reclamation Pool
> in the absence of an IPv4 Global Transfer Policy to neutralize
> transfer process inequities across RIR regions.
> - Applies to legacy IPv4 Address Space initially allocated by the
> IANA to users including the allocations to RIRs.
> - Includes any length of fragments currently held by the IANA now or
> in the future.
>
>
> 2. Definitions
> - ---------------
>
> IANA: Internet Assigned Numbers Authority, or its successor
>
> ICANN: Internet Corporation for Assigned Names and Numbers, or
> its successor
>
> RIR: Regional Internet Registry as recognized by ICANN
>
> MoU: Memorandum of Understanding between ICANN and the RIRs
>
> IPv4: Internet Protocol Version Four(4), the target protocol
> of this Global Policy
>
> Free Space Pool: IPv4 Addresses that are in inventory at any RIR, and/or
> the IANA
>
>
> 3. Summary of the current problem
> - ----------------------------------
>
> 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 moot. The RIRs may, according to their individual
> policies and procedures, recover IPv4 address space. This policy
> provides a mechanism for the RIRs to retro allocate the 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.
>
> This policy proposal addresses the issues raised with the previous
> policy proposal prop-069, which the authors agree will not gain
> global consensus without significant revision.
>
>
> 4. Situation in other RIRs
> - ---------------------------
>
> This proposal is being submitted in all RIR regions, with a view to
> becoming a global policy [1].
>
> - - AfriNIC
>
> Submitted. Presented at AfriNIC 13. However, due to a change in the
> text of the proposal within a week of the meeting, consensus could
> not be obtained. Returned for further discussion on mailing list,
> and to be presented at AfriNIC 14.
>
> http://www.afrinic.net/docs/policies/AFPUB-2010-v4-006.htm
>
>
> - - ARIN
>
> Submitted. The ARIN Address Council has recommended adoption.
>
> https://www.arin.net/policy/proposals/2010_10.html
>
>
> - - LACNIC
>
> Submitted. Presented at LACNIC XIV. Returned to the mailing list for
> further discussion.
>
> http://www.lacnic.net/documentos/politicas/LAC-2010-04-propuesta-en.pdf
>
>
> - - RIPE
>
> Submitted. Under initial discussion.
>
> http://www.ripe.net/ripe/policies/proposals/2010-05.html
>
>
> 5. Details
> - -----------
>
> 5.1 Reclamation Pool
>
> Upon adoption of this IPv4 address policy by the ICANN Board of
> Directors, the IANA shall establish a Reclamation Pool to be
> utilized post RIR IPv4 exhaustion as defined in Section 4. The
> reclamation pool will initially contain any fragments that may be
> left over in IANA inventory. As soon as the first RIR exhausts its
> inventory of IP address space, this Reclamation Pool will be
> declared active. When the Reclamation Pool is declared active, the
> Global Policy for the Allocation of the Remaining IPv4 Address
> Space [3] and Policy for Allocation of IPv4 Blocks to Regional
> Internet Registries [4] will be formally deprecated.
>
>
> 5.2 Returning Address Space to the IANA
>
> The IANA will accept into the Reclamation Pool all eligible IPv4
> address space that are offered for return. Eligible address space
> includes addresses that are not designated as "special use" by an
> IETF RFC or addresses allocated to RIRs unless they are being
> returned by the RIR that they were orignally allocated to. Legacy
> address holders may return address space directly to the IANA if
> they so choose.
>
>
> 5.3 Address Allocations from the Reclamation Pool by the IANA
>
> Allocations from the Reclamation Pool may begin once the pool is
> declared active. Addresses in the Reclamation Pool will be
> allocated on a CIDR boundary equal to or shorter than the longest
> minimum allocation unit of all RIRs in order to complete these
> allocations. The Reclamation Pool will be divided on CIDR
> boundaries and distributed evenly to all eligible RIRs. Any
> remainder not evenly divisible by the number of eligible RIRs based
> on a CIDR boundary equal to or shorter than the longest minimum
> allocation unit of all RIRs will remain in the Reclamation Pool.
> Addresses that are left over will be held in the Reclamation Pool
> until additional IP addresses can be returned to rejoin addresses
> on CIDR boundaries to the Reclamation Pool or a minimum allocation
> unit is set to allow allocation from existing inventory.
>
>
> 5.4 RIR Eligibility for Receiving Allocations from the Reclamation Pool
>
> Upon the exhaustion of an RIR's free space pool and after receiving
> their final /8 from the IANA [3], an RIR will become eligible to
> request address space from the IANA Reclamation Pool when it
> publicly announces via its respective global announcements email
> list and by posting a notice on its website that it has exhausted
> its supply of IPv4 address space. An RIR is considered at
> exhaustion when the inventory is less than the equivalent of a
> single /8 and is unable to further allocate or assign address
> space to its customers in units equal to or shorter than the
> longest of that RIR's policy defined minimum allocation unit. Any
> RIR that is formed after the ICANN Board of Directors has ratified
> this policy is not eligible to utilize this policy to obtain IPv4
> address space from the IANA.
>
>
> 5.5 Reporting Requirements
>
> The IANA shall publish on at least a weekly basis a report that is
> publicly available which at a minimum details all address space that
> has been received and that has been allocated. The IANA shall
> publish a Returned Address Space Report which indicates what
> resources were returned, by whom and when. The IANA shall publish an
> Allocations Report on at least a weekly basis which at a minimum
> indicates what IPv4 address space has been allocated, which RIR
> received the allocation and when. The IANA shall publish a public
> notice confirming RIR eligibility subsequent to Section 5.4.
>
>
> 5.6 No Transfer Rights
>
> Address space assigned from the Reclamation Pool may be transferred
> if there is either an ICANN Board ratified global policy or globally
> coordinated RIR policy specifically written to deal with transfers
> whether inter-RIR or from one entity to another. Transfers must meet
> the requirements of such a policy. In the absence of such a policy,
> no transfers of any kind related to address space allocated or
> assigned from the reclamation pool is allowed.
>
>
> 5. Pros/Cons
> - -------------
>
> 5.1 Advantages
>
> - The policy provides a mechanism for the ongoing distribution of
> IPv4 address space.
>
>
> 5.2 Disadvantages
>
> - None identified.
>
>
> 6. Effect on APNIC Members
> - ---------------------------
>
> This policy governs the allocation relationship between the IANA and
> the RIRs. It does not imply any change to allocation relationships
> between APNIC and its members.
>
>
> 7. Effect on NIRs
> - ------------------
>
> This policy governs the allocation relationship between the IANA and
> the RIRs. It does not imply any change to allocation relationships
> between APNIC and NIRs.
>
>
> 8. References
> - -------------
>
> [1] IANA, Global Policy for the Allocation of the Remaining IPv4 Address
> Space
> http://www.icann.org/en/general/allocation-remaining-ipv4-space.htm
>
> [2] ICANN Address Supporting Organization (ASO) MoU
> http://aso.icann.org/documents/memorandum-of-understanding
>
> [3] Global Policy for the Allocation of the Remaining IPv4 Address Space
> http://www.icann.org/en/general/allocation-remaining-ipv4-space.htm
>
> [4] Policy for Allocation of IPv4 Blocks to Regional Internet Registries
> http://aso.icann.org/wp-content/uploads/2009/09/aso-001-2.pdf
>
> - --
>
> http://www.gaurab.org.np/
>
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG/MacGPG2 v2.0.16 (Darwin)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
>
> iEYEARECAAYFAk1eOJkACgkQSo7fU26F3X0HmQCfdBeJBA4vZObSZxHoWskzMBVx
> mesAoPrQoBR6AJZ7GJ9TkeJaBEZhK2EW
> =wY+r
> -----END PGP SIGNATURE-----
> * sig-policy: APNIC SIG on resource management policy *
> _______________________________________________
> sig-policy mailing list
> sig-policy at lists dot apnic dot net
> http://mailman.apnic.net/mailman/listinfo/sig-policy
>
--
@ChrisGrundemann
weblog.chrisgrundemann.com
www.burningwiththebush.com
www.theIPv6experts.net
www.coisoc.org