Search RPD Archives
Limit search to: Subject & Body Subject Author
Sort by:

[AfriNIC-rpd] IPv4 Softlanding Policy

Scott Leibrand scottleibrand at
Mon Sep 21 16:20:40 UTC 2009


Looks good overall.  A few comments/suggestions inline...  (You can take 
them or leave them as you wish.  I have no definitive opinions either 
way: I just wanted to throw out some suggestions based on previous 
experience with similar policies in our region.)


Douglas Onyango wrote:
> After the last Public policy meeting, the consensus was that this 
> policy be taken back to the mailing list for further discussion.
> As Policy author, i hereby submit the policy for further review; your 
> comments on the same are welcome.
> ==============================================================
> Incentive
> ------------
> In order to ensure a flexible transition from IPv4 to IPv6, the 
> lifespan of IPv4 can be increased in order to give network operators 
> more time to make the transition. This document proposes a strategy 
> for allocation and maintenance of AfriNIC's final /8 block of IPv4 
> from IANA.
> Background
> ---------------
> Following the much anticipated IPv4 pool exhaustion, a global policy, 
> "Global Policy for the Allocation of the Remaining IPv4 Address 
> Space", has been ratified. The policy ensures that IANA reserves one 
> (1) IPv4 /8 address block for each RIR. Details of the Global Policy 
> for the Allocation of the Remaining IPv4 Address Space can be found 
> at:
> This policy (IPv4 Soft Landing) applies to the management of address 
> space that will be available to AfriNIC under the Global Policy
> The purpose of this document is to ensure that this last block will be 
> used in a manner that is acceptable by the AfriNIC community.
> Policy Documents to be affected:
> --------------
> (a) IPv4 Allocation Policy 
> (b) Proposal to Change the Allocation & Assignment Period to 12 months 
> Definitions
> --------------
> (a) Local Internet Registry (LIR)
> A Local Internet Registry (LIR) is an Internet Registry (IR) that 
> receives allocations from an RIR and primarily sub-allocates or 
> assigns address space to 'end-users'. LIRs are generally ISPs. Their 
> customers are other ISPs and possibly end-users. LIRs must be members 
> of an RIR like AfriNIC; which serves the Africa Region and part of the 
> Indian Ocean (Comoros, Madagascar, Mauritius, Seychelles).
> (b) Existing LIR´s An existing LIR is defined as being an organization 
> that
>    assigns address space to 'end-users' and who has already been 
> assigned or allocated
>    IPv4 address space by AfriNIC.
>  (c) New LIR´s A new LIR is defined as being an organization that 
> assigns address
>    space to 'end-users' and who is a member of AfriNIC but has not 
> been assigned or
>    allocated any IPv4 address space prior to the Exhaustion phase.
> Summary
> ------------
> This proposal describes how AfriNIC shall allocate and manage IPv4 
> resources from the last /8 block of IPv4 address allocated by IANA at 
> the time of total depletion of the IANA IPv4 address free pool.
> (i) Current Phase:
> During this phase, AfriNIC will continue allocating IPv4 addresses to 
> the LIR's using the current allocation policy 
> This 
> phase will continue until a request for IPv4 address space from any 
> LIR to AfriNIC either cannot be fulfilled with the IPv4 address space 
> available in the AfriNIC pool (with the exception of the last 
> allocated /8 address block from IANA) or can be fulfilled but leaving 
> the AfriNIC IPv4 address pool empty (with the exception of the last 
> allocated /8 address block from IANA).
> This will be the last IPv4 address space request that AfriNIC will 
> accept from any LIR in the Current Phase, AfriNIC, will declare that 
> the Exhaustion Phase has begun at this point.
> (ii) Exhaustion Phase:
> During the exhaustion phase, the following allocation and assignment 
> policy for the last /8 IPv4 address will be used:
> a) Instead of the /22 block (1024) addresses allocated in the current 
> policy, the new minimum allocation size of /23 (512 addresses) will be 
> allocated to any LIR that requests for IPv4 resources.

This could be construed to mean that any LIR that requests resources 
gets them automatically.  You might want to say "any LIR that is 
approved for" rather than just "requests".

> This is also the maximum allocation size, even though LIRs may request 
> for more than a /23. No LIR may get more than 4 allocations once the 
> Exhaustion phase has begun.
> b) Together with the v4 allocation, AfriNIC shall allocate an IPv6 
> address block in compliance with the current IPv6 allocation policy 
> ( to the 
> LIR (in case it doesn't have any).
> The current allocation and assignment period of 12 months shall be 
> changed to 8 months. This will help to ensure that LIRs request only 
> for resources they need in the short to medium term, and promote 
> fairness in the equitable distribution of the last IPv4 address pool.
> Allocation Criteria
> ---------------------
> a) Existing LIR's
> At the time of the first IPv4 allocation made during the exhaustion 
> phase, AfriNIC shall also allocate an IPv6 address block in compliance 
> with the current IPv6 allocation policy 
> ( to the 
> LIR. In order to receive additional IPv4 allocations in the exhaustion 
> phase, the existing LIR must have used at least 90% of the previous 
> allocations from the exhaustion phase

This statement that the 90% usage criterion (only) applies to 
allocations from the last /8 would seem to create a loophole.  If an 
organization gets a /23 and uses that up, but has a bunch of free space 
in their non-exhaustion-phase allocations, it would seem that they can 
get another /23 based solely on the exhaustion-phase usage without 
regard to overall usage.  I'm not sure if that's what you intended, but 
if not, you might want to just have it say something like "90% of all 
previous allocations."

> b) New LIR's
> Each New LIR will receive IPv4 addresses which they can use for 
> supporting legacy IPv4 services to ensure their full presence on the 
> IPv4 Internet during the transition to IPv6. The following will apply:
> Upon application, a New LIR may receive a maximum of four (4) address 
> blocks according to the minimum allocation size in effect at time of 
> allocation in the AfriNIC region. However, the /23 address blocks 
> shall be issued one at a time.
> In order to receive additional IPv4 allocations, the New LIR should 
> have used at least 90% of the previous allocations from the exhaustion 
> phase.
> New LIRs may apply for and receive this allocation once they meet the 
> criteria to receive IPv4 address space according to the policy in 
> effect at the time.
> IPv4 Address Space Reserve
> ---------------------------------
> A /16 IPv4 address block will be in reserve out of the last /8 pool. 
> This /16 IPv4 address block shall be preserved by AfriNIC for some 
> future uses, as yet unforeseen. The Internet is innovative and we 
> cannot predict with certainty what might happen. Therefore, it is 
> prudent to keep this block in reserve, just in case some future 
> requirement creates a demand for IPv4 addresses.
> In the event that the reserved /16 IPv4 address block remains unused 
> by the time the remaining /8 address space covered by this policy has 
> been allocated to LIRs, it returns to the pool to be distributed in 
> compliance with this policy.

It would seem that this clause would defeat the purpose of having the 
reservation in the first place.  In other words, the /16 wouldn't really 
be "reserved" if it is thrown back in the general pool as soon as the 
general pool is fully allocated.


> AfriNIC resources are for the AfriNIC geographical region. None of 
> these resources can be used outside of the AfriNIC region. All LIR's 
> requesting resources must have operations in Africa and all of the 
> allocations shall be used to support the LIR's African Operations.
> ==============================================================
> Regards,
> Douglas Onyango +256(0712)981329
> If you are not part of the solution, you are part of the Problem.
> ------------------------------------------------------------------------
> _______________________________________________
> rpd mailing list
> rpd at

More information about the RPD mailing list