[AfriNIC-rpd] A new version of the Global Policy proposal for the Allocation of the Remaining IPv4 Address Space

Wed Feb 20 08:08:19 UTC 2008

Dear all,

Since "afpol-v4gp200707" and "afpol-v4ep200708" are merged into one proposal 
as below, as one of co-authors of "afpol-v4ep200708", hereby I would like to 
withdraw "afpol-v4ep200708".

thanks and best regards,
toshi
---
Toshiyuki Hosaka

Hytham EL Nakhal wrote (2008/02/20 0:06):
> Dear Gents,
> 
>  
> 
> On behalf of the following policy proposal authors; I'd like to submit hereunder the new revised policy proposal text for the allocation of the remaining IPv4 address space, to be discussed throughout the mailing list. This proposal text is the result of collaboration between team of proposal "afpol-v4gp200707" and team of proposal "afpol-v4ep200708". Same policy text sent to APNIC, ARIN, and LACNIC policy groups and will send to Ripe and soon. 
> 
>  
> 
> Thanks,
> 
> Haitham El Nakhal
> 
>  
> 
> ******************************************************************************************************************************************************
>  
> Name:               Haitham Zakaria EL Nakhal
> Organisation:   National Telecom Regulatory Authority, Egypt
> Version:      Draft
> 
> Date:           16 February 2008
> Status:         Open for discussion
> Authors:     Roque Gagliano, ANTEL
>                     Francisco Obispo, CENIT
>                     Haitham EL Nakhal, MCIT
>                     Didier Allain Kla, ISOC Cote d'Ivoire
>            JPNIC IPv4 countdown policy team:
>                   - Akinori Maemura
>                   - Akira Nakagawa
>                   - Izumi Okutani
>                   - Kosuke Ito
>                   - Kuniaki Kondo
>                   - Shuji Nakamura
>                   - Susumu Sato
>                   - Takashi Arano
>                   - Tomohiro Fujisaki
>                   - Tomoya Yoshida
>                   - Toshiyuki Hosaka  
>  
> Policy Affected: The current on-demand global policy for the distribution of IPv4 address space to the Regional Internet Registry (RIR) system. 
>  
> Incentive: 
> The exhaustion of IPv4 address space is projected to take place within the next few years. This proposal seeks to focus on measures that should be taken globally in the address management area in order to prepare for this situation in all RIR regions and to assure the equal distribution of the IANA remaining IPv4 address space across RIR regions, this policy proposal describes a process for the distribution of  the remaining IPv4 space from IANA to the existing RIRs.
>  
> Policy Proposal Name: Global Policy for the Allocation of the Remaining IPv4 Address Space.
>  
> Proposal:
>  
> This policy describes the process for the allocation of the remaining IPv4 space from IANA to the RIRs. When a minimum amount of available
> space is reached, one /8 will be allocated from IANA to each RIR, replacing the current IPv4 allocation policy.
> In order to fulfill the requirements of this policy, at the time it is adopted, one /8 will be reserved by IANA for each RIR. The reserved allocation units will no longer be part of the available space at the IANA pool. IANA will also reserve one /8 to any new RIR at the time it is recognized.
> The process for the allocation of the remaining IPv4 space is divided in two consecutive phases:
>   
>    1. Existing Policy Phase:
>         During this phase IANA will continue allocating IPv4 addresses to the RIRs using the existing allocation policy. This phase will continue until a request for IPv4 address space from any RIR to IANA either cannot be fulfilled with the remaining IPv4 space available at the IANA pool or can be fulfilled but leaving the IANA remaining IPv4 pool empty.
> This will be the last IPv4 address space request that IANA will accept from any RIR. At this point the next phase of the process (Exhaustion Phase) will be initiated.
>    
>    2. Exhaustion Phase:
>          During this phase IANA will automatically allocate the reserved IPv4 allocation units to each RIR (one /8 to each one) and respond to the last request with the remaining available allocation units at the IANA pool (M units).
>       
>       2.1. Size of the final IPv4 allocations:
>                 In this phase IANA will automatically allocate one /8 to each RIR from the reserved space as defined in this policy. IANA will also allocate M allocation units to the RIR that submitted the last request for IPv4 addresses.
>       
>       2.2. Allocation of the remaining IPv4 Address space:
>                 After the completion of the evaluation of the final request for IPv4 addresses, IANA MUST:
>                   A) Immediately notify the NRO about the activation of the second phase    (Exhaustion Phase) of this policy.
>                   B) Proceed to allocate M allocation units to the RIR that submitted the last request for IPv4 address space.
>                   C) Proceed to allocate one /8 to each RIR from the reserved space.
>  
> Rational:
> The IANA pool of allocation units of IPv4 addresses (/8s) is decreasing rapidly; and to continue applying a global coordinated policy for distribution of the last piece(s) of each RIR's unallocated address block does not match the reality of the situation in each RIR region. Issues each RIR region will face during the exhaustion period vary by region as the level of development of IPv4 and IPv6 are widely different. As a result, applying a global coordinated policy may adequately address issues in a certain region while it could not be work for the others.
> For example, in a region where late comers desperately need even small blocks of IPv4 addresses to access to the IPv4 Internet, a policy that defines the target of allocations/assignments of IPv4 address space to the late comers would be appropriate in such region. This would allow availability of IPv4 address space for such requirements for more years.
> Another example comes from difference in IPv6 deployment rate. For a region where IPv6 deployment rate is low, measures may be necessary to prolong IPv4 address life for the existing business as well as for new businesses until networks are IPv6 ready. Some regions may have strong needs to secure IPv4 address space for translators.
> A globally coordinated policy which addresses all issues listed above (and/or others) to meet the needs for all RIR regions may result in not solving issues in any of the regions. So a new global policy proposal , a revised version of policy proposals "afpol-v4gp200707" and "afpol-v4ep200708", is proposed to replace the current "on demand" policy for allocating of the remaining IPv4 address space to RIRs.
> 
>  
> 
> Policy proposal “afpol-v4gp200707” statement was as the following :
> 
> This policy describes the process for the allocation of the remaining IPv4 space from IANA to RIRs. When a minimum amount of available space is reached, an identical number of IPv4 allocation units (/8s)
> will be allocated from IANA to each RIR, replacing the current IPv4 allocation policy.
> 
> In order to fulfill the requirements of this policy, at the time of its adoption, an identical number of IPv4 allocation units (N) will be reserved by IANA for each RIR. The number N is defined as 5. The reserved units will no longer be part of the available space at IANA pool. 
> 
> The process for the allocation of the remaining IPv4 space is divided in two consecutives phases:
> 
> 1. Existing Policy Phase:
> 
> During this phase IANA will continue allocating IPv4 addresses to the RIRs using the existing allocation policy. This phase will continue until a request for IPv4 address space from any RIR to IANA can not be fulfilled with the remaining IPv4 space available in the IANA pool.
> 
> This will be the last IPv4 address space request that IANA will accept from any RIR. At this point the next phase of the process will be initiated.
> 
> 2. Exhaustion Phase:
> 
> IANA will automatically allocate the reserved IPv4 allocation units to each RIR (N units to each one) and respond to the last request with the remaining available allocation units in IANA pool (M units).
> 
> 2.1. Size of the final IPv4 allocations:
> 
> During this phase IANA will automatically allocate N allocation units to each RIR from the reserved space defined in this policy. IANA will also allocate M allocation units to the RIR that submitted the last request for IPv4 addresses.
> 
> 2.2. Allocation of the remaining IPv4 Address space:
> 
> After the completion of the evaluation of the final request for IPv4 addresses, IANA must:
> 
> A) Immediately notify the NRO about the activation of the second phase of this policy.
> 
> B) Proceed to allocate M allocation units to the RIR that submitted the last request for IPv4 address space.
> 
> C) Proceed to allocate N allocation units to each RIR from the reserved space.
> 
> Policy proposal "afpol-v4ep200708" statement was as the following :
> 
> 1) Distribute a single /8 to each RIR at the point when new IANA free pool hits 5 */8. This date is defined as "IANA Exhaustion Date".
> 
> 2) It should be completely left up to each RIR communities to define a regional policy on how to distribute the remaining RIR free pool to LIRs within their respective regions after "IANA Exhaustion Date".
> 
> Note 1: It is fine for an RIR to continue operations with the existing policy if that is the consensus decision of the respective RIR community.
> 
> Note 2: Address recovery and re-distribution of recovered address space is another important measure for considerations, but should be treated as a separate policy proposal from distribution of new IANA pool.
> 
> 3) RIRs should provide an official projection on IANA Exhaustion Date to the community through their website, at their Policy Meetings and through any other effective means.
> 
> ******************************************************************************************************************************************************
> 
>  
> 
> 
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> rpd mailing list
> rpd at afrinic.net
> https://lists.afrinic.net/mailman/listinfo.cgi/rpd