[rpd] LACNIC reaches final /10 of IPv4 space

Wed Jun 11 09:32:06 UTC 2014

Involve the regulators so they can police the process...

Telecoms only listen to the regulators.

Noah
On 11 Jun 2014 11:05, "Kris Seeburn" <seeburn.k at gmail.com> wrote:

> I guess it is a simple question of what can we do to ensure that the
> telcos and we know the best users are mobile operators who can use this
> space easily and surely we have ADSL in many parts of our service region
> who are still bound to NAT.
>
> Do we need a lenient policy to force them to take up more space but still
> we want the end users at the same time to adopt so we can wear our space
> out and move on.
>
> my guess is that we all know what is happening and how things are moving
> but we need to reflect better on easing the space allocation whilst
> ensuring a proper allocation without being stolen.
>
> The best question is what policy do we push to ensure that these happen
> naturally.
>
> Kris
>
> On Jun 11, 2014, at 11:50 AM, Kofi ansa akufo <kofi.ansa at gmail.com> wrote:
>
> Hi All
>
> Well so IPv4 is depleting in other regions - but what are the REAL stats
> with respect to the type of consumers of the resources in those regions?
> Which kind of LIRs and EUs are consuming the resources in these regions? Is
> it telcos, Hosting Providers? I bet you will find 7 out of 10 homes in
> these regions using NAT assuming v6 is not transparently pushed to these
> consumers.
>
> We still have a lot of mobile Telcos NATing. If these kind of LIRs alone
> in our region decide to do away with NATing, our IPv4 left will be
> vaporized :). We sldo see a lot of LTE (well branded as 4G data service)
> being deployed which instead of taking advantage of new setups to deploy
> native v6 and / or v4 also going down the NATing route. If we really want
> to do away with the rest of the  v4 quickly i bet these groups hold the
> solution. But then how much does the community get out of this in terms of
> both revenue, infrastructure as well job creation? Is there a case for
> encouraging businesses in other regions to be established or co-located in
> our region for mutual benefit?
>
> What we have by far in terms of access technology which has seen much
> usage of IPv4 is xDSL (e.g. ADSL). Even here due to operational cost many
> operators assign a single dynamic IPv4 address to each client CPE (unless
> explicity requested by customer) which by default implement NAT behind the
> "public dynamic IPv4". Most consumer CPEs by default implement NATing and a
> few have IPv6 in their protocol stack. A few providers have well deployed
> automated push configs to CPEs in terms of managed services.
>
> - This is where I believe IPv6 adoption program should concentrate.
> Encourage procurement of CPEs with v6 support as well as put up element
> management systems which will automatically configure such CPEs not just
> for the outside facing interfaces but the inside as well. New roll-outs
> Projects like LTE should consider going native v6.
>
> Key point here is if End Users - I mean consumers (not Companies in the EU
> category) seldom care about how their various devices are connected be it
> NATing behind one Public IP or a hierarchy of NATing. Are they our target
> group? If they are what should we do to make them aware of the issues with
> NATing and how do we make their connectivity transparent to them?
>
> cheers
>
> Kofi
>
>
> On 11 June 2014 10:47, Andrew Alston <Andrew.Alston at liquidtelecom.com>
> wrote:
>
>>  Hi All,
>>
>>
>>
>> As far as I can see it the following should be considered.
>>
>>
>>
>> Firstly, our continent is far to NAT dependent, and this is in everyone’s
>> disadvantage.  >From a network provider perspective, clients who run NAT
>> are more likely to churn due to ease of renumbering.  From a client
>> perspective, the limitations on end to end communications can introduce
>> problems.  From a security perspective, the ability of individuals with
>> nefarious purpose to hide behind NAT creates problems. As such, I’d argue
>> that using our remaining space to remove the heavy NAT we see on this
>> continent would be advantageous.
>>
>>
>>
>> Further to this, the removal of NAT actually encourages the adoption of
>> IPv6, it is far easier to dual-stack a network with IPv6 if you can run a
>> single topology without worrying about the IPv4 translations.  The question
>> is, how do we encourage people to move away from a legacy behavior that is
>> in their disadvantage but for so long as been painted as a security
>> mechanism (which it most certainly is not, and there are multiple papers to
>> back this perspective available).
>>
>>
>>
>> Secondly, we need to consider if we wish to encourage end user adoption
>> of IPv4 space, or encourage further takeup of space by LIR’s.  There is a
>> key differentiator here, and it actually creates an interesting conflict.
>> From a provider perspective, having clients numbered on their space again,
>> reduces churn and is in the advantage of the provider (LIR), from a client
>> perspective, having provider independent space makes them more portable,
>> grants the easy ability to multi-home and in many instances it may be
>> easier for them to obtain end user space than to get it out of a provider.
>> That however comes with the disadvantage that the end user who chooses this
>> route will probably need to think about running BGP (particularly if they
>> are multi-homing), or alternatively having their sole provider announce on
>> their behalf, this creates complexity that can lead to a rise in OPEX.
>>
>>
>>
>> Either way though, I believe we need to encourage the adoption of our
>> space by whatever reasonable means are possible.  Sitting on a large pool
>> of IPv4 space that is being unallocated disadvantages the continent in a
>> multitude of ways, including, but not limited to:
>>
>>
>>
>> a.)    The amount of V4 space sitting unused discourages the adoption of
>> IPv6, which in the long term holistic sense is bad for the continent in
>> general
>>
>> b.)    The large pool encourages dodgy vendors to come with an argument
>> that we don’t need V6 any time soon so we can be a legacy hardware dumping
>> ground
>>
>> c.)     A greater adoption of V4 by the general community will lead to a
>> greater economy of scale in terms of allocation and management of space
>> within the RIR.
>>
>>
>>
>> Hence, I’d welcome any ideas as to how to drastically encourage the
>> uptake of the V4 that is sitting unused in our pool.
>>
>>
>>
>> Note: This thoughts represent my personal views and are in no way stated
>> as board perspective or the perspective of any other entity to which I may
>> be associated.
>>
>>
>>
>> Thanks
>>
>>
>>
>> Andrew
>>
>>
>>
>>
>>
>> *From:* rpd-bounces at afrinic.net [mailto:rpd-bounces at afrinic.net] *On
>> Behalf Of *Kris Seeburn
>> *Sent:* Wednesday, June 11, 2014 8:43 AM
>> *To:* rpd
>> *Subject:* Re: [rpd] LACNIC reaches final /10 of IPv4 space
>>
>>
>>
>> There are two ends to it.
>>
>>
>>
>>    - We either look at a policy to protect our ipv4 space which would
>>    actually defeat the full push of ipv6
>>    - Or we find ways to deplete our ipv4 space faster that we can move
>>    to ipv6 faster
>>
>>
>>
>> We all know that most hosting / ecom sites are still based on ipv4
>> infrastructure though. As much as we need to protect the ipv4 space we
>> still need to push the ipv6 space. Afrinic nevertheless still has a good
>> deal of ipv4 space. The question is how do we move both agenda forward?
>>
>>
>>
>> I think obviously we need to look at our policy and what can make things
>> work for us. A sharing or sales of ipv4 space with other RIRs as need may
>> also look as a better way of still protecting the precious space whilst
>> still making money out of it. I am not sure. I think this is still a
>> dilemma we all need to figure out.
>>
>>
>>
>> NB: This is not a board perspective but my personal take at it.
>>
>>
>>
>> Kris
>>
>>
>>
>> On Jun 11, 2014, at 9:17 AM, Bope Domilongo Christian <
>> christianbope at gmail.com> wrote:
>>
>>
>>
>>   Thank you Alan and seun, this an important  milestone, having a policy
>> to protect our critical resources will be great.
>>
>> With best regards,
>>
>> writing on my personal capacity.
>>
>>
>>
>> On Wed, Jun 11, 2014 at 4:13 AM, Seun Ojedeji <seun.ojedeji at gmail.com>
>> wrote:
>>
>> Thanks for this update Alan, from all indication it will seem that v4
>> exhaustion time within AfriNIC region may be sooner than earlier
>> predicted.
>>
>> Should this region be worried?... maybe:
>> - More content in those region where v4 is getting exhausted will go v6
>> but then v6 deployment in our region is relatively low (someone says there
>> is translation to the rescue)
>> - Our region will continue to experience an increase in v4 requests from
>> organizations that are more domicile in regions with v4 exhaustion. Perhaps
>> this could be an opportunity to "by policy" improve ISP establishment in
>> our region? Maybe yes. Should we also "by policy" ensure addresses within
>> this region are used more within the region.... how do we encourage this as
>> the region seem to be comfortable with *translation*. Can policy make this
>> happen?
>>
>> Cheers!
>> PS: My views alone.
>> sent from Google nexus 4
>> kindly excuse brevity and typos.
>>
>> On 10 Jun 2014 17:23, "Alan Barrett" <apb at cequrux.com> wrote:
>>
>> Three weeks ago, on 20 May 2014, LACNIC's available pool of IPv4 space
>> became less then a /9 equivalent.  This triggered the activation of IANA's
>> Recovered IPv4 Pool in terms of Global Policy GPP-IPv4-2011.
>>
>> Today, 10 June 2014, LACNIC's available pool of IPv4 space became less
>> than a /10 equivalent (4194302 IPv4 addresses).  This triggers LACNIC's
>> IPv4 exhaustion policy.
>>
>> Announcements from 20 May 2014:
>> <http://www.nro.net/news/lacnics-ipv4-address-pool-now-down-to-a-9>
>> <http://www.nro.net/news/iana-allocates-recovered-ipv4-addresses-to-rir>
>>
>> Announcement from 10 Jun 2014:
>> <
>> http://www.lacnic.net/en/web/anuncios/2014-no-hay-mas-direcciones-ipv4-en-lac
>> >
>>
>> --apb (Alan Barrett)
>> _______________________________________________
>> rpd mailing list
>> rpd at afrinic.net
>> https://lists.afrinic.net/mailman/listinfo.cgi/rpd
>>
>>
>> _______________________________________________
>> rpd mailing list
>> rpd at afrinic.net
>> https://lists.afrinic.net/mailman/listinfo.cgi/rpd
>>
>>
>>
>> _______________________________________________
>> rpd mailing list
>> rpd at afrinic.net
>> https://lists.afrinic.net/mailman/listinfo.cgi/rpd
>>
>>
>>
>> Kris Seeburn
>>
>> seeburn.k at gmail.com
>>
>>    - www.linkedin.com/in/kseeburn/
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> ------------------------------
>> DISCLAIMER: This email contains proprietary information some or all of
>> which may be legally privileged. It is for the intended recipient only. If
>> an addressing or transmission error has misdirected this email, please
>> notify the author by replying to this email. If you are not the intended
>> recipient, you must not use, disclose, copy, print, or rely on this email.
>> We cannot accept liability for any statements made which are clearly the
>> sender's own and not expressly made on behalf of this company or one of its
>> agents.
>>
>>
>> _______________________________________________
>> rpd mailing list
>> rpd at afrinic.net
>> https://lists.afrinic.net/mailman/listinfo.cgi/rpd
>>
>>
> _______________________________________________
> rpd mailing list
> rpd at afrinic.net
> https://lists.afrinic.net/mailman/listinfo.cgi/rpd
>
>
>
>
> _______________________________________________
> rpd mailing list
> rpd at afrinic.net
> https://lists.afrinic.net/mailman/listinfo.cgi/rpd
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.afrinic.net/pipermail/rpd/attachments/20140611/d1de1d88/attachment.html>