Keyboard Shortcuts
Thread View
j
: Next unread messagek
: Previous unread messagej a
: Jump to all threadsj l
: Jump to MailingList overview

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@ipv6canada.com Chris Grundemann cgrundemann@gmail.com Martin Hannigan marty@akamai.com Aaron Hughes ahughes@bind.com Louie Lee louie@equinix.com Matt Pounsett matt@conundrum.com Jason Schiller schiller@uu.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

Hi, I have two clarification questions to the authors.
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)
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)
thanks, Izumi
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@ipv6canada.com Chris Grundemann cgrundemann@gmail.com Martin Hannigan marty@akamai.com Aaron Hughes ahughes@bind.com Louie Lee louie@equinix.com Matt Pounsett matt@conundrum.com Jason Schiller schiller@uu.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
- 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.
- 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
- 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.
- Situation in other RIRs
This proposal is being submitted in all RIR regions, with a view to becoming a global policy [1].
- 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.
- Pros/Cons
5.1 Advantages
- The policy provides a mechanism for the ongoing distribution of IPv4 address space.
5.2 Disadvantages
- None identified.
- 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.
- 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.
- 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 *
sig-policy mailing list sig-policy@lists.apnic.net http://mailman.apnic.net/mailman/listinfo/sig-policy

On Mon, Aug 02, 2010 at 04:26:04AM -0700, Izumi Okutani wrote:
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.
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.
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

I have a few concerns about the proposal, in-line...
- Introduction
This policy defines the process for the allocation of IPv4 addresses post "Exhaustion Phase" [1].
Why are we trying to prolong the use of IPv4 even past the end? Just curious as the text doesn't say why we want/need to do this.
- 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.
Why would, and what's the incentive for, the RIRs to return IPv4 address space to the IANA?
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.
The proposal in 5.3 says that the reclamation pool is divided equally amongst RIRs - which contradicts the above para.
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.
I understood that IANA was exhausting its entire pool. Or is exhaustion really just complete /8s? It would be helpful if someone from IANA could clarify as I was under the impression that remaining fragments would be distributed as well, certainly before IANA declared that the cupboard was bare. The remaining fragments are not insignificant.
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.
"Longest minimum allocation" doesn't parse very well, and indeed the first two words contradict each other. Perhaps it would be clearer to say "smallest minimum allocation".
The Reclamation Pool will be divided on CIDR boundaries and distributed evenly to all eligible RIRs. Any
So each time when, say ARIN, pushes the button for the policy, and gets a /19, the other 4 RIRs will each get a /19 as well? Even if they don't need it? This seems an unusual method of address space distribution - maybe we should have thought about this at the start of IPv4 20+ years ago. ;-)
It also means that the RIRs who have actually implemented runout policies (eg APNIC) for the final /8 will start stockpiling extra address space. Remind me what the incentive was for returning unused address space to IANA? This seems like a contradiction.
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.
Again "longest minimum" doesn't make a lot of sense (to me anyway). Also, exhaustion means "nothing left", not "1 month's supply" in the case of APNIC. Or "2 year's supply" in the case of AfriNIC. Etc.
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.
This seems grossly unfair and unreasonable. What if, for example, a new RIR is formed in the Middle East. Do you seriously think that this new RIR should be denied any IPv4 address space at all, especially when the rest of the world is still trying to share IPv4 address space amongst the folks who too lazy to move onwards?
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.
Don't they do this already for the existing IANA allocations? As do the RIRs. (I guess this is making sure that IANA doesn't stop doing it.)
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.
The reason for banning transfers is...?
APNIC has a policy allowing transfers between account holders. I don't think that this policy can simply march in and take over the existing transfer policy proposal like this. I'd rather see a separate proposal covering transfers after this one gains consensus. (Or it could be done in parallel I suppose.)
- Pros/Cons
5.1 Advantages
- The policy provides a mechanism for the ongoing distribution of IPv4 address space.
Why do we need ongoing distribution of IPv4 address space? I'd have hoped that the policy proposal would have explained this somewhere.
5.2 Disadvantages
- None identified.
See above. There are many.
philip --

Hi Philip,
On 16 Aug 2010, at 4:37, Philip Smith wrote:
[...]
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.
I understood that IANA was exhausting its entire pool. Or is exhaustion really just complete /8s? It would be helpful if someone from IANA could clarify as I was under the impression that remaining fragments would be distributed as well, certainly before IANA declared that the cupboard was bare. The remaining fragments are not insignificant.
I can't speak for the authors but I can describe what we "have in stock" and what the ratified policies allows us to do. The only IPv4 address blocks we have with an UNALLOCATED status are whole /8s. Further, the current policy we implement only allows us to allocate /8s:
" * The IANA will allocate IPv4 address space to the RIRs in /8 units." -- http://www.icann.org/en/general/allocation-IPv4-rirs.html
Similarly, the policy for allocating the last blocks required that they be allocated in /8s, too:
"IANA will automatically allocate the reserved IPv4 allocation units to each RIR (one /8 to each one)" -- http://www.icann.org/en/general/allocation-remaining-ipv4-space.htm
My personal interpretation of the text above was the the "Reclamation Pool" would only be a potential pool unless and until one of the RIRs found that they no longer needed the IPv4 address space they were recovering and could return it to IANA for re-distribution. If I've misunderstood the authors' intentions I am sure that they will correct me.
Kind regards,
Leo Vegoda

Hi Leo,
Thanks for jumping in so quickly with your reply. :-)
Leo Vegoda said the following on 17/08/10 03:54 :
I can't speak for the authors but I can describe what we "have in stock" and what the ratified policies allows us to do. The only IPv4 address blocks we have with an UNALLOCATED status are whole /8s. Further, the current policy we implement only allows us to allocate /8s:
" * The IANA will allocate IPv4 address space to the RIRs in /8 units." -- http://www.icann.org/en/general/allocation-IPv4-rirs.html
Yes, I saw that, but so far I've been interpreting a /8 unit as address space amounting to a /8, not a whole contiguous piece. Hmm, a unit is not lots of little pieces, is it. :-( Perhaps it should have said contiguous rather than unit. Oh well.
Nothing to do with the policy proposal, but what happens to the small pieces you have left?
Do you/we need a policy proposal to allow IANA to allocate smaller pieces to the RIRs?
Thanks!
philip --

