[AfriNIC-rpd] Proposal: Global Policy for IPv4 Allocations by the IANA Post Exhaustion now online

Thu Nov 25 10:13:46 UTC 2010

I support the policy. I understand that some of our procedures have not
been adhered to... but see no reason to delay or scuttle the process.

No one seems to have a substantial disagreement with the policy - just
the way we got here.

Lets move it forward - agree - last call - etc.

On Fri, 2010-08-27 at 17:20 +0400, Mukom Akong T. wrote:
> Hello all,
> 
> The proposal is now up on the website and can be assessed at
> http://www.afrinic.net/docs/policies/AFPUB-2010-v4-003.htm
> 
> Thanks
> 
> On 8/25/10 10:16 PM, Steve Bertrand wrote:
> > 8<---------------------------------->8
> >
> >     Your Name:
> > 		Steve Bertrand
> > 		Chris Grundemann
> > 		Martin Hannigan
> > 		Aaron Hughes
> > 		Louie Lee
> > 		Matt Pounsett
> > 		Jason Schiller
> >     Your Organisation:
> >     Policy Afected:
> >     Date: 2010-08-25
> >     Proposal:Global Policy for IPv4 Allocations by the IANA Post
> >     Exhaustion
> >     Incentive: Allow all IPV4 inventory regardless of prefix size to be
> >                returned to, and subsequently reallocated fairly and
> >                equitably by the IANA post-runout.
> >
> > 8<--------------------------------->8
> >
> > Global Policy for IPv4 Allocations by the IANA Post Exhaustion
> >
> > Rationale:
> >
> > 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.
> >
> > 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.
> >
> > 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 RIR's 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.
> >
> > 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.
> >
> > 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. Exhaustion is defined as an inventory of less than the equivalent
> > of a single /8 and the inability to further assign address space to its
> > customers in units equal to or shorter than the longest of any 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. 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 4.
> >
> > 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.
> >
> > 7. 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
> >
> > 8. Contributors
> >
> > The following individuals donated their time, resources and effort to
> > develop this proposal on behalf of the Internet Community:
> >
> > Steve Bertrand <steve at ipv6canada.com>
> > Chris Grundemann <cgrundemann at gmail.com>
> > Martin Hannigan <marty at akamai.com>
> > Aaron Hughes <ahughes at bind.com>
> > Louie Lee <louie at equinix.com>
> > Matt Pounsett <matt at conundrum.com>
> > Jason Schiller <schiller at uu.net>
> >
> > 9. References
> >
> > 1. http://www.icann.org/en/general/allocation-remaining-ipv4-space.htm
> > Global Policy for the Allocation of the Remaining IPv4 Address Space,
> > IANA, Retrieved 27 April 2010
> >
> > 2. http://aso.icann.org/documents/memorandum-of-understanding/index.html
> > ICANN Address Supporting Organization (ASO) MoU , Retrieved 27 May 2010.
> >
> > 3. http://www.icann.org/en/general/allocation-remaining-ipv4-space.htm
> > Global Policy for the Allocation of the Remaining IPv4 Address Space
> >
> > 4. http://aso.icann.org/wp-content/uploads/2009/09/aso-001-2.pdf Policy
> > for Allocation of IPv4 Blocks to Regional Internet Registries
> > _______________________________________________
> > rpd mailing list
> > rpd at afrinic.net
> > https://lists.afrinic.net/mailman/listinfo.cgi/rpd
> >
> >   
> 

-- 
  .  .     ___. .__      Posix Systems - Sth Africa
 /| /|       / /__       mje at posix.co.za  -  Mark J Elkins, Cisco CCIE
/ |/ |ARK \_/ /__ LKINS  Tel: +27 12 807 0590  Cell: +27 82 601 0496

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 4490 bytes
Desc: not available
URL: <https://lists.afrinic.net/pipermail/rpd/attachments/20101125/6d6e203f/attachment.bin>