<table cellspacing="0" cellpadding="0" border="0" ><tr><td valign="top" style="font: inherit;">Hi all,<br>I appreciate your input to the proposal and i also agree on most of the points you raise - just a few comments here.<br>On the point of giving out v6 addresses like candy, i want to say i am in full agreement, mark that there is a whole policy that is dedicated to  v6 allocations and everyone interested i believe is being served well here.<br><br>On the issue of shortening the allocation periods, rationale was that, when LIR's requisition address space, its easier to justify much bigger chuncks for the 12months even when they will not be used, so solution is is do 6 months and then we can include some threshold say 90% usage (which usage we shall need help on effective measuring both here and in other places in the proposal where its mentioned).<br><br>On the issue raised by McTim, i think its an interesting one that may trigger a salvo of
 discussion, but IMHO, if we have the resources and we can reserve what is sufficient to get us going for another maybe 5 years, i don't see the the evil in availing the space to someone outside the region who needs it. Especially if there is something in it for us.<br><br>Regards,<br><br>Douglas onyango +256(0712)981329<br>
If you are not part of the solution, your are part of the Problem.<br><br>--- On <b>Thu, 1/8/09, rpd-request@afrinic.net <i><rpd-request@afrinic.net></i></b> wrote:<br><blockquote style="border-left: 2px solid rgb(16, 16, 255); margin-left: 5px; padding-left: 5px;">From: rpd-request@afrinic.net <rpd-request@afrinic.net><br>Subject: rpd Digest, Vol 33, Issue 2<br>To: rpd@afrinic.net<br>Date: Thursday, January 8, 2009, 12:41 PM<br><br><pre>Send rpd mailing list submissions to<br>      rpd@afrinic.net<br><br>To subscribe or unsubscribe via the World Wide Web, visit<br>  https://lists.afrinic.net/mailman/listinfo.cgi/rpd<br>or, via email, send a message with subject or body 'help' to<br>      rpd-request@afrinic.net<br><br>You can reach the person managing the list at<br>      rpd-owner@afrinic.net<br><br>When replying, please edit your Subject line so it is more specific<br>than "Re: Contents of rpd digest..."<br><br><br>Today's Topics:<br><br>   1. Policy
 Proposal: IPv4 Soft Landing Policy (Vincent Ngundi)<br>   2. Re: Policy Proposal: IPv4 Soft Landing Policy (McTim)<br>   3. Re: Policy Proposal: IPv4 Soft Landing Policy (Mark J Elkins)<br><br><br>----------------------------------------------------------------------<br><br>Message: 1<br>Date: Wed, 07 Jan 2009 09:37:26 +0300<br>From: Vincent Ngundi <vincent@kenic.or.ke><br>Subject: [AfriNIC-rpd] Policy Proposal: IPv4 Soft Landing Policy<br>To: AfriNIC RPD ML <rpd@afrinic.net><br>Message-ID: <C58A2856.F49%vincent@kenic.or.ke><br>Content-Type: text/plain;        charset="UTF-8"<br><br>The AfriNIC PDP-MG received the following policy proposal on the 6th of<br>January 2009. In accordance with the AfriNIC Policy Development Process, the<br>proposal is being posted to the AfriNIC Resource Policy Discuss (RPD)<br>Mailing List. The proposal will also be placed on the AfriNIC website as a<br>policy proposal under discussion.<br><br>In line with the
 AfriNIC PDP, the AfriNIC community is now invited to review<br>and discuss this policy.<br><br>The AfriNIC Policy Development Process can be found at:<br>http://www.afrinic.net/docs/policies/afpol-pdp200707.htm<br><br>AfriNIC Mailing Lists subscription information can be found at:<br>http://www.afrinic.net/mailinglist.htm<br><br>Regards,<br><br>Vincent Ngundi<br>Chair, PDP-MG<br><br>#### IPv4 Soft Landing Policy ####<br><br>Name:           IPv4 Soft Landing Policy<br>Organization:   Sitronics Telecom Solutions - Uganda<br>Version:        Draft<br>Date:           05 Jan 2009<br>Status:            <br>Authors:        Douglas Onyango<br>              <br><br>Incentive<br>---------<br><br>In order to ensure a smooth transition to IPv6 from IPv4, its necessary that<br>the life span of IPv4 be sustained as much as possible. This document<br>proposes a strategy for allocation and maintenance of the final block of /8<br>IPv4 assignment from
 IANA.<br><br>Background<br>----------<br><br>Following the much anticipated IPv4 pool exhaustion, a global policy,<br>“Global Policy for the Allocation of the Remaining IPv4 Address<br>Space”,<br>is being developed that will ensure that IANA reserves one (1) IPv4 /8<br>address block for each RIR. Details of the Global Policy for the Allocation<br>of the Remaining IPv4 Address Space can be found at:<br>http://www.afrinic.net/docs/policies/afpol-v4gp200802.html. This policy<br>(IPv4 Soft Landing) shall only become applicable if the â€šÃ„úGlobal<br>Policy for<br>the Allocation of the Remaining IPv4 Address Space” is ratified.<br><br>AfriNIC as an RIR is therefore charged with the responsibility of seeing to<br>it that this last block is used in the best way possible. This is the<br>purpose of this document.<br><br>Policy Documents to be affected:<br><br>(a) IPv4 Allocation
 Policy<br>http://www.afrinic.net/docs/policies/afpol-v4200407-000.htm<br><br>(b) Proposal to Change the Allocation & Assignment Period to 12 months<br>http://www.afrinic.net/docs/policies/afpol-af200611.htm<br><br>Definitions<br>-----------<br><br>(a) Local Internet Registry (LIR)<br>A Local Internet Registry (LIR) is an Internet Registry (IR) that receives<br>allocations from an RIR and primarily sub-allocates or assigns address space<br>to 'end-users'. LIRs are generally ISPs. Their customers are other ISPs<br>and<br>possibly end-users. LIRs must be members of an RIR like AfriNIC; which<br>serves the Africa Region and part of the Indian Ocean (Comoros, Madagascar,<br>Mauritius, Seychelles).<br><br>(b) Existing LIR’s<br>An existing LIR is defined as being an organization that has already been<br>assigned or allocated IPv4 address space by AfriNIC<br><br>(c) New LIR’s<br>A new LIR is defined as being an organization
 which has recently become a<br>member of AfriNIC but has yet to be assigned or allocated any IPv4 address<br>space.<br><br>(d) Critical Infrastructure Provider:<br>A critical infrastructure provider is defined as the Root Servers operator,<br>generic Top Level Domain (gTLD) Registry Operator, country code Top Level<br>Domain (ccTLD) Registry Operator, internationalized Domain Names (iDN)<br>Registry operator, or Internet Exchange Point operator.<br><br>Summary<br>-------<br><br>This proposal describes how AfriNIC shall allocate and manage IPv4 resources<br>from the last /8 block of IPv4 address allocated by IANA at the time of<br>total depletion of the IANA IPv4 address free pool.<br><br>(i) Current Phase:<br>During this phase, AfriNIC will continue allocating IPv4 addresses to the<br>LIR’s using the current allocation policy<br>http://www.afrinic.net/docs/policies/afpol-v4200407-000.htm. This phase will<br>continue until a request for
 IPv4 address space from any LIR to AfriNIC<br>either cannot be fulfilled with the IPv4 address space available in the<br>AfriNIC pool (with the exception of the last allocated /8 address block from<br>IANA) or can be fulfilled but leaving the AfriNIC IPv4 address pool empty<br>(with the exception of the last allocated /8 address block from IANA).<br><br>This will be the last IPv4 address space request that AfriNIC will accept<br>from any LIR and at this point, the next phase of the process (Exhaustion<br>Phase) will be initiated.<br><br>(ii) Exhaustion Phase:<br>During the exhaustion phase, an interim allocation and assignment policy for<br>the last /8 IPv4 address block will be available to AfriNIC as described<br>below:<br><br>a)    Instead of the /22 block (1024) addresses allocated in the current<br>policy, a /23 block (512) addresses will be assigned to any LIR that<br>requests for IPv4 resources.<br>b)    The LIR will be required to show an IPv6
 adoption plan that should be<br>implemented within 8 months. AfriNIC shall ratify the IPv6 adoption plan.<br><br>Upon ratification of the IPv6 adoption plan (previous paragraph), AfriNIC<br>shall allocate an IPv6 address block in compliance with the current IPv6<br>allocation policy <br>(http://www.afrinic.net/docs/policies/afpol-v6200407-000.htm) to the LIR (in<br>case it doesn’t have any). This shall be done together with the<br>/23 IPv4<br>address space allocation; according to the allocation criteria described<br>below.<br><br>As proposed above, the current allocation and assignment period of 12 months<br>shall be changed to 8 months. This will help to ensure minimal wastage of<br>resources that could probably lay unused while other LIR’s<br>suffer from<br>deficiency.<br><br>Allocation Criteria<br>-------------------<br><br>Each LIR should receive address space in accordance with the minimum<br>allocation size in effect
 at time of the request. If AfriNIC’s<br>minimum<br>allocation size were to change in future, the allocation made under this<br>policy (/23) should also be changed accordingly.<br><br>a) Existing LIR’s<br><br>Upon application, an Existing LIR may receive only a single IPv4 allocation<br>at the minimum allocation size even if their needs justify a larger<br>allocation. The LIR will be required to show an IPv6 adoption plan that<br>should be implemented within 8 months. AfriNIC shall ratify the IPv6<br>adoption plan. At the time of the IPv4 allocation, AfriNIC shall also<br>allocate an IPv6 address block in compliance with the current IPv6<br>allocation policy <br>(http://www.afrinic.net/docs/policies/afpol-v6200407-000.htm) to the LIR.<br><br>In order to receive additional IPv4 allocations, the Existing LIR must start<br>using the allocated IPv6 address block first, according to the plan ratified<br>by AfriNIC. (In case of no
 IPv6 upstream provider, this should be clarified<br>to the AfriNIC IP analyst, and the same evaluated by AfriNIC).<br><br>Each Existing LIR may apply for and receive this allocation once they meet<br>the criteria to receive IPv4 address space according to the current<br>allocation policy in effect at the time.<br><br>This allocation ensures that each Existing LIR receives routable IPv4<br>addresses that they can use for supporting legacy IPv4 services during the<br>transition phase to IPv6.<br><br>b) New LIR’s<br><br>Each New LIR will receive IPv4 addresses which they can use for supporting<br>legacy IPv4 services to ensure their full presence on the IPv4 Internet<br>during the transition to IPv6. The following will apply:<br><br>Upon application, a New LIR may receive a maximum of four (4) address blocks<br>according to the minimum allocation size in effect at time of allocation in<br>the AfriNIC region. However, the /23 address blocks
 shall be issued one at a<br>time. If AfriNIC’s minimum allocation size were to change in<br>future, the<br>allocation made under this policy (/23) should also be changed accordingly.<br>The LIR will be required to show an IPv6 adoption plan that should be<br>implemented within 8 months. AfriNIC shall ratify the IPv6 adoption plan. At<br>the time of the IPv4 allocation, AfriNIC shall also allocate an IPv6 address<br>block in compliance with the current IPv6 allocation policy<br>(http://www.afrinic.net/docs/policies/afpol-v6200407-000.htm) to the LIR.<br><br>In order to receive additional IPv4 allocations, the New LIR should start<br>using the allocated IPv6 address block first, according to the plan ratified<br>by AfriNIC. (In case of no IPv6 upstream provider this should be clarified<br>to the AfriNIC IP analyst, and the same evaluated by AfriNIC).<br><br>New LIRs may apply for and receive this allocation once they meet the<br>criteria to
 receive IPv4 address space according to the policy in effect at<br>the time. <br><br>IPv4 Address Space Reserve<br>--------------------------<br><br>A /16 IPv4 address block will be in reserve out of the last /8 pool. This<br>/16 IPv4 address block should be preserved by AfriNIC for some future uses,<br>as yet unforeseen. The Internet is erratic and we cannot predict with<br>certainty what might happen. Therefore, it is prudent to keep this block in<br>reserve, just in case some future requirement creates a demand for IPv4<br>addresses.<br><br>Further, assignments to Critical Infrastructure Providers will be done from<br>this /16 IPv4 address block in /24 address blocks.<br><br>In the event that this /16 IPv4 address block remains unused by the time the<br>remaining /8 address space covered by this policy has been allocated to<br>LIRs, it returns to the pool to be distributed in compliance with this<br>policy.<br><br>#### /IPv4 Soft Landing Policy
 ####<br><br><br><br><br><br><br>------------------------------<br><br>Message: 2<br>Date: Thu, 8 Jan 2009 00:54:12 +0300<br>From: McTim <dogwallah@gmail.com><br>Subject: Re: [AfriNIC-rpd] Policy Proposal: IPv4 Soft Landing Policy<br>To: "AfriNIC Resource Policy Discussion List" <rpd@afrinic.net><br>Message-ID:<br>    <f65fb55e0901071354g473f9101xb7946667e43091ea@mail.gmail.com><br>Content-Type: text/plain; charset=WINDOWS-1252<br><br>Hi,<br><br>Douglas thanks for putting so much work into this proposal.<br><br>Here are my thoughts inline (many of them just nits):<br><br>On Wed, Jan 7, 2009 at 8:37 AM, Vincent Ngundi <vincent@kenic.or.ke><br>wrote:<br>> #### IPv4 Soft Landing Policy ####<br>><br>> Name:           IPv4 Soft Landing Policy<br>> Organization:   Sitronics Telecom Solutions - Uganda<br>> Version:        Draft<br>> Date:           05 Jan 2009<br>> Status:<br>> Authors:        Douglas
 Onyango<br>><br>><br>> Incentive<br>> ---------<br>><br>> In order to ensure a smooth transition to IPv6 from IPv4, its necessary<br>that<br>> the life span of IPv4 be sustained as much as possible.<br><br>Some think that the opposite is true.  In any case, perhaps this should read:<br><br>In order to ensure a flexible transition to IPv6 from IPv4, the<br>lifespan of IPv4 can be increased in order to give network operators<br>more time to make the transition.<br><br>This document<br>> proposes a strategy for allocation and maintenance of the final<br> block of /8<br>> IPv4 assignment from IANA.<br>><br>> Background<br>> ----------<br>><br>> Following the much anticipated IPv4 pool exhaustion, a global policy,<br>> ‚ÄúGlobal Policy for the Allocation of the Remaining IPv4 Address<br>Space‚Äù,<br>> is being developed that will ensure that IANA reserves one (1) IPv4 /8<br>> address block for each
 RIR. Details of the Global Policy for the<br>Allocation<br>> of the Remaining IPv4 Address Space can be found at:<br>> http://www.afrinic.net/docs/policies/afpol-v4gp200802.html. This policy<br>> (IPv4 Soft Landing) shall only become applicable if the ‚ÄúGlobal<br>Policy for<br>> the Allocation of the Remaining IPv4 Address Space‚Äù is ratified.<br><br>you mean globally ratified, right? then let's make that clear.<br><br>><br>> AfriNIC as an RIR is therefore charged with the responsibility of seeing<br>to<br>> it that this last block is used in the best way possible.<br><br>Well, AfriNIC is charged with the stewardship of the IP space, i.e.,<br>giving it out in accordance with the policies set by it's community.<br><br>This =! the "best possible way" (that is always open to<br>interpretation).<br><br>This is the<br>> purpose of this document.<br>><br>> Policy Documents to be affected:<br>><br>> (a) IPv4
 Allocation Policy<br>> http://www.afrinic.net/docs/policies/afpol-v4200407-000.htm<br>><br>> (b) Proposal to Change the Allocation & Assignment Period to 12 months<br>> http://www.afrinic.net/docs/policies/afpol-af200611.htm<br>><br>> Definitions<br>> -----------<br>><br>> (a) Local Internet Registry (LIR)<br>> A Local Internet Registry (LIR) is an Internet Registry (IR) that receives<br>> allocations from an RIR and primarily sub-allocates or assigns address<br>space<br>> to 'end-users'. LIRs are generally ISPs. Their customers are other<br>ISPs and<br>> possibly end-users.<br><br>I would delete the above as slightly redundant, and possibly<br>contradicting the previous sentence.<br><br> LIRs must be members of an RIR like AfriNIC; which<br>> serves the Africa Region and part of the Indian Ocean (Comoros,<br>Madagascar,<br>> Mauritius, Seychelles).<br><br>I would rather say:<br><br>LIRs must be members
 of AfriNIC.<br><br>It's more specific.<br><br>><br>> (b) Existing LIR‚Äôs<br>> An existing LIR is defined as being an organization that has already been<br>> assigned or allocated IPv4 address space by AfriNIC<br>><br>> (c) New LIR‚Äôs<br>> A new LIR is defined as being an organization which has recently become a<br>> member of AfriNIC but has yet to be assigned or allocated any IPv4 address<br>> space.<br>><br>> (d) Critical Infrastructure Provider:<br>> A critical infrastructure provider is defined as the Root Servers<br>operator,<br>> generic Top Level Domain (gTLD) Registry Operator, country code Top Level<br>> Domain (ccTLD) Registry Operator, internationalized Domain Names (iDN)<br>> Registry operator, or Internet Exchange Point operator.<br><br>I have always been opposed to g and ccTLD ops as being included in<br>this list of what is critical.  If ICANN does add thousands of new<br>gTLDs, not
 to mention the many iDNs, that reserved /16 you mention<br>below will be gone quickly.<br><br>If the community wants to do this, perhaps it should be extended to<br>Tier 0/1 ENUM ops as well.<br><br>><br>> Summary<br>> -------<br>><br>> This proposal describes how AfriNIC shall allocate and manage IPv4<br>resources<br>> from the last /8 block of IPv4 address allocated by IANA at the time of<br>> total depletion of the IANA IPv4 address free pool.<br>><br>> (i) Current Phase:<br>> During this phase, AfriNIC will continue allocating IPv4 addresses to the<br>> LIR‚Äôs using the current allocation policy<br>> http://www.afrinic.net/docs/policies/afpol-v4200407-000.htm. This phase<br>will<br>> continue until a request for IPv4 address space from any LIR to AfriNIC<br>> either cannot be fulfilled with the IPv4 address space available in the<br>> AfriNIC pool (with the exception of the last allocated /8 address
 block<br>from<br>> IANA) or can be fulfilled but leaving the AfriNIC IPv4 address pool empty<br>> (with the exception of the last allocated /8 address block from IANA).<br>><br>> This will be the last IPv4 address space request that AfriNIC will accept<br>> from any LIR and at this point, the next phase of the process (Exhaustion<br>> Phase) will be initiated.<br>><br><br>Can we just say that "AfriNIC will declare that the Exhaustion Phase<br>has begun at this point."<br><br><br>> (ii) Exhaustion Phase:<br>> During the exhaustion phase, an interim allocation and assignment policy<br>for<br>> the last /8 IPv4 address block will be available to AfriNIC as described<br>> below:<br><br>It's not interim is it?<br><br>> a)    Instead of the /22 block (1024) addresses allocated in the current<br>> policy, a /23 block (512) addresses will be assigned to any LIR that<br>> requests for IPv4 resources.<br><br>Is that the
 minimum allocation size? If so, the proposal should say that.<br><br>Are you proposing a maximum allocation size here?<br><br>> b)    The LIR will be required to show an IPv6 adoption plan that should<br>be<br>> implemented within 8 months. AfriNIC shall ratify the IPv6 adoption plan.<br>><br><br>I think this is very intrusive.  An RIR should have NO input at all on<br>which protocol its members want to use, let alone veto power over<br>their transition plan.<br><br>> Upon ratification of the IPv6 adoption plan (previous paragraph), AfriNIC<br>> shall allocate an IPv6 address block in compliance with the current IPv6<br>> allocation policy<br>> (http://www.afrinic.net/docs/policies/afpol-v6200407-000.htm) to the LIR<br>(in<br>> case it doesn‚Äôt have any). This shall be done together with the /23<br>IPv4<br>> address space allocation; according to the allocation criteria described<br>> below.<br>><br><br>We should be
 giving Ipv6 away like candy, not making people jump thru<br>hoops to get IPv6.<br><br><br>> As proposed above, the current allocation and assignment period of 12<br>months<br>> shall be changed to 8 months. This will help to ensure minimal wastage of<br>> resources that could probably lay unused while other LIR‚Äôs suffer<br>from<br>> deficiency.<br><br>This just means that folk will come back for more IPv4 more often, no?<br><br>><br>> Allocation Criteria<br>> -------------------<br>><br>> Each LIR should receive address space in accordance with the minimum<br>> allocation size in effect at time of the request. If AfriNIC‚Äôs<br>minimum<br>> allocation size were to change in future, the allocation made under this<br>> policy (/23) should also be changed accordingly.<br><br>as above, does this proposal mandate a maximum or minumum (or is it<br>both (one size fits all)?<br><br>><br>> a) Existing
 LIR‚Äôs<br>><br>> Upon application, an Existing LIR may receive only a single IPv4<br>allocation<br>> at the minimum allocation size even if their needs justify a larger<br>> allocation.<br><br>My question has been answered never mind ;-)<br><br>The LIR will be required to show an IPv6 adoption plan that<br>> should be implemented within 8 months. AfriNIC shall ratify the IPv6<br>> adoption plan. At the time of the IPv4 allocation, AfriNIC shall also<br>> allocate an IPv6 address block in compliance with the current IPv6<br>> allocation policy<br>> (http://www.afrinic.net/docs/policies/afpol-v6200407-000.htm) to the LIR.<br><br>This seems to be redundant to me.<br><br>><br>> In order to receive additional IPv4 allocations, the Existing LIR must<br>start<br>> using the allocated IPv6 address block first, according to the plan<br>ratified<br>> by AfriNIC. (In case of no IPv6 upstream provider, this should
 be<br>clarified<br>> to the AfriNIC IP analyst, and the same evaluated by AfriNIC).<br>><br><br>What does the word "using" mean in the above?  Deploying on their<br>network or announcing to the world (or both)?<br><br>> Each Existing LIR may apply for and receive this allocation once they meet<br>> the criteria to receive IPv4 address space according to the current<br>> allocation policy in effect at the time.<br>><br>> This allocation ensures that each Existing LIR receives routable<br><br>NO RIR ever guarantees routability, I think this word needs to be deleted.<br><br> IPv4<br>> addresses that they can use for supporting legacy IPv4 services during the<br>> transition phase to IPv6.<br>><br>> b) New LIR‚Äôs<br>><br>> Each New LIR will receive IPv4 addresses which they can use for supporting<br>> legacy IPv4 services to ensure their full presence on the IPv4 Internet<br>> during the transition to IPv6.
 The following will apply:<br>><br>> Upon application, a New LIR may receive a maximum of four (4) address<br>blocks<br>> according to the minimum allocation size in effect at time of allocation<br>in<br>> the AfriNIC region. However, the /23 address blocks shall be issued one at<br>a<br>> time. If AfriNIC‚Äôs minimum allocation size were to change in future,<br>the<br>> allocation made under this policy (/23) should also be changed<br>accordingly.<br>> The LIR will be required to show an IPv6 adoption plan that should be<br>> implemented within 8 months. AfriNIC shall ratify the IPv6 adoption plan.<br>At<br>> the time of the IPv4 allocation, AfriNIC shall also allocate an IPv6<br>address<br>> block in compliance with the current IPv6 allocation policy<br>> (http://www.afrinic.net/docs/policies/afpol-v6200407-000.htm) to the LIR.<br><br>isn't this also redundant.<br><br>><br>> In order to receive additional IPv4
 allocations, the New LIR should start<br>> using the allocated IPv6 address block first, according to the plan<br>ratified<br>> by AfriNIC. (In case of no IPv6 upstream provider this should be clarified<br>> to the AfriNIC IP analyst, and the same evaluated by AfriNIC).<br>><br>> New LIRs may apply for and receive this allocation once they meet the<br>> criteria to receive IPv4 address space according to the policy in effect<br>at<br>> the time.<br>><br>> IPv4 Address Space Reserve<br>> --------------------------<br>><br>> A /16 IPv4 address block will be in reserve out of the last /8 pool. This<br>> /16 IPv4 address block should be preserved by AfriNIC for some future<br>uses,<br>> as yet unforeseen. The Internet is erratic<br><br>It is actually quite stable ;-), can we say innovative?<br><br><br> and we cannot predict with<br>> certainty what might happen. Therefore, it is prudent to keep this
 block<br>in<br>> reserve, just in case some future requirement creates a demand for IPv4<br>> addresses.<br>><br>> Further, assignments to Critical Infrastructure Providers will be done<br>from<br>> this /16 IPv4 address block in /24 address blocks.<br><br>NO! If you are going to reserve a /16, then reserve it.  Allowing<br>Critical Infrastructure Providers to get it will ensure that it goes<br>within a few years (or months).<br><br><br>><br>> In the event that this /16 IPv4 address block remains unused by the time<br>the<br>> remaining /8 address space covered by this policy has been allocated to<br>> LIRs, it returns to the pool to be distributed in compliance with this<br>> policy.<br><br>I would rather it be "reserved" even after exhaustion.<br><br>Apologies for the length of my submission, but this proposal seems to<br>do 4 main things:<br><br>1. Create a one size fits all minimum/maximum allocation size (BTW,
 it<br>should be limited to PA allocations and not End-User assignments, no?)<br><br>2. Change the assignment period from 1 year to 8 months (we just went<br>down from 2 years to 1 recently).  Perhaps staff can give us some data<br>about the previous change and its impact on the frequency of<br>additional IPv4 allocation requests.  In other words, when we went<br>from 2 years to 1, did that mean that people just came back more often<br>for additional allocs?  What I mean is, did we increase our burn rate<br>of IPv4 becasue of that change?<br><br>3. Force people into using IPv6, which may entail significant costs.<br>We may not have the "legal power" to force this kind of change.<br><br>4. Reserve a /16 for those deemed "critical". I am sure that<br>everybody<br>reading this post thinks their network is pretty darn "critical" ;-)<br><br>So what we are trying to do is to lengthen the runout period AND force<br>folk to use IPv6?  Is that a good summary?  If
 so, I can't say i like<br>this proposal as it stands.<br><br>I would rather use the carrot than the stick, but here's a<br>"stick"<br>that may be helpful.<br><br>If we specify in a policy that AfriNIC must see documentation on the<br>purchase or lease of equipment that has the interfaces to be numbered,<br>that might force people to rethink their needs request.<br><br>In other words, if you tell a hostmaster that you need 2048 IPs, you<br>should have the paper work for 2000<br>CPEs/routers/servers/radios/whatever that those numbers will be<br>deployed on.  Just a radical thought.<br><br>-- <br>Cheers,<br><br>McTim<br>http://stateoftheinternetin.ug<br><br><br>------------------------------<br><br>Message: 3<br>Date: Thu, 08 Jan 2009 11:09:09 +0200<br>From: Mark J Elkins <mje@posix.co.za><br>Subject: Re: [AfriNIC-rpd] Policy Proposal: IPv4 Soft Landing Policy<br>To: AfriNIC Resource Policy Discussion List <rpd@afrinic.net><br>Message-ID:
 <4965C2B5.2090105@posix.co.za><br>Content-Type: text/plain; charset=windows-1252; format=flowed<br><br>Now that the hard works been done - I'd like to add my thoughts.....<br><br>McTim wrote:<br>> Hi,<br>><br>> Douglas thanks for putting so much work into this proposal.<br>><br>> Here are my thoughts inline (many of them just nits):<br>><br>> On Wed, Jan 7, 2009 at 8:37 AM, Vincent Ngundi <vincent@kenic.or.ke><br>wrote:<br>>   <br>>> #### IPv4 Soft Landing Policy ####<br>>><br>>> Name:           IPv4 Soft Landing Policy<br>>> Organization:   Sitronics Telecom Solutions - Uganda<br>>> Version:        Draft<br>>> Date:           05 Jan 2009<br>>> Status:<br>>> Authors:        Douglas Onyango<br>>><br>>><br>>> Incentive<br>>> ---------<br>>><br>>> In order to ensure a smooth transition to IPv6 from IPv4, its<br>necessary that<br>>>
 the life span of IPv4 be sustained as much as possible.<br>>>     <br>><br>> Some think that the opposite is true.  In any case, perhaps this should<br>read:<br>><br>> In order to ensure a flexible transition to IPv6 from IPv4, the<br>>   <br>I'd prefer this to read "from IPv4 to IPv6".<br>> lifespan of IPv4 can be increased in order to give network operators<br>> more time to make the transition.<br>><br>>   <br>I like that! - "sustaining IPv4" is the wrong goal.<br>> This document<br>>   <br>>> proposes a strategy for allocation and maintenance of the final<br>>>     <br>>  block of /8<br>>   <br>>> IPv4 assignment from IANA.<br>>><br>>> Background<br>>> ----------<br>>><br>>> Following the much anticipated IPv4 pool exhaustion, a global policy,<br>>> ‚ÄúGlobal Policy for the Allocation of the Remaining IPv4 Address<br>Space‚Äù,<br>>> is
 being developed that will ensure that IANA reserves one (1) IPv4 /8<br>>> address block for each RIR. Details of the Global Policy for the<br>Allocation<br>>> of the Remaining IPv4 Address Space can be found at:<br>>> http://www.afrinic.net/docs/policies/afpol-v4gp200802.html. This<br>policy<br>>> (IPv4 Soft Landing) shall only become applicable if the ‚ÄúGlobal<br>Policy for<br>>> the Allocation of the Remaining IPv4 Address Space‚Äù is ratified.<br>>>     <br>><br>> you mean globally ratified, right? then let's make that clear.<br>><br>>   <br>>> AfriNIC as an RIR is therefore charged with the responsibility of<br>seeing to<br>>> it that this last block is used in the best way possible.<br>>>     <br>><br>> Well, AfriNIC is charged with the stewardship of the IP space, i.e.,<br>> giving it out in accordance with the policies set by it's community.<br>><br>> This
 =! the "best possible way" (that is always open to<br>interpretation).<br>><br>>   <br><br>Remember - although there is a (yet to be ratified) global policy for <br>allocation the last few blocks to RIR's - each RIR will probably have <br>quite different<br>or unique methods of using that block. The two should not be confused.<br><br>> This is the<br>>   <br>>> purpose of this document.<br>>><br>>> Policy Documents to be affected:<br>>><br>>> (a) IPv4 Allocation Policy<br>>> http://www.afrinic.net/docs/policies/afpol-v4200407-000.htm<br>>><br>>> (b) Proposal to Change the Allocation & Assignment Period to 12<br>months<br>>> http://www.afrinic.net/docs/policies/afpol-af200611.htm<br>>><br>>> Definitions<br>>> -----------<br>>><br>>> (a) Local Internet Registry (LIR)<br>>> A Local Internet Registry (LIR) is an Internet Registry (IR)
 that<br>receives<br>>> allocations from an RIR and primarily sub-allocates or assigns address<br>space<br>>> to 'end-users'. LIRs are generally ISPs. Their customers are<br>other ISPs and<br>>> possibly end-users.<br>>>     <br>><br>> I would delete the above as slightly redundant, and possibly<br>> contradicting the previous sentence.<br>><br>>  LIRs must be members of an RIR like AfriNIC; which<br>>   <br>>> serves the Africa Region and part of the Indian Ocean (Comoros,<br>Madagascar,<br>>> Mauritius, Seychelles).<br>>>     <br>><br>> I would rather say:<br>><br>> LIRs must be members of AfriNIC.<br>><br>> It's more specific.<br>><br>>   <br>>> (b) Existing LIR‚Äôs<br>>> An existing LIR is defined as being an organization that has already<br>been<br>>> assigned or allocated IPv4 address space by AfriNIC<br>>><br>>> (c) New
 LIR‚Äôs<br>>> A new LIR is defined as being an organization which has recently<br>become a<br>>> member of AfriNIC but has yet to be assigned or allocated any IPv4<br>address<br>>> space.<br>>><br>>> (d) Critical Infrastructure Provider:<br>>> A critical infrastructure provider is defined as the Root Servers<br>operator,<br>>> generic Top Level Domain (gTLD) Registry Operator, country code Top<br>Level<br>>> Domain (ccTLD) Registry Operator, internationalized Domain Names (iDN)<br>>> Registry operator, or Internet Exchange Point operator.<br>>>     <br>><br>> I have always been opposed to g and ccTLD ops as being included in<br>> this list of what is critical.  If ICANN does add thousands of new<br>> gTLDs, not to mention the many iDNs, that reserved /16 you mention<br>> below will be gone quickly.<br>><br>> If the community wants to do this, perhaps it should be
 extended to<br>> Tier 0/1 ENUM ops as well.<br>><br>>   <br>>> Summary<br>>> -------<br>>><br>>> This proposal describes how AfriNIC shall allocate and manage IPv4<br>resources<br>>> from the last /8 block of IPv4 address allocated by IANA at the time<br>of<br>>> total depletion of the IANA IPv4 address free pool.<br>>><br>>> (i) Current Phase:<br>>> During this phase, AfriNIC will continue allocating IPv4 addresses to<br>the<br>>> LIR‚Äôs using the current allocation policy<br>>> http://www.afrinic.net/docs/policies/afpol-v4200407-000.htm. This<br>phase will<br>>> continue until a request for IPv4 address space from any LIR to<br>AfriNIC<br>>> either cannot be fulfilled with the IPv4 address space available in<br>the<br>>> AfriNIC pool (with the exception of the last allocated /8 address<br>block from<br>>> IANA) or can be fulfilled but leaving the
 AfriNIC IPv4 address pool<br>empty<br>>> (with the exception of the last allocated /8 address block from IANA).<br>>><br>>> This will be the last IPv4 address space request that AfriNIC will<br>accept<br>>> from any LIR and at this point, the next phase of the process<br>(Exhaustion<br>>> Phase) will be initiated.<br>>><br>>>     <br>><br>> Can we just say that "AfriNIC will declare that the Exhaustion Phase<br>> has begun at this point."<br>><br>><br>>   <br>>> (ii) Exhaustion Phase:<br>>> During the exhaustion phase, an interim allocation and assignment<br>policy for<br>>> the last /8 IPv4 address block will be available to AfriNIC as<br>described<br>>> below:<br>>>     <br>><br>> It's not interim is it?<br>><br>>   <br>>> a)    Instead of the /22 block (1024) addresses allocated in the<br>current<br>>> policy, a /23 block (512) addresses
 will be assigned to any LIR that<br>>> requests for IPv4 resources.<br>>>     <br>><br>> Is that the minimum allocation size? If so, the proposal should say that.<br>><br>> Are you proposing a maximum allocation size here?<br>><br>>   <br>>> b)    The LIR will be required to show an IPv6 adoption plan that<br>should be<br>>> implemented within 8 months. AfriNIC shall ratify the IPv6 adoption<br>plan.<br>>><br>>>     <br>><br>> I think this is very intrusive.  An RIR should have NO input at all on<br>> which protocol its members want to use, let alone veto power over<br>> their transition plan.<br>><br>>   <br><br>At this stage of the game - if a new RIR does not have plans for IPv6 <br>adoption - they are not going to be around for very long.<br>I think its correct for AfriNIC to insist on some sort of IPv6 plan - <br>but nothing too harsh.<br>Perhaps the  IPv4 allocations to new
 RIR's have to be done in parallel <br>with an IPv6 allocation - unless of course the new RIR already has IPv6 <br>addresses.<br>>> Upon ratification of the IPv6 adoption plan (previous paragraph),<br>AfriNIC<br>>> shall allocate an IPv6 address block in compliance with the current<br>IPv6<br>>> allocation policy<br>>> (http://www.afrinic.net/docs/policies/afpol-v6200407-000.htm) to the<br>LIR (in<br>>> case it doesn‚Äôt have any). This shall be done together with the<br>/23 IPv4<br>>> address space allocation; according to the allocation criteria<br>described<br>>> below.<br>>><br>>>     <br>><br>> We should be giving Ipv6 away like candy, not making people jump thru<br>> hoops to get IPv6.<br>><br>><br>>   <br><br>I agree with the sentiment.<br><br>>> As proposed above, the current allocation and assignment period of 12<br>months<br>>> shall be changed to 8 months.
 This will help to ensure minimal wastage<br>of<br>>> resources that could probably lay unused while other LIR‚Äôs<br>suffer from<br>>> deficiency.<br>>>     <br>><br>> This just means that folk will come back for more IPv4 more often, no?<br>><br>>   <br>I don't think we need this change to 8 months.<br>>> Allocation Criteria<br>>> -------------------<br>>><br>>> Each LIR should receive address space in accordance with the minimum<br>>> allocation size in effect at time of the request. If AfriNIC‚Äôs<br>minimum<br>>> allocation size were to change in future, the allocation made under<br>this<br>>> policy (/23) should also be changed accordingly.<br>>>     <br>><br>> as above, does this proposal mandate a maximum or minumum (or is it<br>> both (one size fits all)?<br>><br>>   <br>>> a) Existing LIR‚Äôs<br>>><br>>> Upon application,
 an Existing LIR may receive only a single IPv4<br>allocation<br>>> at the minimum allocation size even if their needs justify a larger<br>>> allocation.<br>>>     <br>><br>> My question has been answered never mind ;-)<br>><br>>   <br><br>Not sure I like this. We use IPv4 resources very slowly. A rough <br>calculation suggests we'll have IPv4 resources well after other parts of<br>the<br>world are depleted. Because of this - I believe that:-<br><br>1 - only treat the last /10 in a special manner - ie - keep existing <br>rules for the first 3/4's of the last block - and be then very careful <br>with the last 1/4 of the block.<br>2 - In the last 1/4 of the block - only give addresses to people without <br>any existing IPv4 resources - or perhaps with less than /22.<br>This implies that if you have a /22 or more - you will never be <br>allocated any IPv4 resources again.<br>3 - We need to be very careful who gets these
 resources - especially <br>from now.<br><br>What I mean from this is - currently - you just need to be an AfriNIC <br>member to get AfriNIC resources.<br>I'd like a statement that says:<br><br>AfriNIC  resources are for the AfriNIC geographical region<br>No more than 10% (or similar) of these resources can be used outside of <br>the AfriNIC region.<br><br>ie - AT&T (or other international player) can come and be an AfriNIC <br>member and acquire resources - but can only really use them in the <br>AfriNIC region.<br><br><br>> The LIR will be required to show an IPv6 adoption plan that<br>>   <br>>> should be implemented within 8 months. AfriNIC shall ratify the IPv6<br>>> adoption plan. At the time of the IPv4 allocation, AfriNIC shall also<br>>> allocate an IPv6 address block in compliance with the current IPv6<br>>> allocation policy<br>>> (http://www.afrinic.net/docs/policies/afpol-v6200407-000.htm) to
 the<br>LIR.<br>>>     <br>><br>> This seems to be redundant to me.<br>><br>>   <br>>> In order to receive additional IPv4 allocations, the Existing LIR must<br>start<br>>> using the allocated IPv6 address block first, according to the plan<br>ratified<br>>> by AfriNIC. (In case of no IPv6 upstream provider, this should be<br>clarified<br>>> to the AfriNIC IP analyst, and the same evaluated by AfriNIC).<br>>><br>>>     <br>><br>> What does the word "using" mean in the above?  Deploying on<br>their<br>> network or announcing to the world (or both)?<br>><br>>   <br>"no IPv6 upstream provider" is a red herring - one can always tunnel<br>or <br>similar.<br>>> Each Existing LIR may apply for and receive this allocation once they<br>meet<br>>> the criteria to receive IPv4 address space according to the current<br>>> allocation policy in effect at the
 time.<br>>><br>>> This allocation ensures that each Existing LIR receives routable<br>>>     <br>><br>> NO RIR ever guarantees routability, I think this word needs to be deleted.<br>><br>>  IPv4<br>>   <br>>> addresses that they can use for supporting legacy IPv4 services during<br>the<br>>> transition phase to IPv6.<br>>><br>>> b) New LIR‚Äôs<br>>><br>>> Each New LIR will receive IPv4 addresses which they can use for<br>supporting<br>>> legacy IPv4 services to ensure their full presence on the IPv4<br>Internet<br>>> during the transition to IPv6. The following will apply:<br>>><br>>> Upon application, a New LIR may receive a maximum of four (4) address<br>blocks<br>>> according to the minimum allocation size in effect at time of<br>allocation in<br>>> the AfriNIC region. However, the /23 address blocks shall be issued<br>one at a<br>>>
 time. If AfriNIC‚Äôs minimum allocation size were to change in<br>future, the<br>>> allocation made under this policy (/23) should also be changed<br>accordingly.<br>>> The LIR will be required to show an IPv6 adoption plan that should be<br>>> implemented within 8 months. AfriNIC shall ratify the IPv6 adoption<br>plan. At<br>>> the time of the IPv4 allocation, AfriNIC shall also allocate an IPv6<br>address<br>>> block in compliance with the current IPv6 allocation policy<br>>> (http://www.afrinic.net/docs/policies/afpol-v6200407-000.htm) to the<br>LIR.<br>>>     <br>><br>> isn't this also redundant.<br>><br>>   <br>>> In order to receive additional IPv4 allocations, the New LIR should<br>start<br>>> using the allocated IPv6 address block first, according to the plan<br>ratified<br>>> by AfriNIC. (In case of no IPv6 upstream provider this should be<br>clarified<br>>> to
 the AfriNIC IP analyst, and the same evaluated by AfriNIC).<br>>><br>>> New LIRs may apply for and receive this allocation once they meet the<br>>> criteria to receive IPv4 address space according to the policy in<br>effect at<br>>> the time.<br>>><br>>> IPv4 Address Space Reserve<br>>> --------------------------<br>>><br>>> A /16 IPv4 address block will be in reserve out of the last /8 pool.<br>This<br>>>     <br>>> /16 IPv4 address block should be preserved by AfriNIC for some future<br>uses,<br>>> as yet unforeseen. The Internet is erratic<br>>>     <br>><br>> It is actually quite stable ;-), can we say innovative?<br>><br>><br>>  and we cannot predict with<br>>   <br>>> certainty what might happen. Therefore, it is prudent to keep this<br>block in<br>>> reserve, just in case some future requirement creates a demand for<br>IPv4<br>>>
 addresses.<br>>><br>>> Further, assignments to Critical Infrastructure Providers will be done<br>from<br>>> this /16 IPv4 address block in /24 address blocks.<br>>>     <br>><br>> NO! If you are going to reserve a /16, then reserve it.  Allowing<br>> Critical Infrastructure Providers to get it will ensure that it goes<br>> within a few years (or months).<br>><br>><br>>   <br>>> In the event that this /16 IPv4 address block remains unused by the<br>time the<br>>> remaining /8 address space covered by this policy has been allocated<br>to<br>>> LIRs, it returns to the pool to be distributed in compliance with this<br>>> policy.<br>>>     <br>><br>> I would rather it be "reserved" even after exhaustion.<br>><br>> Apologies for the length of my submission, but this proposal seems to<br>> do 4 main things:<br>><br>> 1. Create a one size fits all minimum/maximum
 allocation size (BTW, it<br>> should be limited to PA allocations and not End-User assignments, no?)<br>><br>> 2. Change the assignment period from 1 year to 8 months (we just went<br>> down from 2 years to 1 recently).  Perhaps staff can give us some data<br>> about the previous change and its impact on the frequency of<br>> additional IPv4 allocation requests.  In other words, when we went<br>> from 2 years to 1, did that mean that people just came back more often<br>> for additional allocs?  What I mean is, did we increase our burn rate<br>> of IPv4 becasue of that change?<br>><br>> 3. Force people into using IPv6, which may entail significant costs.<br>> We may not have the "legal power" to force this kind of change.<br>><br>> 4. Reserve a /16 for those deemed "critical". I am sure that<br>everybody<br>> reading this post thinks their network is pretty darn "critical"<br>;-)<br>><br>> So what we are
 trying to do is to lengthen the runout period AND force<br>> folk to use IPv6?  Is that a good summary?  If so, I can't say i like<br>> this proposal as it stands.<br>><br>> I would rather use the carrot than the stick, but here's a<br>"stick"<br>> that may be helpful.<br>><br>> If we specify in a policy that AfriNIC must see documentation on the<br>> purchase or lease of equipment that has the interfaces to be numbered,<br>> that might force people to rethink their needs request.<br>><br>> In other words, if you tell a hostmaster that you need 2048 IPs, you<br>> should have the paper work for 2000<br>> CPEs/routers/servers/radios/whatever that those numbers will be<br>> deployed on.  Just a radical thought.<br>><br>>   <br><br><br>-- <br>  .  .     ___. .__      Posix Systems - Sth Africa<br> /| /|       / /__       mje@posix.co.za  -  Mark J Elkins, SCO ACE, Cisco CCIE<br>/ |/ |ARK \_/ /__ LKINS  Tel:
 +27 12 807 0590  Cell: +27 82 601 0496<br><br><br><br>------------------------------<br><br>_______________________________________________<br>rpd mailing list<br>rpd@afrinic.net<br>https://lists.afrinic.net/mailman/listinfo.cgi/rpd<br><br><br>End of rpd Digest, Vol 33, Issue 2<br>**********************************<br></pre></blockquote></td></tr></table><br>