[address-policy-wg] Policy proposal - Cooperative distribution of the end of the IPv4 free pool.
- Previous message (by thread): [address-policy-wg] Policy proposal - Cooperative distribution of the end of the IPv4 free pool.
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Vincent Ngundi
vincent at kenic.or.ke
Wed Oct 31 22:13:38 CET 2007
-----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 at 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-----
- Previous message (by thread): [address-policy-wg] Policy proposal - Cooperative distribution of the end of the IPv4 free pool.
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]