Hi Philip,
On 17 Aug 2010, at 1:22, Philip Smith wrote:
[...]
I can't speak for the authors but I can describe what we "have in stock" and what the ratified policies allows us to do. The only IPv4 address blocks we have with an UNALLOCATED status are whole /8s. Further, the current policy we implement only allows us to allocate /8s:
" * The IANA will allocate IPv4 address space to the RIRs in /8 units." -- http://www.icann.org/en/general/allocation-IPv4-rirs.html
Yes, I saw that, but so far I've been interpreting a /8 unit as address space amounting to a /8, not a whole contiguous piece. Hmm, a unit is not lots of little pieces, is it. :-( Perhaps it should have said contiguous rather than unit. Oh well.
Nothing to do with the policy proposal, but what happens to the small pieces you have left?
Which small pieces?
Do you/we need a policy proposal to allow IANA to allocate smaller pieces to the RIRs?
That's for the SIG to reach a consensus on (or not).
Regards,
Leo

On Tue, Aug 17, 2010 at 01:22:10AM -0700, Philip Smith wrote:
Hi Leo,
Thanks for jumping in so quickly with your reply. :-)
Yes, thank so much, Leo!
Leo Vegoda said the following on 17/08/10 03:54 :
I can't speak for the authors but I can describe what we "have in stock" and what the ratified policies allows us to do. The only IPv4 address blocks we have with an UNALLOCATED status are whole /8s. Further, the current policy we implement only allows us to allocate /8s:
" * The IANA will allocate IPv4 address space to the RIRs in /8 units." -- http://www.icann.org/en/general/allocation-IPv4-rirs.html
Yes, I saw that, but so far I've been interpreting a /8 unit as address space amounting to a /8, not a whole contiguous piece. Hmm, a unit is not lots of little pieces, is it. :-( Perhaps it should have said contiguous rather than unit. Oh well.
I suppose that an organization will attempt to return enough address space amounting to a /8 but is not contiguous in any way whether it falls on the /8 bit boundary or not. (Technically, contiguous doesn't imply falling on the bit boundary, but it can for the purposes of this discussion.)
This is probably unlikely to happen in the timeframe prior to IANA exhaustion at this point. But the policy proposal will be able to handle that issue once that point has been reached.
Do you/we need a policy proposal to allow IANA to allocate smaller pieces to the RIRs?
In another response, I indicated that we feel if there is any free space held by the IANA at all, it should be given to any RIR that has exhausted its supply so that the address get used.
Best Regards, Louie

On Mon, Aug 16, 2010 at 04:37:50AM -0700, Philip Smith wrote:
I have a few concerns about the proposal, in-line...
I apologize personally for the delay in my response. I have consulted with the rest of the authors to craft the reply below.
- Introduction
This policy defines the process for the allocation of IPv4 addresses post "Exhaustion Phase" [1].
Why are we trying to prolong the use of IPv4 even past the end? Just curious as the text doesn't say why we want/need to do this.
Sorry for not being more clear about this.
If there is IPv4 address space available at the IANA, it should be distributed to the RIR's to be utilized as the community sees fit. It is our belief that it would be used to help facilitate transition and to be a small help in avoiding participating in costly address markets.
We also believe that our stewardship of IPv4 address space will be called into question if any region has exhausted their address space, but then is unable to receive free space that is held at the IANA. Without a alternate/better global policy proposal that can be implemented in a timely manner (i.e. prior to IANA exhaustion), we propose our framework for global consideration.
- 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.
Why would, and what's the incentive for, the RIRs to return IPv4 address space to the IANA?
It's expected that the RIR's, through regional policy, will do their best to cooperate. We have the example that right now, an RIR can take five /8s from the IANA. Yet, the RIRs have agreed to take up to only two /8s at a time.
If someone has a way to incent all five regions to return address space as part of global policy we are open to the suggestion. We did ask for such suggestions when we posted draft proposals to all five RIR addressing forums. We didn't receive any questions or suggestion to include incentives for RIRs to return address space.
As I have responded to Izumi-san's question, we have already seen address space returned to IANA for redistribution. We can imagine that this may happen again.
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.
The proposal in 5.3 says that the reclamation pool is divided equally amongst RIRs - which contradicts the above para.
We did not intend to contradict ourselves. :)
To clarify, 5.3 states:
The Reclamation Pool will be divided on CIDR boundaries and distributed evenly to all eligible RIRs.
The key word here is "eligible". If an RIR is eligible, then the space will go there "where it is needed".
It's worth noting that an RIR can fall in and out of eligibility depending on its state of exhaustion.
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.
I understood that IANA was exhausting its entire pool. Or is exhaustion really just complete /8s? It would be helpful if someone from IANA could clarify as I was under the impression that remaining fragments would be distributed as well, certainly before IANA declared that the cupboard was bare. The remaining fragments are not insignificant.
Since Leo Vegoda has already started to answer this, I'll reply to that thread....
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.
"Longest minimum allocation" doesn't parse very well, and indeed the first two words contradict each other. Perhaps it would be clearer to say "smallest minimum allocation".
Thank you. We will consider your alternate wording for clarity.
Yes, the intention is to use the smallest allocation block size out of policies from all RIRs. As you may have seen from my reply to Izumi-san, we might consider exempting addresses set aside under soft landing policies from consideration when calculating whether an RIR has exhausted its address space. It's conceivable that we would also exempt minimum allocation sizes in the soft landing policies when considering how to divide the new free IANA space.
All this, of course, is open for discussion.
The Reclamation Pool will be divided on CIDR boundaries and distributed evenly to all eligible RIRs. Any
So each time when, say ARIN, pushes the button for the policy, and gets a /19, the other 4 RIRs will each get a /19 as well? Even if they don't need it? This seems an unusual method of address space distribution - maybe we should have thought about this at the start of IPv4 20+ years ago. ;-)
It also means that the RIRs who have actually implemented runout policies (eg APNIC) for the final /8 will start stockpiling extra address space. Remind me what the incentive was for returning unused address space to IANA? This seems like a contradiction.
Ya know, that's not all that different from dividing the last five IANA /8s evenly. And that's triggered when only 1 RIR has demonstrated need while the other 4 have address space. :)
In your example, only when an RIR is considered to have exhausted its address space will it be considered to be eligible for the /19. So if an RIR doesn't need the space, they won't get it.
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.
Again "longest minimum" doesn't make a lot of sense (to me anyway). Also, exhaustion means "nothing left", not "1 month's supply" in the case of APNIC. Or "2 year's supply" in the case of AfriNIC. Etc.
Perhaps we need to define "exhaustion" better with some about of X month's supply. There is a time component in the currently active global policy for when RIRs request /8s from the IANA.
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.
This seems grossly unfair and unreasonable. What if, for example, a new RIR is formed in the Middle East. Do you seriously think that this new RIR should be denied any IPv4 address space at all, especially when the rest of the world is still trying to share IPv4 address space amongst the folks who too lazy to move onwards?
I expect that if a new RIR is forming with global community support, we as a comunity will have ample time to update the global policy to include the new RIR.
But if a new RIR just appears out of nowhere....
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.
Don't they do this already for the existing IANA allocations? As do the RIRs. (I guess this is making sure that IANA doesn't stop doing it.)
Yup, just want to be absolutely clear here. The IANA does not have an obligation right now to publish in the report the details of where new space was received.
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.
The reason for banning transfers is...?
APNIC has a policy allowing transfers between account holders. I don't think that this policy can simply march in and take over the existing transfer policy proposal like this. I'd rather see a separate proposal covering transfers after this one gains consensus. (Or it could be done in parallel I suppose.)
We authors do not intend to interfere with intra-RIR transfer policies that cover all address space prior to the IANA exhaustion. The transfer restriction is applied only to IANA-reallocated addresses covered by this policy proposal.
We would like to encourage the RIR's to develop inter-RIR transfer policy that is fair to all regions. Right now, transfer policy is disparate between the regions and it was part of the reason that the previous global policy approach was not able to move forward. By removing the transfer issue and encouraging the communities, we hope to remove one of the major roadblocks to enabling such a global policy to be potentially successful.
This policy gives RIR a fair amount of control through knobs such as transfer policy and minimum allocation sizes. Overall, we could not capture every use case to make everyone happy and instead decided that we would set the expectation that RIR communities would work together in fine tuning this proposal after ratification.
- Pros/Cons
5.1 Advantages
- The policy provides a mechanism for the ongoing distribution of IPv4 address space.
Why do we need ongoing distribution of IPv4 address space? I'd have hoped that the policy proposal would have explained this somewhere.
Again, sorry for not being more clear in the introduction. Please see my response above.
5.2 Disadvantages
- None identified.
See above. There are many.
Perhaps we should have said "None identified as of this posting." :)
philip
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

