Re: [sig-policy] prop-086: Global policy for IPv4 allocations by the IAN
> Hi, I have two clarification questions to the authors.
Izumi-san,
I apologize personally for the delay in my response. I have
consulted with the rest of the authors to craft the reply below.
> 1.
> Is this policy intended to create a framework to allow
> re-allocation mechanism by IANA to RIRs, rather than expecting
> the actual re-clamation and re-allocations to take place
> actively?
>
> (I see that the return of unused address is not mandatory and
> wasn't sure how much it would be used in the actual practice)
Yes, this policy is primarily intended to create this framework
so that re-allocations are possible even if IANA has blocks
smaller than the /8 size that the currently active policy allows.
We have already seen space returned to IANA by ARIN in the past.
The policy attempts to provide a way to redistribute returned
address space in a fair manner. The authors understand from
the community that the topic of mandatory return on unused
address space was a major issue that is preventing prop-069 from
becoming a global policy. By removing that point and allowing
the communities from each region to determine when and how to
return address space, we remove the regional-based issues from
global considerations.
> 2.
> I'd like to understand what it means by ;
>
> "The Reclamation Pool will be divided on CIDR boundaries and
> distributed evenly to all eligible RIRs."in section 5.3.
>
> Does this mean that once an RIR makes a public announcement
> about the exhausition of its free space pool, that RIR can
> constantly receive address space from IANA, everytime its
> Reclamation Pool gets filled up?
>
> (i.e., even if they haven't fully utilized the previous
> allocation from the IANA Reclamation Pool, all "eligible RIRs"
> can receive allocations)
An RIR would become eligible when it has exhausted its address
space by the definition offered in this policy proposal.
However, its exhaustion status will be removed if it comes
into some address space if its members returns usable address
space. That RIR will no longer be eligible again for address
space from IANA until it has again exhausted the new space it
now holds. This helps prevent any RIR from limiting reclamation
efforts prior to reaching exhaustion. It also limits an RIR from
unfairly receiving address space from IANA when it still has
available space to allocate to its members.
Some feedback that we've received suggest that we should add a
clause to not count address space set aside under "soft landing"
policies so as not to disadvantage any region that is trying to
do the smart thing for its members.
By the way, it was suggested that ARIN is the only one that
will qualify for IANA space because it has no such soft landing
policy for the last /8. However, ARIN does have a policy to set
aside a /10 for transition purposes, but it was not designated
specifically to be in the last /8. This actually allows some
flexibility to assign transition space before ARIN knows which /8
it will get.
> thanks,
> Izumi
And thank you for your thoughtful questions.
Please feel free to reply on list so that all the authors may
provide further responses. As I'm unable to be onsite today,
Kenny Huang and Owen DeLong is assisting us for the presentation.
However, I will be available to the audience via Skype. Also,
some authors will be participating via remote facilities.
Best Regards,
Louie
--
Louie Lee
One of the authors of prop-086
> Randy Bush wrote:
> > Dear SIG members,
> >
> > The following 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 30.
> >
> > 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 policy proposal is available at:
> >
> > http://www.apnic.net/policy/proposals/prop-086
> >
> > randy, Ching-Heng, and Terence
> >
> >
> > ________________________________________________________________________
> >
> > prop-086-v001: 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>
> > Martin Hannigan <marty at akamai 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: 1
> >
> > Date: 23 July 2010
> >
> >
> > 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].
> >
> >
> > 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. 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.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/index.html
> >
> >
> > [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
> > * sig-policy: APNIC SIG on resource management policy *
