Search RPD Archives
[AfriNIC-rpd] Updated Version of the "IPv4 Soft Landing Policy" now Available Online
Dr Paulos Nyirenda
paulos at sdnp.org.mw
Tue Feb 22 08:12:54 UTC 2011
more ...
On 21 Feb 2011 at 11:36, Owen DeLong wrote:
> >> [3] The Proposal
> >>
> >
> > "The purpose of this document is to ensure that address space -- is assigned and/or
> > allocated -- in a manner that is acceptable to the AfriNIC community especially during
> > -- the time of IPv4 exhaustion --- ."
> >
> I think the use of the word scarcity is cleaner, but, have no strong opposition to
> exhaustion.
Ok, we should go for exhaustion then. Not really certain that the word scarcity is
cleaner, it is more vague here -- for example, for one reason or another -- many people
think that IPv4 is already, or has been scarce, hence the need for them to resort to
NAT, all along!
> > In [3.9.2], I am concerned that the proposal is leaving matters of policy to the
> > "prerogative" of the Board as follows which I think should be revised to follow the
> > spirit in [3.6]
> >
> >> 3.9.2
> >> When AfriNIC, can no longer meet any more requests for address space
> >> from the last /8 pool because the pool is either empty or has no more
> >> contiguous blocks, the Board will based on the demand and other factors
> >> at the time exercise their prerogative to replenish the exhaustion pool
> >> with whatever address space that will be available to AfriNIC at the
> >> time in a manner that is in the best interest of the community.
> >
> > This proposal in [3.9.2] should be revised to avoid prerogatives as follows:
> >
> > When AfriNIC, can no longer meet any more requests for address space from the last /8
> > pool because the pool is either empty or has no more contiguous blocks, -- AfriNIC
> shall
> > follow policies in effect at the time to replenish resources --
> >
> I think this is very risky. The reality of the situation described her is that the
> policy
> community will be unable to react fast enough to adapt policy to a rapidly changing
> situation. The board is elected to be able to, among other things, handle decisions
> which must be made more rapidly than policy can address them. This is just such
> a situation and I believe that we must give the board discretion, or, simply recognize
> that the pool cannot and will not be replenished (which is not an unlikely outcome
> of board discretion, by the way).
The Internet is already "a rapidly changing situation" and yet we have done well to adapt
policy to manage resources etc - I do not see the need for prerogatives here.
> Everyone should be prepared to face the fact that when the pool is empty, it may
> be impossible to refill it. While IPv4 addresses remain particularly useful, their
> value will be such that I suspect AfriNIC and its members would have trouble
> competing in a bidding war against corporations in the other regions.I doubt
> there will be other sources of significant resources by the time AfriNIC exhausts
> the final /8, and I'm not even sure that source will have a supply.
Being prepared means that we should have a policy for it, does it not?
I strongly feel that introducing prerogatives is the wrong way to go in a policy driven
community and operation like ours in AfriNIC.
There has been another comment from another colleague recommending deletion of this
[3.9.2]
Regards,
Paulos
======================
Dr Paulos B Nyirenda
NIC.MW & .mw ccTLD
http://www.registrar.mw
>
> Owen
>
> > Regards,
> >
> > Paulos
> > ======================
> > Dr Paulos B Nyirenda
> > NIC.MW & .mw ccTLD
> > http://www.registrar.mw
> >
> >
> > On 21 Feb 2011 at 13:53, Mukom Akong T wrote:
> >
> >> Dear Colleagues,
> >>
> >> An updated version of the "IPv4 Soft Landing Proposal" is now available
> >> on our website at
> >> http://www.afrinic.net/docs/policies/AFPUB-2010-v4-005-draft-01.htm
> >>
> >> A text version of the proposal is included below:
> >>
> >> Regards
> >>
> >> _____
> >>
> >> Unique Id: AFPUB-2010-v4-005-draft-01
> >> Author(s): Douglas Onyango | Digiclear E.Africa Ltd |
> >> ondouglas at yahoo.com
> >> Draft Version: 11
> >> Submitted: 2010-11-25
> >> Updates:
> >> a. AFPUB-2005-v4-001
> >> b. AFPUB-2007-GEN-001
> >>
> >>
> >> [1] Summary of the Problem Being Addressed by this Policy Proposal
> >>
> >> Because the Global IPv4 free pool has run out, the IANA has implemented
> >> the Global Policy for the Allocation of the Remaining IPv4 Address Space
> >> - www.afrinic.net/docs/policies/AFPUB-2009-v4-001.html meaning after the
> >> last /8, RIRs will nolonger receive Address space from the IANA as in
> >> the past. This puts AfriNIC in a precarious situation as the current
> >> allocation and assignment Policy cannot be sustained in the mid to longterm.
> >>
> >>
> >> [2] Summary of How this Proposal Addresses the Problem
> >>
> >> In order to ensure a smooth transition to IPv6, AfriNIC's pool should
> >> be managed to provide members with address space after the IPv4 pool
> >> is depleted. This will help in maintaining IPv4 networks while
> >> deploying IPv6 networks a practice that characterize the transition
> >> period. This document proposes a strategy for allocation and Assignment
> >> and maintenance of AfriNIC's IPv4 pool post exhaustion. This policy
> >> begins when AfriNIC starts to allocation space from the last /8
> >>
> >>
> >> [3] The Proposal
> >>
> >> This policy (IPv4 Soft Landing), applies to the management of address
> >> space that will be available to AfriNIC after the current IPv4 pool is
> >> depleted. The purpose of this document is to ensure that address space
> >> used in a manner that is acceptable to the AfriNIC community especially
> >> during this time of scarcity.
> >>
> >> 3.1 Policy Documents to be affected:
> >>
> >> IPv4 Allocation Policy
> >> http://www.afrinic.net/docs/policies/AFPUB-2005-v4-001.htm
> >>
> >> Proposal to Change the Allocation & Assignment Period to 12 months
> >> http://www.afrinic.net/docs/policies/AFPUB-2007-GEN-001.htm
> >>
> >> 3.2 Definitions:
> >>
> >> Local Internet Registry (LIR)
> >>
> >> A Local Internet Registry (LIR) is an Internet Registry (IR) that
> >> receives allocations from an RIR and assigns address space to customers
> >> who use its services. LIRs are generally ISPs and their customers are
> >> end-users and possibly other ISPs. LIRs must be members of an RIR like
> >> AfriNIC; which serves the Africa Region and part of the Indian Ocean
> >> (Comoros, Madagascar, Mauritius, and Seychelles).
> >>
> >> Existing LIR's
> >>
> >> An Existing LIR is a LIR that assigns address space to 'end-users' and
> >> has already been assigned or allocated IPv4 address space by AfriNIC.
> >>
> >> New LIR
> >>
> >> A New LIR, is a LIR that assigns address space to 'end-users' and is a
> >> member of AfriNIC but has not been assigned or allocated any IPv4
> >> address space prior to the Exhaustion phase.
> >>
> >>
> >> End User
> >>
> >> An End User is an organization that receives assignments of IP addresses
> >> exclusively for use in its operational networks
> >>
> >> Final /8 block of IPv4 address space, or "Final /8".
> >>
> >> The Final /8 block of IPv4 address space, or "Final /8", is the /8 block
> >> of IPv4 address space that has been allocated by the IANA to AfriNIC in
> >> terms of section 2.2 C of the Global Policy for the Allocation of the
> >> Remaining IPv4 Address Space
> >> <http://www.icann.org/en/general/allocation-remaining-ipv4-space.html>
> >> at the time of exhaustion of the IANA pool of IPv4 address space.
> >> AfriNIC's version of the Global Policy for the Allocation of the
> >> Remaining IPv4 Address Space is also known as AFPUB-2009-v4-001
> >> <http://www.afrinic.net/docs/policies/AFPUB-2009-v4-001.html>.
> >>
> >>
> >> 3.3 Summary
> >>
> >> This proposal describes how AfriNIC shall assign, allocate, and manage
> >> IPv4 resources during the "Exhaustion Phase" which begins when AfriNIC
> >> first needs to assign or allocate IP addresses from the Final /8 block
> >> of IPv4 address space.
> >>
> >> 3.4 Current Phase:
> >>
> >> The "Current Phase" is the status quo at the time of adoption of this
> >> policy. During this phase, AfriNIC will continue allocating or
> >> assigning IPv4 addresses to LIRs and End Users using the current
> >> policies, including AFPUB-2005-v4-001
> >> <www.afrinic.net/docs/policies/AFPUB-2005-v4-001.htm>, AFPUB-2006-GEN-001
> >> <http://www.afrinic.net/docs/policies/AFPUB-2006-GEN-001.htm>, and any
> >> future amended versions of such policies.
> >>
> >> The current phase will continue until an otherwise-valid request for
> >> IPv4 address space from any LIR or end user to AfriNIC either (a) cannot
> >> be fulfilled with the IPv4 address space available in the AfriNIC pool
> >> (with the exception of the Last /8), or (b) can be fulfilled, but would
> >> leave the AfriNIC IPv4 address pool empty (with the exception of the
> >> Last /8).
> >>
> >> The request that results in either of the above conditions being
> >> fulfilled will be the last IPv4 address space request that AfriNIC will
> >> accept from any LIR or End User in the Current Phase. If the request
> >> can be processed in terms of the Current Phase policies, then it will be
> >> so processed; otherwise, it will be processed in terms of Exhaustion
> >> Phase policies.
> >>
> >> AfriNIC will publicly announce that the Exhaustion Phase has begun at
> >> this point.
> >>
> >> 3.5 Exhaustion Phase:
> >>
> >> During the Exhaustion Phase, the following allocation and assignment
> >> policy will be used. This policy applies to both LIRs and End Users,
> >> and applies at all times after the transition to the Exhaustion Phase.
> >>
> >> The exhaustion phase will be divided into two parts:-
> >> a) Exhaustion Phase 1
> >> b) Exhaustion Phase 2
> >>
> >> 3.5.1 Exhaustion Phase 1
> >> During this phase, allocation/assignment of address space will continue
> >> as in the Current phase (/24 for a EU and /22 for a LIR) but the maximum
> >> will change from /10 to /13.
> >>
> >> Allocations and assignments will be made from the /8 pool until we reach
> >> a /11. At this point the Exhaustion Phase 2 phase will kick in.
> >>
> >> Exhaustion Phase 2
> >> During this phase a minimum allocation/assignment size will be /27. And
> >> a maximum of /22 per allocation/assignment.
> >>
> >>
> >> 3.6) If any LIR or End User requesting IPv4 address space during the
> >> Exhaustion Phase does not already have IPv6 address space, then AfriNIC
> >> shall allocate or assign an IPv6 address block in compliance with the
> >> IPv6 allocation or assignment policies in effect at the time.
> >>
> >> 3.7) 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.
> >>
> >>
> >> 3.8 Allocation Criteria
> >>
> >> In order to receive IPv4 allocations or assignments during the
> >> Exhaustion Phase, the LIR or End User must have used at least 90% of all
> >> previous allocations or assignments (including those made during both
> >> the Current Phase and the Exhaustion Phase). In the case of new LIRs or
> >> End Users with no previous allocations or assignments, this requirement
> >> does not apply to their first allocation or assignment request.
> >>
> >>
> >> AfriNIC resources are for the AfriNIC geographical region. For each
> >> allocation or assignment made during the Exhaustion Phase, no more than
> >> 10% of these resources may be used outside of the AfriNIC region, and
> >> any use outside the AfriNIC region shall be solely in support of
> >> connectivity back to the AfriNIC region.
> >>
> >>
> >> 3.9 IPv4 Address Space Reserve
> >>
> >> A /12 IPv4 address block will be in reserve out of the Last /8. This /12
> >> 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.
> >>
> >> 3.9.2
> >> When AfriNIC, can no longer meet any more requests for address space
> >> from the last /8 pool because the pool is either empty or has no more
> >> contiguous blocks, the Board will based on the demand and other factors
> >> at the time exercise their prerogative to replenish the exhaustion pool
> >> with whatever address space that will be available to AfriNIC at the
> >> time in a manner that is in the best interest of the community.
> >>
> >>
> >>
> >> Acknowledgments
> >> Thanks to RPD-ML and especially Alain Aina and Alan Barrett for their
> >> contributions.
> >>
> >>
> >> 4.0. Revision History (for all but the very first draft)
> >>
> >> Version 1
> >> Removed IPv6 Adoption plans and deployment as requirements for receiving
> >> IPv4 address space in this policy as Members Technology choices are
> >> outside AfriNIC's purview
> >>
> >> Version 3
> >> Changed the scope of the document to cover IPv4 address space outside
> >> the /8 to avoid writing a new policy for IPv4 address space that
> >> AfriNIC might have outside the /8
> >>
> >> Version 5
> >> Removed 4 blocks as maximum possible allocation blocks in policy
> >> To eliminate the possibility of remaining with unusable space in the pool
> >>
> >> Version 8
> >> Changed the Minimum and Maximum Allocation sizes to /27 and /22
> >> respectively
> >> to cater for small requests by members transitioning who only need small
> >> blocks for interoperability
> >>
> >> Version 9
> >> Made all the allocation/assignments only usable within the AfriNIC region
> >> to curb Black Market practices that could crop up post exhaustion)
> >>
> >> Version 10
> >> Changed the Problem Statement due to Global IPv4 free pool running out
> >> _____
> >>
> >>
> >
> >
> > _______________________________________________
> > rpd mailing list
> > rpd at afrinic.net
> > https://lists.afrinic.net/mailman/listinfo.cgi/rpd
>
More information about the RPD
mailing list