I think the real scenario will be more along the lines of:The Reclamation Pool will be divided on CIDR boundariesand distributed evenly to all eligible RIRs. AnySo each time when, say ARIN, pushes the button for the policy,and gets a /19, the other 4 RIRs will each get a /19 aswell? Even if they don't need it? This seems an unusual methodof address space distribution - maybe we should have thoughtabout this at the start of IPv4 20+ years ago. ;-)It also means that the RIRs who have actually implementedrunout policies (eg APNIC) for the final /8 will startstockpiling extra address space. Remind me what the incentivewas for returning unused address space to IANA? This seems likea contradiction.
Ya know, that's not all that different from dividing the last
five IANA /8s evenly. And that's triggered when only 1 RIR
has demonstrated need while the other 4 have address space. :)
In your example, only when an RIR is considered to have exhausted
its address space will it be considered to be eligible for the
/19. So if an RIR doesn't need the space, they won't get it.
5.6 No Transfer RightsAddress space assigned from the Reclamation Pool may betransferred if there is either an ICANN Board ratifiedglobal policy or globally coordinated RIR policyspecifically written to deal with transfers whetherinter-RIR or from one entity to another. Transfers mustmeet the requirements of such a policy. In the absenceof such a policy, no transfers of any kind related toaddress space allocated or assigned from the reclamationpool is allowed.The reason for banning transfers is...?

On 8/25/10 7:32 PM, "Owen DeLong" owen@delong.com wrote:
The Reclamation Pool will be divided on CIDR boundaries and distributed evenly to all eligible RIRs. Any
So each time when, say ARIN, pushes the button for the policy, and gets a /19, the other 4 RIRs will each get a /19 as well? Even if they don't need it? This seems an unusual method of address space distribution - maybe we should have thought about this at the start of IPv4 20+ years ago. ;-)
It also means that the RIRs who have actually implemented runout policies (eg APNIC) for the final /8 will start stockpiling extra address space. Remind me what the incentive was for returning unused address space to IANA? This seems like a contradiction.
Ya know, that's not all that different from dividing the last five IANA /8s evenly. And that's triggered when only 1 RIR has demonstrated need while the other 4 have address space. :)
In your example, only when an RIR is considered to have exhausted its address space will it be considered to be eligible for the /19. So if an RIR doesn't need the space, they won't get it.
I think the real scenario will be more along the lines of:
IANA runs out, last 5 /8s go to RIRs. RIR A runs out of their remaining space. RIR A pushes the button (as you called it above) RIR A receives full reclamation pool RIR B runs out, pushes button RIR C runs out, pushes button Some amount of space is returned to IANA Returned space is divided evenly between B and C RIRs A, B, and C run out and push button. RIR D runs out and pushes button. RIR E runs out and pushes button. The world transitions to IPv6. IPv4 space starts flying in to IANA and is distributed evenly amongst the 5 RIRs.
The exact specifics may vary and the timeline of the above is left to the imagination of the reader. However, the point is that I think there will only be one or two rounds of returned space effected by this policy and the first round will be winner take all for the first RIR to exhaust their address space.
The way the policy is currently worded, any RIR which has a set-aside policy or a rationing policy for the last /8 will be disadvantaged compared to RIRs which have no such limitations.
I don't think that this is the case at all. It will incentivize our communities to establish responsibly sized carve outs and to use them. There should be no carve out so large that it should prevent an RIR from exhausting at some point.
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.
The reason for banning transfers is...?
In the case of an RIR with a transfer policy that does not require a needs-based justification, this becomes a giant sucking hole through which all addresses can drain:
Party A has need, gets space from RIR. Party A sells space to party B which has no need, just money. Party A again has need, gets more space from RIR.
Lather, rinse, repeat.
But more importantly, transfers were not banned.
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.
Best,
-M<

