Policy proposal - Cooperative distribution of the end of the IPv4 free pool.
Policy Proposal Name: Cooperative distribution of the end of the IPv4 free pool. Author name: Tony Hain email: alh-ietf@tndh.net telephone: +1-425-468-1061 organization: Cisco Systems Proposal Version: 1.0 Submission Date: Oct-30-2007 Proposal type: new Policy term: permanent Policy summary: This policy will establish a process for RIR-to-RIR redistribution of the tail-end of the IPv4 pool, taking effect after the IANA Reserve is exhausted. Each redistribution Allocation will be triggered by the recipient RIR depleting its reserve to a 30 day supply, and will result in up to a 3 month supply being transferred from the RIR with the longest remaining time before it exhausts its own pool. Policy statement: At the point when any given RIR is within 30 days of depleting its remaining IPv4 pool, a survey will be taken of the other 4 to determine the remaining time before each of them exhausts their pool (including both member use and recent redistribution allocations to other RIRs). The one with the longest window before exhausting its pool will be designated as the source RIR. The recipient RIR will follow procedures for an LIR in the source RIR region to request a block that is expected to be sufficient for up to 3 months, but is no larger than 1/8th of the source RIR's remaining pool. At the point where no RIR can supply a block that is less than 1/8th of their remaining pool that will sustain the recipient RIR for 30 days, the recipient RIR will collect its requests each week, and forward those individual requests to the source RIR designated that week. Rationale: This policy will establish a mechanism for the Allocation of IPv4 address blocks between RIR's, but will not go into effect until the IANA pool has been depleted. It is really bizarre to watch the maneuvering as the global RIR community grapples with 'fairness' of distributing the last few IANA Reserve /8 blocks. On one level this just appears to be petty sibling rivalry, as people are bickering over who gets the last cookie and whimpering about 'fairness'. At the same time, each RIR is chartered to look after the interests of its membership so it is to be expected that they will each want to get as much as possible to meet the needs of their respective membership. Existing practice requires RIR's to acquire blocks from IANA, which leads to the current round of nonsense about optimal distribution of the remaining pool based on elaborate mathematical models. This globally submitted policy proposal attempts to resolve the issue by shifting to an RIR-to-RIR Allocation model after the IANA pool is depleted. This policy would effectively result in each RIR becoming a virtual LIR member of all of the other RIR's for the sole purpose of managing the tail-end of the IPv4 pool. Timetable for implementation: Before 1/1/2009
Policy summary: This policy will establish a process for RIR-to-RIR redistribution of the tail-end of the IPv4 pool, taking effect after the IANA Reserve is exhausted. Each redistribution Allocation will be triggered by the recipient RIR depleting its reserve to a 30 day supply, and will result in up to a 3 month supply being transferred from the RIR with the longest remaining time before it exhausts its own pool.
Finally some sensible discussion about the end-game that does not cause us to reach a crisis sooner, and may extend the overall life of IPv4 by a small amount. It also removes the incentives for companies to create shell companies in other regions to lock up a supply of IPv4 addresses. We should discard all the other silly end-game proposals and do some serious work on making a workable variation of this one. --Michael Dillon
michael.dillon@bt.com wrote:
Policy summary: This policy will establish a process for RIR-to-RIR redistribution of the tail-end of the IPv4 pool, taking effect after the IANA Reserve is exhausted. Each redistribution Allocation will be triggered by the recipient RIR depleting its reserve to a 30 day supply, and will result in up to a 3 month supply being transferred from the RIR with the longest remaining time before it exhausts its own pool.
This does sound interesting, and further helps fine-tune any tail-end disparity that exists following the final IANA allocations.
However, I believe the value of this would be weakened by having this policy implemented too frequently, e.g. if the fastest-allocating RIRs need to do this more than once, or if a slow-allocating RIR is "hit" more than once.
Finally some sensible discussion about the end-game that does not cause us to reach a crisis sooner, and may extend the overall life of IPv4 by a small amount. It also removes the incentives for companies to create shell companies in other regions to lock up a supply of IPv4 addresses.
We should discard all the other silly end-game proposals and do some serious work on making a workable variation of this one.
I would point out that this policy applies *after* the IANA reserve has been allocated. The other policies under discussion apply *before* the reserve has run out, and concern when and how the final IANA blocks are allocated to RIRs. As such, the two kinds of proposals are orthogonal. And, in fact, if both kinds are implemented, the benefit is greater than if only one or the other were implemented. As such, I would have to encourage support for both the "pie" proposal, *and* this "cooperative" proposal. Brian
We should discard all the other silly end-game proposals and do some serious work on making a workable variation of this one.
I would point out that this policy applies *after* the IANA reserve has been allocated.
The other policies under discussion apply *before* the reserve has run out, and concern when and how the final IANA blocks are allocated to RIRs.
As such, the two kinds of proposals are orthogonal.
Exactly! The policies that apply before the IANA reserve has run out, are silly. This policy, which applies after the IANA reserve has run out, makes some sense and does result in a soft landing.
And, in fact, if both kinds are implemented, the benefit is greater than if only one or the other were implemented.
I disagree. And if Tony Hain's policy were to be implemented, then everything before that is basically meaningless. --Michael Dillon
Hi, We'd be grateful if people could stop cc'ing iana@iana.org when posting messages to this discussion as it generates unnecessary tickets in our ticketing system. Many thanks, Leo Vegoda
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Remarkable foresight! If I read the policy right, do you suggest that we retain the current IANA allocation policy and instead concentrate on life after the depletion of IPv4 in the IANA pool? Regards, - -Vincent On Oct 30, 2007, at 10:40 PM, Tony Hain wrote:
Policy Proposal Name: Cooperative distribution of the end of the IPv4 free pool.
Author name: Tony Hain email: alh-ietf@tndh.net telephone: +1-425-468-1061 organization: Cisco Systems Proposal Version: 1.0 Submission Date: Oct-30-2007 Proposal type: new Policy term: permanent
Policy summary: This policy will establish a process for RIR-to-RIR redistribution of the tail-end of the IPv4 pool, taking effect after the IANA Reserve is exhausted. Each redistribution Allocation will be triggered by the recipient RIR depleting its reserve to a 30 day supply, and will result in up to a 3 month supply being transferred from the RIR with the longest remaining time before it exhausts its own pool.
Policy statement: At the point when any given RIR is within 30 days of depleting its remaining IPv4 pool, a survey will be taken of the other 4 to determine the remaining time before each of them exhausts their pool (including both member use and recent redistribution allocations to other RIRs). The one with the longest window before exhausting its pool will be designated as the source RIR. The recipient RIR will follow procedures for an LIR in the source RIR region to request a block that is expected to be sufficient for up to 3 months, but is no larger than 1/8th of the source RIR's remaining pool. At the point where no RIR can supply a block that is less than 1/8th of their remaining pool that will sustain the recipient RIR for 30 days, the recipient RIR will collect its requests each week, and forward those individual requests to the source RIR designated that week.
Rationale: This policy will establish a mechanism for the Allocation of IPv4 address blocks between RIR's, but will not go into effect until the IANA pool has been depleted.
It is really bizarre to watch the maneuvering as the global RIR community grapples with 'fairness' of distributing the last few IANA Reserve /8 blocks. On one level this just appears to be petty sibling rivalry, as people are bickering over who gets the last cookie and whimpering about 'fairness'. At the same time, each RIR is chartered to look after the interests of its membership so it is to be expected that they will each want to get as much as possible to meet the needs of their respective membership. Existing practice requires RIR's to acquire blocks from IANA, which leads to the current round of nonsense about optimal distribution of the remaining pool based on elaborate mathematical models.
This globally submitted policy proposal attempts to resolve the issue by shifting to an RIR-to-RIR Allocation model after the IANA pool is depleted. This policy would effectively result in each RIR becoming a virtual LIR member of all of the other RIR's for the sole purpose of managing the tail-end of the IPv4 pool.
Timetable for implementation: Before 1/1/2009
- -- KeNIC - The Kenya Network Information Center http://www.kenic.or.ke -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (Darwin) iD8DBQFHKPAChPC3Z8cZxdsRAsbpAJ9QCtMgO6fbPhg5pHtjJzWVt8kf+QCgqu70 77KKjoP4KqBpGKQ59JE0NV8= =k/EN -----END PGP SIGNATURE-----
participants (5)
-
Brian Dickson -
Leo Vegoda -
michael.dillon＠bt.com -
Tony Hain -
Vincent Ngundi