<table cellspacing="0" cellpadding="0" border="0" ><tr><td valign="top" style="font: inherit;">SM<br>Which are four additional allocations being proposed during the Exhaustion phase?<br>Correct, its the four allocations in the exhaustion phase here....because the proposal cuts from the current allocation phase into the Exhaustion phase, the "Additional" word i believe is not misplaced<br><br><br><br>I would suggest rather - that all IPv4 space requests during the<br>exhaustion phase will only be accepted once the LIR has been allocated<br>(or has had an allocation approved) of IPv6 space under the current IPv6<br>allocation policy.<br><br>There is already plenty of IPv6 space that has been allocated but never<br>used. I think that LIRs MUST have IPv6 space and have a concrete<br>deployment plan before they can be considered for IPv4 space during the<br>exhaustion phase.<br><br>Graham<br><br>We had something along this line initially but the general
consensus during the debate is that as an RIR, we should not dictate on what technology the LIR's deploy.<br>If they are not interested in v6 deployment, we can only encourage by providing the readily available resource<br><br><br>Vincent<br><br>My definitions contains the following.......<br><br>Definitions <br>-------------- <br>(a) Local Internet Registry (LIR) <br><br>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). <br><br>(b) Existing LIRīs An existing LIR is defined as being an organization that has already been assigned or allocated IPv4 address space by AfriNIC <br><br>(c) New LIRīs A new LIR is
defined as being an organization which has recently become a member of AfriNIC but has yet to be assigned or allocated any IPv4 address space.<br><br>Regards,<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, 5/14/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;"><br>From: rpd-request@afrinic.net <rpd-request@afrinic.net><br>Subject: rpd Digest, Vol 37, Issue 2<br>To: rpd@afrinic.net<br>Date: Thursday, May 14, 2009, 12:02 PM<br><br><div class="plainMail">Send rpd mailing list submissions to<br> <a ymailto="mailto:rpd@afrinic.net" href="/mc/compose?to=rpd@afrinic.net">rpd@afrinic.net</a><br><br>To subscribe or unsubscribe via the World Wide Web, visit<br> <a href="https://lists.afrinic.net/mailman/listinfo.cgi/rpd" target="_blank">https://lists.afrinic.net/mailman/listinfo.cgi/rpd</a><br>or, via email, send a message with subject or body 'help' to<br> <a
ymailto="mailto:rpd-request@afrinic.net" href="/mc/compose?to=rpd-request@afrinic.net">rpd-request@afrinic.net</a><br><br>You can reach the person managing the list at<br> <a ymailto="mailto:rpd-owner@afrinic.net" href="/mc/compose?to=rpd-owner@afrinic.net">rpd-owner@afrinic.net</a><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. Modifications to the 32-bit ASN policy document<br> (Ernest - (AfriNIC))<br> 2. Re: Softlanding Proposal Update (SM)<br> 3. Re: AfriNIC Policy Proposal Summary (SM)<br> 4. Re: Softlanding Proposal Update (Leo Vegoda)<br> 5. Re: Softlanding Proposal Update (Douglas Onyango)<br> 6. Re: Softlanding Proposal Update (Graham Beneke)<br> 7. Re: Softlanding Proposal Update
(SM)<br> 8. Re: Softlanding Proposal Update (SM)<br><br><br>----------------------------------------------------------------------<br><br>Message: 1<br>Date: Wed, 13 May 2009 15:48:01 +0400<br>From: "Ernest - (AfriNIC)" <<a ymailto="mailto:ernest@afrinic.net" href="/mc/compose?to=ernest@afrinic.net">ernest@afrinic.net</a>><br>Subject: [AfriNIC-rpd] Modifications to the 32-bit ASN policy document<br>To: AfriNIC Resource Policy Discussion List <<a ymailto="mailto:rpd@afrinic.net" href="/mc/compose?to=rpd@afrinic.net">rpd@afrinic.net</a>><br>Message-ID: <<a ymailto="mailto:4A0AB371.9080401@afrinic.net" href="/mc/compose?to=4A0AB371.9080401@afrinic.net">4A0AB371.9080401@afrinic.net</a>><br>Content-Type: text/plain; charset=ISO-8859-1<br><br>Dear Colleagues,<br><br>Following the approval and consequent publication of RFC5396, 32-bit<br>AS Numbers will be represented in their decimal notation. The text<br>in the "4-byte ASN
policy document" still displays 32-bit AS Numbers<br>with the "asdot+" notation (also mentioned in RFC5396).<br><br>The 4-byte ASN policy document has hereby been modified, and the<br>text follows below. Comments from the community are welcome.<br><br><br><br><br>32-bit ASN Policy<br>-----------------<br><br>Date: 22 December 2005<br>Status: Implemented<br>Author: Geoff Huston, APNIC<br><br>1.0 Background<br>2.0 Nomenclature<br>3.0 Proposal<br>4.0 Rationale<br><br>*1.0 Background*:<br>-----------------<br><br>Recent studies of AS Number consumption rates indicate that the<br>existing 16-bit pool of unallocated AS Numbers will be exhausted<br>sometime in the period between 2010 and 2016, absent of any<br>concerted efforts of recovery of already-allocated AS Numbers [1]<br>[2]. Standardisation work in the IETF expanded the AS Number space<br>to a 32-bit field [3].<br><br>It is noted that some advance period may be required by
network<br>operators to undertake the appropriate procedures relating to<br>support of 32-bit AS Numbers, and while no flag day is required in<br>the transition to the longer AS Number field, it is recognised that<br>a prudent course of action is to allow for allocation of these<br>extended AS Numbers well in advance of an anticipated 16-bit AS<br>Number exhaustion date.<br><br>This policy proposal details a set of actions and associated dates<br>for RIR AS Number allocation policies to assist in an orderly<br>transition to use of the 32-bit AS Number space.<br><br>The essential attributes of this policy proposal are to facilitate<br>the ease of transitional arrangements by equipment vendors, network<br>managers and network operations staff, to provide the industry with<br>some predictability in terms of dates and associated actions with<br>respect to registry operational procedures for AS Number allocations.<br><br><br>*2.0
Nomenclature*:<br>-------------------<br><br>AS Numbers will be identified using the "asplain" format as<br>described in RFC5396. Using the "asplain" method, all AS numbers<br>will be identified and represented in their decimal integer notation.<br><br><br>*3.0 Proposal*:<br>----------------<br><br>This policy proposal nominates three dates for changes to the<br>current AS Number allocation policy for the registry:<br><br><br>On 1 January 2007 the registry will process applications that<br>specifically request 32-bit only AS Numbers and allocate such AS<br>Numbers as requested by the applicant. In the absence of any<br>specific request for a 32-bit only AS Number, a 16-bit only AS<br>Number will be allocated by the registry.<br><br>On 1 January 2009 the registry will process applications that<br>specifically request 16-bit only AS Numbers and allocate such AS<br>Numbers as requested by the applicant. In the absence of any<br>specific request for a
16-bit only AS Number, a 32-bit only AS<br>Number will be allocated by the registry.<br><br>On 1 January 2010 the registry will cease to make any distinction<br>between 16-bit only AS Numbers and 32-bit only AS Numbers, and will<br>operate AS Number allocations from an undifferentiated 32-bit AS<br>Number allocation pool.<br><br>No other changes in AS Number allocation policy are implied by this<br>proposal.<br><br><br>*4.0 Rationale*:<br>----------------<br><br>The essential attributes of this policy proposal are to facilitate<br>the ease of transitional arrangements by equipment vendors, network<br>managers and network operations staff, to provide the industry with<br>some predictability in terms of dates and associated actions with<br>respect to registry operational procedures for AS Number allocations.<br><br>References<br><br>[1] Daily AS Number Report: <a href="http://www.potaroo.net/tools/asns"
target="_blank">http://www.potaroo.net/tools/asns</a><br>[2] ASNs MIA: A Comparison of RIR Statistics and RIS Reality:<br> <a href="http://www.nanog.org/mtg-0510/wilhelm.html" target="_blank">http://www.nanog.org/mtg-0510/wilhelm.html</a><br>[3] BGP Support for Four-octet AS Number Space:<br> <a href="http://www.ietf.org/rfc/rfc4893.txt" target="_blank">http://www.ietf.org/rfc/rfc4893.txt</a><br><br><br><br>------------------------------<br><br>Message: 2<br>Date: Wed, 13 May 2009 07:26:44 -0700<br>From: SM <<a ymailto="mailto:sm@resistor.net" href="/mc/compose?to=sm@resistor.net">sm@resistor.net</a>><br>Subject: Re: [AfriNIC-rpd] Softlanding Proposal Update<br>To: Douglas Onyango <<a ymailto="mailto:ondouglas@yahoo.com" href="/mc/compose?to=ondouglas@yahoo.com">ondouglas@yahoo.com</a>><br>Cc: <a ymailto="mailto:rpd@afrinic.net" href="/mc/compose?to=rpd@afrinic.net">rpd@afrinic.net</a><br>Message-ID: <<a
ymailto="mailto:6.2.5.6.2.20090513071251.0294ff10@resistor.net" href="/mc/compose?to=6.2.5.6.2.20090513071251.0294ff10@resistor.net">6.2.5.6.2.20090513071251.0294ff10@resistor.net</a>><br>Content-Type: text/plain; charset="us-ascii"; format=flowed<br><br>Hi Douglas,<br>At 00:15 13-05-2009, Douglas Onyango wrote:<br>>This is the most recent Version of the Softlanding Policy Proposal.<br><br>[snip]<br><br>>(ii) Exhaustion Phase:<br>><br>>During the exhaustion phase, the following allocation and assignment <br>>policy for the last /8 IPv4 address will be used:<br>>a) Instead of the /22 block (1024) addresses allocated in the <br>>current policy, the new minimum allocation size of /23 (512 <br>>addresses) will be allocated to any LIR that requests for IPv4 <br>>resources. This is also the maximum allocation size, even though <br>>LIRs may request for more than a /23. No LIR may get more than 4 <br>>additional allocations
once the Exhaustion phase has begun.<br><br>Which are four additional allocations being proposed during the <br>Exhaustion phase?<br><br>>b) Together with the v4 allocation, AfriNIC shall allocate an IPv6 <br>>address block in compliance with the current IPv6 allocation policy <br>>(<<a href="http://www.afrinic.net/docs/policies/afpol-v6200407-000.htm" target="_blank">http://www.afrinic.net/docs/policies/afpol-v6200407-000.htm</a>><a href="http://www.afrinic.net/docs/policies/afpol-v6200407-000.htm" target="_blank">http://www.afrinic.net/docs/policies/afpol-v6200407-000.htm</a>) <br>>to the LIR (in case it doesn't have any).<br><br>I don't see why this is being proposed as part of a soft landing <br>proposal. I suggest removing any mention of IPv6 as that is already <br>covered under the current IPv6 allocation policy.<br><br>Regards,<br>-sm <br><br><br><br>------------------------------<br><br>Message: 3<br>Date: Wed, 13 May
2009 07:55:51 -0700<br>From: SM <<a ymailto="mailto:sm@resistor.net" href="/mc/compose?to=sm@resistor.net">sm@resistor.net</a>><br>Subject: Re: [AfriNIC-rpd] AfriNIC Policy Proposal Summary<br>To: AfriNIC RPD ML <<a ymailto="mailto:rpd@afrinic.net" href="/mc/compose?to=rpd@afrinic.net">rpd@afrinic.net</a>><br>Message-ID: <<a ymailto="mailto:6.2.5.6.2.20090513074039.034c6658@resistor.net" href="/mc/compose?to=6.2.5.6.2.20090513074039.034c6658@resistor.net">6.2.5.6.2.20090513074039.034c6658@resistor.net</a>><br>Content-Type: text/plain; charset="us-ascii"; format=flowed<br><br>At 05:50 15-04-2009, Vincent Ngundi wrote:<br>>Policy proposal : IPv6 Allocations to Non-Profit Networks<br>>Proposal Date : 13 Jan 2009<br>>Scope : Regional proposal<br>>afpol-v6200901 <br>><<<a href="http://www.afrinic.net/docs/policies/afpol-v6200901.htm" target="_blank">http://www.afrinic.net/docs/policies/afpol-v6200901.htm</a>><a
href="http://www.afrinic.net/docs/policies/afpol-v6200901.htm" target="_blank">http://www.afrinic.net/docs/policies/afpol-v6200901.htm</a>><br>><br>>Summary:<br>>This policy seeks to make it as easy as possible for non-profit <br>>entities to obtain a /48 PI IPv6 addressing resources from AfriNIC <br>>and drive the deployment of and demand for IPv6 services through <br>>this in Africa.<br><br>The Definitions section has an "(a)" only.<br><br>The definition mentions legal responsibility within a country or <br>region. I suggest removing "region" as ths proposed policy is for <br>local geographical areas only.<br><br>Does the organisation have to justify the need for the IPv6 address space?<br><br>The abstract mentions a membership category. There is no mention of <br>that or what fee structure is applicable in the text that follows.<br><br>Regards,<br>-sm <br><br><br><br>------------------------------<br><br>Message:
4<br>Date: Wed, 13 May 2009 13:23:52 -0700<br>From: Leo Vegoda <<a ymailto="mailto:leo.vegoda@icann.org" href="/mc/compose?to=leo.vegoda@icann.org">leo.vegoda@icann.org</a>><br>Subject: Re: [AfriNIC-rpd] Softlanding Proposal Update<br>To: "<a ymailto="mailto:ondouglas@yahoo.com" href="/mc/compose?to=ondouglas@yahoo.com">ondouglas@yahoo.com</a>" <<a ymailto="mailto:ondouglas@yahoo.com" href="/mc/compose?to=ondouglas@yahoo.com">ondouglas@yahoo.com</a>>, "<a ymailto="mailto:rpd@afrinic.net" href="/mc/compose?to=rpd@afrinic.net">rpd@afrinic.net</a>"<br> <<a ymailto="mailto:rpd@afrinic.net" href="/mc/compose?to=rpd@afrinic.net">rpd@afrinic.net</a>><br>Message-ID: <C6307A68.2910D%<a ymailto="mailto:leo.vegoda@icann.org" href="/mc/compose?to=leo.vegoda@icann.org">leo.vegoda@icann.org</a>><br>Content-Type: text/plain; charset="iso-8859-1"<br><br>Hi Douglas,<br><br>Thank you for sharing this.<br><br>I am not sure if I
have understood the proposal properly and would be<br>grateful if you could please clarify some things for me.<br><br>On 13/05/2009 12:15, "Douglas Onyango" <<a ymailto="mailto:ondouglas@yahoo.com" href="/mc/compose?to=ondouglas@yahoo.com">ondouglas@yahoo.com</a>> wrote:<br><br>[...]<br><br>> During the exhaustion phase, the following allocation and assignment policy<br>> for the last /8 IPv4 address will be used:<br><br>Does this policy only apply to the /8 to be allocated to AfriNIC under the<br>recently ratified global policy, or does it apply to other IPv4 space held<br>by AfriNIC at that time?<br><br>> a) Instead of the /22 block (1024) addresses allocated in the current policy,<br>> the new minimum allocation size of /23 (512 addresses) will be allocated to<br>> any LIR that requests for IPv4 resources. This is also the maximum allocation<br>> size, even though LIRs may request for more than a /23. No LIR may get
more<br>> than 4 additional allocations once the Exhaustion phase has begun.<br><br>Does this mean that a new LIR may receive one initial allocation plus four<br>additional allocations, or is it a maximum of four /23 allocations in total?<br><br>I am not sure how many LIRs you would like to benefit from this policy. It<br>would be good to check the proposal against the current and projected<br>AfriNIC membership numbers to see whether it is possible to be more<br>generous.<br><br>Kind regards,<br><br>Leo Vegoda<br><br><br><br>------------------------------<br><br>Message: 5<br>Date: Thu, 14 May 2009 00:07:54 -0700 (PDT)<br>From: Douglas Onyango <<a ymailto="mailto:ondouglas@yahoo.com" href="/mc/compose?to=ondouglas@yahoo.com">ondouglas@yahoo.com</a>><br>Subject: Re: [AfriNIC-rpd] Softlanding Proposal Update<br>To: SM <<a ymailto="mailto:sm@resistor.net" href="/mc/compose?to=sm@resistor.net">sm@resistor.net</a>><br>Cc: <a
ymailto="mailto:rpd@afrinic.net" href="/mc/compose?to=rpd@afrinic.net">rpd@afrinic.net</a><br>Message-ID: <<a ymailto="mailto:472990.49359.qm@web52101.mail.re2.yahoo.com" href="/mc/compose?to=472990.49359.qm@web52101.mail.re2.yahoo.com">472990.49359.qm@web52101.mail.re2.yahoo.com</a>><br>Content-Type: text/plain; charset="iso-8859-1"<br><br>SM,<br>Not sure i fully understood your first question.<br><br>This policy is meant to help in the transition from v4 to v6, and as such every initiative to help people move in the direction of v6 would be a good one. one of them is availing the addresses (if they don't have any)<br><br>Regards,<br>Douglas onyango +256(0712)981329<br><br>If you are not part of the solution, your are part of the Problem.<br><br>--- On Wed, 5/13/09, SM <<a ymailto="mailto:sm@resistor.net" href="/mc/compose?to=sm@resistor.net">sm@resistor.net</a>> wrote:<br><br>From: SM <<a ymailto="mailto:sm@resistor.net"
href="/mc/compose?to=sm@resistor.net">sm@resistor.net</a>><br>Subject: Re: [AfriNIC-rpd] Softlanding Proposal Update<br>To: "Douglas Onyango" <<a ymailto="mailto:ondouglas@yahoo.com" href="/mc/compose?to=ondouglas@yahoo.com">ondouglas@yahoo.com</a>><br>Cc: <a ymailto="mailto:rpd@afrinic.net" href="/mc/compose?to=rpd@afrinic.net">rpd@afrinic.net</a><br>Date: Wednesday, May 13, 2009, 5:26 PM<br><br>Hi Douglas,<br>At 00:15 13-05-2009, Douglas Onyango wrote:<br>> This is the most recent Version of the Softlanding Policy Proposal.<br><br>[snip]<br><br>> (ii) Exhaustion Phase:<br>> <br>> During the exhaustion phase, the following allocation and assignment policy for the last /8 IPv4 address will be used:<br>> 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 is also the maximum
allocation size, even though LIRs may request for more than a /23. No LIR may get more than 4 additional allocations once the Exhaustion phase has begun.<br><br>Which are four additional allocations being proposed during the Exhaustion phase?<br><br>> b) Together with the v4 allocation, AfriNIC shall allocate an IPv6 address block in compliance with the current IPv6 allocation policy (<<a href="http://www.afrinic.net/docs/policies/afpol-v6200407-000.htm" target="_blank">http://www.afrinic.net/docs/policies/afpol-v6200407-000.htm</a>><a href="http://www.afrinic.net/docs/policies/afpol-v6200407-000.htm" target="_blank">http://www.afrinic.net/docs/policies/afpol-v6200407-000.htm</a>) to the LIR (in case it doesn't have any).<br><br>I don't see why this is being proposed as part of a soft landing proposal. I suggest removing any mention of IPv6 as that is already covered under the current IPv6 allocation policy.<br><br>Regards,<br>-sm
<br><br><br><br> <br>-------------- next part --------------<br>An HTML attachment was scrubbed...<br>URL: <a href="https://lists.afrinic.net/pipermail/rpd/attachments/20090514/d1a0600c/attachment-0001.htm" target="_blank">https://lists.afrinic.net/pipermail/rpd/attachments/20090514/d1a0600c/attachment-0001.htm</a><br><br>------------------------------<br><br>Message: 6<br>Date: Thu, 14 May 2009 10:07:41 +0200<br>From: Graham Beneke <<a ymailto="mailto:graham-ml@apolix.co.za" href="/mc/compose?to=graham-ml@apolix.co.za">graham-ml@apolix.co.za</a>><br>Subject: Re: [AfriNIC-rpd] Softlanding Proposal Update<br>To: AfriNIC Resource Policy Discussion List <<a ymailto="mailto:rpd@afrinic.net" href="/mc/compose?to=rpd@afrinic.net">rpd@afrinic.net</a>><br>Message-ID: <<a ymailto="mailto:4A0BD14D.80004@apolix.co.za" href="/mc/compose?to=4A0BD14D.80004@apolix.co.za">4A0BD14D.80004@apolix.co.za</a>><br>Content-Type:
text/plain; charset=ISO-8859-1<br><br>Hi Douglas<br><br>My thoughts inline:<br><br>Douglas Onyango wrote:<br>> a) Instead of the /22 block (1024) addresses allocated in the current<br>> policy, the new minimum allocation size of /23 (512 addresses) will be<br>> allocated to any LIR that requests for IPv4 resources. This is also the<br>> maximum allocation size, even though LIRs may request for more than a<br>> /23. No LIR may get more than 4 additional allocations once the<br>> Exhaustion phase has begun.<br><br>This is extremely restrictive and I think that we should rather just be<br>changing the minimum and maximum allocation sizes but keep it as a range:<br><br>On the one hand - a network that is running full native IPv6 will only<br>need a handful of IPv4 addresses to provide their core services dual<br>stacked and provide a NAT gateway to their users. A /24 is sufficient<br>for global BGP routability and LIRs should be able to
request this if<br>this is all they require during the exhaustion phase.<br><br>On the other hand - there are a number of operators in the AfiNIC region<br>who use about /21 for just their backbone networks.<br><br>I would suggest that we define the minimum allocation as /24 and the<br>maximum allocation as /20 (this figure is up for discussion).<br><br>As Leo mentione - we should be considering the number of AfriNIC LIRs<br>when setting the limit on the amount of address space each may receive.<br>Perhaps one of the AfriNIC staff could provide details of the current<br>number of LIRs and the growth trend over the recent years.<br><br>> b) Together with the v4 allocation, AfriNIC shall allocate an IPv6<br>> address block in compliance with the current IPv6 allocation policy<br>> (<a href="http://www.afrinic.net/docs/policies/afpol-v6200407-000.htm" target="_blank">http://www.afrinic.net/docs/policies/afpol-v6200407-000.htm</a>) to the
LIR<br>> (in case it doesn't have any).<br><br>I think that this puts the focus on the wrong aspects. We are trying to<br>drive IPv6 adoption are we not? It should not be an afterthought once<br>the IPv4 space has been allocated.<br><br>I would suggest rather - that all IPv4 space requests during the<br>exhaustion phase will only be accepted once the LIR has been allocated<br>(or has had an allocation approved) of IPv6 space under the current IPv6<br>allocation policy.<br><br>There is already plenty of IPv6 space that has been allocated but never<br>used. I think that LIRs MUST have IPv6 space and have a concrete<br>deployment plan before they can be considered for IPv4 space during the<br>exhaustion phase.<br><br>regards<br>-- <br>Graham Beneke<br>Apolix Internet Services<br>E-Mail/MSN/Jabber: <a ymailto="mailto:graham@apolix.co.za" href="/mc/compose?to=graham@apolix.co.za">graham@apolix.co.za</a> Skype: grbeneke<br>VoIP:
087-750-5696 Cell: 082-432-1873<br><a href="http://www.apolix.co.za/" target="_blank">http://www.apolix.co.za/</a><br><br><br>------------------------------<br><br>Message: 7<br>Date: Thu, 14 May 2009 01:27:11 -0700<br>From: SM <<a ymailto="mailto:sm@resistor.net" href="/mc/compose?to=sm@resistor.net">sm@resistor.net</a>><br>Subject: Re: [AfriNIC-rpd] Softlanding Proposal Update<br>To: Douglas Onyango <<a ymailto="mailto:ondouglas@yahoo.com" href="/mc/compose?to=ondouglas@yahoo.com">ondouglas@yahoo.com</a>><br>Cc: <a ymailto="mailto:rpd@afrinic.net" href="/mc/compose?to=rpd@afrinic.net">rpd@afrinic.net</a><br>Message-ID: <<a ymailto="mailto:6.2.5.6.2.20090514001415.028bc778@resistor.net" href="/mc/compose?to=6.2.5.6.2.20090514001415.028bc778@resistor.net">6.2.5.6.2.20090514001415.028bc778@resistor.net</a>><br>Content-Type: text/plain;
charset="us-ascii"; format=flowed<br><br>Hi Douglas,<br>At 00:07 14-05-2009, Douglas Onyango wrote:<br>>Not sure i fully understood your first question.<br><br>IPv4 is a public resource which AfriNIC manages on behalf of its <br>constituents. As we move towards the IPv4 address exhaustion, there <br>will be a scarcity for IPv4 addresses. The proposal is to ensure a <br>fair allocation from the limited pool of IPv4 addresses. Without <br>that, a large network or country can end up with a larger slice of <br>the pool. This will have a negative impact on countries or networks <br>that experience a slower growth.<br><br>There are a few cable links currently being deployed on the <br>continent. Once the infrastructure is there, we may see more demand <br>for IP address space within these countries. It's only when AfriNIC <br>turns down their IPv4 allocation request that they will understand <br>the consequences of this
proposed policy. It will be too late to <br>overturn the policy once the IPv4 address pool is exhausted.<br><br>Before devising a policy for managing the last /8 IPv4 address pool, <br>we should review IPv4 address usage in the region over the last years <br>and do a projection to find out how long the IPv4 address pool will <br>last. We should take into account the number of LIRs and see that <br>there is a fair distribution.<br><br>Your proposal specifies that a LIR can be allocated a /23 (IPv4 <br>maximum allocation size) and four additional /23. My question is <br>about whether the aggregate allocation (one + four) will allow <br>equitable distribution of IPv4 addresses among LIRs. To put it <br>differently, how did you reach these numbers?<br><br>>This policy is meant to help in the transition from v4 to v6, and as <br>>such every initiative to help people move in the direction of v6 <br>>would be a good one. one of
them is availing the addresses (if they <br>>don't have any)<br><br>Getting people to adopt IPv6 is a good initiative. But that should <br>not turn out into dishing out IP address space if the assignee does <br>not justify the request. If members do not have any IPv6 address <br>space, it is generally because:<br><br> (i) they are not implementing IPv6 on their network<br><br> (ii) they plan to extend IPv4 lifetime through by using NAT<br><br>An IPv6 address allocation won't change that. If you want to help <br>the transition from IPv4 to IPv6, you can specify that the member <br>shows a migration plan. However, I don't think that it's a good <br>strategy as AfriNIC cannot tell people how they should run their networks.<br><br>Regards,<br>-sm <br><br><br><br>------------------------------<br><br>Message: 8<br>Date: Thu, 14 May 2009 01:50:14 -0700<br>From: SM <<a ymailto="mailto:sm@resistor.net"
href="/mc/compose?to=sm@resistor.net">sm@resistor.net</a>><br>Subject: Re: [AfriNIC-rpd] Softlanding Proposal Update<br>To: Graham Beneke <<a ymailto="mailto:graham-ml@apolix.co.za" href="/mc/compose?to=graham-ml@apolix.co.za">graham-ml@apolix.co.za</a>><br>Cc: AfriNIC Resource Policy Discussion List <<a ymailto="mailto:rpd@afrinic.net" href="/mc/compose?to=rpd@afrinic.net">rpd@afrinic.net</a>><br>Message-ID: <<a ymailto="mailto:6.2.5.6.2.20090514013414.032f3890@resistor.net" href="/mc/compose?to=6.2.5.6.2.20090514013414.032f3890@resistor.net">6.2.5.6.2.20090514013414.032f3890@resistor.net</a>><br>Content-Type: text/plain; charset="us-ascii"; format=flowed<br><br>Hi Graham,<br><br>I won't respond to the first part of your message for now.<br><br>At 01:07 14-05-2009, Graham Beneke wrote:<br>>I think that this puts the focus on the wrong aspects. We are trying to<br>>drive IPv6 adoption are we not? It should not be an
afterthought once<br>>the IPv4 space has been allocated.<br><br>Let's not mix evangelisation and operational matters. It's up to the <br>members to determine whether they want to use this proposal to drive <br>IPv6 adoption. It's not up to me to determine the financial impact. :-)<br><br>>I would suggest rather - that all IPv4 space requests during the<br>>exhaustion phase will only be accepted once the LIR has been allocated<br>>(or has had an allocation approved) of IPv6 space under the current IPv6<br>>allocation policy.<br>><br>>There is already plenty of IPv6 space that has been allocated but never<br>>used. I think that LIRs MUST have IPv6 space and have a concrete<br>>deployment plan before they can be considered for IPv4 space during the<br>>exhaustion phase.<br><br>That's one of the questions item (b) may have to address.<br><br>Regards,<br>-sm
<br><br><br><br>------------------------------<br><br>_______________________________________________<br>rpd mailing list<br><a ymailto="mailto:rpd@afrinic.net" href="/mc/compose?to=rpd@afrinic.net">rpd@afrinic.net</a><br><a href="https://lists.afrinic.net/mailman/listinfo.cgi/rpd" target="_blank">https://lists.afrinic.net/mailman/listinfo.cgi/rpd</a><br><br><br>End of rpd Digest, Vol 37, Issue 2<br>**********************************<br></div></blockquote></td></tr></table><br>