On Aug 25, 2010, at 6:29 PM, Hannigan, Martin wrote:
On 8/25/10 7:32 PM, "Owen DeLong" owen@delong.com wrote:
The Reclamation Pool will be divided on CIDR boundaries and distributed evenly to all eligible RIRs. Any
So each time when, say ARIN, pushes the button for the policy, and gets a /19, the other 4 RIRs will each get a /19 as well? Even if they don't need it? This seems an unusual method of address space distribution - maybe we should have thought about this at the start of IPv4 20+ years ago. ;-)
It also means that the RIRs who have actually implemented runout policies (eg APNIC) for the final /8 will start stockpiling extra address space. Remind me what the incentive was for returning unused address space to IANA? This seems like a contradiction.
Ya know, that's not all that different from dividing the last five IANA /8s evenly. And that's triggered when only 1 RIR has demonstrated need while the other 4 have address space. :)
In your example, only when an RIR is considered to have exhausted its address space will it be considered to be eligible for the /19. So if an RIR doesn't need the space, they won't get it.
I think the real scenario will be more along the lines of:
IANA runs out, last 5 /8s go to RIRs. RIR A runs out of their remaining space. RIR A pushes the button (as you called it above) RIR A receives full reclamation pool RIR B runs out, pushes button RIR C runs out, pushes button Some amount of space is returned to IANA Returned space is divided evenly between B and C RIRs A, B, and C run out and push button. RIR D runs out and pushes button. RIR E runs out and pushes button. The world transitions to IPv6. IPv4 space starts flying in to IANA and is distributed evenly amongst the 5 RIRs.
The exact specifics may vary and the timeline of the above is left to the imagination of the reader. However, the point is that I think there will only be one or two rounds of returned space effected by this policy and the first round will be winner take all for the first RIR to exhaust their address space.
The way the policy is currently worded, any RIR which has a set-aside policy or a rationing policy for the last /8 will be disadvantaged compared to RIRs which have no such limitations.
I don't think that this is the case at all. It will incentivize our communities to establish responsibly sized carve outs and to use them. There should be no carve out so large that it should prevent an RIR from exhausting at some point.
I think that the way the policy is currently defined, set-asides would prevent some RIRs from exhausting during any meaningful portion of this policy unless the set-aside doesn't actually function as a set-aside.
Since so long as an RIR has a single /24 under current policies and potentially as little as a single /28 under proposed policy(ies), they are not considered to be at exhaustion, I don't see how you can expect a reasonable and functioning set-aside to do anything less than prevent qualification under "exhaustion".
I think for this policy to be functional, set-asides up to a certain size must be exempted from the exhaustion criteria.
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.
The reason for banning transfers is...?
In the case of an RIR with a transfer policy that does not require a needs-based justification, this becomes a giant sucking hole through which all addresses can drain:
Party A has need, gets space from RIR. Party A sells space to party B which has no need, just money. Party A again has need, gets more space from RIR.
Lather, rinse, repeat.
But more importantly, transfers were not banned.
Transfers of space received under this policy are banned by this policy. Transfers in general are not banned. That ban could be lifted by subsequent global policy action, but, absent an additional global policy change, yes, this proposal would ban such transfers.
Owen

On 8/25/10 9:40 PM, "Owen DeLong" owen@delong.com wrote:
On Aug 25, 2010, at 6:29 PM, Hannigan, Martin wrote:
[ snip ]
But more importantly, transfers were not banned.
Transfers of space received under this policy are banned by this policy. Transfers in general are not banned. That ban could be lifted by subsequent global policy action, but, absent an additional global policy change, yes, this proposal would ban such transfers.
That is wholly inaccurate. Transfers of space assigned under this policy are not allowed unless there is either a globally coordinated or global policy in place defining how transfers will occur globally. As I had mentioned to Phillip, that's a policy knob that can be turned without reworking the entire policy and at the option of the RIR's. The suggestion speaks volumes.
Best,
-M<

Hi Louie,
Louis Lee said the following on 26/08/10 08:00 :
I apologize personally for the delay in my response. I have consulted with the rest of the authors to craft the reply below.
That's okay, just means we probably end up repeating the discussion on the floor in a few minutes. :-(
It's expected that the RIR's, through regional policy, will do their best to cooperate. We have the example that right now, an RIR can take five /8s from the IANA. Yet, the RIRs have agreed to take up to only two /8s at a time.
Is there an APNIC policy which says that it has to return unused address space to IANA?
To clarify, 5.3 states:
The Reclamation Pool will be divided on CIDR boundaries and distributed evenly to all eligible RIRs.
The key word here is "eligible". If an RIR is eligible, then the space will go there "where it is needed".
It's worth noting that an RIR can fall in and out of eligibility depending on its state of exhaustion.
Okay, so it is not being divided equally between RIRs. It will be given to RIR regions who do not have carefully considered soft-landing policies.
Ya know, that's not all that different from dividing the last five IANA /8s evenly. And that's triggered when only 1 RIR has demonstrated need while the other 4 have address space. :)
Yup, that's a unique situation.
In your example, only when an RIR is considered to have exhausted its address space will it be considered to be eligible for the /19. So if an RIR doesn't need the space, they won't get it.
As per above, those who are profligate and have no run-out policy stand to benefit at the expense of the others.
I expect that if a new RIR is forming with global community support, we as a comunity will have ample time to update the global policy to include the new RIR.
Seems odd to explicitly exclude it.
But if a new RIR just appears out of nowhere....
Not sure what you mean here. RIRs don't appear out of nowhere, they are formed with their community support, and are part of the global community.
We authors do not intend to interfere with intra-RIR transfer policies that cover all address space prior to the IANA exhaustion. The transfer restriction is applied only to IANA-reallocated addresses covered by this policy proposal.
But banning transfers of the addresses covered by this policy proposal does interfere with intra-RIR transfer policies.
We would like to encourage the RIR's to develop inter-RIR transfer policy that is fair to all regions.
Well, you've just proposed one that transfers address space to RIRs who don't have good soft landing policies in places. ;-)
For many years I was under the impression that IPv6 was where we eventually wanted to be, and that IPv4 is going to be phased out. We've developed a soft-landing policy for our final /8 here in the APNIC service region (I was a co-author), designed to ensure that the APNIC community has sufficient IPv4 from the last /8 so they can fully transition to IPv6 over the coming years. If organisations are giving IPv4 addresses back to APNIC because they no longer need them (something I don't see happening for many years yet), it means that the entire industry will have successfully completed the transition to IPv6. So why do we even need IPv4 addresses then?
philip --

On 8/25/10 9:42 PM, "Philip Smith" pfs@cisco.com wrote:
[ snip ]
In your example, only when an RIR is considered to have exhausted its address space will it be considered to be eligible for the /19. So if an RIR doesn't need the space, they won't get it.
As per above, those who are profligate and have no run-out policy stand to benefit at the expense of the others.
How long do you expect your carve out to last? And if another RIR is out of space they have need. I'm not sure that this is truly a critical concern.
[ clip ]
We authors do not intend to interfere with intra-RIR transfer policies that cover all address space prior to the IANA exhaustion. The transfer restriction is applied only to IANA-reallocated addresses covered by this policy proposal.
But banning transfers of the addresses covered by this policy proposal does interfere with intra-RIR transfer policies.
But they're not banned as I had pointed out in another post. There's a knob that RIR's can opt to turn on to allow them without having to rework the global policy. The fact that we included the option to do a globally coordinated policy as well as an ICANN ASO global policy should speak volumes as to the suggestion.
Best,
-M<

On Thu, Aug 26, 2010 at 11:42:11AM +1000, Philip Smith wrote:
Hi Louie,
Hi Philip,
Louis Lee said the following on 26/08/10 08:00 :
I apologize personally for the delay in my response. I have consulted with the rest of the authors to craft the reply below.
That's okay, just means we probably end up repeating the discussion on the floor in a few minutes. :-(
That was my bad. :-(
Is there an APNIC policy which says that it has to return unused address space to IANA?
Not that I am aware of.
John Curran did state ARIN's position for clarification to Randy's concerns:
http://mailman.apnic.net/mailing-lists/sig-policy/archive/2010/08/msg00112.h...
However, for purposes of clarity, it is ARIN's practice is to return address space to the IANA, but the ARIN community expressed concern with making the return of space to the IANA a mandatory policy while there are RIR's which have abandoned needs-based allocation address policies who would also be drawing from the returned address space pool.
This statement is not to be taken as a comment on the merits of prop-086.
Okay, so it is not being divided equally between RIRs. It will be given to RIR regions who do not have carefully considered soft-landing policies.
Wouldn't ARIN's policy 2008-5 qualify as a soft-landing policy?
Dedicated IPv4 block to facilitate IPv6 deployment
When ARIN receives its last /8 IPv4 allocation from IANA, a contiguous /10 IPv4 block will be set aside and dedicated to facilitate IPv6 deployment. Allocations and assignments from this block must be justified by immediate IPv6 deployment requirements.
Full details at:
https://www.arin.net/policy/proposals/2008_5.html
Can we agree that ARIN has a soft-landing policy?
As per above, those who are profligate and have no run-out policy stand to benefit at the expense of the others.
Already addressed by Martin's reply to you:
http://mailman.apnic.net/mailing-lists/sig-policy/archive/2010/08/msg00119.h...
But if a new RIR just appears out of nowhere....
Not sure what you mean here. RIRs don't appear out of nowhere, they are formed with their community support, and are part of the global community.
I suppose that a new Internet Registry that comes about from a bid to ICANN by an organization that considers itself to be above the RIR system wouldn't be considered a "Regional" Internet Registry. But such a bid would certainly ask for the new IR to be treated equally as the RIRs, if it doesn't ask for preferential treatment.
But banning transfers of the addresses covered by this policy proposal does interfere with intra-RIR transfer policies.
Also addressed by Martin's reply to you:
http://mailman.apnic.net/mailing-lists/sig-policy/archive/2010/08/msg00119.h...
We would like to encourage the RIR's to develop inter-RIR transfer policy that is fair to all regions.
Well, you've just proposed one that transfers address space to RIRs who don't have good soft landing policies in places. ;-)
;-)
For many years I was under the impression that IPv6 was where we eventually wanted to be, and that IPv4 is going to be phased out.
As much as I would also like to see IPv4 phased out, it would likely have to come about by lack of demand.
We've developed a soft-landing policy for our final /8 here in the APNIC service region (I was a co-author), designed to ensure that the APNIC community has sufficient IPv4 from the last /8 so they can fully transition to IPv6 over the coming years.
And in a same spirit, the ARIN community is dedicating a /10 for transition purposes.
If organisations are giving IPv4 addresses back to APNIC because they no longer need them (something I don't see happening for many years yet), it means that the entire industry will have successfully completed the transition to IPv6. So why do we even need IPv4 addresses then?
So then this policy won't hurt if there's no demand for IPv4 addresses, right? At that point, no RIR will be in need for new space from IANA.
Louie

Hi Louie,
Louis Lee said the following on 26/08/10 12:23 :
Is there an APNIC policy which says that it has to return unused address space to IANA?
Not that I am aware of.
John Curran did state ARIN's position for clarification to Randy's concerns:
Yup, saw that. Maybe the APNIC Secretariat can clarify APNIC's situation? I suspect it would be the same as ARIN's actually.
Wouldn't ARIN's policy 2008-5 qualify as a soft-landing policy?
Fair point, yes, I overlooked that. So what problem are we trying to solve?
Already addressed by Martin's reply to you:
http://mailman.apnic.net/mailing-lists/sig-policy/archive/2010/08/msg00119.h...
Yup (I'll answer here), APNIC's carve out lasts for 16000+ resource holders. That's many years at current rates.
How long will the ARIN region 2008-5 policy last? Perhaps not as long? So perhaps the ARIN region should consider something that is "softer" landing than the current policy, rather than trying to procure address space from other RIRs via the IANA.
I suppose that a new Internet Registry that comes about from a bid to ICANN by an organization that considers itself to be above the RIR system wouldn't be considered a "Regional" Internet Registry.
That'd be my interpretation too.
But such a bid would certainly ask for the new IR to be treated equally as the RIRs, if it doesn't ask for preferential treatment.
And they'd be outside this if the proposal is worded to be inclusive of *regional* internet registries.
But banning transfers of the addresses covered by this policy proposal does interfere with intra-RIR transfer policies.
Also addressed by Martin's reply to you:
http://mailman.apnic.net/mailing-lists/sig-policy/archive/2010/08/msg00119.h...
Also replying here, knobs shouldn't be needed in policies to be randomly twiddle as and when required. The proposal says no transfers. We have a transfer policy in place here in APNIC service region covering all of APNIC resource holders' holdings.
As much as I would also like to see IPv4 phased out, it would likely have to come about by lack of demand.
And I'm suggesting that people aren't in a position to hand back IPv4 address space until they don't need those addresses, ie the demand has gone.
So then this policy won't hurt if there's no demand for IPv4 addresses, right? At that point, no RIR will be in need for new space from IANA.
If the policy isn't required, then why are we spending cycles proposing it and discussing it? ;-)
philip --


Wouldn't ARIN's policy 2008-5 qualify as a soft-landing policy?
Fair point
not really. read that policy. it is a /10 and folk can come back for more, not just single serve.
much more lax than any other.
this is all smoke.
the whole world except arin agreed to a policy. arin wants it different. and what is different? arin has more aggressive recovery plans and wants to keep and sell the loot.
randy

Randy Bush said the following on 26/08/10 14:31 :
not really. read that policy. it is a /10 and folk can come back for more, not just single serve.
much more lax than any other.
Agreed. It needs to be firmed up to be comparable with other RIR soft landing policies. Better to do that within ARIN PDP than taking up our time with something I can't see the need for in the APNIC service region.
philip --

not really. read that policy. it is a /10 and folk can come back for more, not just single serve. much more lax than any other.
Agreed. It needs to be firmed up to be comparable with other RIR soft landing policies. Better to do that within ARIN PDP
or not. the point is that, unless and until it is, the policy proposal in $subject is quite ill-advised unless you are arin.
randy

On Aug 26, 2010, at 2:31 PM, Randy Bush wrote:
the whole world except arin agreed to a policy. arin wants it different. and what is different? arin has more aggressive recovery plans and wants to keep and sell the loot.
I'm not certain I can sufficiently distance myself from ARIN in order to voice personal opinion, but I'll try... In my purely personal opinion, making returned address space available to the IANA is essential, just as allowing transfers of address space between regions is essential. However, in either case, it's is equally important to maintain the current needs-based allocation framework for these processes. The central issue is the departure from needs-based that simply hasn't been agreed to by all of the regions.
/John (personal view)

On Aug 26, 2010, at 2:31 PM, Randy Bush wrote:
the whole world except arin agreed to a policy. arin wants it different. and what is different? arin has more aggressive recovery plans and wants to keep and sell the loot.
I'm not certain I can sufficiently distance myself from ARIN in order to voice personal opinion, but I'll try... In my purely personal opinion, making returned address space available to the IANA is essential, just as allowing transfers of address space between regions is essential. However, in either case, it's is equally important to maintain the current needs-based allocation framework for these processes. The central issue is the departure from needs-based that simply hasn't been agreed to by all of the regions.
/John (personal view)

Hi Philip
Philip Smith wrote:
Hi Louie,
Louis Lee said the following on 26/08/10 12:23 :
Is there an APNIC policy which says that it has to return unused address space to IANA?
Not that I am aware of.
John Curran did state ARIN's position for clarification to Randy's concerns:
Yup, saw that. Maybe the APNIC Secretariat can clarify APNIC's situation? I suspect it would be the same as ARIN's actually.
APNIC has no policy regarding the return of addresses to IANA. To date, APNIC has not returned any reclaimed space to IANA. Instead, it has been returned to the Resource Quality Assurance Pool for redistribution to APNIC account holders, as discussed in the plenary this morning at APNIC 30.
I hope this helps.
Sam

On 8/26/10 12:22 AM, "Philip Smith" pfs@cisco.com wrote:
Hi Louie,
Louis Lee said the following on 26/08/10 12:23 :
Is there an APNIC policy which says that it has to return unused address space to IANA?
Not that I am aware of.
John Curran did state ARIN's position for clarification to Randy's concerns:
Yup, saw that. Maybe the APNIC Secretariat can clarify APNIC's situation? I suspect it would be the same as ARIN's actually.
Wouldn't ARIN's policy 2008-5 qualify as a soft-landing policy?
Fair point, yes, I overlooked that. So what problem are we trying to solve?
Already addressed by Martin's reply to you:
http://mailman.apnic.net/mailing-lists/sig-policy/archive/2010/08/msg00119.h... ml
Yup (I'll answer here), APNIC's carve out lasts for 16000+ resource holders. That's many years at current rates.
That depends on how long your soft landing policy remains soft.
Still, if you really believe that your carve out will last many years you are arguing moot points since you would never need to receive any of this address space.
If the transfer section were removed and the proposal did every theoretical allocation N/5 and reserved 1/5 for each ineligible RIR until they exhausted or some reasonable period of time went by (take or pay), would that remove your objections?
Best,
-M<

Still, if you really believe that your carve out will last many years you are arguing moot points since you would never need to receive any of this address space.
fallacious.
the space returned to the iana could be used to allocate under v4 policies other than the last /8 policy.
randy

On 8/26/10 3:07 AM, "Randy Bush" randy@psg.com wrote:
Still, if you really believe that your carve out will last many years you are arguing moot points since you would never need to receive any of this address space.
fallacious.
the space returned to the iana could be used to allocate under v4 policies other than the last /8 policy.
randy
Summarizing the "discussion":
As Philip noted, 'no proposal should meddle in a regions affairs'. There is a clear correlation between the APNIC regions non-needs based transfer policy and the ARIN region declining to signup for mandatory address returns. 1:1.
Minus the points of contention, if such a proposal is no longer needed, that's probably much easier to say. If it is needed and wasn't just filler text for trying to force another regions hand, I would argue that it might be better to simply cut and paste the previous proposal sans the requirement or with an insertion about non-needs based transfer.
Seems like the ball is squarely in the APNIC regions court.
Best Regards,
-M<

As Philip noted, 'no proposal should meddle in a regions affairs'. There is a clear correlation between the APNIC regions non-needs based transfer policy and the ARIN region declining to signup for mandatory address returns. 1:1.
i.e. arin wants to meddle in other regions' affairs on transfer
Seems like the ball is squarely in the APNIC regions court.
once again. all, that is ALL, regions except arin came to agreement on a policy. the location of the ball is pretty obvious.
randy

On Aug 26, 2010, at 2:13 PM, Randy Bush wrote:
As Philip noted, 'no proposal should meddle in a regions affairs'. There is a clear correlation between the APNIC regions non-needs based transfer policy and the ARIN region declining to signup for mandatory address returns. 1:1.
i.e. arin wants to meddle in other regions' affairs on transfer
Seems like the ball is squarely in the APNIC regions court.
once again. all, that is ALL, regions except arin came to agreement on a policy. the location of the ball is pretty obvious.
In a world where each region has veto power for global policy, I think it is more productive to identify policy that all regions can agree to than to stand back and finger-point at the one that cast the veto.
I will point out that ARIN was willing to agree to all but one provision of the global policy. From my perspective, ARIN has no desire to meddle in APNICs affairs, merely a desire not to be forced to hand space off to APNIC knowing that it could be allocated without a needs basis.
This is much like countries (e.g. Australia) not wanting to extradite prisoners until they can get an assurance from the destination country that they will not seek the death penalty. I don't consider that a case of Australia attempting to meddle in US affairs. I consider that a case of Australia not wanting to hand someone over unless they know that doing so will not violate their perceived moral obligations.
Owen

Owen DeLong said the following on 27/08/10 07:31 :
I will point out that ARIN was willing to agree to all but one provision of the global policy. From my perspective, ARIN has no desire to meddle in APNICs affairs, merely a desire not to be forced to hand space off to APNIC knowing that it could be allocated without a needs basis.
Unfortunately that is meddling in APNIC region affairs. ;-) It was a lot of hard work to get a transfer policy in place (as we might remember). If anyone wants to change it, they are very welcome to submit a policy here to do so.
I agree with the sentiment expressed by several folks yesterday. We (the community) need to work out a way of making prop-069 (as it was here) fly in the ARIN region. It was approved in the other 4 RIR regions.
philip --

Nope... You misunderstand my statement.Owen DeLong said the following on 27/08/10 07:31 :I will point out that ARIN was willing to agree to all but one provision ofthe global policy. From my perspective, ARIN has no desire to meddlein APNICs affairs, merely a desire not to be forced to hand space offto APNIC knowing that it could be allocated without a needs basis.
Unfortunately that is meddling in APNIC region affairs. ;-) It was a lot
of hard work to get a transfer policy in place (as we might remember).
If anyone wants to change it, they are very welcome to submit a policy
here to do so.
I agree with the sentiment expressed by several folks yesterday. We (the
community) need to work out a way of making prop-069 (as it was here)
fly in the ARIN region. It was approved in the other 4 RIR regions.

On Aug 26, 2010, at 5:53 PM, Philip Smith wrote:
I agree with the sentiment expressed by several folks yesterday. We (the community) need to work out a way of making prop-069 (as it was here) fly in the ARIN region. It was approved in the other 4 RIR regions.
Philip
Prop-069 had two aspects: establishing an IANA pool for returned space, and making return of space to the IANA mandatory. It's possible for all of the RIRs to agree on the former point without "meddling" in each others policy, it does not appear possible to reconcile on the latter point at this time.
i.e. If mandatory return is a requirement in any region, then one would expect prop-086 (which lacks such in my reading) to suffer a similar fate as prop-069.
/John
John Curran President and CEO ARIN

On Fri, Aug 27, 2010 at 09:42, John Curran jcurran@arin.net wrote:
On Aug 26, 2010, at 5:53 PM, Philip Smith wrote:
I agree with the sentiment expressed by several folks yesterday. We (the community) need to work out a way of making prop-069 (as it was here) fly in the ARIN region. It was approved in the other 4 RIR regions.
Philip
Prop-069 had two aspects: establishing an IANA pool for returned space, and making return of space to the IANA mandatory. It's possible for all of the RIRs to agree on the former point without "meddling" in each others policy, it does not appear possible to reconcile on the latter point at this time.
i.e. If mandatory return is a requirement in any region, then one would expect prop-086 (which lacks such in my reading) to suffer a similar fate as prop-069.
As one of the contributers/co-authors of prop-086, I would like to try to add some clarity to this discussion which may (or may not) be lacking. John's reading is correct, prop-086 has no requirement for mandatory return of space to IANA.
When developing this proposal, we too saw prop-069 as having two distinct provisions: 1) Creating a pool in IANA for returned space and creating a method by which IANA could distribute that space (and any other space not covered by current IANA policy, namely the fragments). 2) Mandating the unconditional return of all space recovered in any region to IANA for distribution by the method created in provision #1.
Because we felt that provision #1 was vitally important and we saw that provision #2 had stopped the entire prop from being adopted in the ARIN region, we decided to create a proposal to address provision #1 (facilitate the return and re-distribution of IPv4 address space through the IANA) independently. Prop-086 is what we came up with. I do not believe that putting this proposal forward precludes anyone from submitting a subsequent global proposal to address provision #2 from prop-069 (in fact it may facilitate it).
With all of that in mind (apologies if it is a repeat of common knowledge) I ask the APNIC community to consider that if the world believed that this idea was a valid and necessary one as half of prop-069 then it is still/also a valid and necessary proposal on it's own.
Thanks, ~Chris
/John
John Curran President and CEO ARIN
- sig-policy: APNIC SIG on resource management policy *
sig-policy mailing list sig-policy@lists.apnic.net http://mailman.apnic.net/mailman/listinfo/sig-policy

On 8/26/10 8:53 PM, "Philip Smith" pfs@cisco.com wrote:
Owen DeLong said the following on 27/08/10 07:31 :
I will point out that ARIN was willing to agree to all but one provision of the global policy. From my perspective, ARIN has no desire to meddle in APNICs affairs, merely a desire not to be forced to hand space off to APNIC knowing that it could be allocated without a needs basis.
Unfortunately that is meddling in APNIC region affairs. ;-) It was a lot of hard work to get a transfer policy in place (as we might remember). If anyone wants to change it, they are very welcome to submit a policy here to do so.
I agree with the sentiment expressed by several folks yesterday. We (the community) need to work out a way of making prop-069 (as it was here) fly in the ARIN region. It was approved in the other 4 RIR regions.
I think most of us agree with that as well. I also want you to know that it isn't our intention to meddle in APNIC's affairs. I would like to invite you to join the authors group if you are interested and perhaps we can come up with a compromise or something to make it work together?
Best,
Martin

On 8/26/10 5:13 PM, "Randy Bush" randy@psg.com wrote:
As Philip noted, 'no proposal should meddle in a regions affairs'. There is a clear correlation between the APNIC regions non-needs based transfer policy and the ARIN region declining to signup for mandatory address returns. 1:1.
i.e. arin wants to meddle in other regions' affairs on transfer
Seems like the ball is squarely in the APNIC regions court.
once again. all, that is ALL, regions except arin came to agreement on a policy. the location of the ball is pretty obvious.
randy
How would you make this work?

As Philip noted, 'no proposal should meddle in a regions affairs'. There is a clear correlation between the APNIC regions non-needs based transfer policy and the ARIN region declining to signup for mandatory address returns. 1:1.
i.e. arin wants to meddle in other regions' affairs on transfer
Seems like the ball is squarely in the APNIC regions court.
once again. all, that is ALL, regions except arin came to agreement on a policy. the location of the ball is pretty obvious.
How would you make this work?
it is the task of the arin board, ac, ... to spread clue among the arin community. you might start with "america does not own the internet."
randy

Okay, so it is not being divided equally between RIRs. It will be given to RIR regions who do not have carefully considered soft-landing policies.
Wouldn't ARIN's policy 2008-5 qualify as a soft-landing policy?
Dedicated IPv4 block to facilitate IPv6 deployment
When ARIN receives its last /8 IPv4 allocation from IANA, a contiguous /10 IPv4 block will be set aside and dedicated to facilitate IPv6 deployment. Allocations and assignments from this block must be justified by immediate IPv6 deployment requirements.
Full details at:
https://www.arin.net/policy/proposals/2008_5.html
Can we agree that ARIN has a soft-landing policy?
Yes... Do LACNIC, RIPE, and/or AfriNIC?
The point is that any region that does will be at a disadvantage vs. regions that do not under this global policy.
But if a new RIR just appears out of nowhere....
Not sure what you mean here. RIRs don't appear out of nowhere, they are formed with their community support, and are part of the global community.
I suppose that a new Internet Registry that comes about from a bid to ICANN by an organization that considers itself to be above the RIR system wouldn't be considered a "Regional" Internet Registry. But such a bid would certainly ask for the new IR to be treated equally as the RIRs, if it doesn't ask for preferential treatment.
I think this provision is important and is not intended to prevent the legitimate creation of a Middle East RIR or any other RIR through the approved process or in any way disadvantage such an RIR, but, to prevent some external authority from receiving anything by simply declaring themselves to be an RIR by some form of legal fiat.
Owen

On Aug 25, 2010, at 9:46 PM, Owen DeLong owen@delong.com wrote:
[...]
Can we agree that ARIN has a soft-landing policy?
Yes... Do LACNIC, RIPE, and/or AfriNIC?
http://www.nro.net/documents/comp-pol-201006.html#2-6
HTH,
Leo

Owen,
On Aug 25, 2010, at 9:41 PM, Owen DeLong wrote:
I think this provision is important and is not intended to prevent the legitimate creation of a Middle East RIR or any other RIR through the approved process or in any way disadvantage such an RIR, but, to prevent some external authority from receiving anything by simply declaring themselves to be an RIR by some form of legal fiat.
If an "external authority" declares themselves to be an IR (leaving off the first "R" since it is doubtful it would be "regional") by legal fiat, then presumably they'd use that same legal fiat to delegate to themselves a couple of unused /8s. After all, declaring themselves an IR already violates existing global policies and would threaten the stability of the existing address allocation regime. Going the extra step and saying "oh, and these /8s are ours so don't try to allocate from them" would seem a minor matter.
However, I'd think these sorts of hypotheticals are ... of questionable value given the extremely short window of opportunity.
I suspect it much more likely that if a new IR were to establish itself, it would probably have no interest in new IPv4 allocations, instead focusing on IPv6 for political reasons (see the ITU's "CIR" efforts) and/or establishing themselves as a titles registry to facilitate buying/selling of unencumbered IPv4 space.
To be honest, discussing the creation of new RIRs or even devising new and interesting ways of allocating the bitter dregs of unused IPv4 space at this point in time strikes me as equivalent to determining what sort of new and interesting geometric shapes can be formed with the deck chairs on the Titanic. But that's probably just me...
Regards, -drc
Activity Summary
- 4854 days inactive
- 4854 days old
- sig-policy@lists.apnic.net
- 13 participants
- 38 comments